Hello,
I'm writing because I found a workaround in order to deploy minor
updates without causing the restart of the containers. Maybe this idea
could be useful for others..
The workaround is based on adding another business logic in the start
script inside the docker image.
In my Dockerfile, the last line is:
/CMD ["/tmp/final_script.sh"]/
and in this script I perform some operations but above all I start
apache service
Now before starting apache, the script updates a single file to the last
revision
The file contains the svn revision related to prod env (example 21180).
After this update, the script checks if the revision obtained with the
file (21180) is different from the one with which the Docker image was
created (example 21165)
If it's so, the script update the code to the revision 21180
Then it starts apache as usual
This image (with the "extended" final_script.sh) has been deployed on
prod with a rolling update.
From this moment, we're able to deploy minor updates without the need
to create a new image and above all without any problem of breakdown
during future deployments
Our approach is as follows:
- commit the new files (I get revision 21200)
- update (and commit) of the file containing the prod revision (it will
contain 21200)
- custom script to execute /svn up -r//21200 /on every web container
- if a container may be restarted due some problems, at the boot of the
container the final_script would be executed. The image revision will be
different in this case (21165 != 21200) so the script will update the
code to 21200. And the restarted container would have the same code as
all the others
Il 26/04/2018 19:31, Rodrigo Campos ha scritto:
Adding Kubernetes users again :)
On Thursday, April 26, 2018, Rodrigo Campos <rodrig...@gmail.com
<mailto:rodrig...@gmail.com>> wrote:
On Thursday, April 26, 2018, <mderos...@gmail.com
<mailto:mderos...@gmail.com>> wrote:
Il 25/04/2018 01:27, Rodrigo Campos ha scritto:
I don't understand why can that happen if the code is in
the container image. Unless you change it while it is
running, there should be no chance to misalign anything.
What am I missing?
We're working with continuous delivery approach so we would
like to have the chance to execute svn up on prod env without
the obligation to create a new image for every deploy
Really different things, though.
And, as I said in previous emails, you lose several advantages of
immutability of containers.
For example, we are using zendesk/samson (project on GitHub) and
when a merge is done, Travis runs the tests and if they pass, a
new docker image is created and it gets deployed via Samson.
Automatically. And if something fails (like liveness probes or
something) it rollbacks to the previous image.
This is pretty much what containers deploy look like in the common
case: your code is in the container. You just create new
containers images.
If you are managing all of this yourself, then you need to do it
yourself and handle all these problems that other tools solve for you.
--
You received this message because you are subscribed to the Google Groups "Kubernetes
user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
