Pulumi Blog: Cloud Systems Series

Cloud Systems: Deploying to Amazon ECS

Kat Cosgrove — Tue, 28 Dec 2021 14:52:42 +0000

Cloud engineering is taking over software development. In a lot of ways, this is great; it allows us to build and deploy more complicated applications with less difficulty, and maintaining those applications becomes less troublesome too. We can release smaller updates more quickly than ever, ensuring that we can stay on top of feature requests and security issues. That said, the rise of cloud engineering has also introduced a lot of complexity in the form of dozens of services even within just one cloud provider. Figuring out where to start can be tough, so let’s take a practical tour! In this series, I’ll walk you through building a personal website and deploying it using modern cloud engineering practices.

Elastic Container Service

In the previous tutorial, we extended our personal website to use the Flask web framework, add server-side routing, and package everything up into a Docker container. It’s still only running locally, though, and we want to deploy it. To do that, today we’ll be learning to use Pulumi to deploy to Amazon’s Elastic Container Service. If you completed part two of this series, we’ll be picking up right where we left off. If you’re just now joining me, you can get the completed code by forking and cloning this repository.

Prerequisites:

Configuring Amazon ECS

Amazon’s ECS (Elastic Container Service) is a tool used for container orchestration. It allows you to deploy containerized applications into a cluster, defined as tasks. We’re going to use Pulumi to define all of the necessary rules and settings to do this in a secure manner, then create our infrastructure and deploy the containerized website.

First, run pulumi new python -y to start a new Pulumi project if you don’t already have one for this tutorial. From now on, we’ll be working within __main__.py

import json
import base64
import pulumi
import pulumi_aws as aws
import pulumi_docker as docker

First, we have our imports. We’re working with both AWS and Docker, so we need both of those Pulumi providers. Launch the virtual environment set up for you by Pulumi with source venv/bin/activate and run pip3 install pulumi-aws pulumi-docker to get both. If you want to make sure your dependencies are saved for later, you can run pip3 freeze > requirements.txt .

app_cluster = aws.ecs.Cluster("app-cluster")

app_vpc = aws.ec2.Vpc("app-vpc",
 cidr_block="172.31.0.0/16",
 enable_dns_hostnames=True)

app_vpc_subnet = aws.ec2.Subnet("app-vpc-subnet",
 cidr_block="172.31.32.0/20",
 vpc_id=app_vpc.id)

In this codeblock, we’re first creating our ECS cluster and naming it app-cluster. Then create a VPC (Virtual Private Cloud), and a subnet for it. VPCs are like miniature local networks, with subnets providing the addressing within that mini network. Using a VPC means you can wire up your system as you like it without worrying about how that network setup might collide with other AWS resources, since you define how that network can connect outward. If you’ve ever used Docker networking, you’ll be familiar with the idea that an internal network is different than the external interface.

It is possible to use the default VPC here rather than defining one, but AWS networking is complex, so it’s worth knowing that it is possible to define a custom VPC.

app_gateway = aws.ec2.InternetGateway("app-gateway",
 vpc_id=app_vpc.id)

app_routetable = aws.ec2.RouteTable("app-routetable",
 routes=[
 aws.ec2.RouteTableRouteArgs(
 cidr_block="0.0.0.0/0",
 gateway_id=app_gateway.id,
 )
 ],
 vpc_id=app_vpc.id)

app_routetable_association = aws.ec2.MainRouteTableAssociation("app_routetable_association",
 route_table_id=app_routetable.id,
 vpc_id=app_vpc.id)

Next, we need a gateway and a route table. The gateway’s job is to provide a target in that route table we just created and associated with our VPC. This allows our VPC to communicate with the public internet.

app_security_group = aws.ec2.SecurityGroup("security-group",
 vpc_id=app_vpc.id,
 description="Enables HTTP access",
 ingress=[aws.ec2.SecurityGroupIngressArgs(
 protocol='tcp',
 from_port=80,
 to_port=80,
 cidr_blocks=['0.0.0.0/0'],
 )],
 egress=[aws.ec2.SecurityGroupEgressArgs(
 protocol='-1',
 from_port=0,
 to_port=0,
 cidr_blocks=['0.0.0.0/0'],
 )])

