Live data from Hacker News

Show HN: Managed GitHub Actions Runners for AWS

news.ycombinator.com

31–40 of 59 posts

Re: Show HN: Managed GitHub Actions Runners for AWS

#32
Interesting, makes a lot of sense to me as far as pricing too. However, I feel the video demonstration could greatly improve in terms of explaining and enthusiasm. It's super cool though and presentations/demos should showcase the full potential!

Re: Show HN: Managed GitHub Actions Runners for AWS

#33
At Notion we run our GitHub Actions jobs on ECS, and use auto-scaling to add and remove hosts from the ECS cluster as demand fluctuates throughout the day. We also age out and terminate hosts although they usually live for a few days to a week. I guess we had to pay some one time setup costs around configuring the ECS cluster and fiddling runner tags, but it seems to work pretty well. We have our own cache action although it’s not as fancy as depot’s, just a tarball in s3.

Overall 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
post #23

> - 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…

> > - Each instance has high-throughput networking of up to 12.5 Gbps, hosted in us-east-1

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

#35
A cool idea, but not sure the business case. I wrote a quick and dirty bash script which automates the process of adding 2x GitHub runners on instances (2 CPU cores and 4 GB memory each). Simply scale out horizontally. Since the instances are persistent you get docker image caching out of the box unlike hosted runners on GitHub. Also arm64 is fully supported.

Re: Show HN: Managed GitHub Actions Runners for AWS

#36

How 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…

Not mentioned down-thread, but GitHub’s incentive is to sell you CI minutes, and slow runners are shooting fish in a barrel.

Re: Show HN: Managed GitHub Actions Runners for AWS

#37
TL;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 (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

#38
post #37

TL;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…

It’s not wisdom to point out that using 3P software constitutes a threat vector. Personally, except in rare cases of unusual competence or unusual sensitivity, I believe that in-house CI will be more vulnerable than managed.

Re: Show HN: Managed GitHub Actions Runners for AWS

#40

I 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…

We looked at this Phillips solution originally in a previous org and eventually decided on Karpenter + Actions Runner Controller instead, configured with webhook aka push based triggers. It’s really the best solution for scale but it does take awhile to implement and tune to get right. If you have dedicated infra people I can recommend it. If you don’t, I would look to a more managed solution like OP’s offering
Post reply on HN