search

lifadev / archive_aws-lambda-go

A fast and clean way to execute Go on AWS Lambda.
https://github.com/eawsy/aws-lambda-go
Apache License 2.0
699 stars 36 forks source link

Use amazonlinux Docker image #11

Closed fsenart closed 7 years ago

fsenart commented 7 years ago

Amazon Linux Image now available on Docker Hub https://hub.docker.com/r/_/amazonlinux/

jangaraj commented 7 years ago

Why not tiny alpine docker image? Will it be binary compatibility problem (glibc vs musl)?

cristim commented 7 years ago

Alpine would be preferable indeed, due to its much smaller size it makes it much faster for developers to download it the first time they need it, but indeed it may be problematic due to the different libc, so it definitely needs to be tested first.

But then again, for humans this only matters when pulling the image for the first time, so it may not make much difference. But in my case I also use it from TravisCI, and it seems that the image is always downloaded fresh on each build, which is slower and wasteful with larger images.

I would really expect Travis and most other CI vendors to have a local registry caching proxy, not sure if they use this under the hood.

fsenart commented 7 years ago

@jangaraj as you've noticed, the problem with Alpine is musl. In the past we have tried to overcome this problem without success. That's why we've used a "regular" os as the base of the current Docker image.

@jangaraj @cristim, internally we also have a standalone gcc + go + libc + etc package that can be embedded in an Alpine image but this won't change anything. Indeed, Alpine images are more for production workloads (fast, minimal deployments) rather than development. In development, you need a bunch of different tools to be installed in the image, the effect is the growing size of the image.

Above explanations in mind, I opened the issue to "support"/"promote" the new AWS image. Why not using it, if we use already a regular OS as the base of the image. One more advantage is also the fact that the AWS image along with contained libraries will be the one used by the AWS platform, so we can align our build for this project and others with the official image.

PS: I want you to notice that we don't need to align with libraries of the official image for now because we only depend on libc which has a very impressive backward compatibility.

fsenart commented 7 years ago

I close the issue, we use the amazonlinux image in the new version of the project. https://github.com/eawsy/aws-lambda-go-shim