Just about everything you do in AWS requires a security group. The purpose of a security group is to control traffic, both inbound and outbound. This one enables HTTP access.

# Creating an IAM role used by Fargate to execute all our services
app_exec_role = aws.iam.Role("app-exec-role",
 assume_role_policy="""{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": "sts:AssumeRole",
 "Principal": {
 "Service": "ecs-tasks.amazonaws.com"
 },
 "Effect": "Allow",
 "Sid": ""
 }]
 }""")

# Attaching execution permissions to the exec role
exec_policy_attachment = aws.iam.RolePolicyAttachment("app-exec-policy", role=app_exec_role.name,
 policy_arn="arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy")

# Creating an IAM role used by Fargate to manage tasks
app_task_role = aws.iam.Role("app-task-role",
 assume_role_policy="""{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": "sts:AssumeRole",
 "Principal": {
 "Service": "ecs-tasks.amazonaws.com"
 },
 "Effect": "Allow",
 "Sid": ""
 }]
 }""")

# Attaching execution permissions to the task role
task_policy_attachment = aws.iam.RolePolicyAttachment("app-access-policy", role=app_task_role.name,
 policy_arn=aws.iam.ManagedPolicy.AMAZON_ECS_FULL_ACCESS)

We’re going to be using AWS Fargate to actually run our container. Fargate is a serverless compute platform designed for running containers without requiring you to provision and manage clusters of EC2 (Elastic Compute Cloud) instances. Since our website is containerized and very small, it’s perfect for us. Services also require IAM roles, and in this case, we need to allow Fargate to execute our services and manage our tasks, so we create new roles for both and apply execution permissions to them.

In the context of Fargate, a task is a collection of containers, and a task definition tells AWS what needs to be running all at once in order to make an application run. The task definitions will be written later onm but first we need to define policies. It’s important that these policies be created first, or the task definitions won’t create correctly later on.

# Creating storage space to upload a docker image of our app to
app_ecr_repo = aws.ecr.Repository("app-ecr-repo",
 image_tag_mutability="MUTABLE")

# Attaching an application life cycle policy to the storage
app_lifecycle_policy = aws.ecr.LifecyclePolicy("app-lifecycle-policy",
 repository=app_ecr_repo.name,
 policy="""{
 "rules": [
 {
 "rulePriority": 10,
 "description": "Remove untagged images",
 "selection": {
 "tagStatus": "untagged",
 "countType": "imageCountMoreThan",
 "countNumber": 1
 },
 "action": {
 "type": "expire"
 }
 }
 ]
 }""")

The last thing we need to do for our infrastructure before we can start deploying to it is create a repository on Amazon ECR (Elastic Container Registry) where our Docker image will live, then attach an application lifecycle policy to that repository. This makes sure that we expire and remove any untagged images in the repository, keeping things from getting clogged up.

Deploying a Dockerized Flask Application to ECS

We’re now ready to deploy our website and wire all of this up!

flask_targetgroup = aws.lb.TargetGroup("flask-targetgroup",
 port=80,
 protocol="TCP",
 target_type="ip",
 vpc_id=app_vpc.id)

flask_balancer = aws.lb.LoadBalancer("flask-balancer",
 load_balancer_type="network",
 internal=False,
 security_groups=[],
 subnets=[app_vpc_subnet.id])

flask_listener = aws.lb.Listener("flask-listener",
 load_balancer_arn=flask_balancer.arn,
 port=80,
 protocol="TCP",
 default_actions=[aws.lb.ListenerDefaultActionArgs(
 type="forward",
 target_group_arn=flask_targetgroup.arn
 )])

First, we need to make it possible for our Flask application to communicate with the internet. That requires three pieces of configuration: a target group for port 80, a load balancer to spread out incoming requests and make sure our website doesn’t get overwhelmed as easily, and a listener to forward public traffic to the defined target group. The target group is directed at the endpoint for the VPC we created earlier, defining the port as it is unknown until runtime.

