DEV Community: Droid Ek

Configure AntiGravity

Droid Ek — Mon, 30 Mar 2026 22:38:57 +0000

Note: I am not very good in writing so i did take help from chatgpt.

Docker Labs: From Beginner to Advanced on Azure

Droid Ek — Thu, 06 Nov 2025 19:09:55 +0000

Docker Labs: From Beginner to Advanced on Azure
Note: Thanks for reading, here in this segment i will be talking about docker labs some of this is my own thoughts. I revising what i have learned most of you guys can join me

Lab 1: Initial Azure Setup and Docker Installation

Step 1: Create Azure VM with Docker

# Create resource group
az group create --name DockerLabs --location eastus

# Create Ubuntu VM with Docker
az vm create \
  --resource-group DockerLabs \
  --name DockerVM \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --size Standard_B2s \
  --custom-data cloud-init-docker.txt

Create cloud-init-docker.txt:

#cloud-config
package_upgrade: true
packages:
  - apt-transport-https
  - ca-certificates
  - curl
  - gnupg
  - lsb-release
runcmd:
  - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
  - echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  - apt-get update
  - apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
  - usermod -aG docker azureuser
  - systemctl enable docker

Step 2: Connect and Verify

# SSH to your VM
ssh azureuser@<your-vm-ip>

# Verify Docker installation
docker --version
docker-compose --version
docker system info

# Test with hello-world
docker run hello-world

Lab 2: Basic Docker Operations

Step 1: Container Lifecycle Management

# Pull an image
docker pull nginx:alpine

# Run a container
docker run -d --name web-server -p 80:80 nginx:alpine

# Check running containers
docker ps

# View container logs
docker logs web-server

# Execute commands in running container
docker exec -it web-server sh

# Stop and remove container
docker stop web-server
docker rm web-server

Step 2: Container Networking Basics

# Create a custom network
docker network create my-network

# Run containers on the same network
docker run -d --name web1 --network my-network nginx:alpine
docker run -d --name web2 --network my-network nginx:alpine

# Test connectivity between containers
docker exec web1 ping web2

# Inspect network
docker network inspect my-network

Lab 3: Building Custom Images

Step 1: Create a Simple Web Application
Create project structure:

mkdir my-webapp && cd my-webapp

Create app.py:

from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def hello():
    return f"""
    <html>
        <body>
            <h1>Hello from Docker!</h1>
            <p>Hostname: {os.environ.get('HOSTNAME', 'Unknown')}</p>
            <p>Visit count: <!-- will be implemented later --></p>
        </body>
    </html>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Create requirements.txt:

Flask==2.3.3
Redis==4.6.0

Step 2: Create Dockerfile

# Use official Python runtime
FROM python:3.9-slim

# Set working directory
WORKDIR /app

# Copy requirements and install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy application code
COPY . .

# Expose port
EXPOSE 5000

# Set environment variables
ENV FLASK_ENV=production

# Run the application
CMD ["python", "app.py"]

Step 3: Build and Run

# Build the image
docker build -t my-webapp .

# Run the container
docker run -d --name my-app -p 5000:5000 my-webapp

# Test the application
curl http://localhost:5000

Lab 4: Docker Compose - Multi-Container Application

Step 1: Create Redis Counter Application
Update app.py:

from flask import Flask
import redis
import os

app = Flask(__name__)
redis_client = redis.Redis(host='redis', port=6379, decode_responses=True)

@app.route('/')
def hello():
    count = redis_client.incr('visit_count')
    return f"""
    <html>
        <body>
            <h1>Hello from Docker Compose!</h1>
            <p>Hostname: {os.environ.get('HOSTNAME', 'Unknown')}</p>
            <p>Visit count: {count}</p>
        </body>
    </html>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Step 2: Create docker-compose.yml

version: '3.8'

services:
  web:
    build: .
    ports:
      - "5000:5000"
    environment:
      - FLASK_ENV=production
    depends_on:
      - redis
    networks:
      - app-network

  redis:
    image: redis:7-alpine
    networks:
      - app-network
    volumes:
      - redis-data:/data

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - web
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

volumes:
  redis-data:

Step 3: Create Nginx Configuration
Create nginx.conf:

events {
    worker_connections 1024;
}

