<p>I am learning how Kubernetes works, with the objective of migrating a &quot;Virtual Machine&quot; environment to a &quot;Kubernetes Container&quot; environment.<br />
The final objective is to be able to absorb peak loads (auto scaling).</p>
<p><strong>Currently,</strong> we have a PHP web application (Symfony) running on multiple Debian VMs, which we call &quot;Workers&quot;.<br />
Each VM is a &quot;worker&quot;, it owns the PHP source code, NGINX and PHP-FPM.</p>
<p><em>PHP sessions are not a problem because they are stored in a cluster-redis.<br />
The databases is stored in a cloud-provider.<br />
The file storage is also in cloud-provider, S3 protocol.</em></p>
<p><strong>With this environment</strong> when we push code in production, <strong>we do a git pull via Ansible</strong> on all the &quot;workers&quot;, and it works fine, nice !</p>
<p><strong>So now with Kubernetes ;</strong>
I am a little confused to transcribe this operations in Kubernetes, more particularly the &quot;source code&quot; part.<br />
I have already done this;</p>
<ul>
<li>Create PHP-FPM / NGINX services</li>
<li>Create the PHP-FPM / NGINX deployments, with the nginx vhost stored in a configmap.</li>
</ul>
<p>All this is working fine, my PHP / NGINX environment is up and running fine.</p>
<p>Now my biggest problem, how do I get the source code to run in my pods?</p>
<p>I thought about using an init container, which would make a &quot;git clone&quot; of my code when starting the pods, in a /code volume.<br />
However, once the pods are up and running, how can I git pull them, kill them and reinitialize? Poor solution ?</p>
<p>The other idea I have is to do a Kubernetes Jobs, which I run every time it is necessary to pull new code?</p>
<p>Can you advise me ?<br />
<strong>What is the best solution for &quot;git pull&quot; code in running containers?</strong> As I did before with my VMs, via a git pull from Ansible on all VMs.</p>

Dreamsanon
<p>Your images should be self-contained, and pushed to a registry.  In pure Docker land, you should be able to run them without mounting the source code into them (no <code>docker run -v</code> or Compose <code>volumes:</code> options).  This means you need to <code>COPY</code> the source code into the image in a Dockerfile.</p>
<p>When you build an image, it's also very good practice to give every build a unique tag.  The source control commit ID is a good choice; a date stamp will also be pretty unique and is easier for an operator to understand.</p>
<pre class="lang-sh prettyprint-override"><code>docker build -t my/application:20210403 .
# run this _without_ separately injecting the application code
docker run -d -p 1234:1234 my/application:20210403
docker push my/application:20210403
</code></pre>
<p>In your Kubernetes Deployment spec there will be a line that references the <code>image:</code>, like</p>
<pre class="lang-yaml prettyprint-override"><code>image: my/application:20210403
</code></pre>
<p>When you have a new build of your application, build and push it as above, and change the tag in the <code>image:</code>.  (There is an imperative <code>kubectl</code> command that can do it; tools like Helm can inject it based on deploy-time parameters; or you can edit the YAML file, commit it to source control, and <code>kubectl apply -f</code> it.)  When the <code>image:</code> changes (and it must actually be a different string from before) Kubernetes will launch new pods with the new images, and then tear down the old pods.</p>
<p>This approach has a couple of advantages over what you describe.  In a multi-node or cloud-hosted environment, you don't need to manually copy code into the cluster; the image pull will do it for you.  If you discover something has gone wrong in a build, it's very easy to set the <code>image:</code> back to yesterday's build and go back.  This also uses only standard Kubernetes features and can literally be half the YAML size of a configuration that tries to separately inject the source code.</p>
