DEV Community: Ibrahim Oyinkolade

What CBN Data Localisation Means for Nigerian DevOps Engineers

Ibrahim Oyinkolade — Tue, 22 Sep 2026 10:51:33 +0000

If you are a DevOps engineer in Nigeria, you may have heard a lot more conversations recently about data localisation, Nigerian data centres, cloud migration, compliance, and data sovereignty.

At first, it sounds like a regulatory issue for banks, fintechs, compliance teams, and lawyers.

It isn't.

It is also an infrastructure problem.

And that means DevOps engineers are going to be part of the conversation.

In June 2026, the Central Bank of Nigeria (CBN) introduced measures requiring financial institutions and participants facilitating payments in Nigeria to ensure that payment transaction data generated within Nigeria is stored and managed within Nigeria. The requirement is scheduled to take effect from January 1, 2027.

This is significant because a large portion of modern financial infrastructure has been built around globally distributed cloud platforms.

So what happens when the question changes from:

"Where can we deploy this application?"

to:

"Where is this application's data allowed to live?"

That is where DevOps becomes much more than deploying applications.

First, what exactly is data localisation?

Data localisation means that certain categories of data must be stored, processed, or managed within a particular geographic jurisdiction.

In this case, the CBN requirement focuses on payment transaction data generated within Nigeria.

This does not mean that every application used by a Nigerian company must suddenly run entirely on servers physically located in Nigeria.

The exact regulatory scope matters.

The CBN circular specifically requires affected financial institutions and payment ecosystem participants to ensure that payment transaction data generated within Nigeria is stored and managed in Nigeria, with compliance required from January 1, 2027.

That distinction is important.

Because when engineers hear "data localisation", the first instinct may be:

"We need to move everything."

Not necessarily.

The real engineering question is:

Which data is regulated, where does it flow, where is it stored, and which components are allowed to process it?

Why should DevOps engineers care?

Modern DevOps environments are built around abstraction.

You can create an EC2 instance in seconds.

You can deploy a Kubernetes cluster with Terraform.

You can create an RDS database without knowing exactly which physical machine hosts it.

You can replicate data across regions.

You can move workloads between availability zones.

Cloud makes infrastructure feel almost location-independent.

Regulation brings geography back into the architecture.

Suddenly, things like:

Data residency
Database location
Backup location
Disaster recovery location
Log storage
Object storage
Monitoring systems
Third-party APIs
CI/CD pipelines
Secrets management
Replication
Encryption
Network routing

become compliance considerations.

The CBN's existing IT standards framework already treats areas such as enterprise architecture, solutions delivery, service operations, information security and data-centre infrastructure as important capabilities for the Nigerian financial-services industry.

So this isn't simply a new "cloud hosting" conversation.

It is an architecture and operations conversation.

1. "Which AWS region are we using?" becomes a serious question

For years, a Nigerian startup could provision infrastructure in regions such as:

Europe
        ↓
AWS / Azure / GCP
        ↓
Application
        ↓
Database

The conversation could largely focus on:

latency
availability
cost
service availability
disaster recovery

With localisation requirements, another question enters the architecture review:

Where is the data physically stored?

For regulated workloads, an architecture may instead need to look more like:

                  Internet
                     |
                     v
              Load Balancer
                     |
                     v
              Application Tier
                     |
          +----------+----------+
          |                     |
          v                     v
     Local Database       Local Object Storage
          |                     |
          +----------+----------+
                     |
                     v
             Local DR / Backup

The important part isn't simply the diagram.

It is knowing which components contain regulated data.

2. Your backup strategy suddenly matters even more

This is one of the areas I think DevOps engineers should pay particular attention to.

Imagine your production database is hosted locally.

You might think:

"We're compliant. Our database is in Nigeria."

But then your backup process does this:

Production DB
     |
     v
Automated Backup
     |
     v
S3 Bucket in another country

You may have just created a data residency problem.

The same applies to:

database snapshots
object-storage replication
disaster recovery
log archives
analytics pipelines
exported databases
machine-learning datasets

Data localisation therefore requires engineers to understand the entire data lifecycle, not just production infrastructure.

3. Disaster recovery becomes more complicated

Traditional cloud architecture often encourages geographical separation.

For example:

Primary Region
      |
      | replication
      v
Secondary Region

The reason is obvious.

If one geographic region becomes unavailable, another region can take over.

But if regulated data must remain in Nigeria, your disaster recovery strategy may need to remain within the country as well.

That creates an interesting engineering problem:

How do we achieve high availability and disaster recovery without moving regulated data outside the permitted jurisdiction?

This makes Nigerian infrastructure, local data centres, connectivity, power resilience and local cloud capabilities increasingly important.

The CBN's IT standards framework already identifies data-centre infrastructure and business continuity as important parts of financial-sector IT operations, with a target of Tier 3 data-centre maturity in its standards framework.

4. Logs are data too

This is an easy thing to overlook.

A developer might say:

"The database is in Nigeria."

But what about your logs?

Consider this architecture:

Application
    |
    +----> Database 🇳🇬
    |
    +----> Local Storage 🇳🇬
    |
    +----> Monitoring
    |
    +----> External Logging Platform 🌍

Your application logs might contain:

user_id
account_id
transaction_id
email
IP address
request payload
API response

Now your supposedly local application may be sending sensitive information to an external monitoring platform.

This is why DevOps engineers need to start thinking about observability as part of data governance.

Before shipping logs to a third-party service, ask:

What data is being collected?
Where is it stored?
Is sensitive information being logged?
Where is the logging provider's infrastructure located?
How long is the data retained?
Who can access it?
Is the data encrypted?
Can we redact sensitive fields before transmission?

The CBN's cybersecurity framework specifically recognises cloud-related risks including data breaches, data loss, lack of visibility, compliance and legal issues.

