Drupal's cron job(s) should be run via Drush if you would like to be able to run it in the most efficient, scalable fashion.Drupal's settings.php and other important configuration is challenging to configure via environment variables.Drupal installation and features like CSS and JS aggregation needs to be able to persist data into certain directories inside the Drupal codebase.The Drupal files directory must be persistent and shared among all web containers.
There are five major challenges to turning a Drupal application or website into a more 'stateless' 12-factor app:
It is identical in almost every way between production and non-production environments.Ī 12 Factor App can require database credentials, shared filesystems, etc.-but ideally it can work in ways that minimizes the pain when dealing with such things.It can scale from one to many instances with minimal (ideally zero) intervention.It is not tied too tightly to one type of operating system or a complex tangle of language and environment configurations.
#Deploy drupal on aws best practices manual
It stores all its configuration in some sort of declarative format, so there aren't manual or non-automatable setup steps.Many applications need things like environment-specific database credentials, a shared filesystem for things like uploaded or generated files shared between multiple instances, and other things which may make deploying in a scalable, flexible way more difficult.īut a 12 Factor App is an application which can do some fancy things which make it easier to deploy and manage: You may wonder, "What is a 12 Factor App?" The link to the website above has all the details, but on a very basic level, a 12-factor app is an application which is easy to deploy into scalable, robust, cloud-based environments. Throw Kubernetes into the mix-where anything and everything is almost forced to operate as a 12-factor app, and you really have to be on your game in the world of containerized-Drupal-in-production! 12 Factor Apps
#Deploy drupal on aws best practices code
If you have to have your Drupal code in one place, and a docker container running elsewhere, you have to manage both separately, and rolling out updates can be challenging (and requires most of the same tools you'd use in old-style Drupal-on-a-normal-server approaches, so there's no streamlining this way). But local development environments, where the Drupal codebase is basically mounted as a volume into a Docker container that runs the code, differ radically from production, where the goal is to 'contain' as much of production into a stateless container image as possible, so you can scale up, deploy, and debug most efficiently. They definitely can and do, in many cases, as we see with local development environments built around Docker, like Docksal, Ddev, Lando, and even Drupal VM. You might think that Drupal and Docker work together nicely. It was slow at first, but it's becoming much more rapid. There have always been a few growing pains-there will for some time, as there are so few places actually using Docker or containers in a production environment (at least in a 'cloud native' way, without tons of volume mounts), though this is changing. Since 2014, I've been working on various projects which containerized Drupal in a production environment. There are Kubernetes Drupal Operators which can manage Drupal instances in Kubernetes I maintain the geerlingguy/drupal-operator but there are a couple others out there in development.
0 kommentar(er)
