#How to use gcloud or awscli in Dagger?
1 messages · Page 1 of 1 (latest)
This is what I figured out so far, seems reasonable
func (R *Runtime) GcloudImage() (*dagger.Container) {
cfg, err := os.UserConfigDir()
if err != nil {
fmt.Println(err)
return nil
}
d := R.Client.Host().Directory(filepath.Join(cfg, "gcloud"))
c := R.Client.Container().From("google/cloud-sdk")
c = c.WithEnvVariable("CLOUDSDK_CONFIG", "/gcloud/config")
c = c.WithDirectory("/gcloud/config", d)
return c
}
hmm, interesting, in this example it shows starting with the dagger-sdk and then moving to a google-sdk
what if I need to sequence this gcloud operation in between dagger steps? That seems like having to manually sync things properly.
Maybe the With(...) function fits here, and the gcloud-sdk code runs in a step that doesn't actually modify the container?
basically, if I am letting Dagger's solver handle caching and lazy-eval, I want to let any nested or intermediate calls to my cloud, via another sdk, to be interwoven and managed by Dagger
At least that seems to make sense and be the right way to approach things
👋 take into account that WithDirectory will leak the config credentials in the underlying image if that's something that you're ultimately pushing. I'd advise to mount (WithMountedDirectory) these kind of things (~/.aws, ~/gcloud, ~/.config/docker, etc) instead of adding them to the container
At least that seems to make sense and be the right way to approach things
Yep, that is correct. Only caveat is that With won't run in your container but in SDK execution local host so you need to be mindful about where each part of the pipeline is running which is confusing. I believe project Zenith #daggernauts wil enable a different solution for this which would be providing a similar API like the With one but with the ability to actually run that code within the pipeline container
yea, that makes sense, which is why I'm not so worried about the WithDir, since these images are not being pushed, but it seems like WithMountedDirectory would be better all around anyway, sound more appropriate and prevents any accidents should someone push that image
wait, does that function mean that I can "mount a volume at build time"?
yep.. it's mounting from the build context
say I push that image, will it try to mount that volume when run as a container?
should I WithoutMount to cleanup when I'm logically done with a mount?
no, it won't. It's only at build time
What does a Dockerfile VOLUME map to in Dagger?