5. CI/CD pipelines also deserve attention

Most DevOps engineers focus on production when thinking about infrastructure.

But consider a typical pipeline:

Developer
   |
   v
GitHub
   |
   v
GitHub Actions
   |
   v
Docker Registry
   |
   v
Cloud Infrastructure

Now imagine the deployment pipeline also performs:

Database dump
       |
       v
Testing environment
       |
       v
External CI runner
       |
       v
External storage

That can introduce another data-flow problem.

A good DevOps engineer should therefore understand:

Where does data move during deployment, testing and recovery?

Not just:

Where does the production server live?

6. Infrastructure as Code becomes even more valuable

This is where tools like Terraform become particularly useful.

Imagine an organisation has several environments:

development
staging
production
disaster recovery

If data residency requirements apply to production and DR, infrastructure should not depend on someone remembering a compliance rule when clicking through a cloud console.

Instead, infrastructure can be expressed as code.

For example:

module "production_database" {
  source = "./modules/database"

  environment = "production"
  region      = var.approved_region
  encrypted   = true
}

The real implementation would obviously be more complex.

But the principle is important:

Compliance requirements should become infrastructure constraints where possible.

Instead of relying entirely on human memory:

"Please remember not to deploy this database outside Nigeria."

you move toward:

"Production databases can only be provisioned using approved infrastructure configurations."

This is where Policy as Code becomes particularly interesting.

7. DevSecOps will become more important

Data localisation does not mean:

"Put the server in Nigeria and we're done."

You still need to protect the data.

The CBN's open-banking guidance, for example, requires participants to protect customer data and implement information-security controls, while also requiring appropriate controls around third-party providers.

For DevOps engineers, that means paying attention to:

Identity and access

Use:

IAM
RBAC
MFA
least privilege
short-lived credentials

Encryption

Protect:

data at rest
data in transit
database backups
object storage
secrets

Secrets management

Don't put credentials inside:

GitHub
Dockerfiles
Terraform files
Kubernetes manifests
.env files committed to repositories

Security scanning

Integrate:

SAST
DAST
Container scanning
Dependency scanning
IaC scanning
Secret scanning

into your CI/CD pipeline.

8. Local infrastructure doesn't automatically mean better security

This is another important distinction.

Moving infrastructure into Nigeria can address a location requirement.

It does not automatically solve:

ransomware
insider threats
credential theft
DDoS attacks
misconfiguration
privilege escalation
API attacks
supply-chain attacks

A poorly configured Nigerian server is still a poorly configured server.

The CBN's cybersecurity framework highlights risks associated with cloud services and requires regulated institutions to manage technology and cybersecurity risks appropriately.

So the target should not simply be:

Local infrastructure

It should be:

Local + secure + resilient + observable + auditable infrastructure.

9. This could change the skills Nigerian DevOps engineers need

This is probably the part I find most interesting.

For a long time, a DevOps learning path could look like:

Linux
   ↓
Git
   ↓
Docker
   ↓
AWS
   ↓
Kubernetes
   ↓
Terraform
   ↓
CI/CD
   ↓
Monitoring

Those skills are still valuable.

But the next layer increasingly looks like:

Cloud
  +
Security
  +
Compliance
  +
Data Governance
  +
Infrastructure Architecture
  +
Observability
  +
Disaster Recovery

A DevOps engineer working for a Nigerian bank or fintech may eventually need to answer questions such as:

Where is this database hosted?

Where are its backups stored?

Where are application logs stored?

Where does the disaster recovery environment live?

Which third-party services receive customer data?

Can this workload be deployed outside the approved geography?

How do we prove that it wasn't?

Who accessed the database?

Can we demonstrate this during an audit?

Those are not purely DevOps questions anymore.

They sit at the intersection of:

DevOps + Cloud + Security + Compliance.

10. Terraform + Policy as Code could become a powerful combination

Imagine a company defines approved infrastructure rules:

Production database
        |
        +--> Approved location
        |
        +--> Encryption required
        |
        +--> Backup required
        |
        +--> Monitoring required
        |
        +--> Logging enabled
        |
        +--> Restricted network access

Then tools such as Terraform and policy engines can help enforce those requirements.

A simplified workflow could look like:

Developer
    |
    v
Terraform Code
    |
    v
Security / Policy Checks
    |
    +---- FAIL ---> Fix configuration
    |
    v
Approved Infrastructure
    |
    v
Deployment

This is much stronger than waiting until after deployment to discover that infrastructure violates an internal policy.

11. Multi-cloud architecture may become more nuanced

There is a tendency to hear "data localisation" and conclude:

"Everyone should stop using AWS, Azure and Google Cloud."

That's too simplistic.

The actual architectural decision depends on:

what data is regulated
where the relevant cloud services are physically located
the organisation's regulatory obligations
contractual arrangements
security controls
availability requirements
cost
performance
disaster recovery requirements

The CBN itself recognises the use of cloud services in financial institutions and highlights both their benefits and associated risks.

So the future may not necessarily be:

Cloud OR Nigerian Data Centre

It may increasingly be:

Global Cloud
      +
Local Infrastructure
      +
Strong Data Classification
      +
Controlled Data Flows

That could lead to more hybrid architectures.

12. Data classification becomes an engineering responsibility

Before you can decide where data should go, you need to know what the data is.

For example:

Data	Example	Engineering consideration
Public	Marketing content	Low restriction
Internal	Internal application metrics	Controlled access
Sensitive	Customer information	Strong controls
Financial	Payment transaction data	Regulatory requirements
Secrets	API keys/passwords	Never expose or log

This means DevOps engineers need to become comfortable working with concepts such as:

data classification
data residency
data retention
data encryption
access control
audit trails
data lifecycle management

