DEV Community: MICHAEL ABAJEMITO

Jenkins Remoting: Builds on Remote Agents, Two CPU Architectures, Isolated Nodes (CodeAlpha DevOps Internship, Task 2)

MICHAEL ABAJEMITO — Mon, 09 Nov 2026 16:22:09 +0000

Last project from my CodeAlpha DevOps internship. The task was to set up Jenkins Remoting, which is how Jenkins runs builds on other machines (agents), spread the work across them, run jobs on different CPU architectures, and use node isolation for security.

Repo: github.com/mikegbenga/CodeAlpha_JenkinsRemoting

The idea

The main Jenkins server (the controller) never runs a build itself. Everything goes to agents. If a build runs on the controller, it can read everything in JENKINS_HOME, including every credential, so keeping builds off it is one of the easiest security wins.

Agent	How it connects	CPU	Network
`agent-linux-amd64`	Agent dials in over WebSocket	x86_64	`ci-inbound`
`agent-linux-arm64`	Agent dials in over WebSocket	aarch64	`ci-inbound`
`agent-ssh-secure`	Controller connects over SSH	x86_64	`ci-secure` (no internet)
`remote-vm-01`	Real machine, dials in over WebSocket	any	anywhere it can reach the controller

How Jenkins Remoting works (short version)

Remoting is the library behind the controller–agent connection. It opens a two-way channel, over WebSocket, TCP or an SSH session. Over that channel the controller sends the agent bits of work to run (sh, checkout, file operations), the agent streams the console output and files back, and the agent downloads any Java classes it needs from the controller.

The agent side is agent.jar. It has to match the controller's version, so the installer always downloads it from <JENKINS_URL>/jnlpJars/agent.jar.

For agents that dial in (inbound agents):

The node is defined on the controller, and Jenkins generates a secret for it.
The agent starts with -url, -name, -secret and -webSocket.
It connects to the controller's normal web port, and the controller checks the secret.
The node goes online. If the connection drops, the agent reconnects by itself.

The nice thing about WebSocket is that the agent only needs to reach the controller's web port. The agent machine doesn't need any open ports, so it works fine behind NAT.

Everything is configured as code

I didn't click anything in the Jenkins UI. The controller image installs the plugins, and Jenkins Configuration as Code (JCasC) sets up security, nodes and credentials when it starts. The demo jobs are created by Job DSL.

FROM jenkins/jenkins:lts-jdk17
ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false" \
    CASC_JENKINS_CONFIG=/usr/share/jenkins/casc
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/ref/plugins.txt
COPY casc/      /usr/share/jenkins/casc/
COPY pipelines/ /usr/share/jenkins/pipelines/

The important parts of casc/jenkins.yaml:

jenkins:
  numExecutors: 0          # the controller never builds
  mode: EXCLUSIVE
  remotingSecurity:
    enabled: true          # agents can't read or write controller files
  securityRealm:
    local:
      allowsSignup: false
      users:
        - id: "${JENKINS_ADMIN_ID}"
          password: "${JENKINS_ADMIN_PASSWORD}"
        - id: "${JENKINS_DEV_ID:-developer}"
          password: "${JENKINS_DEV_PASSWORD}"
  authorizationStrategy:
    globalMatrix:
      entries:
        - user:
            name: "${JENKINS_ADMIN_ID}"
            permissions: ["Overall/Administer"]
        - user:
            name: "${JENKINS_DEV_ID:-developer}"
            permissions: ["Overall/Read", "Job/Read", "Job/Build", "Job/Cancel"]

  nodes:
    - permanent:
        name: "agent-linux-arm64"
        labelString: "linux arm64 aarch64 inbound docker"
        remoteFS: "/home/jenkins/agent"
        mode: EXCLUSIVE    # only jobs that ask for these labels
        launcher:
          inbound:
            webSocket: true
    - permanent:
        name: "agent-ssh-secure"
        labelString: "linux amd64 ssh secure-zone"
        launcher:
          ssh:
            host: "agent-ssh"
            credentialsId: "agent-ssh-key"
            javaPath: "/opt/java/openjdk/bin/java"
            sshHostKeyVerificationStrategy:
              manuallyTrustedKeyVerificationStrategy:
                requireInitialManualTrust: false

And the SSH key the controller uses to start the SSH agent:

credentials:
  system:
    domainCredentials:
      - credentials:
          - basicSSHUserPrivateKey:
              scope: SYSTEM        # Jenkins can use it, pipelines can't
              id: "agent-ssh-key"
              username: "jenkins"
              privateKeySource:
                directEntry:
                  privateKey: "${readFile:/run/secrets/agent_ssh_key}"

Things I had to figure out:

The SSH agent image puts Java at /opt/java/openjdk, and an SSH session doesn't load the normal PATH. Without javaPath the agent fails with java: not found.
The inbound agent secret can't be set in advance. Jenkins generates it from the node name and the controller's key, so the setup script reads it from the controller after Jenkins starts.

Network isolation

services:
  jenkins:
    networks: [ci-inbound, ci-secure]   # only the controller is on both

  agent-amd64:
    image: jenkins/inbound-agent:latest-jdk17
    cap_drop: [ALL]
    security_opt: [no-new-privileges:true]
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 1g, pids: 512 }
    networks: [ci-inbound]

  agent-ssh:
    image: jenkins/ssh-agent:latest-jdk17
    networks: [ci-secure]

networks:
  ci-inbound:
    driver: bridge
  ci-secure:
    driver: bridge
    internal: true    # no route to the internet

Agents in different zones can't even resolve each other's names, and the secure zone has no internet access.

Running on two CPU architectures

The arm64 agent is the same image with platform: linux/arm64. On an ARM machine (Apple Silicon, Raspberry Pi, AWS Graviton) it runs natively. On an x86 machine you enable emulation once:

docker run --privileged --rm tonistiigi/binfmt --install arm64
docker compose --profile arm64 up -d agent-arm64

Emulated builds are slower (roughly 5–10×), but it's enough to show the same job running on both.

The demo jobs

Job DSL creates four pipelines in a folder:

01: Multi-architecture build

The same Java program gets compiled and run on three agents at once. Each one prints os.arch, so you can see where it actually ran. Then the results are gathered on one agent and archived.

stage('Build on every architecture') {
    parallel {
        stage('x86_64 (inbound WebSocket)') {
            agent { label 'linux && amd64 && inbound' }
            steps { buildAndRun('amd64') }
        }
        stage('arm64 (inbound WebSocket)') {
            agent { label 'linux && arm64' }
            steps { buildAndRun('arm64') }
        }
        stage('x86_64 (SSH, secure zone)') {
            agent { label 'ssh && secure-zone' }
            steps { buildAndRun('amd64-ssh') }
        }
    }
}

stash and unstash move the built files between agents. That traffic goes through the Remoting channel too.

02: Load distribution

The job splits work into N shards (6 by default). Each shard asks for any agent with the linux label, and Jenkins spreads them across whatever's free. At the end it prints a table of which node ran which shard.

