AWS Proton is a fully-managed application delivery service that enables platform operations
teams to provide consistent architecture across an organization, and enables developers to deliver
their applications on approved infrastructure using a self-service interface. In this demo, we’ll see
how to set up all the different tools our development teams need for infrastructure
provisioning, code deployments, monitoring, and updates. Let’s begin by opening the AWS Proton
service page in the AWS Console and clicking “Get started”. Before development teams can use
Proton to deploy services, we’ll need to create a service template for them to use and a
standardized environment where they can deploy their services. To create that environment, we first
need to create an environment template. Let’s go ahead and do that now. A Proton environment
template is a re-usable bundle of configuration files that define the metadata and infrastructure
resources needed to create a given environment. For this demo, we’ll be creating a template to
provision a new environment using one of the sample template bundles provided by the AWS
Proton team. The sample template bundle consists of: a manifest.yaml file, which lists the
files used to define an environment’s infrastructure, a schema.yaml file, which defines
the input parameters used in the infrastructure templates, and a cloudformation.yaml
infrastructure file, which defines the infrastructure itself. We also have the option of providing our
own template bundle, which will build a custom environment according to our organization’s best
practices, or we could tell Proton to use some existing provisioned infrastructure that we manage
on our own. Let’s select the “fargate-environment” sample template bundle, fill in a template name
and description, and leave the rest of the options alone. Next, we’ll create a service template.
A service template, similar to an environment template, is a re-usable bundle of configuration
files that define a complete set of resources. The sample “fargate-service” template bundle, like the
“fargate-environment” template bundle we just saw, also consists of manifest, schema, and
cloudformation YAML files to define the infrastructure, but also contains an additional
cloudformation.yaml and manifest.yaml file to define a deployment pipeline for the service.
We’ll fill in the service template name and description, and leave the rest of the options alone like before
except for the compatible environment templates. Here, we’ll make sure to select our “proton-demo”
environment template from earlier. This will ensure that anybody using Proton to deploy this service
will deploy it to a compatible environment. After clicking “Create service template”, we’re asked to
configure an account role. This is the IAM Role that Proton will use to make API calls to other
services, such as CloudFormation, on our behalf. For this demo, we’ll have Proton create a new
service role for us; however, we strongly advise platform administrators to read more on Proton’s
access control and scope this role down to the minimal set of privileges required by the templates they intend to use.
Before our developer teams can deploy their own “fargate-service” with Proton,
our last step as the platform operators is to actually build the environment they would be deploying to.
Let’s use the environment template we created earlier to do that now. We’ll choose our
“Proton Demo” environment template, call this a “staging” environment, choose the default service
role we created, and click “Next”. It’s now asking us for some VPC and subnet CIDR ranges
because the schema.yaml file in the sample template bundle said to expect some.
These values are optional, though, so let’s leave these fields blank to accept the defaults.
The deployment was created and is now in progress. While that’s running, let’s repeat the process to
create a “production” environment too, and let’s specify some CIDR ranges this time as well.
Creation of the sample environments should only take a few minutes to complete, but for longer
deployments, we can switch over to the CloudFormation console to follow its progress in more detail.
Great! The environment is ready and now just needs a service to run in it. Our work as platform operators is
complete for now, so let’s see how the next steps look from the perspective of our developer team.
We’re now logged in with a separate AWS Proton Developer role, which has the default
AWSProtonDeveloperAccess IAM policy applied to it, as well as read-only access to AWS CloudFormation
AWS CodePipeline, and a variety of services consumed by our sample application, such as Amazon ECS.
Let’s create our first service! First, we go to Services in the Proton service page and click “Create service”.
Next, we select the “Proton Demo” service template and click “Configure”.
We’ll give it a name and description, then configure the repository settings.
For this demo, we already have a GitHub repository connection established that allows us to detect source changes.
To configure your own, click “Create connection”, and follow the steps.
In this case, we’ll have it deploy from the "main" branch of our forked "aws-proton-sample-fargate-service"
repository using the existing AWS Proton Demo repository connection.
Next, we’ll configure two service instances - one for each environment that we created earlier.
First, we’ll create a “staging” service instance that will deploy to the staging environment
using whichever defaults are specified in the service template, and then, we’ll add a “production” service
instance for the production environment. This time, since it’s for a production environment,
let’s have it create 3 medium-sized Fargate tasks instead. Finally, we’ll leave the container image and Pipeline Inputs
at their defaults for this demo, as the pipeline configuration within the sample Fargate service template template bundle
for AWS Proton takes care of building the container image, and configuring our Fargate task definitions accordingly to use it.
Proton will create the service and service deployment pipeline, and we can follow the
progress using the CloudFormation stack events log. Then, we can watch the deployment pipeline
itself deploy our sample application to each environment. Now that our application is
deployed, making changes is just a matter of pushing new commits to our repository, which will
be detected by CodePipeline and begin a new deployment cycle. Since all this infrastructure is in
our account, we have full capacity to manage, update, and troubleshoot as required.
For example, platform operators can review CloudFormation stack events for issues when deploying environments,
developers can see details on code deployments within CodeBuild and CodePipeline,
and we can make changes to the underlying environments or services by creating a new minor or major version of the
corresponding template, providing an updated template bundle, and then updating the environments or service
instances to use the latest versions. AWS Proton, gives you right blend of control and flexibility so everyone can focus
on innovating for your business. If you'd like to try these examples for yourself, check out the sample templates
repositories linked in the video description, or visit aws.amazon.com/proton to get started today.