Continuous Deployment : Using AWS Code Commit, AWS Code Deploy and Jenkins (Part 3)

AWS CodeDeploy
AWS CodeDeploy coordinates application deployments to Amazon EC2 instances, on-premises instances, or both. (On-premises instances are physical devices that are not Amazon EC2 instances.)
An application can contain deployable content like code, web, and configuration files, executables, packages, scripts, and so on. AWS CodeDeploy deploys applications from Amazon S3 buckets and GitHub repositories.
You do not need to make changes to your existing code to use AWS CodeDeploy. You can use AWS CodeDeploy to control the pace of deployment across Amazon EC2 instances and to define the actions to be taken at each stage. AWS CodeDeploy works with various systems for configuration management, source control, continuous integration, continuous delivery, and continuous deployment.
AWS CodeDeploy offers these benefits:
Automated deployments: AWS CodeDeploy fully automates your application deployments across your development, test, and production environments. AWS CodeDeploy scales with your infrastructure so that you can deploy to one instance or thousands.
Minimize downtime: AWS CodeDeploy helps maximize your application availability by performing rolling updates across your Amazon EC2 instances and tracking application health according to rules you configure. You can stop and roll back deployments if there are errors.
Centralized control: You can launch and track the status of your deployments through the AWS CodeDeploy console or the AWS CLI. You will receive a report that lists when each application revision was deployed and to which Amazon EC2 instances.
Easy to adopt: AWS CodeDeploy is platform-agnostic and works with any application. You can easily reuse your setup code. AWS CodeDeploy can also integrate with your software release process or continuous delivery tool-chain.
sds_architecture
Here’s how it works:
1. First, you create deployable content on your local development machine or similar environment, and then you add an application specification file (AppSpec file). The AppSpec file is unique to AWS CodeDeploy; it defines the deployment actions you want AWS CodeDeploy to execute. You bundle your deployable content and the AppSpec file into an archive file, and then upload it to an Amazon S3 bucket or a GitHub repository. This archive file is called an application revision (or simply a revision).
2. Next, you provide AWS CodeDeploy with information about your deployment, such as which Amazon S3 bucket or GitHub repository to pull the revision from and which set of Amazon EC2 instances to deploy its contents to. AWS CodeDeploy calls a set of Amazon EC2 instances a deployment group. A deployment group contains individually tagged Amazon EC2 instances, Amazon EC2 instances in Auto Scaling groups, or both.
Each time you successfully upload a new application revision that you want to deploy to the deployment group, that bundle is set as the target revision for the deployment group. In other words, the application revision that is currently targeted for deployment is the target revision. This is also the revision that will be pulled for automatic deployments.
3. Next, the AWS CodeDeploy agent on each instance polls AWS CodeDeploy to determine what and when to pull from the specified Amazon S3 bucket or GitHub repository.
4. Finally, the AWS CodeDeploy agent on each instance pulls the target revision from the specified Amazon S3 bucket or GitHub repository and, using the instructions in the AppSpec file, deploys the contents to the instance.
AWS CodeDeploy keeps a record of your deployments so that you can get information such as deployment status, deployment configuration parameters, instance health, and so on
AWS CodeDeploy requires the following for each instance that it deploys to.
  1. Each Amazon EC2 instance must launch with the correct IAM instance profile attached.
  2. Each Amazon EC2 instance must have identifying Amazon EC2 tags  or be in an Auto Scaling group.
  3. Each on-premises instance must have an associated IAM user, identifying on-premises instance tags, and a special configuration file.
  4. The AWS CodeDeploy agent must be installed and running on each instance
Provision an IAM User
Follow these instructions to prepare an IAM user to use AWS CodeDeploy:
Use the previously created IAM user access to AWS CodeDeploy—and AWS services and actions AWS CodeDeploy depends on—by attaching the following policy to the existing IAM user:
{
  "Version": "2012-10-17",
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "autoscaling:*",
        "codedeploy:*",
        "ec2:*",
        "elasticloadbalancing:*",
        "iam:AddRoleToInstanceProfile",
        "iam:CreateInstanceProfile",
        "iam:CreateRole",
        "iam:DeleteInstanceProfile",
        "iam:DeleteRole",
        "iam:DeleteRolePolicy",
        "iam:GetInstanceProfile",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListInstanceProfilesForRole",
        "iam:ListRolePolicies",
        "iam:ListRoles",
        "iam:PassRole",
        "iam:PutRolePolicy",
        "iam:RemoveRoleFromInstanceProfile",
        "s3:*"
      ],
      "Resource" : "*"
    }   
  ]
}

Create a Service Role for AWS CodeDeploy
We need to configure two IAM Roles that would be used to boot the EC2 server / access S3 and then for Code Deploy to talk to EC2 server, S3, Elastic Load Balancing and Auto Scaling .
In AWS, service roles are used to grant permissions to an AWS service, so it can access AWS resources. The policies that you attach to the service role determine which AWS resources the service can access and what it can do with those resources.
The service role you create for AWS CodeDeploy must be granted the permissions to access the instances to which you will deploy applications. These permissions enable AWS CodeDeploy to read the tags applied to the instances or the Auto Scaling group names associated with the instances.
The permissions you add to the service role specify the operations AWS CodeDeploy can perform when it accesses your Amazon EC2 instances and Auto Scaling groups. To add these permissions, attach an AWS-supplied policy,  AWSCodeDeployRole, to the service role.
As part of setting up the service role, you also update its trust relationship to specify the endpoints to which you want to grant it access.
Create a Service Role (Console)
  • Loign in to the Identity and Access Management (IAM) console
  • In the Role Name box, give the service role a name (for example, CodeDeployRole), and then choose Next Step.
  • On the Select Role Type page, with AWS Service Roles selected, next to AWS CodeDeploy, choose Select.