for (int i = 1; i <= shards; i++) {
    def n = i
    branches["shard-${n}"] = {
        node(params.AGENT_LABEL) {
            sh "echo shard-${n} on \$NODE_NAME (\$(uname -m))"
        }
    }
}
parallel branches

03: Node isolation audit

This job runs on every agent and fails if something isn't isolated:

The build runs as non-root
The controller's /var/jenkins_home isn't visible
The controller's SSH key isn't on the agent
No effective Linux capabilities
Agents in one zone can't resolve agents in the other zone

04: Remote machine build

This runs on remote-vm-01, a real machine outside Docker. It prints the host's OS, CPU, memory and Java version.

Connecting a real remote machine

On the controller host, get the node's secret:

./scripts/fetch-agent-secrets.sh remote-vm-01

On the remote Linux machine:

sudo JENKINS_URL=http://<controller-ip>:8080 \
     AGENT_NAME=remote-vm-01 \
     AGENT_SECRET=<secret> \
     ./remote-node/install-agent.sh

The installer creates a jenkins-agent user with no login shell, downloads agent.jar from the controller, saves the secret in a file readable only by that user (-secret @file, so it never shows up in ps), and runs it as a locked-down systemd service:

[Service]
User=jenkins-agent
ExecStart=/usr/bin/java -jar /etc/jenkins-agent/agent.jar \
  -url ${JENKINS_URL} -name ${AGENT_NAME} \
  -secret @/etc/jenkins-agent/secret -workDir ${WORKDIR} -webSocket
Restart=always
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/jenkins-agent
CapabilityBoundingSet=
MemoryMax=2G

There's also install-agent.ps1 for Windows, which runs the agent as a scheduled task at startup.

Running it

./scripts/setup.sh

The setup script:

Creates an SSH key pair and a .env with random passwords
Builds and starts the controller and the SSH agent
Waits for Jenkins to be healthy, then reads the inbound agent secrets
Starts the amd64 agent, and the arm64 one if emulation is available

Then ./scripts/status.sh lists every node with its state, executors, architecture and labels.

Security summary

Control	Why
Controller has 0 executors	Builds can't read controller secrets
Agent → controller access control	A compromised agent can't touch controller files
Exclusive nodes + labels	Sensitive jobs only run in `secure-zone`
Separate networks, `ci-secure` has no internet	Zones can't reach each other
Non-root agents, `cap_drop: ALL`, resource limits	Limits damage from a bad build
Secrets from files, not the command line	Not visible in `ps` or logs
SYSTEM-scoped SSH key	Pipelines can't print it
Matrix authorization, no signup	`developer` can only read, build and cancel
Sandboxed pipeline scripts	Groovy runs under Script Security

Troubleshooting

Problem	Fix
Inbound agent: `Incorrect secret`	The controller volume was reset; run `fetch-agent-secrets.sh` again
Agent tries `tcpSlaveAgentListener`	Set `JENKINS_WEB_SOCKET=true`
`Unknown launcher inbound`	Older Jenkins; rename `inbound:` to `jnlp:`
SSH agent: `Host key verification failed`	The container was recreated; trust the new host key
arm64: `exec format error`	Install binfmt (command above)
Job stuck "waiting for executor"	No online agent has that label; check `status.sh`

What I learned

Keeping builds off the controller is easy and makes a big difference.
WebSocket agents make connecting remote machines simple, even behind NAT.
Labels are what make spreading the load practical.
Having the whole setup in code means I can tear it down and rebuild it in a few minutes.

That's the end of this series. Thanks for reading, and thanks to CodeAlpha for the internship.

Running a Web Server in Docker the Right Way (CodeAlpha DevOps Internship, Task 4)

MICHAEL ABAJEMITO — Mon, 09 Nov 2026 16:22:02 +0000

Second project from my CodeAlpha DevOps internship. The task was to deploy and manage a web server inside Docker, learn the container lifecycle, and monitor the container's health.

Getting NGINX running in Docker is one command. So I tried to set it up the way you'd want it in production: not running as root, locked down, with a proper health check, and able to recover on its own if it crashes.

Repo: github.com/mikegbenga/CodeAlpha_DockerWebServer

What I built

An NGINX container based on nginx-unprivileged, running as user 101
A /healthz endpoint that Docker checks every 15 seconds
A read-only filesystem, no Linux capabilities, and CPU and memory limits
manage.sh, a script for the whole container lifecycle, with tests and a crash test
Optional monitoring with the NGINX Prometheus exporter and Prometheus
GitHub Actions that lint, build, run, test and scan the image on every push

This is the page it serves. The status line at the bottom calls /healthz from the browser and shows the request ID that NGINX adds to every response.

The Dockerfile

FROM nginxinc/nginx-unprivileged:1.27-alpine

USER 0
RUN rm -f /etc/nginx/conf.d/default.conf
COPY --chown=nginx:nginx nginx/nginx.conf      /etc/nginx/nginx.conf
COPY --chown=nginx:nginx nginx/conf.d/         /etc/nginx/conf.d/
COPY --chown=nginx:nginx site/                 /usr/share/nginx/html/
RUN nginx -t
USER 101

EXPOSE 8080
STOPSIGNAL SIGQUIT

HEALTHCHECK --interval=15s --timeout=3s --start-period=5s --retries=3 \
  CMD ["wget", "-q", "--spider", "http://127.0.0.1:8080/healthz"]

CMD ["nginx", "-g", "daemon off;"]

What each part is for:

nginx-unprivileged listens on 8080 and runs as a normal user. A non-root user can't bind to ports below 1024, which is why it's 8080 and not 80.
RUN nginx -t checks the config during the build. A typo fails the build instead of the deploy. This saved me more than once.
STOPSIGNAL SIGQUIT makes docker stop shut NGINX down gracefully, so requests in progress get to finish.
HEALTHCHECK is what makes docker ps show (healthy) or (unhealthy) instead of just "Up".

Running it safely (docker-compose.yml)

services:
  web:
    build: .
    image: codealpha/webserver:latest
    ports:
      - "8080:8080"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://127.0.0.1:8080/healthz"]
      interval: 15s
      timeout: 3s
      retries: 3
    read_only: true
    tmpfs:
      - /tmp:size=16m
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    deploy:
      resources:
        limits:
          cpus: "0.50"
          memory: 128M
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

read_only: true: nothing in the container can be changed, even if someone gets in.
tmpfs: /tmp: NGINX still needs somewhere to write temp files, so I pointed all its temp paths at /tmp in nginx.conf.
cap_drop: [ALL] and no-new-privileges: the process gets no special Linux permissions and can't gain any.
deploy.resources.limits: one container can't eat the whole server.
Log rotation, so docker logs can't fill the disk.

The NGINX config

Main settings in nginx.conf:

pid /tmp/nginx.pid;
client_body_temp_path /tmp/client_temp;
proxy_temp_path       /tmp/proxy_temp;

log_format json escape=json '{"time":"$time_iso8601","request_id":"$request_id",'
                            '"method":"$request_method","uri":"$request_uri",'
                            '"status":$status,"request_time":$request_time}';
access_log /dev/stdout json if=$loggable;   # health checks are not logged

server_tokens off;
gzip on;
limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;

And the server block in conf.d/site.conf:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options        "DENY" always;
add_header X-Request-ID           $request_id always;

location = /healthz {
    access_log off;
    default_type application/json;
    return 200 '{"status":"ok","server":"nginx"}';
}

location = /nginx_status {
    stub_status;
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    allow 192.168.0.0/16;
    deny  all;
}

location ~ /\. { deny all; return 404; }   # .git, .env and other hidden files

There's also a custom 404 page:

One thing that tripped me up: I originally had listen [::]:8080; as well. On a machine with IPv6 turned off, NGINX refused to start with Address family not supported by protocol. I removed that line.

Another one: in NGINX, if a location block has its own add_header, it replaces the headers from the server block instead of adding to them. So the security headers have to be repeated in those locations.

Checking it works

I ran the config on a real NGINX and checked it with curl:

The lifecycle script

scripts/manage.sh wraps the Docker commands so the whole lifecycle is one script:

./scripts/manage.sh build       # build the image
./scripts/manage.sh run         # docker run with all the hardening flags, then wait until healthy
./scripts/manage.sh status      # status, restart count, OOMKilled, exit code
./scripts/manage.sh health      # health state + last 5 probe results
./scripts/manage.sh logs        # follow logs
./scripts/manage.sh stats       # CPU and memory against the limits
./scripts/manage.sh stop        # graceful stop
./scripts/manage.sh test        # 8 functional + security checks
./scripts/manage.sh crash-test  # kill the server and check it comes back
./scripts/manage.sh clean       # remove container and image

The test command checks the pages, the health endpoint, the 404 page, that .env is blocked, the security headers, that the root filesystem is read-only, and that it's not running as root.

The crash test

This was the most interesting part for me. My first idea was docker exec … kill -9 1. It didn't work, because PID 1 inside a container ignores SIGKILL sent from inside its own namespace. Asking NGINX itself to stop works:

docker exec codealpha-web nginx -s stop

The container exits, the unless-stopped restart policy starts it again, and the restart count goes up. Then the script waits until it's healthy again.

One more thing worth knowing: Docker on its own does not restart a container just because it's unhealthy. It only restarts containers that exit. That's why there's also scripts/health-monitor.sh, which restarts the container after 3 failed checks in a row. Swarm or Kubernetes would do this for you.

Container lifecycle cheat sheet

Stage	Command	What happens
Build	`docker build -t codealpha/webserver .`	Layers are cached; `nginx -t` runs
Run	`docker run -d --name codealpha-web -p 8080:8080 …`	Created and started
Health	`docker inspect -f '{{.State.Health.Status}}' codealpha-web`	`starting` → `healthy` / `unhealthy`
Pause	`docker pause` / `docker unpause`	Processes frozen, port still bound
Stop	`docker stop -t 10 codealpha-web`	`SIGQUIT`, then `SIGKILL` after 10 s
Restart	`docker restart codealpha-web`	Stop + start
Remove	`docker rm -f codealpha-web`	Container gone; the image stays

Monitoring

docker compose --profile monitoring up -d --build

This also starts the nginx-prometheus-exporter, which reads /nginx_status, and Prometheus on port 9090. Prometheus has two alert rules: NginxDown and too many active connections.

CI with GitHub Actions

Every push runs .github/workflows/docker-ci.yml:

To be honest, the first two runs failed:

I'd pinned aquasecurity/trivy-action@0.28.0, which doesn't exist. The releases use a v prefix, so v0.36.0 works.
ShellCheck complained about A && B || C (SC2015), because if B fails, C runs even though A succeeded. I changed those lines to proper if/else.

Third run passed in 1 minute 9 seconds.

Troubleshooting

Problem	Likely cause	Fix
`port is already allocated`	Something else is on 8080	`HOST_PORT=8081 ./scripts/manage.sh run`
`Read-only file system` error	A temp path isn't on the tmpfs	Keep the `*_temp_path /tmp/...` lines
`bind() to 0.0.0.0:80 failed (13: Permission denied)`	Non-root can't use port 80	Listen on 8080, map `-p 80:8080`
Stuck on `starting`	The probe can't reach `/healthz`	`docker exec codealpha-web wget -qO- http://127.0.0.1:8080/healthz`
`OOMKilled: true`	Hit the memory limit	Raise the limit

What I learned

A health check tells you a lot more than "the container is running".
Most of the hardening is just a few lines of config.
Checking the config during the build catches mistakes early.
You don't really know self-healing works until you crash it on purpose.

Next in the series: Jenkins Remoting, running builds on other machines.

Thanks to CodeAlpha for the internship.

Building a CI/CD Pipeline on Azure (CodeAlpha DevOps Internship, Task 1)

MICHAEL ABAJEMITO — Mon, 09 Nov 2026 16:21:17 +0000

This is the first project from my DevOps internship at CodeAlpha. The task was to build a CI/CD pipeline with Azure tools: Azure Pipelines for the automation, Azure Container Registry (ACR) to store the images, and Azure App Service to run the app.

I'm writing this down partly so I remember how I did it, and partly in case it helps someone else doing the same thing.

Repo: github.com/mikegbenga/CodeAlpha_AzureCICD

What the pipeline does

Every time I push to main:

The tests run.
The app gets built into a Docker image.
The image is pushed to Azure Container Registry, tagged with the build number.
App Service is updated to run that exact image.
A smoke test calls the live /health endpoint until it reports the new build number.
If that never happens, the pipeline puts the previous image back.

Pull requests only run the tests and the build. Nothing gets pushed or deployed from a PR.

The app

I kept the app small on purpose, because the pipeline is the point here. It's a Node.js server with no dependencies and three routes:

Route	What it returns
`/`	A page that shows which build is running
`/health`	`{"status":"healthy","version":"…"}`, used by App Service and the smoke test
`/api/info`	Build number, environment, hostname, uptime

This is it running on my machine. Locally the version shows dev and the build ID shows local. In Azure those get filled in by the pipeline.

It also logs every request as one line of JSON, which makes the logs easy to search later in Log Analytics:

{"t":"2026-11-09T16:13:19.119Z","method":"GET","path":"/health","status":200,"ms":0.41}

Tests

There are six tests using Node's built-in test runner, so there's nothing to install. They check the health endpoint, the API, the security headers, a 404, that path traversal is blocked, and that POST is rejected.

In the pipeline they run with a JUnit reporter so the results show up in the Tests tab in Azure DevOps:

"test:ci": "node --test --test-reporter=spec --test-reporter-destination=stdout --test-reporter=junit --test-reporter-destination=test-results.xml test/*.test.js"

The Dockerfile

Two stages. The first one runs the tests, so a broken commit can't even produce an image. The second one is the small image that actually runs.

FROM node:22-alpine AS test
WORKDIR /src
COPY app/package.json ./
COPY app/src ./src
COPY app/public ./public
COPY app/test ./test
RUN npm test