def get_registry_info(rid):
 creds = aws.ecr.get_credentials(registry_id=rid)
 decoded = base64.b64decode(creds.authorization_token).decode()
 parts = decoded.split(':')
 if len(parts) != 2:
 raise Exception("Invalid credentials")
 return docker.ImageRegistry(creds.proxy_endpoint, parts[0], parts[1])

app_registry = app_ecr_repo.registry_id.apply(get_registry_info)

flask_image = docker.Image("flask-dockerimage",
 image_name=app_ecr_repo.repository_url,
 build="./website",
 skip_push=False,
 registry=app_registry
)

A small helper function is required here. It’s grabbing some of our AWS credentials, specifically an authorization token, so that we can talk to the registry. Next, we build the Docker image for our website and push it to the repository we created in Amazon ECR earlier. Remember, the Dockerfile is in ./website.

flask_task_definition = aws.ecs.TaskDefinition("flask-task-definition",
 family="frontend-task-definition-family",
 cpu="256",
 memory="512",
 network_mode="awsvpc",
 requires_compatibilities=["FARGATE"],
 execution_role_arn=app_exec_role.arn,
 task_role_arn=app_task_role.arn,
 container_definitions=pulumi.Output.all(flask_image.image_name).apply(lambda args: json.dumps([{
 "name": "flask-container",
 "image": args[0],
 "memory": 512,
 "essential": True,
 "portMappings": [{
 "containerPort": 80,
 "hostPort": 80,
 "protocol": "tcp"
 }],
 }])))

We need a task definition for the Flask instance. AWS Fargate will be managing this for us, using the roles we defined earlier. We’re also handing it a container definition, including the image name and a little bit of information about it, like the container and host ports.

flask_service = aws.ecs.Service("flask-service",
 cluster=app_cluster.arn,
 desired_count=1,
 launch_type="FARGATE",
 task_definition=flask_task_definition.arn,
 wait_for_steady_state=False,
 network_configuration=aws.ecs.ServiceNetworkConfigurationArgs(
 assign_public_ip=True,
 subnets=[app_vpc_subnet.id],
 security_groups=[app_security_group.id]
 ),
 load_balancers=[aws.ecs.ServiceLoadBalancerArgs(
 target_group_arn=flask_targetgroup.arn,
 container_name="flask-container",
 container_port=80,
 )],
 opts=pulumi.ResourceOptions(depends_on=[flask_listener]),
)

Finally, we actually launch our website. We need to create a new service definition and hand it all of the resources we created earlier, beginning with the ECS cluster itself. It has the task definition, our network configurations, and our load balancers, and we make sure that this particular piece of code isn’t executed until the listener we created to watch for traffic is online.

As a shortcut to finding our website, export the DNS name of our load balancer as an output from Pulumi as the last part of the program:

pulumi.export("app-url", flask_balancer.dns_name)

We’re ready to go! Set your AWS region in your terminal:

pulumi config set aws:region us-west-2

Then run pulumi up to watch it go! This time, we’re going to see way more services created than before.

 Type Name Status Info
 + pulumi:pulumi:Stack part-three-dev created
 + ├─ docker:image:Image flask-dockerimage created
 + ├─ aws:ec2:Vpc app-vpc created
 + ├─ aws:ecs:Cluster app-cluster created
 + ├─ aws:iam:Role app-exec-role created
 + ├─ aws:iam:Role app-task-role created
 + ├─ aws:ecr:Repository app-ecr-repo created
 + ├─ aws:iam:RolePolicyAttachment app-exec-policy created
 + ├─ aws:iam:RolePolicyAttachment app-access-policy created
 + ├─ aws:ecr:LifecyclePolicy app-lifecycle-policy created
 + ├─ aws:ec2:Subnet app-vpc-subnet created
 + ├─ aws:ec2:InternetGateway app-gateway created
 + ├─ aws:ec2:SecurityGroup security-group created
 + ├─ aws:lb:TargetGroup flask-targetgroup created
 + ├─ aws:ecs:TaskDefinition flask-task-definition created
 + ├─ aws:lb:LoadBalancer flask-balancer created
 + ├─ aws:ec2:RouteTable app-routetable created
 + ├─ aws:ec2:MainRouteTableAssociation app_routetable_association created
 + ├─ aws:lb:Listener flask-listener created
 + └─ aws:ecs:Service flask-service created