You don't necessarily need to become a lawyer.

But you should understand enough compliance language to translate requirements into infrastructure.

13. The biggest opportunity may be in compliance automation

There is a huge difference between:

"Our infrastructure is compliant."

and:

"We can continuously demonstrate that our infrastructure is compliant."

The second one is where DevOps shines.

Imagine a system that continuously checks:

✓ Database location
✓ Backup location
✓ Encryption status
✓ IAM configuration
✓ Public exposure
✓ Security groups
✓ Kubernetes configuration
✓ Container vulnerabilities
✓ Logging configuration
✓ Resource changes

and produces an audit trail.

That is essentially Compliance as Code.

Instead of compliance being a document reviewed once every few months, compliance becomes part of the engineering workflow.

What should Nigerian DevOps engineers start learning?

If you are currently learning DevOps in Nigeria, I wouldn't recommend abandoning the fundamentals.

Instead, build on top of them.

Core infrastructure

Learn:

Linux
Networking
Git
Docker
Kubernetes
Terraform
CI/CD

Cloud

Understand:

AWS
Azure
Google Cloud
IAM
networking
storage
databases
high availability
disaster recovery

Security

Add:

DevSecOps
vulnerability management
secrets management
encryption
IAM
threat modelling
container security
Kubernetes security

Compliance

Understand the basics of:

NDPA
CBN technology requirements
data residency
data classification
auditability
retention
third-party risk

Observability

Learn:

Prometheus
Grafana
centralized logging
tracing
alerting
audit logs

Infrastructure governance

Explore:

Terraform
Open Policy Agent
policy as code
infrastructure scanning
automated compliance checks

This combination will make you much more useful than simply knowing how to deploy an EC2 instance.

A practical project idea

If you're learning DevOps, here's a project you can build around this topic.

Build a Nigeria-compliant fintech infrastructure simulation.

The application itself can be simple.

Your focus should be the infrastructure.

Architecture

                  Internet
                     |
                     v
               Load Balancer
                     |
                     v
              Application
                     |
          +----------+----------+
          |                     |
          v                     v
    Local Database       Local Object Storage
          |
          v
      Local Backup
          |
          v
      Local DR

Then implement:

Infrastructure

Terraform
Docker
Kubernetes
Nginx
PostgreSQL

Security

IAM/RBAC
Secrets management
TLS
Network policies
Container scanning

CI/CD

GitHub Actions
automated tests
Docker image scanning
Terraform validation
policy checks

Observability

Prometheus
Grafana
application logs
infrastructure metrics
alerts

Governance

Create policies that prevent:

Production database
        ↓
Unapproved location
        ↓
Deployment blocked

Then document:

where customer data is stored
where backups are stored
how data is encrypted
who can access it
how deployments are controlled
how incidents are handled
how compliance can be demonstrated

That project would demonstrate much more than simply:

"I know Docker and Kubernetes."

It would demonstrate that you understand production infrastructure in a regulated environment.

The bigger picture

Nigeria's financial system is becoming increasingly digital.

At the same time, regulators are paying more attention to:

cybersecurity
operational resilience
data governance
third-party technology risk
infrastructure
digital payments

The CBN's existing IT standards framework explicitly links technology standards with areas such as uptime, data integrity, business continuity, security assurance and risk management.

The new localisation requirement adds another dimension:

Where the infrastructure is located now matters.

And that changes the role of DevOps.

The DevOps engineer of the future won't only be asked:

"Can you deploy this application?"

They may also be asked:

"Can you deploy this application in a way that satisfies our security, availability, regulatory and data-residency requirements—and prove that it does?"

That is a much bigger responsibility.

And, in my view, it is also a much more interesting one.

Final thought

Data localisation should not be viewed simply as:

"CBN wants Nigerian data on Nigerian servers."

The engineering challenge is much broader.

It is about designing systems where we know:

what data we have,

where it goes,

where it is stored,

who can access it,

how it is protected,

how it is backed up,

how it is recovered,

and

how we can prove all of the above.

For Nigerian DevOps engineers, this is a signal that cloud engineering, security, compliance and infrastructure architecture are becoming increasingly connected.

The engineers who understand that intersection will be solving a very different class of problems.

And that is where DevOps gets really interesting.

Sources

Central Bank of Nigeria — IT Standards for the Nigerian Financial Services Industry.
Central Bank of Nigeria — Risk-Based Cybersecurity Framework for Deposit Money Banks and Payment Service Banks.
CBN Circular on market structure, data localisation and systemic oversight in the Nigerian payments system, June 15, 2026.
TechCabal — CBN's local data order puts Nigeria's data centres to test.
BusinessDay — Banks ready, fintechs lag as Nigeria's 2027 data localisation deadline nears.

Note: The June 2026 CBN circular is the key source for the January 1, 2027 localisation requirement. The CBN's public website search did not return the circular itself, so the circular's text above is cited through a reproduction of the document; readers implementing compliance should verify the authoritative CBN circular and any subsequent guidance directly with the regulator.

Stop Running `terraform apply` From Your Laptop: Building Your First Terraform CI/CD Pipeline with GitHub Actions

Ibrahim Oyinkolade — Thu, 23 Jul 2026 12:28:11 +0000

One of the biggest mistakes beginners make when learning Terraform is treating their local machine as the deployment server.

A typical workflow looks like this:

terraform init
terraform plan
terraform apply

While this approach is perfectly fine for learning, it quickly becomes problematic when working on real-world projects with multiple engineers.

Consider these questions:

Who deployed the infrastructure?
Was the infrastructure reviewed before deployment?
Can someone else reproduce the deployment?
What happens if the engineer's laptop is lost or misconfigured?
How do we know exactly what changed?

