A container image is a deployment artifact created from application sources and published to a container registry. In a CI workflow, image creation can follow compilation and tests, producing an artifact for a Kubernetes-based application rather than slowing every feature-branch build. section 8.4.2 section 8.6.4
Build images when deployment-ready changes reach the main branch. Keep feature-branch checks fast, then use pull-request workflows for quality, coding-standard, license, and security checks before publishing deployable artifacts. section 8.4.2 section 8.7
Treat image versioning and deployment configuration as one traceable package:
- Scan created containers for known vulnerabilities before preparing deployment artifacts. section 8.5.7
- Insert the image build version into the Kubernetes deployment template so Kubernetes pulls the image built by that workflow. section 8.5.7
- Publish images to a container registry; publication can trigger a versioned release and a subsequent CD workflow. section 8.6.4 section 8.7
Deploy a versioned frontend image
A Kubernetes Deployment references ghcr.io/vriesmarcel/frontend:#{Build.version}#. Replacing that marker with the image build number ensures the deployment artifact identifies the exact image produced by CI; the configuration also specifies resource requests, limits, and registry pull secrets. section 8.5.7
spec:
containers:
- name: frontend
image: ghcr.io/vriesmarcel/frontend:#{Build.version}#
resources:
requests:
memory: "500Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: «750m»
env:
- name: ASPNETCORE_ENVIRONMENT
value: Development
- name: ApiConfigs__EventsCatalog__Uri
value: http://catalog:8080
- name: ApiConfigs__Ordering__Uri
value: http://ordering:8080
ports:
- containerPort: 80
imagePullPolicy: Always
imagePullSecrets:
- name: pullsecret
Inspect a deployment container specification that combines an image tag with resource settings, environment variables, pull behavior, and registry credentials. section 8.5.7
