Unit 4: Core concepts of Continuous Delivery (CD), Deployment & Automation - Subjective Questions

Continuous Delivery (CD) is a software development practice where code changes are automatically built, tested, and prepared for release to production. The software is always in a deployable state, but the actual deployment to production requires a manual approval step.

Continuous Deployment goes one step further — every change that passes all stages of the automated pipeline is automatically deployed to production without any human intervention.

Key Differences:

Summary:

• Both rely on Continuous Integration as a foundation.
• Continuous Delivery ensures software can be released anytime.
• Continuous Deployment ensures software is released automatically.
• Continuous Deployment requires greater confidence in automated testing and monitoring.

A Continuous Delivery (CD) pipeline is an automated sequence of steps that takes code from a source repository through to a production-ready release. It ensures reliability, repeatability, and speed in software delivery.

Typical Stages of a CD Pipeline:

1. Source Stage — Triggered by a commit to version control (e.g., Git).
2. Build Stage — Source code is compiled and dependencies are resolved; artifacts are created.
3. Test Stage — Automated unit, integration, and functional tests are executed.
4. Staging/Release Stage — Artifacts are deployed to a staging environment mimicking production.
5. Approval Stage (for CD) — Manual gate before production deployment.
6. Deploy Stage — Application is released to production.
7. Monitoring Stage — Post-deployment health checks and monitoring.

Benefits:

• Faster feedback on code quality.
• Reduced deployment risk through automation.
• Consistency across environments.
• Improved collaboration between development and operations teams.

Jenkins is an open-source automation server whose functionality is extended through plugins. Key plugins used for Continuous Delivery include:

• Pipeline Plugin — Enables defining the entire build/deploy workflow as code using a Jenkinsfile (Groovy-based DSL).
• Git Plugin — Integrates Jenkins with Git repositories to trigger builds on commits.
• Docker Plugin — Allows building and running Docker containers as part of the pipeline.
• Blue Ocean Plugin — Provides a modern, visual UI for creating and visualizing pipelines.
• Credentials Plugin — Securely stores and manages secrets like passwords and API keys.
• Kubernetes Plugin — Dynamically provisions build agents on a Kubernetes cluster.
• Slack/Email Notification Plugin — Sends build and deployment status alerts.
• Artifactory/Nexus Plugin — Manages and stores build artifacts.

Importance:
These plugins collectively allow Jenkins to orchestrate the complete CD process — from code checkout, building, testing, and packaging to deployment and notification.

Rolling Deployment is a deployment strategy where the new version of an application is gradually rolled out by replacing instances of the old version one batch at a time, rather than all at once.

How it Works:

• The system runs multiple instances (servers/pods).
• Instances are updated incrementally in batches.
• Traffic continues to be served by the remaining old instances during the update.
• The process continues until all instances run the new version.

Advantages:

• No downtime — service remains available throughout.
• Resource efficient — no need for a full duplicate environment.
• Gradual rollout reduces the blast radius of errors.

Disadvantages:

• Slow rollout for large systems.
• Rollback is complex — reverting requires re-deploying old versions batch by batch.
• Version mismatch — old and new versions run simultaneously, which can cause compatibility issues.

Blue-Green Deployment is a strategy that uses two identical production environments called Blue and Green to achieve zero-downtime releases.

How it Works:

• Blue environment runs the current live version serving all traffic.
• Green environment is set up with the new version.
• After testing the Green environment, the router/load balancer switches traffic from Blue to Green.
• Green becomes live; Blue is kept idle as a fallback.

Conceptual Flow:

Users --> Load Balancer --> [Blue - v1 (Live)]
[Green - v2 (Idle, being tested)]

After switch:
Users --> Load Balancer --> [Green - v2 (Live)]
[Blue - v1 (Idle, fallback)]

Advantages:

• Instant rollback — switch traffic back to Blue if issues arise.
• Zero downtime during release.
• Full testing of the new version before going live.

Disadvantages:

