Where do the rpm files come from?

[nicwise]

I'm wondering where this comes from

ARG rpm_x64=java-1.8.0-amazon-corretto-devel-1.8.0_232.b09-1.x86_64.rpm
ARG path_x64=https://d3pxv6yz143wms.cloudfront.net/8.232.09.1
ARG key_x64=E8EB406377AD2B9E9A4765D19CB3BC6FF6C9FC19

I'd expect the RPM's to be from corretto.aws (which is the "site" that AWS lists), not an unmapped cloudfront distro. However, the one you have above is relocatable (yay), and their one isn't.

Any idea? I've made a lambda layer based on the above rpm's (hence relocatable), so I'm going to need to watch your stuff to make sure I bump versions as needed

Thanks

[alvdavi]

Hi,

We have rolled out the corretto.aws domain and urls fairly recently, that is why our dockerfile is still not updated, pointing to the "somewhat ugly" cloudfront url we have before.

That being said, I don't fully understand what are your expectations with the urls. Could you please explain what exactly is that you were hoping for?

[nicwise]

Ah, that explains it (the new domains).

Its not the ugly factor, really, its more "so, who actually owns that CF distro?"

I'd LIKE to use the "latest" urls on the corretto site (eg https://corretto.aws/downloads/latest/amazon-corretto-8-x64-linux-jdk.rpm from https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/downloads-list.html), so I can just have it rebuild weekly and promote it in if it's successful. At it is right now (using your URLs above), I'll have to watch your repo, work out when you update to the newer version, then update my scripts. Thats fine, but it's more work than the other option, which is mostly zero work.

The problem I had was that the RPM's on the downloads page (https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/downloads-list.html) didn't support RPM relocation (ie rpm -i --prefix=/lambda/opt $rpm). I might be able to work around that with the linux (not AL2) version, or possibly using the .tar.gz version, and not using RPM at all.

So thats my goal: make a lambda layer which drops Corretto in, so we can (from a NodeJS lambda) exec java -version (well, actually run code, but you get the idea). Java was present in an old version of the Lambda Node runtime (Node6 and Node8) but it's been removed in the new Lambda runtimes, based on AL2 (Node10 and Node12).

I have the layer working now. This was mostly to work out how much extra work I needed to do.

Thanks! <3

My scripts look like this. This one drives it on the machine your using:

#!/bin/bash

# make somewhere to put the layer
rm -rf java-layer
mkdir java-layer

# put the script we run in the package
cp install.sh ./java-layer

# build it
docker run --rm -v "$PWD"/java-layer:/lambda/opt lambci/yumda:2 bash /lambda/opt/install.sh

# clean up - we don't need these and they are HUGE
cd java-layer
rm src.zip javafx-src.zip install.sh

# zip the result, WITH symlinks
zip -yr ../layer.zip .

and this script is run in the container (ie, it's install.sh in the above)

#!/bin/bash
set -e

# paths came from the official Corretto Docker file
# https://github.com/corretto/corretto-8-docker/blob/8-al2-full/Dockerfile
#
# We need to use those as the rpms below are relocatable

export path=https://d3pxv6yz143wms.cloudfront.net/8.232.09.1
export rpm=java-1.8.0-amazon-corretto-devel-1.8.0_232.b09-1.x86_64.rpm
export key=E8EB406377AD2B9E9A4765D19CB3BC6FF6C9FC19

# build out out /tmp
cd /tmp
curl -O $path/$rpm

# validate the key
export GNUPGHOME="$(mktemp -d)"
gpg --batch --keyserver ha.pool.sks-keyservers.net --recv-keys $key
gpg --armor --export $key > corretto.asc
rpm --import corretto.asc
rpm -K $rpm

# install it into /lambda/opt
rpm -i --prefix=/lambda/opt $rpm

# clean up
rm -r $GNUPGHOME corretto.asc $rpm

# we also need fontconfig
yum install -y fontconfig

I then use Serverless to upload it as a layer.

[alvdavi]

Our docker images were updated to make use of our yum repos instead of downloading rpm files.