Outputs:
 app-url: "flask-balancer-a90d260-057e5a40e0267b63.elb.us-west-2.amazonaws.com"

Resources:
 + 20 created

Duration: 3m36s

Pulumi has created 20 resources for you, and helpfully returned the DNS address of your load balancer. I’ve snipped out the diagnostics section of this output for the sake of keeping things brief, but you will also see the step-by-step process Docker goes through building and running your image. Go to that URL after a couple of minutes, and your website is online!

We now have a functional, multi-page website with server-side routing, packaged up into a Docker container and deployed to a fully-configured AWS ECS cluster in just a couple hundred lines of Python, all without leaving the same repository our website is stored in. What if we want to be able to scale really large, though? Some resiliency would be nice. Stay tuned for the next blog for an introduction to Kubernetes, where we’ll learn to deploy our website to Amazon’s Elastic Kubernetes Service!

Cloud Systems: Containerizing a Website

Kat Cosgrove — Mon, 27 Dec 2021 12:26:10 -0800

In part one of this series, we built a personal website and deployed it to AWS S3. That works perfectly well for a static, single-page application with minimal interactivity, but if you want server-side routing or database interactivity, things have to get a little bit more complicated. In part two of this series, we’ll be adding a couple more pages to our personal website, adding server-side routing, and containerizing it with Docker.

Containers

So, what’s a container and why would you want to use one? You can think of a container here the exact same way you think of containers on a shipping barge. On that barge is a bunch of shipping containers, and inside each shipping container is a bunch of packages. The barge itself is your computer (or your cloud environment), and the shipping containers house your applications.

It may also help to think of them as smaller, more lightweight incarnations of virtual machines. While a virtual machine virtualizes the machine’s physical hardware through the use of a hypervisor, a container virtualizes only the operating system. A virtual machine is usually several gigabytes in size, whereas a container is usually less than a gigabyte. The small size and speed of deployment as compared to a traditional virtual machine has given rise to the popularity of designing applications as collections of microservices (several single-purpose services running in containers that, when working together, make up your complete application) instead of monoliths (all of your application code and services running as a single unit, often within a single file).

Deploying your application using containers allows you to package your application code alongside everything required to run it, including its dependencies and an operating system. You know how sometimes you hand code off to someone else, but it doesn’t run for them, so you go “Well, it works on my machine,” and just shrug? Using a container is pretty similar to just deploying your machine. The most popular container engine today is Docker, so that’s what we’ll be using today.

Prerequisites:

Docker
Python3

Before we go into containerizing and deploying our website, let’s make it a little bit more useful. For this, we’re going to be using Flask, a lightweight web framework for Python. Fork and clone this GitHub repository to get the full sample code for part two of this series.

Expanding the Website

Our file structure gets more complicated now that we are building a more dynamic website with server-side routing and throwing it into a Docker container. You will have something like this:

container-tutorial
├── Pulumi.yaml
├── requirements.txt
├── __main__.py
└── website
├── Dockerfile
├── requirements.txt
└── app
├── server.py
├── static
│ ├── normalize.css
│ ├── style.css
│ └── background.jpg
└── templates
├── base.html
├── index.html
├── portfolio.html
└── about.html

Everything contained within the app directory is the website itself. We now have server-side routing, and a few different pages. To run it locally and see what the new website looks like, pip3 install flask to install the Flask web framework and then run python3 server.py from the app directory. Flask will return an IP address where your website is running; navigate there in your browser and click around a bit!

server.py

from flask import Flask, render_template

app = Flask(__name__)

@app.route("/")
def home():
 return render_template("index.html")

