9: Developer Theory
What is CI/CD?
Continuous Integration, Continuous Deployment.
- Best practice.
- Makesmall changes and automate everything.
An example workflow
- Shared Code Repository with frequently merging or integrating code updates.
- Automated build of the new code from a trigger.
- Run automated tests to check the code locally before it is commited into the master code repository.
The deployment workflow.
- Merged on successful build.
- Prepared for deployment.
- Merged either by manual decision or fully automated.
- CodeCommit: Source and version control.
- CodeBuild: Automated build tool.
- CodeDeploy: Automated deployment to any instance.
- CodePipeline: Manages the workflow. Integrates with all other tools.
- A central code repository. Like GitHub, GitLab.
- Enables collaboration.
- Version control.
In the demo:
- A new repo was created with a new file.
- A new branch was created.
- The file was updated, and the branch was merged.
- Automated deployment service.
- Works with EC2 instances, on-prem and lambdas.
- In-Place: The app is stopped on each instance and the new release is installed (also known as a rolling update).
- Blue/Green: New instances are provisioned and the new release is installed on the new instances. Blue represents the active deployment, green is the new release.
Example deployment (assuming 3 instances behind ELB):
- App is stopped on the first instance.
- Instance will be out of service during the deployment so capacity is reduced.
- You should configure your ELB to stop sending requests to the instance.
- New instance is provisioned and added known as a "revision". This happens for each instance as one comes back online.
Rolling back has no quick fix - you will need to re-deploy the previous version which can be time consuming.
- With the blue/green, you stand up all the instances and re-point the ELB to all new instances at once.
- Blue is deregistered.
- Rollback is quick - just re-point the ELB to the blue group.
- Blue/green is more expensive. It is safer though.
Configuring CodeDeploy with the AppSpec file
- Config file defins the params to be used during a CodeDeploy deployment.
- For EC2 and on-prem systems, YAML only.
- Lambda subpports YAML and JSON. File structure depends on whether you are deploying to Lambda or EC2.
The file stucture:
version - The version of the config - currently only allowed
os - OS version you are using e.g. linux, windows.
files - location of any app files that need to be copied and where they should be copied to.
hooks - lifecycle event hooks. Scripts that need to runs at specific times in a specific order. Examples are unzipping files, running tests, dealing with load balancer registrations.
The typical folder setup:
appspec.yaml MUST be at the root.
The three phases of the deployment:
- De-register instances from a Load Balancer.
- Nuts and bolts of app deployment.
- De-register instances with the Load Balancer.
The run order for an in-place deployment:
BeforeBlockTraffic - tasks you want to run on instances before they are de-registered from a Load Balancer.
BlockTraffic - de-register instances from a Load Balancer.
AfterBlockTraffic - tasks you want to run on instances after they are de-registered from a Load Balancer.
Other lifecycle hooks for in-place:
ApplicationStop - gracefully stop the app.
DownloadBundle - CodeDeploy agent copies the app revision files to a temporary location.
BeforeInstall - Pre-install scripts e.g. backing up current version, decrypting files.
Install - Copy app revision files to final location.
AfterInstall - Post-install scripts e.g. config, file permissions.
ApplicationStart - Start any services that were stopped during
ValidateService - run tests to vaildate the service.
- Run order - lifecycle event hook order.
- In-place deployment: broadly those three phases noted above.
- Understand the logical flow.
Fully managed CI/CD service.
It orcehstrates build, test and deploy.
Code pipline integrates with those AWS services we mentioned before as well as third party applications.
- CodePipeline: Workflow is defined.
- CodeCommit: Starts on new code appearance.
- CodeBuild: builds and tests.
- CodeDeploy: deploys.
Elastic Container Service
Why for microservices:
- Highly scalable
- Fault tolerant
- Easy to maintain
Fargate or EC2?
- Cluster of VMs.
- Fargate for Serverless. No need to worry about underlying instances.
- EC2 for more control.
First thing you'll want to do, it create an Elastic Container Registry.
Cool services that use ECS:
- Amazon Sagemaker.
- Amazon Lex.
- amazon.com is running on ECS.
Docker and Elastic Beanstalk
Elastic Beanstalk also supports the deployment of Docker Containers.
EB handles the capacity provisioning, load balancing, sclaing and app health monitoring.
- Using EB, you can deploy your Docker container to a single EC2 instance.
- You can also deploy multiple Docker instances to an EC2 cluster.
- To deploy a Docker app, just upload code bundle to Elastic Beanstalk.
- Written in YAML or JSON template.
- CF reads the template and makes the API calls on your behalf.
- After creating the template, you upload it to CF using S3.
- The resulting set of resources that CF builds from your template is called a "Stack".
- The resources section is mandatory.
- The transform section is for referencing additional code (stored in S3) as well as allowing for code-reuse. Eg. Lambda coe or template snippests/resusable pieces of CloudFormation code.
- Mappings allow custom mappings like
Region : AMI.
- Conditions: provision resources based on environment.
- Parameters: Input custom values.
Serverless Application Model (SAM)
- CloudFromation for Serverless.
- Simplified syntax.
- Uses the SAM CLI to package and deploy code.
$ sam package
$ sam deploy
CloudFormation Nested Stacks
"Stacks that create other stacks". Enables re-use of CF code for common use cases. Basically a template within a template.
It falls under
Type: AWS::CloudFormation::Stack with a
TemplateURL parameter which points to S3.