> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Docker and Devops
> Explains how Docker uses Dockerfiles, images, and containers to bridge development and operations, improving reproducibility, deployments, continuous integration, and collaboration while reducing environment drift.
Traditionally, development and operations were separate responsibilities. Developers built the application and handed it to operations to deploy and manage in production. This division introduced friction: operations had to prepare hosts (install runtimes, configure dependencies, set environment variables, open ports, and ensure correct permissions) without always having the same environment the developers used. Reproducing developer environments and diagnosing failures across mismatched setups became time-consuming and error-prone.
Docker changes that workflow by encapsulating build and runtime requirements in a single, reproducible artifact: a Docker image built from a Dockerfile. This approach reduces environment drift, improves reproducibility, and makes collaboration between development and operations more efficient.
## Legacy workflow vs. Docker-enabled workflow
| Concern | Legacy (Dev / Ops handoff) | Docker-enabled |
| -: | - | - |
| Environment setup | Ops configures host and runtime manually | Build requirements captured in a `Dockerfile` and baked into an image |
| Reproducibility | Varies between machines; “works on my machine” problems common | Image is immutable and portable — same behavior across hosts |
| Drift and configuration errors | High — manual steps differ by host | Low — image contains app + runtime + config |
| Collaboration | Frequent back-and-forth to diagnose environment issues | Clear contract: the image is the artifact both teams use |
| Deployment prerequisites | Ops installs dependencies on hosts | Only a compatible container runtime (e.g., Docker Engine) is required |
## What is a Dockerfile, image, and container?
* Dockerfile: A plain-text file with step-by-step instructions to assemble an image (base OS, libraries, language runtimes, app code, environment variables, and startup commands). See Dockerfile reference: [https://docs.docker.com/engine/reference/builder/](https://docs.docker.com/engine/reference/builder/)
* Image: An immutable, versioned snapshot built from a Dockerfile. An image contains everything needed to run the application.
* Container: A runtime instance of an image. Containers run on any host with a compatible container runtime (e.g., the Docker Engine).
## Example: Minimal Dockerfile
Use this example as a starting point. It captures build steps and runtime requirements in a deterministic, reproducible way.
```Dockerfile theme={null}
# Use an official Node.js runtime as a parent image
FROM node:18-alpine
# Set working directory and copy package manifest for dependency install
WORKDIR /app
COPY package.json package-lock.json ./
# Install dependencies
RUN npm ci --only=production
# Copy application source code
COPY . .
# Set environment variables and expose port
ENV NODE_ENV=production
EXPOSE 3000
# Default command to run the application
CMD ["node", "server.js"]
```
Build and run:
```bash theme={null}
docker build -t my-app:1.0 .
docker run -p 3000:3000 my-app:1.0
```
## How Docker improves DevOps practices
* Reproducibility: Developers define the exact environment in a Dockerfile, producing consistent images for all environments.
* Reduced configuration drift: Hosts no longer require manual runtime installs or ad-hoc configuration to match developers’ setups.
* Faster troubleshooting: When an issue appears, developers and ops can run the exact same image to reproduce and diagnose problems.
* CI/CD integration: Images can be built, scanned, and published as immutable artifacts in CI pipelines, simplifying rollbacks and deployments.
* Portability: Images run wherever a compatible container runtime exists — local machines, on-prem servers, and cloud platforms.
Capture application behavior and runtime dependencies in the `Dockerfile`. This single source of truth makes builds reproducible and reduces the “works on my machine” problem.
## Practical collaboration flow
1. Developer writes code and defines build/runtime in a `Dockerfile`.
2. Developer builds and tests the image locally.
3. CI pipeline builds the image, runs tests, scans for vulnerabilities, and publishes the image to a registry.
4. Operations pulls the same image and runs it on production hosts or orchestrators (Kubernetes, ECS, etc.).
5. Monitoring, logging, and deployment automation operate on consistent images, simplifying incident response and rollbacks.
## Considerations and best practices
* Keep images small and focused to reduce attack surface and speed up CI/CD pipelines.
* Use multi-stage builds to separate build-time and runtime dependencies.
* Tag images with semantic versions and use immutable tags in production deployments.
* Scan images for vulnerabilities and enforce security policies in CI.
* Use environment variables and secrets management (not baked into images) for runtime configuration.
Docker improves reproducibility and portability but does not replace essential practices like secure configuration management, CI/CD, monitoring, and incident response. Treat container images as one part of a secure, well-governed deployment pipeline.
## Links and references
* Docker: [https://www.docker.com/](https://www.docker.com/)
* Dockerfile reference: [https://docs.docker.com/engine/reference/builder/](https://docs.docker.com/engine/reference/builder/)
* Docker Engine: [https://docs.docker.com/engine/](https://docs.docker.com/engine/)
* Kubernetes documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/)
This is it for now.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.