@app.route("/about")
def about():
 return render_template("about.html")

@app.route('/portfolio')
def portfolio():
 return render_template("portfolio.html")


if __name__ == '__main__':
 app.run(host='0.0.0.0', port=80, debug=True)

Where before our entire website was made up of a single HTML file, we now have several, and we’re using Flask to handle the routing between them. In this server file, three routs are defined: home, about, and portfolio. Flask handles serving these up for us, and associating a route with a particular HTML file. This way, we get a nice www.mywebsite.com/about URL instead of something like www.mywebsite.com/about.html. Building a website this way also means we have the ability to apply some logic to each of these routes, such as adding database interaction, user login, and passing conditional variables from the server to the templates that will be rendering each page. We aren’t doing any of that yet, but we will!

At the bottom, we’re binding the Flask application to 0.0.0.0:80. You can change that to any other unoccupied local IP address and port you like.

Templating

Flask can make use of a templating engine called Jinja2 to make adding pages to your website a bit less repetitive. You start with one template, in this case called base.html, that contains any HTML you want to exist on every single page.

base.html

<!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title>Hello world!</title>
 <link rel="stylesheet" href={{ url_for('static', filename='style.css') }}>
 <link rel="stylesheet" href={{ url_for('static', filename='normalize.css') }}>
</head>
<body>
 <header>
 <div class="logo"><i class="fas fa-cat"></i></div>
 <nav>
 <ul>
 <li {% if request.path == url_for('home') %} class="active" {% endif %}>
 <a href="{{ url_for('home') }}">Home</a>
 </li>
 <li {% if request.path == url_for('about') %} class="active" {% endif %}>
 <a href="{{ url_for('about') }}">About</a>
 </li>
 <li {% if request.path == url_for('portfolio') %} class="active" {% endif %}>
 <a href="{{ url_for('portfolio') }}">Portfolio</a>
 </li>
 </ul>
 </nav>
 <ul class="social">
 <li><a href="http://github.com/katcosgrove" target="_blank"><i class="fab fa-github-alt"></i></a></li>
 <li><a href="http://twitter.com/Dixie3Flatline" target="_blank"><i class="fab fa-twitter"></i></a></li>
 <li><a href="http://linkedin.com/in/katcosgrove" target="_blank"><i class="fab fa-linkedin-in"></i></a></li>
 </ul>
 </header>
{% block content %}{% endblock %}
</body>
<script src="https://kit.fontawesome.com/b4747495ea.js" crossorigin="anonymous"></script>
</html>

This file includes some metadata, stylesheets, the header, navigation, and any Javascript we want to link in. All of the content in this file will exist on every page. Below the header, in the body, you’ll see {% block content %} {% endblock %}. That’s where additional, page-specific content will be added.

index.html

{% extends 'base.html' %}

{% block content %}

<div class="content">
 <h1>Your Name</h1>
 <h3>Job Title at Company</h3>
</div>

{% endblock %}

This is all that exists in our index.html now. The first directive tells Jinja2 that this bit of HTML goes in the base.html template, and the remaining two wrap the content we want to insert. The same thing is happening in about.html and portfolio.html. Neat, right? Jinja2 is not unique to Flask, so you can use this templating engine with another web framework if you prefer.

While we could deploy this as-is, it’s a bit unwieldy. Let’s wrap it up into a container.

Dockerizing our Website

In the website directory, we have something called a Dockerfile. Dockerfiles tell the Docker engine what to do with your application, how your container should behave with respect to the wider internet or other containers, and what needs to be done inside of the container for your application to run. Ours looks like this:

FROM ubuntu:20.04

COPY app /app

WORKDIR /app

EXPOSE 80

RUN apt-get update && \
 apt install -y gcc python3-dev python3-pip python-markupsafe

COPY requirements.txt /app

RUN pip3 install -r requirements.txt

ENTRYPOINT [ "python3" ]

CMD [ "server.py" ]

