Forem: Kene Ojiteli

From Ingress to Gateway API: A Hands-On Walkthrough with NGINX Gateway Fabric

Kene Ojiteli — Sat, 24 Jan 2026 01:37:39 +0000

Kubernetes is a container orchestration platform designed to run distributed applications reliably and efficiently. At its core, it schedules workloads (Pods), keeps them running, and gives primitives to scale and heal systems automatically.

But Kubernetes does not give an application architecture for free, especially when it comes to networking.

A Pod is the smallest deployable unit in Kubernetes, and it is intentionally ephemeral. Pods can be recreated at any time, which means their IP addresses change frequently. This design is great for resilience, but terrible if you try to talk to pods directly.

To solve this, Kubernetes introduced services.

Services: Stable Networking, Limited Scope

A service provides a stable virtual IP and DNS name that routes traffic to a group of Pods. This solves the Pod IP problem cleanly.

However, Services are fundamentally cluster-internal abstractions:

ClusterIP works only inside the cluster.
NodePort exposes ports, but with poor ergonomics and security concerns.
LoadBalancer depends heavily on cloud provider integrations.

Most importantly, services do not give expressive HTTP routing, TLS control, or multi-team ownership boundaries.

This is where Ingress came into play.

Ingress: A Necessary Step, but a Compromise

Ingress introduced HTTP concepts, such as hosts and paths, into Kubernetes. With an Ingress controller (NGINX, Traefik, HAProxy), applications could be exposed externally in a structured way.

Ingress solved real problems, but over time, its limitations became obvious:

The API is underspecified and relies on controller-specific annotations.
One Ingress object often becomes a shared choke point for many teams.
Infrastructure and application concerns are tightly coupled.
Advanced use cases (TCP, gRPC, multi-protocol) feel bolted on.

Ingress works, but it does not scale well organizationally. This is the context in which the Gateway API was created.

Gateway API: A Cleaner Separation of Concerns

Gateway API is an evolution of Ingress, not a replacement-by-default. One of Gateway API’s core ideas is ownership separation: platform teams manage Gateways, while application teams define Routes.

Its key idea is role separation:

GatewayClass - defined by platform teams, shows who implements the Gateway.
Gateway - infrastructure-level entry points, show where traffic enters the cluster.
Routes (HTTPRoute, GRPCRoute, etc.) - owned by application teams, show how traffic is routed.

Instead of one overloaded resource doing everything, responsibilities are explicit. A Gateway does not route traffic by itself. It only defines entry points (listeners). All routing logic lives in Route resources.

To understand whether this actually improves things in practice, I built a small project.

Project goal: This project demonstrates how Kubernetes Gateway API improves traffic management compared to Ingress by deploying a multi-service application and exposing it externally using NGINX Gateway Fabric.

NGINX Gateway Fabric is an implementation of the Kubernetes Gateway API built and maintained by NGINX. It plays the same role that an Ingress controller plays for Ingress, but for Gateway API.

Physically, NGINX Gateway Fabric runs inside the cluster as:

A controller that watches Gateway API resources.
One or more NGINX data-plane pods that act as the actual traffic proxy.

The controller translates Gateway API objects into live NGINX configuration and keeps it in sync.

Prerequisites

A running Kubernetes cluster (kind, minikube, or managed).
kubectl.
helm.
Basic understanding of Kubernetes YAML.
Willingness to debug errors(permission issues, version mismatches).

Step-by-Step Walkthrough

I carried out this walkthrough on an EC2 instance to simulate a realistic cloud environment. I launched an instance with sufficient memory and storage, then connected to it remotely using VS Code over SSH.

Before installing any tools, I updated the system’s package index to ensure I was working with the latest available versions.

I installed the core tools needed for this walkthrough:
- Docker – to run containers.
- Kind – to run Kubernetes locally inside Docker.
- kubectl – to interact with the Kubernetes cluster.
- Helm – to install the NGINX Gateway Fabric controller.

I created a Kubernetes cluster named gateway-api-demo using Kind and a configuration file. This cluster will host all Gateway API resources and workloads.

I installed the Gateway API CRDs, which introduced new Kubernetes resource types such as GatewayClass, Gateway, and HTTPRoute. These are definitions only; they do not route traffic by themselves. They simply tell Kubernetes what kinds of objects are allowed to exist.

With the CRDs installed, I installed NGINX Gateway Fabric using Helm. This component is the actual controller that monitors Gateway API resources and converts them into actual NGINX configurations.

As part of its startup process, NGINX Gateway Fabric automatically created a GatewayClass named nginx. This GatewayClass declares that NGINX Gateway Fabric is responsible for implementing any Gateway that references it. Installing Gateway API CRDs only defines the resource types. The GatewayClass is created by the controller (NGINX Gateway Fabric), not by Kubernetes itself.
To demonstrate routing behaviour, I deployed three simple Python-based HTTP servers, each representing a different device-specific frontend. All applications were deployed into the same namespace.

At this stage, pods are running, but no external traffic can reach them yet.
I then created a Gateway resource. The Gateway defines where traffic enters the cluster by specifying listeners (ports and protocols) and referencing the nginx GatewayClass.

Describing the Gateway shows that the NGINX Gateway fabric accepted the Gateway, the Gateway was successfully programmed, a service was created and exposed, and no routes are attached yet.
This implies that the Gateway is live, listening for traffic, but has no routing rules.

The GatewayClass confirms that NGINX Gateway Fabric is the active controller responsible for handling Gateways that reference it.

At this point, the ngf-gatewayapi-ns namespace contains NGINX Gateway Fabric controller pods and the Gateway and its supporting resources.

I attempted to access the application via: <NodeIP>:<NodePort> (NodePort is used here for simplicity in a demo environment to make the Gateway reachable from outside the EC2 instance. In production, this would be replaced by a cloud LoadBalancer or external traffic manager). I also updated the EC2 security group to allow inbound traffic on the NodePort.

The request failed. This behaviour is expected because the gateway accepts traffic, but there is no backend defined, and no route exists to forward traffic to any service. This is where the HTTPRoute comes in.

The HTTPRoute defines how requests are matched, specifies which backend service should receive traffic and attaches itself to a gateway using parentRefs.
I created three services and a single HTTPRoute that forwards traffic to the appropriate backend based on request rules.
After applying the HTTPRoute, traffic could flow freely. Traffic follows a clear path: Client → Gateway → NGINX Gateway Fabric → HTTPRoute → Service → Pod.

I was able to access the applications successfully as traffic was routed through the gateway and its proxy pods.

Challenges Encountered and Fixes
Error1: I encountered a permission denied error while trying to create a kind cluster. This was caused by insufficient user privileges to interact with the Docker daemon.

Fix: A temporary fix would be adding sudo to the command for creating the cluster (this is not recommended), but I permanently resolved this error by adding my current user to the Docker group, as shown below.

Error2: I encountered a CrashLoopBackOff error in the NGINX Gateway Fabric controller pod. The pod failed immediately on startup, and traffic handling never initialised.

Actions taken: I inspected the controller pod logs and observed repeated startup failures referencing BackendTLSPolicy, with errors indicating that the API server could not find the resource kind.

This indicated that the controller was attempting to register an informer for BackendTLSPolicy during startup. I verified that my installed Gateway API CRDs did not include the BackendTLSPolicy definition, even though I was not explicitly creating or using this resource in my manifests.

Fix: The issue was caused by a version mismatch between the Gateway API CRDs and the NGINX Gateway Fabric controller.

The installed controller version expected the BackendTLSPolicy CRD to exist as part of the Gateway API it was built against. Although I did not intend to use BackendTLSPolicy, the controller still attempted to register an informer for it during startup. Since the CRD was missing, the Kubernetes API server rejected the informer registration, causing the controller to crash.

I resolved the issue by upgrading the Gateway API CRDs to a release that includes the BackendTLSPolicy resource, ensuring compatibility with the installed NGINX Gateway Fabric controller. Once the CRD existed in the cluster, the controller started successfully even without any BackendTLSPolicy objects being created.

Wrapping It All Up
This walkthrough moves from Kubernetes fundamentals to a modern, production-grade traffic management model using Gateway API and NGINX Gateway Fabric.

It shows how:

