Containers, and the wiring between them

A container gives you a reproducible process with its dependencies, an explicit network surface and an explicit filesystem. It does not give you persistence, secrets management, restart behaviour or backups. Those are things you configure, and a deployment that skipped them will look fine until the machine restarts.

The three that matter on day one: named volumes for anything that must survive the container, a restart policy so services come back by themselves, and secrets supplied by the environment rather than baked into an image or committed to a file.

Bring the whole stack up from a single compose file that you keep under version control alongside the customer’s configuration. The value is not elegance: it is that the deployment becomes a document, and a document can be reviewed, handed over and rebuilt after a failure by somebody who was not there.

This is also the first artefact of the handover you will do in module 05. Write it as though the person reading it does not have you available.

Almost every deployment ends up needing scheduled or event-driven work: pull new files nightly, notify a channel when an extraction needs review, write a result into the system of record. Putting that logic inside the application makes the application the customer’s problem forever.

A workflow automation service is the standard place for it. Its jobs are visible, re-runnable and editable by someone who is not you — which is the property that matters when you have left. Note where each connector sends data, because an outbound edge into a hosted tenancy changes the data-boundary verdict for the whole deployment.