FROM node:22-alpine AS runtime
ARG APP_VERSION=dev
ARG BUILD_ID=local
ENV NODE_ENV=production PORT=3000 APP_VERSION=${APP_VERSION} BUILD_ID=${BUILD_ID}
WORKDIR /app
COPY --chown=node:node app/package.json ./
COPY --chown=node:node app/src ./src
COPY --chown=node:node app/public ./public
USER 1000
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD ["wget", "-q", "--spider", "http://127.0.0.1:3000/health"]
CMD ["node", "src/server.js"]

A couple of things I learned here:

USER 1000 means the app doesn't run as root inside the container.
The build number gets passed in as a build arg, so every image knows which build it came from. That's what makes the smoke test possible later.

The pipeline (`azure-pipelines.yml`)

It's one YAML file with three stages.

Stage 1: CI

- stage: CI
  jobs:
  - job: Test
    steps:
    - task: UseNode@1
      inputs:
        version: '22.x'
    - script: npm run test:ci
      workingDirectory: app
    - task: PublishTestResults@2
      condition: succeededOrFailed()
      inputs:
        testResultsFormat: 'JUnit'
        testResultsFiles: 'app/test-results.xml'
        failTaskOnFailedTests: true

Stage 2: Build and push to ACR

The image gets two tags: the build ID (which never changes) and latest. Before pushing, the pipeline starts the container on the build agent and checks /health once, just to make sure it actually starts.

- task: Docker@2
  displayName: 'Build image'
  inputs:
    command: build
    repository: $(imageRepository)
    containerRegistry: $(dockerRegistryServiceConnection)
    tags: |
      $(imageTag)
      latest
    arguments: >-
      --build-arg APP_VERSION=1.0.$(Build.BuildId)
      --build-arg BUILD_ID=$(Build.BuildId)

- task: Docker@2
  displayName: 'Push image to ACR'
  condition: and(succeeded(), eq(variables.isMain, true))
  inputs:
    command: push
    repository: $(imageRepository)
    containerRegistry: $(dockerRegistryServiceConnection)
    tags: |
      $(imageTag)
      latest

Stage 3: Deploy, check, roll back

This was the part that took me the longest to get right. Before deploying, the pipeline saves which image is currently live. Then it deploys the new one and keeps calling /health until the version matches this build.

- task: AzureWebAppContainer@1
  inputs:
    azureSubscription: $(azureSubscription)
    appName: $(webAppName)
    containers: '$(acrLoginServer)/$(imageRepository):$(imageTag)'

- script: |
    URL="https://$(webAppName).azurewebsites.net/health"
    for i in $(seq 1 30); do
      BODY=$(curl -fsS "$URL" || true)
      if echo "$BODY" | grep -q '"version":"1.0.$(Build.BuildId)"'; then
        echo "Deployment verified"; exit 0
      fi
      sleep 10
    done
    exit 1
  displayName: 'Post-deploy smoke test'

- task: AzureCLI@2
  displayName: 'Roll back to previous image'
  condition: and(failed(), ne(variables.previousImage, ''))
  inputs:
    azureSubscription: $(azureSubscription)
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      az webapp config container set -g $(resourceGroup) -n $(webAppName) \
        --container-image-name "$(previousImage)"
      az webapp restart -g $(resourceGroup) -n $(webAppName)

At first I put the rollback in an on: failure: hook, but variables set during the deploy job weren't available there. Moving it into the same job with condition: failed() fixed that.

To test the rollback without actually breaking the app, there's a checkbox when you run the pipeline manually:

parameters:
- name: simulateFailure
  displayName: 'Simulate a failed release (demo the automatic rollback)'
  type: boolean
  default: false

When it's ticked, the smoke test fails on purpose and you can watch the rollback step run.

The infrastructure (Terraform)

Everything in Azure is created by Terraform in infra/terraform/:

Resource group
Container registry (Basic, admin account turned off)
App Service plan (Linux, B1) and the Web App
Log Analytics and Application Insights
Alerts for HTTP 5xx errors and failed health checks, sent to my email

The bit I like most is that the Web App pulls images using a managed identity with the AcrPull role. So no registry password is stored anywhere.

resource "azurerm_linux_web_app" "app" {
  https_only = true
  identity {
    type = "SystemAssigned"
  }
  site_config {
    container_registry_use_managed_identity = true
    health_check_path                       = "/health"
    minimum_tls_version                     = "1.2"
  }
}

resource "azurerm_role_assignment" "acr_pull" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_linux_web_app.app.identity[0].principal_id
}

If you'd rather not use Terraform, there's also scripts/bootstrap-azure.sh, which creates the same things with the Azure CLI.

How to set it up yourself

The full steps are in docs/SETUP.md. The short version:

Create the Azure resources

   az login
   cd infra/terraform
   cp terraform.tfvars.example terraform.tfvars   # add your subscription ID and email
   terraform init && terraform apply

In Azure DevOps, create two service connections
- sc-acr-codealpha: Docker Registry → Azure Container Registry
- sc-azure-codealpha: Azure Resource Manager (workload identity federation)
Create an environment called codealpha-production. You can add an approval step here if you want a manual gate.
Create the pipeline from the existing azure-pipelines.yml in the repo.
Push to main and watch the three stages run.

Heads up: new Azure DevOps organisations don't get free hosted build agents straight away. You have to request them, and approval can take a few days. Request it on day one.

Monitoring

Pipeline: each run shows the stage timings, the Tests tab shows the JUnit results, and the codealpha-production environment keeps the deployment history.
App: Application Insights for requests and failures, and Log Analytics for the JSON request logs.
Alerts: an email if there are more than 5 server errors in 5 minutes, or if the health check drops.

There's also a small script, scripts/monitor-pipeline.sh, that shows the last pipeline runs, the live health, the running image and the log tail in one place.

Problems I hit

Problem	Fix
`node --test test/` didn't find the tests on Node 22	Pass the files directly: `test/*.test.js`
Rollback step couldn't see `previousImage`	Move it into the deploy job with `condition: failed()` instead of an `on: failure` hook
App shows 503 after deploy	`WEBSITES_PORT` has to be `3000`
Image pull fails in App Service	The `AcrPull` role is missing, or `acrUseManagedIdentityCreds` is off

What I learned

Automating every step makes releases a lot less stressful.
Tagging images with the build number means I always know what's running.
A health check straight after deploying is what makes an automatic rollback possible.
Managed identity is nicer than copying registry passwords around.

Next up in this series: running a web server in Docker the proper way.

Thanks to CodeAlpha for the internship.

Cloud Engineering for Beginners: A Friendly, Plain-English Guide

MICHAEL ABAJEMITO — Mon, 09 Nov 2026 16:00:42 +0000

Let's start with a confession

When I first heard people talk about "the cloud", I pictured something floating in the sky, holding everybody's photos and emails. It sounded mysterious, a bit magical, and honestly a little intimidating. People threw around words like EC2, Kubernetes, VPC and serverless as if everyone was born knowing them.

