The promotion reported seven steps, all green. Kargo cloned the repository, rewrote the image tag, committed, pushed a branch, opened a merge request, waited for me to approve it, and told ArgoCD to sync. ArgoCD said Synced. ArgoCD said Healthy.

The pod was running the previous image.

Nothing had failed. No error appeared anywhere in the chain. Every dashboard I had built specifically to catch this said the system was working, and the system was not working.

That failure, and eight or nine others like it, is what I actually want to write about. The architecture is the least interesting part of this project. You can read a hundred posts describing an EKS platform with ArgoCD and GitOps. What you can’t easily find is a list of the things that break in ways that produce no error, and how you notice.

What I built, briefly 🔥

Over three days I built a four-tier EKS platform with an enforced software supply chain. The short version:

• Terraform and Terragrunt for infrastructure, modular, with tiers as thin overrides. Adding a tier is four files averaging twenty lines.
• ArgoCD in an app-of-apps pattern. Terraform creates exactly one Kubernetes object; the root Application and everything after that is reconciled from git.
• GitLab CI building a hardened multi-stage image: FIPS-mode Go on a distroless static base, 7.5 MB, no shell, no package manager, no libc.
• Trivy and Kubescape as blocking gates, syft for SBOMs, cosign signing with an AWS KMS key.
• Kyverno verifying those signatures at admission, in Enforce mode, and rewriting image tags to the verified digest.
• Kargo promoting images between tiers by opening merge requests.
• Velero for backups, Coroot for eBPF observability, Pod Security Admission and NetworkPolicy for workload isolation.

No long-lived cloud credentials anywhere. IRSA for everything in-cluster, GitLab OIDC for CI. The only stored secrets are GitLab tokens in AWS Secrets Manager, pulled at runtime by External Secrets.

All of it built and broken in a development cluster costing about seven dollars a day, destroyed and rebuilt daily.

That last point turns out to be the whole argument, and I’ll come back to it.

Failure one: the promotion that changed nothing

Back to the green promotion.

The cause was two images: entries in a Kustomize overlay. My base Deployment used a short alias:

image: my-app

with the overlay mapping it to the real registry path:

images:
  - name: my-app
    newName: <account>.dkr.ecr-fips.us-east-1.amazonaws.com/dsp-shared/my-app
    newTag: 7fffedb8

Kargo’s kustomize-set-image step doesn't know about that indirection. It writes an entry keyed on the full registry path:

images:
  - name: <account>.dkr.ecr-fips.us-east-1.amazonaws.com/dsp-shared/my-app
    newTag: 7481984b        # Kargo's edit
  - name: my-app
    newName: <account>.dkr.ecr-fips.us-east-1.amazonaws.com/dsp-shared/my-app
    newTag: 7fffedb8        # the original, which wins

Two entries, both valid, both matching nothing the other matched. Kustomize applied the second. Kargo had done exactly what it was asked. ArgoCD had synced exactly what git contained. The deployed image never changed.

The fix was making the base reference the full path so both tools key on the same string. The lesson was the diagnostic:

kubectl kustomize apps/my-app/overlays/dev | grep "image:"

One line, one tag. Run it before merging a promotion. And after the promotion completes, check the pod rather than the promotion:

kubectl -n my-app get pod -o jsonpath='{.items[0].spec.containers[0].image}'

Green statuses are a claim about process. The running image is a fact.

Failure two: ArgoCD reported Synced while refusing to deploy

This one I caused myself, trying to fix something cosmetic 😢.

Kyverno’s mutateDigest rewrites an image reference at admission so what runs is provably the bytes that passed signature verification:

my-app:7481984b@sha256:095729a0c4e28cf2c331645514718628a91ef06...

Git has only the tag. ArgoCD compares live to desired, sees a difference it can never reconcile, and reports OutOfSync forever. Worse, selfHeal keeps trying to strip the digest that Kyverno keeps re-adding, resulting in two controllers quietly fighting over one field.

The obvious fix is to tell ArgoCD to ignore that field:

ignoreDifferences:
  - group: apps
    kind: Deployment
    jqPathExpressions:
      - '.spec.template.spec.containers[].image'

That works and then boom, the Application goes green.

It also means ArgoCD can no longer see legitimate image changes. When Kargo updated the tag in git, ArgoCD compared the live Deployment to the desired one, found no difference in any field it was allowed to look at, and reported Synced. It deployed nothing. There was no error, no warning, no OutOfSync marker. The dashboard was green and the system had silently stopped working.

I found it by forcing a sync manually and watching the image change.

The resolution was to accept a permanently OutOfSync-but-Healthy Application. A misleading status indicator is annoying. An Application that reports success while refusing to deploy is an outage waiting for someone to notice.

There’s a general principle here that cost me several hours across the project: anything that writes to a field git doesn’t control produces unreconcilable drift. I hit it four separate times before I recognized the pattern.

Each time, something other than git was writing to a field, so ArgoCD compared live state to desired state and found a difference it could never reconcile:

• containers[].image — Kyverno's mutateDigest appends the verified digest. Git only has the tag, because the digest isn't known until verification happens.
• APIService.spec.caBundle — cert-manager injects a CA bundle generated in-cluster. That certificate cannot exist in git; it doesn't exist until the cluster creates it.
• Warehouse.spec.subscriptions — Kargo's admission webhook writes defaulted fields back onto its own custom resource.
• directory.recurse: false — the API server itself, and this one is its own category.

That last one is worth its own sentence. I wrote recurse: false explicitly in an ArgoCD Application. false is the default, so the API server drops the key entirely. Git said false, the live object said nothing, and ArgoCD reported drift that could never be resolved.

Never declare a field at its default value in a GitOps manifest.

Failure three: NetworkPolicy that isn’t enforced

I wrote default-deny NetworkPolicies for every namespace (I know, many wouldn’t do this for shifting things left, but I DO 😀), plus explicit allows for DNS, same-namespace traffic, and the Kubernetes API. Applied them. kubectl get networkpolicy -A listed them all. Kubescape moved the relevant control from 0% to 68%.

None of it was enforced 😄😭.

The AWS VPC CNI accepts NetworkPolicy objects and ignores them unless you explicitly turn on enforcement:

configuration_values = jsonencode({ enableNetworkPolicy = "true" })

This is worse than having no policies. With no policies you know you have no policies. With unenforced policies you have documentation that claims otherwise, a compliance scanner that agrees with the documentation, and no actual isolation.

The check takes one command:

kubectl get ds aws-node -n kube-system \
  -o jsonpath='{.spec.template.spec.containers[*].name}'
# aws-node aws-eks-nodeagent

No aws-eks-nodeagent, no enforcement.

Then, once enforcement was on, the policies broke ArgoCD.

Not immediately, and not in a way that looked like networking. Every ArgoCD Application went to Unknown; not OutOfSync, not Degraded. The application-controller logs showed connection timeouts to two addresses:

dial tcp 172.20.222.51:8081: i/o timeout    # repo-server
dial tcp 172.20.180.188:6379: i/o timeout   # redis

My VPC CIDR is 10.10.0.0/16. I had allowed egress to the VPC and to 0.0.0.0/0 on 443. But ClusterIP Service addresses come from the service CIDR, 172.20.0.0/16 on EKS, which is an entirely separate range. A pod calling a Service in its own namespace still egresses to 172.20.x.x.

Two rules were missing:

egress:
  - to: [podSelector: {}]                       # same namespace, any port
  - to: [ipBlock: {cidr: 172.20.0.0/16}]        # ClusterIP Services

The same class of mistake took down health probes later. Kubelet probes originate from the node, not from a pod, so a policy allowing only same-namespace ingress drops them. Pods sat at 0/1 Ready indefinitely with nothing in the container logs, because the request never arrived.

Blocked connections look like timeouts, not refusals. They present as slow startup, mysterious readiness failures, and controllers that report Unknown. They rarely look like a firewall.

Failure four: thirty minutes of nothing (lol LITERALLY)

I added a launch template to the node group which was needed for Bottlerocket’s SSM control container, and a good opportunity to set the IMDS hop limit to 1 so pods can’t reach node credentials.

The apply ran for twenty-eight minutes. I checked:

aws eks describe-nodegroup --cluster-name dsp-dev-eks \
  --nodegroup-name dsp-dev-eks-ng --query 'nodegroup.{status:status,health:health}'

{ "status": "CREATING", "health": { "issues": [] } }

Creating, no issues. Meanwhile:

{ "desired": 3, "instances": 0 }

Zero instances. Every one was being terminated at launch, and the node group API reported nothing at all.

The reason was only visible in one place:

aws autoscaling describe-scaling-activities --auto-scaling-group-name "$ASG" \
  --query 'Activities[].{status:StatusCode,cause:StatusMessage}'

Client.InvalidKMSKey.InvalidState: The KMS key provided is in an incorrect state

I had encrypted the root volumes with the cluster’s KMS key, the one used for envelope-encrypting Kubernetes Secrets. Encrypting EBS volumes with a customer managed key requires the Auto Scaling service-linked role to hold kms:CreateGrant on it. It doesn't, by default, and nothing tells you.

The fix was to use the AWS-managed EBS key, which encrypts at rest just as effectively. The cluster key’s job is etcd, not block storage.

describe-nodegroup will not tell you why a node group is stuck. describe-scaling-activities will. That single command would have saved twenty-five minutes.

Failure five: a chart pinned to an image that no longer exists

I pinned every Helm chart to an exact version, which is correct practice and which I felt good about.

Then Kyverno’s cleanup jobs started failing with ImagePullBackOff, and an ArgoCD sync operation wedged waiting on a hook that could never complete. It blocked that Application four separate times over two days.

The chart was pinned. The chart hadn’t changed. The image the chart references had been retired from public Docker Hub by its vendor.

A pinned chart guarantees the chart doesn’t change. It says nothing about the images inside it.

The second instance of the same class was subtler. Another job referenced:

image: busybox:1.35

No registry prefix, so it resolves to Docker Hub, and anonymous pulls from AWS IP ranges hit Docker Hub’s rate limit. Intermittent ImagePullBackOff on a chart that worked yesterday and will work again tomorrow.

The answer to both is mirroring third-party images into a registry you control. Which introduced its own trap:

Don’t mirror with docker pull on an Apple Silicon machine. You'll pull arm64 images and push them into a registry serving amd64 nodes, and the failure appears at runtime as an exec format error. crane copy transfers the full multi-arch manifest registry-to-registry without pulling anything locally.

crane manifest <image> | jq -r '.manifests[].platform | "\(.os)/\(.architecture)"'

Failure six: six (6) wrong Helm values paths

This one is embarrassing in aggregate 😭.

Helm silently ignores unknown values keys. A wrong path produces no warning, no error, and no effect. The deployment succeeds. The setting does nothing.

I got six of them wrong across the project:

• Kyverno’s IRSA annotation lives at admissionController.rbac.serviceAccount.annotations, not admissionController.serviceAccount.annotations. The leaf key existed; I had the parent wrong.
• Kubescape’s nodeAgent.enabled doesn't exist at all. The eBPF agent is controlled through capability flags, most of which default to enabled. My attempt to disable it did nothing, and would have deployed a privileged DaemonSet onto two t3.medium nodes.
• Coroot’s communityEdition sounds like a boolean. It's an object; its presence enables the feature. communityEdition: true is rejected; communityEdition: {} is correct.
• Coroot’s logCollector has no enabled field. It takes collectLogEntries and collectLogBasedMetrics.

Each was found by reading the actual values file or CRD schema:

helm show values <repo>/<chart> --version <v> > /tmp/values.yaml
kubectl explain <kind>.spec.<field>
kubectl apply --dry-run=server -f <file>

That last one is the best of the three. Server-side validation, one second, exact field name. Once I started running it before every commit, this entire class of failure disappeared.

There’s a variant when a CRD uses x-kubernetes-preserve-unknown-fields and there's no schema to read. Then you ask the webhook by submitting something deliberately wrong:

spec.subscriptions[0].image.imageSelectionStrategy: Unsupported value:
"DEFINITELY_NOT_VALID": supported values: "Digest", "Lexical",
"NewestBuild", "SemVer"

The rejection enumerates the valid values. Faster than searching documentation, and correct for the version you’re actually running.

The failures that were the system working

Not everything that looked like a problem was one.

Pod Security Admission rejected my test pod with five specific violations — privileged, no allowPrivilegeEscalation: false, capabilities not dropped, not runAsNonRoot, no seccomp profile. That's the API server refusing a non-compliant workload before Kyverno was even consulted.

A LimitRange rejected a pod requesting 16Mi because the namespace sets a 32Mi floor. The platform’s own guardrail catching the person who wrote it.

Kyverno blocked an unsigned image pushed to the same repository as a signed one:

resource Pod/my-app/blocked was blocked due to the following policies
verify-image-signatures:
  verify-signed-by-platform-key: 'failed to verify image ...: no signatures found'

That last test mattered more than the positive one. A policy that passes everything is indistinguishable from a policy that isn’t running. I only knew signature verification worked because I watched it refuse something.

Nothing could be created while Kyverno was down. During a rolling node replacement its admission webhook lost all endpoints, and because the chart uses failurePolicy: Fail, every pod creation cluster-wide was blocked until it recovered.

That’s correct behavior, and it’s the strongest argument I have for three admission controller replicas in production before tightening failurePolicy on my own policies. Enforcement that can be bypassed by an outage is weaker than it looks. Enforcement that causes the outage is worse.