This Dockerfile says that our container should be running ubuntu:20.04 as its operating system. It will pull the Ubuntu image from Docker Hub, their public image registry, though you can pull from another registry here as well. The COPY directive moves our website’s files (the app directory) into the container. We then set our working directory for all future commands run inside of the container to /app to reduce the amount of typing we have to do later on, update Ubuntu, and install some dependencies using both apt and from the requirements.txt file we also copy over. Lastly, an entrypoint and command to actually start our application are defined. There is a slightly less verbose way to start the application, but this way of defining an ENTRYPOINT and CMD is fairly common, so it’s worth seeing here.

To see this run locally, we first need to build and tag the image. From the same directory as your Dockerfile, run the following command:

docker build --tag container-tutorial:latest .

We are calling the docker CLI, telling it we want to build a container, and indicating that we want to tag it at the same time. The tag isn’t strictly necessary for the container to run, but it does make the container easier to identify and interact with. We’re also assigning it a version of latest. Note the trailing dot at the end of the command, which is the part of the command that indicates the location of the Dockerfile we want to build.

Run docker images to see a list of all images you have built. Something like this should be in the list:

cloud-systems latest 0ce569ac0360 10 days ago 408MB

Now the container is built, we need to run it and forward the container’s port to a local port so we can see our site.

docker run -d -p 80:80 container-tutorial

There’s a lot going on in that command, so let’s take a closer look. the -d flag is short for --detach, and it tells the Docker engine that we want to print the container’s ID and run it in the background. The -p flag is short for --publish, and it tells the Docker engine to publish the container’s port to the host. In this case, port 80.

Run docker ps to get a list of all running containers, and you’ll see something like this:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f95362faf3cd container-tutorial "python3 server.py" 7 days ago Up 7 days 0.0.0.0:80->80/tcp, :::80->80/tcp affectionate_jackson

That’s our website! You can see the container ID, the image tag, the commands that ran for it to start the application, its host, the container port, and the port it forwarded to. Go to localhost in your browser, and the website is up!

We’re hosting this locally, though. It’s not accessible by the wider internet, and even if it was, our machines would be dealing with all of the traffic. There’s nothing in place to distribute traffic or restrict access. Worry not, cloud services exist for that, too. In the next in this series, we’ll take our containerized website and deploy it to AWS Elastic Container Service, complete with AWS networking configuration, IAM roles, and AWS Fargate!

Cloud Systems: Static Sites and AWS S3

Kat Cosgrove — Wed, 15 Dec 2021 00:00:00 +0000

The simplest website you can build is a static site. That means no web server, just HTML, CSS, and maybe some front-end JavaScript. Static sites can still be beautiful and interactive though, and for many people, they’re more than enough.

Amazon S3 (Simple Storage Service) is an AWS service that provides cloud storage for files, stored as objects in buckets. You can think of it like an external harddrive: plug it into your computer, and you have more storage space for your files, photos, and movies that you can unplug at will and move to another computer. An S3 bucket behaves very similarly in that you can throw just about anything in it, from data lakes to images to logs, and connect it to an application. This also means that you can use it to host a static website! Let’s look at how.

Prerequisites:

An AWS account
Pulumi account
Pulumi installed and configured for AWS
Python3
NodeJS (optional if you want to preview the site locally)

There are a lot of ways to provision an S3 bucket and set its permissions, but for this I’m going to use Pulumi, an Infrastructure as Code tool that allows you to provision, configure, and deploy a variety of cloud services and tools programmatically, without learning a new language. That way, we can stay in our code, and the syntax will be more familiar for developers. It also saves us the headache of going through the AWS Console. All of the code for this, both the website and the infrastructure code, can be found in the GitHub repository for the series, although I’ll be walking you through everything here too.

Building a Static Site

Create a new directory called s3-tutorial and navigate into it. From there, run pulumi new python -y to create a new Pulumi project using Python. You’ll see Pulumi create a few files for you, but the one we’ll be touching is __main__.py.

Before we move on, we need to build out our website. Create a subdirectory and call it website. In that directory, add index.html, style.css, and normalize.css.

This one is built using only HTML and CSS, plus one background image file. Replace the name and bio with your own, as well as the social links in the header.

