https://github.com/byu-oit/hw-fargate-api
Template for creating a product specific repo with terraform files for deployment
https://github.com/byu-oit/hw-fargate-api
devops template
Last synced: 2 months ago
JSON representation
Template for creating a product specific repo with terraform files for deployment
- Host: GitHub
- URL: https://github.com/byu-oit/hw-fargate-api
- Owner: byu-oit
- License: apache-2.0
- Created: 2020-02-14T01:06:55.000Z (almost 6 years ago)
- Default Branch: prd
- Last Pushed: 2025-03-01T01:02:27.000Z (12 months ago)
- Last Synced: 2025-03-01T02:18:48.206Z (12 months ago)
- Topics: devops, template
- Language: HCL
- Homepage:
- Size: 13.1 MB
- Stars: 5
- Watchers: 24
- Forks: 0
- Open Issues: 16
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# hw-fargate-api
Example of creating and deploying an containerized API onto AWS Fargate with OpenTofu
## Prerequisites
* Install [OpenTofu](https://opentofu.org/docs/intro/install/)
* Install the [AWS CLI](https://aws.amazon.com/cli/)
* Log into your `dev` account (with [`aws sso login`](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sso/login.html))
* Ensure your account has a [Terraform/OpenTofu State S3 Backend](https://github.com/byu-oit/terraform-aws-backend-s3) deployed
## Setup
* Create a new repo [using this template](https://github.com/byu-oit/hw-fargate-api/generate).
You need your own repo so that you can push changes and have GitHub Actions deploy them.
Keep your repo name relatively short. Since we're creating AWS resources based off the name, we've seen [issues with repo names longer than about 24 characters](https://github.com/byu-oit/hw-fargate-api/issues/22).
* Clone your new repo
```sh
git clone https://github.com/byu-oit/my-new-repo
```
* Check out the `dev` branch
```sh
cd my-new-repo
git checkout -b dev
```
* Find and replace across the repo:
* replace `977306314792` with your `dev` AWS account number
* replace `539738229445` with your `prd` AWS account number
* replace `hw-fargate-api` with the name of your repo
* replace `byu-oit-terraform-dev` with the name of your `dev` AWS account
* replace `byu-oit-terraform-prd` with the name of your `prd` AWS account
* replace `Codepipeline-Standard-Change` with your [Standard Change Template ID](https://it.byu.edu/nav_to.do?uri=%2Fu_standard_change_template_list.do) - If you need to create a new template, ask in [the ServiceNow channel](https://teams.microsoft.com/l/channel/19%3a75c66bbd4d2646fea0df336abb5723ca%40thread.tacv2/OIT%2520ENG%2520AppEng%2520-%2520ServiceNow?groupId=54688770-069e-42a2-9f77-07cbb0306d01&tenantId=c6fc6e9b-51fb-48a8-b779-9ee564b40413) for help getting it into the [sandbox ServiceNow environment](https://support-test.byu.edu/)
* _Rename_ [`.postman/hw-fargate-api.postman_collection.json`](.postman/hw-fargate-api.postman_collection.json) with the name of your repo replacing `hw-fargate-api` in the filename
* Add yourself (or your team) as a [Dependabot reviewer](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#reviewers) in [`dependabot.yml`](.github/dependabot.yml)
* Enable [Dependabot Security updates](https://github.com/byu-oit/hw-fargate-api/settings/security_analysis) if you're outside the [`byu-oit` GitHub organization](https://github.com/byu-oit)
* Commit your changes
```sh
git commit -am "Update template with repo specific details"
```
## Deployment
### Deploy the "one time setup" resources
```sh
cd iac/setup/
tofu init -var-file=dev.tfvars
tofu apply -var-file=dev.tfvars
```
In the AWS Console, see if you can find the resources from `setup.tf` (ECR, SSM Param, IAM Role).
### Set up Teams notifications
* Create an Incoming Webhook in Teams, following [these instructions](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook#create-an-incoming-webhook), and copy the URL
* Create a GitHub secret `MS_TEAMS_WEBHOOK_URL` using the copied URL (e.g. at https://github.com/byu-oit/hw-fargate-api/settings/secrets/actions/new)
### Push your changes
```sh
git push -u origin dev
```
If you look at [`.github/workflows/deploy.yml`](.github/workflows/deploy.yml), you'll see that it is set up to run on pushes to the `dev` branch. Because you pushed to the `dev` branch, this workflow should be running now.
* In GitHub, click on the workflow run (it has the same name as the last commit message you pushed)
* Click on the `Build and Deploy` job
* Expand any of the steps to see what they are doing
### View the deployed application
Anytime after the `Tofu Apply` step succeeds:
```sh
cd ../app/
tofu output
```
This will output a DNS Name. Enter this in a browser. It will probably return `503 Service Unavailable`. It takes some time for the ECS Tasks to spin up and for the ALB to recognize that they are healthy.
In the AWS Console, see if you can find the ECS Service and see the state of its ECS Tasks. Also see if you can find the ALB Target Group, and notice when Tasks are added to it.
> **Note**
>
> While OpenTofu creates the ECS Service, it doesn't actually spin up any ECS Tasks. This isn't OpenTofu's job. The ECS Service is responsible for ensuring that ECS Tasks are running.
>
> Because of this, if the ECS Tasks fail to launch (due to bugs in the code causing the docker container to crash, for example), OpenTofu won't know anything about that. From OpenTofu's perspective, the deployment was successful.
>
> These type of issues can often be tracked down by finding the Stopped ECS Tasks in the ECS Console, and looking at their logs or their container status.
Once the Tasks are running, you should be able to hit the app's URL and get a JSON response. Between `index.js` and `main.tf`, can you find what pieces are necessary to make this data available to the app?
In the AWS Console, see if you can find the other resources from `main.tf`.
### Push a change to your application
Make a small change to `index.js` (try adding a `console.log`, a simple key/value pair to the JSON response, or a new path). Commit and push this change to the `dev` branch.
```sh
git commit -am "try deploying a change"
git push
```
In GitHub Actions, watch the deploy steps run (you have a new push, so you'll have to go back and select the new workflow run instance and the job again). Once it gets to the CodeDeploy step, you can watch the deploy happen in the CodeDeploy console in AWS. Once CodeDeploy says that production traffic has been switched over, hit your application in the browser and see if your change worked. If the service is broken, look at the stopped ECS Tasks in the ECS Console to see if you can figure out why.
> **Note**
>
> It's always best to test your changes locally before pushing to GitHub and AWS. Testing locally will significantly increase your productivity as you won't be constantly waiting for GitHub Actions and CodeDeploy to deploy, just to discover bugs.
>
> You can either test locally inside Docker, or with Node directly on your computer. Whichever method you choose, you'll have to setup the environment variables that ECS makes available to your code when it runs in AWS. You can find these environment variables in `index.js` and `main.tf`.
## Learn what was built
By digging through the `.tf` files, you'll see what resources are being created. You should spend some time searching through the AWS Console for each of these resources. The goal is to start making connections between the OpenTofu syntax and the actual AWS resources that are created.
Several OIT created Terraform/OpenTofu modules are used. You can look these modules up in our GitHub Organization. There you can see what resources each of these modules creates. You can look those up in the AWS Console too.
## Deployment details
There are a lot of moving parts in the CI/CD pipeline for this project. This diagram shows the interaction between various services during a deployment.
