Feature request: AWS::Serverless::Function.ImageUri Should Also Accept a Local File Path #6909
Comments
chrisoverzero
added
stage/needs-triage
|
Thanks for raising this issue. We're open to accepting this request and can chat here about implementation details, that way other team members can find this issue and reply in case they had more context or ideas. Regarding specification changes (point no.1), would the change to Regarding point no.4, this should be possible. I've never worked with building images from archives, but we build a Docker image from a tarball that contains things like the Dockerfile and required binaries, as part of the local emulation behaviour: aws-sam-cli/samcli/local/docker/lambda_image.py Lines 345 to 355 in a18a729 The documentation for the build API can be found here: https://docker-py.readthedocs.io/en/stable/images.html#docker.models.images.ImageCollection.build If this was the same kind of thing you had in mind, then it should be possible to do the same thing for the building context. There also looks to be a loading API if the archive was exported: https://docker-py.readthedocs.io/en/stable/images.html#docker.models.images.ImageCollection.load |
lucashuy
added
area/build
I worry that this is a laser-guided question and that you, who knows this code base better than I do, already know about something I've missed! 😅 But I don't believe so. What I envision is that this is a preprocessing step, effectively. Once the archive is Note If you provide a local file path, use the AWS SAM CLI to load and push the local archive as an image at deployment. To learn more, see Using the AWS SAM CLI to upload local files at deployment. But I'm sure I'll discover whatever I'm missing when I dive into the code.
That's exactly what I was looking for – thanks for getting directly there. There doesn't seem to be an equivalent to |
|
I don't currently have any issues with using the ImageUri to serve up a local archive, so we can explore that path to implement this. We also have the The Docs: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-build.html |
|
For the record, I have my proof-of-concept running as of this morning (EDT) using I'm confident in meeting the team's standards for documentation, but it's going to take me a bit to figure out how best to add this to automated testing. I'm unlikely to open an MR until I think it's ready to go unless you tell me otherwise. Later: I have |
As a summary, sam has learned to load an an image from a local archive
before proceeding with the `build`, `package`, and `deploy` commands.
When running `sam build` with an `ImageUri` pointing to a local file,
sam will load that archive into an image, then write the ID of the
image to the `ImageUri` property of the built template. ID works the
same as a tag for the Docker API, so business continues as usual from
here. The reason behind writing ID is that a loaded image could be
associated with multiple tags, and selecting one arbtrarily leads to
difficulties in the deploy command.
The package and deploy commands have three kinds of value for
`ImageUri` to consider. First, a value of the form
`{repo}:{tag}`. This functions as it always has. Second, an image
ID (in the form `sha256:{digest}`) which is probably the output of
`sam build`. In this case, the tag translation uses the name of the
as its input. Otherwise, they'd all end up with names starting with
"sha256". Last, a local file. In this case, it proceeds as it does in
the build command: Load the archive into an image first, then pass the
resource name into tag translation.
See: aws#6909
|
I don't yet consider that PR complete because I don't know what documentation the required step "Write documentation" refers to. Is it about documenting methods/functions? Or is it about updating documentation in the SAM Spec? Or a third thing? |
As a summary, sam has learned to load an an image from a local archive
before proceeding with the `build`, `package`, and `deploy` commands.
When running `sam build` with an `ImageUri` pointing to a local file,
sam will load that archive into an image, then write the ID of the
image to the `ImageUri` property of the built template. ID works the
same as a tag for the Docker API, so business continues as usual from
here. The reason behind writing ID is that a loaded image could be
associated with multiple tags, and selecting one arbtrarily leads to
difficulties in the deploy command.
The package and deploy commands have three kinds of value for
`ImageUri` to consider. First, a value of the form
`{repo}:{tag}`. This functions as it always has. Second, an image
ID (in the form `sha256:{digest}`) which is probably the output of
`sam build`. In this case, the tag translation uses the name of the
as its input. Otherwise, they'd all end up with names starting with
"sha256". Last, a local file. In this case, it proceeds as it does in
the build command: Load the archive into an image first, then pass the
resource name into tag translation.
See: aws#6909
As a summary, sam has learned to load an an image from a local archive
before proceeding with the `build`, `package`, and `deploy` commands.
When running `sam build` with an `ImageUri` pointing to a local file,
sam will load that archive into an image, then write the ID of the
image to the `ImageUri` property of the built template. ID works the
same as a tag for the Docker API, so business continues as usual from
here. The reason behind writing ID is that a loaded image could be
associated with multiple tags, and selecting one arbtrarily leads to
difficulties in the deploy command.
The package and deploy commands have three kinds of value for
`ImageUri` to consider. First, a value of the form
`{repo}:{tag}`. This functions as it always has. Second, an image
ID (in the form `sha256:{digest}`) which is probably the output of
`sam build`. In this case, the tag translation uses the name of the
as its input. Otherwise, they'd all end up with names starting with
"sha256". Last, a local file. In this case, it proceeds as it does in
the build command: Load the archive into an image first, then pass the
resource name into tag translation.
See: aws#6909
Also, genericize unit tests a little. See: aws#6909
…Function.ImageUri` (#6930) * feat: sam Commands Understand Local File Paths for `ImageUri` As a summary, sam has learned to load an an image from a local archive before proceeding with the `build`, `package`, and `deploy` commands. When running `sam build` with an `ImageUri` pointing to a local file, sam will load that archive into an image, then write the ID of the image to the `ImageUri` property of the built template. ID works the same as a tag for the Docker API, so business continues as usual from here. The reason behind writing ID is that a loaded image could be associated with multiple tags, and selecting one arbtrarily leads to difficulties in the deploy command. The package and deploy commands have three kinds of value for `ImageUri` to consider. First, a value of the form `{repo}:{tag}`. This functions as it always has. Second, an image ID (in the form `sha256:{digest}`) which is probably the output of `sam build`. In this case, the tag translation uses the name of the as its input. Otherwise, they'd all end up with names starting with "sha256". Last, a local file. In this case, it proceeds as it does in the build command: Load the archive into an image first, then pass the resource name into tag translation. See: #6909 * Reword Explanatory Comment See: #6909 * Correct Old Typo in String Parameter See: #6909 * Take a Swing at Unit Tests See: #6909 * Cover Another Test Case See: #6909 * Take a Swing at Integration Tests Also, genericize unit tests a little. See: #6909 * Now Add Package Integration Tests * And Deploy Integration Tests * Point to Correct File, Remove Unused Import --------- Co-authored-by: jysheng123 <[email protected]> Co-authored-by: sidhujus <[email protected]>
Describe your idea/feature/enhancement
I wish SAM CLI would accept a local path to an image archive (the kind of thing which can be loaded by
docker image load) for the value ofImageUri.Proposal
For an
ImageUricontaining a local path to an image archive, the commandsam buildwould perform the equivalent ofdocker image load(in the same way that it will currently perform the equivalent ofdocker image build) and write the image name and tag into the built template as the new value ofImageUri.The command
sam packagewould do the same thing, but additionally perform the equivalent of thedocker image pushand write the address of the image in the remote repository into the output template as the new value ofImageUri.In general, it would make
ImageUriwork a little more likeCodeUri.Things to consider:
ImageUriproperty would have to be documented to accept this kind of value.docker image importcould be performed instead, assigning a single canonical, generated name to the image in the same way assam builddoes.dockercommand-line tool or the docker service available. I know of other development teams who produce file archives of Docker images for scanning purposes. Lacking either end of Docker simplifies those steps in the CI process, so we only need to associate the docker-in-docker service with the job in which we performsamcommands for the final deployment. Also, it's much easier in many ways to manage CI artifacts which are normal files.sam builddoes its Docker work without thedockerCLI tool available by usingdocker+http://URLs somehow. I presume it's issuing commands to the Docker service over a more direct interface, and I see this capability in the Docker API, so it feels possible.ImageUrilike this is undesirable, I could imagine a property namedImagePathorImageArchiveor something similar to serve the same purpose.Additional Details
I would be willing to take on this work if this request is accepted. I've contributed to serverless-application-model and aws-sam-build-images before, so I probably wouldn't be completely in over my head.
The text was updated successfully, but these errors were encountered: