<p>Static assets should not be in the image, but rather on a PersistentVolume or better yet, on an object store such as AWS S3 then let a CDN to use it.</p>

<p>At the end of the day, Magento is a CMS, so the admin users will change the assets and other part of the content. It is not practical to bake assets these in to an container image doe the nature Magento.</p>

CC BY-SA 4.0
2019-08-27T11:10:22.267Z
dude what u mean by static assets !? if u mean Media files .. they are already in s3 - if u mean css js - we need it for zero downtime deployment
Sina Miandashti
CC BY-SA 4.0
2019-08-29T10:50:41.510Z
Assets are files that are directly served by the webserver. CSS, JS, SVGs etc. could be also in S3. If your theme generates e.g. CSS on-the-fly, that should not be in the image anyway, as the key principle is the image should be read-only. For dynamic assets. you can use PersistentVolume (PV) K8s resource type.
aries1980
CC BY-SA 4.0
2019-08-26T10:55:50.297Z
2019-08-26T10:55:50.297Z
aries1980
<p>Based on the description of your problem, it looks like the solution would be to optimize your testcontainer image:</p>

<ol>
<li>Double check your base for the testimage.  Using something like <a href="https://docs.docker.com/samples/library/alpine/" rel="nofollow noreferrer">Alpine</a> for your base image can save a lot of space.</li>
<li>Check what you are baking into your testimage.  Your "pre-built static data" should not be included as part of the image (as others have pointed out).  If you need this data to compile the initial image, you should purge it after to get the size down.</li>
<li>Any tooling installed that is needed for building testimage can be purged from the container before pushing the image.</li>
</ol>

<p>With a 5MB Alpine base image and proper management of your "pre-built static data" you should be well below 1GB.  A base php-fpm image clocks in around 82MB and nginx at 9MB.</p>

CC BY-SA 4.0
2019-08-28T21:12:28.710Z
2019-08-28T21:12:28.710Z
Wesley Rolnick
<p>As a practice I have pods with these 2 containers:</p>

<ol>
<li>php-fpm</li>
<li>nginx</li>
</ol>

<p>The image of my project is called testimage. The solution uses the 'testimage' as initContainer and then copies the all folders and files of the testimage into a shared volume called volume1. Then this volume is mounted into nginx and php-fpm containers with a Kubernetes volume mount.</p>

<p>When the size of testimage goes beyond 1gb (for example a magento2 project with full pre-built static data and compiled code), it takes a long time for copying these files and it seems like a bad practice.</p>

<p><strong>Should I put the project files into the php-fpm container (first container)?</strong> For nginx to use it again, I have to copy paste data into a Kubernetes volume and then mount it to nginx.</p>

<p>The end solution is putting all app code + fpm + nginx  into a single container than this makes a huge image with all of these. There is no per-container resource management and etc available with this solution.</p>

<docker><kubernetes>
initContainer with huge size software like magento2
Sina Miandashti
# initContainer with huge size software like magento2

(Asked by: username_0 on 2019-08-21)

As a practice I have pods with these 2 containers:

1. php-fpm
2. nginx

The image of my project is called testimage. The solution uses the 'testimage' as initContainer and then copies the all folders and files of the testimage into a shared volume called volume1. Then this volume is mounted into nginx and php-fpm containers with a Kubernetes volume mount.

When the size of testimage goes beyond 1gb (for example a magento2 project with full pre-built static data and compiled code), it takes a long time for copying these files and it seems like a bad practice.

**Should I put the project files into the php-fpm container (first container)?** For nginx to use it again, I have to copy paste data into a Kubernetes volume and then mount it to nginx.

The end solution is putting all app code + fpm + nginx into a single container than this makes a huge image with all of these. There is no per-container resource management and etc available with this solution.

**Tags:** docker, kubernetes


---

## 2 answers

### Answer by username_1 on 2019-08-26. Score: 1

Static assets should not be in the image, but rather on a PersistentVolume or better yet, on an object store such as AWS S3 then let a CDN to use it.

At the end of the day, Magento is a CMS, so the admin users will change the assets and other part of the content. It is not practical to bake assets these in to an container image doe the nature Magento.

> **Comments:**
> **username_0**: dude what u mean by static assets !? if u mean Media files .. they are already in s3 - if u mean css js - we need it for zero downtime deployment  
> **username_1**: Assets are files that are directly served by the webserver. CSS, JS, SVGs etc. could be also in S3. If your theme generates e.g. CSS on-the-fly, that should not be in the image anyway, as the key principle is the image should be read-only. For dynamic assets. you can use PersistentVolume (PV) K8s resource type.  

---

### Answer by username_2 on 2019-08-28. Score: 0

Based on the description of your problem, it looks like the solution would be to optimize your testcontainer image:

1. Double check your base for the testimage. Using something like [Alpine](https://docs.docker.com/samples/library/alpine/) for your base image can save a lot of space.
2. Check what you are baking into your testimage. Your "pre-built static data" should not be included as part of the image (as others have pointed out). If you need this data to compile the initial image, you should purge it after to get the size down.
3. Any tooling installed that is needed for building testimage can be purged from the container before pushing the image.

With a 5MB Alpine base image and proper management of your "pre-built static data" you should be well below 1GB. A base php-fpm image clocks in around 82MB and nginx at 9MB.


---