Pods are ephemeral and unreliable entry points.
Services provide stable in-cluster access, but don’t solve external routing.
Ingress improved the situation, but centralised too much responsibility.
Gateway API splits concerns cleanly:
- GatewayClass defines who implements networking.
- Gateway defines where traffic enters.
- HTTPRoute defines how traffic is routed.

Most importantly, this walkthrough shows that Gateway API is not just “Ingress v2”. It is a deliberate redesign that establishes clear ownership boundaries, enhances extensibility, and provides improved operational visibility for Kubernetes networking.

If you are building multi-team platforms, managing multiple routes and protocols, or preparing for service mesh and mTLS-heavy environments, Gateway API is no longer optional knowledge; it is the direction Kubernetes is heading.

What This Project Solves

This project demonstrates how to:

Expose applications externally without coupling routing logic to workloads.
Safely evolve routing rules without redeploying Gateways.
Use a standards-based API instead of vendor-specific annotations.
Understand why traffic flows the way it does, not just that it works.

If Ingress ever felt magical or fragile to you, Gateway API replaces that magic with explicit contracts.

All manifests, configurations, and steps used in this walkthrough are available here

Did this help you understand how Gateway API works? Drop a comment!

Automating Infrastructure Provisioning with Terraform, AWS S3 Remote Backend, and GitHub Actions

Kene Ojiteli — Sun, 26 Oct 2025 01:01:11 +0000

Infrastructure automation is at the heart of modern DevOps. I moved beyond just running Terraform apply locally and created a fully automated, modular, and version-controlled infrastructure workflow using Terraform, AWS, and GitHub Actions.

This project provisions AWS infrastructure through custom Terraform modules, manages Terraform state securely with S3 as a remote backend, leverages S3’s native state locking mechanism, and automates the provisioning and destruction process through GitHub Actions.

This project simulates a production-ready Infrastructure as Code (IaC) workflow that teams can use for scalable, consistent, and automated deployments.

It also prepares the foundation for the next phase: Automated Multi-Environment Deployment with Terraform & CI/CD, which I am currently building.

Prerequisites

Basic understanding of Terraform (providers, modules, state, variables).
AWS account with:
- An S3 bucket for remote backend storage.
- Programmatic access via IAM user or role.
GitHub repository for automation.
GitHub Actions runner permissions to deploy to AWS.
Terraform.
IDE (VS Code recommended).

Key Terms to Know

Infrastructure as Code (IaC): used to manage and provision cloud infrastructure through code instead of manual processes.
Terraform Module: A reusable, version-controlled block of Terraform configurations that defines one piece of infrastructure.
Remote Backend: A centralised storage for Terraform state files (in this case, AWS S3).
State Locking: Prevents concurrent updates to your infrastructure.
GitHub Actions: CI/CD tool that automates workflows like terraform plan and terraform apply.

Project Overview
The project is built to demonstrate how to structure Terraform code into custom modules, manage state remotely, and automate the provisioning/destruction process through CI/CD.

How Modules Communicate (Data Exchange Between Modules)
Terraform does not allow referencing one child module’s resources (each child module is meant to be self-contained and reusable) directly inside another child module. Instead, outputs and inputs are used with the root module acting as the connector.

In a child module, variables are declared. In the root module, when the child module is called, you must provide values for those variables (unless the child module defines defaults).

For example, consider a VPC child module and an EC2 child module; the EC2 child module will require a subnet ID, which is generated by the VPC module. The best way to do this is to:

Pass the subnet ID as an output of the VPC module in the output.tf file of the VPC module.
Create EC2 child module and put in the argument and attribute refs it expects, including the ones it requires from other child modules (eg, subnet_id); don't forget to parameterise.
Since the root module is the connector, create the EC2 module in the main.tf file of the root module.
Pass the output from the VPC module to the root module's output.tf file (in the image below, pub_subnet_id is the name of the output from the VPC child module)
Reference the output as an input to the EC2 module.
This means that when Terraform wants to create the EC2 resource, it goes into the EC2 module, reads the whole block, noting that some arguments are dependent on other module arguments, and uses the source to locate the EC2 child module, and starts creating the EC2 instance.

Solutions My Project Solved

Terraform state conflicts or lost files: I used S3 remote backend for centralised state management, and also leveraged S3's native state locking feature that allows S3 to manage state locks directly, eliminating the need for a separate DynamoDB table. This simplifies the backend configuration and reduces the associated costs and infrastructure complexity. S3's native state locking feature manages the lock so only one terraform plan or apply can run at a time.
Code duplication: I modularised my Terraform resources into reusable custom modules.
Manual provisioning of resources: I automated resource provisioning with GitHub Actions workflow. To make the workflow seamless, I added the needed credentials as repository secrets.
Lack of CI/CD integration: I initialised Terraform, validated my code, then implemented Terraform plan and apply pipelines in GitHub actions. I also added a manual trigger to destroy the resources.

Challenges and Fixes

Error: I encountered a permission error while trying to use an S3 bucket as a remote backend.
Fix: I added an inline policy obeying the principle of least privilege (giving the IAM user permissions necessary to carry out the role).

Lessons Learned

Modularisation makes scaling Terraform projects easier.
Remote backends are crucial for team collaboration.
Outputs and variables are the lifeblood of inter-module communication.
Automation does not equal speed alone; it also adds consistency and traceability.

Conclusion
This project laid the foundation for a fully automated Infrastructure as Code workflow, from custom modules to remote state management and CI/CD automation.

In my next article, I will automate multi-environment deployment with Terraform & CI/CD, where environments like Dev, Staging, and Production are automatically provisioned using the same pipeline.

Need Terraform code? Check it here

Did this help you understand how Terraform modules communicate? Drop a comment!

Building and Deploying a Cloud-Native FastAPI Student Tracker App with MongoDB, Kubernetes, and GitOps

Kene Ojiteli — Wed, 24 Sep 2025 06:13:16 +0000

I once carried out a skills gap analysis on myself as a DevOps engineer, looking for my next challenging opportunity. I realised that although I had built smaller projects, I hadn’t yet executed a production-grade, full-blown cloud-native project that combined all the essential DevOps practices.

That became my mission: to design, deploy, and manage a FastAPI-based Student Tracker application with a MongoDB backend, but with a strong focus on DevOps functionalities rather than frontend appearance.

This project allowed me to bring together containerization, Kubernetes, Helm, CI/CD, GitOps, monitoring, and observability into one workflow.

Outline.

Prerequisites.
Key Terms & Components.
Step-by-Step Process.
Challenges and Fixes.

Prerequisites.

A code editor (I used VS Code).
A terminal.
Optionally, a cloud provider to provision an instance.
Knowledge of Docker and Kubernetes.

Key Terms & Components.

Docker: a tool used to build, test, and deploy applications.
Kubernetes: used for automating the deployment, scaling, and management of containerised applications.
Ingress: a resource type similar to a Kubernetes service, that allows easy routing of HTTP and HTTPS traffic entering the cluster through a single entry point to different services inside the cluster.
Helm & Helm charts: Helm acts as a package manager for Kubernetes; it is used to manage Kubernetes applications. Helm Charts are used to define, install, and upgrade even the most complex Kubernetes applications.
GitOps: a framework for managing cloud-native infrastructure and applications by using Git as the single source of truth for the desired state of your system.
ArgoCD (deployment platform for k8s): a Kubernetes controller which continuously monitors running applications and compares the current, live state against the desired target state (as specified in the Git repo)
Monitoring & Observability: Monitoring involves tracking known system metrics to detect when something is wrong, while observability is a deeper, more advanced capability that allows you to understand the internal state of a system by correlating logs, metrics, and traces to diagnose the why and how behind an issue.
Vault server: A tool that allows you to manage secrets safely. Secrets mean sensitive information, such as digital certificates, database credentials, passwords, and API encryption keys.

Step-by-Step Process.
This is a full-blown project where I update my progress in each stage, and the process includes the following phases:

