Gitlab CI/CD pipeline with aws integration for magento 2 deployment
Shell
Gitlab CI/CD pipeline with aws integration for magento 2 deployment
Feature highlights
Created with simplicity and ease of use in mind, inspired by magento cloud pipeline
Emphasis on zero downtime during deployment, must have at least 2 nodes for this
Separate root to build application changes without affecting mage root
State checking flow for optimized build of pipeline/server/application related changes
Simple deploy summary for pipeline/server/application section in tabular format during each deployment
Support to sync nginx, php, logrotate and magento env changes directly from repository to golden server
Composer auto update flow when last update run exceeds 30 days during deployment even without any changes
Patches install complete flow to auto apply, revert and delete relevant changes
Aws cli integration to create image, update launch configuration and start/wait for instance refresh
Important configuration information
Part of static pub/static on efs causes massively slow static deployment so it should not been kept on efs
Part of static var/view_preprocessed will be on efs due to entire var being efs, so custom configuration will be done later on to remedy massively slow static deployment
Part of static pub/static/_cache should for now be in efs as it generates only on demand and not sharing it breaks layout
static cache bug
Crontab for root and ubuntu user will be auto deleted on auto scaling nodes to avoid conflicting cron runs, this effectively allows golden server to be also used as a dedicated cron server. It is achieved using launch configuration user data.
Logrotate config has *.cfsaved extenstion so regular cron skips it and we can define custom schedule using root user's crontab as required
Cd into $scripts_root and create two .env file for staging and production from sample env file
cp -a .env.dis .env.prod
cp -a .env.dis .env.stag
Edit each of the .env file and add production or staging aws/magento related details
6. Usage of pipeline and extra information
After setting up everything from previous steps, make some changes in previous already existing repository, commit and push changes
Clone the new repository for cloud in seperate isolated folder and pull changes of previous repository in one of the branches preferably staging
Push the changes to relevant branch, the pipeline should trigger, run it's operations and complete if everything was setup up properly
Symbolic linked view_preprocessed in var will be used by static deployment command while modified view_preprocessed in pub/index.php will be used by nginx
Admin configuration Enable Symlinks does not need to be enabled, it's only needed for read operations while write operations can be done safetly with this disabled
To force application build even without changes use the web ui run pipeline and set FORCE_APPLICATION_BUILD to 1 or set this variable to 1 during git push