Developers can now use App Runner to quickly deploy containerised web applications and APIs
One of the complexities with Amazon Web Services is the wide variety of syntax for the many services that can be deployed, updated and queried via code.
In an effort to bring uniformity to these processes, AWS has released the Cloud Control API. Through a standardised API interface, developers can now run CRUD operations across many of the services within the Amazon ecosystem. AWS has also committed to bring more services into the scope of Cloud Control, so it’s a useful skill to have in your developer’s toolbox.
In addition, the recent released App Runner provides a fully managed method for deploying containerised web applications and APIs with scalability, SSL certificates and CD built-in from the get go.
You can grab the files from this example from the repository to try it out.
As with all AWS services, there are a number of different ways to deploy infrastructure, including:
- AWS console
- AWS CLI
- AWS SDKs
- Infrastructure as code such as Terraform
- You have obtained an AWS authentication access ID and key, and placed both in your GitHub repository’s secrets.
- You have an IAM role to allow App Runner to access ECR.
Image of the “secrets” settings in Github
Building our workflow
As I’ve mentioned, the real benefit with Cloud Control is the standardised structure for CRUD operations, regardless of the resource type. This has some advantages over previous methods of interaction with AWS services.
For our pipeline, we’re going to use a GitHub Action. This will interact with both Cloud Control and App Runner.
The Cloud Control API exposes five main verbs (along with another three for querying request status). The main five are:
GitHub will look in
.github/workflows/ for our workflows, so we define a
cd.yaml file here, which starts by checking out our code so that it’s available to the workflow. We then set up Node.js for use in our scripts, and configure AWS credentials.
workflow_dispatch trigger, which enables us to trigger execution of the workflow manually without having to push any code.
ecr_setup.js — which, as we’ve already defined, will be in our workflow directory along with our YAML.
require the aws-sdk we installed in the previous step, create a new instance of the Cloud Control service SDK and pull in our environment variables.
Note how, in our async function above, we
getResource to check if our repo exists. If it doesn’t, it will generate an error, which is caught by our repo creation code block. This code will
createResource with the desired state and then return control to our YAML script.
Back in our workflow our next step is to build our Docker image and push it to our ECR registry. I’ve written a sample app using Node.js and React for us to deploy here. The app is called “Artist Info” and provides a search facility for looking up any band or singer. It consumes the Musicbrainz API, and displays basic info about the artist, along with any relevant web links (social media, discographies, etc.).
We’re using the registry provided to us at login to ECR, and the repository name defined earlier. Our runlist ends by outputting the
ECR_IMAGE_NAME constructed from our registry and repo, so it can be used by App Runner to pull the correct image.
It’s worth noting here that, as well as running the container built in our GitHub workflow, App Runner has the ability to build from our source code instead, by connecting to the GitHub repository directly.
This is one of the features that could make App Runner extra useful in streamlining CD pipelines. We’re not using that in this example, however, because we found that this method involved carrying out at least one part of the flow manually.
Also, App Runner’s build from source coverage currently extends only to Node version 12 .
We’ll use another of Cloud Control’s methods —
listResources — to get our existing App Runner services. Then, we can simply
return if the
ResourceDescriptions array contains our service.
App Runner should need to be set up just once. One of its strengths is its ability to monitor our ECR image and redeploy it whenever it changes. For this, we set
If our service exists, there’s nothing to do here.
If our service is not found, the workflow is either being run for the first time, or perhaps the service has been manually destroyed for some reason. If so, we create the resource. Remember, we need to submit the
desiredState (Cloud Control’s uniform resource definition) in a JSON blob or, to put it another way, a stringified JSON object.
Now, all that’s left to do is create the App Runner service. Resource creation will happen asynchronously, so our request will receive a response only to confirm that the process has started or that it has immediately failed.
Here, the response from our GitHub workflow log shows that the request has been accepted:
We must therefore
waitFor a success (or failure) message using the token we received when we issued
A diagram showing an overview of the the flow of interactions for deploying an AWS App Runner service with Cloud Control
If you’ve followed these steps correctly, you’ll now have your app deployed and running within App Runner. Any commits you make to the main branch of the repository will re-deploy the infrastructure and code automatically, which should save you a lot of time in the future. You can grab a coffee and relax!
Sébastien Stormacq, Principal Developer Advocate at AWS, has written a great blog post on the release of Cloud Control.
You can also discover more about App Runner on the AWS website.