This will be the subject of a blog at a later date. The task would then be drained and removed from the pool with no problem noticeable to the end user. This would give a seamless switch-over when a task becomes unhealthy - during the period AWS determines that a task is returning errors and has crossed the unhealthy threshold, nginx could still serve pages which would be less than 5 minutes old. My rationale for selecting nginx is I would like to add the feature of nginx serving slightly stale cached pages when the origin is returning 5xx errors. nginxĪ web server is needed, and I've elected for nginx although Apache would also be a good choice. Since that doesn't apply to my own site, and I would like to keep costs down too, my feeling is having Memcached as part of the Fargate task is a better fit. This would be the preferred option if your website is largely serving logged in traffic, and if you are running an eCommerce site with the users' baskets stored in Memcached. Each task in the web service would have an endpoint to the same centralised ElastiCache instance. There is an alternative strategy to this - centralise the caching using for instance the AWS ElastiCache with Memcached product. Memcached will be used for caching the Drupal MySQL cache tables and for page caching for anonymous users. I have elected to run individual Memcached caching in each task running in the Web App service. It will use the Fargate equivalent of the Docker command to exec a particular command and then quit. Since the codebase will already contain Drush binaries in vendor/bin/drush, it will be the same as the previously mentioned image. This will be the Fargate task to run one off Drush commands. Drupal Core + FPM PHP + Codebase + Exec command The web app's codebase - ie all the configuration and custom modules and themes created by the dev team - will be copied into this image. For instance Alpine uses the apk package manager instead of apt-get. This comes at a price - those with Ubuntu experience will have to learn new commands. Note that the Alpine build has been chosen since it's an extremely lightweight version of Linux, based on busybox which has a very small footprint. The intention is to use the official Drupal FPM Docker image using Alpine, and be as up to date as possible with the versioning. The diagram above shows the Docker images requires to achieve our goal. Also have Fargate tasks to run which will run Drush commands, stood up on a per Drush command basis, and terminating after each Drush command completes. The objective is to stand up a Fargate task running as a service which will be the web app, and it will persist and auto scale. This first blog will cover your team's local environment and how its build will ensure your path to Fargate deploy is smooth, with as much reuse of the configuration in production as possible. The blogs in this series will cover important considerations such as the pipelines to deploy your codebase within Docker images, and their storage set up of the Drupal S3FS module along with the CloudFront accelerator and S3 object store auto scaling of the Fargate tasks load testing your app to ensure you are fully optimised and how to run your Drush commands in short living Fargate tasks. Furthermore it offers greater simplicity of operation and setup then its AWS sibling offering ECS over EC2, and again a cost saving. It offers considerable savings over traditional Virtual servers without, if configured correctly, loss of performance. Fargate can now be considered a mature product, and provides a simple serverless containerised platform for hosting web apps. Welcome to a series of blogs on hosting Drupal 9 (or legacy Drupal 8) sites on AWS Fargate.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |