Show HN: Managed GitHub Actions Runners for AWS • Hacker News Board

Re: Show HN: Managed GitHub Actions Runners for AWS

#51

Post by vicio » Fri, Apr 05, 2024, 8:22 AM UTC

jitl wrote: post #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 alt…

Thanks for sharing - Do you have any blogpost or YouTube video where you go deep into the details of the implementation? that would be a good one

Re: Show HN: Managed GitHub Actions Runners for AWS

#52

Post by jacobwg » Fri, Apr 05, 2024, 8:38 AM UTC

cocoflunchy wrote: post #39

Half the price of github is not great right now, this space is heating up! Ubicloud is 10x cheaper and https://runs-on.com is in the same ballpark by using spot instances. (Currently switching to RunsOn)

Yeah, I think our goal is to be the fastest at building software, not necessarily the cheapest. Part of that involves AWS, to have access to more powerful and elastic infrastructure, but that comes at a premium.

But besides just compute, I think the bigger long-term unlock for build performance is a new distributed compute engine, to free build workloads from single machines. We've started building this for our container build product, and plan to integrate Actions jobs as an input as well, starting with the cache integration we have today.

Re: Show HN: Managed GitHub Actions Runners for AWS

#53

Post by siborg » Fri, Apr 05, 2024, 9:44 AM UTC

Your website is surprisingly good. Often, show hn sites are pretty basic and a little off the mark, but this was clear. Pricing seems simple too. Great job. Will give it a try.

Re: Show HN: Managed GitHub Actions Runners for AWS

#54

Post by throwaway384638 » Fri, Apr 05, 2024, 9:58 AM UTC

jitl wrote: post #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 alt…

Can you post the TF file?

Re: Show HN: Managed GitHub Actions Runners for AWS

#55

Post by mason55 » Fri, Apr 05, 2024, 11:25 AM UTC

jacobwg wrote: post #9

toomuchtodo wrote: post #3

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…

Yep, it's a good question! At the moment, my thoughts are roughly: GitHub's incentives and design constraints are different than ours. GitHub needs to offer something that covers a very large user-base, to cover the widest possible number of workflows, and they've done this by offering basic ephemeral VMs on-demand. CI and builds are also not GitHub's primary focus as an org. We're trying to be the absolute fastest p…

This is one of the best responses about market positioning that I've ever read. Best of luck to you!

Re: Show HN: Managed GitHub Actions Runners for AWS

#56

Post by jillesvangurp » Fri, Apr 05, 2024, 11:36 AM UTC

A few months ago I had some issues with build performance. We're on the free plan with Github so using custom runners is not an issue. But I found a nice workaround:

- create a virtual machine with everything you need in gcloud (would work for aws as well). Pick something nice and fast. Suspend it.

- in your github action, resume the vm, ssh into it to run your build script, and suspend it afterwards.

Super easy to implement and easy to script using gcloud commands. It adds about 30 seconds of time to the build for starting the vm. On the machine, we simply pull from git and checkout the relevant branch. Doesn't work for concurrent builds but it's a nice low tech solution. And you only pay for the time the machine is up and running, which is a few minutes per day. So, you can get away with using vms that have lots of CPU and memory.

Re: Show HN: Managed GitHub Actions Runners for AWS

#57

Post by alas44 » Mon, Apr 08, 2024, 10:39 AM UTC

jacobwg wrote: post #18

alas44 wrote: post #8

How do you ensure privacy/isolation between users if you have a pool of ready VMs that you re-use?

We don't re-use the VMs - a VM's lifecycle is basically: 1. Launch, prepare basic software, shut down 2. A GitHub job request arrives at Depot 3. The job is assigned to the stopped VM, which is then started 4. The job runs on the VM completes 5. The VM is terminated So the pool exists to speed up the EC2 instance launch time, but the VMs themselves are both single-tenant and single-use.

My question is thus more on the on-disk data, you mention VM being terminated, does that data is wipped too and new VM starts on a brand new disk?

Re: Show HN: Managed GitHub Actions Runners for AWS

#58

Post by jacobwg » Mon, Apr 08, 2024, 11:36 AM UTC

alas44 wrote: post #57

jacobwg wrote: post #18

Earlier quoted context omitted.

We don't re-use the VMs - a VM's lifecycle is basically: 1. Launch, prepare basic software, shut down 2. A GitHub job request arrives at Depot 3. The job is assigned to the stopped VM, which is then started 4. The job runs on the VM completes 5. The VM is terminated So the pool exists to speed up the EC2 instance launch time, but the VMs themselves are both single-tenant and single-use.

My question is thus more on the on-disk data, you mention VM being terminated, does that data is wipped too and new VM starts on a brand new disk?

Correct yeah, each run starts on a brand new VM with a brand new disk - since these are EC2 instances with EBS volumes for their root disk, the whole instance and the EBS volume are deleted after the job finishes and are not reused.

Re: Show HN: Managed GitHub Actions Runners for AWS

#59

Post by alas44 » Fri, Apr 12, 2024, 9:19 PM UTC

jacobwg wrote: post #58

alas44 wrote: post #57

Earlier quoted context omitted.

My question is thus more on the on-disk data, you mention VM being terminated, does that data is wipped too and new VM starts on a brand new disk?

Correct yeah, each run starts on a brand new VM with a brand new disk - since these are EC2 instances with EBS volumes for their root disk, the whole instance and the EBS volume are deleted after the job finishes and are not reused.

Thanks for the reply