Container Platform defines the contract for an Online Shop release composed of independently built container images. Offline release validation and opt-in Docker Hub metadata verification are implemented.
The project does not build application code or operate a Kubernetes cluster. Its target workflow turns images published to Docker Hub into a versioned release bundle pinned by digests for review, validation and promotion to the SRE Platform.
Status: Release contract v1, baseline/inventory records, offline/registry checks, PR checks and Compose rendering/runtime smoke are implemented. One hosted baseline smoke run passed; legacy eligibility remains negative. The active main-protection ruleset and owner-confirmed Required check labels are recorded; pending-check blocking remains unverified. SRE handoff remains planned.
The Online Shop consists of multiple independently built services. A successful build of each image does not by itself prove that the images form one compatible application release.
The target platform will provide the release boundary below; architecture, the v1 schema, a synthetic example and a discovered baseline candidate are available:
- defines which images and immutable digests make up a release;
- validates that the release is complete and follows container-release rules;
- provides a local Compose-based integration harness for the published images;
- hands an approved release to the SRE Platform for GitOps deployment.
flowchart LR
AML["Application Modernization Lab\nsource code and Dockerfiles"]
CI["CI Build Platform\nbuild, test, scan, publish"]
DH["Docker Hub\nindividual online-shop images"]
CP["Container Platform\nrelease contract and validation"]
SRE["SRE Platform\nGitOps, Argo CD, GKE"]
AML --> CI
CI --> DH
CI -.->|build metadata| CP
CP -.->|planned release control| SRE
DH -->|direct image distribution| SRE
The two paths into the SRE Platform have different roles:
- Docker Hub is the data path: Kubernetes nodes pull the approved images from
dmitryzhuravlev/online-shop-*. - Container Platform is the release-control path: it identifies the exact image digests that are approved together as one Online Shop release.
The diagram describes target relationships. Offline, opt-in Docker Hub metadata, PR checks and Compose rendering are implemented; the active main-protection ruleset requires the three PR checks. Runtime evidence is reported separately; SRE handoff remains planned.
| Component | Owns | Does not own |
|---|---|---|
| Application Modernization Lab | Online Shop source code, Dockerfiles, instrumentation | image distribution or runtime deployment |
| CI Build Platform | per-service build, tests, scans, source/build metadata, Docker Hub publication | release approval or Kubernetes deployment |
| Container Platform | release manifest, release-policy validation, published-image integration checks | application source, image builds, a long-lived environment, or Kubernetes deployment |
| SRE Platform | environment-specific GitOps configuration, rollout, rollback, observability, and runtime operation | rebuilding or retagging the approved release |
- CI Build Platform builds and publishes individual Online Shop images to Docker Hub.
- A full release manifest records immutable digests and per-component source/build references under the contract, with explicit legacy gaps and separate third-party dependency rules.
- Container Platform validates the manifest and the published image references through pull-request checks.
- A release PR may represent approval only after authorized review and all documented mandatory checks pass; merge alone is not validation. Checks and main protection are configured; release authorization remains a separate decision.
- A promotion change updates the SRE Platform's GitOps configuration to the exact digests from that release.
- Argo CD applies the GitOps change, and GKE pulls the same images from Docker Hub.
Container Platform does not sit in the network path between GKE and Docker Hub. It improves the decision and audit path before deployment.
The first MVP will provide:
- a machine-readable Online Shop release manifest;
- immutable Docker Hub digest references for all required services;
- deterministic release-policy checks;
- Docker Hub availability verification;
- a Compose-based validation path that uses published images rather than local builds;
- a documented, reviewable handoff to the SRE Platform;
- a rollback model based on selecting a previously approved release.
The MVP intentionally excludes a new registry, a Kubernetes cluster, a long-lived development or staging environment, and automatic deployment.
See the roadmap for the planned implementation sequence.
The existing Dockerfiles and build/push scripts are empty; root Compose contains legacy local-build placeholders. Use the generated Compose workflow for the supported profile. The scaffold is not a working release pipeline.
See the baseline discovery, profile inventory, candidate, and registry observations. The selected dev profile includes 10 application services, Redis and a load generator. These namespace-published artifacts are third-party upstream copies/dependencies with legacy traceability gaps; this candidate is not approved or deployment-authorized.
Canonical Online Shop source and Dockerfiles are available in Application Modernization Lab. Its adapted profile confirms the selected image mappings; the pinned SRE configuration remains authoritative for this baseline. Existing images were not built from that canonical path and retain legacy source/build gaps.
Install with python -m pip install . (Python 3.11+ and Git), then run:
python -m container_platform releases/baseline-2026-10-18.json --repository . --format json
The committed baseline passes structure and inventory checks but returns exit code 1 with 12 legacy-ineligibility diagnostics. Passing offline rules does not establish approval or deployment authorization. See installation, checks and output/exit-code semantics.
Add --registry to inspect immutable manifest/config bytes and declared platforms after local prerequisites pass. Legacy failures remain visible and keep the baseline unsuccessful. No layers are downloaded, and metadata success grants no approval or deployment authorization. See transport restrictions, output v2 and limits.
GitHub Actions validation runs tests/package checks on Python 3.11 and 3.13 and a stable release check. New candidates receive opt-in registry validation; merged release files are immutable. No candidate changes produces an explicit successful result. The historical legacy baseline remains a negative regression fixture. Main protection records read-only observations, owner settings and the PR enforcement checklist; green CI alone does not prove protected merges or grant release approval.
Offline Compose rendering generates all 12 digest-pinned services from a candidate and the packaged AML profile. Legacy baseline rendering requires explicit --inspection-only; its validation remains negative. Static docker compose config checks do not establish runtime compatibility or release approval.
Bounded runtime smoke requires explicit --execute, consumes the rendered candidate snapshot and cleans up its unique Compose project. It checks service process state and a synthetic catalog/cart/checkout flow. Inspection-only baseline execution preserves legacy ineligibility. See the recorded live outcome and limitations; runtime success is separate from release approval and deployment authorization.
Manual hosted smoke is registered and has a successful baseline dispatch: 12 exact-image services, readiness, five semantic assertions and verified cleanup. Inspection-only preserved validation exit 1 and 12 legacy failures. Runtime smoke is not a mandatory PR check or release approval; live cancellation recovery remains unverified.