1 - What is CI CD

  • CodeCommit : source control service
  • CodeBuild : compiling source codes, runs test and produces packages ready to deploy
  • CodeDeploy : Automates code deployment to any instance (as EC2)
  • CodePipeline = CodeCommit + CodeBuild + CodeDeploy

to remember

  • Continuous Integration = CodeCommit
  • Continuous Delivery = CodeBuild + CodeDeploy
  • Continuous Deployment : CodePipeline

2 - CodeCommit 101

to remember

  • Centralized Code Repository
  • Enables Collaboration
  • Version Control

3 - CodeCommit Lab

ToDo

  1. Developer Tools
  2. CodeCommit
  3. Create a repository
  4. Create branch
  5. Create a commit
  6. Create a pull request

If the branch is out update, we have to clone the master branch before to push on it

4 - CodeDeploy 101

Automated Deployment works with :

  • EC2 instances
  • on-premises
  • lambda

Instance runs on Elastic Run Balancment

2 deployment approaches :

  1. In-Place : the application is stopped on each instance = Rolling Instance :
  2. 1 elastic run balancment + 3 instances
  3. so the capacity will be reduced
  4. new version = Revision (= virgin)
  5. you can NOT rollback quickly
  6. first deploying
  7. fees : +
  8. Blue (active deployment) / Green (the new release) :
  9. 1 elastic run balancment + 2 group of 3 instances
  10. switch between group of instance
  11. no reduces of capacity
  12. you can rollback quickly
  13. after first deployment
  14. fees : ++
  15. safest option

5 - Advanced codedeploy the AppSpec File

AppSpec File : configuration files defining the parameters used during a CodeDeploy deployment

Le fichier Appspec est un fichier spécifique à CodeDeploy. Ce fichier permet d'orchestrer les actions à mener sur une machine. Il est sous format YAML ou JSON et se place à la racine du repository GitHub de notre WordPress.

Ce fichier est nécessaire pour :

  • mapper les fichiers applicatifs avec leur destination sur l'instance
  • gérer les droits des fichiers applicatifs
  • spécifier des scripts à exécuter durant le cycle de vie du déploiement.

File structure

  • version (allowed value is 0.0)
  • OS
  • files : location
  • hooks : life cylce event hooks (have a specific run order)

appspec

step

root folder contains :

  • scripts (launch in the appspec.yml indicates in the hook : (installdependencies.sh or startserver.sh or stop_server.sh) )
  • Config
  • Source (index.html)
  • appspec.yml (root position of the yml file)

6 - CodeDeploy Lifecylce Event Hooks

Run Order - Phase

  1. De-registering instances from a load balancer
  2. Before Block Traffic
  3. Block Traffic
  4. After Block Traffic
  5. Installation : The real nuts & bolts of the appllication deployment
  6. application stop
  7. Download Bundle : CodeDeploy agent copies the application revision files to a temporary location
  8. BeforeInstall : Pre install script (as backing up the current version or decrypting files)
  9. Install : Copy application revision files to* final* location
  10. AfterInstall : Post install scripts e.g. configuration
  11. ApplicationStart
  12. ValidateService (test)
  13. Re-registrering with the load balancer
  14. Before Allow Traffic
  15. Allow Traffic
  16. After Allow Traffic

https://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/deployment-steps-server.html#deployment-steps-components-server

CodeDeploy sont les suivantes:

  1. On crée une application CodeDeploy
  2. On cible les instances sur lesquelles on va déployer : le groupe de déploiement
  3. On spécifie la configuration du déploiement
  4. On envoie une révision du code à CodeDeploy
  5. CodeDeploy la déploie
  6. On vérifie le résultat
  7. Si besoin on redéploie

7 - CodeDeploy Lab