Testing the application locally: This stage can be carried out locally, or you can leverage the use of a VM on any cloud provider (I explored both methods, but I will use an AWS EC2 instance throughout the project).
- While provisioning the instance, I added a script to install every tool I need for the project, which includes: git, docker, kubectl, helm, kind, etc I verified the installation by checking their versions.
- I cloned the application's repository and navigated to the folder.
- To test locally, I installed Python and created a virtual environment (an isolated environment on my computer, to run and test my Python app). After creating a virtual environment, I activated it and installed the necessary dependencies for my application from the requirements.txt file.
- I exported my vault credentials via the CLI and ran the app with uvicorn.
- I accessed the application on my browser with http://<EC2_public_ip>:8000 and registered.
Containerising the application and pushing to Dockerhub: This stage involves building a Docker image through a Dockerfile and pushing to a repository (Dockerhub).
- I created a Dockerfile, which serves as a set of instructions to build a Docker image.
- I built an image from the Dockerfile and created a container (a running instance of the built image) from the image with the required credentials.
- I accessed my app and successfully updated my progress.
- Pushing to Dockerhub requires creating a repository on my Dockerhub account, and successful login from my CLI to my Dockerhub account before pushing to the repository.
Setting up a Kubernetes cluster (using Kind): Here, I used Kind (a local Kubernetes cluster, which stands for Kubernetes in Docker, that uses Docker containers as nodes) to create a cluster. Working with Kind requires Docker to be installed and a Kind configuration file.
- I created a cluster named kene-demo-cluster that has a control plane and a worker node.
Deploying the application to the Kubernetes cluster: I exposed my application via an ingress and created an ingress controller for my kind cluster.
- First, I created my manifest files (namespace, secret, deployment, service and ingress files).
- Then, I applied the configurations to a resource and created an nginx ingress controller.
- I retrieved all the resources I created in each namespace using the kubectl get all -n <namespace> command.
- I accessed the application with the ingress host and updated my progress as usual.
Deploying the application with Helm: This stage focuses on deploying the student tracker application with Helm charts. I created the Helm chart from scratch.
- I installed Helm, and I verified the installation by checking Helm's version with the helm version command.
- I created my Helm chart and navigated to the chart's directory. Note that the chart has the default structure of a typical Helm chart.
- I deleted all the default template files and created new files to customise my chart.
- I added the Nginx ingress controller repository, updated the Helm repository and installed the Nginx ingress controller with Helm.
- I went ahead to update the Chart.yaml file using my app details and my template files using the values I specified in the my-values.yaml file.
- Then, I installed the helm chart (I went out of the chart's directory, and specified the path of the chart's directory, the namespace the chart will be created in, and the values file to use).
- I accessed the app and updated my progress.
Implement CI/CD with GitHub Actions: In this stage, I roleplay as a DevOps engineer (implementing CI/CD with GitHub actions to deploy my application to an EC2 instance) and a developer (adding an admin feature to the application to view the progress of all registered students).
- To implement a CI/CD pipeline on GitHub actions, I created my workflow (a yaml file) in .github/workflows folder, added an event to trigger the pipeline, a deploy job and steps to deploy the application.
- I also added the required credentials as secrets and referenced them where necessary in my workflow, as shown above. The credentials are the details of the instance to which I will deploy my application.
- Based on my workflow, a push event to the main branch triggers the workflow to deploy the application to an EC2 instance (in my case, it is deployed to an EC2 instance on a different AWS account).
- I logged into the account my app was deployed to and verified the application was successfully deployed.
- I used the public IP and port of the account my app was deployed to to access the app and update my progress. I ensured that my port was added to my instance security group, allowing inbound rule.
- As a developer, I added an admin.html file, updated the app/crud.pyand app/main.py files.
- I committed and pushed the changes, which triggered the workflow, and I accessed the application with http://<instance-ip>:<port>/admin.
Implement GitOps with ArgoCD: I implemented GitOps with ArgoCD using Git as the single source of truth. Following best practices, this will be done in an entirely new repository (at this point, I will have an application repository and a GitOps repository).
- I installed ArgoCD with Helm. First, I added ArgoCD to the repository, updated the repository, and configured the server to run in an insecure mode (disabling TLS/SSL and potentially other security measures) before installing it in a namespace called argocd.
- I verified that all resources in the argocd namespace were up and running.
- I will be using the ArgoCD UI. To log in, I need to obtain the initial password and port forward (specifying --address 0.0.0.0/0, which listens on all network interfaces of the machine). You can change your password from the UI.
- Currently, ArgoCD has no record or knowledge of my app; to add my app, I will use an application YAML file (I could also add it from the UI or use the CLI).
- In addition to using ArgoCD as a Kubernetes controller that will monitor my Git repository for changes to application and infrastructure configurations, I will also create a workflow to build and push a Docker image to Dockerhub, such that the push will update the Helm values.yaml file with a new image repository and tag, and ArgoCD auto-syncs the commit.
- I created a repository and a personal access token in my Docker Hub account, then added the PAT and my username as secrets in my project's repo.
- I triggered my workflow by pushing changes to my main branch. My workflow will check out my repo, log in to Docker Hub, build the image, scan the image with trivy (a scanning tool), push the scanned image to my Docker Hub account, update the image tag and push the new update to GitHub.
- The commit step from the pipeline above causes ArgoCD to auto-sync with the Git repo.
Implement Monitoring with the LGTP (Loki, Grafana, Tempo and Prometheus) stack: in this stage, I modified my source code to allow metrics scraping by Prometheus, and deployed monitoring tools to be monitored by argocd and also created the monitoring workloads in a different namespace. I defined Argo CD Applications that point to the Helm charts.
- I used the app of apps pattern where a single, parent ArgoCD application resource manages other child application resources (instead of manually deploying each application), which then manages the actual Kubernetes workloads.
- I port-forwarded to argocd to view the applications created by the single parent application with kubectl -n <namespace> port-forward <argocd-service-name> 8000:80 --address 0.0.0.0.
- Here are my complete applications, which consist of: kube-prometheus-stack (which includes Prometheus, node exporter and Grafana), Tempo, Loki and my student-tracker application.
- I port-forwarded to access Grafana using kubectl -n <namespace> port-forward <grafana-service-name> 3000:80 --address 0.0.0.0 command.
- I added an extra configuration to add Tempo, Loki and Prometheus as my datasources automatically.
- I went ahead to test the data sources and create dashboards.
NB: I made sure to allow inbound traffic for all the ports used in my EC2 instance security group.
Challenges and Fixes: working on this project exposed me to a whole lot of errors, most of which I was able to resolve after so much research.
- Error 1: I had issues accessing my application via the browser, and I debugged by doing an nmap scan to see my open and closed ports; it turned out my ports were closed except port 22.
- I patched my deployment to kubectl patch deployment ingress-nginx-controller -n ingress-nginx -p '{"spec":{"template":{"spec":{"hostNetwork":true}}}}', this is because the kind cluster runs in a container, so exposing ports to the EC2 host and beyond won't work unless the pod is directly attached to the host's network.
- Error 2: I had issues accessing my application on the argocd UI This was caused because by default, helm fetches values from the values.yaml file, but I have a custom file named my-values.yaml.
- I fixed this error by adding default values to the default values.yaml file and specifying the exact Helm file to be used to deploy the application to ArgoCD.
- Error 3: I had a module not found error on my student tracker log on Argocd. This was caused because of a wrong file path in my Dockerfile because I rearranged my application's directory and failed to change the file path.
- I fixed this error by modifying the file to make it easier for Python to look for the module.
Conclusion: This project was a turning point in my DevOps journey. By building a cloud-native FastAPI Student Tracker and deploying it with Docker, Kubernetes, Helm, CI/CD, GitOps, and monitoring, I gained hands-on experience with the full DevOps lifecycle. It taught me:
- How to design end-to-end workflows from local testing to production-ready deployments.
- How GitOps principles simplify cluster management with ArgoCD.
- How monitoring (logs, metrics, and traces) ties DevOps and observability together.
- That errors are part of the process, debugging taught me more than smooth deployments ever could.

GitHub Repositories: Application repo, GitOps repo

Cloud Networking in Practice: Building a Highly Available VPC on AWS with Terraform

Kene Ojiteli — Wed, 25 Jun 2025 02:24:10 +0000

After grasping the concepts of Networking, Subnetting, and IP addressing in Part 1 of my series, I was eager to move beyond theory. In this second part, I’ll guide you through the process of building a highly available VPC on AWS using Terraform, featuring public and private subnets, NAT gateways, and proper routing. Whether you're building your first cloud infrastructure or refining your core networking practices, this hands-on guide has something for you.

