As you can see, there are a lot of configuration options for our env:
EBS is using regular EC2 instances, CloudFormation templates, CloudWatch metrics & alarms and it means that we can do even more customization.
It’s OK to configure some options manually in GUI, but we’ll use configurations files because we need to configure some extra options and because it’s easier to make a mistake while manual configuration.
To meet our requirements we should use a bunch of configuration files:
1. CLI options – they’re pretty poor for our needs,
I’ll use a few: –region,–platform, –cname, –cfg, –label, –message, –timeout
2. Configuration files placed in .ebextensions folder – they are powerful, but you have to perform the whole app deploy to apply them.
Changes will be implemented during eb create in setupEbEnv function.
I’ll use ’em to install stuff on instances and setup CloudWatch.
To watch memory & disk I need to install some stuff directly on instances using instances.config in ebextensions:
I’ll create CloudWatch alarms for this cases:
Unhealthy hosts in ELB > 0
Healthy hosts < 1
ELB latency ELB > 5s
CPU load in ASG > 60%
RAM available in ASG > 75%
Please note that CPU & RAM will be measured for all hosts in Auto Scaling Group.
That’s because we use scaling and don’t care about every particular instance.
And of course triggers will be different for dev and stg / prod.
To manage it I’ll use cloudwatch.config in ebextensions:
3. Saved configurations. I like using it because I can download a current configuration, change it and apply changes fast and secure.
I’ll use ’em for EBS configuration setup. I’ll download file with default configuration, replace this file with mine and then upload updated file and initiate configuration change.
This changes will be implemented during eb config in createEbEnv function:
Here’s configuration example for you:
4. Also I’ll use config.yml files placed in …/eb/$env/.elasticbeanstalk/ folder to skip eb init stage and set correct default environments.
To make things simple I create ’em in a separate initEbEnv function:
So here’s a final structure of configuration files:
You can check configuration files content and notice that it’s very similar to common configuration management software configs, like chef, ansible, etc.
I won’t describe every single configuration file syntax because it might be changed by AWS, so please see AWS docks for details.