jonachehilton
commented
1 year ago +1
Closed davidjb closed 8 months ago
jonachehilton
commented
1 year ago +1
jfuss
commented
1 year ago @davidjb The halt is mostly due to how we support things like this. As the provided runtime has grown in support, we cannot keep adding runtime specific tools into one image.
We haven't made any decisions on paths forward however you can do this yourself by providing --build-image to the sam build command.
davidjb
commented
1 year ago Thanks @jfuss, glad to know solutions are being considered.
As you've said about --build-image, a workaround is to extend the existing provided.al2 image with a Dockerfile like so:
FROM public.ecr.aws/sam/build-provided.al2:latest-arm64
# Install Go
RUN curl -L https://go.dev/dl/go1.19.linux-arm64.tar.gz | tar -zx -C /usr/local
ENV PATH=$PATH:/usr/local/go/bin:/root/go/bin
# Set GOPROXY envvar to avoid using the default proxy.golang.org proxy
ENV GOPROXY=direct
# Compatible with initial base image
ENTRYPOINT []
CMD ["/bin/bash"]Then build the image (e.g. docker build -t provided.al2-with_go .) and use that with sam build, with --build-image ... as you say or in samconfig.toml:
[default.build.parameters]
use_container = true
build_image = [
"TestFunction=provided.al2-with_go",
"TestFunction2=provided.al2-with_go",
...
]This works, but you end up needing to re-specify the build image for each function explicitly (since other functions use different runtimes and I can't use a global build_image). There's also having to manage build processes for this extra container, and ensuring it's up-to-date etc.
If SAM CLI were create the Docker image dynamically (e.g. if go1.x is requested, create/extend a local provided.al2 image to have go in it), then that'd solve the problem and avoid the need to publish build variations of provided.al2, if that's the concern. Alternatively, the layer produced by my Dockerfile above is quite thin and effectively matches what the existing go1.x build image does. Either way, it would be good to have a solution built in to SAM CLI.
mildaniel
commented
1 year ago This works, but you end up needing to re-specify the build image for each function explicitly (since other functions use different runtimes and I can't use a global build_image)
@davidjb what would your thoughts be for SAM CLI to provide some sort of per-runtime/buildmethod configuration interface? Maybe something along the lines of an environment variable like AWS_SAM_CLI_BUILDMETHOD_CONFIGURATION that will pick up the particular configuration for all functions in your template with the same build method?
We're looking into ways of improving the configurations for the CLI and appreciate any suggestions you may have.
davidjb
commented
1 year ago @mildaniel That could be helpful for specific situations where customisation is need (e.g. a specific Go version for builds); having this as able to be specified in config as well as environment variables so it can be easily checked in to version control.
That said, the problem in this case is just about having go present within the given Docker build container - be it already there in the base image or installed manually. My preference is that SAM CLI is capable of achieving this by default without requiring external config, much in the same way SAM CLI knows how to build for or execute a given runtime given its name (e.g. go1.x).
vikhyat187
commented
12 months ago Hey @davidjb @jfuss can we use the --build-image of Go1.x or would that cause any problems as the Go1.x has been deprecating?
Thanks
adamdavis40208
commented
10 months ago Building on to that last question, will the Go1.x image continue to get updated? It currently has 1.20 on it, but how long will it get updated/when should we plan to stop using it? (and will it get 1.21 for example)
docker run --rm -it public.ecr.aws/sam/build-go1.x:latest bash
bash-4.2# go version
go version go1.20 linux/amd64@adamdavis40208 As per https://docs.aws.amazon.com/lambda/latest/dg/lambda-golang.html (and various other pages), go1.x (which is based on AL1) is slated for deprecation from 2023-12-31. I couldn't speak to whether its version internally would be updated ahead of then, however.
It's probably the same answer for you @vikhyat187 - using the old, deprecated go1.x may work right now but isn't a solution. Quoting the page above: If you're using the Go 1.x runtime, you must migrate your functions to provided.al2023 or provided.al2.
shearn89
commented
9 months ago Commenting just for notifications really - interested to see what the recommended way forward for Go via SAM is, when SAM is officially supported but the go1.x runtime is not and the recommendation is to use provided.alX.
Seems like a bit of miscommunication between teams - Lambda team dropping support for the Go runtime, but SAM team not adding in the tooling for the recommended solution...
deivinsontejeda
commented
9 months ago Any news on this? the deprecation is about to be meet and there is not a fix for this :(
hawflau
commented
8 months ago Hey all, SAM CLI v1.108.0 (released two days ago) supports container-build for go1.x on provided.al2 and provided.al2023. All you need to do is set BuildMethod: go1.x under Metadata of the Lambda Function then run sam build --use-container. For example:
Resources:
MyFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: go1.x
Properties:
Runtime: provided.al2 # or provided.al2023
# properties of the function
github-actions[bot]
commented
8 months ago Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.
Description:
The standard
go1.xruntime is based on AL1, which is both EOL and doesn't support ARM-based CPUs. The suggested replacement is to use theprovided.al2orprovided.al20223runtimes withBuildMethod: go1.x. This workssam buildis run locally but only on hosts where issues like https://github.com/aws/aws-lambda-go/issues/340 don't occur. In order to create a normalised build environment, I attempted to build withsam build --use-containerinstead, which errors with:The reason for this is that the
gobinary is not present within thesam/build-provided.al2image and thus preventing builds. A PR had been created at https://github.com/aws/aws-sam-build-images/pull/71 to add Go into theprovidedandprovided.al2runtimes but is under discussion as of the end of 2022.Steps to reproduce:
template.yml:sam build --use-container.Observed result:
Expected result:
Build to succeed and not error with
--use-container.Alternatively, if there was a way to set local environment variables such they're passed to
go buildlocally (e.g. when containers aren't used), that would be a workaround to the initial problem.Additional environment details (Ex: Windows, Mac, Amazon Linux etc)