How to upgrade docker container after its image changed

Question

Let s say I have pulled the official mysql 5 6 21 image    I have deployed this image by creating several docker containers   These containers have been running for some time until MySQL 5 6 22 is released  The official image of mysql 5 6 gets updated with the new release  but my containers still run 5 6 21   How do I propagate the changes in the image  i e  upgrade MySQL distro  to all my existing containers  What is the proper Docker way of doing this

User · Answer

Update  This is mainly to query the container not to update as building images is the way to be done  I had the same issue so I created docker-run  a very simple command-line tool that runs inside a docker container to update packages in other running containers   It uses docker-py to communicate with running docker containers and update packages or run any arbitrary single command  Examples   docker run --rm -v  var run docker sock  tmp docker sock itech docker-run exec  by default this will run date command in all running containers and return results but you can issue any command e g  docker-run exec  uname -a   To update packages  currently only using apt-get    docker run --rm -v  var run docker sock  tmp docker sock itech docker-run update  You can create and alias and use it as a regular command line e g   alias docker-run  docker run --rm -v  var run docker sock  tmp docker sock itech docker-run

User · Answer

I would like to add that if you want to do this process automatically  download  stop and restart a new container with the same settings as described by  Yaroslav  you can use WatchTower  A program that auto updates your containers when they are changed https   github com v2tec watchtower

User · Answer

Here s what it looks like using docker-compose when building a custom Dockerfile    Build your custom Dockerfile first  appending a next version number to differentiate   Ex  docker build -t imagename version    This will store your new version locally  Run docker-compose down Edit your docker-compose yml file to reflect the new image name you set at step 1  Run docker-compose up -d   It will look locally for the image and use your upgraded one    -EDIT-  My steps above are more verbose than they need to be   I ve optimized my workflow by including the build    parameter to my docker-compose file   The steps looks this now    Verify that my Dockerfile is what I want it to look like  Set the version number of my image name in my docker-compose file  If my image isn t built yet  run docker-compose build Run docker-compose up -d   I didn t realize at the time  but docker-compose is smart enough to simply update my container to the new image with the one command  instead of having to bring it down first

User · Answer

Just for providing a more general  not mysql specific  answer      In short   Synchronize with service image registry  https   docs docker com compose compose-file  image    docker-compose pull    Recreate container if docker-compose file  or image have changed   docker-compose up -d    Background   Container image management is one of the reason for using docker-compose   see https   docs docker com compose reference up       If there are existing containers for a service  and the service   s configuration or image was changed after the container   s creation  docker-compose up picks up the changes by stopping and recreating the containers  preserving mounted volumes   To prevent Compose from picking up changes  use the --no-recreate flag    Data management aspect being also covered by docker-compose through mounted external  volumes   See https   docs docker com compose compose-file  volumes  or data container   This leaves potential backward compatibility and data migration  issues untouched  but these are  applicative  issues  not Docker specific  which have to be checked against release notes and tests

User · Answer

Consider for this answers    The database name is app schema  The container name is app db The root password is root123    How to update MySQL when storing application data inside the container  This is considered a bad practice  because if you lose the container  you will lose the data  Although it is a bad practice  here is a possible way to do it   1  Do a database dump as SQL   docker exec app db sh -c  exec mysqldump app schema -uroot -proot123   gt  database dump sql   2  Update the image   docker pull mysql 5 6   3  Update the container   docker rm -f app db docker run --name app db --restart unless-stopped   -e MYSQL ROOT PASSWORD root123   -d mysql 5 6   4  Restore the database dump   docker exec app db sh -c  exec mysql -uroot -proot123   lt  database dump sql   How to update MySQL container using an external volume  Using an external volume is a better way of managing data  and it makes easier to update MySQL  Loosing the container will not lose any data  You can use docker-compose to facilitate managing multi-container Docker applications in a single host   1  Create the docker-compose yml file in order to manage your applications   version   2  services    app db      image  mysql 5 6     restart  unless-stopped     volumes from  app db data   app db data      volumes   my data dir  var lib mysql   2  Update MySQL  from the same folder as the docker-compose yml file    docker-compose pull docker-compose up -d   Note  the last command above will update the MySQL image  recreate and start the container with the new image