What actually got built

Setting the failures aside, the finished path:

A commit triggers a build of a 7.5 MB distroless image running FIPS-mode Go. Trivy scans it and fails on HIGH or CRITICAL findings that have a fix available. Syft generates SBOMs in two formats. The image is pushed to ECR with an immutable tag, then signed with an AWS KMS key, signing after the push, because a signature binds to a digest and the digest doesn’t exist until the push completes.

Kargo polls ECR, notices the new image, and creates Freight. Promoting that Freight clones the GitOps repository, rewrites the image tag in the target overlay, and opens a merge request. It holds a token that could push directly to a protected branch. It deliberately doesn’t. The promotion blocks until a human merges.

ArgoCD syncs. At admission, Pod Security Admission enforces restricted, Kyverno verifies the cosign signature against a public key committed to git; no KMS call, no AWS dependency in the path that decides whether a pod may start — and rewrites the tag to the verified digest. NetworkPolicy denies everything not explicitly allowed. The pod cannot reach the instance metadata service, blocked both by policy and by an IMDS hop limit of 1.

Velero backs it all up to a versioned S3 bucket via IRSA, and I tested a restore rather than assuming one.

Three FIPS layers: the Go cryptographic module in the application, Bottlerocket FIPS AMIs on staging and production nodes, and FIPS endpoints for AWS API calls. The application reports its own mode at runtime, because a Dockerfile comment claiming FIPS proves nothing:

{ "go": "go1.26.8", "fipsMode": "fips140=on" }

Production was stood up and torn down deliberately, which converted four assumptions into facts; most importantly that EKS merges its bootstrap configuration into Bottlerocket’s TOML user data, which if wrong would have meant nodes that never join. It cost about a dollar.

Kargo promotion, seven green steps

Kargo pipeline view with “Waiting for Approval”

Kargo MR Submission

GitLab pipeline, seven jobs across five stages

ArgoCD applications tiles

Coroot service map

CloudWatch audit log group

The part I actually want you to take away

Every failure in this post happened in a development cluster.

Signature verification was configured wrong four times before it worked. The wrong Kyverno values path. Credentials the admission controller couldn’t use. A transparency log setting that had to match on both the signing and verifying side. A mutateDigest incompatibility with Audit mode that Kyverno rejects outright.

Four failures, each diagnosed in minutes, against a cluster nobody depended on and that I destroyed at the end of the day.

The same four failures against production would have been an incident, a change freeze, a rollback, and a meeting.

“Shift security left” usually means scanning earlier in the pipeline. That’s fine, and it’s the easy part. The version I think is more useful: build the enforcement, break it deliberately, and learn its failure modes somewhere the cost of being wrong is a rebuild.

You cannot learn that NetworkPolicy silently isn’t enforced on EKS by reading about NetworkPolicy. You learn it by writing policies, believing they work, and then testing whether a pod can actually reach something it shouldn’t.

You cannot learn that ignoring a field in ArgoCD can silently stop deployments by reading the ArgoCD documentation. You learn it by doing it and noticing your image didn’t change.

The cluster cost seven dollars a day. Every one of these lessons was available for less than the price of lunch, and every one of them would have been considerably more expensive to learn later.

The platform is Terraform, Terragrunt, EKS, ArgoCD, Kargo, Kyverno, Kubescape, Cosign, Velero, Coroot and Git

Follow me on LinkedIn 😄!

https://www.linkedin.com/in/katoria-henry-2018

Everything Was Green. Nothing Was Deploying. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I built a Docker-based machine learning inference service with automated security scanning, testing, and deployment. Every git push triggers a pipeline that scans for vulnerabilities, builds the image, tests it, and pushes to Docker Hub , which can be ready for a general development deployment or production deployment with additional pieces that I call out below. The workflow can also be triggered manually (workflow dispatch) if you’re making changes within the GitHub console directly.

Full GitHub Repo if you’d like to test this out on your own!

What This Actually Is

Let’s be clear: this is not Docker Desktop’s “Model Runner” CLI tool. This is a containerized inference service — a Flask API that loads a Hugging Face model into memory and serves predictions locally.

The architecture:

Container starts → Loads distilgpt2 into RAM → Exposes API → Serves inference

What happens on each request:

POST /generate → Tokenize → Run model (in container) → Return text

No external API calls. No proxying. The model runs in your container.

Why This Matters

Most ML tutorials show you how to train a model. Few show you how to actually deploy it with:

• Automated security scanning (Trivy + SonarCloud)
• Multi-stage Docker builds with hardening
• CI/CD pipeline that catches issues before production
• Real-world testing and deployment

This project demonstrates the deployment side of ML engineering.

Proving It’s Actually a Model Runner

Challenge: “This is just a Hugging Face API wrapper!”

Proof it’s not:

1. Disconnect from internet:

docker run -d -p 5000:5000 model-runner:latest
# Turn off WiFi
curl http://localhost:5000/generate -d '{"prompt":"test"}'
# Still works

2. Check memory usage:

docker stats
# 600MB RAM used (model loaded in memory)

3. Examine the container:

docker exec model-runner ls /root/.cache/huggingface/
# Model files present: pytorch_model.bin (~250MB)

The model is downloaded during build, loaded into memory on startup, and inference runs locally. This is a real inference service.

The CI/CD Pipeline

Every push triggers:

1. SonarCloud — Code quality & security analysis
2. Trivy — Dependency vulnerability scanning
3. Build — Multi-stage Docker image
4. Test — Automated health checks and API tests
5. Deploy — Push to Docker Hub

Real impact: Caught CVE-2024–11392 (CRITICAL) in transformers 4.35.0, updated to 4.48.0 before deployment.

What It’s Missing (Honest Assessment)

This is a starter template, not turnkey production. You’d still need:

• Authentication (API keys, OAuth)
• Rate limiting
• Monitoring & observability
• Horizontal scaling setup
• Production-grade error handling

But it gives you the foundation with security scanning and automated deployment already configured. As an engineer, having a solid starting point is valuable — but understanding how to build from it? That’s where the real learning happens.

Quick Start

# Fork the repo on GitHub, then clone YOUR fork

git clone https://github.com/YOUR_USERNAME/docker-model-runner.git
cd docker-model-runner
# Test locally
make test
# Configure GitHub secrets (5 required):
# - SONAR_TOKEN, SONAR_PROJECT_KEY, SONAR_ORGANIZATION
# - DOCKERHUB_USERNAME, DOCKERHUB_TOKEN
# Push and watch automation
git push origin main

~20 minutes later: Your ML inference service (image) is live on Docker Hub.

Architecture Deep Dive

What Hugging Face Transformers does:

generator = pipeline('text-generation', model='distilgpt2')

This line:

1. Downloads the model from Hugging Face Hub (~250MB)
2. Loads PyTorch weights into memory
3. Initializes tokenizer
4. Creates the inference pipeline
5. Caches everything

When you call inference:

result = generator("Hello", max_length=50)

This:

1. Tokenizes input (in the container)
2. Runs transformer layers (in the container)
3. Generates tokens auto-regressively (in the container)
4. Decodes output (in the container)
5. Returns text

Zero external dependencies after model download.

Performance

Cold start: 40–60 seconds (model loading)
Warm inference: 100–300ms per request
Memory: ~600MB per container
Scaling: Horizontal (multiple containers) or vertical (bigger instances)

When to Use This

Use this approach when:

• Building custom ML APIs with full control
• You need integrated CI/CD for ML deployments
• You want to learn ML deployment best practices
• Building a portfolio project

Don’t use this when:

• You’re just experimenting locally (use Docker Model CLI instead)
• You want a fully managed service (use the Hugging Face API)
• You need <50ms latency (requires GPU optimization)

What You’ll Learn

1. How to containerize ML models properly
2. Multi-stage Docker builds for smaller, secure images
3. CI/CD pipelines for automated testing and deployment
4. Security scanning integration (Trivy, SonarCloud)
5. Real-world ML deployment patterns

The Key Insight

The hard part of ML isn’t training models — it’s deploying them reliably. This project shows you:

• How to package models in containers
• How to automate security scanning
• How to test inference services
• How to deploy with confidence

Everything else is in the repo. The README has a step-by-step setup, troubleshooting, customization options, and production considerations.

Quick Links

• 📁 GitHub Repository: [docker-model-runner] (Complete setup instructions)
• 🔍 Local testing:

#Pull the image & run the container
docker pull 021bl00m/docker-model-runner:latest
docker run -d -p 5001:5000 --name model-runner 021bl00m/docker-model-runner:latest

# Watch the logs
docker logs -f model-runner

# Look for: "Model loaded successfully"
# Press Ctrl+C to exit logs

#Test the API
curl http://localhost:5001/health

#Generate text
   curl -X POST http://localhost:5001/generate \
     -H "Content-Type: application/json" \
     -d '{"prompt": "Hello AI", "max_length": 50}'

# Creative writing
curl -X POST http://localhost:5001/generate \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Once upon a time", "max_length": 100}'

# Technical content
curl -X POST http://localhost:5001/generate \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Machine learning is", "max_length": 80}'

#Clean up
docker stop model-runner
docker rm model-runner

Next Steps

1. Fork the repo to your GitHub account
2. Clone your fork and test locally with make test
3. Set up 5 GitHub secrets (instructions in the README)
4. Push changes and watch your automated pipeline
5. Customize for your use case

This is a learning project that demonstrates ML deployment fundamentals. It’s a foundation, not a complete production solution. Use it to understand the patterns, then build on it.

The repo has everything you need. Go build something!! 🚀

Following me on LinkedIn @https://www.linkedin.com/in/katoria-henry-2018

Building a Containerized ML Inference Service with Automated CI/CD was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Have you ever wanted to chat with Iron Man about your latest tech project? Or get strategic advice from Black Widow?

If you’re a Mac user, especially with Apple Silicon, you’ve probably hit the frustrating wall of “this AI tutorial doesn’t work on M1/M2/M3” or spent hours debugging architecture compatibility issues. Docker containers fail with cryptic errors. Python packages won’t install. AWS tools seem built for Linux developers only.

I’ve been there. And I fixed it.

In this tutorial, we’ll build AI agents that embody Marvel’s Avengers characters using AWS Bedrock and Claude Sonnet 4.5, specifically designed for Mac users. No more “this example is for x86_64 only” disclaimers. No more wrestling with Rosetta errors. No more feeling like a second-class developer.

By the end of this guide, you’ll have:

• A containerized development environment optimized for Apple Silicon
• Infrastructure-as-Code using AWS CloudFormation
• Fully deployed AI agents with custom Marvel personalities
• Secure S3 storage with encryption and access controls

What makes this project special:

• All code is reusable and can be production-ready, with a few security tweaks
• Security best practices built-in from day one
• One-command deployments for any character
• Interactive chat interface included

Let’s assemble!

What We’re Building

We’re creating a complete deployment system for AI agents powered by Claude Sonnet 4.5, AWS’s most advanced AI model. Each agent takes on the personality of a Marvel character, responding in-character with appropriate speech patterns and references.

Tech Stack:

• AWS Bedrock: Managed AI service
• Claude Sonnet 4.5: Advanced language model
• CloudFormation: Infrastructure-as-Code
• Docker: Containerized development
• Python & Boto3: Agent testing and interaction
• S3: Secure storage with encryption

Architecture Overview:

Local Machine (Docker)
        ↓
   AWS Bedrock Agent
        ↓
   Claude Sonnet 4.5
        ↓
   Personalized Response

Prerequisites

Before we start, make sure you have:

1. macOS (M1/M2/M3 or Intel)
2. Docker Desktop installed
3. AWS Account with Bedrock access
4. AWS CLI configured locally
5. Basic terminal knowledge

Cost Estimate:

• AWS Bedrock: Pay-per-use (~$0.003 per 1K tokens)
• S3 Storage: ~$0.023 per GB/month
• Total for tutorial: Less than $1

Part 1: Project Setup

Clone the Repository

First, let’s get the code:

git clone https://github.com/theCaptN21/avengers-bedrock-agents.git
cd avengers-bedrock-agents

Copy the environment template and add your credentials:

cp .env.example .env
vi .env

Add your AWS credentials :

# If using AWS IAM
AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
AWS_DEFAULT_REGION=us-east-1

AWS Profile (if using aws configure or aws login)
AWS_PROFILE=default

Security Note: The .env file is in .gitignore and will never be committed to Git. Your credentials stay local.

Part 2: Understanding the Architecture

Let’s break down what makes this system work.

Multi-Stage Docker Container

Our Dockerfile uses a multi-stage build for efficiency:

Stage 1: Base system with Python 3.10

Stage 2: AWS CLI (architecture-aware for ARM64/x86_64)

Stage 3: Python packages (boto3, AWS SDK)

Stage 4: Final runtime image

This approach keeps the final image lean (~500MB) while including everything we need.

CloudFormation Template

The infrastructure includes:

S3 Buckets:

• Agent storage with AES-256 encryption
• Versioning enabled
• Object Lock (30-day retention)
• Access logging to separate bucket

IAM Role:

• Least-privilege permissions
• Account-scoped trust policy
• S3 and Bedrock access only

Bedrock Agent:

• Claude Sonnet 4.5 model
• Custom personality instructions
• Production alias for versioning

Security Features

Part 3: Building the Container

Start the Docker container:

./start-dev-container.sh


You'll see:

Starting Avengers Development Container...

[+] Building... (2-3 minutes on first run)

Container started successfully!

