Deploy Docker to EC2: Pull Request Environments [Part 1]

In This Series: Deploy Docker to EC2

Deploy Docker to EC2: Pull Request Environments [Part 1]
Deploy Docker to EC2: Root Domain Deploy [Part 2]

In this series, we will show you how to create a deployment (and destroy it) in the same repo. That way, you can have a working deployment set up for the PR and destroyed once it’s ready to merge.

Let's get started!

If you’re new to the Deploy Docker to EC2 GitHub Action, check out this post.

Quick Start Video

Prerequisites

A working Docker deployment. (Your files + docker-compose.yaml, optionally a Dockerfile)
AWS Account

We will assume you already have a running Github action and there is no need to create a new workflow. If you do not have a running workflow, check the first blog for these series!

For more details on hooking up Docker for your app, check out our Academy post: Learn Docker

Pull-Request Based Environments

The idea is to set up deployments of testing environments based on a PR , allowing you to run the tests you need, or do what you need to do with your changes before merging them into the main branch .

Github Workflows have a few trigger options, including: Manual, Change to PR, and Change to branch, among others. In this blog, we will work with pull requests .

If automated pull request environments in your own cloud provider sound like something you or your team could use, you’re in luck. Creating a temporary instance to test out pull requests is easy with our docker-to-ec2 action!

With the two workflows below, you can spin up a temporary instance when a pull request is created and have it automatically destroyed after the pull request is merged. This ensures that your main branch is always up to date with tested code and ensures that any issues with the code are picked up and resolved during the testing phase.

For more possible triggers, you can read the Gihub Actions documentation on event triggers.

🔥 Once merged, this PR environment will get destroyed!

Keep in mind the naming convention. As long as you don’t hard-code any name (more on that here), each identifier will be both easy to understand and mostly unique (most of the times), hence your main instance will stay up while you work in your test instance.

Summary of Work

To start using PR environments, all you need are two files:

Create a deploy-pr workflow file that will generate a testing environment
Create a destroy-pr workflow file that will take care of cleaning up AWS resources

1. Deploy-pr workflow file:

First, set up the deployment workflow file under your repository’s .github/workflows directory.

.github/workflows/deploy-pr.yaml

name: Deploy-PR
on:
  pull_request:
    branches: [ main ]

permissions:
  contents: read
jobs:
  EC2-Deploy:
    # if the branch name of the PR does not contain 'skip-deploy'
    if: "!contains(github.head_ref, 'skip-deploy')"
    runs-on: ubuntu-latest
    environment:
      name: ${{ github.ref_name }}
      url: ${{ steps.deploy.outputs.vm_url }}
    steps:
      - id: deploy
        name: Deploy
        uses: bitovi/github-actions-deploy-docker-to-ec2@v0.4.5
        with:
          aws_access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID}}
          aws_secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY}}
          aws_default_region: us-east-1
          app_port: 3000

Note that the workflow is the same as the workflow shown in our earlier blog series.

Only change here is that we are changing on pushes to main to on pull_requests to main

The above workflow also allows you to include skip-deploy in any branch name to ensure a PR environment is not created for that branch.

2. Destroy-pr workflow file:

To destroy the PR environments, you’ll need another workflow that triggers the workflow when a PR is closed.

Note that the workflow is the same as the workflow above,except that on → pull_request → is set to closed and stack_destroy / tf_state_bucket_destroy inputs are set to true in the steps.

This step is important to mitigate high AWS costs so you’re not paying for what you’re not using.

.github/workflows/destroy-pr.yaml

name: Destroy-PR

on:
  pull_request:
types: [ closed ]

permissions:
  contents: read
  
jobs:
  EC2-Destroy:
    # if the branch name of the PR does not contain 'skip-deploy'
    if: "!contains(github.head_ref, 'skip-deploy')"
    runs-on: ubuntu-latest
    environment:
      name: ${{ github.ref_name }}
      url: ${{ steps.deploy.outputs.vm_url }}
    steps:
      - id: destroy
        name: Destroy
        uses: bitovi/github-actions-deploy-docker-to-ec2@v0.4.5
        with:
          aws_access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID}}
          aws_secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY}}
          aws_default_region: us-east-1
         app_port: 3000
         stack_destroy: true
         # Uncomment this to delete the bucket used to store Terraform state files
         # tf_state_bucket_destroy: true

Now you’re on your way to Platform Engineering by allowing quick iterative development on your projects through PR Environments with the Deploy Docker to EC2 GitHub Action.

Need Help?

Drop into Community Discord and let us know! Bitovians (and our community) love to solve problems and chat about exciting projects.

Need DevOps Consulting or Platform Engineering services ? Bitovi has DevOps consultants who can assist with all aspects of your development and DevOps journey.