Serverless FastAPI Deployment: Actions Speak Louder Than Words

The final chapter of the Serverless FastAPI app tetralogy has arrived, we started with developing our app locally, then we wrote tests and in the last chapter we used native tooling and services within AWS to secure our app from bad actors.

We’ve reached a fork in the road, we can continue to manually deploy our app by running commands locally or we can incorporate a more traditional approach to automatically test and deploy our app using a CI/CD pipeline.

I initially wanted to use Azure Pipelines, that’s what I have been using at work daily for the past 6 years. I appreciate Azure DevOps, lovely platform.

- Cristiano Ronaldo voice (Infamous rant about nothing changing at Man Utd)

To change things up, I then thought why not use GitHub Actions ? The infrastructure and application code already exists in GitHub.

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

- GitHub

Adding GitHub as an identity provider

We have identified GitHub Actions as the platform to implement our CI/CD pipeline, before we begin we need to setup an authenticated connection between GitHub and AWS. We will achieve this by setting up GitHub as an identity provider within AWS IAM.

1. Navigate towards IAM in the AWS management console, select Identity providers under Access management.
2. Select Add provider.
3. Select OpenID Connect under Provider type.
4. Enter https://token.actions.githubusercontent.com under Provider URL.
5. Enter sts.amazonaws.com under Audience.
6. Select Add provider.

Creating a custom IAM policy

Next up is defining the permissions for an IAM role, we’ll go for an approach that best aligns with the principle of least privilege.

1. Select Policies under Access management.
2. Select Create policy.
3. In the Policy editor, select the JSON button.
4. Replace the contents within the editor with the below JSON:
5. Select Next.
6. Enter GitHubActionsDeploymentPolicy under the Policy name.
7. Select Create policy.

Creating an IAM role

(IAM) roles are entities you create and assign specific permissions to that allow trusted identities such as workforce identities and applications to perform actions in AWS. When your trusted identities assume IAM roles, they are granted only the permissions scoped by those IAM roles. Using IAM roles is a security best practice because roles provide temporary credentials that do not need to be rotated.

- Amazon Web Services

1. Select Roles under Access management.
2. Select Create role.
3. Select Web identity under Trusted entity.
4. Select token.actions.githubusercontent.com as the identity provider under Web identity.
5. Select sts.amazonaws.com as the audience.
6. The input box for GitHub organization also supports personal GitHub accounts, feel free to enter your GitHub username.
7. Enter the name of the GitHub repository you are using for this app. Select Next.
8. Search for and select the policy we created earlier (“GitHubActionsDeploymentPolicy”). Select Next.
9. Provide a name for the role, i.e GitHub-Actions-Assume-Role
10. Scroll to the bottom of the page and select Create role.
11. Copy the arn for the role to your clipboard, you’ll need this later.

Creating our first GitHub Actions workflow

1. Navigate towards your GitHub repo.
2. Select settings, select secrets and variables, select Actions.
3. Select New repository secret, enter ROLE_TO_ASSUME as the name and enter the arn for the role you copied earlier as the Secret.
4. Open your project in Visual Studio Code (or your IDE of choice) and create a new branch.
5. Create the following directories and files inside the project directory:

6. Edit the deploy.yml file and add the following code:

At a high level, the deploy.yml file contains 2 jobs, a job to run tests and a job to deploy the app. The Deploy job is dependent on the previous job Test passing. The role-to-assume references the arn we stored as a repository secret earlier on.

7. Commit the changes and publish the new branch.
8. Navigate towards your repo in GitHub, select the Pull requests tab, select Compare & pull request.
9. Select Create pull request.
10. Navigate towards the Actions tab, you should see the workflow running. You can review the logs to see the progress. If successful you’ll see 2 endpoint URLs.

Destroying the cdk stack via GitHub Actions

We’ve seen how our app is deployed using the deploy.yml workflow, we’ll now create a workflow to delete the CDK stack, it prompts the user for confirmation first before initiating the stack deletion.

1. Navigate back towards your IDE, select the destroy.yml file and add the following code:

2. Commit the changes and push the changes.
3. Navigate towards the Actions tab in your browser, you should currently see the Deploy Player FC API workflow that previously ran, navigate towards the main Actions to see all workflows.
4. You’ll see the newly created Destroy Player FC CDK Stack workflow, select the workflow, select the Run workflow dropdown, enter y to initiate the destruction of the CDK stack.

We now have a complete CI/CD pipeline that automatically tests our FastAPI app and deploys it to AWS. You can use this foundation to extend the workflows further or add additional deployment stages.