DEV Community: Dickson Victor

Getting Started with Amazon ECS Express Mode

Dickson Victor — Wed, 24 Dec 2025 17:24:55 +0000

Meet Jake, a backend developer, who just wanted to deploy his Node.js API to ECS. Three hours in, he was Googling "what is a target group" and "do I need a NAT gateway", while his Docker container sat there, perfectly functional, mocking him from his laptop. He'd configured VPCs, subnets, load balancers, security groups, and IAM roles—basically becoming an accidental cloud architect just to run one container. His manager's Slack message still haunted him: "Should be a quick deploy, right?"

Then Amazon announced ECS Express Mode. Now Jake enters his container image, picks two IAM roles, and clicks Create. Done. ECS handles the networking, load balancing, and scaling automatically—even gives him an HTTPS endpoint. He deployed in 10 minutes and actually went home on time. The infrastructure is still there when he needs to customize it, but for once, ECS doesn't make him fight for it.

Amazon ECS Express Mode service reduces the complexity of deploying containerized applications by providing sensible defaults and automating the configuration of supporting AWS services. It orchestrates and configures all necessary infrastructure: a Fargate-based ECS service with a unique accessible URL, load balancer with SSL/TLS ( can automatically consolidate up to 25 Express Mode services behind a single ALB), auto scaling policies (automatically scale based on utilization or traffic), monitoring, and networking components.

Here’s What Jake Benefits By Using ECS Express Mode:

1. Simplified Deployment
Remember Jake's three-hour odyssey through AWS documentation? That's now a one-liner in the CLI or a few clicks in the console. You provide your container image and a couple of IAM roles, and ECS Express Mode does the heavy lifting. No more tab-hopping between CloudFormation docs, ECS guides, and that one Stack Overflow answer from 2019 that might still be relevant.

2. Automated Infrastructure
Express Mode automatically provisions everything Jake was manually configuring at 11 PM: ECS clusters, Application Load Balancers, auto-scaling policies, VPC networking, security groups, and CloudWatch Logs. It's like having a senior DevOps engineer who actually reads AWS documentation and doesn't make typos in YAML files. All the pieces that usually require you to understand the intricate relationships between subnets, route tables, and internet gateways? Handled.

3. Focus on Code
Here's the revolutionary part: you get to be a developer again. Not a part-time network architect, not an amateur security group debugger, not someone who needs to explain to their non-technical manager why deploying a container takes longer than writing the actual application. Express Mode lets you do what you actually signed up for— writing code and shipping features.

4. Production-Ready Defaults
Express Mode doesn't just throw something together and wish you luck. You get secure, scalable configurations with health checks, monitoring, and even a working HTTPS URL right out of the box. It's production-ready from day one, not "well, it works on my machine and I think it'll be fine in prod" ready. Jake can actually deploy on a Friday without his manager giving him the side-eye.

5. Full ECS Power Available
Here's what makes this different from other "easy mode" solutions that lock you into a walled garden: all the standard ECS capabilities are still there. When Jake inevitably needs to add a custom health check endpoint, tweak the auto-scaling thresholds for that Black Friday traffic spike, or integrate with an existing VPC, he can. Express Mode gives you the training wheels, but it doesn't weld them on permanently. It's the fast path to getting started, not a dead end.

Demo Time!

Now let’s get hands-on by deploying a simple nginx container. Follow these steps to deploy your containerized application in minutes.

Prerequisites
Before you start, make sure you have:

A container image stored in Amazon ECR (or a private registry with Secrets Manager configured)
An AWS account with appropriate permissions
Your application's container port number (e.g., 80, 8080, 3000)

Step-by-Step Deployment

Step 1: Navigate to ECS Express Mode

Open the AWS Console and navigate to the Amazon ECS console
In the left navigation pane, click on Express mode
Click the Create button to start your deployment

Step 2: Configure Your Container Image
1. Image URI: Enter your container image URI from Amazon ECR

Click Browse ECR images to easily find your image
Select your repository and image
Choose how to identify the image (AWS recommends using **Image digest **for consistency)

2. Service Name (Optional): Give your service a descriptive name

If you leave this blank, Express Mode generates one from your image name
This name appears in your Application URL and across AWS resources

Step 3: Configure Application Settings

Container port: Enter the port your application listens on (default is 80)
Health check path: Specify the endpoint for health checks (default is "/")
If your app has a dedicated health endpoint like /health or /api/health, use that
Keep health checks lightweight—avoid expensive database queries or external API calls

Step 4: Add Environment Variables (Optional)
If your application needs environment variables (database URLs, API keys, feature flags), add them here:

Click Add environment variable
Enter key-value pairs (e.g., DATABASE_URL, API_KEY)
For sensitive values, consider using AWS Secrets Manager references instead

Step 5: Override Container Command (Optional)
The Command field lets you override the Docker CMD instruction from your Dockerfile:

Enter comma-delimited commands and parameters (e.g., echo,hello world)
This is useful when you want to run different commands without rebuilding your container image
Leave blank to use the default CMD from your Dockerfile
Common use cases: running migration scripts, starting with different flags, or debugging

Step 6: Configure Task Role (Optional but Recommended)
The Task role is different from the Task Execution Role you configured earlier.
If your application needs to interact with AWS services (S3, DynamoDB, SQS, etc.):

Click Choose the task role dropdown
Select an existing IAM role or click Create new role
Grant only the permissions your application actually needs (principle of least privilege)
Example: If your app uploads files to S3, attach a policy with s3:PutObject permissions Note: Without a Task role, your application can't make authenticated AWS API calls.

Step 7: Configure Compute Resources
Express Mode uses AWS Fargate by default, so no EC2 instances to manage. But you still need to size your containers appropriately:
CPU and Memory:
1. CPU: Select the vCPU allocation for your task (0.25, 0.5, 1, 2, 4, 8, or 16 vCPU)
2. Memory: Choose memory based on your CPU selection

Each CPU tier has specific memory options
For example, 1 vCPU supports 2GB to 8GB of memory
Start conservative and scale up if needed—you can always adjust later

Step 8: Configure Auto Scaling
Express Mode automatically sets up intelligent auto-scaling, but you can customize it:
ECS Service Metric:

Select the metric that triggers scaling (default: Average CPU utilization)
Other options include average memory utilization and request count per target
CPU is usually the right choice for most web applications Express Mode uses target tracking scaling, which means it continuously adjusts your task count to maintain your target metric. When traffic drops, it automatically scales down to save costs.

Step 9: Customize Networking (Optional)
By default, Express Mode uses your default VPC and handles all networking automatically. But if you need custom networking:

Check Customize networking configurations
Select your preferred VPC from the dropdown
Choose Subnets where your services will run
Configure Security groups if you need additional inbound access
Express Mode creates sensible security group rules by default
Only customize if you have specific requirements

Step 10: Configure Logging (Optional)
Express Mode automatically sets up CloudWatch Logs, but you can customize:

CloudWatch log group name: Default is based on your cluster and service names
Log stream prefix: Default is ecs
Adjust these if you have specific logging conventions in your organization

Step 11: Add Tags (Optional)
Tag your resources for cost tracking and organization:

Add key-value pairs like Environment: Production or Team: Backend
These tags apply to all resources Express Mode creates

Step 12: Deploy!

Review your configuration
Click Create
Sit back and watch Express Mode work its magic

What Happens Next?
Once you click Create, Express Mode automatically provisions (See attached Screenshot):

✅ ECS cluster (or uses the default one)

✅ ECS service with Fargate tasks

✅ Application Load Balancer with health checks

✅ Auto-scaling policies based on CPU utilization

✅ Security groups and networking configuration

✅ A custom HTTPS URL (automatically generated and ready to use!)

✅ CloudWatch Logs for application monitoring

Once complete, you'll see your Application URL — click it to access your running application

To delete the service with all the resources created, simply click the “Delete Service” button.

CONCLUSION

From Infrastructure Nightmare to Deployment Dream

One thing makes the new Amazon ECS Express Mode great—it meets developers where they are: A developer can safely say "I have a container, I want it running, and I'd like to go home before midnight." The beauty isn't just the 10-minute deployment; it's the mental overhead it eliminates. You no longer need to be a VPC expert just to ship an API. But here's the genius: when you need fine-grained control later, it's all still there. Express Mode isn't a walled garden—it's the on-ramp to production-ready infrastructure without the pain. Jake deployed in 10 minutes, went home on time, and when his manager asked how it went, he just shrugged and said, "Easy." For the first time in his AWS journey, he wasn't lying.

All Images courtesy unsplash

Key Notes from Migrating 7 Microservices to Amazon ECS

Dickson Victor — Wed, 22 Oct 2025 00:08:56 +0000

I recently lead a project where I migrated a customer’s application backend to AWS. Its an e-commerce/marketplace platform with its core backend built with a microservices architecture.
Here are key notes to consider when migrating a similar workload.

1. Infrastructure as Code is Essential

Use Terraform with modular architecture for consistent deployments
Separate modules for ECS services, task definitions, and target groups
Environment-specific configurations (e.g prod.tfvars) for scalability

2. Service Discovery & Communication

Implemented AWS Service Connect for inter-service communication
Both HTTP and gRPC endpoints configured for each service
Service mesh approach eliminates hardcoded service endpoints

3. Load Balancing Strategy

