The aurora-api:2.0.0 image is correct, but you are the one building it, on your laptop, with your cache and your git status. This lesson takes the human out of the loop: every git push fires a chain that runs the tests, builds for two architectures, scans, signs, publishes and deploys, without anybody having to remember a thing.

1. CI, delivery and deployment: three concepts, two acronyms
2. Why Docker fits: the artifact is the image
3. Anatomy of the pipeline
4. Testing inside containers with Compose
5. The Dockerfile's tests stage and --target
6. Aurora Libros' pipeline: triggers and permissions
7. Automatic tagging with metadata-action
8. Multi-architecture builds with the gha cache
9. Trivy scanning that breaks the build
10. Keyless signing, SBOM and provenance
11. The equivalent pipeline in GitLab CI
12. Docker-in-Docker versus the mounted socket
13. Credential management: OIDC and ephemeral tokens
14. Automatic versioning from Git tags
15. Automated deployment

Warning. A CI runner with access to your registry and your servers is a critical piece of infrastructure: whoever controls the pipeline can publish and deploy anything. Runner permissions, token scopes and SSH access to the environments must be defined and reviewed with the infrastructure and security officer in your organization.

The last two share the abbreviation CD and get confused constantly. The practical difference is a button: with delivery, the image is ready and waiting for an "approve"; with deployment, every merge to main that clears all the gates reaches production on its own. Aurora Libros will do delivery to production and deployment to staging: it is the most common combination and the most sensible one for as long as test coverage is not good enough to trust blindly.

Before containers, the CI artifact was a .jar, a .zip or a tarball, and the environment it ran in was prepared separately: that is where "it works on my machine" came from, because the artifact traveled and the environment did not. With Docker, the artifact includes its environment, and that unlocks three properties that make a pipeline trustworthy:

• Immutability. The digest identifies an exact content: sha256:a1b2... is the same thing in CI, in staging and in production, forever.
• Promotion without rebuilding. You promote by retagging. Rebuilding for production means deploying an artifact nobody has tested.
• Environment parity. The container that passed the tests is, byte for byte, the one serving customers.

The rule that sums up the module: build once, deploy many times. One commit produces one image, that image has a digest, and that digest is what gets promoted to staging and to production. If your pipeline has one docker build per environment, it has a design flaw.

The order is not arbitrary: whatever is cheap and whatever fails most, first. A 20-second lint that catches the error saves you spending four minutes on a multi-architecture build. It is the same principle as the layer cache from 02-02, applied to the pipeline.

Testing against a real database rather than a mock is what separates a useful test from one that green-lights broken code. With Compose it is trivial and, more importantly, identical on your laptop and on the runner.

Those two flags are the heart of the matter, and they are worth understanding properly:

• --abort-on-container-exit stops the whole stack as soon as one container finishes. Without it, the tests end and PostgreSQL keeps running: the command never returns and the job hangs until the timeout.
• --exit-code-from tests makes docker compose's exit code the test container's, not that of the Compose operation. Without it, the command returns 0 even when the tests fail, and the pipeline goes green over broken code. This is, by a wide margin, the most frequent mistake in this lesson.

The tmpfs over PostgreSQL's data directory deserves a note: in tests you do not need durability, so putting the data in RAM removes disk writes and usually cuts the suite by somewhere between 30 % and 50 %. Never, ever in production.

The Dockerfile from 06-01 already had the stage ready. Running it on its own is a --target:

Aurora Libros uses the first two together: compose.tests.yaml builds with target: tests. And there is a far from minor cache benefit: the deps stage that installs node_modules is shared by the tests and the final image, so the production build reuses those layers and reinstalls nothing.

About the triggers: pull requests run the tests and build without publishing, because a branch belonging to nobody should not be able to push an image to the registry. Pushes to main publish with the edge tag and deploy to staging. Tags matching v*.*.* produce the publishable SemVer version.

This action replaces the sed and git describe script everybody ends up writing. From the v2.0.0 tag it works out the four moving tags on its own and additionally generates the OCI labels from 06-01 with the date, the commit and the repository URL, without you having to pass them as --build-arg.

type=sha is the most important one on the list even though it looks like the most boring: every build produces a unique, unrepeatable tag, so you can always refer to one specific build even after latest and 2.0 have moved ten times.

The two cache parameters are the difference between a usable pipeline and an unbearable one. Without them, every run starts with an empty cache —the runner is a brand-new machine— and npm ci runs in full twice, once per architecture. With type=gha, BuildKit stores the layers in the GitHub Actions cache and pulls them back on the next build.

mode=max also stores the intermediate layers of the earlier stages —deps and deps-dev included—, so it takes up more cache but hits far more often. The scope keeps two different workflows from stepping on each other's entries. And one operational warning: the GitHub Actions cache has a 10 GB limit per repository and evicts by age, so a mode=max across many branches can evict entries you still need.

The scan runs by digest, not by tag: that guarantees you are analyzing exactly the image you have just built and not some other one somebody published under the same name in the meantime.

The two-step structure is deliberate. The first collects everything (criticals and highs) and uploads it to the security tab for visibility; the second, far stricter, is the gate: it only breaks on criticals with a patch available. That ignore-unfixed is not a relaxation, it is pragmatism: blocking deployments over a CVE nobody has fixed yet does not improve your security, it only stops you from shipping the fix for a different bug. What threshold is acceptable for your organization is decided by its security policy, not by this course.

The keyless signing from 05-03 fits here like a glove. There is no private key to store, rotate or leak: Cosign asks GitHub for a short-lived OIDC token, gets an ephemeral certificate from Fulcio and records the signature in the public Rekor transparency log. The certificate expires within minutes; what remains is the proof, verifiable by anybody:

Look at what that identity actually verifies: it does not say "it is signed", it says "that workflow, from that repository, built it". An image signed from somebody's laptop does not pass that check. Together with the provenance: mode=max and the sbom: true from the previous step, you have the three pieces of the supply chain: what is inside it (SBOM), who built it and how (provenance), and that nobody has touched it since (the signature).

The cache is the most visible practical difference: GitHub has a backend of its own, whereas on GitLab the usual approach is to store the cache in the registry itself with type=registry, which has the bonus of working with any provider.

To build images, the runner needs access to a daemon. There are three ways, and they are not equivalent in terms of security.

The first two rows say the same thing in different words: any job can take control of the runner. With DinD, because the privileged container has every capability. With the mounted socket, because whoever talks to the daemon can run docker run -v /:/host --privileged and read or modify the host's entire disk, including the credentials of every other pipeline.