This article assumes you are familiar with Terraform, AWS CLI and networking basics.

Outline.

Prerequisites.
Key Terms & Components.
Step-by-Step Terraform Setup.
Provisioning the resources on AWS.
Testing the setup.
Cleaning up resources.
Challenges and Fixes.
Suggested Improvements.

Prerequisites.

AWS account with programmatic access (access key + secret key) - This is where the network resources will be created.
AWS CLI - to interact with AWS on your local machine.
Terraform - installed on your local machine to provision a highly available network infrastructure.

Key Terms & Components

Virtual Private Cloud (VPC) - a logically isolated section of a public cloud service where resources can be launched in a virtual network.
Subnet - a logical subdivision of an IP network, effectively creating a network within a network. Subnets are used to break down a larger network into smaller, more manageable segments. Subnetting helps improve network efficiency, traffic management, and security.
Public Subnet - a network segment within a Virtual Private Cloud (VPC) that has a direct route to the internet through an Internet Gateway. This means that resources within the public subnet can communicate directly with the internet using public IP addresses.
Private Subnet - a network segment without a direct route to the internet gateway. Private subnets do not have a public IP address, and resources in a private subnet will need a NAT gateway to have internet access.
Internet Gateway - a horizontally scaled, highly available AWS-managed service that connects your VPC to the internet. An internet gateway allows instances in the public subnet to send traffic to the internet and receive incoming traffic. Without the internet gateway, internet access into the VPC will not be possible.
Elastic IP - a static IPV4 address attached to a NAT gateway.
Network Address Translation (NAT) Gateway - allows private resources in a private subnet to access the internet (for example, to download packages, perform an OS update), without being publicly accessible. For this project, I will be using a public NAT gateway (this is an AWS-managed service launched in the public subnet with access to the internet via the internet gateway that routes traffic from the private subnet to the internet, and also with an elastic IP attached to it).
Route Table - contains a set of rules called routes that determine where network traffic from a subnet or gateway is directed.
Route Table Association - This is the link between a route table and a subnet. This association determines which routes (rules) in the route table are used to direct network traffic from that particular subnet or gateway.
Elastic Compute Cloud Instances - are virtual servers in the AWS cloud that allow users to run applications and workloads. This resource aims to test the VPC setup by placing one instance in the public subnet (called bastion host), and the other instance in the private subnet (to verify internet/NAT access).
Security Group - acts as a virtual firewall that controls inbound and outbound traffic for your EC2 instances. It's a set of rules that specify which traffic is allowed to reach or leave an instance. Each EC2 instance will have a security group attached to it, allowing SSH access on port 22.

Step-by-Step Terraform Setup

I created a provider.tf file where I configured the provider (AWS in this case) that my terraform configuration would interact with.

Then a variable.tf file, where I declared input variables (such as region, availability zones, subnet names, CIDR ranges) used throughout the project.

At this point, it is important to note that this is a highly available VPC architecture designed to maintain uptime and service continuity even if part of the infrastructure fails.
I then created each Terraform resource in a separate file (alternatively, you could define all resources in a single file, but I separated them for clarity) for better understanding and easy readability.
vpc.tf is the resource block for the VPC, which includes a CIDR block.

subnets.tf creates 2 subnets (a public and private subnet) in each availability zone (considering high availability); this can be done easily using Terraform's count argument and element function.

igw.tf creates an internet gateway in the specified VPC (referencing the vpc_id).

nat.tf launches a NAT gateway in each public subnet for each availability zone (This highly available architecture uses a public NAT Gateway in each AZ), but before the NAT gateway, an elastic IP is needed (the NAT gateway is dependent on the presence of an internet gateway and is attached to an elastic IP).

rtb.tf creates route tables for the public and private subnets (I created one route table for the public subnet because there is one internet gateway, and two route tables for the private subnet because there are two NAT gateways).

Next, I associated the route tables with a subnet.
ec2.tf creates two instances in a public and private subnet (I will be using one Availability Zone to test this part of the project).

sg.tf creates two security groups that will be attached to the instances above, allowing port 22 for inbound traffic and all traffic for outbound traffic.
The bastion host's security group only allows SSH from my local machine to the bastion host, while the private instance security group allows inbound SSH if it comes from any instance in the Bastion SG (meaning it only allows SSH from Bastion’s security group), hence the use of security_group instead of cidr_block.

Provisioning the resources on AWS

I configured AWS CLI on my local machine with aws configure.

Using terraform init, I initialised the working directory containing my configuration files to download all the necessary provider plugins.

With terraform plan, I created an execution plan used to preview the changes that Terraform plans to make to my infrastructure.

Then, I executed the actions proposed in the plan in dependency order using the terraform apply command.