ToDo

  1. Security, Identity & Compliance
  2. IAM
  3. Create a role from S3Full access policy
  4. Create a role from AWSCodeDeployRole : Allow it to call AWS services, allowing :
  5. AutoScaling
  6. Describe instances and terminates instances
  7. cloudwatch
  8. tags
  9. registering and deristering with our load balancer
  10. Services - Compute - EC2 IAM Linux
  11. noneed to define a subnet
  12. auto assign public ip
  13. add tags to help codeploy to use this tags to identify the instance to deploy
  14. configure security group : SSH & HTTP
  15. choose a key pair
  16. Connect to ec2-user@
  17. on the instance.

    • wget htps://aws-codedeploy-eu-wet-2.s3.amazoaws.com/latest/install
    • sudo service codedeploy agent status
  18. connect the local machine to code deploy from the local machine
  19. on aws console :

    • add user and save its access key ID and value (programmatic access)
  20. on the local machine :

    • $ aws configure
  21. Upload in a bucket the config files (appspec.yml : application bundle) to give the possibility to CodeDeploy to Access them
  22. AWS console - S3 - Storage - bucket
2.$  aws deploy create-application --application-nam mywebapp
  1. Developper Tools
  2. CodeDeploy
  3. Application - mywebapp
  4. deployment group - create : 1. envirobment configuration : Amazon EC2 instances 2. setting : AllAtOnce, halfAtOnce 3. Use or not the loadbalancer
  5. Application lifecycle event failure
  6. Rollback configuration

8 - CodePipeline

Roles

A fully managed CI/CD service :

  1. Triger a pipelin every time there is a change to our code
  2. Aitomated Release Process
  3. integrates with AWS tools :
  4. CodeCommit, CodeBluid, CodeDeploy, GitHub, Jenkins, Elastiks (containers managers)...

CodePipeline Workflow

  1. CodePipeline (workflow defined)
  2. CodeCommit (new code appears)
  3. CodeBuild (testes)
  4. CodeDeploy (application deployed)

to remember

CodePipeline1

9 - CodePipeline lab

steps

  1. Cloud formation to create an EC2 instance
  2. Upload a version 1 to S3 bucket
  3. Deploy EC2 instance using codeDeploy
  4. Code Pipeline : a managed trigger to deploy our version 2
  5. Cloud Watch : : a automaticaly trigger to deploy our version 3

CodePipeline2

Origin folder and files

CF.txt : CloudFormation commands : laucnh an EC2 instance as on the AWS console

CF.json : tag our instance to identify xith code deploys, asosicate an SSH key pair name, set up a security group, mapping in at least a region

steps

1sr deployment

  1. creation of the bucket using CloudFormation :
  2. upload the CF_template .json files to your own bucket
  3. run the CF.txt files
  4. before :
  5. indicates bucket name
  6. indicates key pair name
  7. create policy to grant new right to the user
  8. add the app.zip to the bucket
  9. verify that the cloud Formation wtack has completed using :
  10. $ awscloudformation describe-stacks --stack-name
  11. Log into you instance and check that the codeploy agent has correctly installed :
  12. laucnh EC2 instance and copy its IPV4 IP
  13. ssh i- keypair.pem ec2-user@
  14. sudo service codedeploy-agent status
  15. CodeDeploy
  16. Deploy Group new
  17. Find the instance thanks to its instance

step with Code Pipeline with manually upload :

  1. Choose pipeline settinfs
  2. Add source stage (where our application S3 object key : app.zip is locataed)
  3. Add build state (providing build artificat details like OS, output files names : CodeBuild or Jenkins)
  4. Add deploy stage (deploy provider, region, application name, deployment group)

step with Code Pipeline with triggered codeDeploy (automatic deployment)

  1. upload the app.zip

10 - IAM - Lab

iam1

.JSON :

{
  "Version :" : "2012-10-37",
  "Statement" [
    {
      "Effect" : "Allow",
      "Action" : "*",
      "Resource" : "*"
    }
  ]
}