These are some of the reasons Infrastructure as Code (IaC) is almost always integrated with Continuous Integration and Continuous Deployment (CI/CD) pipelines in professional environments.

In this article, we'll build a simple Terraform CI/CD pipeline using GitHub Actions. Instead of focusing only on the YAML syntax, we'll first understand why each stage exists and how they work together to produce safe, repeatable infrastructure deployments.

What is Terraform CI/CD?

Terraform CI/CD is the process of automating the validation, planning, and deployment of infrastructure whenever changes are made to Terraform code.

Instead of running Terraform commands manually from a developer's laptop, a CI/CD platform executes those commands automatically in a controlled environment.

The workflow typically looks like this:

Developer
      │
      ▼
Git Push
      │
      ▼
GitHub Repository
      │
      ▼
GitHub Actions
      │
      ▼
Terraform Init
      │
      ▼
Terraform Validate
      │
      ▼
Terraform Plan
      │
      ▼
Manual Approval
      │
      ▼
Terraform Apply
      │
      ▼
AWS Infrastructure

This approach provides consistency, visibility, and security while reducing the chances of human error.

Why Not Run Terraform Manually?

Running Terraform from your laptop works well for personal projects, but it introduces several risks in a team environment.

Manual Deployment	CI/CD Deployment
Requires someone to remember every command	Runs automatically
Easy to skip validation	Validation is enforced
Difficult to track deployments	Every deployment is logged
Credentials live on developer laptops	Secrets are stored securely
Different Terraform versions on different machines	Consistent execution environment

Automation allows every infrastructure change to follow the same process, regardless of who made the change.

What We'll Build

Our goal is to create two independent GitHub Actions workflows:

Workflow 1 – Continuous Integration (CI)

This workflow checks the quality of our Terraform code by running:

terraform fmt
terraform init
terraform validate
terraform plan

Notice that this workflow never creates infrastructure.

Its job is simply to tell us whether the proposed changes are safe and valid.

Workflow 2 – Deployment

The deployment workflow is responsible for creating or updating infrastructure.

It runs only after we've decided that the Terraform plan is acceptable.

This separation is an important best practice because reviewing infrastructure changes is just as important as reviewing application code.

Project Structure

Our repository will look like this:

terraform-github-actions/
│
├── .github/
│   └── workflows/
│       ├── terraform-ci.yml
│       └── terraform-deploy.yml
│
├── main.tf
├── variables.tf
├── outputs.tf

Keeping the CI and deployment workflows separate makes them easier to understand, maintain, and extend as your project grows.

Understanding the CI Pipeline

The CI workflow is responsible for answering one question:

"Is this Terraform code ready to be deployed?"

To answer that question, it performs several checks.

Step 1: Check Formatting

Terraform enforces a consistent coding style.

Running:

terraform fmt -check

helps ensure every contributor follows the same formatting standards.

Step 2: Initialize Terraform

Before Terraform can validate or plan infrastructure, it must download the required providers and initialize the working directory.

This is done using:

terraform init

Step 3: Validate the Configuration

Next, Terraform verifies that the configuration is syntactically correct.

terraform validate

This catches missing arguments, invalid references, and other configuration issues before deployment.

Step 4: Generate an Execution Plan

Finally, Terraform generates an execution plan.

terraform plan

The plan shows exactly what Terraform intends to do without making any changes.

For example:

Resources to be created
Resources to be updated
Resources to be destroyed

Reviewing this output is one of the most important parts of an Infrastructure as Code workflow.

Separating CI From Deployment

One question I often get from students is:

"If the CI workflow already runs terraform plan, why do we need another deployment workflow?"

The answer is simple.

The CI workflow is designed to verify infrastructure.

The deployment workflow is designed to change infrastructure.

Keeping these responsibilities separate gives teams greater control over when deployments occur.

A typical process looks like this:

Push Code
     │
     ▼
CI Pipeline
     │
     ▼
Plan Generated
     │
     ▼
Engineer Reviews Changes
     │
     ▼
Deployment Triggered
     │
     ▼
Terraform Apply

This approach prevents accidental deployments and encourages proper change review.

Managing AWS Credentials Securely

One mistake beginners frequently make is hardcoding AWS credentials inside Terraform code or GitHub workflows.

Never do this.

Instead, GitHub provides encrypted repository secrets that can be accessed securely during workflow execution.

This keeps sensitive information out of your source code and version history.

In future articles, we'll go one step further by replacing long-lived AWS access keys with GitHub's OpenID Connect (OIDC) integration, eliminating the need to store AWS credentials altogether.

What's Next?

In this article, we've explored the concepts behind Terraform CI/CD and why separating validation from deployment leads to safer infrastructure automation.

In the next article, we'll build our first GitHub Actions workflow from scratch, understand every line of the YAML file, and automate Terraform validation and planning for an AWS project.

By the end of the series, we'll have a production-ready pipeline capable of deploying infrastructure securely using GitHub Actions and Terraform.

Final Thoughts

Learning Terraform isn't just about writing .tf files.

Professional Infrastructure as Code is built on repeatable processes, code reviews, secure credential management, and automated deployments.

GitHub Actions gives us the tools to implement those practices, and Terraform provides the foundation for describing infrastructure as code.

Together, they enable teams to build reliable, scalable, and auditable cloud infrastructure.

If you're just starting your DevOps journey, mastering this workflow is one of the best investments you can make.

You can find the complete examples used in this article in my GitHub repository:

github repo

Building Docker Containers with Persistent Storage

Ibrahim Oyinkolade — Thu, 02 Jul 2026 11:12:48 +0000

One of the first surprises new Docker users encounter is that data disappears when a container is removed.

Imagine deploying a web application or a database inside a Docker container. Everything works perfectly until the container crashes or you redeploy your application. Suddenly, all your uploaded files, logs, or database records are gone.

