- Developers push the code to a code repository often
- GitHub, BitBucket, CodeCommit (in AWS) etc...
- A testing / build server checks the code as soon as it's pushed
- Jenkins CI, TeamCity, CodeBuild (in AWS), etc...
- The developer gets feedback about the tests and checks that have passed / failed
- Helps
- Find bugs early, fix bugs
- Deliver faster as the code is tested
- Deploy often
- Happier developers, as they're unblocked
- Ensure that the software can be released reliably whenever needed.
- Ensures deployments happen often and are quick
- Automated deployment -> Shift away from e.g. "one release every 3 months" to 5 releases a day.
- CodeDeploy in AWS, Jenkins CD, Spinnaker, etc...
-
AWS CodePipeline allows you to automate all steps of the deployment:
Step Name AWS Others 1 Code CodeCommit GitHub, GitLab etc.. 2 Build & test CodeBuild Jenkins CI, TeamCity etc.. 3 Deploy ElasticBeanstalk, CodeDeploy Octopus 4 Provision ElasticBeanstalk, CloudFormation Terraform -
CodeDeploy
- Two deployment options:
- In-place deployment: EC2/On-Premises apps are stopped & updated & validated.
- Blue/green deployment: Using slots (deploy A -> switch to A -> stop B) with minimal downtime and rollback capabilities.
- EC2/On-Premises: Must have one ore more EC2 with tags or ASG
- Lambda
- Canary: Traffic is sifted in two increments, 90% to first version, 10% to second before 100% to second.
- Linear: Traffic is shifted in equal increments with number of minutes e.g. 10% per minute.
- All-at-once: All traffic is shifted at once.
- Amazon ECS: Task set switches
- Two deployment options:
- Code will be deployed and create / update / delete infrastructure
- Can be JSON or YAML.
- Can be part of disaster recovery strategy.
- Declarative way of outlining AWS infrastructure for any resources (most of them are supported)
- CloudFormation provisions in the right order with the exact configuration that you specify.
- 💡 Allows re-use the best practices around your company for configuration parameters.
- Templates
- You can upload in S3 and then reference in CloudFormation
- Update a template
- Can't edit previous ones.
- Have to re-upload a new version of the template to AWS.
- Building Blocks
- Cloud formation template consists of components and helpers:
- Template components
- Resources: your AWS resources declared in the template (❗ mandatory)
- Parameters: the dynamic inputs for your template
- Allows you to parameterize & prompt inputs while deploying.
- Mappings: the static variables for your template
- Outputs: References to what has been created
- Conditionals: List of conditions to perform resource creation
- Metadata
- Template helpers
- References (Logical IDs are used to reference resources within the template)
- Functions
- Template components
- Cloud formation template consists of components and helpers:
- Templates
- JSON or YAML text file that contains instructions for building out AWS environment
- Change sets
- Before making changes to your resources, you can generate a change set, which is a summary of your proposed changes, e.g. resource A will be deleted.
- Stacks
- The entire environment described by the template and created, updated, and deleted as a single unit
- Related resources in a template.
- When you update stack, it updates the resources
- Can rollback on failure after timeout in minutes.
- Termination protected with stack from being accidentally deleted.
- Monitoring
- Fires events such as on resource creation
- Can have monitoring time (CloudFormation monitors resources during X minutes after creation)
- Can set up CloudWatch alarms if something fails.
- Can have IAM role or policy to deny/allow access.
- Can use sample template or create one in Designer.
- Identified by name
- Can have input parameters that'll be filled from portal.
- Reusable output information
- It's output information (key, value, description) can be imported by other stacks by using an unique export/import name.
- Stack Sets lets you create stacks in AWS accounts across regions by using a single AWS CloudFormation template
- Operations
- Deleting a stack -> deletes every artifact created by CloudFormation
- Deploying templates/stacks
- by uploading YAML files directly or referencing to Amazon S3 URL
- Use a sample template
- Create template in Designer
- Helps you to see resources & relations
- Might be good for PowerPoints
- ❗ Redeploying a stack deletes old instances.
- Changing a stack
- Done using Stack change sets
- Warns you about resources that'll be deleted, modified and added.
- Drift: difference between the expected configuration values and actual deployed.
- Allows you to better manage your CloudFormation stacks and ensure consistency in your resource configurations
- Can deploy Elastic Beanstalk that'll then deploy:
- E.g. EC2, ALB, ASG, RDS
- IAM Conditions for CloudFormation
cloudformation:TemplateURL
: Ensure template in TemplateURL is used for e.g. update/delete.cloudformation:ResourceTypes
: Specify which types of resources can be created or updated.cloudformation:StackPolicyURL
- Stack policies prevents stack resources from unintentionally being updated or deleted during stack updates
- You define which actions (t.ex. update) are allowed on which resources in a JSON file.
- Control
- No resources are manually created / configured.
- Code can be version controlled e.g. using git.
- Changes are reviewed through code
- Cost control:
- Each stack has ID: follow-up costs.
- Estimate costs of a stack.
- You can automate deletion of templates at 5 PM and recreation at 8 AM safely.
- More productivity:
- Destroy and re-create an infrastructure on the cloud on the fly.
- Automated generation of diagram for your templates!
- Declarative programming (no need to figure out ordering and orchestration)
- Better separation of concerns:
- Many stacks for many apps, and many layers.
- E.g. VPC stacks, network stacks, app stacks
- AWS managed service for Chef & Puppet
- They work great with EC2 & On Premise VM
- Alternative to AWS SSM (Systems Manager)
- OpsWorks stacks
- Groups applications into layers depending on Chef recipes
- No need to provision chef server
- Uses the embedded Chef solo client that is installed on EC2 instances on your behalf
- Serverless & free & open-source
- Is built-in in AWS AMIs
- Does not require any jump-boxes (bastion hosts)
- Can run Ansible, PowerShell DSC or any script from S3 through Run command.
- Can use AWS Systems Manager Automation
- Leverages documents for tasks that can be automated.
- Help with managing server configuration as code
- Helps in having consistent deployments
- Can automate: user accounts, cron, NTP, packages, services
- They leverage "Recipes" or "Manifests"
- Similar to SSM / Beanstalk / CloudFormation but they're open-source tools that work cross-cloud.
- Serverless applications are e.g. Lambda, DynamoDB, API Gateway...
- To be order to locally run, debug and easily deploy serverless applications you can use:
- AWS Serverless Application Model (AWS SAM)
- Open source tool used to package, test, and deploy serverless applications
- YAML based infrastructure as code.
- serverless.com
- Vendor-neutral (Azure, Google, AWS) serverless framework.
- YAML-based infrastructure as code.
- AWS Serverless Application Model (AWS SAM)