Forem: 🚀 Vu Dao 🚀

CI Load Test for http-echo using Kind and k6

🚀 Vu Dao 🚀 — Sat, 10 Jan 2026 03:48:41 +0000

Assignment

Build a CI Load Test for http-echo applications using Kind (Kubernetes in Docker) and the k6 load testing tool.

Solution Overview

This project implements a comprehensive load testing solution using:

Kind: Creates a multi-node Kubernetes cluster for realistic testing environments
NGINX Ingress Controller: Routes HTTP requests to different services based on hostnames
k6: Performs load testing with detailed metrics and performance analysis

Architecture

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   k6 Load Test  │───▶│  NGINX Ingress   │───▶│  http-echo apps │
│                 │    │   Controller     │    │                 │
│ - foo.localhost │    │                  │    │ - foo service   │
│ - bar.localhost │    │  (Port 80/443)   │    │ - bar service   │
└─────────────────┘    └──────────────────┘    └─────────────────┘
                                │
                                ▼
                       ┌──────────────────┐
                       │   Kind Cluster   │
                       │                  │
                       │ - Control plane  │
                       │ - Worker node    │
                       └──────────────────┘

Project Structure

kind-http-echo-test/
├── README.md                   # This documentation
├── kind-config.yaml           # Kind cluster configuration
├── k8s/                       # Kubernetes manifests
│   ├── http-echo-foo.yaml     # Foo service deployment
│   └── http-echo-bar.yaml     # Bar service deployment
└── loadtest/                  # Load testing scripts
    └── load-test.js           # k6 load test script

Prerequisites

Ensure you have the following tools installed in your CI environment:

CI Workflow

This project is designed for automated CI/CD pipelines that trigger on each pull request to the default branch. The workflow consists of four main stages executed sequentially:

Stage 1: Environment Setup

Purpose: Prepare the CI runner with all necessary tools and dependencies, supporting both AMD64 and ARM64 agents.

Key Activities:

Checkout the source code from the repository
Install k6 load testing tool via package manager
Download and install Kind for local Kubernetes clusters
Set up kubectl for cluster management
Configure necessary permissions and environment variables

Stage 2: Cluster Provisioning

Purpose: Create and configure a complete Kubernetes environment for testing.

Key Activities:

Create a multi-node Kind cluster using the project configuration
Install NGINX Ingress Controller for request routing
Wait for all control plane components to become ready
Deploy the http-echo applications (foo and bar services)
Verify all pods are running and services are accessible
Configure ingress rules for hostname-based routing

Stage 3: Load Testing

Purpose: Execute comprehensive load testing against the deployed services.

Key Activities:

Verify endpoint availability with health checks
Execute k6 load test script with predefined scenarios
Monitor real-time performance metrics during testing
Generate detailed test results in JSON format
Track custom metrics for both foo and bar services
Capture response times, error rates, and throughput data

Test Configuration:

Ramp-up: 10s to reach target load
Sustained load: 30s at peak virtual users
Ramp-down: 10s to zero load
Performance thresholds: P95 < 500ms, Error rate < 10%

Stage 4: Results Analysis

Purpose: Validate performance requirements and clean up resources.

Key Activities:

Parse JSON test results for key performance indicators
Validate against predefined performance thresholds
Generate human-readable test summary
Fail the pipeline if performance criteria are not met
Upload test artifacts for later analysis
Clean up the Kind cluster to free resources
Provide detailed feedback on test outcomes

Success Criteria:

All requests complete successfully (< 10% error rate)
Response times meet SLA requirements (P95 < 500ms)
Both services perform within acceptable ranges
No infrastructure errors during testing

🚀 Load Testing Configuration

The load-test.js script provides comprehensive load testing capabilities with the following configuration:

📊 Test Execution Stages

The load test follows a three-phase approach for realistic performance assessment:

Phase	Duration	Virtual Users	Purpose
🔼 Ramp-up	`10 seconds`	`0 → 10 users`	Gradual load increase to target capacity
🎯 Sustained Load	`30 seconds`	`20 users`	Peak performance evaluation
🔽 Ramp-down	`10 seconds`	`20 → 0 users`	Graceful load reduction

⚡ Performance Thresholds

Critical performance criteria that must be met for test success:

Response Time: 📈 95% of requests must complete under 500ms
Error Rate: ❌ Must remain below 10%
Service Availability: ✅ Both foo and bar services must be responsive

📈 Custom Metrics & Monitoring

Advanced monitoring capabilities for detailed performance analysis:

🎯 Host-Specific Metrics

Per-host Response Times: Individual performance tracking for foo and bar services
Load Distribution: Ensures balanced traffic across both deployments
Service Health: Real-time availability monitoring

🔍 Real-Time Tracking

Error Rate Monitoring: Continuous failure rate assessment
Request Distribution: Balanced load verification across services
Performance Degradation: Early detection of performance issues

📋 Test Results & Output

Comprehensive reporting for performance analysis:

🖥️ Console Output

Real-time metrics display during test execution
Live performance indicators and alerts
Immediate feedback on test progress

📄 Detailed Reports

JSON Report: Machine-readable results saved as loadtest-results.json
Per-Host Breakdown: Individual service performance analysis
Threshold Validation: Pass/fail status for each performance criterion

📊 Key Metrics Captured

Request rate (requests/second)
Response time percentiles (P90, P95, P99)
Error distribution by service
Host-specific performance characteristics

📊 Monitoring and Metrics

k6 Metrics Collection

Comprehensive performance data captured during load testing:

Request Rate: Requests per second across all endpoints
Response Time: Average, minimum, maximum, P90, and P95 percentiles
Error Rate: Percentage of failed requests with detailed error categorization
Host-specific Metrics: Individual performance analysis per service (foo/bar)

📋 Sample Test Results

Example output from a successful load testing execution:

{
  "Total Requests": 450,
  "Requests/sec": "9.00",
  "Request Duration": {
    "avg": "25.34ms",
    "min": "10.12ms",
    "max": "89.45ms",
    "p90": "45.67ms",
    "p95": "52.34ms"
  },
  "Failed Requests": "0.00%",
  "Foo Host Duration": {
    "avg": "24.56ms",
    "p90": "44.23ms",
    "p95": "51.12ms"
  },
  "Bar Host Duration": {
    "avg": "26.12ms",
    "p90": "47.11ms",
    "p95": "53.56ms"
  }
}

📝 Project Completion Notes

💡 Development Experience