Why?

Because containers are ephemeral by design. They are designed to be created, destroyed, and recreated quickly. Unless data is stored outside the container, it disappears together with the container.

In this article, you'll learn the three common ways Docker handles storage and when each one should be used.

Understanding Docker Storage

There are three common ways to work with data in Docker:

Storage Type	Persists After Container Removal?	Managed By
Container Writable Layer	❌ No	Docker
Bind Mount	✅ Yes	Host Machine
Docker Volume	✅ Yes	Docker

Let's explore each one with practical examples.

1. Container Writable Layer (Ephemeral Storage)

By default, every Docker container has a writable layer where files can be created or modified while the container is running.

Think of it like a teacher writing notes on a whiteboard during a class. Once the class ends and the board is cleaned, everything written on it is gone.

Similarly, when a container is removed, everything stored inside its writable layer is lost.

Step 1: Start a container

docker run -it --name notes alpine sh

Inside the container:

echo "My first note" > notes.txt
cat notes.txt

Exit the container:

exit

Remove it:

docker rm notes

Create a new container:

docker run -it --name notes alpine sh

Try reading the file again:

cat notes.txt

Observation

The file no longer exists because it was stored only inside the container.

When is this useful?

Temporary files
Cache
Generated reports
Session data

2. Bind Mount

A bind mount connects a folder on your host machine directly into a container.

Think of it as giving someone access to a folder on your computer. They can read from it and write to it, and you can immediately see the changes from your host machine.

Unlike the container's writable layer, the data remains on your computer even after the container is deleted.

Create a folder

mkdir docker-notes

Run the container:

docker run -it \
  --name bind-demo \
  -v $(pwd)/docker-notes:/app/data \
  alpine sh

Inside the container:

echo "Bind Mount Note" > /app/data/notes.txt

Exit:

exit

Verify the file on your host machine:

cat docker-notes/notes.txt

Remove the container:

docker rm bind-demo

Check the file again:

cat docker-notes/notes.txt

Observation

The file is still available because it is stored on the host machine, not inside the container.

Common Use Cases

Local development
Editing source code
Sharing files between host and container

3. Docker Volumes

Docker volumes are the recommended way to persist data in production.

Unlike bind mounts, Docker manages the storage location for you.

Think of a Docker volume as a portable external drive that Docker can attach to any container whenever it starts.

This is the preferred method for storing application and database data.

Create a volume

docker volume create notes-volume

Run a container using the volume:

docker run -it \
  --name volume-demo \
  -v notes-volume:/app/data \
  alpine sh

The option

-v notes-volume:/app/data

attaches the Docker volume to the container.

Inside the container:

echo "Volume Note" > /app/data/notes.txt

Exit:

exit

Remove the container:

docker rm volume-demo

Start another container using the same volume:

docker run -it \
  --name volume-demo2 \
  -v notes-volume:/app/data \
  alpine sh

Check the file:

cat /app/data/notes.txt

Observation

The file still exists because it was stored inside the Docker volume instead of the container.

Common Use Cases

Databases
Production applications
User uploads
Application logs

Comparison

Feature	Writable Layer	Bind Mount	Docker Volume
Persists after container removal	❌	✅	✅
Stored on host	❌	✅	✅
Managed by Docker	✅	❌	✅
Best for Production	❌	⚠️ Sometimes	✅
Best for Development	❌	✅	✅

Which One Should You Use?

Choose the storage option that matches your use case:

Container Writable Layer → Temporary data that doesn't need to survive.
Bind Mount → Local development where you want to edit files directly on your machine.
Docker Volume → Databases and production workloads where persistent storage is essential.

Final Thoughts

Understanding Docker storage is one of the most important skills for anyone learning containers.

If you don't store your data correctly, removing a container can also remove everything your application has generated.

As a general rule:

Use the container writable layer for temporary data.
Use bind mounts during development.
Use Docker volumes in production.

Following these best practices will help you build containerized applications that are reliable, portable, and easier to maintain.

Resources

You can find the complete examples used in this article in my GitHub repository:

👉 https://github.com/highbee2810/Docker_storage_tutorials

If this article helped you, consider leaving a ❤️ and following me for more practical Docker, DevOps, and Cloud tutorials.

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

Ibrahim Oyinkolade — Thu, 19 Jun 2025 14:59:47 +0000

When it comes to Infrastructure as Code (IaC), one of the first tools that comes to mind is Terraform. Developed by HashiCorp, Terraform is widely adopted because of its simplicity, ease of installation, and support for multiple cloud providers.

In this blog post, I'll walk you through how to use Terraform modules to deploy a 3-tier architecture on AWS. By the end, you’ll understand how modular Terraform projects are structured and how to build reusable infrastructure components.

What is a Terraform Module?

A Terraform module is a collection of .tf files grouped together to perform a specific task or provision a particular resource. You can think of a module as a reusable template for deploying cloud infrastructure.

Terraform code is written in HCL (HashiCorp Configuration Language), which is human-readable and much easier to understand than languages like C or Java.

The primary purpose of using modules is to avoid code repetition and to promote reusability and maintainability in your infrastructure.

There are:

Official AWS modules in the Terraform Registry
Community-contributed modules
And of course, custom modules you can write yourself

The 3-Tier Architecture We’re Deploying

In this project, we’ll deploy the following infrastructure on AWS:

A VPC with public and private subnets
An Internet Gateway for the public subnet
A NAT Gateway for the private subnet
EC2 Instances in each tier (Frontend, Backend, and Database)
Security Groups and Network ACLs to control traffic rules

Here’s a simple breakdown of the three tiers:

Tier	Purpose
Presentation Layer	Frontend (e.g., React app)
Business Logic Layer	Backend (e.g., Node.js or Django)
Database Layer	RDS or MySQL/PostgreSQL

