ECR Image: push without build

[mattfysh]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Currently the image being pushed to ECR must be also built by Pulumi, which is a rather uncommon setup in projects where the build steps are separated from the deployment steps. The schema of the resource allows for no build args to be provided, but fails when it cannot locate a Dockerfile

It would be great if there were a way to push an image to the ECR registry if it has already been built and tagged on the local host.

See pulumi/pulumi-docker#54 for a similar discussion on the docker provider. It is suggested that if no build is required, a docker.RegistryImage should be created instead of docker.Image

Affected area/feature

A possible solution is to support an imageName input for the Image, and branch the internal logic based on its presence:

import * as awsx from "@pulumi/awsx";
const repository = new awsx.ecr.Repository("repository", {
    forceDelete: true,
});
const image = new awsx.ecr.Image("image", {
    repositoryUrl: repository.url,
    imageName: 'my-locally-built-image',
});

[mjeffryes]

Thanks for this suggestion @mattfysh; we've been talking a bit about this use case in the context of some of our docker work too recently. We'll try to think about how to enable this scenario in awsx as well. cc @blampe

[mattfysh]

let me know if this is off topic, but I was looking into the implementation of ecr.Image and noticed that a new image is built and pushed on each program run only because aws.ecr.getCredentialsOutput will return new credentials each time.

If (for example) the same creds token was returned then pulumi wouldn't invoke the resource, so a new image wouldn't be built/pushed even if the (files referenced by) context or Dockerfile has changed

[flostadler]

I started working on this and created a prototype. There's still some rough edges though; this is affected by pulumi/pulumi-docker#952.

I'm working on an enhancement to the docker provider to ignore changes to the volatile parts of the auth data (username & password)

[flostadler]

This is currently blocked on pulumi/pulumi-docker#952. We'll first need to first iron out issues with the provider showing updates on every run because of the changing credentials

[flostadler]

We made progress on pulumi/pulumi-docker#952 and once it is resolved we can tackle this here.

The one decision we have to make then is whether we want to add another shallow wrapper for the docker resources or instead provide a more user friendly function to fetch the credentials for the registry in order to configure the docker provider.
There's a total of 3 resources and 2 functions in the docker provider that would benefit from having a function to fetch creds.

Right now folks have to do the following to fetch credentials and configure the docker provider:

const registryInfo = repo.registryId.apply(async id => {
    const credentials = await aws.ecr.getCredentials({ registryId: id });
    const decodedCredentials = Buffer.from(credentials.authorizationToken, "base64").toString();
    const [username, password] = decodedCredentials.split(":");
    if (!password || !username) {
        throw new Error("Invalid credentials");
    }
    return {
        address: credentials.proxyEndpoint,
        username: username,
        password: password,
    };
});

const ecrProvider = new docker.Provider("ecr-provider", {
    registryAuth: [registryInfo],
});

If we had a convenience function it could look like this:

const registryInfo = aws.ecr.getDockerCredentialsOutput({ registryId: repo.registryId });
const ecrProvider = new docker.Provider("ecr-provider", {
    registryAuth: [registryInfo],
});

IMO adding the shallow wrappers mostly has drawbacks for users compared to the convenience function. E.g. there's gonna be delays between new features in pulumi-docker trickling down to awsx.

[flostadler]

This will block providing the convenience function: pulumi/pulumi#12008.
We could instead add it as a resource method (i.e. call) to awsx.ecr.Repository, but there's plenty of scenarios (I'd probably even same most) where you create an ECR repository in a different stack then where you work with the images.

I'll see if there's a good way to work around this or we go with the wrapper resources. One possible option would be adding the function to the AWS provider itself (either muxing or patching), but that would be quite costly. For now I'll quickly add a wrapper component for the docker.RegistryImage resource like I mentioned above and hold it until pulumi/pulumi-docker#952 is resolved.

[pulumi-bot]

This issue has been addressed in PR #1464 and shipped in release v2.21.0.