On the Attach Policy page, select the box next to the AWSCodeDeployRolepolicy, and then choose Next Step.
The AWSCodeDeployRole policy provides the permissions required for your service role to read the tags on your instances or identify your Amazon EC2 instances by Auto Scaling group names. By default, this policy also includes a trust relationship that grants your service role access to all of the endpoints currently supported by AWS CodeDeploy.
You can restrict the service role’s access to only those endpoints you specify.
Note the value of the Role ARN field. You will need it later when you create deployment groups. If you forget the value, follow the instructions in Get the Service Role ARN (Console) .
Choose Create Role.
If you want this service role to have permission to access all currently supported endpoints, you are finished with this procedure. If you want to restrict this service role from accessing all endpoints, in the list of roles, browse to and choose the role you just created, and continue with the next step.
Under Trust Relationships, choose Edit Trust Relationship.
You should see the following policy, which provides the service role permission to access all supported endpoints:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "codedeploy.amazonaws.com"
        ]
      },
         "Action": "sts:AssumeRole"
    }
  ]
}
To grant the service role access to only some supported endpoints, replace the contents of the Policy Document box with the following policy, remove the lines for the endpoints to which you want to exclude access, and then choose Update Trust Policy.
{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Sid": "",
        "Effect": "Allow",
        "Principal": {
           "Service": [
             "codedeploy.us-east-1.amazonaws.com", 
             "codedeploy.us-west-1.amazonaws.com",
             "codedeploy.us-west-2.amazonaws.com",
             "codedeploy.ap-northeast-1.amazonaws.com",
             "codedeploy.ap-northeast-2.amazonaws.com",
             "codedeploy.ap-south-1.amazonaws.com",
             "codedeploy.ap-southeast-1.amazonaws.com",
             "codedeploy.ap-southeast-2.amazonaws.com",
             "codedeploy.eu-central-1.amazonaws.com",
             "codedeploy.eu-west-1.amazonaws.com",
             "codedeploy.sa-east-1.amazonaws.com"
            ]
          },
      "Action": "sts:AssumeRole"
       }
     ]
   }

Get the Service Role ARN (Console)
To use the IAM console to get the ARN of the service role:
  1. Sign in to the Identity and Access Management (IAM) console
  2.  In the navigation pane, choose Roles.
  3.  In the Search box, type CodeDeployRole, and then press Enter.
  4.  Choose CodeDeployRole.
  5. Note the value of the Role ARN field.
Create an IAM Instance Profile for Your Amazon EC2 Instances
Your Amazon EC2 instances need permission to access the Amazon S3 buckets or GitHub repositories where the applications that will be deployed by AWS CodeDeploy are stored. To launch Amazon EC2 instances that are compatible with AWS CodeDeploy, you must create an additional IAM role, an instance profile. These instructions show you how to create an IAM instance profile to attach to your Amazon EC2 instances. This role gives AWS CodeDeploy permission to access the Amazon S3 buckets or GitHub repositories where your applications are stored.
Create an IAM Instance Profile for Your Amazon EC2 Instances
  1. Sign in to the Identity and Access Management (IAM) console
  2.  In the IAM console, in the navigation pane, choose Policies, and then choose Create Policy. (If a Get Started button appears, choose it, and then choose Create Policy.)
  3.  Next to Create Your Own Policy, choose Select.
  4. In the Policy Name box, type InstanceRole.
  5.  In the Policy Document box, paste the following:
{
   "Version": "2012-10-17",
   "Statement": [          {
            "Resource": "*",
            "Action": [
                "elasticloadbalancing:Describe*",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "autoscaling:Describe*",
                "autoscaling:EnterStandby",
                "autoscaling:ExitStandby",
                "autoscaling:UpdateAutoScalingGroup",
                "autoscaling:Describe*",
                "cloudformation:Describe*",
                "cloudformation:GetTemplate",
                "s3:Get*"
            ],
            "Effect": "Allow"
        }
    ]
}

  1. ChooseCreate Policy.
  2. In the navigation pane, chooseRoles, and then choose Create New Role.
  3. In theRole Name box, give the IAM instance profile a name CodeDeployInstance , and then choose Next Step.
  4. On theSelect Role Type page, next to Amazon EC2, choose Select.
  5. On theAttach Policy page, select the box next to InstanceRole, and then choose Next Step.
  6. ChooseCreate Role.
This service role will give the access permission for EC2 server to access Amazon S3, AWS CloudFormation, Elastic Load Balancing and Auto Scaling services.
Now you need to launch a new Instance attached with IAM role CodeDeployInstance and install aws cli with aws code deploy agent.

To Install CodeDeploy agent follows below steps:
aws s3 cp s3://aws-codedeploy-us-east-1/latest/install . --region us-east-1
chmod +x ./install
sed -i "s/sleep(.*)/sleep(10)/" install
./install auto
service codedeploy-agent status

Comments

Popular posts from this blog

Datastax Error : Cannot start node if snitch's data center (dc1) differs from previous data center (dc2)

Datastax Error : Cassandra - Saved cluster name Test Cluster != configured name

Configure Nagios plugin " check_logfiles " for scanning log file

Popular posts from this blog

Datastax Error : Cannot start node if snitch's data center (dc1) differs from previous data center (dc2)

Datastax Error : Cassandra - Saved cluster name Test Cluster != configured name

Configure Nagios plugin " check_logfiles " for scanning log file