Chapter 4 — Programming I
Lesson map
Lesson 04 published. Map, example, EX010.
flowchart TD
N0["Learning outcomes"]
N1["4.1 Why programming"]
N2["4.2 Core structures"]
N3["4.3 Functions and tests"]
N4["4.4 Reading files safely"]
N5["4.5 Stdlib only"]
N6["4.6 Clear output"]
N7["Reading exports"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX010"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["4.1 Why programming"]
N2["4.2 Core structures"]
N3["4.3 Functions and tests"]
N4["4.4 Reading files safely"]
N5["4.5 Stdlib only"]
N6["4.6 Clear output"]
N7["Reading exports"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]
[Learning outcomes]
|
v
[4.1 Why programming]
|
v
[4.2 Core structures]
|
v
[4.3 Functions and tests]
|
v
[4.4 Reading files safely]
|
v
[4.5 Stdlib only]
|
v
[4.6 Clear output]
|
v
[Reading exports]
|
v
[Worked example] --> [Exercise EX010]
Learning outcomes
You will (1) write small, safe Python programs that read configuration data; (2) use functions, loops and data structures; (3) test programs with synthetic inputs; (4) follow stdlib-only lab rules.
4.1 Why programming
Cloud and container configuration is data: YAML, JSON and key-value settings. Engineers who can read and check that data with programs can review hundreds of resources reliably.
A cluster with forty services may have hundreds of manifests and thousands of settings. Reading them by eye invites mistakes, especially late in a review. A short program can check every manifest for the same issues in seconds and produce a consistent list, which a human then examines with fresh attention. Rosa reviews each script's output.
4.2 Core structures
Dictionaries map names to settings, lists hold resources, sets hold permissions. Elena represents each pod's security settings as a dictionary, which makes comparisons simple.
Representing settings as dictionaries means a check like 'is privileged true?' is a single lookup. Lists of resources can be filtered and counted. Sets of permissions can be compared with set operations, such as finding permissions one role has that another lacks. Choosing the right structure keeps the code short and clear. Elena keeps each structure small.
4.3 Functions and tests
A function such as check_pod(spec) returns a list of issues. Small tests with synthetic specs confirm it flags privileged pods and passes compliant ones.
Returning a list of issues, rather than printing them, lets other code count, sort or filter the results. Synthetic specs give known answers: a pod with privileged set should produce exactly one issue, a compliant pod none. When the function is changed later, the tests show immediately if it still behaves correctly. Edge cases get their own tests.
4.4 Reading files safely
Programs only read configuration exports; they never call cloud APIs to change anything. Inputs are treated as untrusted: missing fields are reported, not assumed.
Reading exports avoids any chance of a script changing a live system by mistake, and it means the scripts need no cloud credentials. Treating inputs as untrusted guards against odd or malformed exports. A missing field reported as missing is honest; one silently treated as false could hide a real problem. Each script states which export it expects.
4.5 Stdlib only
Labs use only Python's standard library (json, csv, hashlib, statistics, re), so they run anywhere without installing packages, and their behaviour is easy to review.
Each external package is code from outside that may change, break or be compromised. The standard library covers parsing, hashing, statistics and pattern matching, which is enough for these labs. Students can run them on any machine with Python and review every line without needing to understand third-party code. The labs record the Python version used.
4.6 Clear output
Output names the resource, the issue and the reason, so non-programmers can act on it.
An output line such as 'ingest-7f9: privileged=true; privileged containers can access the host' tells a manager what is wrong and why it matters. Listing only a rule identifier would force them to look it up. Clear output also helps engineers fix issues quickly, because the resource and the reason are given together. Elena also sorts issues by severity, so the most serious appear first.
Reading exports
The pod export is a JSON list. Elena's program loops over each pod, then each container, and checks whether a resources.limits field exists with both cpu and memory. Pods are reported by namespace and name so owners can find them. She keeps the input file name and its hash in the output so the result can be traced to the exact export. Writing the program also teaches her how Kubernetes nests settings, which helps in later chapters on pod security.
Worked example
Elena writes a 40-line program that reads a JSON export of meterhub pods and lists those without resource limits. It finds 6 of 22 pods missing limits. A colleague reviews the code and adds a test for pods with limits on only one container.
Synthetic case. Exports and counts are synthetic.
Errors and limits
A program is only as good as its tests; check edge cases.
Exercises
- EX010 — Config as data. Why can programs help with configuration? Rubric: 3 = configuration is data; scale; 2 = partial; 1 = vague; 0 = none.
- EX011 — Stdlib reason. Why use only the standard library? Rubric: 3 = runs anywhere, easy to review; 2 = partial; 1 = vague; 0 = none.
- EX012 — Limits program. What did Elena's program find? Rubric: 3 = 6/22 pods missing limits; 2 = partial; 1 = vague; 0 = none.
Synthesis
Small, tested programs make configuration review reliable.
Continue studying — chapter 04 of 50
← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →