Hands-on DevOps labs

Run and Verify an NGINX Container

Practice Docker port publishing, container inspection, HTTP verification, and cleanup with a safe local NGINX lab.

Source guide: Docker Commands Master Class

Outcomes

• Run a detached NGINX container with host port mapping.
• Verify HTTP reachability from the host.
• Inspect running container metadata.
• Clean up the lab safely.

Prerequisites

• Docker installed and running locally.
• Port 8080 available on the lab machine.
• A shell with docker and curl available.

Lab steps

1. Confirm Docker is available

   Start by proving the Docker daemon is reachable before creating resources.

   docker version

2. Run NGINX on host port 8080

   The -p flag maps host port 8080 to container port 80. --name gives the container a predictable cleanup target.

   docker run -d --name mcc-nginx-lab -p 8080:80 nginx:latest

3. Verify the container is running

   List the named container and confirm Docker reports it as running.

   docker ps --filter name=mcc-nginx-lab

4. Verify HTTP response

   Use curl to confirm traffic reaches NGINX through the published host port.

   curl -I http://127.0.0.1:8080

5. Inspect port bindings

   Inspect proves how Docker mapped the host port to the container port.

   docker inspect mcc-nginx-lab --format '{{json .NetworkSettings.Ports}}'

6. Clean up

   Remove the lab container so the host is left clean.

   docker rm -f mcc-nginx-lab

Validation

HTTP 200 or 3xx response headers from http://127.0.0.1:8080 before cleanup, followed by no remaining mcc-nginx-lab container.

curl -I http://127.0.0.1:8080

docker ps --filter name=mcc-nginx-lab

docker rm -f mcc-nginx-lab

Troubleshoot a Pod and Service Path

Practice read-only Kubernetes checks for pod status, service endpoints, DNS, and temporary curl validation.

Source guide: Kubernetes Master Class

Outcomes

• Read pod and service state.
• Verify endpoints and DNS.
• Use a disposable curl pod.
• Clean up the test pod.

Prerequisites

• kubectl configured for a lab cluster.
• A namespace with a service to inspect.
• Permission to create a temporary test pod.

Lab steps

1. Read-only namespace inventory

   Start with read-only discovery before creating any diagnostic pods.

   kubectl get pods,svc,endpoints -n default

2. Describe the target service

   Confirm selectors, ports, and endpoint wiring.

   kubectl describe svc SERVICE_NAME -n default

3. Check pod events

   Events usually reveal image, scheduling, probe, or permission failures.

   kubectl describe pod POD_NAME -n default

4. Run a disposable curl pod

   Create a temporary client and remove it automatically after the test.

   kubectl run curl-test --rm -it --image=curlimages/curl -- curl -I http://SERVICE_NAME.default.svc.cluster.local

5. Clean diagnostic state

   Delete any leftover debug pod if the interactive session was interrupted.

   kubectl delete pod curl-test -n default --ignore-not-found

Validation

Service endpoints exist and the temporary curl test reaches the service or provides a clear DNS/TCP failure.

kubectl get endpoints SERVICE_NAME -n default

kubectl delete pod curl-test -n default --ignore-not-found

Practice Terraform Plan, Apply, and Destroy Safely

Practice the Terraform lifecycle with formatting, validation, planning, controlled apply, output review, and cleanup.

Source guide: Terraform with Azure Master Class

Outcomes

• Initialize a Terraform workspace.
• Validate and plan before writes.
• Apply only after review.
• Destroy lab resources cleanly.

Prerequisites

• Terraform installed.
• A disposable lab configuration.
• Cloud credentials scoped to a sandbox.

Lab steps

1. Format and validate

   Keep this read-only before planning or applying.

   terraform fmt -check && terraform validate

2. Initialize providers

   Download provider plugins and prepare backend configuration.

   terraform init

3. Create a saved plan

   Review the plan file before any write action.

   terraform plan -out=tfplan

4. Apply after review

   This is the controlled write step; run only in a sandbox lab.

   terraform apply tfplan

5. Clean up with destroy

   Destroy lab resources to avoid drift and cost.

   terraform destroy -auto-approve

Validation

Terraform validate passes, plan is reviewed, apply succeeds in a sandbox, and destroy removes lab resources.

terraform validate

terraform plan -destroy

terraform destroy -auto-approve

Build an Azure Resource Inventory

Practice read-only Azure CLI inventory commands using account context, resource lists, Resource Graph, and tag checks.

Source guide: Azure CLI Commands Master Class

Outcomes

• Confirm Azure context.
• List resource groups and resources.
• Run Resource Graph inventory.
• Export read-only evidence.

Prerequisites

• Azure CLI installed.
• Reader access to a subscription.
• No production write permissions required.

Lab steps

1. Confirm account context

   This read-only check prevents running inventory against the wrong tenant or subscription.

   az account show --query '{name:name,id:id,tenant:tenantId,user:user.name}' -o table

2. List resource groups

   Discover top-level organization without changing anything.

   az group list --query '[].{name:name,location:location}' -o table

3. List resources

   Export an inventory of resources by group and type.

   az resource list --query '[].{name:name,type:type,rg:resourceGroup,location:location}' -o table

4. Run Resource Graph count

   Use Resource Graph for fast cross-resource summaries.

   az graph query -q "Resources | summarize count() by type | order by count_ desc" -o table

5. No write cleanup required

   This lab is intentionally read-only, so cleanup is limited to removing local exported files if created.

   rm -f azure-resource-inventory.json

Validation

Azure resource groups/resources are listed without creating, modifying, or deleting cloud resources.

az account show -o table

az graph query -q "Resources | summarize count() by type" -o table

Troubleshoot DNS and TCP Reachability

Practice a layered network troubleshooting flow from DNS to route, TCP, TLS, and packet capture.

Source guide: Networking Fundamentals Master Class

Outcomes

• Resolve DNS.
• Check route selection.
• Test TCP reachability.
• Inspect TLS metadata.
• Capture packets when needed.

Prerequisites

• Linux shell or equivalent tools.
• Permission to run tcpdump if packet capture is used.
• A safe target hostname such as example.com.

Lab steps

1. Resolve DNS

   Start by confirming the hostname resolves to an address.

   dig +short example.com

2. Check route selection

   Read the route that the host will use for the destination.

   ip route get 93.184.216.34

3. Test TCP port

   Verify that TCP 443 is reachable before debugging HTTP.

   nc -vz example.com 443

4. Verify HTTP and TLS

   curl shows HTTP status and TLS handshake details.

   curl -Iv https://example.com

5. Optional clean packet capture

   Capture only target traffic and stop the capture after the test.

   tcpdump -i any host example.com and port 443 -c 10

Validation

DNS resolves, route selection is visible, TCP 443 connects, and HTTPS returns response headers.

dig +short example.com

nc -vz example.com 443

curl -I https://example.com