ImageSwap 2.0 Planning

[phenixblue]

Have been ruminating on ImageSwap 2.0 lately.

If you have any thoughts, please comment below. After a certain period of time, we'll lock down the final enhancements and begin implementation.

Major Thoughts at the moment:

Move to Golang

• Use COBRA + VIPER to move to a true 12 Factor model
• Undecided on whether to use net/http + client-go only, bring in controller-runtime, or to use kubebuilder
• Use more official docker libraries to handle canonical image naming standards for swaps

Implement proper configuration file with flexible structure

• Use VIPER and implement a YAML config to handle app/maps config
• Standard structure for any map type
• Maybe use K8s CRD for Maps

Other Ideas

• Use Rego to define mutations for swaps?
• Instrument with distributed tracing using OTEL libraries
• Overhaul init model (maybe use cert-controller)

[phenixblue]

Here's my first stab at what a true config file for ImageSwap might look like. I think I included all previously handled map scenarios:

global:
  log-level: info
  mode: maps
  disable-label: "k8s.twr.io/imageswap"
maps:
  - name: default
    registry:
    map: default.example.com
  - name: docker.io
    registry: docker.io
    map: my-example.com/mirror-
  - name: quay.io
    registry: quay.io
    map: quay.example3.com
  - name: cool.io
    registry: cool.io
    map: 
  - name: registry.internal.twr.io
    registry: registry.internal.twr.io
    map: registry.example.com
  - name: twr.io-skip
    registry: twr.io
    map: 
    skip: true
  - name: walrus.io-skip
    registry: walrus.io
    map: 
    skip: true
  - name: ghcrl.io-coolstuff-v1.0
    match: ghcr.io/fantasy/coolstuff:v1.0
    swap: my-local-registry.com/patched-coolstuff:latest
    exact: true

[phenixblue]

Correction...I think this doesn't cover the noswap_wildcards scenario yet. Will need to think on that

[phenixblue]

Here's another possibility that would add more verbosity on the frontend configuration of maps, but reduce the overall complexity of processing the maps:

apiVersion: imgswap.io/v1alpha1
kind: Maps
metadata:
  name: example-maps
spec:
  maps:
    - name: swap-docker-nginx-latest
      registry: "docker.io"
      project: "nginx"
      image: "nginx:latest"
      noSwap: false
    - name: no-swap-nginx
      registry: "docker.io"
      project: "nginx"
      image: "nginx:1.14-alpine"
      noSwap: true
    - name: swap-registry-port
      registry: "example.registry.com"
      port: "5000"
      project: "nginx"
      image: "nginx:1.15-alpine"
      noSwap: false
    - name: swap-full-image-name
      registry: "docker.io"
      project: "nginx"
      image: "nginx:1.15-alpine"
      noSwap: false

[phenixblue]

@mariomcosta @howardburgess @log2 @jchanam @ferenc-hechler @M4C4R

Looking for some feedback here if you have any thoughts

[ferenc-hechler]

I think using a custom resource is good. It also allows restricting access.
What is the purpose of the "name" field? Will the mapping rules be referenced somewhere?

[phenixblue]

The name field serves 2 purposes in my mind. 1) it provides a logical name for a map rule, and 2) it can provide flexibility to have multiple project specific map rules for the same top level registry domain, etc.

For naming, the examples posted previously probably aren't the best for getting the point across since they just use the registry name. The name could be something like "docker-to-harbor-internal" or something that has meaning to your team, business, etc.