• High cost — requires double the infrastructure.
• Database synchronization between environments can be challenging.

Canary Deployment is a strategy where a new version of the application is released to a small subset of users first, before rolling it out to the entire user base.

Origin of the Name:
The term comes from the historical practice of using canary birds in coal mines to detect toxic gases. Similarly, a small group of users acts as an early-warning system for detecting problems in the new release.

How it Works:

1. Deploy the new version to a small percentage of servers/users (e.g., 5%).
2. Monitor key metrics (errors, latency, performance).
3. If stable, gradually increase the traffic to the new version (e.g., 25%, 50%, 100%).
4. If issues occur, roll back immediately with minimal impact.

Advantages:

• Low risk — issues affect only a small group.
• Real-world testing with actual production traffic.
• Gradual and controlled rollout.

Disadvantages:

• Complex monitoring and traffic routing required.
• Slower full rollout compared to other strategies.

The three major deployment strategies differ significantly in their approach and trade-offs:

Summary:

• Rolling is cost-efficient but has slow rollbacks.
• Blue-Green offers instant rollback but doubles infrastructure cost.
• Canary minimizes risk with real-user testing but is the most complex to implement.

The choice depends on budget, risk tolerance, and infrastructure capabilities.

Configuration Management (CM) is the process of systematically handling changes to a system's configuration in a way that maintains consistency, integrity, and reliability across environments.

Key Objectives:

• Maintain a known, consistent state of infrastructure.
• Automate the provisioning and configuration of servers.
• Enable version control for infrastructure settings.

Importance in DevOps:

• Consistency — Eliminates the 'works on my machine' problem by ensuring identical environments.
• Automation — Reduces manual, error-prone configuration tasks.
• Scalability — Easily configure hundreds of servers simultaneously.
• Reproducibility — Environments can be recreated reliably.
• Auditability — Changes are tracked and version-controlled.

Popular Tools:

• Ansible — Agentless, uses YAML playbooks.
• Puppet — Uses declarative language and a master-agent model.
• Chef — Uses Ruby-based recipes.
• Terraform — Focuses on infrastructure provisioning (IaC).

While all three tools support infrastructure automation, they differ in purpose and architecture:

Summary:

• Terraform excels at provisioning infrastructure (creating servers, networks).
• Puppet is strong at maintaining desired state over time.
• Ansible is simple, agentless, and good for both configuration and orchestration tasks.

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure through machine-readable configuration files rather than manual processes. This allows infrastructure to be versioned, tested, and reused like application code.

Terraform is a leading IaC tool developed by HashiCorp that uses a declarative language called HCL (HashiCorp Configuration Language).

Key Terraform Concepts:

• Providers — Plugins for cloud platforms (AWS, Azure, GCP).
• Resources — Infrastructure components (VMs, networks, storage).
• State File — Tracks the current state of managed infrastructure.
• Plan & Apply — Preview (terraform plan) and execute (terraform apply) changes.

Basic Terraform Workflow:
hcl
provider "aws" {
region = "us-east-1"
}

resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t2.micro"
}

Command Workflow:

1. terraform init — Initialize providers.
2. terraform plan — Preview changes.
3. terraform apply — Provision resources.
4. terraform destroy — Tear down infrastructure.

Benefits: Repeatability, versioning, consistency, and automation of infrastructure provisioning.

Ansible is an open-source, agentless automation tool used for configuration management, application deployment, and orchestration.

Ansible Architecture Components:

• Control Node — The machine where Ansible is installed and from which commands are run.
• Managed Nodes — Target machines configured by Ansible (no agent required).
• Inventory — A file listing the managed hosts (IPs/hostnames).
• Modules — Units of code that perform tasks (e.g., install packages).
• Playbooks — YAML files defining automation tasks.
• SSH — Communication protocol used to connect to managed nodes.

How a Playbook Works:
A Playbook is a YAML file containing one or more plays, each mapping a group of hosts to a set of tasks.