Here is the good news: the cloud is not magic, and you do not need to be a genius to understand it. Underneath all the jargon is a simple idea that you already understand from everyday life. By the end of this guide you should be able to explain the cloud to a friend over a cup of tea, know what a cloud engineer actually does all day, and have a clear, realistic path for getting started yourself.

No prior experience is assumed. If a word sounds technical, I will explain it. Grab a drink, get comfortable, and let's walk through it together.

1. What is "the cloud", really?

Here is the simplest honest definition you will ever hear:

The cloud is simply other people's computers, which you rent over the internet and pay for only while you use them.

That's it. Somewhere in the world there are huge buildings called data centres, filled with thousands of powerful computers (we call them servers), stacked in rows of metal cabinets, cooled by giant air-conditioning systems and protected by guards, fences and cameras. Companies like Amazon, Microsoft and Google own these buildings. Instead of buying your own servers, you rent a slice of theirs.

The electricity analogy

Think about electricity. A hundred years ago, many factories generated their own power with their own generators. They had to buy the machines, hire people to maintain them, buy fuel, and deal with breakdowns. Today, almost nobody does that. You plug into the national grid, use what you need, and pay a bill at the end of the month.

The cloud does the same thing for computing. Before the cloud, every company had to buy and run its own servers. Now they can "plug in" to a cloud provider and pay for exactly what they use, just like electricity or water.

Life before the cloud: the server room story

Imagine you run a growing online shop in 2008. To put your website online, you would have to:

Buy physical servers (very expensive, paid upfront).
Find a cool, secure room to keep them, with backup power in case of an outage.
Wait weeks for the hardware to be delivered and set up.
Guess how much traffic you will get. Buy too little, and your site crashes on a busy day. Buy too much, and expensive machines sit idle most of the year.
Hire people to replace broken disks, apply updates and fix things at 2 a.m.

Now imagine the same shop today. You open a website, click a few buttons (or run a short script), and within minutes you have a server running in a data centre in another country. When a big sale brings ten times the usual visitors, the cloud can add more servers automatically. When the rush is over, it removes them, and you stop paying for them. That shift, from owning to renting on demand, is the heart of the cloud revolution.

Remember this: the cloud gives you computing power the way a tap gives you water. Turn it on when you need it, turn it off when you don't, and pay for what flowed through.

2. So what is cloud engineering?

If the cloud is a giant rental warehouse of computers, then cloud engineering is the skill of designing, building, running and looking after systems inside that warehouse, so that applications are reliable, secure, fast and affordable.

A cloud engineer is a bit like a combination of an architect, a builder and a building manager:

As an architect, they plan how an application should be laid out in the cloud: which services to use, how they connect, and how to keep everything safe.
As a builder, they actually set things up: servers, networks, databases, storage and permissions, usually using code rather than clicking around.
As a building manager, they keep everything running: watching for problems, fixing issues, applying updates, controlling costs and planning for growth.

A day in the life of a cloud engineer

No two days are the same, but a typical day might look like this:

Time	What they might be doing
Morning	Check the monitoring dashboards. Did anything break overnight? Are any servers struggling? Is the monthly bill growing faster than expected?
Mid-morning	Join a short team meeting with developers to plan a new feature that needs a database and file storage.
Late morning	Write code (for example, Terraform) that creates the new database and storage, and submit it for review.
Afternoon	Improve the automated pipeline that tests and deploys the developers' code to the cloud every time they make a change.
Late afternoon	Investigate why one service is slow, find a misconfigured setting, fix it, and write a short note so the team learns from it.
Occasionally	Respond to an alert at an awkward hour when something important goes down. (Good engineers work hard to make these rare.)

Notice something? Very little of this is about touching physical hardware. Cloud engineering is mostly about thinking clearly, writing configuration and code, automating repetitive work, and solving problems.

Related job titles you will hear

The cloud world has many overlapping titles. Don't let them confuse you; they share much of the same foundation.

Title	In simple words
Cloud Engineer	Builds and runs systems in the cloud. A great general starting point.
Cloud Architect	Designs the big picture: how all the pieces fit together. Usually a more senior role.
DevOps Engineer	Focuses on automating how software is built, tested and released, often in the cloud.
Site Reliability Engineer (SRE)	Focuses on keeping services up, fast and reliable, using software engineering skills.
Cloud Security Engineer	Focuses on protecting cloud systems and data from attacks and mistakes.
Platform Engineer	Builds internal tools and "paved roads" so developers can use the cloud easily and safely.

3. Meet the cloud providers

A cloud provider is a company that owns the data centres and rents out computing services. Three names dominate the global market:

Amazon Web Services (AWS): the pioneer, launched in 2006, with an enormous catalogue of services.
Microsoft Azure: very popular with businesses that already use Microsoft products such as Windows Server, Office 365 and Active Directory.
Google Cloud Platform (GCP): known for strengths in data, analytics, machine learning and Kubernetes (which Google originally created).

There are many others too, including Oracle Cloud, IBM Cloud, Alibaba Cloud, DigitalOcean and Linode (now Akamai), as well as regional providers in different countries.

Beginner's tip: don't try to learn all of them at once. Pick one, learn it well, and you will find the others surprisingly familiar. The names differ, but the ideas are the same. A virtual server is called EC2 on AWS, a Virtual Machine on Azure, and Compute Engine on Google Cloud, but it is the same idea in each.

4. The three ways to use the cloud: IaaS, PaaS and SaaS

You will constantly hear the terms IaaS, PaaS and SaaS. They simply describe how much of the work you do yourself versus how much the provider does for you. The classic way to explain them is with pizza.

The pizza analogy

Option	Pizza version	Cloud version	Who does what
On-premises (no cloud)	You make pizza at home: buy flour, make dough, own the oven, cook, serve.	You own the servers, the building, the network and everything on top.	You do everything.
IaaS: Infrastructure as a Service	You rent a kitchen with an oven. You bring ingredients and cook.	You rent virtual servers, storage and networks. You install and manage the operating system and apps.	Provider: hardware. You: almost everything else.
PaaS: Platform as a Service	You order a take-and-bake pizza. It is prepared for you; you just bake and serve.	You upload your code; the provider runs the servers, operating system and scaling.	Provider: platform. You: your code and data.
SaaS: Software as a Service	You order a delivered pizza. Just eat.	You simply use finished software through a browser, like Gmail, Microsoft 365 or Zoom.	Provider: everything. You: just use it.

Real examples help:

IaaS: AWS EC2, Azure Virtual Machines, Google Compute Engine.
PaaS: Azure App Service, AWS Elastic Beanstalk, Google App Engine, Heroku.
SaaS: Gmail, Microsoft 365, Salesforce, Dropbox, Zoom.

As a cloud engineer, you will mostly work with IaaS and PaaS, and increasingly with serverless services, where you don't think about servers at all. You upload a small piece of code (a "function"), and it runs only when something triggers it, such as a file upload or a web request. You pay per run. AWS Lambda, Azure Functions and Google Cloud Functions are popular examples.