Enter the container:

./enter-dev-container.sh


You're greeted with:

======================================
  AVENGERS BEDROCK DEV CONTAINER    
======================================

Working Directory: /workspace
Architecture: aarch64
Python: Python 3.10.12
AWS CLI: aws-cli/2.15.0

Quick Commands:
  awsid      - Show AWS identity
  awsregion  - Show AWS region
  ll         - List files

Part 4: Enable Claude Model Access

Before deploying agents, we need to enable access to Claude models in AWS Bedrock.

Request Model Access

1. Go to the AWS Console → Bedrock → Model access
2. Click Manage model access
3. Find the Anthropic section
4. Check Claude Sonnet 4.5
5. Click Request model access
6. Complete the use case form:

• Company: Personal Project (normally accepts this input)
• Industry: Technology
• Use case: “Educational project for learning AWS Bedrock and AI agents”

Approval is usually instant!

Verify Access

Inside the container:

aws bedrock-runtime invoke-model \
    --model-id "us.anthropic.claude-sonnet-4-5-20250929-v1:0" \
    --region us-east-1 \
    --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":50,"messages":[{"role":"user","content":"Hi"}]}' \
    --content-type "application/json" \
    /tmp/test.json && cat /tmp/test.json

If you see a response, jump for excitement because you’re now ready to deploy!

Part 5: Deploy Your First Agent — Iron Man

Now for the exciting part…deploying Iron Man!

./scripts/deploy-hero.sh 


**What happens behind the scenes:**

1. **CloudFormation creates the stack** (3-5 minutes)
   - S3 buckets with encryption
   - IAM role with permissions
   - Bedrock agent configuration

2. **Agent preparation** (90 seconds)
   - Creates a versioned snapshot
   - Updates the production alias

3. **Automatic testing**
   - Sends a test message
   - Displays Iron Man's response

Beautiful! Iron Man is now live and responding in character.

Part 6: Interacting with Your Agent

Single Questions

Load the agent environment and ask a question:

source /workspace/outputs/ironman-env.sh
python3 /workspace/scripts/test-agent.py "How does the arc reactor work?"

Interactive Chat

Start a conversation:

/workspace/scripts/chat.sh

======================================
  CHAT WITH IronMan
======================================

Type exit to end the chat.

Part 7: Deploy More Heroes

The beauty of what we’ve created? We can deploy any character with one command, and follow the steps above if you’d like to chat with either character. It’s important to note that when you deploy a new character, a new CloudFormation stack is created, along with a bucket for the agent and a bucket for the logs.

Thor: God of Thunder

./scripts/deploy-hero.sh thor Thor "The God of Thunder from Asgard"

Quick Sample Chat w/ Thor

Feel free to chat away with the other Avengers!

Black Widow: Master Strategist

./scripts/deploy-hero.sh blackwidow BlackWidow "a master spy and expert combatant. You are strategic, analytical, and always three steps ahead"

Captain America: The Leader

./scripts/deploy-hero.sh captain CaptainAmerica "a super soldier and natural leader from the 1940s. You inspire others and reference your experiences in World War II"

Part 8: Behind the Scenes: How It Works

Let’s peek under the hood at what makes this system tick. There were a LOT of moving pieces to get this deployed successfully, especially ensuring that we had very clean, and manageable scripts.

CloudFormation Template

The blueprint that automatically creates all of your AWS infrastructure with one command instead of clicking through the AWS Console for hours.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Avengers AI Agent powered by Claude Sonnet 4.5 with Secure S3 Storage'

Parameters:
  HeroName:
    Type: String
    Description: 'Hero name in lowercase (used for S3 bucket naming)'
    AllowedPattern: '^[a-z][a-z0-9-]*$'
    ConstraintDescription: 'Must be lowercase letters, numbers, and hyphens only'
  
  HeroDisplayName:
    Type: String
    Description: 'Display name for the hero (used for agent naming)'
  
  HeroPersonality:
    Type: String
    Description: 'Personality description for the AI agent'

Resources:
  AgentBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub '${HeroName}-bedrock-agent-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      ObjectLockEnabled: true
      ObjectLockConfiguration:
        ObjectLockEnabled: Enabled
        Rule:
          DefaultRetention:
            Mode: GOVERNANCE
            Days: 30
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      LoggingConfiguration:
        DestinationBucketName: !Ref LoggingBucket
        LogFilePrefix: !Sub '${HeroName}-logs/'
      LifecycleConfiguration:
        Rules:
          - Id: TransitionToIA
            Status: Enabled
            Transitions:
              - TransitionInDays: 90
                StorageClass: STANDARD_IA
      Tags:
        - Key: Hero
          Value: !Ref HeroDisplayName
        - Key: Project
          Value: Avengers-Bedrock

  LoggingBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub '${HeroName}-bedrock-logs-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      LifecycleConfiguration:
        Rules:
          - Id: ExpireLogs
            Status: Enabled
            ExpirationInDays: 365

  AgentBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref AgentBucket
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Sid: DenyInsecureTransport
            Effect: Deny
            Principal: '*'
            Action: 's3:*'
            Resource:
              - !GetAtt AgentBucket.Arn
              - !Sub '${AgentBucket.Arn}/*'
            Condition:
              Bool:
                'aws:SecureTransport': 'false'
          - Sid: AllowBedrockAgentAccess
            Effect: Allow
            Principal:
              AWS: !GetAtt BedrockAgentRole.Arn
            Action:
              - 's3:GetObject'
              - 's3:PutObject'
            Resource: !Sub '${AgentBucket.Arn}/*'

  BedrockAgentRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub '${HeroDisplayName}-BedrockAgentRole'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: bedrock.amazonaws.com
            Action: 'sts:AssumeRole'
            Condition:
              StringEquals:
                'aws:SourceAccount': !Ref 'AWS::AccountId'
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/AmazonBedrockFullAccess'
      Policies:
        - PolicyName: S3Access
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - 's3:GetObject'
                  - 's3:PutObject'
                  - 's3:ListBucket'
                Resource:
                  - !GetAtt AgentBucket.Arn
                  - !Sub '${AgentBucket.Arn}/*'

  BedrockAgent:
    Type: AWS::Bedrock::Agent
    Properties:
      AgentName: !Sub '${HeroDisplayName}-Agent'
      AgentResourceRoleArn: !GetAtt BedrockAgentRole.Arn
      FoundationModel: 'us.anthropic.claude-sonnet-4-5-20250929-v1:0'
      Instruction: !Sub |
        You are ${HeroDisplayName}, ${HeroPersonality}.
        
        Your mission is to assist users with their queries while staying completely in character.
        
        Character Guidelines:
        - Respond as ${HeroDisplayName} would, using their personality traits and speech patterns
        - Reference your abilities and background when relevant
        - Stay heroic, helpful, and true to your character
        - Use humor and wit appropriate to ${HeroDisplayName}
        
        Help users with their questions while making them smile and staying in character.
      IdleSessionTTLInSeconds: 600
      Description: !Sub 'AI Agent powered by ${HeroDisplayName} personality using Claude Sonnet 4.5'

  BedrockAgentAlias:
    Type: AWS::Bedrock::AgentAlias
    Properties:
      AgentId: !GetAtt BedrockAgent.AgentId
      AgentAliasName: 'production-v1'
      Description: 'Production alias for the Avengers agent'

Outputs:
  AgentId:
    Description: 'Bedrock Agent ID'
    Value: !GetAtt BedrockAgent.AgentId
    Export:
      Name: !Sub '${HeroDisplayName}-AgentId'
  
  AgentAliasId:
    Description: 'Agent Alias ID'
    Value: !GetAtt BedrockAgentAlias.AgentAliasId
    Export:
      Name: !Sub '${HeroDisplayName}-AliasId'
  
  AgentBucketName:
    Description: 'Secure S3 Bucket'
    Value: !Ref AgentBucket
  
  LoggingBucketName:
    Description: 'Logging Bucket'
    Value: !Ref LoggingBucket
  
  AgentRoleArn:
    Description: 'Agent IAM Role ARN'
    Value: !GetAtt BedrockAgentRole.Arn

The Deployment Script

The deploy-hero.sh script orchestrates everything:

#!/bin/bash
set -e

HERO_NAME=${1}
HERO_DISPLAY=${2}
HERO_PERSONALITY=${3}

# 1. Checks for an existing stack, deletes it if found
# 2. Creates a CloudFormation stack
# 3. Waits for completion
# 4. Extracts outputs (Agent ID, Alias ID, Bucket)
# 5. Saves the environment file
# 6. Prepares the agent (creates version snapshot)
# 7. Updates the alias to point to the 'correct' version
# 8. Runs automatic tests

Key insight: The script is idempotent. You can run it multiple times, but be sure that you’re doing it in a safe manner.

The Python Test Script

def test_agent(agent_id, alias_id, input_text):
    client = boto3.client('bedrock-agent-runtime')
    
    # Invoke agent with streaming response
    response = client.invoke_agent(
        agentId=agent_id,
        agentAliasId=alias_id,
        sessionId=f"session-{timestamp}",
        inputText=input_text,
        enableTrace=False
    )
    
    # Process streaming chunks
    output_text = ""
    for event in response.get('completion', []):
        if 'chunk' in event:
            output_text += event['chunk']['bytes'].decode('utf-8')
    
    return output_text

Key features:

• Retry logic with exponential backoff
• Streaming response handling
• Clear error messages

CloudFormation Template Highlights

** The CloudFormation Template was easily one of my more challenging components to get correct for this project as the formatting was just not letting me be great**

BedrockAgent:
  Type: AWS::Bedrock::Agent
  Properties:
    AgentName: !Sub '${HeroDisplayName}-Agent'
    FoundationModel: 'us.anthropic.claude-sonnet-4-5-20250929-v1:0'
    Instruction: !Sub |
      You are ${HeroDisplayName}, ${HeroPersonality}.
      
      Stay completely in character.
      Reference your abilities and background.
      Help users while making them smile.

The personality is injected directly into the system prompt!

Part 9: Lessons Learned

Building this project taught me several valuable lessons:

1. Apple Silicon & Inference Profiles Requires Attention

Problem: Docker images built for x86_64 fail on ARM64 with cryptic errors, and direct model invocation for Claude Sonnet 4.5 was a no-go.

Solution: Multi-stage Dockerfile with architecture detection, and switching to the inference profile format:

RUN ARCH=$(uname -m) && \
    if [ "$ARCH" = "aarch64" ]; then \
        curl "...-aarch64.zip" -o "awscliv2.zip"; \
    else \
        curl "...-x86_64.zip" -o "awscliv2.zip"; \
    fi


## Inference Profiles are Required

**Problem:** Direct model invocation fails with Claude Sonnet 4.5

**Solution:** Use the inference profile format:

us.anthropic.claude-sonnet-4-5-20250929-v1:0


Not the foundation model ID:

anthropic.claude-sonnet-4-5-20250929-v1:0

2. Agent Aliases Need Versions

Problem: Alias creation succeeds but invocations fail

Solution:

1. Prepare the agent (creates a snapshot)
2. Get the version number
3. Update the alias to point to that version
4. Never use DRAFT in production

3. Model Access is Not Automatic

Problem: “resourceNotFoundException” even though model exists. I saw this message ~5 times before I figured out my issue 😭🥴.

Solution: Submit the Anthropic use case form in the AWS Console. Approval is instant but required.

Part 10: Cost Management

Let’s talk about actual costs as I was very surprised that this deployment didn’t cost $100,000 🥹🤣.

Pricing Breakdown

AWS Bedrock (Claude Sonnet 4.5):

• Input: $0.003 per 1K tokens
• Output: $0.015 per 1K tokens

S3 Storage:

• Standard: $0.023 per GB/month
• Requests: $0.0004 per 1K PUT requests

Example costs:

• 100 conversations/day (avg 500 tokens each): ~$2.25/month
• S3 storage (minimal): ~$0.05/month
• Total: Under $3/month for ‘moderate’ usage

Cost Optimization Tips

1. Use lifecycle policies (already configured)

• Transitions to Infrequent Access after 90 days
• Logs expire after 365 days

2. Monitor usage (metrics will take some time to appear, so no need to panic!):

aws cloudwatch get-metric-statistics \
       --namespace AWS/Bedrock \
       --metric-name InvocationCount

# List your agent invocations (if any)
aws bedrock-agent list-agents \
    --region us-east-1 \
    --query 'agentSummaries[*].[agentName,agentId,agentStatus]' \
    --output table

# List your logging bucket
aws s3 ls s3://ironman-bedrock-logs-YOUR_ACCOUNT_ID/

# Or for Thor
aws s3 ls s3://thor-bedrock-logs-YOUR_ACCOUNT_ID/

# View today's Bedrock costs (appears within hours)
aws ce get-cost-and-usage \
    --time-period Start=$(date +%Y-%m-01),End=$(date -d tomorrow +%Y-%m-%d) \
    --granularity DAILY \
    --metrics UnblendedCost \
    --filter file://<(echo '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Bedrock"]}}') \
    --region us-east-1

3. Set billing alerts:

• AWS Console → Billing → Budgets
• Set an alert at $5/month

Part 11: Cleanup

When you’re done experimenting, always be sure to clean up resources that you no longer require, unless you’d like a surprise bill 😊.

Delete All Agents

# Inside the container
for STACK in $(aws cloudformation list-stacks \
    --stack-status-filter CREATE_COMPLETE \
    --query 'StackSummaries[?contains(StackName, `avengers`)].StackName' \
    --output text); do
    aws cloudformation delete-stack --stack-name $STACK
