Lambda Machine Local is the third project we are announcing under the Lambda Linux Project umbrella.
Lambda Machine Local provides a stable and secure local development environment that is designed to complement a stable and secure production environment on AWS.
Under the hood Lambda Machine Local uses Lambda Linux VirtualBox Flavor as its local container host virtual machine. Lambda Linux VirtualBox Flavor is based on Amazon Linux, the Linux operating system that powers AWS. We also use libmachine from Docker Machine Project for managing local container host virtual machines.
We would also like to say thank you to Amazon Linux AMI Team and Docker Machine Contributors for providing for providing some good ideas and code.
baseimage-amzn is the second project we are announcing under the Lambda Linux Project umbrella.
Sometime back, we wanted a Docker Base Image based on Amazon Linux RPM packages to make our container based development and deployment workflow on AWS more efficient and secure. It seemed like there was a need for a secure, stable Docker Base Image based on Amazon Linux packages.
So we created baseimage-amzn.
baseimage-amzn is inspired by baseimage-docker project. We would like to say thank you to Phusion for providing some good ideas and code. We would also like to say thank you to Amazon Linux AMI Team for providing excellent Amazon Linux RPM packages.
Extra Packages for Amazon Linux (EPLL) is the first project we are announcing under the Lambda Linux Project umbrella.
The goal is to create high quality set of additional packages that complements amzn*.repo package repositories.
Lambda Linux is a community project sponsored by Atihita Inc.
A while back we realized that Amazon Linux is an excellent server-style operating system. Given all the innovation that is happening on AWS and EC2, we felt that it was a bit strange that there is no vibrant open source community around Amazon Linux.
One thing led to another and we now have Lambda Linux Project. We look forward to creating a welcoming, commercial friendly, open-source community.
Btw, we have to clarify that – Lambda Linux Project is not related to, affiliated with, sponsored or endorsed by Amazon Web Services, Inc.
There are two hard things in Computer Science: cache invalidation and naming things.
Phil Karlton
Unfortunately this was not a Computer Science problem, but a trademark issue, that had to be taken care of.
Hence our project is called – Lambda Linux®. The registered trademark Linux® has been used pursuant to a sublicence from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.
By calling our project Lambda Linux, we are paying our respects to two Computer Scientists – Alan Turing and Alonzo Chruch
The future is already here – it's just not evenly distributed.
William Gibson
In Lambda Linux Project we understand, agree and appreciate many of the design decisions that Amazon has taken around – Minimal Operating System, Security Configuration and Updates, Multiple Package/Library Versions, Rolling Releases, etc.,
We believe that these decisions will play a crucial role as we enter the new world of application specific virtual machines, containers, cloud security and devops. When building our packages and images, we look forward to learning as much as we can from Amazon Linux packages and repositories.
Thank you Amazon Linux AMI Team for leading the way!
On most technical and design issues, Lambda Linux is not that different from Amazon Linux. We consider this as a feature, not a bug! The key difference perhaps is that we are an open-source project, where our direction us driven by our users and contributors.
In Lambda Machine Local, we want to provide a stable docker development environment for our users and that includes a stable Docker Engine.
Our users would be relying on Lambda Machine Local to develop applications to serve the needs of their customers. We need to be careful when migrating to newer docker releases because it can create issues for our users.
We track vendors who have a high bar for operational excellence and learn from how they have implemented docker engine. We then integrate those best practices into Lambda Machine Local.
We are aware of support for Hyper-V and xhvye in projects such as – Docker Machine and Minikube. We are following the issues users are reporting when using Hyper-V and xhvye drivers.
For us, using OS native hypervisors is interesting, but we need to give it more time before supporting them in Lambda Machine Local.
To us this discussion comes down to three aspects – operational security, trust and availability of newer & multiple package versions.
Ubuntu, RedHat, Debian, CentOS are designed to be general purpose Linux distributions. In contrast Amazon Linux is designed as a minimal server-style rolling Linux distribution. The design of Amazon Linux naturally provides much smaller exploit surface area when compared to general purpose Linux distributions. You can estimate the exploit surface area of a distribution by looking at the following metric - number of CVEs per distribution per month. Smaller exploit surface area is more easier to secure and automate.
Minimizing the number of entities we trust is a security best practice. By using AWS we are directly or in-directly trusting Amazon Linux. baseimage-amzn lets us extend our existing chain of trust with Amazon Linux to the container layer.
Amazon Linux is a stable rolling distribution. It provides the latest and multiple versions of language runtimes, databases and other packages. This allows us to decouple application dependent packages and language runtimes from OS dependent packages. Package and language runtime migrations can be managed at their own cadence. By providing a Docker based workflow, with baseimage-amzn we further simplify management and packaging of application dependencies.
You can expect to see following kinds of packages,
Packages used by the AWS EC2 community, but not available in amzn*.repo repositories
Packages useful to our users that landed in Red Hat® Extras repository instead of Fedora's EPEL repository
Packages from Fedora's EPEL repository that breaks when used with amzn*.repo repositories
We are a open-source project. So, you can also contribute and maintain packages on behalf of our community.
Our end-user security is extremely important to us. Security updates and other package updates are made available in the yum repositories. You can use yum updateinfo commands to identify and apply updates.
We will also provide a security portal similar to Amazon Linux AMI Security Center and a RSS feed. Please stay tuned!
All source RPMs (SRPMs) are available in yum repositories. You can use yumdownloader --enablerepo=epll-source --source <package_name> to download SRPM package.
No. We build, qualify and support our packages only against amzn*.repo repositories. You can think of EPLL as a community driven layered product on top of amzn*.repo repositories.
In general we avoid introducing duplicate packages (with the same RPM name and version) in EPLL repositories that might be present in amzn*.repo repositories.
However occasionally in order to support certain packages, we might introduce a newer version of an existing package that might be present in amzn*.repo repositories. These newer versions of packages are documented here. Once a package, originally in EPLL, lands in amzn*.repo, we will deprecate and remove it from EPLL repository. This process should be very seamless to you, our users.
You can find our package signing public key on GitHub at https://github.com/lambda-linux-pkgs/epll-release/blob/master/RPM-GPG-KEY-lambda-epll
First and foremost, we would like to say thank you to Fedora community. We have learned many good ideas from Fedora and where it makes sense, we will continue doing so.
If you are a Fedora or CentOS contributor, you will find yourself right at home in Lambda Linux project. If you come from other Linux distributions, we heartily welcome you too.
We are different from Fedora in the following ways –
We aim to deliver free, secure, stable and latest software to our users all the time
This is a very important distinction because we think it is the right thing to do for our users.
To our critics who might say it cannot be done! We kindly ask you to give it five minutes and learn from Amazon Linux.
We are focused only on server-style use-cases
This means – container, cloud, server and data center. There is no workstation.
We are not controlled by Red Hat® Inc.
While many things are yet to evolve, our governance structure will be very simple and modeled along the lines of – PostgreSQL and Linux Kernel project.