5. Where does your cloud live? Public, private, hybrid and multi-cloud

Public cloud: you share the provider's huge infrastructure with other customers (safely separated). This is what most people mean by "the cloud".
Private cloud: cloud-style technology used by a single organisation, often in its own data centre. Banks and governments sometimes choose this for strict control.
Hybrid cloud: a mix of private (or on-premises) and public cloud working together. For example, a bank keeps its core records in-house but runs its mobile app in the public cloud.
Multi-cloud: using more than one public provider, such as AWS for some workloads and Azure for others.

Think of it like housing: public cloud is renting an apartment in a big, well-managed building; private cloud is owning your own house; hybrid is living in your house but renting a storage unit across town.

6. The building blocks: the five things almost every system needs

No matter how complicated a cloud system looks, it is built from a handful of basic building blocks. If you understand these five, you understand most of the cloud.

Building block 1: Compute (the brains)

Compute is processing power, the part that actually runs your programs. In the cloud, compute comes in a few flavours:

Virtual machines (VMs): a full computer created in software, with its own operating system. You choose how much CPU and memory it has. Think of it as renting a whole flat.
Containers: lightweight packages that hold an application and everything it needs to run, so it behaves the same everywhere. Think of shipping containers: the same box fits on any ship, train or truck. Docker is the most popular tool for creating them.
Serverless functions: tiny pieces of code that run on demand. Think of calling a taxi only when you need a ride, rather than owning a car.

Building block 2: Storage (the memory and filing cabinets)

Object storage (like AWS S3 or Azure Blob Storage): perfect for files such as images, videos, backups and documents. Imagine an endless, extremely durable warehouse of labelled boxes.
Block storage: virtual hard drives attached to your virtual machines.
File storage: shared folders that several machines can use at the same time, like a shared office drive.

Building block 3: Databases (the organised records)

Most applications need to remember things: users, orders, payments, messages. Databases store this information in an organised way.

Relational (SQL) databases, such as MySQL, PostgreSQL and Microsoft SQL Server, store data in tables with rows and columns, like a very powerful spreadsheet.
NoSQL databases, such as MongoDB, DynamoDB and Cosmos DB, are more flexible and are often used for very large or fast-changing data.

The cloud offers these as managed databases: the provider handles backups, updates and hardware, while you focus on your data. That alone saves teams countless hours.

Building block 4: Networking (the roads and gates)

Networking connects everything together and to the internet, while keeping out what shouldn't get in. A few key ideas:

Virtual network (VPC or VNet): your own private, fenced-off area inside the cloud. Think of it as a gated estate.
Subnets: smaller sections inside that estate. Public subnets face the internet (like the reception area); private subnets are hidden (like the back office).
Firewalls and security groups: the security guards at each gate, deciding who may come in and on which door.
Load balancer: a friendly receptionist who spreads incoming visitors evenly across several servers, so no single one is overwhelmed.
DNS: the internet's phonebook, turning names like example.com into the numeric addresses computers use.
CDN (Content Delivery Network): copies of your files stored in many cities around the world, so users download from somewhere close to them, which is much faster.

Building block 5: Identity and security (the keys)

Identity and Access Management (IAM) decides who can do what. Every person and every application gets an identity, and each identity is given only the permissions it truly needs. This is called the principle of least privilege: give the cleaner a key to the corridor, not to the safe.

Put the five together: a typical web application has users who reach it through DNS and a load balancer (networking), which sends them to servers or containers (compute) that read and write data in a database, store files in object storage, and all of it is protected by IAM and firewalls (security). That one sentence describes thousands of real systems.

7. The big ideas that make the cloud special

Beyond the building blocks, a few concepts explain why companies love the cloud. You will hear these words in every interview and meeting.

Scalability and elasticity

Scalability means your system can grow to handle more work. Elasticity means it can grow and shrink automatically as demand changes. Picture a restaurant that magically adds tables when a crowd arrives and removes them when it's quiet, and only pays rent for the tables in use.

Scaling up (vertical): making one server bigger, like swapping a small car for a bus.
Scaling out (horizontal): adding more servers, like adding more cars to the fleet. In the cloud, scaling out is usually preferred because there is no single point of failure.

Pay-as-you-go

Instead of a huge upfront purchase (what accountants call CapEx), you pay a running bill for what you use (OpEx). A startup can launch with very little money, and a large company can experiment without buying hardware it may never need.

Regions and availability zones

Cloud providers have data centres spread across the world. A region is a geographic area, such as "West Europe" or "South Africa North". Inside each region are several availability zones: separate data centres with their own power and cooling, a few kilometres apart.

Why does this matter? If you run your application in two or three zones and one has a power failure, the others keep serving your users. It's the cloud version of not putting all your eggs in one basket. You also choose regions close to your users (for speed) or in specific countries (for legal reasons about where data may be stored).

High availability and disaster recovery

High availability means designing systems so they keep running even when parts fail. Assume things will break, and plan for it.
Disaster recovery means having a plan, and tested backups, to recover if something big goes wrong, such as a whole region going down or data being deleted by accident.

The shared responsibility model

This is one of the most important, and most misunderstood, ideas in cloud security. The provider and the customer share the job of keeping things safe:

The provider is responsible for…	You (the customer) are responsible for…
Security OF the cloud: physical buildings, guards, hardware, power, the global network and the core software that runs the cloud.	Security IN the cloud: your data, your user accounts and passwords, who has access, your firewall rules, your application code, and patching your own virtual machines.

In plain words: the landlord secures the building, but you still have to lock your own front door. Many real-world cloud data leaks happen not because the provider was hacked, but because a customer left a storage bucket open to the public or used a weak password.

8. How modern cloud engineers actually work

Ten years ago, many people set up cloud resources by clicking around in a web console. That still works for learning, but professional teams have moved on to methods that are faster, safer and repeatable.

Infrastructure as Code (IaC)

Instead of clicking buttons, you describe your infrastructure in text files, and a tool builds it for you. It's like the difference between giving a builder verbal instructions and giving them a precise blueprint. With a blueprint you can:

Build the exact same setup again and again (for testing, staging and production).
Keep a history of every change in Git, so you know who changed what and why, and can undo mistakes.
Review changes before they happen, just like developers review code.

Popular tools include Terraform (works with almost every provider), AWS CloudFormation, Azure Bicep, Pulumi, and Ansible (great for configuring servers after they are created). Here is a tiny taste of what Terraform looks like. Even without experience, you can probably guess what it does:

resource "azurerm_resource_group" "shop" {
  name     = "online-shop-rg"
  location = "West Europe"
}

That short block says: "create a container for my resources called online-shop-rg in the West Europe region." Readable, repeatable, reviewable.

DevOps and CI/CD

DevOps is a culture and set of practices that brings software developers (Dev) and operations teams (Ops) together, so software can be released quickly and reliably. A key tool of DevOps is the CI/CD pipeline:

Continuous Integration (CI): every time a developer saves a change, it is automatically built and tested.
Continuous Delivery or Deployment (CD): if the tests pass, the change is automatically packaged and released to the cloud.