📁 Project Folder Structure

Assuming Terraform is already installed on your machine (if not, check out Terraform installation guide), here’s how you should organize your project:

project-root/
│
├── main.tf
├── variables.tf
├── outputs.tf
├── provider.tf
│
└── modules/
    ├── vpc/
    ├── compute/
    └── network/

📝 Note: To keep the blog concise, I won’t paste all the code here. You can find the full source code in my GitHub repository.

🧠 What Each Terraform File Does

File	Purpose
main.tf	Entry point – defines the resources and calls the modules
variables.tf	Contains input variables (like AMI IDs, instance types, subnet IDs)
outputs.tf	Displays outputs after successful deployment (e.g., public IPs, VPC IDs)
provider.tf	Declares the cloud provider (e.g., AWS region, access keys)

The module directories (like vpc, compute, and network) each contain .tf files that define the logic to deploy VPCs, EC2s, and other networking components.

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`

Terraform keeps track of the infrastructure it manages using a file called terraform.tfstate. This file is critical because it:

Stores the current state of your deployed infrastructure
Allows Terraform to know what exists, what to create, update, or destroy

Now here’s where terraform.tfstate.backup comes in:

terraform.tfstate.backup is an automatic backup of your last good known state.

Whenever you run a command like terraform apply, Terraform creates a new terraform.tfstate and moves the previous version to terraform.tfstate.backup. This ensures that:

If something goes wrong, you can manually restore the backup
You don’t lose the entire state file due to corruption or interruption

💡 Best Practice: Never share your state file publicly. It often contains sensitive information like resource IDs, passwords, and more. Use remote backends (like S3 with encryption) for production environments.

Final Thoughts

Using Terraform modules makes your infrastructure more modular, scalable, and easy to maintain. Whether you're managing a simple EC2 instance or a full-blown 3-tier app on AWS, breaking your setup into logical modules helps avoid repetition and enhances reusability.

Let me know what you’d like to see next — maybe monitoring this infrastructure with Prometheus and Grafana? Or setting up CI/CD pipelines with GitHub Actions?

🔗 Full Source Code

GitHub Repository – 3-Tier Architecture with Terraform

If you found this post helpful, feel free to like, share, or leave a comment. You can connect with me on LinkedIn for more DevOps and cloud tips!

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

Ibrahim Oyinkolade — Thu, 19 Jun 2025 14:54:20 +0000

What is a Terraform Module?

Terraform code is written in HCL (HashiCorp Configuration Language), which is human-readable and much easier to understand than languages like C or Java.

The primary purpose of using modules is to avoid code repetition and to promote reusability and maintainability in your infrastructure.

There are:

Official AWS modules in the Terraform Registry
Community-contributed modules
And of course, custom modules you can write yourself

The 3-Tier Architecture We’re Deploying

In this project, we’ll deploy the following infrastructure on AWS:

A VPC with public and private subnets
An Internet Gateway for the public subnet
A NAT Gateway for the private subnet
EC2 Instances in each tier (Frontend, Backend, and Database)
Security Groups and Network ACLs to control traffic rules

Here’s a simple breakdown of the three tiers:

Tier	Purpose
Presentation Layer	Frontend (e.g., React app)
Business Logic Layer	Backend (e.g., Node.js or Django)
Database Layer	RDS or MySQL/PostgreSQL

📁 Project Folder Structure

Assuming Terraform is already installed on your machine (if not, check out Terraform installation guide), here’s how you should organize your project:

project-root/
│
├── main.tf
├── variables.tf
├── outputs.tf
├── provider.tf
│
└── modules/
    ├── vpc/
    ├── compute/
    └── network/

📝 Note: To keep the blog concise, I won’t paste all the code here. You can find the full source code in my GitHub repository.

🧠 What Each Terraform File Does

File	Purpose
main.tf	Entry point – defines the resources and calls the modules
variables.tf	Contains input variables (like AMI IDs, instance types, subnet IDs)
outputs.tf	Displays outputs after successful deployment (e.g., public IPs, VPC IDs)
provider.tf	Declares the cloud provider (e.g., AWS region, access keys)

The module directories (like vpc, compute, and network) each contain .tf files that define the logic to deploy VPCs, EC2s, and other networking components.

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`

Terraform keeps track of the infrastructure it manages using a file called terraform.tfstate. This file is critical because it:

Stores the current state of your deployed infrastructure
Allows Terraform to know what exists, what to create, update, or destroy

Now here’s where terraform.tfstate.backup comes in:

terraform.tfstate.backup is an automatic backup of your last good known state.

Whenever you run a command like terraform apply, Terraform creates a new terraform.tfstate and moves the previous version to terraform.tfstate.backup. This ensures that:

If something goes wrong, you can manually restore the backup
You don’t lose the entire state file due to corruption or interruption

💡 Best Practice: Never share your state file publicly. It often contains sensitive information like resource IDs, passwords, and more. Use remote backends (like S3 with encryption) for production environments.

Final Thoughts

Let me know what you’d like to see next — maybe monitoring this infrastructure with Prometheus and Grafana? Or setting up CI/CD pipelines with GitHub Actions?

🔗 Full Source Code

GitHub Repository – 3-Tier Architecture with Terraform

If you found this post helpful, feel free to like, share, or leave a comment. You can connect with me on LinkedIn for more DevOps and cloud tips!

Key DevOps roles and responsibilities

Ibrahim Oyinkolade — Sat, 31 Aug 2024 13:47:13 +0000


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/samdq79lzlhd3q4x8qn3.png)

DevOps vs Traditional Software Development: A Comprehensive Comparison

Ibrahim Oyinkolade — Sat, 31 Aug 2024 13:10:17 +0000