Single ALB with path-based routing e.g (/admin/* , /order/* , etc.)
Priority-based listener rules for 7 services
Cost-effective compared to individual load balancers per service

4. Security & Configuration Management

AWS Systems Manager Parameter Store for environment variables
IAM roles with least-privilege access per service
Secrets management separated from application code

5. Observability & Monitoring

Centralized logging with CloudWatch Log Groups
Service-specific log streams for easier debugging
Health check endpoints for each service

6. Deployment & Scaling Considerations

Fargate for serverless container management
Circuit breaker pattern for deployment safety
Auto-scaling capabilities

7. Network Architecture

Multi-AZ deployment across 3 availability zones
Public subnets for ALB, private subnets for services
Security groups for network-level isolation

8. Service Organization

Clear service boundaries: admin, notification, order, ship, store, user, wallet
Consistent naming conventions and tagging strategy
Modular Terraform structure for maintainability

9. Container Strategy

ECR for private container registry
Standardized port configurations (HTTP + gRPC)
Resource allocation (CPU/memory) per service requirements

10. Operational Excellence

GitHub Actions for CI/CD automation
Terraform state management for team collaboration
Parameter scripts for environment setup automation

These lessons demonstrate a well-architected microservices migration focusing on scalability, security, and operational efficiency.

Fargate vs EC2-Based ECS: Key Migration Lessons

Why Fargate Was Chosen

1. Operational Simplicity

No EC2 instance management (patching, scaling, monitoring)
AWS handles underlying infrastructure completely
Eliminated capacity provider complexity

2. Cost Optimization for Microservices

Pay-per-task model better for 7 small services
No idle EC2 capacity costs
Right-sizing at container level (256 CPU, 512 MB per service)

3. Security Benefits

No SSH access or EC2 security hardening needed
Automatic security patches by AWS
Network isolation at task level with awsvpc mode

4. Simplified Networking

Each task gets its own ENI
Direct security group assignment to tasks
No port mapping conflicts between services

5. Auto-scaling Efficiency

Task-level scaling vs instance-level
Faster cold starts for microservices
No pre-provisioned capacity waste

Trade-offs Accepted

1. Higher Per-vCPU Cost

Fargate costs ~40% more than EC2 equivalent
Justified by reduced operational overhead

2. Limited Customization

No access to underlying OS
Can't install custom agents or tools
Fixed networking and storage options

3. Cold Start Considerations

Slightly longer task startup times
Mitigated with health check grace periods ( in my case 120s)

Fargate Sweet Spot

For 7 lightweight microservices with variable traffic, Fargate eliminated infrastructure management complexity while providing better resource utilization than maintaining EC2 instances that would often run underutilized.

Deploying A Dockerized Golang App To AWS App Runner

Dickson Victor — Sat, 06 Sep 2025 00:24:37 +0000

AWS App Runner is a fully managed container application service offered by Amazon Web Services (AWS). It is designed to simplify the process of building, deploying, and scaling containerized web applications and API services.

In this demo, we will deploy a containerised golang app with a mongodb database running on EC2, to AWS AppRunner.

To begin, we will clone the project repo on github to our local machine. The project is a task management app that saves data to a mongodb database.

The project contains a dockerfile. We will use github actions to build and push the docker image to Amazon ECR. Ensure you have created the ecr repository.

name: Build and Push to ECR

on:
  push:
    branches: ['main']

env:
  AWS_REGION: 'eu-west-1'
  ECR_REPOSITORY: 'tasky'
  ACCOUNT_ID: '<fill in>'
  ROLE_NAME: 'github-actions-role'

permissions:
  id-token: write
  contents: read

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ env.ACCOUNT_ID }}:role/${{ env.ROLE_NAME }}
          role-session-name: github_action_session
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:latest .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:latest

Since AWS strongly recommends OIDC (OpenID Connect) over long-term access keys, we will configure oidc for the role 'github-actions-role'.

First, Create the OIDC provider:

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1 \
  --profile

Next, configure an IAM role “github-actions-role“ with an IAM policy that gives github actions runner the required permssion to push to ECR, add a trust policy similar to the following:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<Account-ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:<github-username>/tasky:ref:refs/heads/main"
        }
      }
    }
  ]
}

Push your changes to the github repo and the workflow should be triggered.

Navigate to the ECR console to view the docker image in the repository.

Deploying The MongoDB instance on EC2

Navigating to the EC2 console and launch a t3.micro ubuntu instance. Ensure to have the following in your Security Group Configuration apart from SSH port 22:

Type: Custom TCP
Port: 27017
Source: 0.0.0.0/0

Connect to the instance terminal and use the following commands to install MongoDB.
First, Install the public key using the following command.

curl -fsSL https://pgp.mongodb.com/server-7.0.asc | sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg

Next, Add sources (Mongo 7.0 repo).

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

Reload the local package database and install the MongoDB packages using the command.

sudo apt update
sudo apt install -y mongodb-org

To check if MongoDB is installed or not, verify using the following command.

mongod --version

Run the following commands to start mongodb.

sudo systemctl start mongod
sudo systemctl enable mongod
sudo systemctl status mongod

You should see an output similar to the following;

Creating a MongoDB User and Password

MongoDB doesn't have a default password when installed on Ubuntu. By default, MongoDB runs without authentication enabled.

Connect to MongoDB (no password needed initially):

mongosh

Create an admin user:

use admin
db.createUser({
  user: "admin",
  pwd: "yourstrongpassword",
  roles: ["userAdminAnyDatabase", "readWriteAnyDatabase"]
})

MongoDB Configuration:

By default, the MongoDB server (mongod) only allows loopback connections from IP address 127.0.0.1 (localhost). To allow connections from elsewhere in your Amazon VPC, do the following:

Edit the /etc/mongod.conf file and look for the following lines.

# network interfaces
net:
  port: 27017
  bindIp: public-dns-name  # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses

NB: Replace public-dns-name with the actual public DNS name for your instance, for example ec2-11-22-33-44.us-west-2.compute.amazonaws.com.

To enable authentication in config, Add:

security:
  authorization: enabled

Then, Restart MongoDB:

sudo systemctl restart mongod

Creating The AppRunner Service

Navigate to the Apprunner console, click “Create Service“ button

Click “Next” and on the “Configure service” page, fill in the required environment variables such as below;

NOTE:
When specifying the hostname in the MONGODB_URI, ensure you use the Private IP and NOT the Public IP of the host EC2 instance
Also, update the Port as necessary (our golang app is exposed on port 8080)

Navigate to the “Networking” section and under “Outgoing network traffic”, click “Custom VPC”.

To create custom vpc endpoint, follow this guide

If the deployment is successful and service status changes to “Running” state as shown below.

Copy the Default Domain URL and paste on your browser

Proceed to sign up and you will see a daily task management app like so;

Go ahead to play around with it. Data is persisted in mongodb so you can log out and back in.

Clean Up

To clean up resources, simply delete the EC2 instance as well as the App Runner service.

References

https://docs.aws.amazon.com/dms/latest/sbs/chap-mongodb2documentdb.02.html

https://www.geeksforgeeks.org/installation-guide/how-to-install-mongodb-on-aws-ec2-instance/

https://aws.amazon.com/apprunner/

How To Connect AWS AppRunner Service To RDS And EC2

Dickson Victor — Thu, 28 Aug 2025 15:18:34 +0000

AWS App Runner is a fully managed container application service provided by Amazon Web Services (AWS). It simplifies the process of building, deploying, and running containerized web applications and API services.

VPC Connector

A VPC connector in AWS App Runner enables your App Runner service to establish outbound connections to resources located within a private Amazon Virtual Private Cloud (VPC). This allows your App Runner application to securely access private resources such as databases (e.g., Amazon RDS), other services running on Amazon EC2 or ECS, or internal APIs that are not exposed to the public internet.

Fig.1 : Architecture diagram for Connection to RDS

Fig.2 : Architecture diagram for Connection to EC2

How To Create VPC Connector
You can associate your service with a VPC by creating a VPC endpoint from the App Runner console, called VPC Connector. To create a VPC Connector, specify the VPC, one or more subnets, and optionally one or more security groups. After you configure a VPC Connector, you can use it with one or more App Runner services.

Look for the Networking configuration section on the console page. For Outgoing network traffic, choose in the following:

Public access: To associate your service with public endpoints of other AWS services.
Custom VPC: To associate your service with a VPC from Amazon VPC. Your application can connect with and send messages to other applications that are hosted in an Amazon VPC.

To enable Custopm VPC,

Open the App Runner console, and in the Regions list, select your AWS Region.

Go to Networking section under Configure service.

Fig.3: Navigating to Networking Section

Choose Custom VPC, for Outgoing network traffic.

In the navigation pane, choose VPC connector.

If you created the VPC connectors, the console displays a list of VPC connectors in your account. You can choose an existing VPC connector and choose Next to review your configuration. Then, move to the last step. Alternatively, you can add a new VPC connector using the following steps.

Choose Add new to create a new VPC connector for your service.

Then, the Add new VPC connector dialog box opens.

Fig. 4: Creating VPC Connector

Enter a name for your VPC connector and select the required VPC from the available list.

For Subnets select one subnet for each Availability Zone that you plan to access the App Runner service from. For better availability, choose three subnets. Or, if there are less than three subnets, choose all available subnets.


Note:
Make sure you assign private subnets to the VPC connector. If you assign public subnets to VPC connector, your service fails to create or rolls back automatically during an update.

(Optional) For Security group, select the security groups to associate with the endpoint network interfaces.

(Optional) To add a tag, choose Add new tag and enter the tag key and the tag value.

Choose Add.

The details of the VPC connector you created appear under VPC connector.

Choose Next to review your configuration, and then choose Create and deploy.

App Runner creates a VPC connector resource for you, and then associates it with your service. If the service is successfully created, the console shows the service dashboard, with a Service overview of the new service.

NOTE:
When specifying the IP address to connect AppRunner with an EC2 instance, ensure you use the Private IP and NOT the Public IP

Connecting AppRunner Service to an RDS Instance with Public Access
When an RDS instance is configured for public access, it gets a public IP address and can be reached directly over the internet. In this case, your App Runner service can connect to the RDS instance directly without needing a VPC connector, since the database is accessible from outside the VPC.

How Amazon Q Stands Out: A Comparison with Microsoft Copilot and Google Gemini

Dickson Victor — Sun, 10 Nov 2024 19:03:38 +0000

Amazon Q is a generative AI assistant that helps businesses and developers automate tasks, improve workflows, and respond to natural language requests. Built on AWS’s powerful infrastructure, Amazon Q is designed for high performance, scalability, and easy integration.

It can understand language, generate natural responses, and assist with tasks like coding, data analysis, and workflow management.

It works not only with AWS tools and services but also with various third-party tools, making it easy for businesses to incorporate it into their existing systems.

In this post, we will be considering a comparison between Amazon Q and its major competitors such as microsoft copilot and google's gemini.

Amazon Q Business
Amazon Q Business is a generative AI assistant that helps your team work smarter. It can answer questions, provide summaries, generate content, and securely complete tasks based on the information in your enterprise systems. Users can request information about company policies, product information, business results, and more across data repositories. Anyone can automate generative AI tasks—from content creation to email writing and raising tickets. Amazon Q Business empowers your team to be more data-driven, creative, and productive.

Amazon Q Developer Differentiated Value Propositions

Amazon Q Developer is the AI assistant for your software development and AWS management tasks. It’s an expert on building AWS applications—from coding, testing and upgrading, to troubleshooting and optimizing your AWS resources.
Amazon Q Developer is available wherever you need it: in your IDE, in the AWS Console, in Slack, and more. Going beyond inline code recommendations, Q can help you understand, debug, and optimize your existing code through a conversational interface. And, it can save time by generating and implementing new features or by upgrading applications to newer versions in minutes.
In the AWS console, Amazon Q Developer can help you learn about AWS services and architectural best practices, troubleshoot service errors and networking issues, select instances, and optimize your SQL queries and ETL pipelines. You won’t find this broad set of abilities in any other companion.

More Value Across SDLC

Entire stack of generative AI functionality to the IDE
Most competitive pricing, for $19 per user per month
Best Assistant for Building on AWS

Integration with popular IDEs

Native integration to AWS console
Faster Innovation with Advanced Features

Code Transformation

Responsible Coding
.NET Code Migrations from Windows to Linux (upcoming)

In summary, Amazon Q stands out as a powerful AI assistant designed to streamline software development and AWS management tasks. With its broad capabilities—from coding and debugging to SQL optimization and architectural guidance—Amazon Q provides a robust solution that integrates seamlessly with both AWS and popular third-party tools. Its competitive pricing and advanced features like code transformation and responsible coding make it an attractive option for organizations seeking to enhance productivity across the software development lifecycle. For businesses ready to harness AI-driven efficiencies, Amazon Q is a tool worth exploring.

How to Deploy Jenkins Server on AWS EC2 with Terraform

Dickson Victor — Sun, 19 Nov 2023 21:22:59 +0000

Hi there! In this demo, I'll show you how to automate the installation of Jenkins and other softwares such as ansible, docker,AWS CLI and terraform on the AWS EC2 instance created using terraform. Jenkins is a popular open source continuous integration/continuous delivery and deployment (CI/CD) automation software DevOps tool. It is used to implement CI/CD workflows, called pipelines.

BEFORE YOU BEGIN

Install AWS CLI and configure credentials.
Install Terraform
Clone the repository and "cd" into the folder.
Create an EC2 keypair in your desired region and download it( I used us-east-1 and named it demoKP respectively in this demo) and ensure it's in the specified path( check the variables.tf file) Feel free to go through the cloned folder and peruse through the files. The Userdata.sh contains the scripts for the installation while the main.tf creates the EC2 infrastructure.

CREATING THE INFRASTRUCTURE
Run the following commands to begin the provisioning.

terraform init
terraform plan
terraform apply --auto-approve

Copy the url in the output to a browser

As suggested in the screenshot, ssh into the instance and run the command,sudo cat /var/lib/jenkins/secrets/initialAdminPassword in the terminal and paste the output into the box.( Don't forget to set the right permission on the keypair file).
It takes you to a getting started page, go ahead to click "Install suggested plugins"

Go ahead to configure an admin user. You can use a dummy email address. On the next page, click the button Save and Finish and then Start using Jenkins
And then, taadahh! Jenkins is ready!

Go ahead to use it for your CI/CD workloads

DESTROY INFRASTRUCTURE
To destroy the infrastructure created with terraform, simply run the following command.

terraform destroy --auto-approve

And that's How to deploy Jenkins server on AWS EC2 with Terraform. Thanks for reading.

How to Manually Install Jenkins on AWS EC2 Linux

Dickson Victor — Fri, 07 Apr 2023 14:37:01 +0000

Have you tried installing jenkins on ubuntu server severally without success? Do you get the following error message when you try to install jenkins?

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package jenkins is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'jenkins' has no installation candidate

Then, its time to install manually. Follow the steps listed below.

Install Java: Jenkins requires Java to run. You can install OpenJDK 8 using the following command:

sudo apt-get update
sudo apt-get install openjdk-8-jdk

Download the Jenkins WAR file: Go to the official Jenkins website and download the latest Jenkins WAR file. You can use the following command to download the latest WAR file:

wget https://updates.jenkins-ci.org/latest/jenkins.war

Start Jenkins: Start Jenkins using the following command:

java -jar jenkins.war

Access Jenkins: Open a web browser and navigate to http://public-ip:8080 to access the Jenkins web interface.

Complete the setup: Follow the instructions on the Jenkins setup screen to complete the installation process. To obtain the initial passwod, run:

cat /home/clouduser/.jenkins/secrets/initialAdminPassword

Note: By default, Jenkins will run on port 8080. If port 8080 is already in use on your system, you can specify a different port using the --httpPort option when starting Jenkins. For example, to start Jenkins on port 9090, you can use the following command:

java -jar jenkins.war --httpPort=9090

I hope these steps help you to install Jenkins manually.

How to Deploy WordPress to Amazon EKS using Helm

Dickson Victor — Sun, 15 Jan 2023 21:48:21 +0000

In this article, you will learn how to deploy a production ready wordpress site to Amazon Elastic Kubernetes Service(EKS) with just a few easy steps. This is made possible using a package manager known as helm.

What is Helm?

Helm is a Kubernetes deployment tool for automating creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters. It is an open source package manager that automates the deployment of software for Kubernetes in a simple, consistent way. Helm deploys packaged applications to Kubernetes and structures them into charts. The charts contain all pre-configured application resources along with all the versions into one easily manageable package.

What is a Helm Chart?

Helm charts are Helm packages consisting of YAML files and templates which convert into Kubernetes manifest files. These charts are reusable by anyone for any environment, which reduces complexity and duplicates.

For this demo, I made use of the helm chart for wordpress developed and maintained by bitnami.

Prerequisites

Ensure that you have the following utilities installed and configured on your machine.
AWS CLI, EKSCTL, HELM

1. Provision the EKS cluster

Run the following code on your terminal after placing the value for your preferred region and existing keypair name

cat <<EOF>>demo-eks-cluster.yaml
----
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: demo-eks-cluster
  region: your-region
  version: "1.21"

managedNodeGroups:
  - name: dev-ng-1
    instanceType: t3.large
    minSize: 1
    maxSize: 1
    desiredCapacity: 1
    volumeSize: 20
    volumeEncrypted: true
    volumeType: gp3
    ssh:
      allow: true
      publicKeyName: your-keypair-name
    tags:
      Env: Dev
    iam:
      attachPolicyARNs:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/ElasticLoadBalancingFullAccess
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
        - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
      withAddonPolicies:
        autoScaler: true
EOF

To confirm that the nodes have been provisioned, run:

kubectl get nodes

2. Deploy Wordpress to EKS

First, add the helm repo to your environment.

helm repo add my-repo https://charts.bitnami.com/bitnami

Then, install the helm chart for wordpress. For this use case, I did overwrite the default wordpressPassword value in values.yaml using the command:

helm install my-release my-repo/wordpress --set wordpressPassword=password

After successful deployment, check the pods and see if status reads "Running"

kubectl get pods

3. Accessing your wordpress site

To access your WordPress site from outside the cluster follow the steps below:

Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available.

export SERVICE_IP=$(kubectl get svc --namespace default wp-demo-wordpress --include "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
echo "WordPress URL: http://$SERVICE_IP/"
echo "WordPress Admin URL: http://$SERVICE_IP/admin"

Open a browser and access WordPress using the obtained URL.
Login with the following credentials below to see your blog:

username: user
password: password

Adding a /admin to the url gives the following:

4. Cleaning up

To clean up the resources created using the eksctl utility, run the following:

eksctl delete cluster demo-eks-cluster

Congratulations, your have successfully deployed a production-grade wordpress website to amazon EKS. Feel free to connect with me on linkedin if you have any questions.

Provisioning a Persistent EBS-backed Storage on Amazon EKS using Helm

Dickson Victor — Mon, 12 Dec 2022 00:16:08 +0000

Deploying stateful applications on kubernetes can pose a lot of complexities. In this demo, we will deploy a postgres database to AWS Elastic Kubernetes Service(EKS) and configure its persistence on Amazon Elastic Block Store(EBS). We will be using Helm, a package manager, to make this process more efficient.

Pre-requisites

First, ensure that the following utilities are installed and properly configured on your machine.
AWS CLI
EKSCTL
HELM

1. Create an EKS cluster
You can use either the AWS management console or EKSCTL utility to create your kubernetes cluster, for convinience, we use eksctl.
Create a file "demo-cluster.yaml" and paste the following into it.

# demo-cluster.yaml
# A cluster with two managed nodegroups
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: demo-cluster
  region: us-west-1

managedNodeGroups:
  - name: managed-ng-1
    instanceType: t3.small
    minSize: 1
    maxSize: 2

  - name: managed-ng-2
    instanceType: t3.small
    minSize: 1
    maxSize: 2

The file creates a kubernetes cluster named demo-cluster, with two managed nodegroups. To apply it, run;

eksctl create cluster -f demo-cluster.yaml

After the cluster has finished provisioning, view the nodes with the command;

kubectl get nodes

2. Create an IAM OIDC identity provider

Determine whether you have an existing IAM OIDC provider for your cluster.

Retrieve your cluster's OIDC provider ID and store it in a variable.

oidc_id=$(aws eks describe-cluster --name demo-cluster --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)

Determine whether an IAM OIDC provider with your cluster's ID is already in your account.

aws iam list-open-id-connect-providers | grep $oidc_id

Create an IAM OIDC identity provider for your cluster with the following command;

eksctl utils associate-iam-oidc-provider --cluster demo-cluster --approve

3. Configure a Kubernetes service account to assume an IAM role

Create an IAM role and associate it with a Kubernetes service account. You can use either eksctl or the AWS CLI. Here we used the AWS CLI. a. Create a Kubernetes service account. Copy and paste the following contents to your terminal.

cat >my-service-account.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ebs-csi-controller-sa
  namespace: kube-system
EOF
kubectl apply -f my-service-account.yaml

b. Set your AWS account ID to an environment variable with the following command.

account_id=$(aws sts get-caller-identity --query "Account" --output text)

c. Set the cluster's OIDC identity provider to an environment variable with the following command.

oidc_provider=$(aws eks describe-cluster --name demo-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")

d. Set variables for the namespace and name of the service account.

export namespace=kube-system
export service_account=ebs-csi-controller-sa

e. Run the following command on your terminal to create a trust policy file for the IAM role.

cat >aws-ebs-csi-driver-trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "$oidc_provider:aud": "sts.amazonaws.com",
          "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
        }
      }
    }
  ]
}
EOF

f. Create the role "AmazonEKS_EBS_CSI_DriverRole", and my-role-description with a description for your role.

aws iam create-role --role-name AmazonEKS_EBS_CSI_DriverRole --assume-role-policy-document file://aws-ebs-csi-driver-trust-policy.json --description "my-role-description"

g. Attach the required AWS managed policy to the role with the following command.

aws iam attach-role-policy \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --role-name AmazonEKS_EBS_CSI_DriverRole

h. Annotate your service account with the Amazon Resource Name (ARN) of the IAM role that you want the service account to assume.

kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/AmazonEKS_EBS_CSI_DriverRole

4. Adding the Amazon EBS CSI add-on

To improve security and reduce the amount of work, you can manage the Amazon EBS CSI driver as an Amazon EKS add-on. You can use eksctl, the AWS Management Console, or the AWS CLI to add the Amazon EBS CSI add-on to your cluster. To add the Amazon EBS CSI add-on using the eksctl, run the following command. Remember to replace with your account ID.

eksctl create addon --name aws-ebs-csi-driver --cluster demo-cluster --service-account-role-arn arn:aws:iam::$account_id:role/AmazonEKS_EBS_CSI_DriverRole --force

5. Update the worker nodes role

Attach the policy "AmazonEBSCSIDriverPolicy" to the two worker node's roles for the cluster and also the cluster's ServiceRole.

6. Deploying postgres database with Helm

Helm is a Kubernetes deployment tool for automating creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters. Kubernetes is a powerful container-orchestration system for application deployment.

- Define storage class

You must define a storage class for your cluster to use and you should define a default storage class for your persistent volume claims.
To create an AWS storage class for your Amazon EKS cluster, create an AWS storage class manifest file for your storage class. The following storage-class.yaml example defines a storageclass named "aws-pg-sc" that uses the Amazon EBS gp2 volume type.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: aws-pg-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

Use kubectl to create the storage class from the manifest file.

kubectl create -f storage-class.yaml

Run the following to view the available storageclasses in your cluster,

kubectl get storageclass

- Helm chart for postgresql

In this demo, we will leverage the helm chart for postgresql managed by bitnami. . We will be overwriting some values in values.yaml so that the chart uses the storageclass we provisioned earlier. Create a file "values-postgresdb.yaml" and paste the following into it.

primary:
   persistence:
      storageClass: "aws-pg-sc"
auth: 
   username: postgres 
   password: demo-password
   database: demo_database

- Installing the Chart

To install the chart with the release name pgdb:

helm repo add my-repo https://charts.bitnami.com/bitnami
helm install pgdb --values values-postgresdb.yaml my-repo/postgresql

After the database successfully deploys, check the PV, PVC and pod created respectively with the following commands, which should give similar outputs as the following respectively;

$kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                            STORAGECLASS   REASON   AGE

pvc-0e4020a4-8d43-4292-b30f-f57bbc4414bb   8Gi        RWO            Delete           Bound    default/data-pgdb-postgresql-0   aws-pg-sc               87s

$kubectl get pvc
NAME                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE

data-pgdb-postgresql-0   Bound    pvc-0e4020a4-8d43-4292-b30f-f57bbc4414bb   8Gi        RWO            aws-pg-sc      6h44m

$kubectl get pods
NAME                READY   STATUS    RESTARTS   AGE

pgdb-postgresql-0   1/1     Running   0          16m

You can also verify that the persistent storage was provisioned by navigating to the AWS management console >> EC2 >> Elastic Block Store >> Volumes. The screenshot attached is the volume provisioned in my case.

7. Cleaning up

To clean up and delete the kubernetes cluster we created earlier, run the following command;

 eksctl delete cluster -f demo-cluster.yaml

If the above command doesn't delete the cluster due to the presence of the pod, navigate to cloudformation console and manually delete each cloudformation stack.

And that concludes the demo on provisioning a persistent EBS-backed storage on Amazon EKS using Helm. Feel free comment below with your feedbacks.
You can also watch the video demostration on YouTube

Understanding Command Line Interfaces and Tools

Dickson Victor — Mon, 15 Aug 2022 00:25:16 +0000

Have you ever typed a text or commands in the form of lines of texts into a computer terminal? Then, you've definitely used a command line interface. What most of us are used to, is the Graphical User Interface (GUI), which is a visual, user-friendly interface through which a user interacts with electronic devices such as computers and smartphones through the use of icons, menus and other visual indicators or representations (graphics). However, some programming and maintenance tasks may not have a graphical user interface and only use a command line. This article aims to help you understand the concept of a command line interface ( CLI for short ) and the different types of CLI tools from cloud providers.

What is a Command Line Interface?

In simple terms, a command-line interface (CLI) is a text-based user interface (UI) used to run programs, manage computer files and interact with the computer. It is a program on your computer that allows you to create and delete files, run programs, and navigate through folders and files. On a Mac and Linux, it’s called Terminal, and on Windows, it’s Command Prompt.

Programmers, experienced computer users, or administrators may utilise a CLI. There are specific situations when typing text into the interface will provide faster results than simply using a GUI. Plus, CLIs can offer greater control over an operating system via succinct commands. Operating system (OS) command line interfaces are normally programs that come with the OS. There are software applications that only offer a CLI. This software delivers a prompt, the user responds, and the application reacts to the commands successively. Users enter the specific command, press “Enter”, and then wait for a response. After receiving the command, the CLI processes it accordingly and shows the output/result on the same screen; command line interpreter is used for this purpose.

Command Line Tools

Developers and those with engineering responsibilities are fond of calling terminal their home. Anyone with a Linux system has to frequently interact with the Terminal in one way or the other. And customization has always been a big part of how much the Terminal can be used to improve productivity, create unique experiences, and manage the system to improve the workflow.
Command line tools are scripts, programs, and libraries that have been created with a unique purpose, typically to solve a problem that the creator of that particular tool had himself. In other words, these tools allow programmers to compile programs and debug them, convert files, and perform a number of tasks for handling the resources required for making applications and other tools.
There are thousands of command line tools that have been developed and are being used in different areas such as Web Development,
Productivity, Utility, Visual, Entertainment etcetera.

CLI Tools from Cloud Providers

Cloud providers such AWS, Google Cloud, Microsoft Azure, IBM, Digital Ocean, Oracle and a host of others usually create CLI tools for interacting with their platforms through the terminal. Example of such is the AWS CLI, Google Cloud Shell, Azure cloud Shell, IBM Cloud CLI etcetera. These tools interact with the various cloud services via an API (Application Programming Interface), which is a set of programming code that enables data transmission between one software product and another.

I trust you have been able to gain a better understanding of what a CLI is, feel free to add your comments in the comment box below.

Configuring An End-to-End CI/CD Pipeline Using CircleCI, Ansible and Cloudformation

Dickson Victor — Mon, 27 Jun 2022 01:30:26 +0000

I recently completed a project in the udacity cloud DevOps Nanodegree program , during which I implemented CI/CD for the UdaPeople product, a revolutionary concept in Human Resources which promises to help small businesses care better for their most valuable resource: their people. During the course of the project, I demostrated mastery of the following objectives.

Utilizing Deployment Strategies such as CircleCI and a version control system e.g Github, to design and build CI/CD pipelines that support Continuous Delivery processes.
Utilizing a configuration management tool such as Ansible to accomplish deployment to cloud-based servers.
Surface critical server errors for diagnosis using centralized structured logging and monitoring such as prometheus.

The Beauty of CI/CD

In order to understand the beauty of CI/CD, let's define each term.
Continuous Integration is a development practice that requires developers to integrate code into a mainline as frequently as possible, at least once a day. An automated build that compiles the code then verifies each check-in and runs the set of automated tests against it so that teams can quickly detect problems.
Continuous Delivery is the process of getting changes of all types, including configuration changes, bug fixes, experiments and new features into production or into the hands of users in a sustainable way. When a team of developers implements continuous delivery, the mainline is in a deployable state and anyone can deploy it to the production anytime with the click of a button. When the button is clicked, an automated pipeline gets triggered. The significant element to achieve continuous delivery is automation.
Continuous Deployment is a step up from Continuous Delivery where every change in the source code is deployed to production automatically without requiring explicit approval from a developer. A developer’s role usually ends at checking a pull request from a teammate and merging it to the master branch. Continuous Integration/Continuous Delivery takes it from there by executing all automated tests and deploying the code to production while keeping the team updated about the outcome of every event.
Continuous Integration, Continuous Delivery and Continuous Deployment are like vectors with the same direction but different magnitude. All three terms aim to make the software development and release process more robust and quicker.

CircleCI, Ansible and Cloudformation

The udapeople product relied on automation tools such as circleci, ansible and cloudformation in order to reduced the workload on it's developers and guarantee its sustainability.
CircleCI is the continuous integration & delivery platform that helps the development teams to release code rapidly and automate the build, test, and deploy. After repositories on GitHub or Bitbucket are authorized and added as a project to circleci.com, every code commit triggers CircleCI to run jobs defined in it's .circleci/config.yml file.
Ansible is an open-source automation tool, or platform, used for IT tasks such as configuration management, application deployment, intraservice orchestration, and provisioning. Ansible can automate IT environments whether they are hosted on traditional bare metal servers, virtualization platforms, or in the cloud. It can also automate the configuration of a wide range of systems and devices such as databases, storage devices, networks, firewalls, and many others.
AWS CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your cloud environment. It allows you to use a simple text file to model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts. Check out this post on deploying a high availability webapp using cloudformation.

Project steps

1.Setup - AWS

Create and download a new key pair in AWS EC2. Name this key pair whatever name you wish ( I named mine "udapeople.pem").
Add a PostgreSQL database in RDS that has public accessibility. This tutorial may help. As long as you marked "Public Accessibility" as "yes", you won't need to worry about VPC settings or security groups. Take note of the connection details, such as:

Endpoint (Hostname): database-1.ch4a9dhlinpw.us-east-1.rds.amazonaws.com
Instance identifier: database-1 //This is not the database name
Database name: postgres (default)
Username: postgres
Password: mypassword
Port: 5432

Note that the AWS wizard will create a default database with name postgres. If you wish to give another name to the initial database, you can do so in the additional configuration as shown in the snapshot below.

Verify the connection to the new database from your local SQL client, using this tutorial.

2.Set up - CircleCI

Set up project in CircleCI.

Add the SSH key (*.pem) to CircleCI.

Add the environment variables to CircleCI by navigating to {project name} > Settings > Environment Variables.

AWS_ACCESS_KEY_ID=(from IAM user with programmatic access)
AWS_SECRET_ACCESS_KEY= (from IAM user with programmatic access)
AWS_SESSION_TOKEN= (from IAM user with programmatic access)
AWS_DEFAULT_REGION=(your default region in aws)
TYPEORM_CONNECTION=postgres
TYPEORM_MIGRATIONS_DIR=./src/migrations
TYPEORM_ENTITIES=./src/modules/domain/**/*.entity.ts
TYPEORM_MIGRATIONS=./src/migrations/*.ts
TYPEORM_HOST={your postgres database hostname in RDS}
TYPEORM_PORT=5432 (or the port from RDS if it’s different)
TYPEORM_USERNAME={your postgres database username in RDS}
TYPEORM_PASSWORD={your postgres database password in RDS}
TYPEORM_DATABASE=postgres {or your postgres database name in RDS}
ENVIRONMENT=production

3.When a change has been pushed to GitHub non-main branch, it will test and scan the backend and frontend of the app.

4.When a change has been pushed to GitHub main branch, it will trigger the pipeline and deploy the backend and frontend of the app to aws.

5.The app allows you to add new employees. The frontend URL can be obtained through S3 and CloudFront. The backend URL can be seen through EC2.

Conclusion

Considering the udapeople HR product as a case study, the benefits of an automated CI/CD pipeline range from practical considerations like code quality and rapid bug fixes, to ensuring you’re building the right thing for your users and improving your entire software development process.

Despite the name 'DevOps' suggesting a focus on developer and operations teams, building a CI/CD pipeline provides an opportunity for collaboration across a whole range of functions. By streamlining the steps to release your product, you provide your team with more insights into how your product is used and free up individuals’ time so they can focus on innovation.

Did you enjoy reading the article? Drop a comment.

Why Should You Consider Using Docker as a Developer?

Dickson Victor — Mon, 20 Jun 2022 10:47:26 +0000

Hey awesome reader, in this article, I’ll be giving a basic introduction to docker, how it works, why you, as a developer, should use it for packaging your applications and its impact on the development ecosystem. Happy reading.

What is a Docker?

Docker is an open source containerization platform. It is a platform that makes it easier, simpler, and safer in building, deploying, and managing containerized applications. Docker provides the ability to package and run an application in a loosely isolated environment called a container. The isolation and security allows you to run many containers simultaneously on a given host. Containers are lightweight and contain everything needed to run the application, so you do not need to rely on what is currently installed on the host. You can easily share containers while you work, and be sure that everyone you share with gets the same container that works in the same way.

How Does Docker Work?

Docker packages an application and all its dependencies in a virtual container that can run on any Linux server.
Each container runs as a n isolated process in the usr space and takes up less space than regular VMs due to their layered architecture. So it will always work the same regardless of it’s environment.

Why should you use Docker?

Let’s say you want to create an application. And that’s working fine on your machine. But in production it doesn’t work properly(Developers experience a lot). The reason could be due to Dependencies, Libraries and versions, Framework, OS Level features, Microservices that the developer’s machine has but not in the production environment.
We need a standardized way to package the application with its dependencies and deploy it on any environment. And that’s where docker comes in.
Docker is a tool designed to make it easier to create, deploy, and run applications by using containers.

Impact on the Development Ecosystem

Traditionally, developing an application and deploying it in a production environment hasn’t been easy. Development and production environments are often configured differently, which makes it difficult to resolve problems quickly when something was broken.
Docker is inexpensive, easy to deploy, and offers increased development mobility and flexibility. Here are some major impacts of using Docker:

As an open-source tool, Docker automates deploying applications in software containers.
It allows developers to package applications with all required parts like libraries and other dependencies and deploy them as one package.
Docker helps developers create a container for each application and focus more on building it without having to worry about the operating system.
Developers can easily move their software from one host to another using containers to deploy software. Containers are portable and self-contained.
Containers are the standard for delivering microservices in the cloud. Microservices are deployed in separate containers and use virtual networks when they need to communicate with each other. Each microservice container is isolated from the others, making debugging much easier.
Containers are easy to install and run because they don’t require installing an application or runtime environment. All you need is a Docker container image running on a container platform such as Docker Engine or Kubernetes.

Conclusion

Docker is a popular containerization technology that makes it easy to deploy applications. In this article, we’ve looked at a basic introduction to docker, how it works, why you should use it for packaging your applications and its impact on the development ecosystem. Thanks for reading.