On Thursday, 24 January 2019 20:41:02 UTC+1, Jesse Glick wrote:
>> make backup of jobs history before Jenkins master pod deletion and
restore it in new pod
>> You do not just set a custom build record directory […] and use a
persistent volume claim? […]
>> Beware however that there is some more true state besides
>> build history; it is safest to persist the entire `$JENKINS_HOME`, and
>> let JCasC + `job-dsl` overwrite old configurations.
>> Making backup of ~50GB is not good idea. […] Backup is triggered before
Jenkins master pod deletion and it have to be quick as possible.
> Which is why I suggested a PVC rather than a backup per se. Anyway the
> vast majority of the disk usage in `$JENKINS_HOME` is likely to be
> build records (`*/jobs/**/builds/**`), especially if you are not using
> any of the other “pluggable storage” features mentioned in the SIG to
> externalize big files like artifacts or logs. Or do you mean something
> else by “jobs history”?
tar -C ${jenkinsHome} -z --exclude jobs/*/config.xml --exclude
jobs/*/workspace* --exclude jobs/*/simulation.log -c config-history jobs
-f ${tmpBackupPath}
The biggest team have 400MB backup(*.tar.gz), after unpack it is 2GB. When
using Kubernetes plugin build workspace is located in another pod and it is
not saved in JENKINS_HOME.
Teams save artifacts explicity what they want to store(test/performance
results ...). Kubernetes clusters have troubles with attach/detach of
PVC(one exception is NFS).
We had a lot of issues when Kubernetes coudn't detach PVC after pod restart
and the new one coudn't be loaded. PVC should be added as backup strategy
but is hightly not recommended.
Moreover detach and attach takes a lot of time and it increases time when
master will be offline.
>> plugins are separated in two groups: required by jenkins-operator(used
to configure Jenkins)(A) and required by user(B)
> I would agree with Nicolas here that you should not use Jenkins code
> to manage installed plugins. (You can mandate the inclusion of some
> minimum version of certain plugins, such as `configuration-as-code`,
> known to be needed for managing _other_ configuration.)
Yes, you are right. I need to think on solution where:
- plugins are defined in one place
- plugin can be set with version or the last version should be picked
- where dependend plugins can be set
To avoid Jenkins master pod restart when some plugins have changed and
Jenkins is running I can install missing plugins, delete unused and restart
Jenkins inside pod.
>> we have to run some jobs on master to configure it(apply groovy scripts,
restore/backup and seed jobs creation).
> This seems inadvisable and is generally insecure. Better for these
> tasks to be externalized.
I'm understand the risk, however encapsulation configuration tasks into
jobs give view what is wrong with configuration provided by user.
Maybe there is a solution where we can restrict which jobs can be run on
master?
> (In the case of the `job-dsl` plugin, no master executor should be
> required as it runs in-process. That in itself is a major headache and
> we ought to prefer systems which run externally.)
Thanks for the tip, I will try this.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/4e4c3808-402f-4432-bf50-be08f77a45d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