After running the terraform apply command, I verified the creation of the resources on my AWS account by checking the resource map (this shows a visual representation of my VPC's architecture and resource relationships).

And, also the running instances (notice the networking properties attached to each instance, and the absence of a public IP on the private host).

Testing the Setup

Connect via SSH: SSH into the bastion from my machine, and SCP or SSH-agent-forward Bastion → Private EC2
Test internet access: curl on the private instance (this works via NAT), and remove NAT and repeat curl (fails, confirming NAT’s impact).

Steps

To securely connect to an EC2 instance, a keypair is needed (I created it on the AWS console, downloaded it to my machine and navigated to the directory via CLI).

After navigating to the keypair's location using git bash terminal, I securely connected to the bastion host via SSH using ssh -i <your-key.pem> <default-user-based-on-machine>@<bastion_public_ip> command.

Having gained access to the bastion host, the next step is to SSH to the private host via SSH from the bastion host. This requires having a keypair on the bastion host (meaning I have to copy my keypair from my local machine to the bastion host with either secure copy or SSH agent forwarding, I used the former method).

Then, I verified the key’s presence in the user’s home directory (which is the destination).

Then I accessed the private host via SSH using ssh -i <your-key.pem> <default-user-based-on-machine>@<private_host_private_ip>.

Without changing permission, the error below will be encountered.
Using curl, I tested internet/NAT access on the private host; I got a successful response, meaning the NAT gateway works properly.

I removed the NAT gateway and tried to update packages and ping a network, but it wasn't successful; this implies that without the NAT gateway, outbound connections cannot be initiated to the internet.

Cleaning up Resources

I cleaned up by running the terraform destroy command to avoid incurring costs. The terraform destroy command deprovisions all objects managed by a Terraform configuration

Challenges and Fixes

Error 1- Failed to query available provider packages: The timeout error was due to poor network connectivity. I switched to a better network, and it was resolved.
Error 2- No valid credential sources found: this error occurred because AWS needs credentials. I fixed it by configuring the CLI with the aws configure command to set up my AWS credentials and region for the Terraform provider.
Error 3- Incorrect attribute value type: This error is a syntax error and was resolved by updating the attribute (shared_credential_file) from a single string ("~/.aws/credentials") to a list of strings (["~/.aws/credentials"]).

Suggested Improvements

Remote state backend using AWS S3 (for secure, shared state).
Refactor using Terraform modules to make the VPC reusable, maintainable by component.

In Part 2, I turned theory into practice, building a fault-tolerant, multi-AZ VPC with secure networking. I explored key AWS components, tested routing logic, and tackled real-world errors. With this foundation, Part 3 will focus on production-grade deployment: adding IAM, storage, monitoring, and a containerized app on top of this VPC.

Need Terraform code? Check it here

Did this help your cloud networking skills? Drop a comment!

Networking Basics: Understanding Subnets, IP Addresses & Subnet Masks.

Kene Ojiteli — Wed, 04 Jun 2025 15:16:22 +0000

Networking was always that one topic I kept putting off until I realised it’s the backbone of almost everything I do as a DevOps Engineer. Concepts like Subnetting, CIDR notation, IP classes, and the OSI model used to feel overwhelming and sounded like magic to me. But with some patience and practical examples, I finally cracked the code, and I want to help you do the same.

In this article, I will break down everything I wish I understood from the basics of how computers communicate using IP addresses, what subnetting means, and how everything connects within the OSI model. Whether you are a complete beginner, someone brushing up, preparing for a cloud certification, or diving into DevOps, this article will simplify those tricky networking topics in a way that just makes sense.

Outline

How Computers Communicate Using IP.
Understanding IP addressing.
Subnets, CIDR notation and calculating IP Ranges.
Calculating subnet info and IP ranges with examples.
OSI Model.

How Computers Communicate Using IP
Computer networking is how computers and devices talk to each other and share information. For example, the way humans communicate via texts and calls with phones, computers communicate via networks to send and receive data. This communication happens through connections, like cables (wired) or Wi-Fi (wireless), using rules called protocols (like IP, TCP, HTTP).

An IP (Internet Protocol) address is a unique address that identifies a device on the Internet or a local network. Think of an IP address the same way a house address is used to locate or differentiate a house (no two houses share the same address), an IP address identifies a device on a network.

It’s important to note that the computer only understands bits and bytes (0s and 1s), so it uses an IP address (for example, 192.168.10.20 converted to binary) while humans use hostnames (for example, www.google.com).

Private IP addresses usually range from:

10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

While Public IP addresses are:

Routable on the internet.
Assigned by your ISP or cloud provider.

Understanding IP addresses
At the moment, an IP address has two versions: IPv4 (an older version that is running out of addresses, which uses a 32-bit address space with a dot-decimal notation) and IPv6 (which uses a 128-bit address space, providing a virtually limitless number of addresses using hexadecimal notation). I will be focusing on IPv4 in this article.

Understanding IPv4 Addressing
An IPv4 address is a 32-bit number divided into 4 octets separated by a dot. This means that each octet is made up of 8 bits (which is also equivalent to 1 byte) and each octet ranges from 0 - 255 (where 0 is the minimum value and 255 is the maximum value). The image below shows a typical IPv4 address in both decimal and binary format.

An IP has 2 parts, namely the host bit (identifies devices within the network) and the network bit (identifies the network, and is the reserved or fixed portion), but this is determined by the IP address class (IP addresses are divided into classes based on their first octet).

There are 5 main IP address classes. This article focuses on types A, B, and C, which are used by large organisations, medium-sized businesses, and small networks, respectively. Types D and E are reserved for multicast and experimental use, respectively.

N.B.: Class A ranges from 1 - 126 and Class B ranges from 128 - 191, one would wonder if 127 was omitted? No, 127 was not omitted; it is reserved for loopback, making Class A have only 126 usable networks.

From the diagram above, I will break down how to calculate the number of available hosts and the number of networks for each class.

To calculate the number of networks = 2 ^ (Number of network bits)
The number of network bits depends on how many bits are reserved for identifying networks in that class.

Class	Network Bits	Number of Networks (2^network bits)
A	7 bits	2⁷ = 128 → 128 - 2 = 126 usable
B	14 bits	2¹⁴ = 16,384 networks
C	21 bits	2²¹ = 2,097,152 networks

This calculation is done based on the default subnet mask (a 32-bit value used to distinguish the network portion of an IP address from the host portion) for each class (refer to the first diagram in this article).

For Class A;

Subnet mask in decimal = 255.0.0.0      
Subnet mask in binary = 11111111.00000000.00000000.00000000 (the computer only understands numbers in binary format). 
Network bit = 11111111 = 2 ^ (8 - 1) = 2 ^ 7 = 128 (the first bit in class A is always 0, making 7 bits available, so we subtract 1 from the sum of the first octet)
Total Class A network = 128
Usable Class A network = 128 - 2 = 126 (0.x.x.x and 127.x.x.x are reserved for special routing and loopback, respectively).

For Class B;

Subnet mask in decimal = 255.255.0.0      
Subnet mask in binary = 11111111.11111111.00000000.00000000 
Network bit = 11111111.11111111 = 2 ^ (16 - 2) = 2 ^ 14 = 16,384 (the first 2 bits in class B are always 10, so we subtract 2 from the sum of the first 2 octets)
Total Class B network = 16,384

For Class C;

Subnet mask in decimal = 255.255.255.0      
Subnet mask in binary = 11111111.11111111.11111111.00000000 
Network bit = 11111111.11111111.11111111 = 2 ^ (24 - 3) = 2 ^ 21 = 2,097,152 (the first 3 bits in class C are always 110, so we subtract 3 from the sum of the first 3 octets)
Total Class C network = 2,097,152

Note that the network bits are the octets comprising 1.

To calculate the number of available hosts = 2 ^ (Number of host bits) - 2, where the 2 subtracted is reserved for the network ID and broadcast address.
Using the formula above is similar to calculating the network bits except that the host bits comprise zero (0) in the subnet mask, and subtracting 2 for each class.

For Class A;

Subnet mask in decimal = 255.0.0.0      
Subnet mask in binary = 11111111.00000000.00000000.00000000 
Host bit = 00000000.00000000.00000000 = 2 ^ 24 = 16,777,216
Total Class A hosts = 16,777,216
Usable Class A hosts = 16,777,216 - 2 = 16,777,214

For Class B;

Subnet mask in decimal = 255.255.0.0      
Subnet mask in binary = 11111111.11111111.00000000.00000000 
Host bit = 00000000.00000000 = 2 ^ 16 = 65,536
Total Class B hosts = 65,536
Usable Class B hosts = 65,536 - 2 = 65,534

For Class C;

Subnet mask in decimal = 255.255.255.0      
Subnet mask in binary = 11111111.11111111.11111111.00000000 
Host bit = 00000000 = 2 ^ 8 = 256
Total Class C hosts = 256
Usable Class C hosts = 256 - 2 = 254

Here is a quick recap

Class	First Octet Range	Default Subnet Mask	Number of Hosts per Network	Number of Networks
A	1 - 126	255.0.0.0 (/8)	16,777,214	128 (2⁷) - 2 = 126
B	128 - 191	255.255.0.0 (/16)	65,534	16,384 (2¹⁴)
C	192 - 223	255.255.255.0 (/24)	254	2,097,152 (2²¹)

Subnets, CIDR notation and Calculating IP Ranges
Subnet stands for sub-network. It is a smaller part of a larger network. They make networking more secure, organised and efficient.

CIDR (Classless Inter-Domain Routing) is a more flexible method for defining network size. CIDR removes the strict class rules (A, B, C) and allows more flexible subnetting.

A typical example of CIDR is 192.168.1.0/24, where /24 indicates that 24 bits are reserved for the network part and the remaining 8 bits (32 - 24 = 8) are allocated for the host part (32 - CIDR).

Calculating Subnet Info and IP Ranges using examples
Before delving into examples, here is a list of how to calculate subnet info and IP ranges:

Calculate the network bit from the CIDR block (this is the number after the forward slash).
Calculate the host bit: (32 - CIDR).
Calculate the number of available hosts (the number of IP addresses): 2 ^ (number of host bits) - 2.
Calculate the network address, first assignable IP, last assignable IP, and the broadcast address.
N.B.: As the subnet mask gets larger, the IP ranges get smaller.

Example 1: 192.168.1.1/24
IP address class: C
CIDR: /24
Subnet mask(decimal): 255.255.255.0
Subnet mask(binary): 11111111.11111111.11111111.00000000
IP address(binary): 11000000.10101000.00000001.00000001
Network bit: 24
Host bit: 32 - 24 = 8 (a short way to get this is to convert the subnet mask and IP to binary, then match the 1s in the subnet mask with the IP address based on the CIDR, the remaining part with 0s is the host bit)
Number of available hosts: 2 ^ (8 - 2) = 254
Network Address: 192.168.1.0
First Assignable IP: 192.168.1.1
Last Assignable IP: 192.168.1.254
Broadcast Address: 192.168.1.255

Example 2: 205.150.65.0/26
IP address class: C
CIDR: /26
Subnet mask(decimal): 255.255.255.0 now becomes 255.255.255.192
Subnet mask(binary): 11111111.11111111.11111111.11000000 (since the CIDR is /26, the last bit becomes 11000000)
IP address(binary): 11001101.10010110.01000001.00000000
Network bit: 26
Host bit: 32 - 26 = 6 
Number of available hosts: 2 ^ (6 - 2) = 62
Network Address: 205.150.65.0
First Assignable IP: 205.150.65.1
Last Assignable IP: 205.150.65.62
Broadcast Address: 205.150.65.63

OSI Model
The OSI (Open Systems Interconnection) model is a conceptual framework that describes how data travels through a network. It divides network communication into seven layers, each with specific responsibilities.

A mnemonic to remember the 7 layers is All People Seem To Need Data Processing or Please Do Not Throw Sausage Pizza Away from top to bottom or bottom-up, respectively.

Layer	OSI Layer	What Happens Here	Examples
7	Application	User initiates a request to the server with a specified protocol	HTTP, HTTPS, FTP, DNS, SMTP
6	Presentation	Translates, encrypts, compresses data	SSL/TLS, JPEG, MP4, ASCII
5	Session	Starts, manages, and ends sessions. Browser creates a session to avoid multiple authentication with the server.	API sessions, NetBIOS, RPC
4	Transport	Breaks data into chunks (segments); ensures delivery	TCP, UDP, ports (e.g., port 80, 443)
3	Network	Finds path to destination; adds IP addresses	IP, ICMP, Routers
2	Data Link	Requests are sent to switches, and these switches convert data to frames, which also adds a MAC (informs the switches about other components within the network) from the IP address sent from the previous layer	Ethernet, MAC address, ARP, Switches
1	Physical	Data is transmitted through electronic signals using optical cables	Cables, Wi-Fi, Hubs, Network Interface

This is a beginner-friendly article that explains:

How computers communicate using IP addressing.
Subnets, CIDR notation and calculating IP ranges.
How to calculate subnet info and IP ranges with real examples.
The OSI model.

At this point, you should have a solid grasp of how IP addressing works, what subnets do, how to calculate hosts and ranges, and how the OSI model fits into the bigger networking picture. These aren’t just theories, they are skills needed in cloud computing, DevOps, and system design. Whether you’re debugging network issues or configuring infrastructure on AWS, understanding these fundamentals gives you confidence and clarity.

In Part 2, I will put this knowledge into practice by building real subnets on AWS and testing traffic flow within a real network infrastructure, all using Terraform.

Share this with someone who is learning DevOps or networking!

Until then, stay curious and happy subnetting! ✌

Dockerizing a FastAPI CRUD App: Automating Builds and Pushes with GitHub Actions

Kene Ojiteli — Wed, 09 Apr 2025 19:33:49 +0000

FastAPI is a high-performance Python framework for building APIs, and Docker allows us to containerize applications to make them easier to deploy. In this guide, we'll containerize a FastAPI app with Docker, and automate the build and push of the Image to a private container registry using GitHub actions.

Prerequisites

Python and fastAPI dependencies (including pydantic for validation, fastAPI, uvicorn).
Docker - to build the fastAPI application into an image and push to a private registry.
GitHub and GitHub Actions: for version control and CICD to automate image build and push.
Terminal and a code editor / IDE: for code development, image building and CICD.

Steps taken

Testing the application locally.
Manually build the image.
Automate with GitHub Actions.

Testing the application locally

Install Python and fastAPI using pip, verify the installation by checking the version
Create a main.py, requirements.txt (I did a pip freeze and saved it to the requirements.txt file).
The main.py contains the CRUD app built with fastAPI.

I also installed an email-validator, since my validation with pydantic requires validating the email field.

I ran the application with uvicorn main:app --reload

I accessed the application via http://127.0.0.1:8000/users/ or via http://127.0.0.1:8000/docs#/

Manually build the image

I built the image with the Dockerfile (as a best practice, I copied the project's dependencies in the requirements file before copying other application files needed, to leverage Docker's caching) in the project directory.
The Dockerfile contains the instructions to create the Docker image.

I created a container with the new image to test that the application worked fine. I had to exec into the container to test with curl.

Automate Image build and push with GitHub Actions

Working with the GitHub container registry (a private registry) requires generating a Personal Access Token (PAT), my password to log in to the registry and push my image.
To generate a Personal Access Token (PAT), navigate to settings => developer settings => personal access tokens(tokens classic) and generate a new token(classic), with read, write and delete packages permission, ensure to :
- Give the token a name.
- An expiration date.
- Copy the token to a safe place as it is viewable only once.

Before setting up my workflow, I added my generated PAT and my username as a repository secret, which was used for authentication to the GitHub container registry.

After adding secrets, this is what it should look like.
To automate with GitHub actions, I created a ./github/workflows folder with a build_push.yml file containing the workflow.

After the workflow file is completed, initialize the repo, add files and remote origin, commit and push code to GitHub.
Once the code is pushed to GitHub, it triggers the workflow(the workflow is configured to trigger when there is a push or pull request event on the repository), which builds the image, logs into the registry and pushes the image.

After pushing to the registry, the image can be viewed using this URL format: https://github.com/users/YOUR_USERNAME/packages

Challenges encountered and fixes

I had a couple of unsuccessful builds, and I realised there were some rules to follow while working with GitHub container registry. I will be outlining some challenges I encountered and how I resolved them.

Some of the challenges I encountered included:

I discovered that GitHub Container Registry (GHCR) requires all repository names to be in lowercase, a suggested fix was to change from tags: ghcr.io/${{ github.actor }}/fast-api-crud:latest to tags: ghcr.io/${{ github.repository_owner }}/fast-api-crud:latest (this converts username to lowercase using GitHub's toLower function)

The option above did not work, so I renamed my GitHub account (this is not advisable, but I took the risk) and removed all uppercase letters, and updated my secret.

The next error is something around organizations. I do not know much about organizations, so I deleted the organizations attached to my account (it was not useful to me anymore) and renamed the secret name for my token from TOKEN to GHCR_PAT (I also effected this change on the workflow).
I also forgot to allow pip read the list of dependencies from the specified file (requirements.txt). I fixed it by adding the -r flag.

This tutorial shows how to:

Structure a FastAPI application for seamless containerization.
Write a Dockerfile to package the app into a container.
Automate builds and pushes using GitHub Actions.
Troubleshoot common issues with private container registries.

Because this setup is automated, any code changes automatically trigger a new Docker image build and push to GitHub container registry, which streamlines the deployment process.

Thank you for reading, kindly check out the repository. Till my next project, happy building! ✌🏽

Configuration Management With Ansible.

Kene Ojiteli — Fri, 09 Jun 2023 08:42:12 +0000

Introduction
In the world of DevOps where automation is necessary, ansible is one tool used to automate tedious and manual tasks.

What is Ansible?
Ansible is a configuration management tool used to automate repetitive tasks like cloud provisioning, and application deployment.

Ansible connects to nodes and uses the concept of control and managed nodes and push modules to them from a centralized place. This will then execute the modules and automatically remove them when the action is complete.

Ansible is agentless in the sense that no additional software is required to be installed on the target machines, ansible is just executing bash commands or actions over SSH or Windows Remote Management connections.

Basic Ansible Terms

Hosts: a machine (either physical hardware or remote) hosted by ansible.
Inventory: a collection of all the hosts and groups that Ansible manages.
Group: Several hosts grouped together that share a common attribute.
Module: Units of code that Ansible sends to the nodes for execution or actions run by tasks.
Tasks: Units of action that combine a module and its arguments along with some other parameters.
Playbooks: An ordered list of tasks along with their necessary parameters that define a recipe to configure a system.
YAML: A popular and simple data format that is very clean and understandable by humans (Ansible playbooks are written in YAML format).
Roles: Redistributable units of organization that allow users to share automation code easier.

Demo: In this article, I will demo how to use ad hoc commands (a quick way to run a task on one or more managed nodes) and how to use ansible playbook to install an application on a virtual machine.

Prerequisites

A cloud provider (Azure with an active subscription) - to create virtual machines.
An SSH client (I will be using Mobaxterm) to SSH into my VMs.

Steps

Login to your Azure account and create a virtual machine (for now I will create 1 VM which will be my control node).
Using an SSH client, I will SSH into my control node

To enable me ssh into other machines, I will need to create an ssh key on my control node using ssh-keygen -t rsa command

After which I will navigate to the directory and get the public key.
Go to the Azure portal, search for ssh keys and create a key with the public key gotten from the step above.
I will create 2 VMs that will serve as my managed nodes with the public key so as to enable swift ssh connection between the control node and managed nodes.
SSH into VM1 using ssh <ip address of vm> on the control node.

And use exit to logout out of the machine (I repeated the same process on my second VM).
I will install ansible on the control node (no installation will be done on the managed node because ansible is agentless).
Firstly, I will run sudo apt-get update command to download information for all packages listed in the sources file.
Then install ansible with sudo apt install ansible command.
Checking to see if the installation was successful by using ansible --version command.
I will create an inventory file to store a list of my host and group (I grouped my hosts in a test group); note that the default inventory file is located in /etc/ansible/hosts
Using ad hoc command: ansible test -i inventory -m ping to execute a ping command on all hosts.

Using ansible playbook to deploy a website on virtual machines
Ansible playbooks are the simplest way to automate repeating tasks in the form of reusable and consistent configuration files. They are written in YAML and contain any ordered set of steps to be executed on our managed nodes.

My playbook which will deploy a website on my target machines is in the main.yml file

Before executing the play book command, notice that the VMs are empty (not accessible).

Using ansible-playbook -i inventory main.yml command to run playbook; notice that it runs each task for the 2 managed nodes/target machines I specified in my inventory file.

After the playbook is run, I can now access the website on both target machines (notice the different IP addresses for both machines on the images below)

Things to note

Ansible is agentless meaning that no additional software installation is required on the managed nodes.
Ansible is just executing commands over SSH.
The default inventory file in ansible is located in /etc/ansible/hosts.
Ansible modules are idempotent which means that changes are applied only if needed; the current state is checked and nothing is done unless the current state is different from the specified final state.
Ansible playbooks are written in yaml format

Challenge Encountered: the challenge I encountered was the inability to establish an ssh connection between my VMs, but this was resolved by creating an ssh key and passing the public key to the managed nodes while the control node had the private key.

Conclusion: through this tutorial, we have learned:

About ansible and its basic terms.
How to use a simple ad hoc command to ping host machines.
How to use a playbook to deploy a website on a virtual machine.

Kindly visit the project repo and thank you for reading.

My SCA Cloud School Experience: Cohort 4.

Kene Ojiteli — Fri, 26 May 2023 12:33:16 +0000

At some point in my life, I was passionate about Cloud and DevOps Engineering and decided to make a career out of it after trying my hands at Frontend, Backend, and Cybersecurity.

She Code Africa (SCA) Cloud School is a cohort-style, Bootcamp program specifically targeted at ladies across Africa, looking to kick off or switch careers into the Site Reliability Engineering (SRE) field organized by She Code Africa (a registered non-profit organization aimed at empowering young girls and women across Africa with technical and soft skills needed to match or scale their careers in STEM) in partnership with Deimos.

I joined the SCA Community while trying to gain experience in front-end development, and I learned about Cloud school via the community and Linkedin. I applied for the boot camp with high hopes and also had the opportunity to attend a Twitter space which talked about the program (and also we were told to learn how to work with technologies like Docker and Kubernetes) and also got to connect with ladies from past cohorts.

After a daily refresh of my emails for weeks, I finally got a mail saying I passed the first stage of the selection process, with instructions for the second stage (which was to record a video of myself talking about my journey, how the program will help in my journey and why I am a good fit for the program); I finally passed both stages and I was overjoyed.

The successful 50 ladies had an onboarding call where we were briefed on how the whole program will be and also split into 2 classes (Ruby and Emerald) before the program commenced.

Start of Cloud School: The program started with introductions to our facilitators and also a general introduction to cloud computing, (My facilitator was really awesome because she made the class interactive); As someone who is a big fan of AWS, I started losing interest in the program because the main cloud provider taught in cloud school was Azure (before cloud school, I was never an azure fan, but thanks to cloud school and my facilitator I have a special relationship with Microsoft Azure).

Some of the projects I worked on in SCA cloud school are

During the program we also had to do some evaluation to test our progress, and a final project.

Final Project: We had one week to work on our project which was either on:

Containerizing an application and deploying on Kubernetes.
Deploying an application to azure using web app service and SQL.

I went for the docker and kubernetes project and wrote a detailed article because it was more interesting and challenging (I encountered some errors which halted my progress and I almost didn't submit my project) at the same time.

What I gained from SCA cloud school
Through the SCA Cloud school, I gained:

Knowledge on Azure, got conversant with various azure services by working on hands-on projects.
Knowledge on Microservices, Containerization and Container orchestration which is must know for a DevOps engineer.
How to share my learning by constantly writing articles.

Conclusion
I would like to thank the founder of She Code Africa Ada Nduka Oyom and the entire team for coming up with this initiative, My facilitators Oluwadamilola Aremu, Chiamaka Obitube for their effort and patience, and also Ruby class ladies.

I highly recommend this program for cloud computing beginners and also intermediates who will like to learn with peers.

I look forward to getting the internship opportunity with Deimos as this will be a great plus in my career.

Thank you for reading, you can follow me on Twitter, Linkedin, and Github

Deploying an Application on Kubernetes.

Kene Ojiteli — Sun, 21 May 2023 20:48:21 +0000

Introduction
Kubernetes is an open source technology used to autonomously deploy, scale, and manage applications that use containers. It is a popular container orchestration solution since it enables the control of several containers as a single entity as an alternative to managing each container separately.

This is a walkthrough of deploying an application to Azure Kubernetes Service similar to my previous article walkthrough.

What will be covered

Azure Kubernetes Service
Azure Container Registry
Docker Container
Azure CLI
Kubectl
Simple Node app

Overview
A note keeper app written in node js will be containerized and pushed to ACR, after which one Kubernetes cluster will be created on AKS and a deployment and a service will be created having 4 pod replicas via a manifest file.

Prerequisites

Terminal and Azure CLI installed on local machine - some of the steps for this project (such as connecting to kubernetes cluster will be done using Azure CLI).
Docker installed on local machine - which will be used to build an image and push to a registry (Azure Container Registry in this demo).
Azure account with active subscription.
Code Editor or IDE - which will be used to write code that will be containerized.
Terraform installed - an IAC tool that will be used to provision infrastructure on Azure.

Note: The required services can be created using either terraform, Azure portal or Azure CLI.

Getting Started

Testing sample app locally
- Write the code or fork and clone app from Github
- Navigate to application folder on terminal using cd <foldername>
- Install dependencies using npm install
- Run app to test using node <filename> or npm <filename>

Provision infrastructure on Azure with terraform using the following commands: terraform init terraform fmt terraform validate terraform plan terraform apply(note that a terraform file has a .tf extension)

Head to azure portal to confirm if infrastructure is provisioned

Containerize the application

After resources have been provisioned on azure, we need to login to ACR using credentials (which includes login server, username and password) from container registry => settings => access keys
Navigate to your project directory via terminal and login using the details from the step above docker login <login server> --username <username> --password <password>
Build docker image using this command docker build -t <name>:<tag> . where . is the current directory.

Check the image exists using docker images command ( this lists all available images, the first image is my newly created image).
Push the image to ACR using docker push <name>:<tag>

Going over to azure portal => container registry, to verify the push is successful.

I created a container using my image (exercising how to forward ports, run container in a detached mode, give container a specified name and run the app using the forwarded port on my local machine)

Connect to Cluster

kubectl will be used to manage the Kubernetes cluster. Run the command az aks get-credentials --resource-group <resourcegroupname> --name <clustername> to configure kubectl and connect to the cluster we previously created and also verify connection using kubectl get nodes to return a list of the cluster nodes.

Kubernetes Deployment: A Deployment is one of the Kubernetes objects that is used to manage Pods via ReplicaSets in a declarative way. It provides updates, control as well as rollback functionalities. This deployment file will be used to:
Create a deployment (which automatically creates a replicaset), service and pods.

Lists all objects created at once using kubectl get command

Get more details about the deployment, use kubectl describe deployments <deploymentname> command

Scale down replica set from 2 to 4

And also seeing the change in the events log

Deleting a pod and showing how a deployment always ensures the desired number of pods is always present.

Head to azure portal => kubernetes cluster => kubernetes resources => services and ingresses to view ports and pods.

The app can be accessed using external IP of the service.

Challenges encountered during this project

Creating a new azure account due to credit card issues
I encountered the ImagePullBackOff and ErrImagePull error which was as a result of not properly connecting my azure container registry to my kubernetes cluster, this was detected while debugging .

Changing my demo app from a note keeper app to a basic node app and back to my note keeper app due to ImagePullBackOff and ErrImagePull error.

Conclusion
This tutorial shows how to:

Create a Docker image for a node application
Push the image on ACR.
Deploy on kubernetes

The End.

Thank you for reading

Deploying a Container App on a Kubernetes Cluster.

Kene Ojiteli — Sun, 14 May 2023 18:16:32 +0000

Delving into the world of Containers and Container Orchestration, one might wonder what these terms mean.

Containers are a way to package software in a format that can run isolated on a shared operating system. Unlike Virtual Machines, containers do not bundle a full operating system - only libraries and settings required to make the software work.

Container Orchestration automates the provisioning, deployment, networking, scaling, availability, and lifecycle management of containers.

In this article, I will demo how to containerize an application and deploy on a kubernetes cluster.

Prerequisites

Docker installed on your local machine - which will be used to build image and push to a registry.
Azure account with active subscription
Terraform installed - an IAC tool that will be used to provision infrastructure on a cloud provider (Azure in this demo)
Code Editor or IDE with a terminal- which will be used to write code that will be containerized.
Azure CLI - to connect to kubernetes cluster.

Steps
There are 4 main steps which include:
Writing code for the application that will be containerized with docker

This section involves writing the code in a preferred programming language (I will be using node js).

Using terraform to provision infrastructure to Azure

Terraform is an infrastructure as code tool used to provision resources, instead of using the azure portal to create my resources, I will be using terraform, see terraform code

To make this creation possible, the following terraform commands will be used:

terraform init: initializes a working directory that contains terraform configuration files (note that a terraform file has a .tf extension)

Formatting and validating my code using the command below

terraform plan: used to preview the action terraform would take to modify your infrastructure.

terraform apply: similar to terraform plan but actually carries out the planned changes to each resource using the relevant infrastructure provider's API.

I created a resource group, container registry and azure kubernetes service on azure.

Using Docker to containerize the application and pushing to a registry

Dockerizing an application requires a Dockerfile which is a template that contains all the commands a user could call on the command line to build an image after which the image will be pushed to a container registry.

To push to a container registry, a connection first need to be established before login to the container registry.

I will head over to azure => container registry => settings => access keys

Navigate to your project directory via terminal and login using the details from the step above docker login <login server> --username <username> --password <password>

Build docker image using this command docker build -t <name>:<tag> . where . is the current directory.

Check the image exists using docker images command ( this lists all available images, the first image is my newly created image).

Push the image to ACR using docker push <name>:<tag>

Going over to azure portal => container registry, to verify the push is successful.

Deploying the web application to azure kubernetes cluster

Having created an azure kubernetes cluster using terraform, go over to azure portal to verify.

I will be using azure CLI to get credentials so as to connect to my cluster using the commands below

az login
az aks get-credentials --resource-group <resourcegroupname> --name <clustername> (this command downloads credentials and configures the kubernetes CLI to use them)

Verifying connection to my cluster using kubectl get nodes to return a list of the cluster nodes (note that I declared 1 cluster node and status = ready).

Create a deployment using a YAML manifest file that will roll out a replicaset to bring up specified number of instances of a specified pod and create a service (which enables network access to a set of pods) using kubectl apply -f <deploymentfile-name>.

A kubernetes deployment tells kubernetes how to create or modify instances of the pods that hold a containerized application.

To get more details about the deployment, use kubectl describe deployments <deploymentname> command
Using the commands below to get deployments, replicasets (a deployment automatically creates a replica set), service and pods (pod name usually starts with the deployment name).

Notice there are 2 pods, this is because my deployment file specified 2 replicas

Checking azure portal => kubernetes cluster => kubernetes resources => services and ingresses to view ports and pods.

Using external IP of the service with port to access the app
A use case of replicas (which specifies the number of pods that will run concurrently) can be seen when a pod is deleted and a new pod is automatically created based on the number of replicas stated in the manifest file, as shown below

kubectl get all lists all objects created at once
A deployment can also be updated to either increase or decrease number of instances by changing the replica value or changing the version of a container image, the former can be done using the command below:
The updated number of pods on AKS.
A list of updated pods
Cleaned up my resources using terraform destroy command.

Thank you for reading and I hope you learned something new, project code can be found on my repo

Connecting Azure App Service to Azure SQL Database and Storage Account using Azure CLI part 2.

Kene Ojiteli — Mon, 08 May 2023 13:46:34 +0000

This is a continuation of previous article which showed how to connect azure app service to an azure sql database using azure cli, it is important to read part 1 before this article so as to be aware of the prerequisites and some azure terms.

In this article, I'll demonstrate how to use azure cli to connect an azure app service to a storage account, this is similar to previous article but with slight differences

Prerequisites

An Azure account with an active subscription.
Azure Cloud shell or a Azure CLI installed on local machine.

Steps

Login into your azure account using az login command.
Create your script and save on an editor using .ps1 extension; then navigate to the directory where script is saved and run the script.

Note: Always ensure the storage account name is unique in lowercase and does not include special characters (like the screenshot above, I had to change the name to something unique demoaccount901).

Feel free to change your location and variable names.

Ensure the variable names on the script is preceded by $ to avoid errors like screenshot below on powershell.

As with the previous post, the following will be created: a resource group, app service plan and web app.
After that a storage account with a unique name will be created, through which our app service will connect with to store data.
Retrieving the connection string from the storage account to have access to stored data in app service.
And lastly assigning connection string to an app setting which are exposed as environment variables.

Viewing the created resources within the resource group on the azure portal.

Clean up resources with az group delete --name $resourceGroup

Thank you for reading and I hope you learned something new, view script on my repo

The End!!!

Connecting Azure App Service to Azure SQL Database and Storage Account using Azure CLI part 1.

Kene Ojiteli — Mon, 08 May 2023 11:56:27 +0000

This article is a walkthrough on how to connect an azure app service to an azure SQL database and also an azure storage account using the command line interface.

Recall the following terms:

Azure app service is a fully managed service which enables you to build and host web apps, mobile back ends, and RESTful APIs in the programming language of your choice without managing infrastructure.
Azure SQL database is a fully-managed platform as a service (PAAS), that handles management functions such as patching, upgrading, backups, etc and gives an SLA of 99.99% availability.
Azure storage account contains all of your Azure Storage data objects, including blobs, file shares, queues, tables, and disks.

Prerequisites for this project include:

An Azure account with an active subscription.
Azure Cloud shell or a Azure CLI installed on local machine (I will be using powershell with azure CLI installed).

Things to Note

I will be using powershell (an automated engine with an interactive command-line shell), I will run a powershell script (this file will contain all the configuration needed for connecting app service to azure sql database, and will be run at once).
I will breakdown the commands in the script via screenshot.

Steps

Create your script and save on an editor using .ps1 extension (showing it is a powershell script); then navigate to the directory where script is saved and run the script as shown below

This is a breakdown of my script with variables declared first.

Creating a resource group which will house all resources used in this demo with the command below:

Creating a resource group needs a resource group name, a location and a tag which will be referenced by calling my variables. Upon successful creation, the output will be:

Creating an app service plan that defines a set of compute resources for a web app to run, this requires a name, resource group and a location.

If all goes well, the output will look like this:

Creating a web app which requires an app service plan and a resource group.

With output as:

Since we need a database, it is essential to create a server for the database with parameters like server name, resource group, location, and username and password, this is done below with the output as:

To enable access to the server, a firewall rule is needed, this rule determines what traffic is allowed or blocked by the firewall.

Creating a database and attach it to the server using the database name, server, resource group variables and service objective.

Getting a connection string which is required by say the application hosted on the app service to form a connection with the database server, which requires the database name, server, client driver (ado.net in this demo) and output format stored in a variable using the command below:

Add login credentials to the connection string variable using the command below.

Assign the connection string to app setting in the azure app service, this would help to prevent exposing credentials.

After the script is run and successful, head over to azure portal to view the created resources.

From my resource group, the resources created are visible.

And my web app is running but without a content.

To avoid incurring excess charges on your azure account, clean up your resources using the command below:

az group delete --name $resourceGroup

which would prompt you to choose a yes or no.

Thank you for reading and I hope you learned something new, the powershell script is available on my repo

Kindly read part 2 of this article.