index.html

<!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title>Hello world!</title>
 <link rel="stylesheet" href="style.css">
 <link rel="stylesheet" href="normalize.css">
</head>
<body>
 <header>
 <div class="logo"><i class="fas fa-cat"></i></div>
 <ul class="social">
 <li><a href="http://github.com/katcosgrove" target="_blank"><i class="fab fa-github-alt"></i></a></li>
 <li><a href="http://twitter.com/Dixie3Flatline" target="_blank"><i class="fab fa-twitter"></i></a></li>
 <li><a href="http://linkedin.com/in/katcosgrove" target="_blank"><i class="fab fa-linkedin-in"></i></a></li>
 </ul>
 </header>
<div class="banner">
 <h1>Your Name</h1>
 <h3>Job Title at Company</h3>
 <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam blandit tristique arcu, sed commodo ligula. Ut ullamcorper velit non luctus mollis. Sed placerat quam sed tellus aliquam, ac eleifend quam lacinia. Praesent bibendum velit at metus auctor, vitae feugiat quam luctus. Morbi eu imperdiet metus, et tincidunt tellus. Aliquam non ullamcorper justo. Cras ornare nulla vel pellentesque vulputate. Mauris in elit neque. Aliquam tempor aliquam libero, elementum luctus nisl imperdiet sit amet. Praesent urna ante, scelerisque non tellus mollis, laoreet sodales felis.</p>
</div>
</body>
<script src="https://kit.fontawesome.com/b4747495ea.js" crossorigin="anonymous"></script>
</html>

style.css

@import url('https://fonts.googleapis.com/css?family=News+Cycle|Teko&display=swap');

ul {
 list-style-type: none;
}

ul li {
 display: inline-block;
}

a {
 color: white;
 -webkit-transition: color .5s ease-out;
 transition: color .5s ease-out;
 text-decoration: none;
}

a:hover, a:active {
 color: rgb(255, 157, 112);
}

header {
 background-color: rgba(0, 0, 0, .8);
 height: 80px;
 position: absolute;
 top: 0;
 width: 100%;
}

header li {
 color: white;
}

.active a {
 color: rgb(255, 157, 112);
}

.social {
 position: absolute;
 right: 50px;
 top: -5px;
 font-size: 30px;
}

.social li {
 margin: 0 5px 0 5px;
}

.logo {
 position: absolute;
 left: 10px;
 margin-left: 20px;
 font-size: 60px;
 color: white;
}

body {
 background: url('./background.jpg');
 background-size: cover;
 background-repeat: no-repeat;
}

.banner {
 width: 60vw;
 font-family: Teko;
 font-size: 2vw;
 text-align: center;
 margin-top: 15vw;
 margin-left: 20vw;
}

.banner p {
 font-family: News Cycle;
}

Your normalize.css can be copied from this repository, and the expected background.jpg can be downloaded from this repository.

To see what this looks like before we deploy it, we’re going to use a tool called live-server. This isn’t a real, functional webserver, but it’s a useful tool during development for static websites. It will reload automatically when a change is detected, so you don’t have to wait for deploys.

Install it with this:

npm install -g live-server

And run it from the same directory as your index.html file:

live-server

Your browser should automatically open to localhost:8080, but if it doesn’t, navigate there yourself and you’ll see your website.

Configuring an S3 Bucket

It’s time to deploy this thing to S3. From your project’s root, run source venv/bin/activate to make sure we’re in a virtual environment, and run pip3 install pulumi-aws. From now on, we’ll be working in __main__.py

For imports, we need the following:

import json
import mimetypes
import os

from pulumi import export, FileAsset
from pulumi_aws import s3

We’re going to be reading files from the operating system and working with JSON, so we need the first three packages from the standard Python library. We’re also going to be using Pulumi. You will already have the pulumi package installed, but we also need the AWS provider, which we just installed.

web_bucket = s3.Bucket('s3-website-bucket',
 website=s3.BucketWebsiteArgs(
 index_document="index.html",
 ))

