Tutorial - deploy to S3 and OpsWorks from AWS by creating separate users

Make life easier for deploying your AWS web application project to S3 and OpsWorks by creating different users in AWS to do the job for you. We show you how in this tutorial.

In this post we will do a simple configuration for deployment to different environments with Amazon Web Services (AWS). We will show you how to configure two separate AWS users for deploying apps to both S3 and OpsWorks, allowing us to easily work with different environments. Amazon’s S3 is a popular cloud web hosting service and OpsWorks is their server configuration management service.

This post describes a very specific configuration setup for the deployment to S3 and OpsWorks, so here is a long list of assumptions we need to make first:

• You have a front-end app which is going to be deployed to S3
• You have a back-end API app which is going to be deployed to OpsWorks
• You already know how to deploy an app to OpsWorks and S3
• You have a separate stack on OpsWorks for production and staging
• You have a separate bucket on S3 for production and staging
• the `staging_deployer` user should only have access to the staging stack
• the `deployer` user should have access to all stacks

If you are still with us, let's get to work.

Deployer user

We will start with the `deployer` user because it's easier - this user has access to all stacks and buckets.

First we need to create a `deploy-s3` policy that will update all of our S3 buckets:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmtxxxxxxxxxxxxxxxxxxx",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:PutObjectACL",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ]
        }
    ]
}

and then the `deploy-opsworks` policy to update all stacks on Opworks:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeInstances",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "elasticloadbalancing:CreateLoadBalancerListeners",
                "elasticloadbalancing:DeleteLoadBalancerListeners",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "elasticloadbalancing:DescribeInstanceHealth",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeLoadBalancers",
                "opsworks:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Staging deployer

The policies for the `staging_deployer` user are slightly more complex since they should only allow updates to S3’s staging bucket and OpsWorks’s stack.

The `deploy-s3-staging` policy allows us to deploy a front-end app to a single S3 bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:PutObjectACL",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::your-staging-bucket",
                "arn:aws:s3:::your-staging-bucket/*"
            ]
        }
    ]
}

Remember to replace `your-staging-bucket` with your actual bucket's name.

The `deploy-opsworks-staging` policy allows us to perform rolling deploys (zero down-time) to a single stack on OpsWorks:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeInstances",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "elasticloadbalancing:DescribeInstanceHealth",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeLoadBalancers",
                "opsworks:DescribeStacks"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:CreateLoadBalancerListeners",
                "elasticloadbalancing:DeleteLoadBalancerListeners",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer"
            ],
            "Resource": [
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/your-staging-load-balancer-name"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "opsworks:*"
            ],
            "Resource": [
                "arn:aws:opsworks:*:*:stack/your-staging-stack-id/"
            ]
        }
    ]
}

Remember to replace `your-staging-load-balancer-name` and `your-staging-stack-id` with the correct values.

If you need help with AWS, or at any other stage of your DevOps pipeline, we are the people to come and see. iRonin’s team of DevOps and software development experts are always looking for the best way to do things, and the most highly automated solutions to make your life (and project) easier. Contact us for more information about our range of specialized services.