In software development, two primary approaches stand out: the traditional Waterfall model and the more modern DevOps methodology. Each has its unique characteristics, advantages, and challenges. This blog post explores the fundamental differences between these approaches to help you understand which might best suit your needs.

Traditional Software Development Process

The traditional software development process, often called the Waterfall model, is a linear and sequential approach. It follows a structured path through distinct phases: requirements, design, coding/implementation, testing, and deployment. Each stage must be completed before moving on to the next, with the output of one phase serving as the input for the next.

** Pros:**

Clear Specifications: Provides a well-defined specification at each stage, which helps in understanding requirements and goals clearly.
Comprehensive Documentation: Offers extensive documentation, which can be valuable for future reference and compliance.

Cons:

Rigidity: The rigid structure makes it difficult to accommodate changes once a phase is completed.
Time-Consuming: Progressing through each phase sequentially can be slow, delaying the final delivery.
Error Correction Challenges: Identifying and fixing mistakes early in the process is difficult, often leading to costly fixes later on.

** DevOps Approach**

DevOps is a modern approach that fosters a collaborative culture between development and operations teams. It emphasizes automation, continuous integration, and continuous deployment/delivery to accelerate the software development lifecycle and improve product quality.

** Pros:**

Speed: Enables rapid development and deployment, significantly reducing time-to-market.
Quality: Continuous integration and testing ensure high-quality software.
Flexibility: Easily adapts to changes, allowing for iterative improvements.
Ease of Maintenance: Streamlined processes make debugging and maintenance more efficient.

Cons:

Adoption Challenges: Implementing DevOps requires cultural shifts and can be difficult to adopt initially.
Documentation Complexity: Continuous changes can make maintaining comprehensive documentation challenging.

Conclusion

Choosing between traditional software development and DevOps depends on your specific needs. If you require a structured, well-documented process with clear specifications, the traditional approach might be suitable. However, if speed, flexibility, and collaboration are your priorities, embracing DevOps could be the better choice. Each method has its place, and understanding the differences will help you make an informed decision.

Automating User and Group Management with a Bash Script

Ibrahim Oyinkolade — Tue, 02 Jul 2024 11:07:21 +0000

Automating User and Group Management with a Bash Script

inspired by HNG .

As a SysOps engineer, one of your routine tasks involves managing users and groups on a server. This can be time-consuming and prone to errors, especially when dealing with many users. Automation is the key to efficiency and reliability. This article will walk you through a Bash script that automates creating users and groups, setting up home directories with appropriate permissions, generating random passwords, and logging all actions.

This project was inspired by HNG internship 11, DevOps trcak of stage one.
visit HNG WEBSITE to learn more about the program

Overview

Creates users and their groups.
Adds users to additional specified groups.
Sets up home directories with correct permissions and ownership.
Generates random passwords for users.
Logs all actions to /var/log/user_management.log. Stores generated passwords securely in /var/secure/user_passwords.txt

A bash script create_users.sh will be created:

The script, create_users.sh, reads a text file containing usernames and their associated groups. Each line in the file is formatted as user;groups, where groups are delimited by commas. The script performs the following tasks:

Example Input File

light;sudo,dev,www-data
idimma;sudo
mayowa;dev,www-data

The script
Below is the complete script

#!/bin/bash

# Define log and password files
LOG_FILE="/var/log/user_management.log"
PASSWORD_FILE="/var/secure/user_passwords.txt"

# Create log and password files if they don't exist
touch $LOG_FILE
mkdir -p /var/secure
touch $PASSWORD_FILE

# Function to log messages
log_message() {
    echo "$(date +'%Y-%m-%d %H:%M:%S') - $1" | tee -a $LOG_FILE
}

# Function to generate random password
generate_password() {
    tr -dc A-Za-z0-9 </dev/urandom | head -c 12 ; echo ''
}

