awslabs
Bumping configs for eBPF and Graviton2 support
Like to get some eyeballs on a builder to catch any mistakes. Ruby on Rails server - but could easily be .Net/JVM/Node/Django/RustRocket.
-
On the fence over the 5.4.20 kernel for awslinux2 or switch distros to Centos 8. Even the EKS AMI is broken on a lot of kubernetes tools from an old kernel.
-
Going with Graviton 2. Travis' benchmarks and my own M1 experience are overwhelming that x86 is toast.
-
Custom compile of the Ruby stack with FDO - source traceability on all gems as a build artifact.
-
Nginx, RDS compatible mysql 5.7 for local testing, SAM local for testing.
-
Task workers in a cgroup to limit blast radius of lurking media processing 0-days.
-
Source RPMs cached as artifacts cached to S3.
-
Anything that isn't production critical compressed with zstd to save space.
-
Deployment as EC2 batch for running tests - or giving devs a production parity instance they can ssh/vscode into from their laptop (especially with Docker hosed on M1, and this being ARM which would hose x86 WSL2).
Hey Chad - I'm not sure I got the ask, could you expand on the issue a bit on the problem and suggested solution?
Quickly glancing to the repo you mention I see two changes - Packer minor version bump and readme.
Perhaps this was created in error?
Livecoding :) Once I get yaks shaved for ARM and bumping the kernel I'll send a PR.
haha I know the feeling hence I thought I'd ask :)
On Wed, 25 Nov 2020 at 09:14, Chad Brewbaker [email protected] wrote:
Livecoding :) Once I get yaks shaved for ARM and bumping the kernel I'll send a PR.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/awslabs/ami-builder-packer/issues/16#issuecomment-733541966, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZPQBFQV3IQY6OTPFNYA5LSRS4HRANCNFSM4UCAJZUA .