Running a container is straightforward; repeatedly running several containers with the right settings is harder. Configuration records the state you want in a file instead of leaving it in remembered commands or one-off changes to a machine. For a Kubernetes workload, you describe how it should run, then Kubernetes places and manages its Pods. section 1.2 section 1.2.1
The file and the tool depend on where you are running the application:
- For local container testing, a Docker Compose file can preserve the build command, startup command, and port mapping. You can bring the group up again without reconstructing a long Docker command. section 2.3
- For Kubernetes, configuration files describe objects such as Deployments and Services. Apply the files to create the objects; edit and reapply them to request a change. section 3.3 section 3.4.3
Listing 2.16 Chapter02/2.3_Compose/docker-compose.yaml
services:
web:
build: ../timeserver #1
command: python3 server.py #2
ports: #3
- "8080:80" #3
This Compose file keeps a web container’s build location, startup command, and port mapping together for local testing. section 2.3
This is the declarative approach: state the desired result rather than issuing a separate command for every operation. Imperative commands can create a Deployment, expose a Service, or change an image, but reproducing that sequence elsewhere means retaining every command. With files, the same configuration can be applied to a local cluster and later to production, with adjustments where needed. A service update can be expressed as a configuration change while Kubernetes handles the rollout. section 3.3 section 3.4.3 section 1.2
Keep the files as the place where changes are made first. They make it possible to recreate deleted objects and to deploy similar workloads into separate namespaces, such as staging and production. Treating configuration like code also makes version control and reviews possible. Deleting Kubernetes objects does not necessarily remove the cost of the cluster itself. section 3.2.8 section 11.0 section 11.1.1
If someone changes a workload directly with a command, the files may no longer reflect what is running. You can retrieve an object's YAML with kubectl, but clean it before reusing it: exported status and generated metadata describe the deployed object, not the settings you normally want to maintain. An embedded namespace can also send an update to the wrong environment. section 11.1.2