# Check if the input file is provided
if [ $# -ne 1 ]; then
    echo "Usage: $0 <input_file>"
    exit 1
fi

# Read the input file
INPUT_FILE=$1

# Check if the input file exists
if [ ! -f $INPUT_FILE ]; then
    echo "Input file not found!"
    exit 1
fi

while IFS=';' read -r username groups; do
    # Remove leading and trailing whitespaces
    username=$(echo $username | xargs)
    groups=$(echo $groups | xargs)

    if id "$username" &>/dev/null; then
        log_message "User $username already exists. Skipping..."
        continue
    fi

    # Create a personal group for the user
    groupadd $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create group $username."
        continue
    fi
    log_message "Group $username created successfully."

    # Create user and add to personal group
    useradd -m -g $username -s /bin/bash $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create user $username."
        continue
    fi
    log_message "User $username created successfully."

    # Create additional groups if they don't exist and add user to groups
    IFS=',' read -ra group_array <<< "$groups"
    for group in "${group_array[@]}"; do
        group=$(echo $group | xargs)
        if [ -z "$group" ]; then
            continue
        fi
        if ! getent group $group >/dev/null; then
            groupadd $group
            if [ $? -ne 0 ]; then
                log_message "Failed to create group $group."
                continue
            fi
            log_message "Group $group created successfully."
        fi
        usermod -aG $group $username
        log_message "User $username added to group $group."
    done

    # Set up home directory permissions
    chmod 700 /home/$username
    chown $username:$username /home/$username
    log_message "Permissions set for home directory of $username."

    # Generate random password and store it
    password=$(generate_password)
    echo "$username:$password" | chpasswd
    echo "$username:$password" >> $PASSWORD_FILE
    log_message "Password set for user $username."

done < "$INPUT_FILE"

log_message "User and group creation process completed."

exit 0

Detailed Explanation

Let's break down the script line by line to understand how it works.

1. Shebang and Definitions

#!/bin/bash
LOG_FILE="/var/log/user_management.log"
PASSWORD_FILE="/var/secure/user_passwords.txt"

The shebang (#!/bin/bash) indicates that the script should be executed using the Bash shell.
LOG_FILE and PASSWORD_FILE specify the paths for the log and password files.
2. Creating Log and Password Files

touch $LOG_FILE
mkdir -p /var/secure
touch $PASSWORD_FILE

touch $LOG_FILE creates the log file if it doesn't exist.
mkdir -p /var/secure creates the directory /var/secure if it doesn't exist.
touch $PASSWORD_FILE creates the password file if it doesn't exist.

3. Logging Function

log_message() {
    echo "$(date +'%Y-%m-%d %H:%M:%S') - $1" | tee -a $LOG_FILE
}

'log_message' is a function that logs messages with a timestamp to both the log file and the terminal.

4. Password Generation Function

generate_password() {
    tr -dc A-Za-z0-9 </dev/urandom | head -c 12 ; echo ''
}

This function generates a random 12-character alphanumeric password.
5. Input File Check

if [ $# -ne 1 ]; then
    echo "Usage: $0 <input_file>"
    exit 1
fi
INPUT_FILE=$1
if [ ! -f $INPUT_FILE ]; then
    echo "Input file not found!"
    exit 1
fi

The script checks if exactly one argument (the input file) is provided and if the file exists.
6. Reading the Input File

while IFS=';' read -r username groups; do
    username=$(echo $username | xargs)
    groups=$(echo $groups | xargs)

his loop reads the input file line by line, splitting each line into username and groups using ; as the delimiter.
xargs removes leading and trailing whitespaces.

7. Checking for Existing Users

    if id "$username" &>/dev/null; then
        log_message "User $username already exists. Skipping..."
        continue
    fi

This checks if the user already exists and logs a message if they do, then skips to the next iteration
8. Creating Personal Group and User

    groupadd $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create group $username."
        continue
    fi
    log_message "Group $username created successfully."
    useradd -m -g $username -s /bin/bash $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create user $username."
        continue
    fi
    log_message "User $username created successfully."

groupadd $username creates a personal group for the user.
useradd -m -g $username -s /bin/bash $username creates the user with the specified home directory and shell.
9. Adding User to Additional Groups

    IFS=',' read -ra group_array <<< "$groups"
    for group in "${group_array[@]}"; do
        group=$(echo $group | xargs)
        if [ -z "$group" ]; then
            continue
        fi
        if ! getent group $group >/dev/null; then
            groupadd $group
            if [ $? -ne 0 ]; then
                log_message "Failed to create group $group."
                continue
            fi
            log_message "Group $group created successfully."
        fi
        usermod -aG $group $username
        log_message "User $username added to group $group."
    done

This splits the groups string into an array and iterates over each group, creating the group if it doesn't exist and adding the user to it.
10. Setting Up Home Directory Permissions

    chmod 700 /home/$username
    chown $username:$username /home/$username
    log_message "Permissions set for home directory of $username."

chmod 700 /home/$username sets the permissions so that only the user can access their home directory.
chown $username:$username /home/$username sets the ownership of the home directory.
11. Generating and Storing Passwords

    password=$(generate_password)
    echo "$username:$password" | chpasswd
    echo "$username:$password" >> $PASSWORD_FILE
    log_message "Password set for user $username."

This generates a random password for the user, sets it, and securely stores it
12. Completing the Process

done < "$INPUT_FILE"
log_message "User and group creation process completed."
exit

DEV Community: Ibrahim Oyinkolade

What CBN Data Localisation Means for Nigerian DevOps Engineers

First, what exactly is data localisation?

Why should DevOps engineers care?

1. "Which AWS region are we using?" becomes a serious question

2. Your backup strategy suddenly matters even more

3. Disaster recovery becomes more complicated

4. Logs are data too

5. CI/CD pipelines also deserve attention

6. Infrastructure as Code becomes even more valuable

7. DevSecOps will become more important

Identity and access

Encryption

Secrets management

Security scanning

8. Local infrastructure doesn't automatically mean better security

9. This could change the skills Nigerian DevOps engineers need

10. Terraform + Policy as Code could become a powerful combination

11. Multi-cloud architecture may become more nuanced

12. Data classification becomes an engineering responsibility

13. The biggest opportunity may be in compliance automation

What should Nigerian DevOps engineers start learning?

Core infrastructure

Cloud

Security

Compliance

Observability

Infrastructure governance

A practical project idea

Architecture

Infrastructure

Security

CI/CD

Observability

Governance

The bigger picture

Final thought

Sources

Stop Running `terraform apply` From Your Laptop: Building Your First Terraform CI/CD Pipeline with GitHub Actions

What is Terraform CI/CD?

Why Not Run Terraform Manually?

What We'll Build

Project Structure

Understanding the CI Pipeline

Step 1: Check Formatting

Step 2: Initialize Terraform

Step 3: Validate the Configuration

Step 4: Generate an Execution Plan

Separating CI From Deployment

Managing AWS Credentials Securely

What's Next?

Final Thoughts

Building Docker Containers with Persistent Storage

Understanding Docker Storage

1. Container Writable Layer (Ephemeral Storage)

Step 1: Start a container

Observation

When is this useful?

2. Bind Mount

Create a folder

Observation

Common Use Cases

3. Docker Volumes

Create a volume

Observation

Common Use Cases

Comparison

Which One Should You Use?

Final Thoughts

Resources

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

What is a Terraform Module?

The 3-Tier Architecture We’re Deploying

📁 Project Folder Structure

🧠 What Each Terraform File Does

📦 Understanding terraform.tfstate and terraform.tfstate.backup

Final Thoughts

🔗 Full Source Code

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

What is a Terraform Module?

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`