Example Playbook:
yaml

• name: Install and start Nginx
  hosts: webservers
  become: yes
  tasks:
  • name: Install nginx
    apt:
    name: nginx
    state: present
  • name: Start nginx service
    service:
    name: nginx
    state: started

Execution: ansible-playbook playbook.yml connects to hosts via SSH and executes tasks sequentially to reach the desired state.

Containerization is a lightweight form of virtualization that packages an application along with its dependencies, libraries, and configuration into a single unit called a container, which runs consistently across environments.

Key Differences: Containers vs Virtual Machines (VMs):

Advantages of Containerization:

• Consistency across development, testing, and production.
• Fast startup and low overhead.
• Scalability and efficient resource usage.
• Portability — 'build once, run anywhere.'

Popular Platform: Docker is the most widely used containerization platform.

Docker follows a client-server architecture that enables building, shipping, and running containers.

Main Components:

1. Docker Client — The command-line interface (docker) users interact with. It sends commands to the Docker daemon.

2. Docker Daemon (dockerd) — The background service running on the host that manages Docker objects (images, containers, networks, volumes). It listens for API requests.

3. Docker Host — The physical/virtual machine running the daemon and containers.

4. Docker Images — Read-only templates used to create containers.

5. Docker Containers — Runnable instances of images.

6. Docker Registry — A storage/distribution system for images (e.g., Docker Hub).

Architecture Flow:

    Images               Containers               Registry

Workflow:

• The client issues commands (docker build, docker run).
• The daemon executes them, pulling images from the registry if needed and running containers.

This architecture allows efficient, portable, and isolated application execution.

The Docker workflow describes the lifecycle of taking application code and running it as a container.

Steps in the Docker Workflow:

1. Write Application Code — Develop the application to be containerized.

2. Create a Dockerfile — Define instructions to build the image (base image, dependencies, commands).

3. Build the Image — Run docker build -t myapp . to create a Docker image from the Dockerfile.

4. Store/Push the Image — Optionally push the image to a registry using docker push (e.g., Docker Hub).

5. Pull the Image — On the target machine, pull the image using docker pull.

6. Run the Container — Use docker run -d -p 8080:80 myapp to create and start a running container.

7. Manage Containers — Use commands like docker ps, docker stop, and docker rm to manage the container lifecycle.

Summary Flow:

Code --> Dockerfile --> Image (build) --> Registry (push) --> Container (run)

This workflow ensures consistency and portability — the same image runs identically everywhere.

A Dockerfile is a text file containing a set of instructions used by Docker to automatically build an image. Each instruction creates a layer in the image.

Commonly Used Instructions:

• FROM — Specifies the base image.
  dockerfile
  FROM node:18-alpine

• WORKDIR — Sets the working directory inside the container.
  dockerfile
  WORKDIR /app

• COPY — Copies files from host to the image.
  dockerfile
  COPY . .

• RUN — Executes a command during image build.
  dockerfile
  RUN npm install

• EXPOSE — Documents the port the container listens on.
  dockerfile
  EXPOSE 3000

• ENV — Sets environment variables.
  dockerfile
  ENV NODE_ENV=production

• CMD — Default command to run when the container starts.
  dockerfile
  CMD ["node", "app.js"]

• ENTRYPOINT — Configures the container to run as an executable.

Complete Example:
dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]

Building a Docker image is the process of executing the instructions in a Dockerfile to create a reusable, read-only template.

Build Command:
bash
docker build -t myapp:1.0 .

• -t assigns a name and tag.
• . specifies the build context (current directory).

Image Layers:

• Each instruction in a Dockerfile (FROM, RUN, COPY, etc.) creates a layer.
• Layers are stacked on top of each other to form the final image.
• Layers are read-only; a writable layer is added when a container runs.

Layer Caching:

• Docker caches each layer during the build.
• If a layer hasn't changed, Docker reuses the cached version instead of rebuilding it, speeding up builds.
• If an instruction changes, that layer and all subsequent layers are rebuilt.