GitHub Copilot Integration:
- Successfully leveraged GitHub Copilot (GPT-4.1) to generate code with the following prompts:
- Create a Kind configuration for a Kubernetes cluster with 2 nodes, adding taints to the control-plane node to ensure only the ingress-nginx controller is deployed on it
- Add a step for deploying an Ingress controller to handle incoming HTTP requests in the CI workflow
- Create 2 http-echo deployments using the hashicorp/http-echo:1.0 image, one serving a "bar" response and another serving a "foo" response. Configure cluster/ingress routing to send traffic for the "bar" hostname to the bar deployment and "foo" hostname to the foo deployment on the local cluster (routing both http://foo.localhost and http://bar.localhost), where ingress rules are based on the request's host header
- Generate randomized traffic loads for both bar and foo hosts and capture load testing results using k6
- Add a CI workflow step at the beginning to modify /etc/hosts, aliasing foo.localhost and bar.localhost to 127.0.0.1
- Create a CI workflow that triggers on each pull request to the master branch
- Use Github-copilot (Claude Sonnet 4) to write this document
Kind Learning Curve: This was my first experience with Kind (Kubernetes in Docker). I spent considerable time understanding how Kind works, particularly the configuration required to expose services to localhost for external access and testing.
Time Investment: The complete project took approximately 5 hours to complete, including research, implementation, testing, and documentation.

Source: https://github.com/vumdao/kind-http-echo-test

Ref: Goodnotes Take Home Assignment - DevOps Engineering

Note: The solution did not meet the team's expectations.

Self-Hosted N8N on AWS ECS with AWS CDK Typescript

🚀 Vu Dao 🚀 — Thu, 18 Dec 2025 16:04:34 +0000

📋 Abstract

This repository provides Infrastructure as Code (IaC) solution for deploying a self-hosted N8N workflow automation platform on AWS using the AWS Cloud Development Kit (CDK). The solution implements a scalable, cost-optimized, and highly available architecture leveraging AWS ECS Fargate, PostgreSQL RDS database instance, and ElastiCache Redis for queue management.

📑 Table of Contents

🏗️ Architecture Overview
🔍 Deep-Dive the Solution
🚀 Deploy CDK Stack and Test
- 📋 Prerequisites
- ⚙️ Environment Setup
- 🚀 Deployment Steps
- ✅ Verify Deployment
- 🧪 Testing N8N Workflows
🧹 Cleanup Stack
🎉 Conclusion
📚 References

🏗️ Architecture Overview

Key Components:

VPC with Multi-AZ Subnets: Isolated network with public, private, and isolated subnets across multiple availability zones
Network Load Balancer (NLB): Distributes HTTPS traffic to N8N main service instances
ECS Fargate Cluster: Runs containerized N8N services with auto-scaling capabilities
RDS PostgreSQL: Multi-AZ managed database for workflow data persistence
ElastiCache Redis: In-memory cache for BullMQ job queue management
AWS Cloud Map: Service discovery for internal service-to-service communication

🔍 Deep-Dive the Solution

🚀 Deploy CDK Stack and Test

📋 Prerequisites

Before deploying, ensure you have:

AWS CLI installed and configured (aws configure)
Node.js 16+ and pnpm installed
AWS CDK CLI installed (npm install -g aws-cdk)
An AWS account with appropriate permissions
A Route53 hosted zone (optional, for custom domain)

⚙️ Environment Setup

Clone the repository:

git clone https://github.com/vumdao/aws-cdk-self-hosted-n8n-infra
cd aws-cdk-self-hosted-n8n-infra

Install dependencies:

pnpm install

Configure environment variables: Create a .env file in the root directory:

CDK_DEFAULT_ACCOUNT=your-aws-account-id
CDK_DEFAULT_REGION=your-aws-region
HOSTED_ZONE_NAME=example.com
HOSTED_ZONE_ID=Z1234567890ABC

🚀 Deployment Steps

Synthesize CloudFormation template:

pnpm run synth

Review the changes:

pnpm run diff

Deploy the stack:

pnpm run deploy

✅ Verify Deployment

After successful deployment, verify the resources in AWS Console:

1. ECS Cluster:

The ECS cluster shows both N8N services running with the configured task definitions and capacity providers.

2. Main Service:

The N8N main service displays running tasks, auto-scaling configuration, and health status.

3. Worker Service:

The worker service shows active workers processing queued jobs with concurrency settings.

4. Network Load Balancer:

The NLB shows the listener configuration and DNS name which is used to create alias record in route53.

5. Target Group:

The target group displays registered ECS tasks with health check status and routing configuration.

🧪 Testing N8N Workflows

1. Access N8N UI:

Navigate to your NLB DNS name or custom domain (if configured):

https://n8n.simflexcloud.com

The N8N interface shows the workflow editor where you can create, test, and monitor automation workflows.

2. Create a Test Workflow:

Example workflow: Send an inspirational quote from internet to Slack daily

3. Verify Execution:

The Slack integration demonstrates successful workflow execution with the message being delivered to the configured Slack channel.

🧹 Cleanup Stack

To avoid ongoing AWS charges, destroy all resources:

# Destroy the CDK stack
pnpm run destroy

🎉 Conclusion

This CDK solution provides a scalable, and cost-optimized infrastructure as code (AWS CDK) for running N8N on AWS ECS.

📚 References

https://github.com/azmimengu/aws-cdk-self-hosted-n8n-infra

ClamAV (Anti-Virus) as a REST application on AWS ECS

🚀 Vu Dao 🚀 — Tue, 09 Dec 2025 15:50:59 +0000

📋 Abstract

This project provides an AWS CDK solution for automated virus scanning of S3 objects using ClamAV. It addresses the performance limitations of serverless ClamAV implementations by running ClamAV daemon (clamd) as a containerized REST API on AWS ECS Fargate. This architecture eliminates the 15-30 second cold start delay associated with loading ClamAV libraries in Lambda functions, enabling near-instant scan results.

The solution uses a hybrid approach: ECS Fargate hosts the persistent ClamAV daemon service, while Lambda functions handle S3 event processing and orchestration. Files uploaded to monitored S3 buckets trigger Lambda functions that call the ClamAV REST API, which performs fast scans using the pre-loaded daemon. Results are published to SNS topics for downstream processing.

📚 Table of Contents

📋 Abstract
📚 Table of Contents
⚠️ Opening Problems
🏗️ Architecture Overview
- 💻 Infrastructure as Code with AWS CDK
- 🔧 Core Infrastructure
- 📦 Application Components
🔍 Deep-dive the Solution
- 🛡️ 1. ClamAV REST API on ECS Fargate
- 📢 2. Result Notification System
🚀 Deploy CDK Stack and Test
- ✅ Prerequisites
- 📥 Installation and Deployment
- 🧪 Testing the Solution
🧹 Cleanup Stack
🎯 Conclusion

⚠️ Opening Problems

The cdk-serverless-clamscan project provides a serverless solution for scanning S3 objects with ClamAV using AWS Lambda. While this approach offers simplicity and automatic scaling, it suffers from a critical performance limitation:

Cold Start Delay: Lambda functions must load the entire ClamAV scanning library on each lambda invocation, resulting in 15-30 second delays before scanning can begin. This makes the solution impractical for time-sensitive workloads or high-volume scanning scenarios.

The Solution: As suggested in the ClamAV GitHub discussion, using clamd (ClamAV daemon) as a persistent service significantly improves performance. The daemon pre-loads virus definitions into memory and remains running, allowing scans via clamdscan to execute instantly without initialization overhead.

This project implements that recommendation by:

Running clamd as a containerized REST API on AWS ECS Fargate
Using Lambda functions to orchestrate S3 event processing
Calling the persistent ClamAV API for near-instant scan results

🏗️ Architecture Overview

💻 Infrastructure as Code with AWS CDK

This project uses AWS CDK (Cloud Development Kit) with TypeScript to define and provision all infrastructure resources.

CDK Project Structure:

src/
├── bin/main.ts                          # CDK app entry point
├── lib/
│   ├── stacks/
│   │   └── s3-clamav-scan-stack.ts     # Main stack orchestration
│   ├── constructs/
│   │   ├── ecs-cluster-provider/       # ECS cluster, NLB, ClamAV service
│   │   └── s3-serverless-clamscan/     # Lambda scanner, SNS, SQS
│   └── shared/
│       ├── environment.ts               # Environment configurations
│       └── constants.ts                 # Shared constants

The solution consists of the following components:

🔧 Core Infrastructure

VPC with Multi-AZ Configuration: Isolated network with public, private-isolated, and private-with-egress subnets
ECS Fargate Cluster: Hosts the ClamAV REST API containers with Fargate Spot for cost optimization
Network Load Balancer (NLB): Internal load balancer for distributing traffic to ClamAV API containers
S3 Gateway Endpoint: Direct S3 access from private subnets without NAT gateway costs

📦 Application Components

ClamAV REST API: Flask-based API running in Docker containers with clamd, nginx, and uwsgi
Lambda Scanner Function: Python function triggered by S3 events to orchestrate scanning
S3 Upload Bucket event trigger: Monitored bucket where files are uploaded for scanning
SNS Topics: Separate topics for clean and infected file notifications
SQS Error Queue: Dead letter queue for failed scan operations with retry logic

🔍 Deep-dive the Solution

🛡️ 1. ClamAV REST API on ECS Fargate

The ClamAV API is containerized and runs on ECS Fargate, providing a scalable and persistent scanning service.

Docker Container Components:

# Key components from Dockerfile
- Base: python:3.14-bookworm
- ClamAV packages: clamav, clamav-daemon
- Web stack: nginx, uwsgi, Flask
- Process manager: supervisor
- Fresh virus definitions via freshclam

API Endpoints:

GET / - Health check endpoint (returns "OK")
POST /scan_file - Scan endpoint accepting JSON payload with S3 bucket and key

📢 2. Result Notification System

The solution uses SNS topics to notify downstream systems of scan results:

SNS Topics:

clamav-clean-topic: Notifications for clean files
clamav-infected-topic: Notifications for infected files

Message Format:

{
  "input_bucket": "bucket-name",
  "input_key": "path/to/file.pdf",
  "status": "CLEAN" | "INFECTED",
  "message": "Scanning bucket-name/path/to/file.pdf\n<ClamAV output>"
}

Use Cases:

Clean Files: Trigger downstream processing (e.g., move to processed bucket, extract metadata)
Infected Files: Quarantine, alert security team, delete, or move to isolated bucket
Integration: Subscribe Lambda, SQS, email, or other services to topics

🚀 Deploy CDK Stack and Test

✅ Prerequisites

AWS account with appropriate permissions
AWS CDK CLI installed (npm install -g aws-cdk)
Node.js 16+ and pnpm package manager
Docker for building container images
AWS CLI configured with credentials

📥 Installation and Deployment

Clone the repository:

git clone https://github.com/vumdao/cdk-clamav-rest-api-on-aws-ecs.git
cd cdk-clamav-rest-api-on-aws-ecs

Install dependencies:

pnpm install

Deploy the stack:

pnpm run deploy

Build and push Docker image to ECR:

During the cdk deployment, build and push the ClamAV API Docker image:

# Navigate to the Dockerfile directory
cd src/lib/constructs/s3-serverless-clamscan/clamd-api

# Build the Docker image
docker build -t simflexcloud/clamav-api .

# Authenticate Docker to your ECR registry (replace region and account ID)
aws ecr get-login-password --region ap-southeast-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com

# Tag the image for ECR
docker tag simflexcloud/clamav-api:latest 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/simflexcloud/clamav-api:latest

# Push the image to ECR
docker push 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/simflexcloud/clamav-api:latest

Expected Output:

✅  S3ClamAvStack

Outputs:
S3ClamAvStack.EcsClusterProviderclamav-apiEndpoint = nlb-xxxx.elb.ap-southeast-1.amazonaws.com:5000

🧪 Testing the Solution

Test with clean file:

Test with the EICAR test virus

🧹 Cleanup Stack

Destroy the CDK stack:

pnpm run destroy

🎯 Conclusion

This solution successfully addresses the performance limitations of serverless ClamAV implementations by leveraging a persistent clamd daemon running on ECS Fargate. Key achievements include:
This architecture demonstrates how combining AWS managed services (ECS Fargate, Lambda, S3) with open-source tools (ClamAV) can create production-ready solutions that overcome the limitations of purely serverless approaches while maintaining operational simplicity and cost efficiency

CDK AWS Aurora PostgreSQL Limitless

🚀 Vu Dao 🚀 — Sat, 18 Jan 2025 16:04:02 +0000

Abstract

The Amazon Aurora PostgreSQL Limitless Database is now generally available, offering an advanced solution to scale your Aurora cluster seamlessly. This technology enables millions of write transactions per second and supports petabytes of data, all while maintaining the simplicity of operating a single database instance.
This post outlines a structured approach to creating an Amazon Aurora PostgreSQL Limitless Database using the AWS Cloud Development Kit (CDK) in TypeScript for demontration of Amazon Aurora PostgreSQL Limitless Database

Deploying Aurora PostgreSQL Limitless Database Using AWS CDK
Test
Check workload and scaling

🚀 Deploying Aurora PostgreSQL Limitless Database Using AWS CDK

The structure includes VPC, Aurora PostgreSQL Limitless Database with one shard group, secret manager for storing RDS credential, EC2 as bastion-host for access database in private network

Source code: https://github.com/vumdao/cdk-aurora-postgres-limitless

  src
  ├── bin
  │   └── main.ts
  └── lib
      ├── cluster.ts
      └── shared
          ├── constants.ts
          ├── environment.ts
          ├── index.ts
          └── tagging.ts

Adjust CDK_DEFAULT_REGION and CDK_DEFAULT_ACCOUNT in src/lib/shared/constants to yours
Adjust the max

  serverlessV2MaxCapacity: 64, // Adjust this for your test.
  serverlessV2MinCapacity: 16, // Minimum allow is 16

Deploy

  ✗ cdk ls
  AuroraPostgresLimitlessClusterStack

  ✗ cdk deploy AuroraPostgresLimitlessClusterStack

🚀 Test

Cluster created

Go to sample_sql

  cd sample_sql

Create E-Commerce sample schema's standard tables

  \i create_standard_tables_ec_sample_schema.sql

Convert E-Commerce sample schema's standard tables to limitless tables

  \i convert_standard_tables_to_limitless_ec_sample_schema.sql

Load data into the orders and orderdetails tables using pgbench

  pgbench  -n --client=500 --jobs=100 --progress=60 --transactions=2000  -f insert_orders_orderdetails_ec_sample_schema.sql

🚀 Check workload and scaling

Performance insight

Cloudwatch metrics

Query limitless table

Query database tables

🚀 Cleanup

Destroy resources to avoid cost

  cdk destroy AuroraPostgresLimitlessClusterStack

🚀 Conclusion

Give Aurora PostgreSQL Limitless Database a try by using AWS CDK to provision cluster faster and in secure way
Remember to adjust the query size and time of running to avoid huge cost

References:

ECS service-to-service communication

🚀 Vu Dao 🚀 — Mon, 22 Jul 2024 16:02:27 +0000

Abstract

Interconnect Amazon ECS services: Applications that run in Amazon ECS tasks often need to connect to other applications that run in Amazon ECS services. If you need an application to connect to other applications that run in Amazon ECS services, Amazon ECS provides the following ways to do this without a load balancer:
- Amazon ECS Service Connect
- Amazon ECS service discovery

🚀 Amazon ECS Service Connect

Amazon ECS Service Connect enables easy communication between microservices and across Amazon Virtual Private Clouds (Amazon VPCs) by leveraging AWS Cloud Map namespaces and logical service names. This allows you to seamlessly distribute traffic between your Amazon ECS tasks without having to deploy, configure, and maintain load balancers.
We recommend Service Connect, which provides Amazon ECS configuration for service discovery, connectivity, and traffic monitoring. With Service Connect, your applications can use short names and standard ports to connect to Amazon ECS services in the same cluster, other clusters, including across VPCs in the same AWS Region

🚀 AWS ECS Service Connect vs Service Discovery

Service Connect offers a significant advantage over plain Cloud Map for service discovery by providing faster failover when service instances go down. With DNS-based lookup in Cloud Map, the client may take some time (depending on the TTL settings) to recognize that it needs a new IP address when a service goes down. This delay can be exacerbated if the client library caches the same IP address for an extended period, or if the client's retry logic repeatedly attempts to connect to the same IP address after a failure.
Service Connect, on the other hand, introduces a sidecar "proxy" container that intercepts outgoing connections and routes them to the correct destinations. Instead of relying on potentially stale DNS entries, the sidecar uses API calls to Cloud Map to look up the IP address of a healthy service instance in real-time. This method provides the standard benefits of a service mesh, like Envoy, with the added advantage that Service Connect manages the sidecar for you. For a more detailed discussion of these benefits, see the guide on migrating existing Amazon ECS services from service discovery to Amazon ECS Service Connect.
Since Service Connect doesn't rely on DNS, it avoids registering even private DNS entries. Instead, it registers endpoints with Cloud Map that are privately discoverable only through API calls. There currently appears to be no option to configure Service Connect to register service names in DNS.

🚀 Deploying Sample Yelb Application for service connect with Amazon ECS and AWS CDK Typescript

The Yelb application used in this demo was adapated from Massimo Re Ferrè's original application here.

📖 Solution overview

📖 CDK Stacks

🚀 Walkthrough

Prerequisites: For this walkthrough, you’ll need the following prerequisites
- AWS account
- AWS CDK CLI
- CDK bootstrap on the target region
- Projen - Configuration management
- pNpm - Fast, disk space efficient package manager

1. Initial setup

# Clone project sample
git clone git@github.com:vumdao/ecs-service-connect-cdk.git && cd ecs-service-connect-cdk

# Install node modules
pnpm install

# Update your AWS account in `src/lib/shared/constants.ts` at `CDK_DEFAULT_ACCOUNT` and target region in `src/lib/shared/environment.ts` at `devEnv`
sed -i 's/123456789012/234567890123/g' src/lib/shared/constants.ts
sed -i 's/region: .*,/region: "us-west-2",/g' src/lib/shared/environment.ts

# Update Hosted zone name and zone ID in `src/lib/shared/constants.ts` with yours AWS hosted zone to create domain for yelb application eg. yelb.simflexcloud.com
# export const SIMFLEXCLOUD_ZONE_NAME = 'simflexcloud.com';
# export const SIMFLEXCLOUD_ZONE_ID = 'ZZZZZZZSSSSSSAAAA';

# Get CDK stack
cdk ls

# Deploy CDK
cdk deploy EcsBlueprintsStack --require-approval never

2. Explore created resources

Cloudformation Stack
ECS Cluster
Yelb database with client service connect
Yelb redis with client service connect
Yelb appserver with client and api-call service connect
Yelb appserver task with service-connect side-car (this agent is required for all services which enabled service connect)
appserver autoscaling group with CPU Utilization track
Yelb UI with client service connect
Application load balancer to forward requests to yelb-ui target group
Target group of yelb-ui
Cloud map service with namespace used by ECS service connect
Cloud map namespace

🚀 Cleaning up

To avoid charges, clean up the resources created in this post by running cdk destroy or go to cloudformation and delete the stack

🚀 Conclusion

With this walkthrough, you can easily deploy ecs-service-connect-yelb-sample-app using AWS CDK typescript to demonstrate ECS service-to-service communication using ECS service connect
Cloudmap creates private hosted zone automatically when creating namespace, we can delete it as we don't rely on private hosted zone when using service connect
Regarding the pricing for ECS Service Connect, AWS Cloud Map usage is entirely free when utilised by Service Connect. This includes service discovery, connectivity, and telemetry generated within the ECS console and CloudWatch by Service Connect. The only charges incurred are for the compute resources utilised. ECS Service Connect introduces a new container (Service Connect proxy) to each new task upon initiation. Consequently, you are only billed for the CPU and memory allocated to this sidecar proxy container.

References

Empowering Amazon CodeCatalyst: Workflows as Code with CodeCatalyst-Blueprints

🚀 Vu Dao 🚀 — Tue, 30 Jan 2024 17:04:28 +0000

Abstract

This blog introduces how to optimize workflow management within the Amazon ecosystem using codecatalyst-blueprints. By employing a blueprint.ts file, developers can succinctly express workflows as code, promoting readability and collaboration without CodeCatalyst Enterprise tier

Blueprints introduction
Init Blueprint project using Projen
Write blueprint.ts to build worksflow
Generate workflow yaml file
Workflows Runs
Conclusion

🚀 Blueprints introduction

Blueprints are code generators used to create and maintain projects in Amazon CodeCatalyst. You can build your own blueprint (Custom Blueprints) today by upgrading to the CodeCatalyst Enterprise tier. An integral aspect of Blueprints involves workflow generation. Disregarding the CodeCatalyst Enterprise tier, we can utilize this feature to create CodeCatalyst workflows as code, utilizing the preferred programming language, such as Typescript.

🚀 Init Blueprint project using Projen

We cannot use Projen to init a blueprint project as AWS CDK or CDK8S, but we can do a trick by init TypeScript project and then update .projenrc.ts as ProjenBlueprint
While we cannot directly use Projen to initialize a blueprint project such as AWS CDK or CDK8S, we can employ a workaround. Initialize a TypeScript project first, and then update the .projenrc.ts file using ProjenBlueprint
To initialize a TypeScript project using Projen, you can use the following command

  ➜  projen new typescript --no-git --projenrc-ts --github false --dev-deps "@amazon-codecatalyst/blueprint-util.projen-blueprint" "@amazon-codecatalyst/blueprint-util.cli"
  👾 Project definition file was created at /private/tmp/blueprint/.projenrc.ts
  👾 Installing dependencies...
  👾 install | yarn install --check-files
  yarn install v1.22.19

Override the .projenrc.ts with the following code

  import { ProjenBlueprint } from '@amazon-codecatalyst/blueprint-util.projen-blueprint';

  const project = new ProjenBlueprint({
    name: 'cdk-todo-web-app',
    defaultReleaseBranch: 'main',
    projenrcTs: true,
    sampleCode: false,
    github: false,
    tsconfig: {
      compilerOptions: {
        esModuleInterop: true,
        noImplicitAny: false,
      },
    },
    deps: [
      'projen',
      '@amazon-codecatalyst/blueprints.blueprint',
      '@amazon-codecatalyst/blueprint-component.workflows',
      '@amazon-codecatalyst/blueprint-component.source-repositories',
      '@amazon-codecatalyst/blueprint-component.dev-environments',
      '@amazon-codecatalyst/blueprint-component.environments',
    ],
    devDeps: [
      'ts-node@^10',
      'typescript',
      '@amazon-codecatalyst/blueprint-util.projen-blueprint',
      '@amazon-codecatalyst/blueprint-util.cli',
    ],
  });

  project.synth();

Then run projen to update the package.json, .projen, and other files managed by Projen

  ➜  projen
  👾 default | ts-node --project tsconfig.dev.json .projenrc.ts
  👾 Installing dependencies...
  👾 install | yarn install --check-files
  yarn install v1.22.19

🚀 Write `blueprint.ts` to build worksflow

If you've utilized CodeCatalyst custom blueprints, you are likely familiar with blueprint.ts, which contains code for generating UI options, environment settings, source repository configurations, and workflows. When creating a custom blueprint, these elements are automatically generated. However, if your goal is to leverage the CI/CD capabilities of the CodeCatalyst workspace without requiring all components, you specifically need the workflow generation part.
In short, the blueprint.ts file encompasses the following elements:
1. Source repository - serves as a reference point for workflow configurations
```
const repository = new SourceRepository(this, {
  title: "cdk-todo-web-app",
});
```

Environment - Where we define the CI/CD environment, including the connection to the AWS account.

const environment = new Environment(this, {
  name: "default_environment",
  environmentType: "DEVELOPMENT",
  description: "Blueprint environment",
  awsAccount: {
    cdkRole: { name: CDK_DEFAULT_ROLE },
    id: CDK_DEFAULT_ACCOUNT,
    name: CDK_DEFAULT_ACCOUNT,
  },
});

Workflow Actions

An Action includes the following major components

  export interface ActionProps {
    actionName: string;
    identifier: string;
    steps: string[];
    environment?: WorkflowEnvironment;
    dependancies?: string[];
    inputs?: { [key: string]: any[] };
    outputs?: { [key: string]: any };
  }

- A wrapper function that generates a workflow Action based on the interface

  ```
  /**
  * Generate an action for the workflow
  * @param props ActionProps
  * @returns Action
  */
  export function GenerateAction(props: ActionProps) {
    return {
      [props.actionName]: {
        Identifier: props.identifier,
        Inputs: props.inputs ? props.inputs : { Sources: ["WorkflowSource"] },
        Outputs: props.outputs
          ? props.outputs
          : {
              AutoDiscoverReports: {
                IncludePaths: ["**/*"],
                ExcludePaths: ["*/.codecatalyst/workflows/*"],
                ReportNamePrefix: "AutoDiscovered",
                Enabled: true,
              },
            },
        Configuration: {
          Steps: props.steps.map((step) => ({ Run: step })),
        },
        Environment: props.environment,
        DependsOn: (props.dependancies) ? props.dependancies : undefined,
      },
    };
  }
  ```

- We will have following actions
  1. `FrontendBuildAndPackage`
  2. `FrontendTest`
  3. `CDKBootstrapAction`
  4. `CDKDeploy`

WorkflowBuilder - Responsible for defining the workflow name, compute type, trigger type, and the required actions

const workflowBuilder = new WorkflowBuilder(this, {
  Name: "main_fullstack_workflow",
  Compute: {
    Type: ComputeType.EC2,
    Fleet: ComputeFleet.LINUX_X86_64_LARGE,
  },
  Triggers: [
    {
      Branches: ["main"],
      Type: TriggerType.PUSH,
    },
  ],
  Actions: {
    ...frontendBuildAndPackage,
    ...frontendTest,
    ...cdkBootstrapAction,
    ...cdkDeploy,
  },
});

Workflow - Collects all WorkflowBuilder instances and incorporates them into the source code repository
```
new Workflow(this, repository, workflowBuilder.getDefinition());
```

🚀 Generate workflow yaml file

Run yarn blueprint:synth (This script is from package.json)

  ➜  cdk-todo-web-app git:(main) ✗ yarn blueprint:synth
  yarn run v1.22.19
  $ blueprint drive-synth --blueprint ./ --outdir ./synth --default-options ./src/defaults.json --additional-options ./src/wizard-configurations $*
  [1706372494181] INFO (5048 on Daos-MBP): Running in quick mode. Run this command with --cache to emulate the wizard
  [1706372494192] INFO (5048 on Daos-MBP): ==========================================
  [1706372494192] INFO (5048 on Daos-MBP): [00.synth.defaults.json]
  [1706372494192] INFO (5048 on Daos-MBP): npx blueprint synth --options merge[./src/defaults.json,./src/defaults.json] --blueprint ./ --outdir synth/00.synth.defaults.json/proposed-bundle
  [1706372494192] INFO (5048 on Daos-MBP): ==========================================
  ===== Starting synthesis =====
  options:  {}
  outputDir:  synth/00.synth.defaults.json/proposed-bundle
  Instantiations location not specified
  running synthesis into /codecatalyst/cdk-todo-web-app/synth/00.synth.defaults.json/proposed-bundle/src/cdk-todo-web-app
  ===== Ending synthesis =====
  ✨  Done in 2.10s.

We have the generated files in synth/00.synth.defaults.json/proposed-bundle and we have our workflow YAML file is located at synth/00.synth.defaults.json/proposed-bundle/src/cdk-todo-web-app/.codecatalyst/workflows/main_fullstack_workflow.yaml

  ➜  cdk-todo-web-app git:(main) ✗ tree synth/00.synth.defaults.json/proposed-bundle/src/cdk-todo-web-app/.codecatalyst
  synth/00.synth.defaults.json/proposed-bundle/src/cdk-todo-web-app/.codecatalyst
  └── workflows
      └── main_fullstack_workflow.yaml

  2 directories, 1 file

Copy the YAML file

  ➜  cdk-todo-web-app git:(main) ✗ cp synth/00.synth.defaults.json/proposed-bundle/src/cdk-todo-web-app/.codecatalyst/workflows/main_fullstack_workflow.yaml .codecatalyst/workflows/main_fullstack_workflow.yaml

Now we can push the code to the repository and check the workflow run

🚀 Conclusion

Congratulations! You have successfully generated CodeCatalyst workflows as code using codecatalyst-blueprints without enabling the CodeCatalyst Enterprise tier.
You can create an Action to automatically generate and update the workflow YAML file by pushing a new commit to the main branch, reflecting changes from the blueprint.ts file.

🌠 Blog · Github · stackoverflow · Linkedin · Group · Page · Twitter 🌠

Bootstrapping AWS CDK Automation With Amazon CodeCatalyst

🚀 Vu Dao 🚀 — Wed, 24 Jan 2024 17:14:49 +0000

Abstract

A step-by-step guide on establishing an AWS CDK setup alongside Amazon CodeCatalyst from the ground up, enabling the creation of a comprehensive CI/CD pipeline for your infrastructure.
AWS CDK is fantastic for overseeing your entire infrastructure as code, but when multiple developers are involved in modifying the infrastructure, the situation can become chaotic without a proper mechanism like a CI/CD pipeline. Absence of such a system makes coordinating and communicating changes to the infrastructure a challenging task, and this challenge amplifies as more individuals participate in the modification process.
This tutorial will guide you through setting up a CI/CD pipeline using Amazon CodeCatalyst and AWS CDK for building To-Do web application

Setting up a CodeCatalyst Project, Repo, and Environment
Design workflows
Source code and CDK stacks
Push source code to repo
Workflows Runs
Conclusion

🚀 Setting up a CodeCatalyst Project, Repo, and Environment

Login to CodeCatalyst and go to your Space (Create one if you don't have)
Create a project from scratch

Create repository to store code and workflows of the project

Create CICD Environments which associates to AWS account for deploying our infrastructure.

Create IAM role for codecatalyst to consume during running workflows. It should be already created while you create the Space or you can customize the others

🚀 Design workflows

Workflows directory

  .codecatalyst
  └── workflows
      └── main_fullstack_workflow.yaml

Workflows is triggered by PUSH of branch main and includes following Actions

  Triggers:
    - Branches:
        - main
      Type: PUSH

FrontendBuildAndPackage build react app, target build which is shared to cross-actions by Artifacts of Outputs

FrontendBuildAndPackage:
  Identifier: aws/build@v1
  Inputs:
    Sources:
      - WorkflowSource
  Outputs:
    Artifacts:
      - Name: frontend
        Files:
          - "**/*"
  Configuration:
    Steps:
      - Run: cd static-assets/frontend
      - Run: npm install
      - Run: echo "REACT_APP_SERVICE_URL=/api/todos" > ".env"
      - Run: npm run build

FrontendTest Test frontend code

FrontendTest:
    Identifier: aws/managed-test@v1
    Inputs:
      Sources:
        - WorkflowSource
    Outputs:
      AutoDiscoverReports:
        IncludePaths:
          - frontend/**/*.xml
        ExcludePaths:
          - frontend/node_modules/**/*
        ReportNamePrefix: AutoDiscovered
        Enabled: true
        SuccessCriteria:
          PassRate: 100
    Configuration:
      Steps:
        - Run: cd static-assets/frontend
        - Run: npm install
        - Run: npm test -- --coverage --watchAll=false;

CDKBootstrapAction Run cdk bootstrap for the region of the account with latest CDK version. This action depends on FrontendTest and FrontendBuildAndPackage

CDKBootstrapAction:
  Identifier: aws/cdk-bootstrap@v1
  Configuration:
    Region: us-east-1
    CdkCliVersion: latest
  Environment:
    Name: default_environment
    Connections:
      - Name: "123456789012"
        Role: CodeCatalystWorkflowDevelopmentRole-simflexcloud
  DependsOn:
    - FrontendTest
    - FrontendBuildAndPackage

CDKDeploy Download build target of FrontendBuildAndPackage and trigger cdk deploy, this action depends on CDKBootstrapAction. Here I don't use the defined action aws/cdk-deploy@v1 of CodeCatalyst because I'd like to use projen and pnmp in CDK and handle copying frontend target build

CDKDeploy:
  Identifier: aws/build@v1
  Inputs:
    Artifacts:
      - frontend
  Outputs:
    AutoDiscoverReports:
      IncludePaths:
        - "**/*"
      ExcludePaths:
        - "*/.codecatalyst/workflows/*"
      ReportNamePrefix: AutoDiscovered
      Enabled: true
  Configuration:
    Steps:
      - Run: cp -r static-assets/frontend/build static-assets/cdkStack/src/lib/frontend/
      - Run: cd static-assets/cdkStack
      - Run: npm install -g pnpm
      - Run: pnpm i --no-frozen-lockfile
      - Run: export CDK_DEPLOY_ACCOUNT=123456789012
      - Run: export CDK_DEPLOY_REGION=us-east-1
      - Run: pnpm dlx projen deploy --all --require-approval never
  Environment:
    Name: default_environment
    Connections:
      - Name: "123456789012"
        Role: CodeCatalystWorkflowDevelopmentRole-simflexcloud
  DependsOn:
    - FrontendTest
    - FrontendBuildAndPackage

Use EC2 compute type for CodeCatalyst workflows

  Compute:
    Type: EC2
    Fleet: Linux.x86-64.Large

🚀 Source code and CDK stacks

Structure
- cdkStack Define CDK stacks and use projen for configuration management as well as pnpm
- frontend Frontend react app

  static-assets
  ├── cdkStack
  │   │   ├── LICENSE
  │   │   ├── README.md
  │   │   ├── cdk.json
  │   │   ├── package.json
  │   │   ├── src
  │   │   │   ├── bin
  │   │   │   │   └── main.ts
  │   │   │   ├── lib
  │   │   │   │   ├── backend
  │   │   │   │   │   ├── lambda
  │   │   │   │   │   │   ├── CorsAPIGatewayProxyResult.ts
  │   │   │   │   │   │   ├── Todo.ts
  │   │   │   │   │   │   ├── addTodo.ts
  │   │   │   │   │   │   ├── deleteTodo.ts
  │   │   │   │   │   │   ├── getTodo.ts
  │   │   │   │   │   │   ├── getTodos.ts
  │   │   │   │   │   │   └── updateTodo.ts
  │   │   │   │   │   └── todo-api-stack.ts
  │   │   │   │   └── frontend
  │   │   │   │       ├── build
  │   │   │   │       ├── constants.ts
  │   │   │   │       └── frontend-stack.ts
  │   │   │   └── main.ts
  │   │   ├── test
  │   │   │   └── todo-api.test.ts
  │   │   ├── tsconfig.dev.json
  │   │   └── tsconfig.json
  │   └── frontend
  │       ├── README.md
  │       ├── babel.config.js
  │       ├── jest.config.js
  │       ├── package.json
  │       ├── public
  │       │   ├── index.html
  │       │   ├── manifest.json
  │       │   └── robots.txt
  │       ├── src
  │       │   ├── App.css
  │       │   ├── App.test.tsx
  │       │   ├── App.tsx
  │       │   ├── index.css
  │       │   ├── index.tsx
  │       │   ├── react-app-env.d.ts
  │       │   ├── reportWebVitals.ts
  │       │   ├── setupTests.ts
  │       │   ├── to-do.api.ts
  │       │   └── to-do.types.ts
  │       └── tsconfig.json
  ├── tsconfig.dev.json
  ├── tsconfig.json
  └── yarn.lock

🚀 Push source code to repo

Init the repo and add repo URL which is created from the above as origin

  ➜  git init
  Initialized empty Git repository in /Users/vudao/workspace/codecatalyst/cdk-todo-web-app/.git/
  ➜  git remote add origin https://vumdao@git.us-west-2.codecatalyst.aws/v1/simflexcloud/cdk-todo-web-app/cdk-todo-web-app
  ➜  git branch --set-upstream-to=origin/main main
  branch 'main' set up to track 'origin/main' by rebasing.
  ➜  git pull
  ➜  git add .
  ➜  git commit -m "Init commit"
  ➜  git push origin main

🚀 Workflows Runs

When the commit is pushed to the main branch, CodeCatalyst CI/CD triggers the workflows

The CDKDeploy triggers cloudformation to create AWS resources

After the workflows done, we now have the To-Do Web app UI

🚀 Conclusion

Congratulations! You've successfully bootstrapped and initialized AWS CDK with CodeCatalyst, and you can now deploy infrastructure changes or update frontend/backend using a pull request workflow.

🌠 Blog · Github · stackoverflow · Linkedin · Group · Page · Twitter 🌠

Multi-Tenancy In EKS Cluster Using Vcluster

🚀 Vu Dao 🚀 — Sun, 08 Oct 2023 17:18:34 +0000

Abstract

Why should we consider using Vcluster? Our requirement is to establish multiple environments for developers to facilitate development, testing, as well as regression and performance tests.
The crucial aspect is ensuring that these environments closely mimic the structure of our staging and production environments, which are based on Kubernetes. Instead of relying on Kubernetes namespaces to create these environments, We opt to offer developers a solution that provides them with an environment that closely resembles a real Kubernetes cluster. This is where Vcluster comes into play.
Watch Demo: https://www.youtube.com/watch?v=vWNkGyLajJE
Source code: https://github.com/vumdao/multi-tenancy-using-vcluster-in-eks/tree/master

Abstract
Table Of Contents
🚀 vcluster overview
🚀 Solution overview
🚀 Bootstrap EKS cluster using CDK EKS Blueprints
🚀 Create vcluster
🚀 Expose vcluster using Network Laoad Balancer
🚀 Cleanup

🚀 vcluster overview

https://www.vcluster.com

🚀 Solution overview

🚀 Bootstrap EKS cluster using CDK EKS Blueprints

The bootstrap provisions EKS cluster with required AddOns using CDK EKS blueprints

    new VpcCniAddOn(),
    new MetricsServerAddOn(),
    new KarpenterAddOn(),
    new AwsLoadBalancerControllerAddOn(),
    new EbsCsiDriverAddOn(),

Cluster provider
- Fargate to deploy Karpenter
- Karpenter simplifies Kubernetes infrastructure with the right nodes at the right time.

🚀 Create vcluster

Create two vclusters with namepsace app1 and app2

  $ ./demo/create-vcl.sh app1
  $ ./demo/create-vcl.sh app2

🚀 Expose vcluster using Network Laoad Balancer

Create NLB service

  ✗ k apply -f demo/app1/service.yaml
  service/app1-lb created

  ✗ k apply -f demo/app2/service.yaml
  service/app2-lb created

  ✗ k get svc -n app1 app1-lb
  NAME      TYPE           CLUSTER-IP       EXTERNAL-IP                                                                    PORT(S)         AGE
  app1-lb   LoadBalancer   172.20.150.105   k8s-app1-app1lb-bb32c11098-3381306256798df4.elb.ap-southeast-1.amazonaws.com   443:32392/TCP   30h

  ✗ k get svc -n app2 app2-lb
  NAME      TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)         AGE
  app2-lb   LoadBalancer   172.20.78.127   k8s-app2-app2lb-4690ffbcfe-bfb88a1245728e8a.elb.ap-southeast-1.amazonaws.com   443:31510/TCP   49s

Create CName record point to the NLB DNS

  ➜  multi-tenancy-in-eks-using-vcluster git:(master) ✗ ./demo/r53-record.sh create app2
  ➜  multi-tenancy-in-eks-using-vcluster git:(master) ✗ ping app2-eks.simflexcloud.com
  PING k8s-app2-app2lb-4690ffbcfe-bfb88a1245728e8a.elb.ap-southeast-1.amazonaws.com (13.250.162.120): 56 data bytes

Now we can connect to the vcluster app1 and app2 using their expose endpoint

✗ vcluster connect app2 -n app2 --server=https://app2-eks.simflexcloud.com --update-current=false
done √ Virtual cluster kube config written to: ./kubeconfig.yaml
- Use `kubectl --kubeconfig ./kubeconfig.yaml get namespaces` to access the vcluster

🚀 Deploy applications on vcluster

Deploy echo and guestbook project

  ✗ ka2 apply -f demo/app2/vcluster
  ingress.networking.k8s.io/echo created
  deployment.apps/echo created
  service/echo created
  ingress.networking.k8s.io/guestbook created
  service/redis-leader created
  deployment.apps/redis-leader created
  service/redis-follower created
  deployment.apps/redis-follower created
  service/frontend created
  deployment.apps/frontend created

Get ALB DNS and point to the Web app endpoint

✗ ka2 get ingress
NAME        CLASS   HOSTS   ADDRESS                                                          PORTS   AGE
echo        alb     *       k8s-app2-dbb948e3be-939359744.ap-southeast-1.elb.amazonaws.com   80      10s
guestbook   alb     *       k8s-app2-dbb948e3be-939359744.ap-southeast-1.elb.amazonaws.com   80      10s
✗ ./demo/r53-record.sh create app2 k8s-app2-dbb948e3be-939359744.ap-southeast-1.elb.amazonaws.com

🚀 Cleanup

Delete vcluster

  ✗ vcluster delete dev -n dev
  info   Delete vcluster dev...
  done √ Successfully deleted virtual cluster dev in namespace dev
  done √ Successfully deleted virtual cluster pvc data-dev-0 in namespace dev

Destroy all AWS resources within this project

🚀 Vu Dao 🚀 Follow

🚀 AWSome Devops | AWS Community Builder | AWS SA || ☁️ CloudOpz ☁️

vumdao / vumdao

Single-Sign-On By Vouch Proxy And AWS Cognito

🚀 Vu Dao 🚀 — Wed, 31 May 2023 15:55:04 +0000

Abstract

For Kubernetes cluster, we have many observability and monitoring tools which are built-in with separated dashboard/console UIs with login-authentication. We don't want to create many domains as well as multiple accounts to handle them. This post introduces vouch proxy as a solution to provide single-sign on which supports many OAuth and OIDC login providers and can enforce authentication to AWS Cognito user pool.

Vouch Proxy Overview
What Exactly Vouch Proxy Does?
How does vouch-proxy protect the domains?
Setup AWS Cognito as authorised provider
Deploy vouch-proxy and nginx
Troubleshooting
Conclusion

🚀 Vouch Proxy Overview

Vouch Proxy - An SSO solution for Nginx using the auth_request module. Vouch Proxy can protect all of your websites at once.
Vouch Proxy supports many OAuth and OIDC login providers and can enforce authentication to... This blog introduces applying vouch-proxy with AWS Cognito userpool
In this blog post, we apply this solution for Applications such as Solr Cloud, AKHQ, and glowroot in Kubernetes cluster where vouch proxy and nginx are also deployed on.

🚀 What Exactly Vouch Proxy Does

Diagram

The flows
1. User access to one of the subpaths such as /solr for Solr Admin UI through https://sso.simflexcloud.com/solr
2. The request is go to AWS Application load balancer and then forwarded to NGINX target group
3. Nginx authorizes the request by calling/validating the request using vouch-proxy through the internal endpoint http://vouch:9090/validate of Kubernetes service
4. Vouch-proxy validates and returns 200 if the user already has the cache login token or returns 401 if not yet performed login
  - With 200 code, the request is redirected to the target location here is Solr UI admin
  - With 401 code, the request is redirected to https://vouch.simflexcloud.com/login?url=https://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$auth_resp_err> to login, if the login is successful, the request is redirected to the target location here is Solr UI admin
5. Default redirect is the main page or marketing page or anything you would like to show as your SSO

🚀 How does vouch-proxy protect the domains?

Vouch-proxy (VP) supports many OAuth and OIDC login providers to authentication
Furthermore, vouch-proxy whitelists the domains, not only the access domain but also the domain of email login. The cookie domain, the domain that VP is served from and the protected app must all be the same domain. For example, if we just whitelist the app domain such as simflexcloud.com but the email is simflex.cloud@gmail.com it will not authorize the user ```

2022-07-07T15:58:12.716Z WARN /auth User is not authorized: verifyUser: Email simflex.cloud@gmail.com is not within a Vouch Proxy managed domain . Please try again or seek support from your administrator


## 🚀 **Setup AWS Cognito as authorised provider** <a name="Setup-AWS-Cognito-as-authorize-provider"></a>
- Pre-requisite: You already create Coginto user for login authentication.

- Cognito userpool application client

  <img src=https://raw.githubusercontent.com/vumdao/sso-vouch-proxy/master/images/cognito-sso.png width=1100>

- Setup vouch-proxy config with AWS Cognito, replace the URLs with one's setup from Cognito

vouch:
logLevel: debug
port: 9090

cookie:
  secure: false

domains: # app domain and mail domain only
- simflexcloud.com
- gmail.com

oauth:
provider: oidc
client_id: AWS_COGNITO_VOUCH_CLIENT_ID
auth_url: https://{yourCognitoDomain}.amazoncognito.com/oauth2/authorize
token_url: https://{yourCognitoDomain}.amazoncognito.com/oauth2/token
user_info_url: https://{yourCognitoDomain}.amazoncognito.com/oauth2/userInfo
scopes:
- openid
- email
- profile
callback_url: https://{callbackURL}/auth


## 🚀 **Deploy vouch-proxy and nginx** <a name="Deploy-vouch-proxy-and-nginx"></a>
- Go to [nginx](https://github.com/vumdao/sso-vouch-proxy/tree/master/nginx) to get Dockerfile, nginx config files to build the `nginx-gw` image
- Use the `quay.io/vouch/vouch-proxy` image to start vouch-proxy by mounting the config file to `/config/config.yml`

## 🚀 **Troubleshooting** <a name="Troubleshooting"></a>
- Getting started to align between Nginx, Vouch Proxy and your identity provider (IdP) can be tricky, vouch-proxy provides a config to enable the testing mode

vouch:
testing: true
logLevel: debug


- With testing enable, the UI will step us to each phase of redirecting

  <img src=https://raw.githubusercontent.com/vumdao/sso-vouch-proxy/master/images/vp-1.png width=1100>

  <img src=https://raw.githubusercontent.com/vumdao/sso-vouch-proxy/master/images/vp-2.png width=1100>

## 🚀 **Conclusion** <a name="Conclusion"></a>
- Now we have SSO domain to access all the services conveniently and it's possible to add any more subpath for other services. The session with Congito userpool token has expired time and we can update this timeout through Cognito attributes.

---


    
      
        
      
    
  
    
🚀 Vu Dao 🚀 Follow

    
      🚀 AWSome Devops | AWS Community Builder | AWS SA || ☁️ CloudOpz ☁️
    
  



  
    
      
      
        vumdao
       / 
        vumdao

FastApi With AWS Serverless powered by CDK Typescript

🚀 Vu Dao 🚀 — Sun, 21 May 2023 07:05:20 +0000

Abstract

Deploy FastAPI in a Lambda function that is fronted by an HTTP API in API Gateway, you can enable API key required for the API

Solution overview
Build FastAPI as lambda funnction handler
Deploy
Test API
Conclusion

🚀 Solution overview

Use AWS APIGW to build a simple API server with lambda integration
APIGW route paths such as /api/v1/ and /chat_gpt/ require API key (with usage plan)
The lambda function contains FastApi code to serves API requests and responses.
Let's see the stack relationships

🚀 Build FastAPI as a lambda funnction handler

Lambda handler source code



  ➜  simple-serverless-fastapi tree src/lambda-handler
  src/lambda-handler
  ├── api
  │   └── api_v1
  │       ├── api.py
  │       └── endpoints
  │           └── users.py
  ├── main.py
  └── requirements.txt

  4 directories, 4 files

Direct route paths include / and chat_gpt ```

@app.get("/")
async def root():
return {"message": "FastAPI running in a Lambda function"}

@app.get("/chat_gpt/")
async def read_chatgpt(question: str = None):
return {"message": f"We got question: {question}"}


- Restructure FastAPI Routing for developing API and optimize source code by using `APIRouter`

src/lambda-handler/api
└── api_v1
├── api.py
└── endpoints
└── users.py

from api.api_v1.api import router as api_router
app.include_router(api_router, prefix="/api/v1")


- For the lambda function handler, we use [`Mangum`](https://pypi.org/project/mangum/) python module which is an adapter for running ASGI applications in AWS Lambda to handle Function URL, API Gateway, ALB, and Lambda@Edge events.

- For building API Docs, one must set the following parameters in `FastApi()` constructor to resolve `/openapi.json` correctly
  - For API URL using APIGW stage URL, set `root_path` equal to the API stage name, eg. `root_path=/AppAPI`
  - For API custom domain
    ```


    docs_url='/docs',
    openapi_url='/openapi.json',

🚀 Deploy

For production, building CDK pipeline for this is the best practice.
For the demo, I run cdk deploy manually ```

➜ simple-serverless-fastapi cdk deploy
✅ SimpleFastApiServerless

✨ Deployment time: 72.44s


- The API GW and method request

  <img src=https://raw.githubusercontent.com/vumdao/simple-serverless-fastapi/master/images/apigw.png width=1100>

  <img src=https://raw.githubusercontent.com/vumdao/simple-serverless-fastapi/master/images/chat_gpt.png width=1100>

- Custom domain mapped to the API

  <img src=https://raw.githubusercontent.com/vumdao/simple-serverless-fastapi/master/images/custom-domain.png width=1100>

## 🚀 **Test API** <a name="Test-API"></a>
- Open API Docs

  <img src=https://raw.githubusercontent.com/vumdao/simple-serverless-fastapi/master/images/api_docs.png width=1100>

- Call `/chat_gpt` with API key and query `question`

➜ simple-serverless-fastapi curl -X GET -H "Content-Type: application/json" -H 'x-api-key: 6sUnYj8PAw8MKu8O6FqSw1kf1clmC0Fx8ilQhVeO' https://chatgpt.simflexcloud.com/chat_gpt/ -d 'question=how%20are%20you' -G
{"message":"We got question: how are you"}


## 🚀 **Conclusion** <a name="Conclusion"></a>
- We created a FastAPI application using AWS Serverless. The user must provide the API key to query request and the API key is associated with the usage plan where we can specify who can access the deployed API stages and methods, and optionally sets the target request rate to start throttling requests.

---

References:
- [Simple Serverless FastAPI with AWS Lambda](https://www.deadbear.io/simple-serverless-fastapi-with-aws-lambda/)

---


    
      
        
      
    
  
    
🚀 Vu Dao 🚀 Follow

    
      🚀 AWSome Devops | AWS Community Builder | AWS SA || ☁️ CloudOpz ☁️
    
  



  
    
      
      
        vumdao
       / 
        vumdao

Amazon ECS Farget with Blue-Green Deployments by CDK Typescript - Part 2

🚀 Vu Dao 🚀 — Wed, 17 May 2023 15:25:49 +0000

Abstract

Continue the previous post Hands-on Amazon ECS for Blue-Green Deployments With CDK Typescript which uses EC2 to host the ECS container service and manually operate blue-green deployments. In this blog post, I use AWS Fargate as a container of ECS service and codedeploy to operate blue-green deployment automatically.

Solution overview
Source code structure
Process flow
Cleanup
Conclusion

🚀 Solution overview

The whole AWS resources are created using CDK pipeline except the pipeline itself.
The ECS cluster is placed in private subnet as well as the fargate service. We create ECS service with task definition that has desired count of 3 and use FARGATE as requiresCompatibilities
The ECS service is registered to ECS deployment controller with the type CODE_DEPLOY for handling blue-green deployment. It sticks the application load balancer to the replacement target group when deploying successfully.
A container image is built with codepipeline and codebuild which store images to ECR.
Here is the stacks relationship

🚀 Source code structure

We have two Git repositories (codecommit) one for application project app-project directory and others for CDK infrastructure cdk-infra directory



  ➜  ecs-blue-green-deployments tree -L 1
  .
  ├── README.md
  ├── app-project
  ├── cdk-infra
  └── images

  3 directories, 1 file

We create the codecommit repositories through CDK
- Go to cdk-infra and run cdk ls ```
cdk ls
simflexcloud-ecs-blue-green-deployments-pipeline
simflexcloud-ecs-blue-green-deployments-pipeline/master-sin/EcsBlueGreenDeploymentsStack


  - Deploy `simflexcloud-ecs-blue-green-deployments-pipeline` it will create the repository of `cdk-infra`. Note: replace `CDK_DEFAULT_ACCOUNT` and `CDK_DEFAULT_REGION` in `cdk-infra/src/shared/constants.ts` with expected ones.
    ```


    cdk deploy simflexcloud-ecs-blue-green-deployments-pipeline

Add the remote Git repository to cdk-infra (Note: Replace the priv-acc with yours)



git remote add origin ssh://priv-acc/v1/repos/ecs-blue-green-deployments-infra


  - Create branch `master` and push source code to the repo, it will trigger CDK pipeline to create all stacks which also include the repository and pipeline for `app-proj`

  - After the pipeline is completed successfully, go to `app-proj` directory and add Git remote repository, then create the branches `testgreen` and `testblue` and push them to codecommit
    ```


    git remote add origin ssh://priv-acc/v1/repos/simflexcloud-ecs-blue-green-deployments

🚀 Process flow

1. Build project

Use AWS CodeBuild to create Docker images and store them in Amazon ECR. This process is powered by codepipeline to handle CICD.

2. Create ECS cluster

Create an Amazon ECS cluster using fargate.

3. Application load balancer

We have two rules:
- Port 80: the main rule
- Port 8080: testing rule
The ALB is currently stuck to the target group of green

4. CodeDeploy application and deployment group

A CodeDeploy deployment group that orchestrates ECS blue-green deployments.

🚀 Test the blue-green deployments

Test the blue service by loading ALB DNS

Now we change the color to red in app-proj/index.html and push the commit to CodeCommit. It triggers the pipeline to build and then deploy a new change

The deploy stage creates codedeploy deployment ID to perform the deployment process and handle the Traffic shifting progress strategy with rule LINEAR_10PERCENT_EVERY_1MINUTES (CodeDeploy predefined deployment configuration that shifts 10 percent of traffic every minute until all traffic is shifted)

ECS run new tasks with new image version on the ECS service

After the new tasks are in healthy state, the deployment starts rerouting production traffic to replacement task set gradually following the rule LINEAR_10PERCENT_EVERY_1MINUTES

Use port 8080 for testing and compare with current version

Complete the replacement and start terminating the original task set

ECS remove the tasks with old revision

The final result

🚀 Cleanup

To cleanup all resources in this project, we first need to delete the ECR image as they were not created by CDK and prevent CDK to destroy the ECR repository.
Go to cloudformation and delete stacks.

🚀 Conclusion

Now that you know how to launch tasks into your Amazon ECS cluster using CDK pipeline with the required type EC2 or Fargate.
The approach of a blue-green deployment involves utilizing two identical production environments as a means of reducing downtime. Various cutover strategies may be employed, but typically only one of the environments should be actively serving production traffic.

References:

BLUE/GREEN DEPLOYMENTS ON ECS FARGATE

🚀 Vu Dao 🚀 Follow

🚀 AWSome Devops | AWS Community Builder | AWS SA || ☁️ CloudOpz ☁️

vumdao / vumdao

Hands-on Amazon ECS for Blue-Green Deployments With CDK Typescript - Part 1

🚀 Vu Dao 🚀 — Wed, 10 May 2023 15:38:26 +0000

Abstract

This blog post supports you in hands-on AWS ECS by building the Blue-Green Deployments With CDK Typescript. Instead of using AWS console to create all necessary resources, you will create them through CDK code and automate deployment with CDK pipeline for both project application and infrastructure as code.

Solution overview
Source code structure
Process flow
Cleanup
Conclusion

🚀 Solution overview

The whole AWS resources are created using CDK pipleine except the pipeline itself.
The ECS cluster is placed in a private subnet with EC2 instances which is managed by the autoscaling group. We create two services which are Blue and Green, there should be only one service that has a desired count > 0 and the other is 0 at the time so that the application load balancer always forwards the request to one of them.
A container image is built with codepipeline and codebuild which store images to ECR.

🚀 Source code structure

We have two Git repositories (codecommit) one for application project app-project directory and others for CDK infrastructure cdk-infra directory

  ➜  ecs-blue-green-deployments tree -L 1
  .
  ├── README.md
  ├── app-project
  ├── cdk-infra
  └── images

  3 directories, 1 file

We create the codecommit repositories through CDK
- Go to cdk-infra and run cdk ls
```
cdk ls
simflexcloud-ecs-blue-green-deployments-pipeline
simflexcloud-ecs-blue-green-deployments-pipeline/master-sin/EcsBlueGreenDeploymentsStack
simflexcloud-ecs-blue-green-deployments-pipeline/master-sin/simflexcloud-ecs-blue-green-deployments-build-image
```
- Deploy simflexcloud-ecs-blue-green-deployments-pipeline it will create the repository of cdk-infra. Note: replace CDK_DEFAULT_ACCOUNT and CDK_DEFAULT_REGION in cdk-infra/src/shared/constants.ts with expected ones.
```
cdk deploy simflexcloud-ecs-blue-green-deployments-pipeline
```
- Add the remote Git repository to cdk-infra (Note: Replace the priv-acc with yours)
```
git remote add origin ssh://priv-acc/v1/repos/ecs-blue-green-deployments-infra
```
- Create branch master and push source code to the repo, it will trigger CDK pipeline to create all stacks which also include the repository and pipeline for app-proj
- After the pipeline completed successfully, go to app-proj directory and add Git remote repository, then create the branches testgreen and testblue and push them to codecommit
```
git remote add origin ssh://priv-acc/v1/repos/simflexcloud-ecs-blue-green-deployments
```

🚀 Process flow

1. Build project

Use AWS CodeBuild to create Docker images and store them in Amazon ECR. This process is powered by codepipeline to handle CICD. We need to build two image tags which are testgreen based on branch testgreen and testblue based on branch testblue. Any commits from these branches will trigger pipelines to execute build projects based on the buildspec.yml and Dockerfile.

2. Create ECS cluster

Create an Amazon ECS cluster using EC2 as container instance. The EC2 instance is attached an IAM role which includes AmazonEC2ContainerServiceforEC2Role policy for the ECS agent to connect to ECS cluster.
Task definitions are required to run Docker containers in Amazon ECS. They tell the services which Docker images to use for the container instances, what kind of resources to allocate, network specifics, and other details. We create two task definitions which are Blue and Green. In the task, we define image tag, task size, container port, Task execution role, etc.
With ECS, we can easily deploy and manage containerized applications at scale, while benefiting from features such as automatic scaling, load balancing, and automatic service discovery. It resembles Auto Scaling in that it keeps a specified number of instances, but unlike Auto Scaling, it doesn't adjust the number of instances in response to CloudWatch alarms or other Auto Scaling mechanisms. By utilizing a load balancer, it is possible to maintain a specified amount of resources while ensuring a singular application reference point. As such, we generate two distinct services, one for the blue application and the other for the green application. Only one service is active (has desire count greater than zero) at a time.
Due to desired tasks 2, the service creates 2 containers on the EC2 instance and expose the public port for ALB target group, mapping to container port 8081.

3. Test the blue green deployments

Test the blue service by calling the /api request with ALB DNS
Now we switch deployment to green service by updating desiredCount from blue to 0 and from green to 2 then deploy.
We see targetgroup add new target port and draining the old one

🚀 Cleanup

To cleanup all resoures in this project, we first need to delete the ECR image as they were not created by CDK and prevent CDK to destroy the ECR repository.
Go to cloudformation and delete stacks.

🚀 Conclusion

Now that you know how to launch tasks into your Amazon ECS cluster using CDK pipeline
The approach of a blue-green deployment involves utilizing two identical production environments as a means of reducing downtime. Various cutover strategies may be employed, but typically only one of the environments should be actively serving production traffic.

🌠 Blog · Github · stackoverflow · Linkedin · Group · Page · Twitter 🌠

🚀 Vu Dao 🚀 Follow

🚀 AWSome Devops | AWS Community Builder | AWS SA || ☁️ CloudOpz ☁️

Forem: 🚀 Vu Dao 🚀

CI Load Test for http-echo using Kind and k6

Assignment

Solution Overview

Architecture

Project Structure

Prerequisites

CI Workflow

Stage 1: Environment Setup

Stage 2: Cluster Provisioning

Stage 3: Load Testing

Stage 4: Results Analysis

🚀 Load Testing Configuration

📊 Test Execution Stages

⚡ Performance Thresholds

📈 Custom Metrics & Monitoring

🎯 Host-Specific Metrics

🔍 Real-Time Tracking

📋 Test Results & Output

🖥️ Console Output

📄 Detailed Reports

📊 Key Metrics Captured

📊 Monitoring and Metrics

k6 Metrics Collection

📋 Sample Test Results

📝 Project Completion Notes

💡 Development Experience

Self-Hosted N8N on AWS ECS with AWS CDK Typescript

📋 Abstract

📑 Table of Contents

🏗️ Architecture Overview

🔍 Deep-Dive the Solution

🚀 Deploy CDK Stack and Test

📋 Prerequisites

⚙️ Environment Setup

🚀 Deployment Steps

✅ Verify Deployment

🧪 Testing N8N Workflows

🧹 Cleanup Stack

🎉 Conclusion

📚 References

ClamAV (Anti-Virus) as a REST application on AWS ECS

📋 Abstract

📚 Table of Contents

⚠️ Opening Problems

🏗️ Architecture Overview

💻 Infrastructure as Code with AWS CDK

🔧 Core Infrastructure

📦 Application Components

🔍 Deep-dive the Solution

🛡️ 1. ClamAV REST API on ECS Fargate

📢 2. Result Notification System

🚀 Deploy CDK Stack and Test

✅ Prerequisites

📥 Installation and Deployment

🧪 Testing the Solution

🧹 Cleanup Stack

🎯 Conclusion

CDK AWS Aurora PostgreSQL Limitless

Abstract

Table Of Contents

🚀 Deploying Aurora PostgreSQL Limitless Database Using AWS CDK

🚀 Test

🚀 Check workload and scaling

🚀 Cleanup

🚀 Conclusion

ECS service-to-service communication

Abstract

🚀 Amazon ECS Service Connect

🚀 AWS ECS Service Connect vs Service Discovery

🚀 Deploying Sample Yelb Application for service connect with Amazon ECS and AWS CDK Typescript

📖 Solution overview

📖 CDK Stacks

🚀 Walkthrough

🚀 Cleaning up

🚀 Conclusion

References

Empowering Amazon CodeCatalyst: Workflows as Code with CodeCatalyst-Blueprints

Abstract

Table Of Contents

🚀 Write `blueprint.ts` to build worksflow