Drone and AWS App Runner - Better Together
Getting started with Drone to handle the build and publish sections is a breeze, then allowing AWS App Runner to deploy into AWS infrastructure.
As more developer resources head towards the public cloud, Amazon Web Services recently released AWS App Runner. The premise of AWS App Runner is that engineers can focus solely on the source code and do not need to have knowledge of the underlying infrastructure. AWS App Runner seems to be AWS’ first foray into offering a platform-as-a-service (PaaS) aimed at the AWS platform.
AWS App Runner resembles Rancher Rio; removing the networking/route complexities for services by just creating publicly-accessible routes for the deployments. Getting started with Drone to handle the build and publish sections is a breeze, then allowing AWS App Runner to deploy into AWS infrastructure.
There are a few moving parts to get started. The first will be the need to install a Drone if you do not have access to a Drone Installation. In this example, we will be using GitHub as the source code management platform. Next, the pieces will be to create an Amazon ECR registry/repository which will be used to store the Docker images that will eventually be deployed by App Runner.
Amazon ECR Configuration
Drone has a plugin to facilitate Amazon ECR publishes. If you have not created an Amazon ECR registry before, the configuration is simple. You can log into your AWS Account and head to ECR -> Create repository.
In this example, we will give the private ECR Registry then the Repository name of “sample-apprunner-ecr.”
When you hit Submit, the private ECR repository is ready.
There are a few ways to get programmatic access to your private ECR repository, such as authenticating with the registry. The Drone plugin out of the box uses access keys. You can use the access keys for the account that created the ECR repository, or you can make a purpose-made IAM account. For this example, I made a Drone-ECR account and attached an ECR policy [also named Drone-ECR].
AWS IAM -> Create Policy then select the appropriate permissions. For this example, I granted all permissions to the new policy. In your own environment, you can lock down more appropriately.
Once created, you can attach the IAM policy to an IAM user via an IAM group.
If this is a new user, make sure to mark down the access and secret keys of the user. With the ECR permissions out of the way, it’s time to head to GitHub.
You can fork this sample project which will have a sample recipe for Drone to publish to ECR. Drone does need to instantiate the project (for example, creating a webhook on your behalf to monitor for changes).
Navigate in Drone to the GitHub project that you want to build. Click on Activate Repository.
If you are leveraging the example project, the Drone Configuration is called “drone.yaml” which you can configure at the bottom of Settings.
Once you hit Save, your GitHub project should have a webhook installed to your installation URL:
Now you are ready to dig a little deeper into the Drone Settings.
If leveraging the example, there are 5 items that are sensitive, which can be shared as Drone Secrets: the AWS IAM user’s secret and key, the ECR Repository Name, ECR Registry Address, and ECR Region.
You can wire the secrets by going to Repository -> Settings -> Secrets and create the five secrets.
Secrets that need creating, and their value:
- aws_access_key : IAM Access Key for User Account
- aws_secret_key : IAM Secret Key for User Account
- aws_ecr_repo : AWS ECR Repo Name for example “sample-apprunner-ecr”
- aws_ecr_registry : AWS ECR Registry address for example “your_unique_id.dkr.ecr.us-east-2.amazonaws.com”
- aws_region : AWS Region ECR is in for example “us-east-2”
Each wired in:
To simulate a change, you can modify the drone.yaml file, for example changing the tag and committing in GitHub. This will kick off a build.
The build should be successful.
You can validate the publish step by looking in ECR for a new image.
Now that you are able to easily build and publish an image, the next step is to configure AWS App Runner.
Your First AWS App Runner
Configuring AWS App Runner is straightforward, especially when following their first published example.
The first step is to navigate to AWS App Runner in your AWS Account.
Click on Create an App Runner service. Then, select Container Registry and Amazon ECR as the provider.
You can click Browse and select the image that was uploaded by Drone.
Click Continue, and for the example, just leverage a Manual trigger.
If you do not have an appropriate Service Role, the wizard can create a generic one for you.
Click Next to configure the service. The example application in the GitHub repo sends traffic over port 3000, which you can configure as the port in App Runner.
You can leverage all the defaults to deploy this “AwesomeApp.”
Click on Create & Deploy. The service will take a few moments to create the appropriate infrastructure and deploy.
By clicking on the default domain, you now have access to your first AWS App Runner Service.
Navigating to the URL:
Just like that, you have a deployed container with a publicly accessible route with AWS App Runner!
Harness and AWS App Runner, Better Together
If you need more control over the prescribed AWS App Runner opinion, adding Harness to the mix is a great choice to leverage the capabilities of both. AWS App Runner is AWS’ newest PaaS-like service, aiming to simplify user experience from Elastic Beanstalk. Not all workloads are conducive to being run on AWS App Runner. With the Harness Platform, you are free to build and deploy very heterogeneous technologies. Certain workloads can fare better in other AWS services such as Fargate or just a plain AMI/EC2 instance. No matter where you are deploying, Harness has you covered.