From e2893298043695064a2de062710c69d30153bde5 Mon Sep 17 00:00:00 2001 From: Aidan Delaney Date: Fri, 26 Apr 2024 11:13:48 +0100 Subject: [PATCH] Motivate a traditional package workflow Motivate why we might want to use a per-service package. And why we might wish the packages to be as static as possible. Similar to a traditional Linux distribution. --- .../docs/develop/linux-package-workflow.md | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 site/content/imgpkg/docs/develop/linux-package-workflow.md diff --git a/site/content/imgpkg/docs/develop/linux-package-workflow.md b/site/content/imgpkg/docs/develop/linux-package-workflow.md new file mode 100644 index 000000000..354096164 --- /dev/null +++ b/site/content/imgpkg/docs/develop/linux-package-workflow.md @@ -0,0 +1,47 @@ +--- +title: Linux Package Workflow +--- + +## Scenario + +You want to deploy a large number of services on development and production environments. In addition, you want to support release of specific integrations of services. + +## Prerequisites + +To complete this workflow you will need access to an OCI registry like Docker Hub, and optionally, +a Kubernetes cluster. (If you would like to use a local registry and Kubernetes cluster, try using [Kind](https://kind.sigs.k8s.io/docs/user/local-registry/)) + +If you would like to deploy the results of this scenario to your Kubernetes cluster, you will additionally need [`kbld`](/kbld) and kubectl. + +## Example + +We have two images + +* `example.registry.fake/hello@sha256:4c8b96d4...`, and +* `example.registry.fake/echo@sha256:6139d4728...`. + +Each image needs to be deployed to a `dev` cluster alongside the development configuration files, and separately to a `prod` cluster alongside the production configuration files. The configuration can be represented as a `ConfigMap` containing a single key `mode` which either has either value `"dev"` or `"prod"`. + +``` +apiVersion: v1 +kind: ConfigMap +data: + mode: dev +``` + +In addition, we want to create a `metapackage` so that a well-tested integration of services can be deployed. + +To achieve our goals we will + +1. Create an `imgpkg` combining `example.registry.fake/hello@sha256:4c8b96d4...` and a development `ConfigMap` + - this will be pushed to a development distribution +2. Create an `imgpkg` combining `example.registry.fake/hello@sha256:4c8b96d4...` and a production `ConfigMap` + - this will be pushed to a production distribution + +We will create similar development and production flavored packages for `example.registry.fake/echo@sha256:6139d4728...` and push them to separate distribution channels. + +Finally, we will create a development flavored `metapackage` and a separate production flavored `metapackage`. The `metapackage` will depend on specific pinned versions of the `hello` and `echo` `imgpkg`s. + +## Static versus Dynamic + +It is an explicit goal of this workflow to deploy static packages. These are packages that require few, or no, `values` to be supplied at deployment time. We avoid dynamic computation of YAML because we want to use existing tools to audit our packages. In addition, we want to use `imgpkg` packages within teams that have strong knowledge and trust in Linux package management systems.