Closed ymettier closed 1 year ago
The PR mentionned in the bug description (extraVolumes
and extraVolumeMounts
) is https://github.com/woodpecker-ci/helm/pull/47.
Sorry, but I don't see how it's related to Woodpecker/put your own CI. Especially as a bug.
Find a way to provide my ca.crt to the agent
For why? In context of Kubernetes backend. Your build/publish step executes in different pod.
Find a way for the agent to provide that ca.crt to plugins like plugin-docker-buildx
It's responsibility of used tool/container/plugin to expose to you some configuration parameters.
You can at least
I get this error
Because in Kunernetes there is no docker socket. I got the same when tried docker build.
For Kubernetes backend I suggest to use kaniko. And this may help in your case.
Hello,
I consider this is a bug because https://woodpecker-ci.org/plugins/Docker%20Buildx says Use custom registries
and includes a note on how to provide the CA certificate on runner server host
. This seems to be possible with docker backend but not with kubernetes backend. Missing feature or bug as a regression ?
As far as I understand, this is not a bug of woodpecker-ci but a bug in woodpecker-ci plugin "docker-buildx" ? Sadly I cannot report it on https://github.com/woodpecker-ci/plugin-docker-buildx (no issue tracking system).
I just found https://codeberg.org/woodpecker-plugins/docker-buildx/issues : should I report it there ?
Thanks for the hint with Kaniko (I did not know about it). I will give a try. If it works for me with Kaniko, I may report it somewhere in https://github.com/woodpecker-ci/woodpecker so you can add it to the documentation ?
Helpful links, that I used: https://docs.docker.com/get-started/overview/#docker-architecture https://medium.com/geekculture/create-docker-images-without-docker-daemon-kaniko-847a688155a6 https://codefresh.io/blog/docker-images-without-docker-practical-guide/ https://earthly.dev/blog/docker-vs-buildah-vs-kaniko/ https://stackoverflow.com/questions/67495607/what-is-the-difference-between-kaniko-and-buildkit-buildx
And this is an example using WP. Without custom certificate, but working solution in general.
Hello,
OK, it works with Kaniko.
Here is my .woodpecker.yml (extracts) :
workspace:
base: /src
path: /repo
steps:
build:
...
publish:
image: gcr.io/kaniko-project/executor:debug
secrets:
- registry_ca_crt
commands:
- echo "$${REGISTRY_CA_CRT}" > "/kaniko/ssl/certs/additional-ca-cert-bundle.crt"
- /kaniko/executor --destination "myregistry:5001/awesome/tool:$${CI_COMMIT_TAG=build}-$${CI_COMMIT_SHA:0:8}-arm64" --context "/src/repo" --dockerfile "/src/repo/Dockerfile"
It seems that --context
is mandatory. I have tested with --dockerfile
. No idea if it works without it.
Thanks for the help.
I have a solution for my problem, so I will not try to make it work with plugin/buildx. I still consider there is a bug somewhere (as I explained in my previous post) but this is no more a problem for me. I guess we can close this issue ?
Last point : it would be a nice feature if the contents of my secret registry_ca_crt
above could be defined in a Kubernetes secret. Then I could use it either with volume
or as an environment variable defined from my secret. It would be a nice feature because I would not have to define it as a Woodpecker secret in all my repos. Should I open an issue (tagged "feature") for that ?
Last point : it would be a nice feature if the contents of my secret registry_ca_crt above could be defined in a Kubernetes secret. Then I could use it either with volume or as an environment variable defined from my secret. It would be a nice feature because I would not have to define it as a Woodpecker secret in all my repos.
I guess we can close this issue ?
You decide :) If you want to improve the docs, you can rename issue and use it as a base for following PR.
should I report it there?
Seems that kaniko, buildx and plugin-docker-buildx can use custom certs. So there is no bug or missing functionality. You can just open PR with improved docs. Otherwise you should open the issue in respective repos (buildx or plugin-docker-buildx).
the contents of my secret registry_ca_crt above could be defined in a Kubernetes secret. Then I could use it as an environment variable defined from my secret.
If you want exactly that behavior, then it's not implemented as I know. Then it will be feature request (this issue or new one), I think.
looks more like an issue for our bildx plugin ?
can we close this here?
Hello,
I'll try to finish this issue with as much as infos as I can.
@zc-devs
I looked at closed issues/PRs yesterday... Seems you can mount volume :)
True, but with Kubernetes backend, it does not work with configMaps or secrets (yet ?). I have not checked for an issue "wanted feature" for that but maybe it should be created ? Again : for me it now works with kaniko so, with Agile methods in mind, I will not create an issue for what I don't need :)
You can try Global variables also.
Yes! Thanks for that tip. This is what I use now. I like the "Fill it once, use it everywhere" idea and it works.
@6543
looks more like an issue for our bildx plugin ?
Maybe. So I wrote it : https://codeberg.org/woodpecker-plugins/docker-buildx/issues/69
I have no reason to keep that issue open. I close it. Feel free to re-open it if I was too fast at closing ! And thanks for your help and tips !
Component
agent
Describe the bug
The bug
I want to build and push an OCI image (aka docker image) on my self-hosted registry. I'm running Woodpecker with Kubernetes backend.
I have this error :
x509: certificate signed by unknown authority
.Explanation
The
docker build
is not aware of myca.crt
file.How to fix the bug
ca.crt
to the agent (easy to do, need a little hack of the helm chart)ca.crt
to plugins like plugin-docker-buildx (likeWOODPECKER_BACKEND_DOCKER_VOLUMES
but that does not work with Kubernetes backend)What I did, what I tried...
I have read a lot of documentation on how to build+push my image. I have also read some parts of source code of Woodpecker Kubernetes backend. I have hacked the helm chart in order to put my ca.crt in a ConfigMap and mount it (with success) in either the agent pod or the dind pod (I will probably do a PR for this in repo woodpecker-ci/helm).
I have tried with
WOODPECKER_BACKEND_DOCKER_VOLUMES
variable but this is restricted to Docker backend. I found nothing similar for Kubernetes.At last, it does not work whatever I do.
My favorite try (with and without dind enabled) :
This should work but I fail at mounting the ConfigMap in the plugin-docker-buildx pod.
Another try (too complex I guess):
I get this error :
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
I have also tried with Podman but I'm getting problems to run in privileged mode.
System Info
Helm values
Notice the hack with
extraVolumes
andextraVolumeMounts
.registry-ca-crt
is a ConfigMap that contains a key namedca.crt
and the value is the CA certificate.