Answers: <p>The image acts as a foundation for each container that you start from it.</p>
  <p>You might do the update in your 'fashion' way, but containers are ephemeral - let's say it got restarted, you updates are lost and you are back to the previous version.</p>
  <p>If you want to handle this process by yourself, how would you track your versions ? Essentially you would have a root docker image and after that it would be so hard to know which version is currently running ? Could you also safely roll-back version to version ? How about if somebody hijacks you container, due to some Unix Socket permissions with the Docker daemon ...</p>
  <p>What I am trying to say, do not rediscover the wheel :)</p>
  <p>Take advantage of modern technologies like Kubernetes, deploy each image for a new version there, you have a roll - out deployment, readiness probes and so on ... You would be safe that your software is always working, track the versions and have H/A.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-11-18T11:07:48.813Z
Answers: 2020-11-18T11:07:48.813Z
Answers: Recoba20
Body: <p>I am running production code within an active docker container.
  I would like to use the Gitlab CI tool to auto deploy changes to the production environment WITHIN the docker container.</p>
  <p>I am having trouble finding a clean way to do this.</p>
  <p>One idea I have is to simply log into the docker container as part of the gitlab-ci automation script</p>
  <ul>
  <li>docker exec -it 82jf72h8dj2 bash</li>
  <li>then git pull from the appropriate directory</li>
  </ul>
  <p>In theory, this will work... but what happens when the docker ID changes? Is there any way to detect this as part of the script? I would hate to have to keep updating the CICD variable since the docker ID seems to change fairly often...</p>
  
Comments: CC BY-SA 4.0
Comments: 2020-11-05T11:31:09.787Z
Comments: in theory this could work, but its a bad solution. you should build a new image from your codebase and then update it on your production environment and restart it.
Comments: Milan Markovic
Tags: <docker><gitlab><cicd><gitlab-ci-runner>
Title: Gitlab CI - Deploy to an active docker container
UserDisplayName: Martin
ThreadText: # Gitlab CI - Deploy to an active docker container
  
  (Asked by: username_0 on 2020-11-04)
  
  I am running production code within an active docker container.
  I would like to use the Gitlab CI tool to auto deploy changes to the production environment WITHIN the docker container.
  
  I am having trouble finding a clean way to do this.
  
  One idea I have is to simply log into the docker container as part of the gitlab-ci automation script
  
  * docker exec -it 82jf72h8dj2 bash
  * then git pull from the appropriate directory
  
  In theory, this will work... but what happens when the docker ID changes? Is there any way to detect this as part of the script? I would hate to have to keep updating the CICD variable since the docker ID seems to change fairly often...
  
  **Tags:** docker, gitlab, cicd, gitlab-ci-runner
  
  > **Comments:**
  > **username_1**: in theory this could work, but its a bad solution. you should build a new image from your codebase and then update it on your production environment and restart it.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2020-11-18. Score: 1
  
  The image acts as a foundation for each container that you start from it.
  
  You might do the update in your 'fashion' way, but containers are ephemeral - let's say it got restarted, you updates are lost and you are back to the previous version.
  
  If you want to handle this process by yourself, how would you track your versions ? Essentially you would have a root docker image and after that it would be so hard to know which version is currently running ? Could you also safely roll-back version to version ? How about if somebody hijacks you container, due to some Unix Socket permissions with the Docker daemon ...
  
  What I am trying to say, do not rediscover the wheel :)
  
  Take advantage of modern technologies like Kubernetes, deploy each image for a new version there, you have a roll - out deployment, readiness probes and so on ... You would be safe that your software is always working, track the versions and have H/A.
  
  
  ---
  
  