Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Allow makefile BuildMethod to use Amazon Linux 2 based build image #6718

Open
rikbruil opened this issue Feb 20, 2024 · 2 comments
Labels
type/feature Feature request

Comments

@rikbruil
Copy link

rikbruil commented Feb 20, 2024

Describe your idea/feature/enhancement

I'm not sure if this is a bug or a feature request, but when running sam build --use-container for a Lambda Layer resource we have encountered a situation where it seems you can only use the makefile build method with the provided build image (apparently based on Amazon Linux 1) and there seems to be no way to use BuildMethod makefile with an image based on Amazon Linux 2 instead.

Proposal

If this is indeed not possible currently, I would like to see a way to control the image used during build (provided or provided.al2) when specifying a makefile BuildMethod.

I'm not sure if this would require changes to the SAM spec, or could perhaps be solved with a CLI flag/toggle when running sam build (or perhaps a setting in samconfig.toml)? Alternatively I could see a way of adding a new BuildMethod called makefile.al2, but I think a CLI toggle initially should do the trick.

Additional Details

Our situation is that we are using SAM to build some layers used by Python3.9 lambda runtimes, and we are using the makefile build method to install some binaries (pg_dump/pg_restore) and copy those along with their libraries to the layer for use by the lambda functions.

It seems there is a mismatch between the lambda runtime and the OS used at build time causing library version issues (Amazon Linux 1 seems to have outdated versions compared to what should be available in Amazon Linux 2).

@rikbruil rikbruil added stage/needs-triage Automatically applied to new issues and PRs, indicating they haven't been looked at. type/feature Feature request labels Feb 20, 2024
@lucashuy
Copy link
Contributor

Thanks for raising this feature request. Was there a particular way you were building the layer? Defining a layer as such:

HelloWorldLayer:
  Type: AWS::Serverless::LayerVersion
  Properties:
    ContentUri: ./layer
    CompatibleRuntimes:
      - provided.al2
    CompatibleArchitectures:
      - x86_64
  Metadata:
    BuildMethod: makefile

With a random requirements.txt and a Makefile in the ./layer folder:

# ./layer/Makefile
build-HelloWorldLayer:
	# my system does not have yum, AL2 provided does
	yum --version

	mkdir -p "$(ARTIFACTS_DIR)/python"
	python3 -m pip install -r requirements.txt -t "$(ARTIFACTS_DIR)/python"

Running sam build -u HelloWorldLayer seems to pull the provided AL2 build image and installed requirements successfully.

@lucashuy lucashuy removed the stage/needs-triage Automatically applied to new issues and PRs, indicating they haven't been looked at. label Feb 21, 2024
@rikbruil
Copy link
Author

@lucashuy Thanks for the info, I compared your snippet to our templates and everything was identical except for the CompatibleRuntime setting which was set to python3.8 in our case.

I ran the SAM build command just for the layer resource as you did, and now it turns out the correct image gets used when building (whether I specify provided.al2 or python3.8, in both cases I get an AL2 based image). I took another look at our template and noticed there was also one lambda function in there with Runtime: provided.

It seems that SAM CLI prefers the provided runtime over our explicitly specified python3.8 compatible runtime for the layer when we build the entire stack via sam build. I'm not sure if that's correct behaviour, because the provided runtime appears to be the only one using a different AmazonLinux version compared to the rest of the runtimes. To me it seems to be the 'least' compatible, while SAM CLI output says:

For container layer build, first compatible runtime is chosen as build target for container.

Do you recommend I open a bug around this behaviour, or does first compatible runtime mean any existing runtime image in this context?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feature Feature request
Projects
None yet
Development

No branches or pull requests

2 participants