Best Practices for Efficient Builds:

• Place frequently changing instructions (like COPY . .) later in the Dockerfile.
• Copy dependency files (e.g., package.json) before source code to leverage caching.
• Use multi-stage builds to reduce final image size.
• Use a .dockerignore file to exclude unnecessary files.

A Docker container is a runnable instance of an image. The docker run command creates and starts a container.

Basic Syntax:
bash
docker run [OPTIONS] IMAGE [COMMAND]

Key docker run Options:

• -d — Run in detached mode (background).
  bash
  docker run -d myapp

• -p — Map host port to container port.
  bash
  docker run -p 8080:80 nginx

• --name — Assign a custom name to the container.
  bash
  docker run --name webserver nginx

• -e — Set environment variables.
  bash
  docker run -e ENV=prod myapp

• -v — Mount a volume for persistent storage.
  bash
  docker run -v /host/data:/app/data myapp

• -it — Run interactively with a terminal.

Container Management Commands:

• docker ps — List running containers.
• docker stop <id> — Stop a container.
• docker start <id> — Start a stopped container.
• docker rm <id> — Remove a container.
• docker logs <id> — View container logs.

These commands provide full control over the container lifecycle.

Continuous Delivery (CD) and containerization (Docker) complement each other to create fast, reliable, and portable deployment pipelines.

Integration Points:

1. Consistent Artifacts:

   • Docker packages the application into an image — a single, immutable artifact.
   • The same image moves through all stages (dev → test → prod), eliminating environment inconsistencies.

2. Pipeline Automation:

   • In a CD pipeline (e.g., Jenkins), a stage builds the Docker image (docker build).
   • The image is tested and then pushed to a registry (docker push).
   • Deployment stages pull and run the image on target environments.

3. Faster Deployments:

   • Containers start in seconds, enabling rapid rollouts and rollbacks.

4. Deployment Strategies:

   • Containers make Blue-Green, Rolling, and Canary deployments easier by spinning up/down instances quickly.

5. Scalability:

   • Combined with orchestrators like Kubernetes, containers scale automatically.

Typical CD + Docker Flow:

Commit --> Jenkins Build --> docker build --> Test --> docker push (Registry)
--> Deploy (docker run / Kubernetes) --> Monitor

Benefit: This integration ensures repeatable, portable, and automated releases with minimal risk.

Idempotency is a property where performing the same operation multiple times produces the same result as performing it once. In configuration management, applying a configuration repeatedly does not cause unintended changes if the system is already in the desired state.

Example:
If a task says 'ensure Nginx is installed,' running it multiple times:

• First run: Installs Nginx.
• Subsequent runs: Detects Nginx is already installed and makes no changes.

Why Idempotency is Important:

• Safe Re-runs — Playbooks/scripts can be run repeatedly without side effects.
• Consistency — Ensures systems always converge to the desired state.
• Predictability — Eliminates unexpected duplicate actions.
• Reliability — Reduces configuration drift over time.

In Tools:

• Ansible — Modules are designed to be idempotent; they check current state before acting.
• Terraform — Uses a state file to compare desired vs current infrastructure and only applies necessary changes.

Summary: Idempotency guarantees that infrastructure remains stable and predictable, which is essential for automation at scale.

A Docker Image and a Docker Container are two fundamental but distinct concepts in Docker.

Docker Image:

• A read-only template containing the application code, libraries, dependencies, and configuration.
• Built from a Dockerfile.
• Immutable and can be stored in registries.
• Analogy: A class in object-oriented programming or a blueprint.

Docker Container:

• A running instance of an image.
• Has a writable layer on top of the image layers.
• Ephemeral — can be started, stopped, and deleted.
• Analogy: An object created from a class.

Comparison Table:

Relationship:

• An image is used to create a container (docker run).
• Multiple containers can be created from a single image.
• A container adds a writable layer over the read-only image layers.