1

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.

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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
    Commented Aug 27, 2019 at 11:10
  • 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
    Commented Aug 29, 2019 at 10:50
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 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.