If you google ‘How to Dockerize Magento’ you will see a number of YouTube results, some Stack Overflow posts, and a number of pages that are fairly dated or fail to consider the critical working pieces of Magento’s underlying architecture.
Whether we are talking about Magento 1 or Magento 2, there is one common thread that brings all the systems together in a meaningful way - and that is Magento’s underlying complexity. There are many moving parts that must work in a certain way, or be manipulated or expressed in a certain manner for anything to work. An example of this is the nasty error page that you are presented with when, say, the permissions on a certain session or log file change (ie. by way of an errant cron job). This one file being brushed against, however seemingly inconsequential the file may be, Magento decides to render any pages. At all. On a production system, this is nerve-racking. On a development system, it is less of a problem, but there is always that idea in the back of your mind that whatever caused that problem could happen again in production. Your developers saying ‘Well, it worked on Dev!’ Is of little reassurance to you, and putting the onus on your systems/operations team doesn’t instill confidence in the code that is being pushed into production.
To properly appreciate the complexity of Magento through the lens of DevOps - we have to look at it like a rocket. Some of the first rockets were made in garages by hobbyists. The first version of Magento was brought up quickly in what is rumored to be a flat out multi week coding smash. The last thing on their mind was how this platform would be deployed as part of a bonafide pipeline - in much the same way that hobbyist rocket enthusiasts develop their vehicle that they will hurl into the upper atmosphere for fun. Rockets at the production level are dizzyingly complex, and require teams of people following specific processes in order to send people into space without killing anyone. Magento is build on a complicated framework that has a lot of moving parts, much like said rocket. You wouldn’t send people to space on a hobbyist rocket, and you certainly wouldn’t make modifications to that rocket while the vehicle is on the launch pad. You would only trust your production workloads to a vehicle that was developed and maintained in a process driven manner.
So, how do we Dockerize magento? There are two ways that is can be done, and I will break down the various considerations of each approach.
Full containerization of your magento code is the optimal route for a variety of reasons. Your code is baked into a docker image. It can be scaled to N size, and you are running the same version controlled image across your infrastructure. Your database can be handled in a container, or you can use a DBMS like Amazon’s RDS.
Pros of Full Magento Containerization
If there is an issue with corrupted files, or something is not working properly, you can respawn the containers back to a known working state. This makes rollbacks much easier as well, in the event that some errant code gets pushed.
Cons of Full Magento Containerization
This is the more difficult approach for existing applications. The reason for this is because you have to plan out how you are going to structure where your various files and assets will be stored (such as product images and the like). The nature of your store will also have an impact on the viability of this approach. If customers are going to be uploading images for customized products, you need to have a plan for where that data is going to go, because as soon as that container is restarted, that data is gone. Having a plan for handling this data is not always straightforward and can slow down some projects, or enhancements to an existing codebase. Another con to this approach is the handling of your cron jobs and other time-based executions or functions. It’s not standard practice to put cron in a docker image that also has your code, so you need a cron specific image that also has php installed so it can run the cron jobs. You also have to wrap your code into this image as well, so you will be maintaining two docker images for your production code. This can be done, and there are a lot of shops that are doing this, but it’s important to have a plan for this when looking to pursue full containerization of Magento.
Partial Containerization of Magento
The partial containerization of Magento is widely used for production workloads. Magento was not designed to be ‘Cloud Native’. This method is ideal for existing Magento codebases that have lots of customizations.
Pros of Partial Magento Containerization
As stipulated previously, this approach is great for existing sites that are making the switch to containerization. In it’s simplest form, you just need an image for php-fpm, nginx and redis. You have flexibility in how the database is handled like the full containerization option (RDS or your choice of managed database engine). Once you have your images that handle your app infrastructure pieces, you simply point them at an NFS share like Amazon’s EFS, or something like a GlusterFS setup, and you have access to your site files like you would if this was being hosted on a dedicated server. The various infrastructure pieces can scale as load increases. Your handling of cron is slightly simpler because you don’t have to bake your code into your cron image, thus relieving your deployment pipeline sprawl.
Cons of Partial Magento Containerization
Getting the site files and changed code into the NFS server requires a container to run that will act as a window to the NFS share where you can dump the files. The handling of build versions needs to be handled a certain way as well. Since we are not tagging images with versions, we need to have a folder structure in the NFS share with the build version, then the containers need to be respawned with instructions on where to look for the files. To do this in a totally automated manner requires some special setup and testing to make sure everything goes correctly.
Should I Containerize Magento?
Containerization, when set up correctly for Magento, will make hosting and maintaining it much simpler. Getting there can be a struggle, but it is worth it in the long run - as most cloud native platforms are now being packaged and deployed by way of container images.