to remember

  1. Roles are more secure thant storing your access key and secret access key on individual EC2 instances
  2. Roels are easier to manage
  3. Roelse can be assigner to an EC2 instance after it is created using both AWS console and command line
  4. Roles are universal (any region)

11- Using BootStrap Script - Lab

Way to automatisating AWS deployment

ToDo

1.S3 bucket using our bootstrap script

  1. Add in Advanced details at the configure Instance details

    #!/bin/bash
    yum update -y
    yum install httpd -y
    service httpd start
    chkconfig httpd on
    cd /var/www/html
    echo "Hello"
    aws s3 mb s3 
    aws s3 cp index
    

12 - Instance MetaData

curl http://123.123.132/latest/meta-data \ > bootstrap.txt

curl http://123.123.132/latest/user-data \ > ip_adress.txt

EC2 vs Lambda

https://www.simform.com/aws-lambda-vs-ec2/

EC2 = Elastic

AppSpec file : YAML only

Amazon Elastic Compute Cloud (EC2) est un service d'infrastructure de cloud virtuel proposé par AWS. Il fournit des ressources informatiques à la demande grâce auxquelles vous pouvez créer de puissants serveurs dans le nuage.

L'ensemble du matériel de l'EC2 est fragmenté en de multiples ressources qui sont offertes sous la forme d'instances évolutives en termes de mémoire de calcul et de puissance de traitement.

Il vous offre également la possibilité d'héberger votre application sur plusieurs plateformes avec une sécurité renforcée pour une architecture multi-modèles et multi-locataires. Ces instances peuvent être accessibles par HTTP ou HTTPS (API), ce qui permet aux développeurs de créer des applications comme s'il s'agissait d'une infrastructure sur site.

Avec Amazon EC2, vous avez la possibilité d'approvisionner des machines virtuelles selon les besoins de vos applications. Cette possibilité est offerte dans le cadre d'un modèle d'abonnement basé sur l'utilité, où l'utilisateur est facturé en fonction de sa consommation de ressources.

AWS Lambda

AppSpec file : YAML and JSON

AWS Lambda est une ressource de cloud computing à la demande proposée en termes de fonction-as-a-service par AWS. Au fil du temps,

La principale différence entre AWS Lambda et EC2 (ressources basées sur des serveurs virtuels) réside dans la responsabilité du provisionnement et des cas d'utilisation, pour n'en citer que quelques-uns. La tarification d'AWS Lambda est également l'un des principaux facteurs.

Avant l'émergence de solutions agiles comme AWS Lambda, les équipes opérationnelles devaient allouer les ressources en fonction des prévisions. Elles devaient s'assurer que les besoins en ordinateurs et en mémoire ne dépassaient pas les limites que leur système pouvait supporter.

Avec des ressources informatiques comme AWS Lambda, les ressources informatiques peuvent s'adapter et diminuer automatiquement en fonction des demandes en temps réel. Actuellement, AWS Lambda prend en charge plusieurs langues et peut être utilisé dans une application de plusieurs manières ou en tant que service.

L'architecture des applications construites à l'aide de fonctions comme AWS Lambda est communément appelée architecture sans serveur.

Which one to use

If you’re wasting your compute resources due to unpredictable traffic for your application but still want a scalable and cost friendly solution, AWS Lambda is for you. When not to use AWS Lambda? When you want to do complex processing and your process can’t be executed in the limited execution time.Or maybe you want to run a complex application which has consistent traffic and want to operate in a tried and tested deployment environment, EC2 if for you. The only drawbacks are a complex setup environment and provisioning of servers.The result- For either AWS Lambda vs EC2 or vice versa, both operate for a highly specific use case, however, one wasn’t sufficing the need which necessitated the invention of another.Until then, let’s make the most of each of the services. If you’ve hands-on experience with either EC2 or Lambda or both, I’d love to hear from you.


Ce site est propulsé par:

  • unofficial javascript logo
  • react atom logo
  • gatsbyjs logo
  • markdown logo

©2020 - SDLDonfred Digital