Show HN: Managed GitHub Actions Runners for AWS
31–40 of 59 posts
Re: Show HN: Managed GitHub Actions Runners for AWS
#32Re: Show HN: Managed GitHub Actions Runners for AWS
#33Overall it’s pretty simple terraform setup plus a couple dockerfiles. And we get to run in the same region as the rest of our infra that’s close to most of our devs (us-west-2).
ECS might sound more complicated than “just use ec2” but we don’t have to screw around with lambdas and the terraform is pretty simple, much simpler then the Philips-labs one. It’s about 1400 lines of Terraform across 2 files since ECS has so much stuff built in and integrates with auto scale groups well.
Re: Show HN: Managed GitHub Actions Runners for AWS
#34> - Each instance has high-throughput networking of up to 12.5 Gbps, hosted in us-east-1, so interacting with artifacts, cache, container registries, or the internet at large is quick. do you actually get the promised 12.5 Gbps? I've been doing some experiments and it's really hard to get over 2.5Gbit/s upstream from AWS EC2, even when using large 64 vCPU machines. Intra-AWS (e.g. VPC) traffic is another thing and th…
with that pull quote, I thought you were going to point out their use of us-fail-1. I struggle to think of a service that I care so little about its availability that I'd host it there, but CI/CD for sure wouldn't be one
Re: Show HN: Managed GitHub Actions Runners for AWS
#35Re: Show HN: Managed GitHub Actions Runners for AWS
#36How will you compete if GitHub talks to the Azure folks (who have the benefit of Azure scale) and gets better compute and network treatment for runners? Or is the assumption GH running remains perpetually stunted as described (which is potentially a fair and legit assumption to make based on MS silos and enterprise inertia)? To be clear, this is a genuine question, as compute (even when efficiently orchestrated and a…
Re: Show HN: Managed GitHub Actions Runners for AWS
#37A managed runner means not only entrusting a third party with your code but also typically providing it with enough data/network connectivity to make testing/validation feasible as a part of the build process. While this is doable per se, it introduces multiple major failure modes outside of data owners' control.
Failure scenario (hypothetical): you hydrate your test DB using live data; you store it in a dedicated secure S3 bucket, which you make accessible for the build process. Now the managed runner organization gets hacked because making resilient infra is hard, and the attackers intercept the S3 credentials used by your build process. Boom! Your live data is now at the mercy of the attackers.
Re: Show HN: Managed GitHub Actions Runners for AWS
#38TL;DR: managed runners by construction constitute a major ongoing infosec liability. A managed runner means not only entrusting a third party with your code but also typically providing it with enough data/network connectivity to make testing/validation feasible as a part of the build process. While this is doable per se, it introduces multiple major failure modes outside of data owners' control. Failure scenario (hy…
Re: Show HN: Managed GitHub Actions Runners for AWS
#39Re: Show HN: Managed GitHub Actions Runners for AWS
#40I recently set up AWS Github runners with this terraform. It works well and you don't have to pay any extra in addition to AWS. https://github.com/philips-labs/terraform-aws-github-runner
I helped set this up at my workplace and can second that it works fairly well, but it definitely does have scale issues (we tend to exhaust our GH org's API ratelimit and end up being unable to scale up sometimes, as well as seeing containers be prematurely terminated because the scale down lambda doesn't seem to always see them in the GH API) and it's definitely lacking a lot of tooling around building runner images…