Linux Roles Across Development, CI/CD, Cloud, and Production

1. Linux across the delivery system

flowchart TD
  DEV["Development environment"] --> SCM["Source and review"]
  SCM --> CI["Linux CI runner"]
  CI --> ART["Artifact or image"]
  ART --> CD["Deployment automation"]
  CD --> PROD["Linux production runtime"]
  PROD --> OBS["Logs, metrics, traces, and alerts"]
  OBS --> OPS["Operations and incident response"]
  OPS -. feedback .-> DEV

The specific distribution or hosting model may change, but the same operating concepts recur: processes, users, files, permissions, network sockets, resource limits, packages, logs, services, and automation.

2. Development environments

Developer convenience should not silently become production configuration. Local shortcuts—broad permissions, embedded credentials, disabled TLS checks—must not cross the delivery boundary.

3. CI runners and build agents

A CI runner is an automation identity executing untrusted or semi-trusted repository instructions. Its Linux host must manage workspace isolation, credentials, caches, processes, network access, and cleanup.

4. Containers, orchestration, and cloud hosts

Containers rely on Linux namespaces, cgroups, capabilities, seccomp, filesystems, and networking. Kubernetes schedules containers, but node health still depends on the host kernel, runtime, storage, DNS, time synchronization, certificates, and system services.

5. Production services and runtime state

In production, configuration files describe intended state, but the live host reveals actual state. Operators must compare both.

• Which process is listening on a port?
• Which user and groups own the process?
• Which executable and configuration file were loaded?
• What environment variables, limits, capabilities, and cgroup constraints apply?
• Which filesystems and volumes are mounted?
• What changed since the last healthy deployment?

# Examples of live-state inspection
systemctl --failed
ps -eo user,pid,ppid,stat,etimes,comm --sort=-etimes | head
ss -lntup
findmnt
free -h
df -hT
journalctl -p warning -b --no-pager | tail -n 50

Some commands require privileges to display every process or socket owner. Absence of evidence under an unprivileged account does not always prove absence of activity.

6. Observability, security, and compliance agents

7. Environment parity without pretending environments are identical

Development, CI, staging, and production should share versioned application dependencies and deployment logic. They should not necessarily share secrets, scale, network exposure, data, or privilege.

8. Linux as the incident-response control surface

When a deployment fails, start with evidence rather than random restarts:

9. Capstone lab: create a Linux responsibility map

Build a report that connects the current machine to DevOps stages. The commands are read-only.

lab="$HOME/devops-academy/linux/chapter01/lesson05"
mkdir -p "$lab"
cd "$lab"

{
  printf '=== host identity ===\n'
  hostname
  uname -srmo
  cat /etc/os-release

  printf '\n=== development and build tools ===\n'
  for tool in git bash make gcc python3 node docker kubectl; do
    if command -v "$tool" >/dev/null 2>&1; then
      printf '%-10s %s\n' "$tool" "$(command -v "$tool")"
    fi
  done

  printf '\n=== service and runtime state ===\n'
  ps -p 1 -o pid,comm,args
  systemctl --failed --no-pager 2>/dev/null || true

  printf '\n=== listening TCP sockets ===\n'
  ss -lnt 2>/dev/null || true

  printf '\n=== capacity ===\n'
  free -h
  df -hT

  printf '\n=== recent warnings ===\n'
  journalctl -p warning -b -n 20 --no-pager 2>/dev/null || true
} > devops-role-report.txt

less devops-role-report.txt

10. Common operating mistakes

11. Knowledge check

12. Chapter summary

Linux forms the operational substrate across development, CI/CD, cloud, containers, production, observability, security, and incident response. Chapter 1 established the mental model: kernel and user space, distribution lifecycle, ecosystem licensing, and Linux responsibilities across delivery.

13. Further reading

• Linux Foundation and kernel documentation — Linux architecture and production operations.
• systemd documentation — services, journal, resource control, and host lifecycle.
• Open Container Initiative specifications — runtime and image contracts.
• Kubernetes documentation — node architecture, workloads, logging, and cluster operations.
• Site Reliability Engineering resources — monitoring, incident response, change management, and reliability practices.