Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 763 of 80211. Production Operations and ReliabilityFree lesson

Defining Infrastructure Through Declarative Configuration

Learn to translate manual infrastructure requirements into version-controlled declarative templates that define the desired state of your environment.

In this lesson, you will learn how to shift from manual environment management to a reliable, version-controlled model by defining your infrastructure as a "desired state."

Moving Beyond Imperative Commands

In the early days of operations, infrastructure was often managed imperatively—running commands like docker run or kubectl scale to make manual, one-off changes. This "snowflake" approach is dangerous; it leads to configuration drift, where the production environment eventually differs from what you intended.

Declarative configuration changes the paradigm. Instead of giving the system a list of commands to execute, you describe the end state you want. You tell the system: "I want three replicas of this service running on this specific network." The system (like Kubernetes) then continuously compares this declaration against the actual state and performs the necessary actions to close the gap.

The Power of Version Control

By defining your infrastructure in YAML files and storing them in Git, you gain three major advantages:

  1. Auditability: You have a clear history of who changed the infrastructure and why, linking changes directly to pull requests.
  2. Reproducibility: You can spin up an identical staging or development environment by simply applying your declarative templates to a different cluster.
  3. Consistency: Because the configuration is treated as code, you can run tests against these files before they ever reach production.

Consider this declarative definition for a Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: reliability-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: reliability
  template:
    metadata:
      labels:
        app: reliability
    spec:
      containers:
      - name: api
        image: service:v1.2.0

When you apply this file, the orchestrator ensures that three pods are always running. If a pod crashes, the orchestrator sees the deviation from your "desired state" and automatically replaces it. By managing this file in Git, you ensure that your production environment is always a direct reflection of your reviewed, versioned configuration.

Key Takeaway: Declarative configuration replaces manual, error-prone operations with version-controlled "desired state" templates, ensuring your infrastructure remains predictable, reproducible, and resilient.