done

Stop the Container

# Exit the container
exit

# Stop and remove the container
./stop-dev-container.sh

Costs after cleanup: $0 (S3 buckets are deleted)

Conclusion

While this tutorial uses Marvel characters for fun, the underlying architecture can be production-ready, with a few additional security tweaks as necessary. We’ve built a complete AI agent deployment system from scratch, with a little pain in between, but we got it done!! You now have:

**A Containerized development environment** that works on any Mac
**Infrastructure-as-Code** for reproducible deployments  
**Production-ready security** with encryption and access controls
**Scalable architecture** that handles multiple agents
**Cost-effective solution** at under $3/month

If you’ve enjoyed this tutorial, stay tuned as there is definitely more to come 🚀🔒!!

Follow me on LinkedIn @katoria-henry-2018! ✅

Building AI-Powered Marvel Avengers Chatbots with AWS Bedrock and Claude Sonnet 4.5 was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Docker has revolutionized the way developers build, ship, and run applications, making containerization a core part of modern DevOps workflows. While many tutorials focus on simple Flask applications, this guide takes things to the next level by showcasing a fully automated, production-ready multi-stage Docker build using FastAPI. But that’s just the beginning. We’ll go beyond basic containerization by leveraging Python automation to build, deploy, and verify our application — all while ensuring a minimal, optimized Docker image.

Additionally, we’ll integrate Docker Scout for manual vulnerability scanning, adding a security-focused layer to our workflow. This end-to-end tutorial is designed to impress, demonstrating best practices for efficient container builds, dependency management, and automation. Whether you’re a Solutions Architect, a DevOps engineer, or just looking to refine your containerization skills, this tutorial will equip you with practical techniques to streamline your Docker-based development process. 🚀

Key Features

✅ Automated Docker build, run, and status verification using Python
✅ Optimized multi-stage Dockerfile (minimizing layers and improving caching efficiency)
✅ FastAPI-based application with multiple endpoints and external API calls
✅ Manual Docker Scout scanning (ensuring security best practices)

Prerequisites for This Tutorial

Before diving into this tutorial, ensure you have the following prerequisites set up on your system:

📝System Requirements

• A macOS, Linux, or Windows machine with Docker installed.
• At least 4GB of RAM to run containers smoothly (or sufficient RAM).

📝 Installed Software

• Docker Desktop — Install from Docker’s official site
• Python 3.8+

👩🏽‍💻Set Up a Python Virtual Environment

🐍Install Required Python Packages

🚢Verify Docker Installation

🚢Install Docker Scout (Optional)

Build, Automate, & Scan Your Dockerized Application Like A Pro

Application-Specific Requirements

We’ll start things off by first installing FastAPI in our python environment:

To ensure we have the necessary libraries that will be needed for our deployment, let’s create our requirements.txt file next:

Because we’re using FastAPI as part of this build, we’ll need to create an app.py file that includes the core application logic that will run inside the Docker container. This logic will define the FastAPI-based web service, allowing users to send HTTP requests and receive responses. This is the actual application we are containerizing, so it’s crucial to verify that it works before packaging it into a Docker image.

Before building and running the application inside a container, testing it locally ensures:

1. The code is functional — This confirms that the FastAPI app is correctly set up and can handle requests.
2. Dependencies are installed — If the app runs outside Docker, it means Python and required packages (e.g., uvicorn, requests) are installed correctly.
3. Easier Debugging — Running the app locally helps catch syntax errors, import issues, or missing dependencies before introducing Docker.
4. Faster Iteration — Fixing issues outside Docker saves time compared to repeatedly building and running containers.

from fastapi import FastAPI, HTTPException # type: ignore
import requests # type: ignore

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello, Docker Captains! This is a multi-stage Docker build project."}

@app.get("/status")
def get_status():
    return {"status": "Running", "version": "1.0.0"}

@app.get("/external-api")
def fetch_external_api():
    """Fetch data from an external API to demonstrate network requests."""
    try:
        response = requests.get("https://api.github.com/repos/docker/docker")
        return response.json()
    except requests.RequestException:
        raise HTTPException(status_code=500, detail="External API request failed.")

We can execute a local dry run of the app.py file to confirm that we can in fact get a health status check and fetch data from an external API:

Crafting Our Dockerfile & Python Script

This Dockerfile is designed for efficiency and security using a multi-stage build approach. It installs dependencies in a temporary builder stage and only copies the necessary files into the final production image, keeping it lightweight and optimized. By structuring the layers strategically, it leverages caching to speed up builds while ensuring that unnecessary files, such as build tools and caches, are removed. This results in a smaller, faster, and more secure container that is ready for production use. 🚀