Think of it as a factory conveyor belt with quality checks at each station. Tools include GitHub Actions, Azure DevOps, GitLab CI and Jenkins.

Containers and Kubernetes

Once you have lots of containers, you need something to organise them: start them, restart them if they crash, spread them across servers and add more when traffic grows. That "orchestra conductor" is called Kubernetes (often shortened to K8s). Every major cloud offers a managed version: Amazon EKS, Azure AKS and Google GKE.

Don't rush into Kubernetes. It is powerful but complex. Learn Linux, networking, one cloud and Docker first. Kubernetes will make far more sense once those foundations are solid.

Monitoring and observability

You can't fix what you can't see. Cloud engineers use monitoring tools to watch the health of systems: CPU usage, error rates, response times and costs. They set alerts that send a message when something looks wrong, and they collect logs (detailed diaries of what applications are doing) to investigate problems. Examples include Amazon CloudWatch, Azure Monitor, Google Cloud Monitoring, Prometheus and Grafana.

9. Cloud security in plain English

Security is not a separate topic you learn "later"; it's part of everything you build. Here are the habits that prevent the vast majority of beginner disasters:

Turn on multi-factor authentication (MFA) for every account, especially the main "root" or administrator account. Then stop using the root account for daily work.
Never put passwords or secret keys in your code or upload them to GitHub. Use a secrets manager such as AWS Secrets Manager, Azure Key Vault or Google Secret Manager. Bots scan public code for leaked keys within minutes.
Follow least privilege. Give people and applications only the permissions they need, nothing more.
Keep storage private by default. Only make something public if you truly mean to.
Encrypt data, both while it is stored (at rest) and while it travels (in transit, using HTTPS).
Patch and update your virtual machines and software regularly.
Back up important data, and occasionally test that you can actually restore it. An untested backup is just a hope.

10. Let's talk about money (before the cloud talks to you)

Almost every beginner has a story about a surprise cloud bill. Pay-as-you-go is wonderful, but it also means things you forget to switch off keep costing money. Protect yourself from day one:

Set up a budget alert immediately after creating your account, so you get an email if spending passes a small amount you choose.
Use the free tier wisely. All major providers offer free credits or always-free services for learning, but read the limits carefully.
Delete what you're not using. When you finish a lab or tutorial, clean up every resource you created. Infrastructure as Code makes this easy: one command destroys everything you built.
Stop or shut down test virtual machines when you're not using them.
Watch out for the sneaky costs: data leaving the cloud (egress), forgotten disks and IP addresses, and large database instances.

In companies, managing cloud spending has become its own discipline, often called FinOps. Engineers who can save money are highly valued.

11. Your first cloud project: a gentle walkthrough

Reading is good, but doing is where understanding really clicks. Here is a beginner-friendly progression of projects. Each builds on the last.

Project 1: Host a personal website (the "hello, cloud" moment)

Create a free-tier account with one provider and set up a budget alert.
Write a simple HTML page about yourself.
Upload it to object storage (for example, an S3 bucket or Azure Storage account) and switch on static website hosting.
Open the web address the cloud gives you. Your page is now live on the internet, served from a data centre.

You just used storage, networking and permissions, three of the five building blocks.

Project 2: Launch and connect to a virtual machine

Create a small Linux virtual machine.
Configure its firewall (security group) to allow only SSH from your own IP address, plus web traffic on port 80.
Connect to it securely using SSH, install a web server like Nginx, and serve your page from it.
Shut it down (or delete it) when you're done.

Project 3: Rebuild Project 2 with code

Now repeat Project 2 using Terraform. Then destroy everything with a single command and recreate it in seconds. This is the moment many people truly understand why Infrastructure as Code matters.

Project 4: Containerise and automate

Package a small web app in a Docker container.
Store your code on GitHub.
Create a GitHub Actions pipeline that builds the container and deploys it to the cloud every time you push a change.

Congratulations: you have now touched compute, storage, networking, security, Infrastructure as Code, containers and CI/CD. Put these projects on GitHub with a clear README. They become your portfolio, which is often more convincing to employers than any certificate.

12. A realistic learning roadmap

You don't need a computer science degree to become a cloud engineer, but you do need solid foundations. Here's a sensible order. Timelines vary from person to person; consistency matters more than speed.

Stage	What to learn	Why it matters
1. Foundations	How computers and the internet work; Linux command line basics; networking basics (IP addresses, ports, DNS, HTTP/HTTPS, firewalls).	Most cloud servers run Linux, and nearly every cloud problem is secretly a networking problem.
2. One cloud provider	Pick AWS, Azure or GCP. Learn compute, storage, networking, databases, IAM, monitoring and billing.	This is your home base. Depth in one beats shallow knowledge of three.
3. Scripting	Python or Bash; enough to automate tasks and read code comfortably.	Automation is the superpower of cloud engineers.
4. Git and GitHub	Saving versions, branching and pull requests.	Everything modern, including infrastructure, lives in Git.
5. Infrastructure as Code	Terraform first, plus the basics of Ansible.	This is how professionals build real cloud environments.
6. Containers	Docker, then the fundamentals of Kubernetes.	Most modern applications ship in containers.
7. CI/CD and DevOps	GitHub Actions, Azure DevOps or Jenkins pipelines.	Shipping software safely and quickly is the end goal.
8. Security and cost	IAM in depth, secrets management, encryption, budgets and FinOps habits.	These separate trusted engineers from risky ones.
9. Monitoring	Logs, metrics, alerts and dashboards.	Running systems well is as important as building them.

Certifications: helpful, but not magic

Certifications give structure to your learning and help your CV get noticed. Good beginner starting points are the entry-level "fundamentals" exams from each provider, such as AWS Certified Cloud Practitioner, Microsoft Azure Fundamentals (AZ-900) and Google Cloud Digital Leader. After that, associate-level exams such as AWS Solutions Architect Associate or Azure Administrator (AZ-104) are widely respected. Exam names and versions change from time to time, so always check the provider's official certification page before you book.

One honest word of advice: a certificate shows you studied; a project shows you can do the work. Aim for both.

Soft skills nobody tells you about

Curiosity: the cloud changes constantly. Enjoying learning is a genuine advantage.
Clear communication: explaining technical trade-offs in simple words to managers and clients is a rare and valuable skill.
Documentation: writing things down saves your team (and your future self) hours of confusion.
Calm problem-solving: when systems break, the engineer who stays calm, reads the logs and works step by step is the hero.
Thinking about the business: the best cloud engineers ask, "What does this cost, and what value does it bring?"

13. Common beginner mistakes (so you can skip them)

Trying to learn everything at once. Three clouds, Kubernetes and five tools in your first month leads to burnout. Go deep, one layer at a time.
Only watching videos. Tutorials feel productive, but real learning happens when you build, break and fix things yourself.
Ignoring Linux and networking. These foundations make everything else easier.
Leaving resources running. Always clean up, and always have a budget alert.
Hard-coding secrets. Never commit passwords or access keys to Git.
Using the root or admin account for everything. Create separate users with limited permissions.
Being afraid to break things. Your learning account is a sandbox. Breaking things there is how you learn not to break things in production.

