Skip to main content

Artifact Registry

Context​

Microservices are being adopted. Microservices (can) have separate repositories. There are automated deployments via CI/CD.

Problem​

  • The deployment requires to aggregate all deployment artifacts of the different microservices
    • Potentially from different repositories

Solution​

Introduce a shared artifact registry serving as a central place to collect deployment artifacts, e.g. a container registry if containers are used as deployment artifacts.

Publishing the deployment artifacts to the artifact registry can be a final step in the continuous integration pipeline after testing. This central artifact registry can be used by the deployment environment to fetch the deployment artifacts.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L3:

  • Docker => used Docker Registry too as part of CI pipeline
  • Docker compose to easily deploy from private Docker registry

L9:

  • CI uploads development and build images to image repository
    • contains versioned release, libs, language bindings
  • Operator downloads image from repository to deploy

L12:

  • Context: experience report
  • DockerHub / Docker Registry => (private) docker image repositories
  • Integrate it into CI
  • They separated code repositories per microservice
    • Dockerfile per service
    • CI job per service
    • pushes to Docker registry
    • => run whole system via Docker Compose
      • deploys services from private Docker registry

L19:

  • Docker Registry
    • shared repository for docker images
    • download or upload images via Docker client
    • makes distribution of images easy
      • Docker Hub (public)
        • freely create new images and add them to the collection
      • self-host private repository
  • create docker image from particular microservice repository
    • include versioning!
  • push to dedicated private Docker registry of the project
    • can be used to launch containers as needer via "docker pull" request

L31:

  • Context: MP1 - Enable continuous integration
  • CI job: fetch code from repository, run tests, build corresponding artifacts, push artifacts to artifact repository

L41:

  • all container images hosted in internal central Docker Registry
    • new images deployed to registry when new version successfully built and tested by CI

L43:

  • Each successful pipeline build (tests passed) => updated set of containers pushed to centralized container registry
  • deployment process to distribute updated containers to staging or test env

LN41:

  • Container attack surface contains whole deployment tool chain
    • image conception, image distribution process, automated builds, image signature, host config, 3rd-party components
    • addition: image distribution by container hub and other registries
      • adds several external steps, increases global attack surface

LN48:

  • Context: proposed deployment model
  • use a Container Repository to store created containers
  • deployment server uses container rpo to start instances of microservice => does not need to build and test from scratch
    • when starting new instances of already deployed microservice
  • deployment server builds container image after successful build and test
  • Example technology: docker registry
    • in their setup: local docker registry to store created images used by Jenkins for deployment
    • helps to redeploy microservice during failure, minimizes downtime

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • Docker for containerization
  • all images in internal docker registry = central repository for container images
  • new images get deployed to registry after build and test by CI
  • supports querying all available project images