Here, we are instantiating an s3 Bucket object and assigning it to the web_bucket variable. S3 buckets are capable of hosting websites, but we have to tell the bucket that’s what it’s going to be doing and what it should expect the index document to be called. Ours is just called index.html.

content_dir = "website"
for file in os.listdir(content_dir):
 filepath = os.path.join(content_dir, file)
 mime_type, _ = mimetypes.guess_type(filepath)
 obj = s3.BucketObject(file,
 bucket=web_bucket.id,
 source=FileAsset(filepath),
 content_type=mime_type)

This codeblock defines our content directory (the website folder containing your site files, from earlier) and reads each of them in, before creating using the Pulumi AWS module to create an S3 bucket object for that file. We are also including a little bit of metadata for each file.

def public_read_policy_for_bucket(bucket_name):
 return json.dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Effect": "Allow",
 "Principal": "*",
 "Action": [
 "s3:GetObject"
 ],
 "Resource": [
 f"arn:aws:s3:::{bucket_name}/*",
 ]
 }]
 })

This function sets some permissions for our bucket. Since this should be publicly-accessible, we need to allow anyone the ability to read the files.

bucket_name = web_bucket.id
bucket_policy = s3.BucketPolicy("bucket-policy",
 bucket=bucket_name,
 policy=bucket_name.apply(public_read_policy_for_bucket))

Now we assign the ID of our bucket as the bucket’s name, then create a policy for it that includes its name and the policy we defined in the previous step. We’re almost done!

export('bucket_name', web_bucket.id)
export('website_url', web_bucket.website_endpoint)

These last two lines are using Pulumi to export some data for us to interact with. The first is the ID of the bucket so we know which one we’re working with, and the second is the website endpoint created by S3 once the bucket is online, so we know where to go to see our site!

Deploying

All that’s left to do is deploy! From your project’s root directory, define the AWS region you want to work in by running pulumi config set aws:region us-west-2, then run pulumi up!

Pulumi will first give you an overview of the expected changes and ask if you want to perform the update. In my case, it looks like this:

 Type Name Plan
 + pulumi:pulumi:Stack static-site-s3-dev create
 + ├─ aws:s3:Bucket s3-website-bucket create
 + ├─ aws:s3:BucketObject index.html create
 + ├─ aws:s3:BucketObject style.css create
 + ├─ aws:s3:BucketObject normalize.css create
 + ├─ aws:s3:BucketObject background.jpg create
 + └─ aws:s3:BucketPolicy bucket-policy create

Resources:
 + 7 to create

Do you want to perform this update? [Use arrows to move, enter to select, type to filter]
> yes
 no
 details

If everything goes smoothly, you’ll see more feedback from Pulumi showing each resource that was created:

 Type Name Status
 + pulumi:pulumi:Stack static-site-s3-dev created
 + ├─ aws:s3:Bucket s3-website-bucket created
 + ├─ aws:s3:BucketObject index.html created
 + ├─ aws:s3:BucketObject style.css created
 + ├─ aws:s3:BucketObject normalize.css created
 + ├─ aws:s3:BucketObject background.jpg created
 + └─ aws:s3:BucketPolicy bucket-policy created

Outputs:
 bucket_name: "s3-website-bucket-89f0341"
 website_url: "s3-website-bucket-89f0341.s3-website-us-west-2.amazonaws.com"

Resources:
 + 7 created

Duration: 6s

Notice the Outputs section there. Those are the two things we exported at the very end of our __main__.py: the ID of the bucket, and the website URL. Click on the website URL, and you’ll see your personal site, deployed to AWS S3 and publicly accessible by anyone! If you don’t want to keep this up, run pulumi destroy to tear down all of these resources, and you’re done!

We’re not quite done yet, though—this site is a little slow, and it’s not very interactive. Maybe we want some kind of database associated with it, or the convenience of containers, or the scalability of Kubernetes. Stay tuned for the next tutorial in this series, where we’ll keep building on this website to introduce more modern cloud engineering tools until it looks like something you’d happily call production!