14. Myths about cloud engineering

Myth	Reality
"You must be a programming genius."	You need to be comfortable with scripting and reading code, not to build the next big app. Many great cloud engineers came from IT support, networking or system administration.
"The cloud is always cheaper."	It can be, if it's designed and managed well. Poorly managed cloud environments can be very expensive.
"The cloud is automatically secure."	Providers secure the infrastructure; you must secure your configuration, data and access.
"Servers disappear in the cloud."	They still exist; you just don't manage the hardware. Even "serverless" runs on servers that someone else manages.
"It's too late to start."	Organisations keep moving workloads to the cloud, and skilled people are still needed everywhere, from startups and banks to governments and nonprofits.

15. A beginner's glossary

Term	Plain-English meaning
Cloud provider	A company that rents out computing resources over the internet (AWS, Azure, Google Cloud).
Data centre	A large, secure building full of servers.
Server	A powerful computer that provides services to other computers.
Virtual machine (VM)	A computer created in software, running on a physical server.
Container	A lightweight package containing an app and everything it needs to run.
Docker	The most popular tool for building and running containers.
Kubernetes (K8s)	A system that manages and scales large numbers of containers.
Serverless	Running code without managing any servers; you pay per execution.
Region	A geographic area where a provider has data centres.
Availability zone	An independent data centre (or group of them) within a region.
VPC / VNet	Your private, isolated network inside the cloud.
Load balancer	Spreads incoming traffic across several servers.
IAM	Identity and Access Management: who can do what.
Object storage	Storage for files of any kind, accessed over the internet.
IaC	Infrastructure as Code: defining infrastructure in text files.
Terraform	A popular Infrastructure as Code tool that works with many clouds.
CI/CD	Automatically testing and releasing code changes.
Scalability	The ability to handle more work by adding resources.
Elasticity	Automatically adding and removing resources as demand changes.
High availability	Designing systems to keep running even when parts fail.
Latency	The delay before data arrives; lower is faster.
Egress	Data leaving the cloud, which often costs money.
FinOps	The practice of managing and optimising cloud spending.

Final thoughts: you can do this

Let's go back to where we started. The cloud is simply other people's computers, rented over the internet and paid for as you go. Cloud engineering is the craft of building and running things on those computers so they are reliable, secure, fast and affordable.

Every expert you admire once typed their first command, broke their first server and stared confused at their first error message. The difference between them and someone who never started is not talent; it's that they kept going, one small project at a time.

So here is your challenge for this week: create a free cloud account, set a budget alert, and put a one-page website online. It might take an afternoon. When you see your page live on the internet, served from a data centre somewhere in the world, you will feel the spark that got many of us hooked.

Welcome to the cloud. The sky is not the limit; it's just where your servers live.

Originally written by Michael Gbenga Abajemito. If this helped you, share it with someone starting their cloud journey.

Step-by-Step Guide: Create a Resource Group in Azure

MICHAEL ABAJEMITO — Tue, 17 Mar 2026 14:05:22 +0000

Sign in to Azure Portal
Open your browser.
Navigate to:https://portal.azure.com
Log in with your Azure account credentials.
This opens the Microsoft Azure Portal dashboard.
Open the Resource Groups Service
In the left navigation menu, click Resource groups.
If it is not visible:
• On the Search Bar
• Search for Resource groups
• Select it.
Start Creating a Resource Group
Click the + Create button at the top of the page.
This opens the Create Resource Group configuration page.
1. Configure Basic Settings Fill in the required fields: Subscription Select the Azure subscription where the resource group will be created. Example: Subscription: Pay-As-You-Go Resource Group Name Enter a unique name. Example: GreenCity-RG Best practice: -RG Example naming patterns: FintechApp-RG DataAnalytics-RG GreenCityPlatform-RG Region Select the geographic region where metadata for the resource group will be stored. Example: West Europe East US UK South Note: This does not restrict resources to that region, but it is recommended to align them.
Review Configuration
Click Review + Create.
Azure validates:
• Naming rules
• Subscription permissions
• Region availability
Create the Resource Group
Click Create.
Azure will deploy the resource group in a few seconds.
After that Go back and select Resource Group and the newly created resource group will be displayed.

DEV Community: MICHAEL ABAJEMITO

Jenkins Remoting: Builds on Remote Agents, Two CPU Architectures, Isolated Nodes (CodeAlpha DevOps Internship, Task 2)

The idea

How Jenkins Remoting works (short version)

Everything is configured as code

Network isolation

Running on two CPU architectures

The demo jobs

01: Multi-architecture build

02: Load distribution

03: Node isolation audit

04: Remote machine build

Connecting a real remote machine

Running it

Security summary

Troubleshooting

What I learned

Running a Web Server in Docker the Right Way (CodeAlpha DevOps Internship, Task 4)

What I built

The Dockerfile

Running it safely (docker-compose.yml)

The NGINX config

Checking it works

The lifecycle script

The crash test

Container lifecycle cheat sheet

Monitoring

CI with GitHub Actions

Troubleshooting

What I learned

Building a CI/CD Pipeline on Azure (CodeAlpha DevOps Internship, Task 1)

What the pipeline does

The app

Tests

The Dockerfile

The pipeline (azure-pipelines.yml)

Stage 1: CI

Stage 2: Build and push to ACR

Stage 3: Deploy, check, roll back

The infrastructure (Terraform)

How to set it up yourself

Monitoring

Problems I hit

What I learned

Cloud Engineering for Beginners: A Friendly, Plain-English Guide

Let's start with a confession

1. What is "the cloud", really?

The electricity analogy

Life before the cloud: the server room story

2. So what is cloud engineering?

A day in the life of a cloud engineer

Related job titles you will hear

3. Meet the cloud providers

4. The three ways to use the cloud: IaaS, PaaS and SaaS

The pizza analogy

5. Where does your cloud live? Public, private, hybrid and multi-cloud

6. The building blocks: the five things almost every system needs

Building block 1: Compute (the brains)

Building block 2: Storage (the memory and filing cabinets)

Building block 3: Databases (the organised records)

Building block 4: Networking (the roads and gates)

Building block 5: Identity and security (the keys)

7. The big ideas that make the cloud special

Scalability and elasticity

Pay-as-you-go

Regions and availability zones

High availability and disaster recovery

The shared responsibility model

8. How modern cloud engineers actually work

Infrastructure as Code (IaC)

DevOps and CI/CD

Containers and Kubernetes

Monitoring and observability

9. Cloud security in plain English

10. Let's talk about money (before the cloud talks to you)

11. Your first cloud project: a gentle walkthrough

Project 1: Host a personal website (the "hello, cloud" moment)

Project 2: Launch and connect to a virtual machine

Project 3: Rebuild Project 2 with code

Project 4: Containerise and automate

The pipeline (`azure-pipelines.yml`)