# --- Base Image (Builder Stage) ---
    FROM python:3.11-slim AS builder
    WORKDIR /app
    
    # Install dependencies in a single RUN statement for efficient layer caching
    RUN apt-get update && \
        apt-get install -y gcc curl && \
        rm -rf /var/lib/apt/lists/*
    
    # Copy requirements and install the required dependencies
    COPY requirements.txt .
    RUN pip install --no-cache-dir --prefix=/install -r requirements.txt
    
    # --- Final Production Image ---
    FROM python:3.11-slim
    WORKDIR /app
    
    # Copy built dependencies from the builder stage
    COPY --from=builder /install /usr/local
    
    # Ensure the correct path is used for installed Python packages
    ENV PYTHONPATH=/usr/local/lib/python3.11/site-packages
    
    # Copy the necessary application files
    COPY . .
    
    # Expose the desire port and define the entry point
    EXPOSE 8000
    CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

The Python script (deploy.py) automates the entire Docker workflow, eliminating the need for manual commands. It builds the Docker image, runs the container, and verifies the application’s status to ensure a seamless deployment. This approach streamlines development, reduces human error, and saves time, making it easier to manage containerized applications efficiently. Instead of manually executing multiple Docker commands, this script handles everything with a single execution, ensuring consistency across deployments.

Key Features of deploy.py

🏁Automated Docker Build — Builds the FastAPI container with optimized caching
🏁Container Deployment — Runs the container with the correct ports and settings
🏁Health Check — Calls the /status endpoint to confirm the application is running

🏁Error Handling — Provides meaningful error messages if any step fails
🏁 Manual Cleanup Option — Leaves the container running for Docker Scout vulnerability scanning

This script enhances developer productivity by making Dockerized deployments faster, repeatable, and more reliable!

import subprocess
import time
import requests # type: ignore

def run_command(command):
    """Runs a shell command with error handling."""
    try:
        subprocess.run(command, check=True)
    except subprocess.CalledProcessError as e:
        print(f"Error executing {command}: {e}")
        exit(1)

def build_image():
    print("\n🚀 Building the Docker image...")
    run_command(["docker", "build", "-t", "fastapi-multi-stage", "."])

def run_container():
    print("\n🚀 Running the container...")
    run_command(["docker", "run", "-d", "-p", "8000:8000", "--name", "fastapi-app", "fastapi-multi-stage"])
    time.sleep(3)

def check_status():
    """Check if the container is running by calling the /status endpoint."""
    url = "http://localhost:8000/status"
    try:
        response = requests.get(url)
        if response.status_code == 200:
            print("\n✅ Application is running successfully!")
            print(f"Response: {response.json()}")
        else:
            print(f"\n⚠️ Unexpected response: {response.status_code}")
    except requests.exceptions.RequestException:
        print("\n❌ Application failed to start. Check logs.")

if __name__ == "__main__":
    build_image()
    run_container()
    check_status()

    print("\n📸 The container is running and ready for Docker Scout scanning.")
    print("🛑 To stop and remove the container, run: docker stop fastapi-app && docker rm fastapi-app")

And if you execute the script by running python deploy.py, this is what you should see:

We can verify that the application is in fact up and running by navigating to http://localhost:8000, and here, we should see our little Docker Captain’s message (I’m a new Docker Captain btw ☺️):

Assuming that you have Docker Desktop up and running, you can also verify your image that was created, container, logs, docker build, and so forth in the tool directly:

Vulnerability Management: Why Is This Important for Docker Images?

Containerized applications are only as secure as the images they are built from, making vulnerability management a critical aspect of Docker security. Since Docker images often include base OS layers, dependencies, and third-party libraries, any unpatched vulnerabilities in these components can introduce security risks, potentially exposing applications to exploits, malware, and data breaches. Regularly scanning and updating images helps mitigate these risks, reduce attack surfaces, and ensure compliance with security best practices.

Docker Scout plays a vital role in this process by providing automated vulnerability analysis for container images. It helps developers quickly identify known security issues, analyze Common Vulnerabilities and Exposures (CVEs), and make informed decisions about remediating risks before deploying containers to production. By integrating Docker Scout into the development workflow, teams can proactively manage vulnerabilities, ensuring that their Docker images remain secure, reliable, and production-ready.

If your build was successful, you would have noticed a “What’s Next” blurb, which directs you to take a quick view of the Docker Scout summary of the image vulnerabilities and recommendations by simply running docker scout quickview fastapi-multi-stage. It scans for known vulnerabilities (CVEs) and gives an overview of critical, high, medium, and low-risk issues found in the image layers. This command is useful for fast vulnerability assessments, allowing teams to identify risks early in the development cycle without diving into full detailed reports.

To actually dive deeper into the CVEs that were identified, you would run docker scout cves fastapi-multi-stage. This command performs a detailed vulnerability scan on a Docker image, listing all detected Common Vulnerabilities and Exposures (CVEs) along with their severity levels. Unlike quickview, which provides a summary, this command gives in-depth insights into each vulnerability, including affected packages, CVE identifiers, and available fixes. It helps developers identify and prioritize security risks, ensuring that container images remain secure and compliant before deployment.

The docker scout recommendations command provides actionable security insights by suggesting remediation steps for vulnerabilities found in a Docker image. Unlike basic vulnerability scans, this command goes further by identifying safer base image alternatives, recommending updated dependencies, and offering best practices to reduce security risks. This is beneficial because it helps developers proactively fix issues, minimize the attack surface, and ensure more secure and resilient containers before deployment. To see the recommendations, you would simply run docker scout recommendations fastapi-multi-stage:latest:

Closing Thoughts

Mastering Docker automation, multi-stage builds, and vulnerability management is essential for building efficient, secure, and production-ready containers. By leveraging Python automation for deployment and Docker Scout for security analysis, this tutorial streamlines the entire container lifecycle — from development to security hardening. Whether you’re a DevOps engineer, a security-conscious developer, or a Docker enthusiast, integrating these best practices will help you build smarter, deploy faster, and secure your applications more effectively.

Now that you have the tools to automate and scan your images, the next step is to apply these techniques to your own projects and elevate your container security game. 🚀💡 What’s the first image you’ll scan with Docker Scout?

Feel free to follow me on LinkedIn for more content, and find your next Docker Captain here!

💫 Bonus💫: Check out the python script that I created to generate the diagram for this tutorial:

import matplotlib.pyplot as plt
import networkx as nx

def draw_docker_workflow():
    # Define graph
    G = nx.DiGraph()

    # Define nodes with labels
    nodes = {
        "start": "Start Project\n(Set Up Python Env)",
        "write_app": "Write FastAPI App\n(app.py)",
        "test_locally": "Test Locally\n(uvicorn app:app)",
        "create_dockerfile": "Create Multi-Stage Dockerfile",
        "run_deploy": "Run deploy.py\n(Auto-Build & Run Container)",
        "check_status": "Check App Status\n(via API Endpoint)",
        "scan_image": "Scan Image with\nDocker Scout",
        "review_remediate": "Review & Remediate\nUsing Docker Scout",
        "deploy_production": "Deploy Secure Container\nto Production"
    }

    # Define edges
    edges = [
        ("start", "write_app"),
        ("write_app", "test_locally"),
        ("test_locally", "create_dockerfile"),
        ("create_dockerfile", "run_deploy"),
        ("run_deploy", "check_status"),
        ("check_status", "scan_image"),
        ("scan_image", "review_remediate"),
        ("review_remediate", "deploy_production")
    ]

    # Add nodes and edges to graph
    G.add_nodes_from(nodes.keys())
    G.add_edges_from(edges)

    # Node positions (layered top to bottom)
    pos = {
        "start": (0, 8),
        "write_app": (0, 7),
        "test_locally": (0, 6),
        "create_dockerfile": (0, 5),
        "run_deploy": (0, 4),
        "check_status": (0, 3),
        "scan_image": (0, 2),
        "review_remediate": (0, 1),
        "deploy_production": (0, 0)
    }

    # Node colors based on function
    node_colors = {
        "start": "lightblue",
        "write_app": "#fdf5c9",
        "test_locally": "lightgreen",
        "create_dockerfile": "#fdf5c9",
        "run_deploy": "lightgreen",
        "check_status": "lightcoral",
        "scan_image": "#fdf5c9",
        "review_remediate": "lightgreen",
        "deploy_production": "lightblue"
    }

    # Draw nodes
    plt.figure(figsize=(6, 10))
    nx.draw(G, pos, labels=nodes, with_labels=True, node_size=4000, font_size=10, 
            node_color=[node_colors[n] for n in G.nodes()], edge_color='black', font_weight='bold', arrows=True)
    
    # Display the diagram
    plt.title("Docker Project Workflow")
    plt.show()

# Call the function to generate the diagram
draw_docker_workflow()

Thank you for being a part of the community

Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: X | LinkedIn | YouTube | Newsletter | Podcast
• Check out CoFeed, the smart way to stay up-to-date with the latest in tech 🧪
• Start your own free AI-powered blog on Differ 🚀
• Join our content creators community on Discord 🧑🏻‍💻
• For more content, visit plainenglish.io + stackademic.com

Docker Multi-Stage FastAPI Tutorial was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

This tutorial is designed to help you create a secure, encrypted Amazon Machine Image (AMI) using Python and the AWS SDK for Python (Boto3), with a robust GitHub Actions pipeline to validate and enhance the process. Each step is broken down for junior developers to understand the logic, purpose, and value of the code and pipeline. By the end of this very simple, yet, valuable tutorial, you will know how to run the script and the pipeline locally or trigger the workflow in GitHub directly.

An Amazon Machine Image (AMI) is a pre-configured virtual machine template in AWS that includes an operating system, application code, storage volume definitions, and permissions. It serves as a blueprint for launching EC2 instances, enabling users to replicate pre-configured environments quickly and consistently. AMIs are critical for ensuring consistency across instances, streamlining automation, supporting scalability, and reducing manual configuration time. They are highly customizable and tailored to specific workloads, making them essential for efficient deployment and operational management.

Encrypting an AMI before sharing it with another account is vital for maintaining data security and compliance. AMIs often contain sensitive application configurations, proprietary software, or confidential data. Encryption ensures that the contents of the AMI are protected from unauthorized access and can only be accessed by accounts or users with the proper decryption key. This practice is particularly important for meeting regulatory compliance requirements, such as GDPR or HIPAA, which mandate encryption for stored or shared data

In this tutorial, you’ll:

• Create a secure AMI with encrypted volumes using a custom KMS key.
• Validate AMI ownership and sharing permissions.
• Implement robust automation using GitHub Actions for end-to-end validation.

You’ll also learn how to dry run the workflow locally and visualize it in GitHub.

Pre-requisites

Install the following tools:

• Boto3 (AWS SDK)
• Python (3.9+)
• AWS CLI, configured with YOUR credentials
• Git and GitHub CLI (optional for remote runs)

Directory Structure

Here’s the structure of the project, which can be forked from this repo, if you’d like to give it a go on your end:

.
├── .github/
│   └── workflows/
│       └── secure_ami.yml  # GitHub Actions workflow
├── requirements.txt         # Python dependencies
├── secure_ami.py            # Python script for secure AMI creation
├── .gitignore               # Files to ignore in version control
├── README.md                # Project documentation

Setting Up Your Environment

In addition to the pre-requisites listed above, it is highly recommended that you consider setting up a virtual python environment as well. This would be extremely helpful as we’ll be leveraging the Boto3 SDK and we’ll want to perform a dry run locally. To ensure that you won’t encounter any potential errors locally, consider setting the following environment variables, which are vital pieces within the script that we will execute:

export AWS_REGION="your-desired-region"
export AWS_ACCESS_KEY_ID="your-access-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret-access-key"
export INSTANCE_TYPE="t2.micro"
export BASE_AMI_ID="ami-xxxxx" # Replace this with a valid AMI ID
export KEY_PAIR_NAME="your-key-pair"
export SECURITY_GROUP_NAME="your-security-group"
export MY_PUBLIC_IP="your-public-ip" # E.g., "203.0.113.0"

You’ll need a requirements.txt file that includes the following libraries collectively, to enable the secure creation and management of AWS resources, at a minimum:

boto3==1.26.160
paramiko==3.2.0
cryptography==41.0.3

Our Python Script: An End-to-End Walkthrough

Note: This is a single script that I’ve created, but will be explaining the various pieces that make up the script in its entirety.

The first part of the script involves importing the required libraries and configuring logging to track our progress. It’ll be a bit difficult to monitor the execution of our script without logging of some sort:

import boto3 #type:ignore
import os
import sys
import logging
from botocore.exceptions import ClientError # type:ignore
import time

# Configure your logging
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s: %(message)s")

As part of our deployment, we want to ensure that we have an encrypted EBS volume that’ll be attached to the EC2 instance, and so we’ll need to verify the existence of a KMS Key OR create a net-new key. A KMS client is created using the boto3 library, with the AWS region taken from the environment variable AWS REGION. The function will call kms_client.list_aliases() to retrieve a list of all existing aliases in the AWS account, and will then iterate over the aliases to check if the desired alias (alias/whatever-your-alias-name-should-be) already exists.

def create_kms_key():
    """Create or retrieve a KMS key for EBS encryption."""
    kms_client = boto3.client("kms", region_name=os.getenv("AWS_REGION"))
    alias_name = "alias/whatever-your-alias-name-should-be"

    try:
        response = kms_client.list_aliases()
        for alias in response.get("Aliases", []):
            if alias["AliasName"] == alias_name:
                logging.info(f"KMS key already exists: {alias_name} ({alias['TargetKeyId']})")
                return alias["TargetKeyId"]

        response = kms_client.create_key(Description="AMI Encryption Key")
        key_id = response["KeyMetadata"]["KeyId"]
        kms_client.create_alias(AliasName=alias_name, TargetKeyId=key_id)
        logging.info(f"KMS key created: {alias_name} ({key_id})")
        return key_id
    except ClientError as e:
        logging.error(f"Error managing KMS key: {e}")
        sys.exit(1)

If there’s any desire to securely access the EC2 instance in the future for additional testing and validation, another enhancement for our script is to add in the creation of a key pair. Though not entirely required, this may be necessary if you’d like to access the instances locally:

def create_key_pair():
    """Create a key pair for SSH access."""
    ec2_client = boto3.client("ec2", region_name=os.getenv("AWS_REGION"))
    key_pair_name = os.getenv("KEY_PAIR_NAME")

    try:
        ec2_client.create_key_pair(KeyName=key_pair_name)
        logging.info(f"Key pair {key_pair_name} created.")
    except ClientError as e:
        if "InvalidKeyPair.Duplicate" in str(e):
            logging.info(f"Key pair {key_pair_name} already exists.")
        else:
            logging.error(f"Error creating key pair: {e}")
            sys.exit(1)

I’m a security person by nature, and so this wouldn’t be a robust python script without some added security layers. In this portion of the script, we are simply wanting to restrict access to our personal IP. Now, I know what you’re thinking, which is “why would you restrict access to only your IP if you may end up sharing the AMI with another user or account?”. The answer is simple — You can always UPDATE the security group rules AND this script, so no need to panic 🙂!

def create_security_group():
    """Create a security group with SSH access restricted to your IP."""
    ec2_client = boto3.client("ec2", region_name=os.getenv("AWS_REGION"))
    security_group_name = os.getenv("SECURITY_GROUP_NAME")
    my_public_ip = os.getenv("MY_PUBLIC_IP")

    try:
        response = ec2_client.create_security_group(
            Description="AMI Security Group", GroupName=security_group_name
        )
        sg_id = response["GroupId"]
        ec2_client.authorize_security_group_ingress(
            GroupId=sg_id,
            IpPermissions=[
                {
                    "IpProtocol": "tcp",
                    "FromPort": 22,
                    "ToPort": 22,
                    "IpRanges": [{"CidrIp": f"{my_public_ip}/32"}],
                }
            ],
        )
        logging.info(f"Security group {security_group_name} created with ID: {sg_id}")
        return sg_id
    except ClientError as e:
        logging.error(f"Error managing security group: {e}")
        sys.exit(1)

Who say’s that we can’t have a little fun and launch a secure, encrypted EC2 instance with encrypted EBS volumes as part of this deployment? This portion of the script does just that, and also executes the following:

• Uses environment variables to define key instance properties (AMI ID, instance type, key pair name).
• Attaches an encrypted EBS volume as the root device, using a specified KMS key for encryption.
• Associates the instance with a security group (identified by its ID).
• Tags the instance with a name (“SecureInstance”).
• Waits for the instance to reach the “running” state before completing the process.

def launch_instance(sg_id, kms_key_id):
    """Launch an encrypted EC2 instance."""
    ec2_client = boto3.client("ec2", region_name=os.getenv("AWS_REGION"))
    try:
        response = ec2_client.run_instances(
            ImageId=os.getenv("BASE_AMI_ID"),
            InstanceType=os.getenv("INSTANCE_TYPE"),
            KeyName=os.getenv("KEY_PAIR_NAME"),
            SecurityGroupIds=[sg_id],
            MinCount=1,
            MaxCount=1,
            BlockDeviceMappings=[
                {
                    "DeviceName": "/dev/xvda",
                    "Ebs": {"VolumeSize": 10, "VolumeType": "gp3", "Encrypted": True, "KmsKeyId": kms_key_id},
                }
            ],
            TagSpecifications=[
                {
                    "ResourceType": "instance",
                    "Tags": [{"Key": "Name", "Value": "SecureInstance"}],
                }
            ],
        )
        instance_id = response["Instances"][0]["InstanceId"]
        logging.info(f"Instance {instance_id} launched.")
        wait_for_instance_state(instance_id, "running")
        return instance_id
    except ClientError as e:
        logging.error(f"Error launching EC2 instance: {e}")
        sys.exit(1)

The next part of our script is probably what I’m the most excited about — Creating our OWN custom AMI! Okay, so this little snippet in our code is deigned to generate a reusable and secure AMI based on the state of a running EC2 instance. It will use the EC2 create_image API to initiate the creation of an AMI, provides options to customize the AMI’s name, description, and behavior during the creation process (e.g., avoiding instance reboot), and returns the AMI ID for further use or tracking:

def create_ami(instance_id):
    """Create an AMI from the instance."""
    ec2_client = boto3.client("ec2", region_name=os.getenv("AWS_REGION"))
    try:
        ami_name = "SecureAMI"
        response = ec2_client.create_image(
            InstanceId=instance_id,
            Name=ami_name,
            Description="A secure AMI created from SecureInstance",
            NoReboot=True,
        )
        ami_id = response["ImageId"]
        logging.info(f"AMI creation initiated: {ami_id}")
        return ami_id
    except ClientError as e:
        logging.error(f"Error creating AMI: {e}")
        sys.exit(1)

We’ll include a verification step after the AMI has been created to confirm that the AMI is in fact “owned” by our AWS account:

def verify_ami_ownership(ami_id):
    """Verify that the created AMI is owned by your AWS account."""
    ec2_client = boto3.client("ec2", region_name=os.getenv("AWS_REGION"))
    try:
        response = ec2_client.describe_images(ImageIds=[ami_id])
        owner_id = response["Images"][0]["OwnerId"]
        logging.info(f"AMI {ami_id} is owned by account: {owner_id}")
    except ClientError as e:
        logging.error(f"Error verifying AMI ownership: {e}")
        sys.exit(1)

And finally, we’ll close out the script using the main function, with a focus on the following:

• Validating the required environment variables for the process.
• Calling a series of functions to handle encryption, security, EC2 instance launching, and AMI creation.
• Logging the progress and ensuring errors are handled appropriately.

def main():
    # Validate required environment variables
    required_vars = [
        "AWS_REGION",
        "AWS_ACCESS_KEY_ID",
        "AWS_SECRET_ACCESS_KEY",
        "INSTANCE_TYPE",
        "BASE_AMI_ID",
        "KEY_PAIR_NAME",
        "SECURITY_GROUP_NAME",
        "MY_PUBLIC_IP",
    ]
    missing_vars = [var for var in required_vars if not os.getenv(var)]
    if missing_vars:
        logging.error(f"Missing required environment variables: {', '.join(missing_vars)}")
        sys.exit(1)

    # Run the secure AMI creation process
    logging.info("Starting secure AMI creation process...")
    kms_key_id = create_kms_key()
    create_key_pair()
    sg_id = create_security_group()
    instance_id = launch_instance(sg_id, kms_key_id)
    ami_id = create_ami(instance_id)
    verify_ami_ownership(ami_id)
    logging.info("Secure AMI creation process completed successfully.")


if __name__ == "__main__":
    main()

Automating Our Script Using A GitHub Actions Workflow

Now, you can’t work with the AWS Boto3 SDK without throwing in some exciting pipeline action. You must be sure that you DO NOT hardcode your AWS Account ID, AWS Access Key & Secret Access Key, and instead, add these as GitHub Secrets. Here are a few things of note regarding this workflow, just in case you’ve never used GitHub Actions, starting with the type of workflow that’s created:

Trigger

• workflow_dispatch:
  The pipeline is manually triggered and accepts several inputs related to the configuration of the AWS resources and environment. What this means is that you would navigate to your GitHub repo, head to the ‘Actions’ tab, find the workflow, and add the values you’d like as inputs before running it. You can run the workflow as MANY times as you’d like 😄. These are the input options for the workflow:

Job

• create-ami:
  This job runs the secure AMI creation process in a series of steps on an ubuntu-latest runner.

Secure Ami Creation Script Step

• Executes the Python script (secure_ami.py) to perform the secure AMI creation steps.

Wait for the AMI Availability Step

• Ensures the created AMI is in the available state before proceeding.

Verify AMI Sharing Step

• Checks to see if the newly created AMI has been shared with other AWS accounts.

Making The Magic Happen

There are a few different approaches that you can take to create the desired resources. If you’re interested in performing a simple dry run locally via Python, you’d execute the following command below, and also run the export of the variables that was mentioned earlier:

DRY_RUN=true python secure_ami.py

Alternatively, if you’d like to skip the dry run and see the magic unfold via the pipeline instead, you can kick it off locally, but you must ensure that you’ve pushed your configuration files to the desired repo (pushing the files will not trigger the workflow since we’re using a workflow dispatch):

gh workflow list

gh workflow run secure_ami.yml \ 
-- field region="your-region" \ 
-- field instance_type="t2.micro" \ 
-- field base_ami_id="ami-xxxxx" \
-- field key_pair="key-pair-name" \ 
-- field security_group="sg-name" \ 
-- field my_ip="x.x.x.x"

Validating Our Deployment

With a quick glance at our Pipeline, we can see that we have a successful deployment 🙌:

If we navigate to our AWS Console, we’ll only validate a few things, just to serve as proof that resources were actually created:

Conclusion

And there you have it! 🚀 You’ve now set up a streamlined, secure, and automated pipeline to create encrypted AMIs and launch EC2 instances like a pro. 🔒 By leveraging GitHub Actions, Python, and AWS, you’ve taken a major step toward simplifying infrastructure management while following best practices for security. 🌟

Ready to take this to the next level? Start customizing and scaling this workflow to fit your unique cloud needs. The sky’s the limit! ☁️

Happy coding! 🎉

Thank you for being a part of the community

Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: X | LinkedIn | YouTube | Newsletter | Podcast
• Check out CoFeed, the smart way to stay up-to-date with the latest in tech 🧪
• Start your own free AI-powered blog on Differ 🚀
• Join our content creators community on Discord 🧑🏻‍💻
• For more content, visit plainenglish.io + stackademic.com

Creating a Secure, Encrypted AMI Using Boto3, Python, and GitHub Actions was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s software development landscape, automating deployments and managing infrastructure as code are essential skills for developers and DevOps engineers. This tutorial will walk you through setting up a CI/CD (Continuous Integration/Continuous Deployment) pipeline to automate the process of building and deploying a simple web application. We’ll be using Docker to containerize a basic Flask application (a lightweight web framework for Python), CircleCI to automate the building and testing of our code, and Terraform to manage the infrastructure setup on AWS (Amazon Web Services).

Our goal is to deploy the Flask application to ECS (Elastic Container Service), a managed container orchestration service provided by AWS that makes it easy to run, stop, and manage containers. By the end of this guide, you’ll understand how these tools work together to create a fully automated, scalable, and resilient deployment pipeline. Whether you’re a beginner or have some experience with cloud services, this tutorial will help you get hands-on experience with modern DevOps practices.

Prerequisites

1. AWS Account with permissions to manage ECS, ECR, IAM, and related services.
2. CircleCI account, linked to your GitHub or Bitbucket repository.
3. Terraform installed locally.
4. Docker installed locally.
5. Flask installed locally.

Step 1: Create a Simple Flask Application

We’re going to kick things off by getting our directory structure properly configured as we want to ensure that we have ALL of the necessary files. Below, you’ll find the files that I’ve used for this deployment (your deployment files should be similar):

.
├── .circleci/
│   └── config.yml
├── python/
│   ├── app.py
│   └── .env
├── terraform/
│   ├── ecs.tf
│   ├── main.tf
│   └── variables.tf
├── Dockerfile
├── requirements.txt
├── .gitignore
└── README.md

We’ll start by adding our Python files first. Feel free to use whatever code you’d prefer for app.py, but here’s a simple snippet of what that may consist of. Note: You may want to ensure that Flask is installed locally or within your virtual environment, or you will most likely see a ‘problem’ indicated in your IDE, such as what we have below:

app.py

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, CircleCI and ECS!'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5001)

It’s important to note that whenever you’re working with “sensitive” values, you NEVER want to hard-code these config details directly within your code base. It’s a horrible security practice — flat out. Instead, you’ll want to use a file for your environment variables, such as the one that I have below (it is not required to use a Python env for this deployment, though it is optional if you choose to do so):

.env

AWS_REGION=your-aws-region
AWS_ACCOUNT_ID=your-aws-account-id
ECR_REPOSITORY_NAME=your-ecr-repo-name
IMAGE_TAG=your-image-tag
KMS_KEY_ALIAS=your-key-alias

With any Python application, it is normal to also have a requirements file as well as this helps with dependency management, though if your project is very small, you probably would not need this file. Nevertheless, below you’ll find our super-duper simple requirements file:

requirements.txt

Flask==3.0.3

If you’d like, you can run a quick test against the simple app locally by executing the file, and visiting the webpage in the browser using http://localhost:<port>:

Step 2: Dockerize the Flask Application

The Dockerfile is a crucial part of this deployment because it defines how the application is containerized. In the context of deploying a Flask application to AWS ECS using CircleCI and Terraform, here’s why the Dockerfile is important:

• The Dockerfile specifies the environment in which the Flask application will run. It starts with a base image, such as python:3.9-slim, and installs all the necessary dependencies (like Flask) for the application to work. This ensures consistency across different environments (local, testing, staging, and production), as the container will always run the same code in the same environment.
• It handles the installation of application dependencies, such as the Python packages listed in the requirements.txt file. This allows you to package everything needed for the application to run within the container, avoiding the problem of "it works on my machine" but fails elsewhere.
• Since Docker containers can run on any platform that supports Docker, a Dockerfile makes your application portable and reproducible. It ensures that the application behaves the same way regardless of where it is deployed, whether on a developer’s laptop, a CI/CD server (like CircleCI), or a cloud environment (like AWS ECS).
• By keeping the Dockerfile in version control along with the application code, changes to the deployment environment (like updates to dependencies or base images) are tracked. This helps maintain a history of changes and allows you to roll back to previous configurations if needed.
• In our CI/CD pipeline, the Dockerfile serves as the blueprint for building the Docker image. CircleCI uses the Dockerfile to create an image of the Flask application, which is then pushed to a container registry (ECR). The same image is then pulled by the ECS service for deployment. This automation speeds up development workflows and minimizes manual configuration.

Step 3: Use Terraform to Set Up AWS Infrastructure

In this step, we’re going to use Terraform to create the necessary AWS resources: an ECS cluster, ECR repository, IAM roles, and networking configurations. Remember, you SHOULD NOT be hard-coding any of your environment variables within the TF configuration directly. It’s important to also be mindful that since we will be creating an ECR repo, KMS Key, and ECS Cluster & Service, you MUST ensure that you have the appropriate permissions to create these resources or you will not be able to apply the Terraform configuration locally. We’ll start by creating our main.tf file:

Next, we’ll dive into our ecs.tf config file. Remember, for any of the resources that you are wanting to create for ECS, please note that if you have previously used ECR images in your task definition, you may have an existing execution IAM role. Your Terraform configuration will not be applied successfully if there is an existing role in place. You have the option of using the existing role (if you have one), or creating a net-new role, such as what I have done below:

And finally, we’ll wrap things up with our last file for our terraform variables….NO, this is not the same file that we created earlier for Python. This is a totally separate, and different configuration type for Terraform specifically:

So, what are some of the key benefits of using Terraform for our deployment?

• It enables the automatic creation, updating, and deletion of infrastructure, making deployments more efficient and reliable.
• If something goes wrong, you can roll back changes to a previous version, just like you would with application code.
• You can easily create and tear down test environments, which is especially useful for continuous integration/continuous deployment (CI/CD) workflows.
• In this deployment, you can use CircleCI to trigger Terraform to provision resources or update configurations whenever changes are made to the infrastructure code. This results in a fully automated pipeline where changes to code and infrastructure are deployed together.

Alright, now I’m sure that by this point you’re anticipating some action, so let’s jump into the Terraform magic, and run the following commands. You should have at least eight (8) resources provisioned successfully:

terraform init
terraform plan
terraform apply

Step 4: Configure CircleCI for your CI/CD Pipeline

With our AWS resources now deployed, and our sample Python application tested locally for verification purposes, we must now ensure that we configure a pipeline to manage our deployment. You’ll need to create a .circleci directory, and create a config.yml file within this directory. Without this file, your pipeline will NOT run, and you’ll miss out on all of the fun that’s to come!

Be sure that you have pushed ALL of your files to your designated repo at this time (the config.yml file will be needed to trigger the pipeline from your repo directly). This ‘push’ will actually trigger your workflow directly (which may fail initially), but you’ll have the ability to update the settings in a later step and re-trigger the workflow for a successful run:

Let’s break this config.yml file down a bit to understand exactly what we’re doing here:

Defines a Docker-based executor (docker-executor):

• Uses a Docker image (circleci/python:3.9) to run the jobs, providing a Python environment where the commands will execute.

Build Job:

• Checks out the code from the repository.
• Sets up a remote Docker environment to enable building Docker images within the CircleCI environment.
• Installs the AWS CLI to allow interaction with AWS services.
• Logs in to Amazon ECR using the AWS CLI, enabling the pushing of Docker images to the registry.
• Builds a Docker image for the Flask application using the provided Dockerfile.
• Tags the Docker image with the repository and image tag.
• Pushes the Docker image to ECR, making it available for deployment.

Deploy Job:

• Installs the AWS CLI to perform AWS-specific operations.
• Updates the ECS service to use the newly pushed Docker image, forcing a new deployment to pull the latest version of the image from ECR.

Workflows Section:

• Defines a workflow named build_and_deploy that runs both the build and deploy jobs.
• Ensures that the deploy job only runs after the build job completes successfully, creating a sequential pipeline.

Step 5: Updating the Circle CI Settings & Executing the Pipeline

With all of our code now pushed to our desired repo, we must ensure that we get things configured within the Circle CI console correctly. The assumption is that you have signed up for an account, and that you have integrated your desired GitHub/Bitbucket repo accordingly.

With your repo integrated, you must first ensure that you have setup your project, following the guidance in the console:

Be sure that you select the existing config file that you just pushed, or if you dare to be dangerous, create a net-new config.yml file:

**Once you’ve selected the correct config.yml file, DO NOT panic as you may see a pipeline trigger**

Navigate to > Project Settings > Environment Variables > Enter your environment variables that you created earlier, along with the AWS Access/Secret Access Key:

After you’ve successfully added all required env variables, navigate back to > Projects > Select Your Project > Trigger Pipeline:

From here, you can sit back and watch the the various phases of the pipeline execute (super neat!!), all of which should be successful if you have the CORRECT environment variables in place. We’ll start by showing some of the Build Job run details:

Next, let’s check out what was done for our Deploy Job:

Wrapping Things Up

I know you may be wondering if in fact we actually have AWS resources that were created via Terraform, and whether or not the pipeline actually updated the ECS Service…well, if you’ve followed along with my tutorial and your configuration is similar to the example code I’ve provided, you will see that all of the resources were in fact created successfully, and we can verify that we actually have an active cluster, container, active deployment, and so forth:

Dance Break: Did you all see that it ONLY took 48 seconds for this pipeline to run just ‘two’ workflows, end-to-end ? Now do you see why pipelines are everythiinnnngggg??!! Phew, it doesn’t get any better than that! Oh, and don’t forget to remove all AWS resources via terraform destroy!

Thanks for stopping by for the read! Follow me on LinkedIn if you’d like to see more interesting content like this! https://www.linkedin.com/in/katoria-henry-2018/

In Plain English 🚀

Thank you for being a part of the In Plain English community! Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: X | LinkedIn | YouTube | Discord | Newsletter
• Visit our other platforms: CoFeed | Differ
• More content at PlainEnglish.io

Deploy a Dockerized Flask Application to AWS ECS using CircleCI and Terraform was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello world! We are back again and will be diving into configuring & using the Istio Service Mesh with an EKS cluster. We’ll visualize our deployment via Grafana, and tack on a special Prometheus data source as well for further monitoring. If you’re fairly new to Istio, Granfa, or Prometheus, check out the brief overview below:

Istio is an open-source service mesh platform that provides a uniform way to connect, manage, and secure microservices. It offers features like traffic management, observability, policy enforcement, and security. With Istio, you can gain insights into the interactions between services, control traffic flow, enforce security policies, and more, all without modifying your application code.

Grafana is an open-source analytics and monitoring platform that allows you to query, visualize, and understand metrics from various data sources. It provides features like customizable dashboards, alerting, and powerful querying capabilities. Grafana is commonly used for visualizing metrics collected by Prometheus and other monitoring systems.

Prometheus is an open-source monitoring and alerting toolkit designed for reliability and scalability. It collects metrics from monitored targets by scraping HTTP endpoints at regular intervals, evaluates rule expressions, and triggers alerts when specified conditions are met. Prometheus is highly customizable and integrates seamlessly with Kubernetes for monitoring containerized workloads.

Now that we have those details out of the way, let’s get things started by identifying the necessary prerequisites for the tutorial.

**Keep in mind that this is a *demo* setup and the configuration for a production environment will require more stringent requirements!

Pre-Reqs

• An AWS Account
• IAM Roles Configured — Roles for the Cluster & Nodes
• eksctl & kubectl installed
• IDE of your choice

Step 1

We’ll start by assuming that you’ll need to create an EKS cluster from scratch. Before creating your cluster, I would highly recommend that you have custom roles identified, such as a custom EKS role, and at least a service role for the cluster and node groups. Without the necessary permissions, you will not be able to create nor interact with your cluster.

• Note that it will take ~15–20 minutes to create your demo cluster. There are a few different approaches in configuring your EKS cluster & Node Groups, such as the options below (choose the command(s) that work best for you):

eksctl create cluster --name <cluster name> --region <yourregion> --nodes=4 --node-type=m5.large

eksctl create cluster --name <cluster name> --version <clusterversion> --region <yourregion> --nodegroup-name<ngname> --node-type=t2.micro --nodes-min 1 --nodes-max 2 --nodes 2

eksctl create cluster --name <cluster name> --region <yourregion> --nodegroup-name my-nodes --node-type t3.medium --nodes 3

aws eks create-cluster --region <your region> --name <cluster name> --kubernetes-version 1.28 - role-arn <rolearn> --resources-vpc-config subnetIds=subnet-
<id>,subnet-<id>,securityGroupIds=sg-<id>

aws eks create-nodegroup --region <your region> --cluster-name <cluster name> --nodegroup-name <ngname> --scaling-config minSize=2,maxSize=2,desiredSize=2 --subnets subnet-<id> subnet-<id> --ami-type AL2_x86_64 --node-role arn:aws:iam::<accountid>:role/<name>

eksctl create cluster --name <cluster name> --region <yournregion> --nodes=4 --node-type=m5.large

eksctl create cluster --name <clustername> --version <clusterversion> --region <yourregion> --nodegroup-name<ngname> --node-type=t2.micro --nodes-min 1 --nodes-max 2 --nodes 2

eksctl create cluster --name <cluster name> --region <your region> --nodegroup-name my-nodes --node-type t3.medium --nodes 3

aws eks create-cluster --region <your region> --name <cluster name> --kubernetes-version 1.28 --role-arn <rolearn> --resources-vpc-config subnetIds=subnet-<id>,subnet-<id>,securityGroupIds=sg-<id>

aws eks create-nodegroup --region <your region> --cluster-name <cluster name> - nodegroup-name <ngname> --scaling-config minSize=2,maxSize=2,desiredSize=2 --subnets subnet-<id> subnet-<id> --ami-type AL2_x86_64 --node-role arn:aws:iam::<accountid>:role/<name>

• Let’s also create a net-new kubernetes namespace. This will be needed for the manifests we’ll create in a later step, and also helps with dividing cluster resources between users and projects. It is a best practice to create a new namespace whenever possible:

kubectl create namespace <namespacename>

• Next, we’ll update the context that we want to use for our cluster, which requires modifying the kubeconfig file:

aws eks --region <your region> update-kubeconfig --name <cluster name>

• With the cluster now created, let’s proceed by installing Istio locally, using the following command:

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH

• To install Istio on EKS, let’s run the command below:

istioctl install --set profile=demo -y

• You’ll need to create a net-new nodegroup and remove the older group since we were required to update the Cluster. Verify that all nodes have reached a ‘ready’ state.

kubectl get nodes

• You may need to re-install istio, following the commands above. Once done, you should no longer see any warnings regarding the versioning conflicts:

• Finally, we’ll need to ensure that the pods have an Envoy sidecar injected so that Istio is able to manage the necessary service. Be sure that you use the correct namespace when running this command:

kubectl label namespace<yournamespace> istio-injection=enabled

Step 2

We’re now going to jump into creating the first set of files that will be needed. We will keep things simple with this deployment and use a basic Nginx server with a custom HTML webpage for our applications.

• We’ll need to create a Dockerfile for the Nginx image we will be using along with a custom index.html file to replace the default index.html webpage. Following this creation, we’ll need to build our custom image:

# Image of your choice (We're using Nginx)
FROM nginx:alpine

# Copy your custom HTML file into the Nginx document root
COPY index.html /usr/share/nginx/html/index.html

# Expose port 80
EXPOSE 80

# Command to start Nginx
CMD ["nginx", "-g", "daemon off;"]

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Katoria's DemoApps</title>
    <style>
        body {
            background-color: black;
            color: white;
            font-family: Arial, sans-serif;
            text-align: center;
        }
        h1 {
            margin-top: 50px;
        }
        img {
            width: 400px;
            height: auto;
            margin-bottom: 20px;
        }
    </style>
</head>
<body>
    <iframe src="https://giphy.com/embed/9Hx2Jhutoccy75DzIm" width="480" height="360" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/clap-applaus-picard-9Hx2Jhutoccy75DzIm">via GIPHY</a></p>
    <h1>Katoria's DemoApps</h1>
</body>
</html>

Building the custom image:

• Next, we’ll create our Istio Gateway & Virtual Service as they will need to be added to our two deployments, both of which will leverage the custom image that we’ve built in the step above:

• Before applying your deployments, you may need to run a container from the image you’ve built using the docker run command if you are adding a customized webpage and/or depending on your custom deployments. Create at least TWO deployments using this sample deployment as a starting point:

• Next, let’s apply the deployments, istio gateway & virtual service, using the following commands:

kubectl apply -f <appname>.yml
kubectl apply -f <appname>.yml
kubectl apply -f <gatewayfile>.yml

• If you wanted to verify your deployments and/or pods, you can run the following command, using -n to specify a namespace. Note that it may take a few minutes to see the pods up and running. Re-run this command if you see that your pods are not ready, such as the below:

kubectl get pods -n <namespace>

Step 3

Now that we have our deployments and necessary services and gateway up and running, we can proceed with the installation of Grafana, followed by the creation of Prometheus as a data source:

• To deploy Grafana using Helm, we will first start by creating a namespace:

kubectl create namespace <name>

• Next, let’s get the Helm chart repo added as well:

helm repo add grafana https://grafana.github.io/helm-charts

• And finally, we have to actually install Grafana via Helm:

helm install grafana grafana/grafana --namespace <name>

• If you are following the exact steps that I have added above, you will notice that Grafana has a status of “Deployed”. However, you must also follow the instructions that are provided as part of this deployment, which include (1) generating your ‘admin’ user password, (2) locating the Grafana URL, and (3) setting up Port Forwarding:

**Note — If you do not properly setup port forwarding, you will not be able to reach the Grafana server!

• With Grafana installed & deployed, let’s proceed with installing Prometheus, with one simple command:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.12/samples/addons/prometheus.yaml

Step 4

Whew! I know there were a ton of steps above to implement, but the fun starts now as we get to play around with Grafana and the Prometheus data source, following some basic guidance below:

• Let’s start by taking a peek at the pods and services in the istio-system namespace:

kubectl get pods -n istio-system
kubectl get services -n istio-system

• Since port forwarding was configured in an earlier step, we should be able to access Grafana, by navigating to http://localhost:3000, and logging in using the default user name of ‘admin’ and the ‘secret’ that we generated above:

• We’ll be configuring a Prometheus data source, so go to “Configuration” > “Data Sources” > “Add data source”. Here, you will need to select Prometheus as the data source type, and set the URL to the Prometheus service:

• You’ll need to “Save & Test” the connection (located at the bottom left), and if the connection is successful, you will see these messages populate for the data source:

• From here, you can play around with the various queries that are available to you, or create your own custom queries, along with creating a custom dashboard. If in fact your cluster is accessible and can be monitored via Grafana and Prometheus, once the queries have been added, and you have a dashboard created, you should see your results populate, like so:

• Additionally, you can also configure custom alerting (depending on your monitoring needs), which may look similar to the below:

• Lastly, to wrap things up, let’s not forget about that custom webpage that we created at the very beginning of this tutorial. You should be able to reach your webpage via the gateway by either running http://<cluster_ip>/<appname> or localhost:<containerport#>:

And there you have it 😁! We have successfully executed the following:

✅ Created an EKS Cluster & NodeGroup; Also updated both!

✅ Created multiple deployments using a custom image

✅ Deployed an Istio gateway and virtual service

✅ Configured monitoring and alerting via Grafana & Prometheus

✅ Verified that we could reach our custom webpage.

🚨Now, tear down EVERYYYTHIINNNGGGG as you do NOT want to leave resources running! Until next time 👋🏽!

AWS EKS: Observability with Istio, Grafana & Prometheus was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello World! I know its been a while since our last tutorial on leveraging AWS CodePipeline, but we’re staying in the groove of things with pipeline automation, but this time, via GitHub Actions! I know you’re probably wondering WHY I’ve chosen to use GitHub Actions for automation…and the answer is super simple — It’s one of the more simpler CI/CD tools that you can use, that doesn’t give you an automatic headache!

GitHub Actions is a continuous integration and continuous deployment (CI/CD) platform provided by GitHub. It allows you to automate various workflows, such as building, testing, and deploying your code, directly from your GitHub repository. It uses YAML-based configuration files called “workflow files” to define these automation tasks. The beauty behind it all is that you have the option to create your workflows directly in the UI, or if you’re feeling dangerous, you can actually build and test your workflows locally as well.

For this tutorial, we’re going to show you how to build, test, and analyze an NGINX image, using tools such as AWS CloudWatch and AWS ECR as our container registry (yes, our pipeline will also include Docker references!). We’ll be creating our container registry for ECS, as those two services are normally used in tandem. Though we won’t be creating a cluster, I think it’s beneficial to show how ECS/ECR are used together. Now with CloudWatch, we are simply going to set up some basic logging. Nothing too fancy, but it’s an excellent service to use for monitoring, logging, and gaining insights into activity for your servers and other resources. If you’re interested in following along with this tutorial and giving it a go, check out the pre-reqs that I have below and let’s get started!

Pre-Reqs

• GitHub Account
• AWS Account
• IAM rules/policies configured for the necessary AWS resources
• Docker installed (Can use Rancher desktop, install Docker locally, or install it on an EC2 instance — your choice!)
• Some working knowledge of GitHub Actions

Part 1

• One of the most important steps for this tutorial is to ensure that you are NOT hardcoding any of your credentials within your GitHub Actions pipeline. It is ideal to leverage either a secrets manager, such as AWS Secrets Manager, Vault, or you can actually add your secrets to your repository, such as what I’ve done for this demo. Note: Your secrets may differ as your pipeline may not include certain values that I’m passing in my pipeline.
• For your repository, navigate to “Settings → Security → Secrets & Variables → Actions” and this is where you will place your secrets.

• As a best practice, it is ALWAYS essential to include branch protection rules for your repository. Note that if you are using a private repository for the FREE version of GitHub, you will not be able to add Branch protection rules. You will have to use a Public repo for this.
• The next step is to clone the repository that you’ve created above locally. This is needed as you will be adding a new directory and the required files for your pipeline. To clone your repository, you would Navigate to your repo → Code → Select your clone method:

Part 2

• If you have not already done so, you will need to create a new directory locally, and change into that directory BEFORE you actually paste your URL code for your repo. To make a new directory and change into that directory, you’d simply run mkdir <directoryname> && cd <directoryname>.
• Remember to add ‘git clone’ before pasting your URL. You will also need to change into the repo directory after it is cloned:

• Next, we will need to create our Dockerfile (for the Nginx image we intend to use) as well as the Nginx configuration file. These are files that can be standalone or placed in a directory (optional).
• Your Dockerfile should include the image you intend to pull, a command to copy the NGINX config file, port exposure, and a command to start the NGINX server. Remember, the less lines used within your Dockerfile, the better, as this helps with keeping the image size small.
• You’ll also need a script to create your Log Group & Log Stream for AWS CloudWatch:

Part 3

• Next, let’s create our directory for our workflow, as well as create an empty yaml file. As an aside, Workflows are automated procedures that you can set up in your GitHub repository to build, test, package, release, or deploy any code project on GitHub.The YAML file specifies the events that trigger the workflow, such as a push or pull request to the repository, or on a schedule (like a cron job). Your directory MUST begin with .github/workflows:

• With our empty file created, we will now build out our workflow. A few things that we will include are the following:

On-push: This is the event that we are selecting to trigger our workflow which means it will run automatically whenever a change is ‘pushed’ to that repo.

Matrix Strategy: This will allow us to run jobs across multiple combinations of environments, operating systems, programming languages, or any other set of variables.

Jobs: We will have a job for building the nginx image, testing the image, and a job for using AWS CloudWatch. Jobs will be running on a runner machine and will execute the individual steps. A ‘runner’ can be self-hosted (created by you), or you can leverage existing runners (github managed). They are simply operating systems.

Steps: Steps are located within each individual job and will either perform an action directly, or will leverage a script or our choice

Actions: These are pre-defined by you or pulled from the GitHub Marketplace. They are basically standalone commands that are combined into steps to create a job. They checkout your repo under your Github workspace so that your workflow can access it.

**Note: When you have multiple jobs in a workflow, you must specify within that job if it “needs” the previous job to be completed before it will start.

• With the explanation above that gives a more detailed breakdown of the workflow, let’s see how it all comes together in our yaml file (our pipeline):

Part 4

Now that we have all of the necessary files that we need for our deployment, let’s proceed by adding the files to our repo and watching the magic unfold!

• Start by running the command git add .
• Next, run git commit -m <yourcommitmessage>
• Finally run git push and head to the “Actions” tab of your repo

• In the Actions tab, you’ll notice that the workflow has started as we chose the ‘push’ event trigger, so it was automatically started on our behalf (You can also manually run the workflow over directly within the console)
• Take a peek at the various steps in your workflow to review the steps that are being executed:

Our Pipeline shows a complete success!

ECS/ECR Job

Build & Push

Image Testing

CloudWatch Log Creation

• As a bonus, you can navigate to your AWS Console and review the goodies that were created via your pipeline as well:

• *Remember, customizing your pipeline requires reviewing the GitHub Actions documentation, and adding in your explicit customizations and actions, based on your deployment. As mentioned earlier, NEVER hard-code your credentials and to ALWAYS test your pipelines on a branch other than main before merging with your codebase. That is the biggest takeaway from this tutorial. I hope you all enjoyed it and remember to delete the resources you no longer need!! See ya next time 😀!

Follow me on LinkedIn: https://www.linkedin.com/in/katoria-henry-2018/

Automating the Build of an NGINX Server via GitHub Actions, AWS ECR & CloudWatch was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the past several weeks I’ve taken you all on a miniature Terraform journey, and that continues today as well! This week, I’m going to be walking you all through a very simple project of using Terraform with GitLab 🙂. Last week we took a look at another CI/CD tool, Terraform Cloud, in which we only used the Terraform modules and files that we created to deploy our resources. This week, we’re going to take it up a notch and build a pipeline using Terraform files, as well as a customized GitLab yaml file for our AWS deployment!

So what exactly is GitLab? Well, GitLab has become more and more popular these days as companies look for simplified, secure, and CI/CD tools to help with deployments. If you understand the basics of Git, which is used for version control and tracking changes to files, well add in the “Lab” part to that and you have a web-based Git repo that serves as a CI/CD tool, provides open repos for collaboration across teams, and like Git, provides an easy method for tracking changes within a project.

Additional interesting facts about GitLab include the following:

• It helps with automating the entire DevOps lifecycle
• Considered one of the most user-friendly DevOps platform for project planning and execution
• Some of its key features include issue tracking, automation for building and testing code, as well as security enhancements such as scanning pipelines and workflows for vulnerabilities
• Gitlab provides end-to-end DevOps and DevSecOps capabilities
• You have the option of choosing between public or private branches (FREE)
• GitLab also offers online code storage

So now that we have an overview of GitLab, let’s get into our scenario for this walkthrough. Again, we will keep it very simple with our Terraform code this week and the resources to deploy:

Your team needs you to deploy a Docker container with a Centos image:

• Pull a Centos image from the Docker registry
• Create an AWS ECS cluster using the docker image with Terraform
• Create a remote backend to store your Terraform State file in a S3 Bucket
• Use a CI/CD pipeline tool that will deploy the infrastructure through AWS
• Add a build stage to your pipeline to test before deploying your code

Resources/PreReqs:

• As always, Confidence to get it done!
• AWS Account
• GitHub Account integrated with VSCode or Cloud9
• Terraform Installed
• GitLab Account: Sign up Here
• AWS IAM generated Access/Secret Key

Part 1

In this section, I’ve included a few of the files that we will be using for today’s deployment. Instead of using several modules as with my previous tutorials, I opted to use single files this time around instead. Feel free to clone my Github repo found here for all files we will be using for the walkthrough:

GitHub - theCaptN21/CICD-Tooling-Terraform: Repo that includes Terraform files for an automated workflow using CI/CD tools

ecs.tf (Main.tf)

.gitlab-ci.yml (Be sure to customize this based on your deployment reqs)

Variables.tf

Part 2

Let’s walk through getting our Project set up in GitLab as this phase may confuse some. If you’ve already signed up for your free trial of GitLab and you’re logged into your Github account, follow the steps below:

• In GitLab, the first thing that you want to do is to configure your CI/CD to run with an external repo (Your GitHub Repo or the URL for the Repo):

• If you haven’t already done so (I hadn’t used GitLab in a while), you may be required to “Authenticate” first, before you can actually connect your repo:

• Once you’ve authenticated, you’ll be promoted to “Import” the repositories that you’d like to work on for the project. Be sure to only select the repos that you absolutely NEED to import:

• Once the repo has been successfully imported, it should look similar to this:

• Similar to what was done in Terraform Cloud, you must also configure your AWS environment variables to ensure you can deploy the resources required. Navigate to “Settings -> CI/CD -> Variables (Expand) -> Add variable”, and populate the fields for REGION, ACCESS & SECRET Key (be sure to mask these data fields):

Part 3

In this next section, we will walk through the steps of building the actual GitLab yaml file required for our Terraform deployment. Though my file was created prior to the deployment, it’s helpful in understanding how I got to that point:

• Within GitLab, navigate to the main menu and there should be an option that provides a list of templates that you can use to start your deplyments. Since we will be using Terraform, let’s select that Template :

• With our template selected, we can begin to either keep the file as is, or customize it based on our deployment workflow. The template will look like this and will tell you if your syntax is accurate. It will prompt you to push your newly created template to your repo once completed:

• Getting back into the swing of things, we can now head over to “CI/CD -> Pipelines -> Run Pipeline (2x)”, to watch the magic unfold:

Part 4

With our pipeline now kicking off, let’s cross our fingers, toes, legs, and anything else we can in hopes that it goes through lol!!

• You won’t believe it, but I received an error initially when I tried my first Pipeline run. It is quite embarrassing to say the least lol:

• As you can see from above, I “forgot” to validate my account — Rookie mistake!! But once validated, I was able to proceed with the run, and this is how it went:

• Typically, it’s a good idea to actually check out the “jobs” in GitLab as the pipeline is being built, to ensure you’re seeing the resources being created and green throughout. If all goes well, you will see “Job Succeeded” at the end of the build:

Part 5

While I was able to get the pipeline running and the jobs were successful, I, myself, need to brush up on my GitLab skills! Too many rookie errors, forgetting syntax reqs, etc. I will be taking it up a notch with the next walkthrough for sure! Finally, let’s head over to AWS to check out the resources that were created:

Cluster & Service

S3 Bucket

VPC w/ Route Tables & Subnets

Docker Container (Centos)

Capacity Providers

• Note: If you did not set your gitlab-ci.yml file to auto destroy your resources, be sure that you select “Manual” when it gets to that phase in the pipeline to destroy unneeded resources!!!

BONUS: For a quick tutorial on using GitLab to manage your Terraform files, check out this video below:

Follow me on LinkedIn, and @theCaptN21 on GitHub!

Level Up Coding

Thanks for being a part of our community! Before you go:

• 👏 Clap for the story and follow the author 👉
• 📰 View more content in the Level Up Coding publication
• 💰 Free coding interview course ⇒ View Course
• 🔔 Follow us: Twitter | LinkedIn | Newsletter

🚀👉 Join the Level Up talent collective and find an amazing job

Into the Storm With Terraform & GitLab was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

This week we’re coming right back at you with more Terraform, in which we’ll be leveraging Terraform Cloud as our CI/CD tool to verify our build. If you’ve never heard of Terraform Cloud, one of the top reasons as to why it’s used in DevOps is AUTOMATION — from compliance, to management of various cloud service providers, data centers, to infrastructure automation for provisioning, Terraform Cloud does that for you. It’s basically a SaaS that could be run locally and enables Terraform to retrieve and save state files from it as well.

Additional fun facts about Terraform Cloud are as follows:

• You have visibility into state files that are being accessed and by whom
• Versioning and backing up state files is as easy as 1,2,3
• You can talk directly to various CSPs (remote state)
• You can set up your runs so that they are approved before deployment; There’s only one run at a time
• And of course, it improves overall collaboration

*I would highly recommend that you check out some of the tutorials for Terraform Cloud to become more familiar with it. They can be found here.

Today we’ll be deploying multiple AWS resources via Terraform Cloud to see some of the bells and whistles that it has. For starters, it’s best to get your Github repo all set up as that will be needed for this walkthrough. Similar to what we did last week, we will be leveraging modules this week as well, and this is the scenario we will attempt to execute:

• Create a highly available two-tier AWS architecture containing the following:
• Custom VPC with:

2 Public Subnets for the Web Server Tier

2 Private Subnets for the RDS Tier

• Launch an EC2 Instance with your choice of Web Server in each private web tier subnet (Apache, NGINX, etc).
• One RDS MySQL Instance (micro) in the private RDS subnets
• Security Groups properly configured for resources ( Web servers, RDS)
• Use module blocks for ease of use and re-usability
• Replace the EC2 Instances with an Auto Scaling Group for the Web Server (in the Public Web Server subnets) with min of 2 and max of 5 spread across the 2 subnets
• Internet-facing Application Load Balancer targeting the Web Server Auto Scaling Group.
• ALB Security Group with permissions and modifications required for the Web Servers SG to reflect the new architecture
• Use Terraform Cloud as the CI/CD to check the build

Note: I’ve done a dry run of this locally and I was having issues resolving these two errors below 🥴, so we’ll see if we can get it fixed using Terraform Cloud!

Resources/PreReqs:

• As always, Confidence to get it done!
• AWS Account
• GitHub Account integrated with VSCode
• Terraform Installed
• Terraform Cloud Account: Sign up Here
• Source Code Editor (I use Visual Studio Code (VS Code)) w/ the Terraform Extension Installed
• AWS IAM generated Access/Secret Key

Part 1

If you haven’t already done so, be sure to sign up for Terraform Cloud, preferably using your GitHub account as that will be needed for this walkthrough. I actually used my email when I first signed up for my account, so no biggie if you choose not to sign up using Github. Because there are various steps that we’ll be walkthing through, let’s highlight a few of the files that we will be using today:

Main.tf (root)

Compute (main.tf)

Load Balancer (main.tf) — Be sure to add your VPC ID to line 17

Your file structure should resemble this once completed:

For a full list of files and modules that will be used, feel free to clone my repo for this walkthrough that can be found here:

GitHub - theCaptN21/Terraform-Cloud: TF Modules to be used w/ Terraform Cloud

Part 2

Now that we have signed up for Terraform Cloud, let’s start with some of the basics of getting things set up for our new deployment. Follow the steps below to kick things off:

• As previously mentioned, if you’ve signed up using your Github account, select “Sign in with Github”, as shown below. Otherwise, continue with your email and password:

• If you signed up for MFA, you may be prompted to enter the 6-digit code that’s provided before being redirected
• Now that you’ve successfully logged on, you’ll see “Projects & Workspaces”, in which for most will be empty if this is your first time using it:

• Since this is a new deployment, let’s start by selecting “New Workspace”, in which you will then select “Version control workflow”

• Connect to Github (or if you’re using one of the other version providers, select that option). Select “Github.com”, and then authorize Terraform Cloud. From there, you’ll want to select the repositories that will be used for this walkthrough:

• Be sure to give the Workspace a name and pay close attention to the advanced options. If you’re like me and would prefer NOT to have changes automatically pushed to your repo and/or applied to your configuration automatically (though auto apply is more convenient), keep your apply method as “Manual”, and then select “Create workspace”

• We’ll have to configure our variables next (this will be your AWS access/secret key that were a pre-req), so let’s click on “Continue to workspace overview” before starting our new plan. Start by clicking on “Configure Variables”, and you will add a Terraform variable for access to the Bastion Host. Following this, you will add the Environment variables for AWS, and mark them as Sensitive to prevent the actual value from being displayed:

Part 3

Previous versions of Terraform Cloud would require you to start a new plan immediately after adding in your required variables, but with that option being changed, we will proceed with our first step of starting a new run, as shown below:

• Let’s give our run a name and leave the default run type as is for now, and click on “Start Run”:

• If you’re seeing “GREEN” on your end, that means your configuration was valid and Terraform Cloud will be able to create the resources as listed. To continue, select “Confirm & Apply”, followed by “Confirm Plan”, and your AWS resources will be created:

• Out of the 33 resources that we were hoping to create, it appears as though we have the SAME two errors from our dry-run that was completed earlier ☹️:

• All other resources were successfully created, so let’s see if we can fix our Load Balancer Module to get rid of one of the two errors. We’ll start by removing “var.vpc_id”, and applying the VPC-ID to the target group directly:

• Stage your changes to this file, and then push to Github. It should automatically trigger a new run in Terraform Cloud:

• Now, let’s retry our run to see what happens:

• It appears as though we cleared one error, but we are still having issues with that autoscaling group for RDS…let’s try one more update to see if we can resolve the error. We will follow the exact same steps and make updates to our “Compute” variables.tf file. It’s showing that our instance type is invalid for the launch template, which is an easy fix:

• You’ll also notice that the output provided us with our alb_dns address, so let’s copy that and paste it into our browser, to see what happens:

• After waiting for roughly 10 min, I gave it another shot to access the Application Load Balancer, and…New Error

Part 4

With our final error now being resolved, we can head into our AWS Console to verify some of the resources that were created:

VPC

Load Balancer across 3AZs

Internet Gateway

Auto Scaling Groups

EC2 Connect

Terraform Cloud List of Resources Created

Part 5

I hope you’ve enjoyed using Terraform Cloud CI/CD for your AWS resources. We’ve succeeded, failed, and had several “eye-brow-raising” moments with this walkthrough, but we made to the end! If you’re ready to destroy everything that you’ve deployed, let’s start with the steps below:

• Head over to your workspace settings, and scroll down to “Destruction and Deletion”

• Select “Queue Destroy Plan”, and confirm your Workspace Name
• And one-by-one, you will start to see the resources being destroyed:

• Remember, you must select “Confirm & Apply”, followed by “Confirm Plan” to ensure the resources are deleted:

As a best practice, double check that the resources no longer exist by visiting your AWS Console as well! And that wraps it up for this week 👏

Until next time everyone! Follow me on LinkedIn, and @theCaptN21 on GitHub!

Level Up Coding

Thanks for being a part of our community! Before you go:

• 👏 Clap for the story and follow the author 👉
• 📰 View more content in the Level Up Coding publication
• 💰 FREE coding interview course
• 🔔 Follow us: Twitter | LinkedIn | Newsletter

🚀👉 Join the Level Up talent collective and find an amazing job

Continuous Integration and Continuous Deployment with Terraform Cloud was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.