User · Answer

After evaluating the answers and studying the topic I d like to summarize   The Docker way to upgrade containers seems to be the following   Application containers should not store application data  This way you can replace app container with its newer version at any time by executing something like this   docker pull mysql docker stop my-mysql-container docker rm my-mysql-container docker run --name my-mysql-container --restart always     -e MYSQL ROOT PASSWORD mypwd -v  my data dir  var lib mysql -d mysql   You can store data either on host  in directory mounted as volume  or in special data-only container s   Read more about it    About volumes  Docker docs  Tiny Docker Pieces  Loosely Joined  by Tom Offermann  How to deal with persistent storage  e g  databases  in Docker  Stack Overflow question    Upgrading applications  eg  with yum apt-get upgrade  within containers is considered to be an anti-pattern  Application containers are supposed to be immutable  which shall guarantee reproducible behavior  Some official application images  mysql 5 6 in particular  are not even designed to self-update  apt-get upgrade won t work    I d like to thank everybody who gave their answers  so we could see all different approaches

User · Answer

Make sure you are using volumes for all the persistent data  configuration  logs  or application data  which you store on the containers related to the state of the processes inside that container  Update your Dockerfile and rebuild the image with the changes you wanted  and restart the containers with your volumes mounted at their appropriate place

User · Answer

Similar answer to above  docker images   awk   print  1     grep -v  none    grep -iv  repo    xargs -n1 docker pull

User · Answer

This is something I ve also been struggling with for my own images   I have a server environment from which I create a Docker image   When I update the server  I d like all users who are running containers based on my Docker image to be able to upgrade to the latest server   Ideally  I d prefer to generate a new version of the Docker image and have all containers based on a previous version of that image automagically update to the new image  in place    But this mechanism doesn t seem to exist   So the next best design I ve been able to come up with so far is to provide a way to have the container update itself--similar to how a desktop application checks for updates and then upgrades itself   In my case  this will probably mean crafting a script that involves Git pulls from a well-known tag   The image container doesn t actually change  but the  internals  of that container change   You could imagine doing the same with apt-get  yum  or whatever is appropriate for you environment   Along with this  I d update the myserver latest image in the registry so any new containers would be based on the latest image   I d be interested in hearing whether there is any prior art that addresses this scenario

User · Answer

I don t like mounting volumes as a link to a host directory  so I came up with a pattern for upgrading docker containers with entirely docker managed containers   Creating a new docker container with --volumes-from  lt container gt  will give the new container with the updated images shared ownership of docker managed volumes   docker pull mysql docker create --volumes-from my mysql container       --name my mysql container tmp mysql   By not immediately removing the original my mysql container yet  you have the ability to revert back to the known working container if the upgraded container doesn t have the right data  or fails a sanity test   At this point  I ll usually run whatever backup scripts I have for the container to give myself a safety net in case something goes wrong  docker stop my mysql container docker start my mysql container tmp   Now you have the opportunity to make sure the data you expect to be in the new container is there and run a sanity check   docker rm my mysql container docker rename my mysql container tmp my mysql container   The docker volumes will stick around so long as any container is using them  so you can delete the original container safely    Once the original container is removed  the new container can assume the namesake of the original to make everything as pretty as it was to begin   There are two major advantages to using this pattern for upgrading docker containers   Firstly  it eliminates the need to mount volumes to host directories by allowing volumes to be directly transferred to an upgraded containers   Secondly  you are never in a position where there isn t a working docker container  so if the upgrade fails  you can easily revert to how it was working before by spinning up the original docker container again

User · Answer

You need to either rebuild all the images and restart all the containers  or somehow yum update the software and restart the database   There is no upgrade path but that you design yourself

User · Answer

If you do not want to use Docker Compose  I can recommend portainer  It has a recreate function that lets you recreate a container while pulling the latest image

User · Answer

Taking from http   blog stefanxo com 2014 08 update-all-docker-images-at-once   You can update all your existing images using the following command pipeline   docker images   awk    REPOSITORY   lt none  gt    next   print  1     xargs -n 1 docker pull

[docker] How to upgrade docker container after its image changed

Examples related to docker