-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Private docker registries support for polling #50
Comments
I think what could be working here is to scan the |
interesting approach |
Hi, I had similar plan according to https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/. It appears that secret should be defined in deployment:
And then I could fetch secret by name What would be really helpful is to get some actual use cases on how you are using private registries. |
Actually in my case, I don't specify the imagePullSecret in all cases, because this can be bypassed via serviceaccounts, which is a more convenient use I think: https://kubernetes.io/docs/concepts/containers/images/#referring-to-an-imagepullsecrets-on-a-pod
|
I understand that k8s automatically sets this field for deployments so when Keel accesses deployment through API would it be set? I will create transport for secrets from providers to triggers using |
Unfortunately I haven't found them so this is a runtime thing I guess, I checked the pods and the deployments as well. |
I withdraw my last comment, imagePullSecrets is becoming the part of the Pod descriptor even when using the ServiceAccount way. |
awesome! |
New image with Kubernetes provider - creating a secret
and then using it in a k8s documented way such as
Is enough, Keel will use the same secret your pods are using to access docker registry, so this integration is transparent and doesn't require user to know anything. Helm provider:Here user is required to do two things:
Does this make sense? |
I'm curious why do one needs to provide the imagePullSecret in the values file, if it is already part of the Pod descriptor on the API? Right now I don't have to define imagePullSecret in the Helm configuration, and now I have to define it two times. |
I will have a look again at it, but it doesn't look like Healm releases have pod descriptors inside them. |
@bonifaido |
If keel checks the deployment descriptor this is right, but on the API this information is available without specifying it by hand. |
Are you talking about Helm API or Kubernetes API and which provider? |
Polling provider and the Kubernetes API. |
Ok, I think you mean polling trigger and Helm provider, right? The reason why secret reference needs to be defined in values.yml when using Helm provider is that Keel doesn't contact Kubernetes API directly, it communicates with Helms Tiller and uses Tillers API to start release updates, therefore you get revisions 1,2,3, etc.. I will have another look at how we can identify deployments from helm releases :) |
Slightly upgraded secret retrieving mechanism, it's no longer needed to define secrets specifically for Keel anywhere. It will figure it out from where to get them. Triggering |
nice one :) |
Great! Just checking out the new version. |
Somehow I get this error:
I have installed the keel right now with:
This is how my Pod looks like on the API:
|
do you see a message similar to |
No this message is not in the logs, this is the last message before the error: |
added additional log message to show when no secrets for pod found (will remove it later): |
Yes, this error message appears now: The secrets in the default namespace:
|
Pushed yet another alpha image to display more debugging info, in that previous log as values it should also show selector, how it's looking for pods. It looks like it could be labeling/selector issue.
https://github.com/webhookrelay/webhook-demo/blob/master/webhookdemo/templates/deployment.yaml#L5-L8 While your pod labels:
I expected this to be default things on Helm. Could you add |
This is how my Pod looks like now:
But still the same error message, I can't see the new log messages about the selectors :( |
Try pulling again
and then use that selector to see if correct pod is retrieved (in my case it's keel):
|
Okay, I have upgraded keel (please post the image digest, so I can make 100% sure I'm using the exasct same version), and now the error message saying
Keel version:
|
Digest is correct. How did you create your secret? It seems that it finds the secret but then doesn't decode it.
Pushed new image that should show looked up secret names. Digest Edit: Also, some more info would be helpful - Kubernetes and Helm versions. |
I think we are now on track:
The issue is that my secret
I guess the code looks for usernames and password right now. You have to |
yeah, that's not something I can probably add today as I have plans this evening. Sorry about that, token support will definitely be added in the next few days. If you could add credentials to your secrets and see whether everything else works as expected - it would be great. |
Absolutely no issues, and thanks for the support and blazing fast responses! |
I'm trying to do use Artifactory as docker store with polling using the Kubernetes provider and it seems the user is not coming through. Its picking up the secret OK and shows the correct username in the log, but somehow does not seem to be sending it on correctly. I've tried using the api key and user/pass that are validated on the Artifactory side. Using 90515df8f4b5bc95042f1bbeee05221ae6f27b8f2ded55286063d2a8e4b901c1
|
@bonifaido - added support for those base64 auth strings in #74. Created new alpha image: @stickycode - I assume there can be issues with artifactory as I have seen problems in other libraries authenticating to it, especially that 403 error. Could you please open a separate issue specifically for Artifactory related problems? I will need to get a dev environment with it, saw that they have a 30 days trial, should be good enough. |
Implemented in #74, available from release 0.4.3. If there any issues then please create a new ticket, this one became a bit too long :) Thanks for help everyone! |
Hi. We're using node configuration to avoid imagePullSecrets in our deployments (as described here https://kubernetes.io/docs/concepts/containers/images/#using-a-private-registry under "Configuring Nodes to Authenticate to a Private Repository". Is there a way to get keel to work with such a setup? |
Hi @maehld, please create a new issue for this. Keel can't access local docker config, we will have to find another way. It would be good to know more, whether you are running your own private registry and what kind of authentication it expects (basic, token). |
No description provided.
The text was updated successfully, but these errors were encountered: