[AWS DA] AWS CICD: CodeCommit, CodePipeline, CodeBuild, CodeDeploy

codecommit: storing code

codepipeline: automating our pipeline from code to elasticbeanstalk

codebuild: building and testing our code

codedeploy: deploying the code to ec2 fleets (not beanstalk) impportant! codedeploy only deploy to ec2, no whereelse

authentication in git:

ssh key

https

mfa

authorization in git:

iam policies for user / role to repositories

encryption:

repo are encrypted at rest using kms automatically

encrypted in transit (ssh or https)

cross account access:

use iam role in your aws account and use aws sts (with assumerole api)

not share ssh

not share aws credentials

you can trigger notification in codecommit using sns, lambda or cloudwatch event rules.

basiclly any notification related to pull request (inlcude comments), goes to cloudwatch event rules. otherwise goes to sns / aws lambda. cloudwath event rules can also goes into sns topic.

sns / lambda:

deletion of branches

push to master

notify external build system

trigger aws lambda function to perform codebase analysis (maybe credentials got committed in the code?)

cloudwatch event rules:

trigger for pull request (created/updated/deleted/commented)

commit comment events

cloudwatch event rules goes into a sns topic

answer: cloudwatch event rules. anything related to pr, goes to cer.

each pipeline stage can create "artifacts"

artifacts are passed stored in amamzon s3 and passed on to next stage

codepipeline state changes happen in aws cloudwatch events, which can in return create sns notifications.

you can create events for failed piplines

you can create events for cancelled stages

pipeline -> all goes to cloudwatch event rules -> sns different from codecommit, only pull request related goes into cloudwatch event rules

if codepipeline fails a stage, you pipeline stops and you can get information in the console

aws cloudtrail can be used to audit aws api calls

if pipeline cannot perform an action, make sure the "iam service role" attached does have enough permission (iam policy)

services which codepipeline can deploy to:

you can new stage easily and each stage can have multi action groups (sequential / parallel)

continuous scaling

pay for usage

leverage docker under the hood for reproducible builds

possibility to extend capabilities leveraging our own base docker images

intergration with kms for encryption of build artifacts

iam for build permissions

vpc netowrk security

cloudtrail for api calls logging

build instruction can be defined in code (buildspec.yml file)

output logs to s3 & aws cloudwatch logs

use cloudwatch alarms to detect failed build and trigger notification

cloudwatch events / aws lambda as a glue

sns notifications

ability to reproduce codebuild locally to troubleshoot in case of errors

builds can be defined within codepipeline or codebuild itself

deployment group are set of ec2 instance where you are going to deploy to

supported environment

if not in lists, then you can use docker to extend any environment you linke

must be at root of your code

define environment variables

plaintext variables

secure secreets: use ssm parameter store

phases

install: install dependencies you may need for your build

pre build: final commands to execute before build

build: actual build commands

post build: finishing touches (zip output for example)

artifacts: upload to s3 encrypted with kms

cache: files to cache (usually dependencies) to s3 for future build speedup

codebuild containers are deleted at the end of their execution. you cannot ssh into them, even while they are running.

codepipeline can deploy to s3, so need to choose codepipeline

codebuild is mainly used for transform markdown file to html file in build phrase.

deploy application automatically to many ec2 instance

ec2 instnaces are grouped by deployment group (dev/test/prod)

codedeploy works with any application, auto scaling integration

blue/green only works with ec2 instances (not no premise)

support for aws labda

codedploy doesn't previson resources

hooks: set of instructions to do to deploy the new version (hooks can have timeouts).

the order is:

beforeblocktraffic

afterblocktraffic

applicationstop

downloadbundle

beforeinstall

afterinstall

applicationstart

validateservice: really important (to make sure application is indeed working)

beforeallowtraffic

allowtraffic

afterallowtraffic

failures:

new deployments wil first be deployed to "failed state" instance

to rolback: redploy old deployment or enable automated rollback for failures 

deployment targets:

set of ec2 intances with tags

directly to an auto scaling group

mix of asg / tags so you can build deployjment segments

customization in scripts with deployment_group_name environment variables

0. appspec.yml file, app store in s3

1. create two roles

one for codedeploy role:

another for ec2 role, because ec2 need to pull the code from s3

2. create an ec2 instance where codedeploy can deploy to:

add iam role for ec2

add http for security group

add tag "enviroment=dev"

3. ssh into ec2 instance

4. create codedeploy application

5. create deployment group

6. create deployment

7. view the app in broswer by using ec2 public ipv4 address.

you can specify automated roolback options

rollback when a deploymetn fails

disable rollbacks - do not perform rollbacks fro this deployement

if a roll back happens, codedepoy redepploys the last know good revision as a new deployment. (so it will get a new deployment id).

'

ref: https://aws.amazon.com/blogs/devops/how-to-enable-caching-for-aws-codebuild/ without cache: 

enable cache:

 build time was faster. as the dependencies didn’t need to get downloaded, but were reused from cache.

enable s3 and cloudwatch logs integration - aws codebuild monitors functions on your behalf and reports metrics through amazon cloudwatch. these metrics include the number of total builds, failed builds, successful builds, and the duration of builds. you can monitor your builds at two levels: project level, aws account level. you can export log data from your log groups to an amazon s3 bucket and use this data in custom processing and analysis, or to load onto other systems. incorrect options: use cloudwatch events - you can integrate cloudwatch events with codebuild. however, we are looking at storing and running queries on logs, so cloudwatch logs with s3 integration makes sense for this context.

deployment groups: goups to tagged intances (prod/dev/test) you can specify one or more deployment groups for a codedeploy application. the deployment group contains settings and configurations used during the deployment. most deployment group settings depend on the compute platform used by your application. some settings, such as rollbacks, triggers, and alarms can be configured for deployment groups for any compute platform. in an ec2/on-premises deployment, a deployment group is a set of individual instances targeted for deployment. a deployment group contains individually tagged instances, amazon ec2 instances in amazon ec2 auto scaling groups, or both.

amazon ecr users require permission to call ecr:getauthorizationtoken before they can authenticate to a registry and push or pull any images from any amazon ecr repository. amazon ecr provides several managed policies to control user access at varying levels