In a private repository with trusted collaborators, either one is common practice. The moment you accept pull requests from outsiders, the mounted socket is unacceptable: a malicious PR that modifies the workflow walks off with your secrets. The alternatives are single-use ephemeral runners (what GitHub's hosted runners do) or building without a daemon using rootless BuildKit.

GITHUB_TOKEN is not a secret you created: GitHub generates it when the run starts, with exactly the permissions in the permissions: block, and invalidates it when it finishes. Stolen half an hour later, it is worth nothing.

The rule that is never broken is not printing a secret. Providers mask known values and show ***, but masking is easy to bypass: echo $KEY | base64 comes out in the clear, and a set -x in a bash script prints every command with its arguments. That is why credentials always go in through stdin (--password-stdin) and never as a command-line argument, which is also visible in the runner's process list.

metadata-action translates that tag into the image's four tags with no intervention:

The two rows that never move are the ones for production; the moving ones are handy for development and dangerous in deployments. Aurora Libros' compose.prod.yaml pins the digest, so it does not even depend on 2.0.0 still pointing at the same thing.

Four details make this a deployment rather than a roulette wheel. The --wait (which you were already using during onboarding) waits for the healthchecks to pass and returns an error if they do not, so a broken deployment turns the job red instead of silently leaving you with a downed service. The set -euo pipefail stops at the first line that fails. The deploy user is not root and can only touch that directory. And the deployment goes by digest, not by tag: the up -d starts exactly the image that has just passed the tests.

Even so, this is a single-machine deployment: for a few seconds the service is recreated and nobody is serving. From 06-03 onwards the final step stops being a remote docker compose up and becomes an instruction to the orchestrator, which replaces the replicas one at a time without interrupting service.

• Forgetting --exit-code-from. The pipeline goes green with the tests in the red, which is worse than having no tests: it gives false confidence. Verify it on purpose by breaking a test.
• Rebuilding the image in the deployment job. It destroys traceability and deploys something nobody has tested. You promote by digest.
• Building without a remote cache. A four-minute pipeline per change makes people stop pushing small commits, and that makes everything else worse.
• Scanning by tag instead of by digest. You analyze an image that may not be yours. Always use image@sha256:....
• exit-code: 1 for every severity. The pipeline breaks every morning over a low CVE with no patch, and people learn to bypass the gate. Be strict where it matters.
• Publishing from pull requests. Anybody who opens a PR can push an image to your registry: gate push: on the event. And never pass secrets as arguments, since they show up in ps inside the runner and in plenty of logs; always --password-stdin.
• Tip: make the pipeline reproducible locally. If docker compose -f compose.tests.yaml up is the same thing CI runs, debugging a pipeline failure does not take twenty trial commits.
• Tip: use concurrency with cancel-in-progress. Ten pushes in a row should not launch ten multi-architecture builds; only the last one matters.

Exercise 1. Demonstrate the danger of --exit-code-from: deliberately break one of aurora-api's tests and run the test stack with and without that flag, comparing the exit codes. Explain what the pipeline would have done in each case.

Exercise 2. Measure the effect of the remote cache: run the pipeline three times (cold, cached, and cached after a change only in src/) and build the timing table. Explain why the third case is the fastest.

Exercise 3. Verify the complete supply chain of a published image: check the signature demanding that it comes from your workflow, extract the SBOM and locate the exact commit that generated it.

Solution 1.

The two exit codes, faced with exactly the same failing test, sum up the exercise:

What is perverse about the first case is that the failure does appear in the log, AssertionError and all, but nobody reads it: the green check says everything is fine. Without the flag, docker compose up reports whether it managed to bring the stack up —and it did—, not whether the test container finished happy.

Hence a practice worth adopting: the first time you set up a pipeline, break it on purpose. A pipeline you have never seen fail is not a green pipeline, it is an unverified one.

Solution 2.

The third case is the fastest for the same reason you studied in 02-02, now applied to a different machine each time. The Dockerfile from 06-01 copies package.json and package-lock.json first, runs npm ci, and only then copies src/. If only the source code changes, the npm ci layer is still valid and BuildKit fetches it from the GitHub cache instead of reinstalling 180 packages.

What makes it possible for a brand-new runner to take advantage of the previous one's work is cache-from: type=gha: the runner is ephemeral, the cache is not. Without it, all three columns of the table would read 4 min 35 s.

One important nuance so the number does not mislead you: those 41 seconds cover two architectures. The arm64 build runs under QEMU emulation and is about three times slower than the native one; without cache, that fact alone would add more than two minutes.

Solution 3.

The checks answer different questions, and together they close the circle:

The decisive piece of data is the Subject, and it is worth pausing on: it does not say "somebody signed this image", it says which workflow, from which repository and from which Git reference built it. If an attacker managed to publish an image in your registry tagged 2.0.0, the signature would not verify against that identity and the deployment should reject it. That check is the one you automate in the cluster with an admission policy.

And the SBOM + revision pair is what turns a security alert into ten minutes of work: when the next critical CVE for a library is published, cosign download sbom tells you in seconds whether your image includes it and at which version, and the revision label takes you to the exact commit to apply the fix on.

The road from commit to published image is no longer one you walk yourself. You can tell continuous integration apart from continuous delivery and continuous deployment —three concepts and two acronyms— and you know why Aurora Libros does deployment to staging and delivery to production. You have internalized the rule that holds the whole module together: build once, deploy many times, because the artifact is the image and its digest is the same object in every environment; a docker build per environment is a design flaw, not a convenience.

The tests run against a real PostgreSQL and Redis in an ephemeral stack with its data in tmpfs, and you know that --abort-on-container-exit without --exit-code-from produces the worst possible outcome: a green pipeline over red tests, which you triggered on purpose in order to see it. The complete GitHub Actions workflow chains lint and tests, metadata-action translating v2.0.0 into four tags plus the unrepeatable sha-, build-push-action building for amd64 and arm64 with cache-to: type=gha,mode=max —which took the build from 4 min 35 s to 41 s when only src/ changes—, Trivy reporting everything and breaking only on criticals with a patch available, and Cosign's keyless signing that spares you custody of any private key. You have verified the entire chain from the outside: a valid signature, a Subject naming the workflow and the Git tag that produced it, an SBOM with the version of every package and the OCI revision label carrying the exact commit.

You also know the GitLab CI equivalent with its mapping table, the real trade-off between Docker-in-Docker and the mounted socket —where both options mean, put bluntly, that a job can take control of the runner—, and the credential rules: ephemeral tokens with per-job permissions, OIDC instead of static passwords and no secrets on the command line. The final step, for now, is a remote docker compose pull && up -d --wait over SSH deploying by digest.

And that is where the limit is. That deployment has a gap of a few seconds during which nobody serves, it runs on a single machine and, if that machine goes down, Aurora Libros disappears from the internet. In the next lesson, Orchestrating Containers with Docker Swarm, you will set up your first cluster: several nodes with managers and workers, overlay networks connecting containers on different machines, services that reschedule themselves when a node dies, and the compose.yaml you already know deployed as a stack with docker stack deploy.