jenkins-infra
/
iep
mirror of https://github.com/jenkins-infra/iep
1
0
Fork 0
Code Issues Releases Wiki Activity

Update upgrade process

This commit is contained in:
olblak 2017-07-06 15:11:01 +02:00
parent 73b93eee00
commit c6fa2de77b
1 changed files with 12 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
iep-007/README.adoc
View File

@ -61,6 +61,12 @@ IMPORTANT: The old cluster must be kept until the new one is ready to served req
==== Step 1 : Backup
. Backup secrets containing Letsencrypt certificates. (Manual operation)
----
mkdir ~/tls
.bin/kubectl get secret accountapp-tls --export=true -o yaml > ~/tls/accountapp.yaml
.bin/kubectl get secret pluginsite-tls --export=true -o yaml > ~/tls/pluginsite.yaml
.bin/kubectl get secret repo-proxy-tls --export=true -o yaml > ~/tls/repo-proxy.yaml
----
==== Step 2 : Deploy the new cluster
@ -82,6 +88,11 @@ profile::kubernetes::kubectl::client_key_data
kubectl get service nginx --namespace nginx-ingress
----
. Restore backed up secrets containing Letsencrypt certificates on the new cluster (Manual operation)
----
.bin/kubectl apply -f ~/tls/accountapp.yaml
.bin/kubectl apply -f ~/tls/pluginsite.yaml
.bin/kubectl apply -f ~/tls/repo-proxy.yaml
----
. Validate that everything work as expected (Manual operation)
==== Step 2: Update DNS from old to new cluster
@ -96,8 +107,7 @@ Users shouldn't detect any differences.
==== Conclusion
With this scenario, in theory we shouldn't have any downtime as HTTP/HTTPS requests will have almost (depending on the service) the same respond whatever we reach the old or the new cluster.
With this scenario, in theory we shouldn't have any downtime as HTTP/HTTPS requests will almost have (depending on the service) the same response whatever we reach the old or the new cluster.
== Motivation