http {
    upstream webapp {
        server web:5000;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://webapp;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

Step 4: Deploy with Compose

# Start all services
docker compose up -d

# Check status
docker compose ps

# View logs
docker compose logs -f

# Scale web service
docker compose up -d --scale web=3

Lab 5: Data Management and Volumes

Step 1: Persistent Data with Volumes

# Create named volume
docker volume create app-data

# Run container with volume
docker run -d \
  --name db \
  -v app-data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=secret \
  mysql:8.0

# Inspect volume
docker volume inspect app-data

# Backup volume
docker run --rm \
  -v app-data:/source \
  -v $(pwd):/backup \
  alpine tar czf /backup/backup.tar.gz -C /source .

Step 2: Bind Mounts for Development

# Development with bind mount
docker run -d \
  --name dev-app \
  -p 5001:5000 \
  -v $(pwd):/app \
  -w /app \
  python:3.9-slim \
  sh -c "pip install -r requirements.txt && python app.py"

Lab 6: Advanced Dockerfile Techniques

Step 1: Multi-Stage Build
Create advanced Dockerfile.advanced:

# Build stage
FROM python:3.9-slim as builder

WORKDIR /build
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# Runtime stage
FROM python:3.9-slim

# Install security updates
RUN apt-get update && \
    apt-get upgrade -y && \
    rm -rf /var/lib/apt/lists/*

# Create non-root user
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app

# Copy installed packages from builder
COPY --from=builder /root/.local /home/appuser/.local
COPY --chown=appuser:appuser . .

# Switch to non-root user
USER appuser

# Add user's local bin to PATH
ENV PATH=/home/appuser/.local/bin:$PATH

EXPOSE 5000

HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:5000/ || exit 1

CMD ["python", "app.py"]

Step 2: Build and Test Advanced Image

# Build with advanced Dockerfile
docker build -t my-webapp:secure -f Dockerfile.advanced .

# Run with security context
docker run -d \
  --name secure-app \
  -p 5002:5000 \
  --read-only \
  --tmpfs /tmp \
  my-webapp:secure

# Check health status
docker inspect --format='{{.State.Health.Status}}' secure-app

Lab 7: Container Orchestration with Docker Swarm

Step 1: Initialize Swarm Mode

# Initialize swarm (on manager node)
docker swarm init

# Create overlay network
docker network create -d overlay app-overlay

# Deploy stack
docker stack deploy -c docker-compose.swarm.yml myapp

Step 2: Create Swarm Compose File
Create docker-compose.swarm.yml:

version: '3.8'

services:
  web:
    image: my-webapp:secure
    ports:
      - "5000:5000"
    deploy:
      replicas: 3
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
      resources:
        limits:
          memory: 256M
        reservations:
          memory: 128M
    networks:
      - app-overlay

  redis:
    image: redis:7-alpine
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager
    volumes:
      - redis-data:/data
    networks:
      - app-overlay

  visualizer:
    image: dockersamples/visualizer:stable
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      placement:
        constraints:
          - node.role == manager
    networks:
      - app-overlay

networks:
  app-overlay:
    external: true

volumes:
  redis-data:

Step 3: Manage Swarm Services

# Check service status
docker service ls

# Scale services
docker service scale myapp_web=5

# View service logs
docker service logs myapp_web

# Update service
docker service update --image my-webapp:new-version myapp_web

Lab 8: Monitoring and Logging

Step 1: Set up Monitoring Stack
Create monitoring/docker-compose.monitoring.yml:

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--storage.tsdb.retention.time=200h'
      - '--web.enable-lifecycle'
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana_data:/var/lib/grafana
    networks:
      - monitoring

  node-exporter:
    image: prom/node-exporter:latest
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    networks:
      - monitoring

networks:
  monitoring:
    driver: bridge

volumes:
  prom_data:
  grafana_data:

Step 2: Prometheus Configuration
Create monitoring/prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'docker-containers'
    static_configs:
      - targets: ['localhost:9323']

Lab 9: Security Best Practices

Step 1: Security Scanning

# Install Docker Scout (if not available, use Trivy)
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Scan image for vulnerabilities
grype my-webapp:secure

# Use Docker Bench Security
docker run -it --net host --pid host --userns host --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST=1 \
  -v /var/lib:/var/lib \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc:/etc \
  --label docker_bench_security \
  docker/docker-bench-security

Step 2: Content Trust and Signing

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Build and push with signing
docker build -t myregistry.azurecr.io/my-webapp:1.0 .
docker push myregistry.azurecr.io/my-webapp:1.0

Lab 10: Azure Container Registry Integration

Step 1: Create and Configure ACR

# Create Azure Container Registry
az acr create --resource-group DockerLabs --name myDockerRegistry --sku Basic

# Login to ACR
az acr login --name myDockerRegistry

# Tag and push images
docker tag my-webapp:secure mydockerregistry.azurecr.io/my-webapp:1.0
docker push mydockerregistry.azurecr.io/my-webapp:1.0

# Pull from ACR
docker pull mydockerregistry.azurecr.io/my-webapp:1.0

Step 2: Automated Builds with ACR Tasks

# Create ACR build task
az acr build --registry myDockerRegistry --image my-webapp:latest .

# Set up automated build on Git commit
az acr task create \
  --registry myDockerRegistry \
  --name buildwebapp \
  --image my-webapp:{{.Run.ID}} \
  --context https://github.com/yourusername/my-webapp.git \
  --file Dockerfile \
  --branch main \
  --git-access-token <your-token>

Final Project: Complete Microservices Application

Create final-project/docker-compose.prod.yml:

version: '3.8'

services:
  frontend:
    image: mydockerregistry.azurecr.io/my-webapp:1.0
    deploy:
      replicas: 3
    environment:
      - REDIS_HOST=redis
    networks:
      - frontend
      - backend

  api:
    image: mydockerregistry.azurecr.io/api-service:1.0
    deploy:
      replicas: 2
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/app
    networks:
      - backend

  redis:
    image: redis:7-alpine
    deploy:
      placement:
        constraints:
          - node.role == manager
    volumes:
      - redis-data:/data
    networks:
      - backend

  db:
    image: postgres:13
    environment:
      - POSTGRES_DB=app
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - backend

  traefik:
    image: traefik:v2.9
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik.yml:/etc/traefik/traefik.yml
    networks:
      - frontend

networks:
  frontend:
    driver: overlay
  backend:
    driver: overlay

volumes:
  redis-data:
  postgres-data:

N8N Installation And Configuration

Droid Ek — Thu, 06 Nov 2025 18:49:41 +0000

N8N Installation And Configuration

Setting Up a Self-Hosted n8n Automation Server on Ubuntu

This document outlines the end-to-end process of deploying the n8n automation platform on a fresh Ubuntu Server virtual machine using Docker. It also includes optional steps for adding a graphical user interface (GUI) for remote management.

Operating System: Ubuntu 24.04 LTS (Server Edition)

Part 1: Server and Prerequisite Setup

This section covers the initial server preparation, the optional installation of a desktop environment, and the mandatory installation of the Docker Engine.

Step 1.1: Virtual Machine (VM) Provisioning

An Ubuntu 24.04 LTS Server environment was chosen. This is a command-line-only operating system, which is lightweight and secure, making it ideal for server applications.

Step 1.2: (Optional) Installing a Graphical Desktop Environment

The server operates via command line by default. For users who prefer a graphical interface for management, a desktop environment can be installed.

Note: This is generally not recommended for a production server as it consumes more system resources (RAM, CPU) and can increase the system's security attack surface.

Install the Ubuntu Desktop (GNOME): This command installs the standard graphical interface.

Bash

sudo apt update

sudo apt install ubuntu-desktop -y

Install a Remote Desktop Server (xrdp): To access the graphical desktop from another computer, a remote desktop protocol (RDP) server is required. xrdp is a common choice.

Bash

sudo apt install xrdp -y

Allow RDP through the firewall (if enabled): If you are using ufw (Uncomplicated Firewall), you must allow traffic on the RDP port.

Bash

sudo ufw allow 3389

After these steps, you can connect to your server's IP address using any standard Remote Desktop Client (like the one built into Windows).

Step 1.3: System Update

Ensure all system packages are up to date.

Bash

sudo apt update && sudo apt upgrade -y

Step 1.4: Docker Engine Installation

Install prerequisite packages: These are needed to allow apt to use repositories over HTTPS.

Bash

sudo apt install ca-certificates curl gnupg

Add Docker's official GPG key: This verifies the authenticity of the Docker packages.

Bash

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

Set up the Docker repository: This tells the system where to download Docker from.

Bash

echo \

"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \

$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \

sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install Docker Engine, CLI, and Compose:

Bash

sudo apt update

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Allow non-root user to run Docker (Post-installation): Add your user to the docker group to avoid using sudo for every command.

Bash

sudo usermod -aG docker $USER

IMPORTANT: You must log out and log back in for this change to take effect.

Part 2: n8n Application Deployment with Docker Compose

This section details the deployment of the n8n application container.

Step 2.1: Create a Project Directory

Create and enter a dedicated directory to store n8n configuration and data.

Bash

mkdir n8n-selfhosted

cd n8n-selfhosted

Step 2.2: Create the docker-compose.yml File

Using a text editor like nano, create the configuration file that defines the n8n service.

Bash

nano docker-compose.yml

Step 2.3: Define the n8n Service

Paste the following configuration into the docker-compose.yml file. This setup ensures data is persisted in a Docker volume.

YAML

version: '3.7'

services:

n8n:

image: n8nio/n8n:latest

restart: always

ports:

  - "5678:5678"

environment:

  - GENERIC_TIMEZONE=Asia/Kolkata

  - N8N_ENCRYPTION_KEY='YOUR_SUPER_SECRET_KEY_HERE'

volumes:

  - n8n_data:/home/node/.n8n

# Wait for container to be stopped before killing it

stop_grace_period: 1m

volumes:

n8n_data:

Step 2.4: Customize Configuration

Timezone: The GENERIC_TIMEZONE was set to Asia/Kolkata to ensure scheduled workflows run at the correct local time.
Encryption Key: A unique and persistent N8N_ENCRYPTION_KEY is critical for securing credentials. A key was generated using the command below and pasted into the 'YOUR_SUPER_SECRET_KEY_HERE' placeholder.

Bash

Run this command to generate a key

openssl rand -base64 32

Step 2.5: Launch n8n

From within the n8n-selfhosted directory, start the n8n container in detached mode.

Bash

docker compose up -d

Part 3: Final Setup and Verification

This section covers accessing the UI and completing the initial setup.

Step 3.1: Access the n8n Web Interface

The n8n instance is accessible via a web browser at:

http://:5678

Step 3.2: Create the n8n Owner Account

Upon first access, the setup screen prompts for the creation of an owner (admin) account with a username, email, and password. This completes the installation.

Part 4: First Workflow Creation (Beginner's Guide)

A simple workflow was created to learn the core concepts of n8n.

"Hello World" with the Set Node: A workflow was created with a Manual trigger and a Set node to create a static JSON object ({"message": "Hello..."}). This demonstrated the basic build-and-execute cycle.
Connecting to an API with the Weather Node:
    The Weather node was added to the workflow.
    A new credential was created for the OpenWeatherMap API by providing a free API key.
    The node was configured to fetch the current weather for "Bengaluru". This demonstrated connecting to external services and managing credentials.
Automating with the Cron Trigger:
    The Manual trigger was replaced with a Cron node.
    The schedule was set to run daily at a specific time (e.g., 9:00 AM).
    The workflow was activated using the toggle switch in the top-right, enabling it to run automatically in the background.

Appendix: Common Management Commands

All commands should be run from the n8n-selfhosted directory.

Stop n8n: docker compose stop
Start n8n: docker compose start
View n8n logs: docker compose logs -f
Update n8n to the latest version:

Bash

Pull the latest image from Docker Hub

docker compose pull

Recreate the container with the new image

docker compose up -d

Stop and remove the n8n container: docker compose down (Your data in the n8n_data volume will be p

reserved).

Note: I am pretty new to the Ai, ML, Deep Learning stuff i am learning as i go.

Azure Landing Zone

Droid Ek — Thu, 06 Nov 2025 18:40:53 +0000

The Complete Guide to Production-Grade Azure Landing Zones

Note; If you find any mistakes please do not burn me kindly let me know.

Intro

An Azure Landing Zone is the foundational output of a multi-subscription Azure environment that considers scale, security, governance, networking, and identity. It provides a well-defined, repeatable starting point for all your cloud workloads, ensuring they are deployed into a secure, compliant, and operationally excellent environment from day one. A landing zone solves critical enterprise challenges like inconsistent security postures, sprawling and ungoverned environments, lack of visibility, and ballooning costs by establishing a baseline architecture and "guardrails" through policy.

Architect and Design: Confidently design an enterprise-grade Azure Landing Zone based on the Cloud Adoption Framework's principles.
Build with Confidence: Use Infrastructure as Code (Bicep and Terraform) to deploy a complete, modular, and repeatable landing zone.
Govern at Scale: Implement robust governance using Azure Policy, Management Groups, and Role-Based Access Control (RBAC) to enforce security and compliance.
Automate Everything: Build and configure CI/CD pipelines in GitHub Actions and Azure DevOps to enable safe, automated, and auditable deployments.
Operate with Excellence: Establish centralized monitoring, logging, and security to ensure the health, performance, and security of your Azure environment.
Validate and Test: Write and execute automated tests to continuously validate the compliance and health of your landing zone.

1. Prerequisites: Tools, Accounts, and Setup

(Estimated Time: 2 Hours)

Before we build, we must prepare our workshop. This module ensures you have all the necessary tools and permissions.

Lab 1.1: Tool Installation

Lab 1.2: Account and Permissions Verification

Why this matters: A landing zone deployment creates and configures fundamental resources like management groups. These actions require elevated permissions. Verifying them now prevents failures later.

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Verify Role	`az ad signed-in-user show --query "userPrincipalName"` and check permissions in the Azure portal at the tenant root management group.	You need `Owner` or a role with `Microsoft.Management/managementGroups/write` permissions at the root scope.	10m
2	Register Providers	`az provider register --namespace Microsoft.Management` `az provider register --namespace Microsoft.Network` `az provider register --namespace Microsoft.Insights`	For each command, the output `RegistrationState` should eventually be `Registered`.	25m

2. High-Level Architecture, Naming, and Tagging

This section outlines the target state architecture we will build.

Architecture Diagram (Hub-and-Spoke)

/------------------------------------------------------\
| Azure Tenant / Root Management Group                 |
|                                                      |
|   /---------------------------------------------\    |
|   | Platform Management Group                   |    |
|   |   /------------------\   /----------------\ |    |
|   |   | Identity MG      |   | Management MG  | |    |
|   |   | (Sub: Identity)  |   | (Sub: Mgmt)    | |    |
|   |   \------------------/   \----------------/ |    |
|   |   /------------------\                      |    |
|   |   | Connectivity MG  |                      |    |
|   |   | (Sub: Hub Ntwk)  |                      |    |
|   |   \------------------/                      |    |
|   \---------------------------------------------/    |
|                                                      |
|   /---------------------------------------------\    |
|   | Landing Zones Management Group              |    |
|   |   /------------------\   /----------------\ |    |
|   |   | Prod MG          |   | Non-Prod MG    | |    |
|   |   | (Sub: Prod-App1) |   | (Sub: Dev-App1)| |    |
|   |   \------------------/   \----------------/ |    |
|   \---------------------------------------------/    |
\------------------------------------------------------/

Network Flow:
[Spoke VNet (Prod-App1)] <--VNet Peering--> [Hub VNet] <--Firewall--> [Internet/On-Prem]

Naming Convention and Tagging Strategy

Why this matters: A consistent naming and tagging strategy is the bedrock of good governance. It enables automation, simplifies cost management, improves clarity, and enhances security by making resources easily identifiable and groupable.

Naming Convention: [ResourceType]-[WorkloadName]-[Environment]-[AzureRegion]-[Instance]

Examples: rg-myapp-prod-eastus-001, vnet-hub-prod-eastus-001

Tagging Strategy (Mandatory Tags):

Tag Key	Purpose	Example Value
`owner`	Identifies the business or technical owner.	`finance-team@example.com`
`costCenter`	Associates resource with an internal cost center.	`12345`
`environment`	The deployment environment.	`prod` / `dev`
`appName`	The name of the application or service.	`SAP-HANA`

3. Curriculum: The Learning Path

Module 1: Governance Foundation with Management Groups

Summary: Establish the core hierarchical structure of your Azure environment.
Time: 3 Hours
Difficulty: Beginner

Module 2: Identity & Access Management (IAM)

Summary: Configure the identity backbone, defining who can do what.
Time: 4 Hours
Difficulty: Intermediate

Module 3: Policy-Driven Governance & Security Baselines

Summary: Implement automated guardrails to enforce security and compliance.
Time: 5 Hours
Difficulty: Intermediate

Module 4: Network Foundation (Hub-and-Spoke)

Summary: Build the core network topology for secure connectivity.
Time: 6 Hours
Difficulty: Advanced

Module 5: Centralized Operations & Shared Services

Summary: Deploy and configure centralized services for logging and secrets.
Time: 4 Hours
Difficulty: Intermediate

Module 6: Infrastructure as Code (IaC) & Repository Structure

Summary: Organize your Bicep/Terraform code for scalability and reuse.
Time: 5 Hours
Difficulty: Intermediate

Module 7: CI/CD & GitOps Automation

Summary: Build automated pipelines to deploy landing zone changes safely.
Time: 6 Hours
Difficulty: Advanced

Module 8: Capstone Project

Summary: Apply all learned concepts to build a complete landing zone from scratch.
Time: 8 Hours
Difficulty: Expert

Module 1: Governance Foundation with Management Groups

Why this matters: Management groups provide a level of scope above subscriptions, allowing you to apply governance controls like policies and access assignments efficiently and consistently across your entire Azure estate. A well-designed hierarchy is the first and most critical step to scaling your cloud environment securely.

Hands-on Lab: Creating the Management Group Hierarchy

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create Platform MG	`az account management-group create --name "lz-platform"`	JSON output describing the new `lz-platform` MG.	10m
2	Create Child MGs	`az account management-group create --name "lz-identity" --parent "lz-platform"` `az account management-group create --name "lz-management" --parent "lz-platform"` `az account management-group create --name "lz-connectivity" --parent "lz-platform"`	JSON output for each new MG.	15m
3	Create Landing Zones MG	`az account management-group create --name "lz-landingzones"`	JSON output for the `lz-landingzones` MG.	10m
4	Create Prod/NonProd MGs	`az account management-group create --name "lz-prod" --parent "lz-landingzones"` `az account management-group create --name "lz-nonprod" --parent "lz-landingzones"`	JSON output for each new MG.	10m
5	Verify Hierarchy	`az account management-group show --name "lz-platform" --expand --recurse`	A tree structure in the JSON output showing the parent-child relationships.	5m

Bicep Artifact: `managementGroups.bicep`

targetScope = 'tenant'

resource mgPlatform 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'lz-platform'
  properties: { displayName: 'Platform' }
}

resource mgConnectivity 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'lz-connectivity'
  properties: {
    displayName: 'Connectivity'
    details: { parent: { id: mgPlatform.id } }
  }
}
// ... other MGs follow the same pattern

Deployment: az deployment tenant create --location eastus --template-file managementGroups.bicep

Terraform Artifact: `management_groups.tf`

resource "azurerm_management_group" "platform" {
  display_name = "Platform"
  name         = "lz-platform"
}

resource "azurerm_management_group" "connectivity" {
  display_name               = "Connectivity"
  name                       = "lz-connectivity"
  parent_management_group_id = azurerm_management_group.platform.id
}
// ... other MGs follow the same pattern

Deployment: terraform init && terraform apply

Architectural Deep Dive & Use Case

Deep Dive: The recommended CAF hierarchy is relatively shallow to reduce complexity. A deep hierarchy modeled after an org chart can become difficult to manage due to complex policy and RBAC inheritance. The functional design (Platform, Landing Zones) provides a more robust model for applying governance.
Use Case - Preventing Cloud Sprawl: An enterprise is struggling with uncontrolled resource creation and costs. By creating Prod and Non-Prod management groups, they can apply stricter policies (like limiting expensive VM SKUs) to the Non-Prod group while applying stricter security policies to the Prod group, all from a central point of control.

Module 2: Identity & Access Management (IAM)

Why this matters: Identity is the modern security perimeter. This pillar focuses on ensuring all access to Azure is authenticated, authorized, and audited according to Zero Trust principles.

Hands-on Lab: Implementing Least Privilege

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create Custom Role	Create `SpokeVnetContributor.json` (see below). Then run: `az role definition create --role-definition @SpokeVnetContributor.json`	JSON output of the new role definition.	20m
2	Assign Role	Get your App Team's Group ID: `GROUP_ID=$(az ad group show --group "YourAppTeamGroup" --query id -o tsv)` Get subscription ID: `SUB_ID=$(az account show --query id -o tsv)` `az role assignment create --assignee $GROUP_ID --role "Spoke VNet Contributor" --scope /subscriptions/$SUB_ID`	JSON output of the role assignment.	15m
3	Configure PIM	In the Azure Portal, navigate to Azure AD > Privileged Identity Management. Make your platform admin account "eligible" for the built-in `Contributor` role on the `lz-platform` management group.	When you go to "My roles" in PIM, you will see the eligible assignment and an "Activate" button.	30m

Artifact: `SpokeVnetContributor.json`

{
  "Name": "Spoke VNet Contributor",
  "Description": "Allows contributing to resources within a spoke VNet without network modification rights.",
  "Actions": [
    "Microsoft.Storage/*",
    "Microsoft.Compute/*",
    "Microsoft.Sql/*",
    "Microsoft.Web/*"
  ],
  "NotActions": [
    "Microsoft.Network/virtualNetworks/*",
    "Microsoft.Network/routeTables/*"
  ],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/lz-landingzones"
  ]
}

Architectural Deep Dive & Use Cases

Deep Dive - Managed Identities: The superior architectural choice over service principals with secrets. A Managed Identity is a credential managed entirely by Azure for a resource (like a VM or Web App). This eliminates the entire class of risks associated with developers managing, rotating, and potentially leaking secrets.
Use Case 1 - Secure Emergency Access: A production application is down. Using PIM, an on-call engineer requests to activate the Contributor role for 2 hours, providing the incident ticket number as justification. They get temporary, just-in-time access to fix the issue. All actions are audited, and access is automatically revoked, eliminating the risk of a standing privileged account.
Use Case 2 - Passwordless CI/CD: A CI/CD pipeline needs to deploy resources. Instead of storing a service principal secret in GitHub, the pipeline uses Managed Identity (or workload identity federation) to securely obtain an access token, eliminating secrets from the DevOps toolchain.

Module 3: Policy-Driven Governance & Security Baselines

Why this matters: Azure Policy is the core of governance, enabling you to enforce rules at scale. It ensures that as new resources are created, they automatically adhere to security and compliance standards, preventing misconfigurations before they happen.

Hands-on Lab: Creating and Assigning Policy

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create "Enforce Tag" Policy	Create `enforce-tag-policy.json` (see below). Run: `az policy definition create --name "enforce-costCenter-tag" --rules enforce-tag-policy.json --mode All`	JSON output of the created policy definition.	20m
2	Create Initiative	`POLICY_ID=$(az policy definition show --name "enforce-costCenter-tag" --query id -o tsv)` Create `initiative.json` (see below). Then run: `az policy set-definition create --name "landingzone-baseline" --definitions initiative.json`	JSON output of the created initiative.	20m
3	Assign Initiative	`INITIATIVE_ID=$(az policy set-definition show --name "landingzone-baseline" --query id -o tsv)` `MG_ID=$(az account management-group show --name "lz-landingzones" --query id -o tsv)` `az policy assignment create --name "lz-baseline-assignment" --scope $MG_ID --policy-set-definition $INITIATIVE_ID`	JSON output of the policy assignment.	15m
4	Test Policy	Try to create a resource group without the `costCenter` tag under the target MG: `az group create -n "test-rg" -l "eastus"`	The command should fail with a policy violation error.	10m

Azure Policy JSON Artifacts

enforce-tag-policy.json (Deny effect)

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Resources/subscriptions/resourceGroups" },
      { "field": "tags['costCenter']", "exists": "false" }
    ]
  },
  "then": { "effect": "deny" }
}

initiative.json (placeholder)

{
  "properties": {
    "displayName": "Landing Zone Baseline Policies",
    "policyDefinitions": [
      { "policyDefinitionId": "[POLICY_ID]" }
    ]
  }
}

Architectural Deep Dive & Use Case

Deep Dive - Policy-as-Code: This is the practice of managing your policy definitions and assignments as code in a Git repository. Every change is peer-reviewed via a pull request and deployed through an automated CI/CD pipeline. This provides versioning, validation (using what-if), and an audit trail for all your governance rules. The DeployIfNotExists effect is a powerful remediation tool to automatically configure things like diagnostic settings.
Use Case - Enforcing Data Sovereignty (GDPR): A European company must ensure citizen data remains within the EU. A policy initiative is assigned to their EU management group containing an "Allowed Locations" policy that only permits deployment in West Europe and North Europe. This automated guardrail makes it impossible for developers to accidentally violate GDPR, preventing massive potential fines.

Module 4: Network Foundation (Hub-and-Spoke)

Why this matters: A hub-and-spoke network topology centralizes common services like firewalls and gateways, reducing cost and management overhead. It provides a secure and scalable model for connecting multiple workloads (spokes) while enforcing traffic inspection.

Hands-on Lab: Building the Hub-and-Spoke Network

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Deploy Hub VNet	Use the `hubNetwork.bicep` file below with the command: `az deployment group create --resource-group "rg-hub-prod-eastus" --template-file hubNetwork.bicep`	Successful deployment. This may take 20-30 minutes for the Firewall to provision.	30m
2	Deploy Spoke VNet	Use `spokeNetwork.bicep` below with the command: `az deployment group create --resource-group "rg-spoke-app1-prod-eastus" --template-file spokeNetwork.bicep`	Successful deployment.	15m
3	Peer the VNets	(Use CLI or Portal to create peering from Hub -> Spoke and Spoke -> Hub) `az network vnet peering create ...`	Peering status becomes `Connected`.	15m
4	Configure Spoke Route	`FW_PRIVATE_IP=$(az network firewall show ... --query "ipConfigurations[0].privateIpAddress")` `az network route-table route create ... --next-hop-type VirtualAppliance --address-prefix 0.0.0.0/0 --next-hop-ip-address $FW_PRIVATE_IP` `az network vnet subnet update ... --route-table <YourRouteTable>`	Route table is associated with the spoke subnet.	20m

Bicep Artifacts

hubNetwork.bicep

param location string = resourceGroup().location
param vnetName string = 'vnet-hub-prod-eastus-001'
param firewallName string = 'fw-hub-prod-eastus-001'

resource publicIpFirewall 'Microsoft.Network/publicIPAddresses@2022-01-01' = {
  name: '${firewallName}-pip'
  location: location
  sku: { name: 'Standard' }
  properties: { publicIPAllocationMethod: 'Static' }
}

resource hubVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: { addressPrefixes: [ '10.0.0.0/16' ] }
    subnets: [
      { name: 'AzureFirewallSubnet', properties: { addressPrefix: '10.0.1.0/24' } }
    ]
  }
}

resource firewall 'Microsoft.Network/azureFirewalls@2022-01-01' = {
  name: firewallName
  location: location
  properties: {
    sku: { name: 'AZFW_VNet', tier: 'Standard' }
    ipConfigurations: [
      {
        name: 'fw-ipconfig'
        properties: {
          subnet: { id: hubVnet.properties.subnets[0].id }
          publicIPAddress: { id: publicIpFirewall.id }
        }
      }
    ]
  }
}

spokeNetwork.bicep

param location string = resourceGroup().location
param vnetName string = 'vnet-spoke-app1-prod-eastus-001'

resource spokeVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: { addressPrefixes: [ '10.10.0.0/16' ] }
    subnets: [
      { name: 'snet-workload', properties: { addressPrefix: '10.10.1.0/24' } }
    ]
  }
}

Architectural Deep Dive & Use Case

Deep Dive - Azure Virtual WAN (vWAN): For enterprises with a significant global footprint and many on-premises sites, vWAN is the strategic evolution of the hub-spoke model. It's a Microsoft-managed service that creates a global transit network, simplifying routing, providing built-in transitivity (spoke-to-spoke communication), and reducing operational overhead compared to managing a mesh of regional hubs yourself.
Use Case - Securing a Regulated Workload (PCI-DSS): A payment processing application is deployed into a dedicated spoke VNet. A route table forces all its traffic through the central Azure Firewall. The firewall policy is configured to only allow connections to known payment gateways, denying all other internet traffic. This provides the provable network isolation and traffic inspection required to meet PCI compliance.

Module 5: Centralized Operations & Shared Services

Why this matters: Centralizing services like logging and secrets management provides a single pane of glass for security and operations, reduces costs, and simplifies management across the entire estate.

Hands-on Lab: Deploying Centralized Logging

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create Mgmt RG	`az group create --name "rg-management-prod-eastus" -l "eastus"`	JSON output of new RG.	5m
2	Deploy Log Analytics	`az deployment group create -g "rg-management-prod-eastus" --template-file logAnalytics.bicep`	Successful deployment.	10m
3	Create Policy	Create a `DeployIfNotExists` policy to send diagnostics from all Key Vaults to this workspace.	Policy definition is created.	20m
4	Assign Policy	Assign the policy to the `lz-landingzones` management group, passing the workspace ID as a parameter.	Policy assignment is created. New Key Vaults will now automatically send logs.	15m

Bicep Artifact: `logAnalytics.bicep`

param location string = resourceGroup().location
param workspaceName string = 'log-analytics-prod-eastus'

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: workspaceName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
    retentionInDays: 90
  }
}

output workspaceId string = logAnalyticsWorkspace.id

Architectural Deep Dive & Use Case

Deep Dive - The Subscription Vending Machine: This is the pinnacle of platform automation. It's a workflow (e.g., Logic App, GitHub Actions) that allows application teams to request and receive a new, fully configured, and compliant subscription without manual intervention. The workflow creates the sub, moves it to the correct MG (inheriting policies), deploys a baseline spoke VNet peered to the hub, and assigns the team RBAC. This transforms the platform team from a gatekeeper into an enabler.
Use Case - Centralized Incident Response: A SOC analyst is alerted to a threat by Azure Defender for Cloud. Because all security signals (Firewall, NSG, Azure AD, Defender) are streamed to a central Log Analytics Workspace and ingested by Azure Sentinel, they can see the entire attack chain in a single incident view—from the initial risky sign-in to the network traffic and the final alert on the VM—drastically reducing investigation time from hours to minutes.

Module 6 & 7: IaC, CI/CD, and GitOps Automation

Why this matters: Applying DevOps principles to infrastructure allows for safe, repeatable, and auditable management of your landing zone. Every change is peer-reviewed and automatically validated before being deployed.

Conceptual Lab: Structuring Your Repository & Pipeline

Repository Structure: Organize your code into a logical structure.

/infra
├── /bicep
│   ├── /modules
│   │   ├── network.bicep
│   │   └── policy.bicep
│   └── main.bicep
└── /pipelines
    └── deploy-landingzone.yml

Terraform State Management: For Terraform, it is critical to use a remote backend to store the state file securely and to manage locking.

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "sttfstateprod"
    container_name       = "tfstate"
    key                  = "landingzone.tfstate"
  }
}

CI/CD Pipeline (GitHub Actions): The pipeline is the engine of GitOps.
- Trigger: On pull request to the main branch.
- CI (Validation) Job:
  - Check out the code.
  - Install Bicep/Terraform.
  - Run a linter to check code style.
  - Run az deployment mg what-if (for Bicep) or terraform plan (for Terraform) to preview the changes.
  - Post the plan results as a comment on the PR.
- CD (Deployment) Job:
  - Trigger: On merge to the main branch.
  - Requires a manual approval step in the pipeline.
  - Run az deployment mg create (for Bicep) or terraform apply (for Terraform) to deploy the changes.

GitHub Actions Artifact: `deploy-landingzone.yml`

name: 'Deploy Landing Zone'

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Bicep What-If
      if: github.event_name == 'pull_request'
      run: |
        az deployment tenant what-if \
          --location eastus \
          --template-file ./infra/bicep/main.bicep

  deploy:
    runs-on: ubuntu-latest
    needs: validate
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    environment: production
    steps:
    - uses: actions/checkout@v2
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Bicep Deploy
      run: |
        az deployment tenant create \
          --location eastus \
          --template-file ./infra/bicep/main.bicep

Module 8: Capstone Project

Objective: Deploy a complete, multi-subscription landing zone using IaC and a CI/CD pipeline, applying all concepts learned.

Statement of Work:

Governance: Create a management group hierarchy (Platform, Landing Zones, Prod, Non-Prod).
Networking: Deploy a hub-and-spoke topology. The hub must contain an Azure Firewall and a Log Analytics workspace. Deploy two spoke VNets (one prod, one non-prod) and peer them to the hub.
Policy: Author and assign a policy initiative that enforces the costCenter tag on all resource groups and requires diagnostic settings on all storage accounts.
Identity: Create a custom RBAC role for an application team that grants them contributor rights within their spoke VNet but denies them rights to modify the network peering or route tables.
Automation: All infrastructure must be defined in Bicep or Terraform. The deployment must be executed via a GitHub Actions pipeline that validates changes on a pull request and deploys on merge to main.

Acceptance Criteria & Scoring Rubric:

Criteria	Pass Condition	Score ( /100)
Management Groups	Correct hierarchy is deployed and visible.	15
Network	Hub with Firewall and Spokes are deployed. Peering is `Connected`. UDR on spokes forces traffic to Firewall.	30
Policy	Policy initiative is assigned. Attempting to create an untagged RG fails.	20
RBAC	Custom role is created and assigned. Test user can create a VM but cannot alter peering.	15
CI/CD	Pipeline runs `what-if`/`plan` on PR and successfully deploys on merge to `main`.	20
Total		100

Final Checklist & Production Readiness

Before going live, perform this final go/no-go check.

[ ] Governance: All required policies are assigned and showing a compliant state.
[ ] Identity: All administrative access is managed through PIM. No standing privileged accounts exist.
[ ] Networking: Firewall rules are locked down to least privilege. Hybrid connectivity (if any) is stable and redundant.
[ ] Operations: Centralized logging is collecting data from all critical resources. High-priority alerts (e.g., for security events) are configured and tested.
[ ] Costs: Budgets and cost alerts are configured for all subscriptions/management groups.
[ ] Automation: The CI/CD pipeline is the only way infrastructure changes are deployed. The main branch is protected, requiring PRs and reviews.
[ ] Validation: Automated health checks are in place to validate core landing zone functionality (e.g., DNS resolution, connectivity through the firewall).

DEV Community: Droid Ek

Configure AntiGravity

Docker Labs: From Beginner to Advanced on Azure

Step 3: Manage Swarm Services

N8N Installation And Configuration

Run this command to generate a key

Pull the latest image from Docker Hub

Recreate the container with the new image

Azure Landing Zone

1. Prerequisites: Tools, Accounts, and Setup

Lab 1.1: Tool Installation

Lab 1.2: Account and Permissions Verification

2. High-Level Architecture, Naming, and Tagging

Architecture Diagram (Hub-and-Spoke)

Naming Convention and Tagging Strategy

3. Curriculum: The Learning Path

Module 1: Governance Foundation with Management Groups

Module 2: Identity & Access Management (IAM)

Module 3: Policy-Driven Governance & Security Baselines

Module 4: Network Foundation (Hub-and-Spoke)

Module 5: Centralized Operations & Shared Services

Module 6: Infrastructure as Code (IaC) & Repository Structure

Module 7: CI/CD & GitOps Automation

Module 8: Capstone Project

Module 1: Governance Foundation with Management Groups

Hands-on Lab: Creating the Management Group Hierarchy

Bicep Artifact: managementGroups.bicep

Terraform Artifact: management_groups.tf

Architectural Deep Dive & Use Case

Module 2: Identity & Access Management (IAM)

Hands-on Lab: Implementing Least Privilege

Artifact: SpokeVnetContributor.json

Architectural Deep Dive & Use Cases

Module 3: Policy-Driven Governance & Security Baselines

Hands-on Lab: Creating and Assigning Policy

Azure Policy JSON Artifacts

Architectural Deep Dive & Use Case

Module 4: Network Foundation (Hub-and-Spoke)

Hands-on Lab: Building the Hub-and-Spoke Network

Bicep Artifacts

Architectural Deep Dive & Use Case

Module 5: Centralized Operations & Shared Services

Hands-on Lab: Deploying Centralized Logging

Bicep Artifact: logAnalytics.bicep

Architectural Deep Dive & Use Case

Module 6 & 7: IaC, CI/CD, and GitOps Automation

Conceptual Lab: Structuring Your Repository & Pipeline

GitHub Actions Artifact: deploy-landingzone.yml

Module 8: Capstone Project

Final Checklist & Production Readiness

Bicep Artifact: `managementGroups.bicep`

Terraform Artifact: `management_groups.tf`

Artifact: `SpokeVnetContributor.json`

Bicep Artifact: `logAnalytics.bicep`

GitHub Actions Artifact: `deploy-landingzone.yml`