https://pantsbuild.org/ logo
Join Slack
Powered by
Is there a way I could write a plugin or some sort...
# plugins
f
Is there a way I could write a plugin or some sort of templating to get the image digest for a docker target, then use that to deploy by digest in a helm target?
g
Sure! There's a few ways of doing this I think. Without deeper integration, the easiest probably is something like a CodeGenerator plugin for Helm, which generates the helm source file from a template + a docker dependency. Caveats apply that I don't think your rule can depend on the docker image actually being published.
You can see the general shape of this workflow here: https://www.pantsbuild.org/docs/plugins-codegen. I don't know much about the Helm backend, but it seems like a natural workflow to support so maybe @witty-family-13337 has some input. This was one of the first things I added to my OCI/kustomize/kubectl stack 😄
f
What about simply getting the digest from all docker builds as a start? i’m having trouble doing that
i essentially want to make a goal called get-digest, that if i run over ::, will build all docker targets and give me the image digest
w
you mean a Pants' 
Digest
with the contents of the Docker image?
f
w
ok, 
digest
is quite an overloaded word in Pants so I had to ask
f
ha ya i realize that now
w
you can get the 
image_id
(which is the equivalent to the SHA digest) by triggering a build of the docker image using 
await Get(BuiltPackage, DockerPackageFieldSet)
. The returned 
BuiltPackage
will contain 
BuiltDockerImage
artifacts and each of them will have an 
image_id
field with that value
I'm curious to know how you are intended to use it though, as if there is a potential improvement for the 
helm
backend
f
deploy my image by digest rather than by tag
w
saying this as you shouldn't need to use those values at all, just reference the 
docker_image
target in the 
helm_deployment
target as described in the docs and let Pants take care of it
worth saying that current behavior was implemented before the Docker backend was capable of returning an 
image_id
, do you mind describing what problem do you have now using the Helm backend so I may come up with some enhancement for a future release?
f
i just simply can’t figure out how to have the sha256 of the generated docker image from publish be injected into the helm chart for deployment
w
you can't inject it because the Helm backend wasn't implemented to do so
f
hm, i could read it into the chart from a file
i just can’t figure out how to get the digest
w
f
google cloud seems to need the full sha256 hash and not the short ID
g
As far as I can tell from a quick glance at the Docker code, if you enable BuildKit it should give you the full digest if possible
This isn't a limitation of Pants, it's a limitation of Docker in general. OCI images solve this better, but I don't think basic Docker can tell you even if you instruct it to build OCI images. And even there, technically your image could be modified once pushed and your local SHA is wrong
So the only way to truly know for sure is to push and then ask the remote what sha256 it got
w
as @gorgeous-winter-99296 said, enabling buildkit would give you the full SHA. In the other hand, you could save yourself quite a lot of time by using tags, if what you want is to emulate some sort of immutable tags, you can use what is described here to generate a tag based on the git commit and let Pants handle the rest: https://www.pantsbuild.org/v2.19/docs/tagging-docker-images#using-env-vars-to-include-dynamic-data-in-tags
f
That makes sense, the problem is that i need to use GCP's binary authorization, which requires i not only deploy by image digest, i have to run a command to attest my image before doing so https://cloud.google.com/binary-authorization/docs/making-attestations
i manage to solve around the image by essentially grabbing all docker targets, using the plugin rules mechanism to force them to run 
packaeg
, then taking the output 
BuiltPackage
's image_id field, and pushing it into a ``docker inspect --format='{{index .RepoDigests 0}}' $IMAGE`` command. This lets me iterate over all images that need to be build using the 
MutliGet
method to then run the attestation. So that part is fine, what im still stuck on is how do i elegantly pass the digests upstream to helm for deployment, if i can't do that, you'd have to manually run 
package
(or my new plugin 
pants attest_image ::
, and manually enter the digests for the GKE deployment
b
@fancy-daybreak-62348 I know this was a while ago, but I am also looking to do attestations on my docker images. Do you have some example code you can share? I don't have the requirement to deploy with helm just sign the images.
4 Views
Open in Slack
PreviousNext
Powered by