Using a pull-thru docker cache with the imagePolicy schedule feature?

[zvickery]

What happened?
We prefer to run our pods from a private pull-thru Docker image cache rather than directly from Dockerhub. At the same time, the auto-update feature with the schedule and dockerhub provider is pretty nice.

Would it be possible to combine these features somehow? Checking for updates on Dockerhub but starting the pod using a different repository than the default? In other words, setting TwingateConnector attributes like below:

  imagePolicy:
    provider: dockerhub
    repository: private_dockerhub_repo/twingate/connector
    schedule: 0 15 * * 5

I personally would expect it to use dockerhub to check for updates. The next time it starts a pod, it would use the supplied repository name for the image instead of the default. With a pull-thru cache, this should work fine.

Did you expect to see something different?

I tried using the features together but the code got a Python error:

  File "/app/app/version_policy_providers/dockerhub.py", line 33, in get_all_tags
    for result in data["results"]:
                  ~~~~^^^^^^^^^^^
KeyError: 'results'

I suppose it makes sense if a private repository isn't intended to support any sort of update checking.

How to reproduce it (as minimally and precisely as possible):

See above.

Environment

• Twingate Kubernetes Operator version:
  0.11.5
• Kubernetes version information:
  Client Version: v1.31.1 Kustomize Version: v5.4.2 Server Version: v1.31.0-eks-a737599
• Kubernetes cluster kind:
  EKS
• Manifests:
  N/A
• Twingate Kubernetes Operator Logs:
  N/A

Anything else we need to know?:
N/A

[linear]

OSS-48 Using a pull-thru docker cache with the imagePolicy schedule feature?

[ekampf]

Changing this from bug to enhancement.
dockerhub provider is meant to work against public repos. We'll need to see what settings are required to allow it to pull data off private repos

[ekampf]

hey @zvickery ,
So thinking about how to do this... I'm assuming in your cluster you already have a Secret object you also use with Kubernetes's imagePullSecrets and you'll expect to reference it in the operator as well.
Something like this?

  imagePolicy:
    provider: "dockerhub"
    schedule: "0 0 * * *"
    repository: twingate/connector
    version: "^1.0.0"
    imagePullSecret:
       name: "my-secret"
       namespace: "default"

Also, just note that if you want to use operator's image instead of imagePolicy (granted, you'll lose the auto update capability) you could use pull-thru today:

apiVersion: twingate.com/v1beta
kind: TwingateConnector
metadata:
  name: my-connector-fixed-image
spec:
  image:
    repository: twingate/connector
    tag: latest
  podExtra:
    imagePullSecrets:
      - name: my-secret

[zvickery]

We use ECR for this so the access is authorized with IAM instead of image pull secrets. The pull-thru works using the image.repository, which is great. But it loses the update functionality.

For my purposes, this would work great if line 12 of app/version_policy_providers/dockerhub.py was simply set to self.repository = "twingate/connector". This would force the update check to dockerhub no matter what. I'm not sure if there are any downsides to doing this?

[ekampf]

@zvickery your last comment makes sense... just to make sure we're in sync:

• We check for new tags in dockerhub but we actually fetch the image from a different address supplied in the CRD
• In that different address is private one could provide imagePullSecrets via podExtra
  right?

I'll see if I can figure out a nice way to do this

[zvickery]

That is correct! As long as the imagePullSecrets isn't strictly required.

[ekampf]

@zvickery merged #477 ! aiming to make an official release some time this week