https://pulumi.com logo
Join Slack
Powered by
Is there any way to tell the new DockerBuild Image...
# getting-started
a
Is there any way to tell the new DockerBuild Image resource to use my local docker for images? I'd like to use it to retag and push up some images that are already built and waiting to go up...
l
Would that mean that the code wouldn't work on anyone else's machine?
Might be best to push to an internal registry and have the Pulumi code know about that.
a
Well, it would just depend on the image being readily available.
Much like any source code / Dockerfile.
l
Most source code is imperative though; Pulumi is declarative. It might not work so well with this pattern; "create resource one way if the local info exists else create it another way"; if the next time you run that code, the local info has been built, then the remove resource might get destroyed and recreated even though it shouldn't...
Probably best to use a single well-known location that works for everyone who might run the code, and your local machine can push to that well-known location
a
I'm fine with it failing if it's not there.
l
You could use automation-api to wrap your normal project in some imperative code that handles the local stuff.
a
Involving other remote registries is a bit of an over-design I'd say for what I want.
I just am doing my build of an image using other tools, and I want pulumi to be able to have the responsibility for retagging and pushing the image up.
l
> I'm fine with it failing if it's not there. But that doesn't work with Pulumi. What happens in this scenario: 1. It's there. 2. You run the project. Something remote is created. 3. You clean your local Docker. It's not there any more. 4. You run the project. Your remote thing is destroyed.
a
Eh, that's not likely in my scenario.
My scenario is: 1. External thing builds an image and puts it in local docker 2. Pulumi takes it, retags it and uploads it
l
Ok. Well if you really want to do it, then I think there is a resource for it. Onesec I'll refresh my memory...
a
This is all happening on a CI server or whatever. Straight-shot. Build, retag, push.
Copy code
csharp
    var apiImage = new Image("api", new()
    {
        
        Dockerfile = new DockerfileArgs
        {
            Inline = "FROM api",
        },
        Pull = false,
        Push = true,
        Tags = [
            infrastructure.Outputs.Apply((infrastructureApply) => infrastructureApply["apiRegistryUrl"] as string ?? throw new("Missing API registry URL!")),
        ],
    });
This is what I've been trying with the 
Image
resource. But it doesn't see the image that's already in my local Docker. Likely because it's using some transient buildx engine?
l
Ok, I'm thinking of the cacheFromLocal functionality. Is that what you're looking for? https://www.pulumi.com/registry/packages/docker-build/api-docs/image/#cachefrom_nodejs
a
That appears to take a path, rather than a socket or some indicator to just use "default engine".
Could it be made to work with that?
l
Hmm. I'm guessing probably not. It's a caching functionality, rather than access to the Docker daemon. However, when you build your image, you could set the 
--cacheTo
(iirc) flag, which should work with Pulumi's cacheFromLocal functionality?
a
Maybe. I'm relying on the dotnet automatic docker container build target (convenient, always stays up to date)
Every possibility I could spin out a Dockerfile.
But then I have one more mouth to feed 😉
l
I don't know what that is. Sounds interesting though!
a
Yeah, I dunno, if you're a java guy, imagine a free gradle target that packs the project up into a container for you. Batteries included.
l
Cool. Well if the gradle job is configurable and is a wrapper around buildx, then cacheTo should be an option.
a
I'm going to think about this.
Leaning towards just having the Dockerfile
Then I can benefit from all the creature comforts Pulumi offers during builds.
Although it pushes my dotnet build deep behind some layers, so maybe not, blurgh. Thanks for the insights on that cache though 🙂
7 Views
Open in Slack
PreviousNext
Powered by