5

I'm deploying a Magento 2 site to AWS, the site will have a load balancer in front which serves via multiple instances (frontends). I've enabled redis for cache and session storage. The media folder is a shared NFS directory across the instances.

Should I also make the 'var' directory a shared NFS folder? I'm unsure about when and why Magento writes to the var folder during operation and what problems this could cause if a user is moved from one server to another during their time on the site.

One annoyance of not using NFS for the 'var' directory would be trying to check logs and reports of any problems that Magento writes to 'var'.

Improve this question
1
  • Another important directory to share is the pub/static/_cache directory if you have JS file merging turned on (which is important for performance). This directory is populated on the fly from requests (not from static-content:deploy), and if the page load runs on a different node than the merged JS file is requested from, the JS file load will fail. See github.com/magento/magento2/issues/13225
    – Scott Buchanan
    Sep 17, 2018 at 18:44

3 Answers 3

Reset to default
2

Sharing the var directory via NFS would be advisable. You already outlined the benefit of having shared log files. Another is sharing generated/compiled code. Without sharing the var directory you would need to run compilation on each ec2 instance during your code deployments.

Improve this answer
4
  • With the current setup I have a separate smaller Instance just for accessing the admin. So the deploy process I have is creating a new deployment on the admin instance, running compilation and static-deploy on it first then putting all the web frontends into maintanance mode and rsycning the files over. So it means I never run compile or setup-content on the frontend instances. This was to try and mitigate downtime. So with that in mind do you think it's only the logs that I'm missing the benefit of?
    – codekipple
    Jul 5, 2017 at 22:18
  • The downside of sharing the var directory through NFS would mean the admin instance plus the frontend instances would all share var which would mean I could no longer mitigate downtime during deploy by running the compile and setup-content on the admin instance first before putting the web frontends into maintenance.
    – codekipple
    Jul 5, 2017 at 22:27
  • 1
    You could just NFS 'var/log' and rsync the other directories. I've used Capistrano to do this as well. The compilation occurs in the release directory and the symlink to current is updated at the end of the deployment process.
    – Pmclain
    Jul 5, 2017 at 22:38
  • Yeah I might go with that, thanks. I'm currently using ansistrano for deployment.
    – codekipple
    Jul 5, 2017 at 22:48
0

I'm looking to set up a similar environment with two web node servers, a database server, and a Redis server for session and page caching. (Locally hosted is the only difference).

What was your final solution? Also, how do you perform upgrades of extensions etc. when you have two web nodes? In my experience running the following commands gets very messy if you try to run them on two separate nodes. Are you able prevent downtime when upgrading extensions? Seems like it's not possible because as soon as you run the upgrade on one node, your other web node that uses the shared database doesn't have the code for the new or updated versions of the extensions.

Commands

bin/magento setup:upgrade

bin/magento setup:di:compile

bin/magento setup:static-content:deploy

I'm thinking more and more about seeing how well something like lsyncd(rsync) works for keeping the second node in line with the first. That would provide for redundancy and better management of load but it would still require downtime for upgrades etc.

Any thoughts or suggestions would be appreciated.

Improve this answer
1
0

This is the current setup we have settled on.

Shared directories

We are only using NFS for the media directory. To deal with the logs we have used Logstash to send all the logs to our kibana server.

Deployment

In answer to DribbleCastle's question.

We have some ansible that runs locally and does the following:-

  • Creates a deploy package folder localy using a timestamp
  • Git clones the repo into it
  • Downloads the latest database of the site from s3
  • Applies the database to the local deploy package by editing the app/etc/env.php file
  • Runs all the magento commands on the local deploy package (setup:upgrade, setup:di:compile, setup:static-content:deploy)
  • Compile assets (css, js)
  • Then changes app/etc/env.php back to the live database creds
  • Creates a tarball of the deploy package e.g 20180328092632.tar.gz
  • Uses ansitrano deploy to rsync up the deploy package to all EC2 instances to a new release folder
  • unzip the tarball
  • put the live site into maintenance mode
  • Run setup:upgrade on the new release folder which now changes the live database
  • ansitrano deploy then enables the release by symlinkning it to the correct place
  • disable maintanence mode

It's a bit of a lengthy process (about 7 minutes), but it does minimise the down time of the site by only putting the site into maintence mode at the very end so we can run setup:upgrade on the live database.

AMI management

We have also added a new part of the deployment which creates a new update to date EC2 ami via packer so when the EC2's scale up and down they always have the latest code, but that's a whole another subject.

Improve this answer

Your Answer

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

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