DevOps the Hard Way: Intro
With this blog now set up and running, the next project to cover will be DevOps the Hard Way (GitHub link).
What is it?
In the author’s own words, the labs in this repository involve setting up “an entire workflow and DevOps environment from a real-world perspective in AWS.” The result will be a simulated DevOps workflow centered around an Uber API, complete with automated testing and CI/CD.
Here’s an overview of the topics covered:
- AWS
- GitHub
- Python
- Terraform
- Docker
- Kubernetes
- CI/CD
- Automated testing
Going through the labs in order, Labs 1-3 aren’t particularly worth detailing in their own posts; I’ll provide a quick outline of them below and move on to more detailed posts.
Outline of Labs 1-3:
1. Fulfill Prerequisites
The prerequisites listed are:
- Have prior knowledge in tech
- Have or create AWS and GitHub accounts
- Set up the AWS CLI, VSCode, Terraform, and Docker Desktop
I already had the required accounts and most of the software listed above. All installations listed are trivial.
2. Create the VPC
This step simply involves running a standard CloudFormation template* provided by AWS, which creates a VPC designed for use in an Elastic Kubernetes Service (EKS) environment.
Note: this template creates NAT gateways on AWS, which as of this writing, are priced to incur an hourly cost for as long as they exist.
Per AWS:
If you no longer wish to be charged for a NAT gateway, simply delete your NAT gateway using the AWS Management Console, command line interface, or API.
Similarly, there are other resources in this lab that will incur costs even if left unused after deployment, so be aware if following along.
3. Configure AWS credentials
This was already done in my environment. AWS recommends short-term, auto-refreshing credentials for users of their CLI (and in general, as best security practice). They detail CLI credential configuration here.
In the next post, the Terraform CLI will used to create an AWS S3 bucket, which will serve as a centralized back-end for Terraform’s own configuration data.