When we refer to an application environment we’re grouping together our hardware, software, files and processes.
To make these environments durable & highly available, we need to find a way to ensure that our application can failover automatically & continue to run and that all our configuration files are backed up for additional resilience.
In a traditional LAMP stack application, were talking about: Linux; Apache; MySQL; PHP; Apache config files; firewall configuration, PHP config; MySQL tables & data; MySQL config files; static HTML, CSS and JS resources; PHP scripts; Cron Jobs and domain name configuration to name a few.
What can we do to ensure that this environment is as resilient as possible?
Well, let’s look at it, assuming we’re utilizing AWS:
Utilizing autoscaling groups coupled with healthchecks & an elastic load balancer provides us with a ‘self-healing’ environment – whereby the ELB stops serving traffic to unhealthy instances and the autoscaling group replaces those unhealthy instances with healthy ones.
The core server configuration and the applications installed on it can be defined in the launch configuration of your autoscaling group. You’ll be able to bootstrap all instances launched into the group via the use of bash scripts. These scripts, can download your application files from a GIT repository or S3 and can install the core applications that you need (Apache, PHP, MySQL, etc…).
Our MySQL database can be backed up in a different availability zone through a Multi-AZ deployment of RDS, which automatically promotes the secondary database to primary in the event of a failure.
and that’s it?
Yes, that’s it. We have our server and application config backed up on a GIT repository. When a new instance is launched into an autoscaling group, it automatically downloads those config files and installs the required packages onto the server (e.g. Apache) and attaches to the RDS endpoint which will automatically failover to the standby instance in the event of a failure.