DevOps & Cloud Technologies Guide 2024 Edition
DevOps & Cloud
Technologies Guide
Definition • Why use it • How to use it • Real-Life Example
Docker containerd Kubernetes OpenShift
Flannel Calico Ansible Terraform
Harbor GitOps GitLab
Page 1
DevOps & Cloud Technologies Guide 2024 Edition
Table of Contents
01 Docker Containerization platform
02 containerd Container runtime
03 Kubernetes Container orchestration
04 OpenShift Enterprise Kubernetes platform
05 Flannel Kubernetes networking (CNI)
06 Calico Network policy & security
07 Ansible Agentless IT automation
08 Terraform Infrastructure as Code
09 Harbor Private container registry
10 GitOps Git-driven operations model
11 GitLab DevSecOps platform
Page 2
DevOps & Cloud Technologies Guide 2024 Edition
#1
Docker
Build, ship, and run any app, anywhere
DEFINITION
Docker is an open-source platform that uses OS-level virtualization to package applications and
their dependencies into lightweight, portable units called containers. Unlike virtual machines,
containers share the host OS kernel but run in isolated user-space processes, making them fast
and resource-efficient.
WHY USE IT?
• Eliminates 'works on my machine' problems by bundling code + runtime + libraries.
• Containers start in milliseconds vs minutes for VMs.
• Runs identically on developer laptops, CI servers, and production clouds.
• Docker Hub provides 100,000+ ready-to-use images (nginx, postgres, redis...).
• Foundation for all modern container orchestration (Kubernetes, etc.).
HOW TO USE IT
Install Docker Engine, write a Dockerfile, build an image, push to a registry, run containers.
# 1. Dockerfile for a Python Flask app
FROM python:3.11-slim
WORKDIR /app
COPY [Link] .
RUN pip install -r [Link]
COPY . .
CMD ["python", "[Link]"]
# 2. Build & run
docker build -t myapp:1.0 .
docker run -d -p 5000:5000 myapp:1.0
# 3. Push to Docker Hub
docker tag myapp:1.0 username/myapp:1.0
Page 3
DevOps & Cloud Technologies Guide 2024 Edition
docker push username/myapp:1.0
Real-Life Example
Scenario: E-commerce startup at a Tunisian company (Jumia TN).
Developers package the [Link] frontend, Python API, and PostgreSQL DB each in
separate Docker containers.
A single [Link] spins up the full stack locally in 30 seconds.
The same images are deployed to AWS ECS in production — no environment mismatches.
Result: onboarding a new developer dropped from 2 days to 15 minutes.
Page 4
DevOps & Cloud Technologies Guide 2024 Edition
#2
containerd
The industry-standard container runtime
DEFINITION
containerd is a high-performance, CNCF-graduated container runtime that manages the
complete container lifecycle: image pull, storage, network attachment, execution, and
supervision. It is the runtime that Kubernetes uses internally — Docker itself is built on top of
containerd since version 1.11.
WHY USE IT?
• Kubernetes deprecated the dockershim in v1.24; containerd is the recommended CRI runtime.
• Lower overhead than Docker daemon — no extra REST API layer.
• Supports OCI (Open Container Initiative) standard images.
• Used by AWS EKS, GKE, and Azure AKS by default.
• Pluggable snapshotters (overlayfs, btrfs, ZFS) for storage flexibility.
HOW TO USE IT
containerd is usually managed indirectly by Kubernetes or Docker. Direct use is via the `ctr` or
`nerdctl` CLI.
# Install containerd (Ubuntu)
sudo apt-get install containerd
sudo systemctl enable --now containerd
# Pull and run an image with ctr
sudo ctr images pull [Link]/library/nginx:latest
sudo ctr run --rm [Link]/library/nginx:latest nginx-test
# Or use nerdctl (Docker-compatible CLI for containerd)
nerdctl run -d -p 80:80 nginx
Real-Life Example
Scenario: A bank migrating its Kubernetes cluster from Docker to containerd.
Page 5
DevOps & Cloud Technologies Guide 2024 Edition
The ops team drains each node, switches the kubelet's --container-runtime-endpoint to
containerd.
containerd pulls and caches images from the private Harbor registry.
Pod startup time drops by ~20% due to the leaner runtime.
Security teams appreciate containerd's smaller attack surface (no Docker daemon running
as root).
Page 6
DevOps & Cloud Technologies Guide 2024 Edition
#3
Kubernetes
Automated deployment, scaling, and management of containerized apps
DEFINITION
Kubernetes (K8s) is an open-source container orchestration platform originally designed by
Google and donated to the CNCF in 2014. It automates deploying, scaling, self-healing, load
balancing, and rolling updates of containerized workloads across clusters of machines using a
declarative YAML-based API.
WHY USE IT?
• Self-healing: restarts failed containers, replaces unhealthy nodes automatically.
• Horizontal scaling: scale from 1 to 1000 replicas with one command.
• Service discovery & load balancing built-in via kube-proxy and DNS.
• Rolling updates & rollbacks with zero downtime.
• Multi-cloud and on-prem portability — same YAML works everywhere.
HOW TO USE IT
Define workloads as YAML manifests (Deployment, Service, ConfigMap, etc.) and apply them with
kubectl.
# [Link]
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels: {app: web}
template:
metadata:
labels: {app: web}
Page 7
DevOps & Cloud Technologies Guide 2024 Edition
spec:
containers:
- name: web
image: myapp:1.0
ports: [{containerPort: 5000}]
kubectl apply -f [Link]
kubectl get pods
kubectl scale deployment web-app --replicas=10
Real-Life Example
Scenario: Streaming platform (like Starzplay MENA) handling Ramadan traffic spikes.
All microservices (auth, catalog, player, recommendation) run as Kubernetes Deployments.
During peak hours (night of Ramadan), Horizontal Pod Autoscaler scales pods from 5 to 50
automatically based on CPU.
A bad release is detected; kubectl rollout undo brings back the stable version in 60 seconds.
Multi-AZ node pools ensure the platform survives a data-center outage.
Page 8
DevOps & Cloud Technologies Guide 2024 Edition
#4
OpenShift
Enterprise Kubernetes — batteries included
DEFINITION
Red Hat OpenShift is an enterprise-grade Kubernetes distribution that adds developer tooling, a
built-in CI/CD pipeline (Tekton), an integrated container registry, role-based access control
(RBAC), security policies (SCCs), a web console, and Red Hat support on top of upstream
Kubernetes.
WHY USE IT?
• Security by default: pods cannot run as root; Security Context Constraints enforced.
• Built-in image streams, S2I (Source-to-Image) builds — no Dockerfile needed.
• Operator Framework for day-2 operations of stateful apps (databases, Kafka...).
• Supported by Red Hat — critical for regulated industries (banking, healthcare).
• Available as managed service: ROSA (AWS), ARO (Azure), RHOCP on-prem.
HOW TO USE IT
Use the `oc` CLI (superset of kubectl) or the web console to deploy and manage workloads.
# Login to OpenShift cluster
oc login [Link]
# Create a new project (= namespace)
oc new-project my-app
# Deploy directly from Git repo (S2I)
oc new-app python~[Link]
# Expose the service as a Route (HTTPS)
oc expose svc/myapp
oc get route myapp
Real-Life Example
Scenario: Tunisian national health ministry deploying a patient portal.
Page 9
DevOps & Cloud Technologies Guide 2024 Edition
Ministry uses OpenShift on-prem to meet data sovereignty requirements.
Security Context Constraints prevent any pod from running as root, satisfying audit
requirements.
Developers push code to GitLab; OpenShift Pipelines (Tekton) build, test, and deploy
automatically.
The web console gives project managers a dashboard without kubectl knowledge.
Page 10
DevOps & Cloud Technologies Guide 2024 Edition
#5
Flannel
Simple overlay network for Kubernetes
DEFINITION
Flannel is a lightweight CNI (Container Network Interface) plugin created by CoreOS that
provides a simple layer-3 overlay network for Kubernetes. Each node gets a subnet, and Flannel
creates a virtual network (VXLAN by default) so pods on different nodes can communicate using
their pod IPs.
WHY USE IT?
• Easiest CNI to set up — ideal for dev/test clusters and small production setups.
• Minimal resource overhead compared to feature-rich CNIs.
• Works on bare metal, VMs, and clouds without special configuration.
• Supports multiple backends: VXLAN, host-gw, AWS VPC, GCE.
• Default CNI for many Kubernetes distributions (k3s, some kubeadm guides).
HOW TO USE IT
Deploy Flannel as a DaemonSet on your cluster after initializing with kubeadm.
# During kubeadm init, specify the pod CIDR
kubeadm init --pod-network-cidr=[Link]/16
# Apply Flannel manifest
kubectl apply -f \
[Link]
# Verify Flannel pods are running
kubectl get pods -n kube-flannel
Real-Life Example
Scenario: A startup building an internal ML training cluster on bare-metal servers.
Team spins up a 5-node Kubernetes cluster with kubeadm on Ubuntu servers.
Flannel is deployed in 30 seconds via a single kubectl apply command.
Page 11
DevOps & Cloud Technologies Guide 2024 Edition
All GPU training pods can communicate across nodes via 10.244.x.x pod IPs.
Simple VXLAN tunneling handles cross-node traffic with no cloud vendor lock-in.
Page 12
DevOps & Cloud Technologies Guide 2024 Edition
#6
Calico
Network security and policy for Kubernetes at scale
DEFINITION
Project Calico is an open-source CNI plugin and network policy engine that provides
high-performance networking using BGP routing (no overlay by default) and powerful
NetworkPolicy enforcement at the kernel level via eBPF or iptables. It is the most widely
deployed CNI in production Kubernetes environments.
WHY USE IT?
• Native BGP routing avoids VXLAN overhead — near wire-speed performance.
• Fine-grained NetworkPolicy: control pod-to-pod, pod-to-service, and external traffic.
• Calico Enterprise adds DNS-based policies, threat detection, and compliance reporting.
• Scales to 50,000+ nodes (tested by Google, Apple, IBM).
• Integrates with Istio service mesh for L7 policy enforcement.
HOW TO USE IT
Install Calico as a CNI plugin; then define NetworkPolicy objects to control traffic.
# Install Calico via operator
kubectl create -f [Link]
v3.27.0/manifests/[Link]
kubectl create -f [Link]
v3.27.0/manifests/[Link]
# NetworkPolicy: allow only frontend -> backend on port 8080
apiVersion: [Link]/v1
kind: NetworkPolicy
metadata: {name: allow-frontend}
spec:
podSelector: {matchLabels: {app: backend}}
ingress:
- from: [{podSelector: {matchLabels: {app: frontend}}}]
Page 13
DevOps & Cloud Technologies Guide 2024 Edition
ports: [{port: 8080}]
Real-Life Example
Scenario: A fintech company (payment processor) with PCI-DSS compliance requirements.
Calico isolates the cardholder data environment (CDE) pods from all other workloads by
default (deny-all policy).
Explicit allow policies permit only the payment API pod to reach the database on port 5432.
eBPF dataplane provides sub-millisecond policy enforcement without iptables overhead.
Calico flow logs feed into a SIEM for real-time anomaly detection — required for PCI audit.
Page 14
DevOps & Cloud Technologies Guide 2024 Edition
#7
Ansible
Agentless IT automation in plain YAML
DEFINITION
Ansible is an open-source IT automation tool by Red Hat that automates configuration
management, application deployment, and orchestration using playbooks written in YAML. It is
agentless — it connects to managed nodes over SSH (Linux) or WinRM (Windows) with no
software to install on targets.
WHY USE IT?
• No agent to install or maintain — just SSH access and Python on the target.
• Human-readable YAML playbooks serve as living documentation.
• Idempotent: running a playbook twice produces the same result.
• 3000+ built-in modules: yum, apt, copy, template, docker_container, k8s...
• Replaces fragile shell scripts with version-controlled, testable automation.
HOW TO USE IT
Write an inventory file (list of hosts) and a playbook (list of tasks), then run with ansible-playbook.
# [Link]
[webservers]
[Link]
[Link]
# [Link]
- hosts: webservers
become: true
tasks:
- name: Install Nginx
apt: {name: nginx, state: present, update_cache: yes}
- name: Copy config
template: {src: [Link].j2, dest: /etc/nginx/[Link]}
- name: Start Nginx
Page 15
DevOps & Cloud Technologies Guide 2024 Edition
service: {name: nginx, state: started, enabled: yes}
ansible-playbook -i [Link] [Link]
Real-Life Example
Scenario: Tunisian ISP (Topnet) provisioning 200 new customer-facing servers.
A single Ansible playbook installs and configures Nginx, firewalld, and monitoring agents on
all 200 servers.
Execution completes in 8 minutes in parallel vs 3 days of manual work.
The playbook is stored in Git — every change is peer-reviewed and auditable.
Monthly OS patching is now a scheduled cron job running ansible-playbook with no human
intervention.
Page 16
DevOps & Cloud Technologies Guide 2024 Edition
#8
Terraform
Infrastructure as Code — provision any cloud with declarative HCL
DEFINITION
Terraform is an open-source IaC tool by HashiCorp that lets you define cloud and on-prem
infrastructure in HCL (HashiCorp Configuration Language) or JSON. It uses provider plugins
to manage resources across AWS, Azure, GCP, Kubernetes, Datadog, and 3000+ other
platforms — all from a single workflow.
WHY USE IT?
• Declare desired state; Terraform calculates the diff and applies only what changed.
• One tool for multi-cloud: provision AWS RDS + Azure AD + Cloudflare DNS in one plan.
• terraform plan shows exactly what will change before touching production.
• State management tracks real-world infrastructure for drift detection.
• Huge module registry: reuse community-built modules for VPCs, EKS clusters, etc.
HOW TO USE IT
Write .tf files, run terraform init, terraform plan, terraform apply.
# [Link] — provision an AWS S3 bucket + EC2 instance
provider "aws" { region = "eu-west-3" }
resource "aws_s3_bucket" "assets" {
bucket = "myapp-assets-prod"
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "[Link]"
tags = { Name = "web-server" }
terraform init
terraform plan # Preview changes
Page 17
DevOps & Cloud Technologies Guide 2024 Edition
terraform apply # Apply changes
terraform destroy # Tear down
Real-Life Example
Scenario: SaaS startup launching in two AWS regions simultaneously.
The entire infrastructure (VPC, EKS, RDS, ALB, Route53, ACM) is defined in 400 lines of
Terraform.
terraform workspace new eu / terraform workspace new us-east deploys identical stacks in
both regions.
When the team needs a new S3 bucket, they add 5 lines of HCL, open a PR, and CI runs
terraform plan for review.
After a failed experiment, terraform destroy removes 47 resources cleanly in 3 minutes.
Page 18
DevOps & Cloud Technologies Guide 2024 Edition
#9
Harbor
Cloud-native private container registry with security scanning
DEFINITION
Harbor is a CNCF-graduated open-source container registry that stores, signs, and scans
Docker/OCI images. It adds enterprise features on top of a basic registry: vulnerability
scanning (Trivy/Clair), image signing (Notary), RBAC, replication between registries, and audit
logs.
WHY USE IT?
• Keep container images on-premises — required for air-gapped or regulated environments.
• Automated CVE scanning blocks vulnerable images from being pulled.
• Image signing (cosign/Notary) ensures supply-chain integrity.
• Replication: mirror images from Docker Hub to Harbor for air-gapped deployments.
• RBAC per project: developers can push, but only CI can promote to production.
HOW TO USE IT
Deploy Harbor via Helm on Kubernetes, configure projects, push images using standard Docker CLI.
# Add Harbor Helm repo and install
helm repo add harbor [Link]
helm install harbor harbor/harbor \
--set [Link]=ingress \
--set [Link]=true \
--set externalURL=[Link]
# Push an image to Harbor
docker login [Link]
docker tag myapp:1.0 [Link]/team/myapp:1.0
docker push [Link]/team/myapp:1.0
# Trivy scan is triggered automatically on push
# View results in Harbor web UI or via API
Page 19
DevOps & Cloud Technologies Guide 2024 Edition
Real-Life Example
Scenario: Defense contractor building software for a government client.
All base images are mirrored from Docker Hub into Harbor on an air-gapped network.
Every image pushed by developers is automatically scanned; images with Critical CVEs are
blocked.
Kubernetes admission controller (Gatekeeper) only allows signed images from Harbor to run
in production.
Audit logs in Harbor record every image pull for compliance reporting.
Page 20
DevOps & Cloud Technologies Guide 2024 Edition
#10
GitOps
Git as the single source of truth for infrastructure and apps
DEFINITION
GitOps is an operational model that uses Git repositories as the single source of truth for
declarative infrastructure and application definitions. A GitOps operator (ArgoCD, Flux)
continuously reconciles the live cluster state with the desired state in Git — any drift triggers an
automatic correction.
WHY USE IT?
• Every change is a Git commit — full audit trail, easy rollback with git revert.
• No human kubectl access to production — reduces risk of accidental changes.
• Developers use pull requests to deploy to production — familiar workflow.
• Automatic drift detection: if someone manually changes a resource, GitOps corrects it.
• Disaster recovery: recreate an entire cluster from Git history.
HOW TO USE IT
Store Kubernetes manifests in Git. Deploy ArgoCD or Flux to watch the repo and sync the cluster.
# Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f \
[Link]
# Define an ArgoCD Application pointing to your Git repo
apiVersion: [Link]/v1alpha1
kind: Application
metadata: {name: my-app, namespace: argocd}
spec:
source:
repoURL: [Link]
path: apps/my-app
targetRevision: main
Page 21
DevOps & Cloud Technologies Guide 2024 Edition
destination:
server: [Link]
namespace: production
syncPolicy: {automated: {prune: true, selfHeal: true}}
Real-Life Example
Scenario: Global retail company deploying 50 microservices across 3 Kubernetes clusters.
All 50 services' Helm charts are stored in a monorepo on GitLab.
A developer opens a MR to bump an image tag from v1.4 to v1.5 — that's the entire deploy
process.
ArgoCD detects the merge, syncs the cluster in under 2 minutes, and sends a Slack
notification.
After a bug is found, git revert reverts the commit; ArgoCD rolls back production
automatically.
Page 22
DevOps & Cloud Technologies Guide 2024 Edition
#11
GitLab
Complete DevSecOps platform — from code to production
DEFINITION
GitLab is an open-core DevSecOps platform that provides Git repository hosting, CI/CD
pipelines, container registry, security scanning (SAST, DAST, dependency scanning), issue
tracking, Wiki, and Kubernetes integration — all in a single application, available as SaaS
([Link]) or self-hosted.
WHY USE IT?
• Single tool replaces GitHub + Jenkins + Jira + Nexus + SonarQube.
• GitLab CI/CD uses simple .[Link] — no Jenkinsfile XML complexity.
• Built-in security: SAST, DAST, container scanning, secret detection on every MR.
• GitLab Runners can be self-hosted for air-gapped or compliance environments.
• Deep Kubernetes integration: deploy to K8s directly from pipelines.
HOW TO USE IT
Create a repository, add a .[Link] to define your pipeline stages, and push.
# .[Link] — full CI/CD pipeline
stages: [build, test, scan, deploy]
build:
stage: build
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
test:
stage: test
script: [pytest tests/ --junitxml=[Link]]
artifacts: {reports: {junit: [Link]}}
sast:
Page 23
DevOps & Cloud Technologies Guide 2024 Edition
stage: scan
include: [{template: Security/[Link]}]
deploy_prod:
stage: deploy
script: [kubectl set image deploy/web web=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA]
environment: {name: production}
when: manual
Real-Life Example
Scenario: A Tunisian software house (e.g. SDC or Vermeg) with 30 developers.
All source code, issues, and wikis live on a self-hosted GitLab instance inside the company
VPN.
Every merge request triggers a pipeline: build Docker image, run 500 unit tests, SAST scan,
deploy to staging.
Security team reviews vulnerabilities in the GitLab Security Dashboard before approving
MRs.
Production deploys require two approvals — all tracked in GitLab's audit log for ISO 27001
compliance.
Page 24