Configuration Options
- Allow to customize resources managed by EB
- Specified (precedence)
- directly applied to the environment (Create/Update)
- saved configurations
- configuration files (.ebextensions)
- default values
Directly Applied
- applied to the environment during Create and Update API calls
- any client (API, CLI, AWS Console)
- can override "recommended values"
- may differ from default values
- allow AWS to apply best practices in backward compatible manner
- examples
- aws:elb:loadbalancer - CrossZone
- aws:elb:policies - ConnectionDrainingEnabled
- Example
- eb create my-env --instance_type m2.medium
Saved Configuration
- Template that is managed by EB
- Can be created from running environment or JSON file (AWS Console)
- like creating machine image (snapshot)
- Contains Solution Stack (do not specify again)
- Use API/CLI/Console to manage them
- Can be stored in the Application source bundle
- .elasticbeanstalk/saved_configs/some_config.cfg.yml
- S3
- sections
- metadata
- solutionstack
- optionsSettings
- environmentTier
Configuration files (.ebextension)
- Part of Application source boundle
- easy to make changes
- .ebextension folder in the root of the application
- YAML/JSON formatted .config files in the folder
- e.g. healthcheckurl.config
- sections
- option_settings
- modify EB configuration options
- aws:elasticbeanstalk:*
- set environmental variables
- modify EB configuration options
- resources
- add additional resources
- all CloudFormation types are supported
- Example
- SQS queue with CW Alarm on the queue depth
- packages
- Linux: rpm, yum, rubygems, python (pip, easy_install)
- Windows: msi
- sources
- Download file from http location and unpack to target directory
- files
- create files
- content passed inline or downloaded from http location
- users
- linux only
- groups
- linux only
- commands
- execute arbitrary commands
- run before web server setup
- container_commands
- run
- after web server setup
- application version extracted
- before application version has been deployed
- from staging directory
- Can be run on "leader_node" only
- Single instance in the AutoScaling group
- run
- services
- control services running on the instance
- option_settings
- use cases
- customize environment resources
- add SQS queue and ALARM on queue depth
- ElastiCache cluster
- customize environment resources
Environment configuration update
- Rolling update (performed in batches)
- Triggered when serious configuration changes made
- Examples: VPC Settings, Launch Configuration (e.g. Instance Type)
- Type
- Health
- Basic: healthy as soon as all instances in the batch pass ELB healthcheck
- Enhanced
- Web: 12 must pass in 2 minutes
- Worker: 18 in 3 minutes
- Timeout 30 minutes (configurable: 15-60)
- If not reached update is cancelled
- Time
- Pause time between batches
- Proceed without regard for healthcheck
- Health
- Split environment into batches (Maximum batch size)
- Deregister batch from ELB (keep minimum number of instances running)
- Update
- Register with ELB
- Can be triggered by .ebextensions changes
Environment Group
- Collection of environments that work together (e.g. SOA)
- One environment may depend on another (see Environment Links)
- naming "+" allows to create entire groups for different stages
- specify "group name"
- e.g. TEST, PROD
- specify "group name"
Environment Manifest (env.yml)
- places in the root of application source
- same format as saved configurations
- supports environment groups
Environment Links
- Used when you have multiple components (e.g. web, services, database)
- Each components gets its own environment
- You can specify connections between environments
- Defined in environment manifest (env.yml)
No comments:
Post a Comment