<p>I have a setup with a webserver (NGINX) and a react-based frontend that uses webpack to build the final static sources.</p>

<p>The webserver has its own kubernetes <code>deployment</code> + <code>service</code>.</p>

<p>The frontend needs to be build before the webserver can serve the static html/js/css files - but after that, the <code>pod</code>/<code>container</code> can stop.</p>

<p>My idea was to share a <code>volume</code> between the webserver and the frontend <code>pod</code>. The frontend will write the generated files to the <code>volume</code> and the webserver can serve them from there. Whenever there is an update to the frontend sourcecode, the files need to be regenerated.</p>

<p>What is the best way to accomplish that using kubernetes tools?
Right now, I'm using a <code>init-container</code> to build - but this leads to a restart of the webserver <code>pod</code> as well, which wouldn't be neccessary.</p>

<p>Is this the best/only solution to this problem or should I use kubernetes' <code>jobs</code> for this kind of tasks?</p>

<p><strong>Jobs</strong>, <strong>Init</strong> containers, or alternatively a <strong>gitRepo</strong> type of <strong>Volume</strong> would work for you.</p>

<p><a href="http://kubernetes.io/docs/user-guide/volumes/#gitrepo" rel="nofollow noreferrer">http://kubernetes.io/docs/user-guide/volumes/#gitrepo</a></p>

<p>It is not clear in your question why you want to update the static content without simply re-deploying / updating the <strong>Pod</strong>. </p>

<p>Since somewhere, somehow, you have to build the webserver Docker image, it seems best to build the static content into the image: no moving parts once deployed, no need for volumes or storage. Overall it is simpler.</p>

<p>If you use any kind of automation tool for Docker builds, it's easy.
I personally use Jenkins to build Docker images based on a hook from git repo, and the image is simply rebuilt and deployed whenever the code changes.</p>

<p>Running a <strong>Job</strong> or <strong>Init</strong> container doesn't gain you much: sure the web server keeps running, but it's as easy to have a <strong>Deployment</strong> with rolling updates which will deploy the new <strong>Pod</strong> before the old one is torn down and you server will always be up too.</p>

<p>Keep it simple...</p>
