From c9bf5f02f8e8e086477126a78b1ad26fe1dddef0 Mon Sep 17 00:00:00 2001 From: "Alex Ellis (OpenFaaS Ltd)" Date: Mon, 4 Mar 2024 12:30:37 +0000 Subject: [PATCH] Updates --- 404.html | 4 ++-- .../blog.json | 0 .../blog/amd-zenbleed-update-now.json | 0 .../blog/arm-ci-cncf-ampere.json | 0 .../blog/automate-packer-qemu-image-builds.json | 0 .../blog/blazing-fast-ci-with-microvms.json | 0 .../blog/caching-in-github-actions.json | 0 .../blog/calyptia-case-study-arm.json | 0 .../case-study-bring-your-own-bare-metal-to-actions.json | 0 .../Cxoj3UCPrpnpf54sZEXpk/blog/cncf-arm-march-update.json | 1 + .../blog/custom-sizes-bpf-kvm.json | 0 .../blog/develop-a-great-go-cli.json | 0 .../blog/faster-nix-builds.json | 0 .../blog/faster-self-hosted-cache.json | 0 .../blog/firecracker-container-lab.json | 0 .../blog/github-actions-usage-cli.json | 0 .../blog/how-to-run-multi-arch-builds-natively.json | 0 .../blog/is-the-self-hosted-runner-safe-github-actions.json | 0 .../blog/kvm-in-github-actions.json | 0 .../blog/local-caching-for-github-actions.json | 0 .../blog/managing-github-actions.json | 0 .../blog/multi-arch-docker-github-actions.json | 0 .../blog/native-arm64-for-github-actions.json | 0 .../blog/oidc-proxy-for-openfaas.json | 0 .../blog/right-sizing-vms-github-actions.json | 0 .../blog/sbom-in-github-actions.json | 0 .../blog/secure-microvm-ci-gitlab.json | 0 .../bR4Jv3N8T_1-64ExyobFe/blog/cncf-arm-march-update.json | 1 - .../_buildManifest.js | 0 .../_ssgManifest.js | 0 blog.html | 2 +- blog/amd-zenbleed-update-now.html | 4 ++-- blog/arm-ci-cncf-ampere.html | 4 ++-- blog/automate-packer-qemu-image-builds.html | 4 ++-- blog/blazing-fast-ci-with-microvms.html | 4 ++-- blog/caching-in-github-actions.html | 4 ++-- blog/calyptia-case-study-arm.html | 4 ++-- blog/case-study-bring-your-own-bare-metal-to-actions.html | 4 ++-- blog/cncf-arm-march-update.html | 6 +++--- blog/custom-sizes-bpf-kvm.html | 4 ++-- blog/develop-a-great-go-cli.html | 4 ++-- blog/faster-nix-builds.html | 4 ++-- blog/faster-self-hosted-cache.html | 4 ++-- blog/firecracker-container-lab.html | 4 ++-- blog/github-actions-usage-cli.html | 4 ++-- blog/how-to-run-multi-arch-builds-natively.html | 4 ++-- blog/is-the-self-hosted-runner-safe-github-actions.html | 4 ++-- blog/kvm-in-github-actions.html | 4 ++-- blog/local-caching-for-github-actions.html | 4 ++-- blog/managing-github-actions.html | 4 ++-- blog/multi-arch-docker-github-actions.html | 4 ++-- blog/native-arm64-for-github-actions.html | 4 ++-- blog/oidc-proxy-for-openfaas.html | 4 ++-- blog/right-sizing-vms-github-actions.html | 4 ++-- blog/sbom-in-github-actions.html | 4 ++-- blog/secure-microvm-ci-gitlab.html | 4 ++-- index.html | 2 +- pricing.html | 2 +- rss.xml | 4 ++-- 59 files changed, 59 insertions(+), 59 deletions(-) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/amd-zenbleed-update-now.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/arm-ci-cncf-ampere.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/automate-packer-qemu-image-builds.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/blazing-fast-ci-with-microvms.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/caching-in-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/calyptia-case-study-arm.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/case-study-bring-your-own-bare-metal-to-actions.json (100%) create mode 100644 _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/cncf-arm-march-update.json rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/custom-sizes-bpf-kvm.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/develop-a-great-go-cli.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/faster-nix-builds.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/faster-self-hosted-cache.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/firecracker-container-lab.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/github-actions-usage-cli.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/how-to-run-multi-arch-builds-natively.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/is-the-self-hosted-runner-safe-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/kvm-in-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/local-caching-for-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/managing-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/multi-arch-docker-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/native-arm64-for-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/oidc-proxy-for-openfaas.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/right-sizing-vms-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/sbom-in-github-actions.json (100%) rename _next/data/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/blog/secure-microvm-ci-gitlab.json (100%) delete mode 100644 _next/data/bR4Jv3N8T_1-64ExyobFe/blog/cncf-arm-march-update.json rename _next/static/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/_buildManifest.js (100%) rename _next/static/{bR4Jv3N8T_1-64ExyobFe => Cxoj3UCPrpnpf54sZEXpk}/_ssgManifest.js (100%) diff --git a/404.html b/404.html index 74c7e8e..315572e 100644 --- a/404.html +++ b/404.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

404

This page could not be found.

\ No newline at end of file + }

404

This page could not be found.

\ No newline at end of file diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/amd-zenbleed-update-now.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/amd-zenbleed-update-now.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/amd-zenbleed-update-now.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/amd-zenbleed-update-now.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/arm-ci-cncf-ampere.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/arm-ci-cncf-ampere.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/arm-ci-cncf-ampere.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/arm-ci-cncf-ampere.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/automate-packer-qemu-image-builds.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/automate-packer-qemu-image-builds.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/automate-packer-qemu-image-builds.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/automate-packer-qemu-image-builds.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/blazing-fast-ci-with-microvms.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/blazing-fast-ci-with-microvms.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/blazing-fast-ci-with-microvms.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/blazing-fast-ci-with-microvms.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/caching-in-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/caching-in-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/caching-in-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/caching-in-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/calyptia-case-study-arm.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/calyptia-case-study-arm.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/calyptia-case-study-arm.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/calyptia-case-study-arm.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/case-study-bring-your-own-bare-metal-to-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/case-study-bring-your-own-bare-metal-to-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/case-study-bring-your-own-bare-metal-to-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/case-study-bring-your-own-bare-metal-to-actions.json diff --git a/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/cncf-arm-march-update.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/cncf-arm-march-update.json new file mode 100644 index 0000000..f25ce37 --- /dev/null +++ b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/cncf-arm-march-update.json @@ -0,0 +1 @@ +{"pageProps":{"post":{"slug":"cncf-arm-march-update","fileName":"2024-03-04-cncf-arm-march-update.md","contentHtml":"

It's now been 4 months since we kicked off the sponsored program with the Cloud Native Computing Foundation (CNCF) and Ampere to manage CI for the foundation's open source projects. But even before that, Calyptia, the maintainer of Fluent approached us to run Arm CI for the open source fluent repos, so we've been running CI for CNCF projects since June 2023.

\n

Over that time, we've got to work directly with some really bright, friendly, and helpful maintainers, who wanted to have a safe, fast and secure way to create release artifacts, test PRs, and to run end to end tests. Their alternative until this point was either to go against GitHub's own advice, and to run an unsafe, self-hosted runner on an open source repo, or to use QEMU that in the case of Fluent meant their 5 minute build took over 6 hours before failing.

\n

You can find out more about why we put this program together in the original announcement: Announcing managed Arm CI for CNCF projects

\n

Measuring the impact

\n

When we started out, Chris Aniszczyk, the CNCF's CTO wanted to create a small pilot to see if there'd be enough demand for our service. The CNCF partnered with Ampere to co-fund the program, Ampere sell a number of Arm based CPUs - which they brand as \"Cloud Native\" because they're so dense in cores and highly power efficient. Equinix Metal provide the credits and the hosting via the Cloud Native Credits program.

\n

In a few weeks, not only did we fill up all available slots, but we personally hand-held and onboarded each of the project maintainers one by one, over Zoom, via GitHub, and Slack.

\n

Why would maintainers of top-tier projects need our help? Our team and community has extensive experience porting code to Arm, and building for multiple CPUs. We were able to advise on best practices for splitting up builds, how to right-size VMs, were there to turn on esoteric Kernel modules and configurations, and to generally give them a running start.

\n

Today, our records show that the CNCF projects enrolled have run a total of 70.3k minutes. That's almost the equivalent of a computer running tasks 24/7 for a total of 2 months solid, without a break.

\n

Here's a list of the organisations we've onboarded so far, ordered by the total amount of build minutes. We added the date of their first actuated build to help add some context. As I mentioned in the introduction, fluent have been a paying customer since June 2023.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RankOrganisationDate of first actuated build
1etcd-io (etcd, boltdb)2023-10-24
2fluent2023-06-07
3falcosecurity2023-12-06
4containerd2023-12-02
5cilium (tetragon, cilium, ebpf-go)2023-10-31
6cri-o2023-11-27
7open-telemetry2024-02-14
8opencontainers (runc)2023-12-15
9argoproj2024-01-30
\n

Data sorted by most Arm minutes consumed

\n

Some organisations have been actuated on multiple projects like etcd-io, with boltdb adding to their minutes, and cilium where tetragon and ebpf-go are also now running Arm builds.

\n

It's tempting to look at build minutes as the only metric, however, now that containerd, runc, cilium, etcd, and various other core projects are built by actuated, the security of the supply chain has become far more certain.

\n

From 10,000ft

\n

Here's what we aimed for and have managed to achieve in a very short period of time:

\n\n

Making efficient use of shared resources

\n

After fluent, etcd was the second project to migrate off self-managed runners. They had the impression that one of their jobs needed 32 vCPU and 32GB of RAM, and when we monitored the shared server pool, we noticed barely any load on the servers. That led me to build a quick Linux profiling tool called vmmeter. When they ran the profiler, it turned out the job used a maximum of 1.3 vCPU and 3GB of RAM, that's not just a rounding error - that's a night and day difference.

\n

You can learn how to try out vmmeter to right-size your jobs on actuated, or on GitHub's hosted runners.

\n

Right sizing VMs for GitHub Actions

\n

The projects have had a fairly stable, steady-state of CI jobs throughout the day and night as contributors from around the globe send PRs and end to end tests run.

\n

But with etcd-io in particular we started to notice on Monday or Tuesday that there was a surge of up to 200 jobs all at once. When we asked them about this, they told us Dependabot was the cause. It would send a number of PRs to bump dependencies and that would in turn trigger dozens of jobs.

\n

\"Thundering

\n
\n

Thundering herd problem from dependabot

\n
\n

It would clear itself down in time, but we spent a little time to automate adding in 1-2 extra servers for this period of the week, and we managed to get the queue cleared several times quicker. When the machines are no longer needed, they drain themselves and get deleted. This is important for efficient use of the CNCF's credits and Equinix Metal's fleet of Ampere Altra Q80 Arm servers.

\n

Giving insights to maintainers

\n

I got to meet up with Phil Estes from the containerd project at FOSDEM. We are old friends and used to be Docker Captains together.

\n

We looked at the daily usage stats, looked at the total amount of contributors that month and how many builds they'd had.

\n

\"Phil

\n

Then we opened up the organisation insights page and found that containerd had accounted for 14% of the total build minutes having only been onboarded in Dec 2023.

\n

\"Detailed

\n

We saw that there was a huge peak in jobs last month compared to this month, so he went off to the containerd Slack to ask about what had happened.

\n

Catching build time increases early

\n

Phil also showed me that he used to have a jimmy-rigged dashboard of his own to track build time increases, and at FOSDEM, my team did a mini hackathon to release our own way to show people their job time increases.

\n

We call it \"Job Outliers\" and it can be used to track increases going back as far as 120 days from today.

\n

\"Job

\n

Clicking \"inspect\" on any of the workflows will open up a separate plot link with deep links to the longest job seen on each day of that period of time.

\n

So what changed for our own actuated VM builds in that week, to add 5+ minutes of build time?

\n

\"Maximum

\n

We started building eBPF into the Kernel image, and the impact was 2x 2.5 minutes of build time.

\n

This feature was originally requested by Toolpath, a commercial user of actuated with very intensive Julia builds, and they have been using it to keep their build times in check. We're pleased to be able to offer every enhancement to the CNCF project maintainers too.

\n

Wrapping up

\n

Through the sponsored program, actuated has now run over 70k build minutes for around 10 CNCF projects, and we've heard from a growing number of projects who would like access.

\n

We've secured the supply chain by removing unsafe runners that GitHub says should definitely not be used for open source repositories, and we've lessened the burden of server management on already busy maintainers.

\n

Whilst the original pilot program is now full, we have the capacity to onboard many other projects and would love to work with you. We are happy to offer a discounted subscription if your employer that sponsors your time on the said CNCF project will pay for it. Otherwise, contact us anyway, and we'll put you into email contact with Chris Aniszczyk so you can let him know how this would help you.

","title":"The state of Arm CI for the CNCF","description":"After running over 70k build minutes for top-tier CNCF projects, we give an update on the sponsored Arm CI program.","tags":["efficiency","githubactions","metering"],"author_img":"alex","image":"/images/2024-03-cncf-update/background.png","date":"2024-03-04"}},"__N_SSG":true} \ No newline at end of file diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/custom-sizes-bpf-kvm.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/custom-sizes-bpf-kvm.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/custom-sizes-bpf-kvm.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/custom-sizes-bpf-kvm.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/develop-a-great-go-cli.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/develop-a-great-go-cli.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/develop-a-great-go-cli.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/develop-a-great-go-cli.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/faster-nix-builds.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/faster-nix-builds.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/faster-nix-builds.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/faster-nix-builds.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/faster-self-hosted-cache.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/faster-self-hosted-cache.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/faster-self-hosted-cache.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/faster-self-hosted-cache.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/firecracker-container-lab.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/firecracker-container-lab.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/firecracker-container-lab.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/firecracker-container-lab.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/github-actions-usage-cli.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/github-actions-usage-cli.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/github-actions-usage-cli.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/github-actions-usage-cli.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/how-to-run-multi-arch-builds-natively.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/how-to-run-multi-arch-builds-natively.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/how-to-run-multi-arch-builds-natively.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/how-to-run-multi-arch-builds-natively.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/is-the-self-hosted-runner-safe-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/is-the-self-hosted-runner-safe-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/is-the-self-hosted-runner-safe-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/is-the-self-hosted-runner-safe-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/kvm-in-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/kvm-in-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/kvm-in-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/kvm-in-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/local-caching-for-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/local-caching-for-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/local-caching-for-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/local-caching-for-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/managing-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/managing-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/managing-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/managing-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/multi-arch-docker-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/multi-arch-docker-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/multi-arch-docker-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/multi-arch-docker-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/native-arm64-for-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/native-arm64-for-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/native-arm64-for-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/native-arm64-for-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/oidc-proxy-for-openfaas.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/oidc-proxy-for-openfaas.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/oidc-proxy-for-openfaas.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/oidc-proxy-for-openfaas.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/right-sizing-vms-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/right-sizing-vms-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/right-sizing-vms-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/right-sizing-vms-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/sbom-in-github-actions.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/sbom-in-github-actions.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/sbom-in-github-actions.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/sbom-in-github-actions.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/secure-microvm-ci-gitlab.json b/_next/data/Cxoj3UCPrpnpf54sZEXpk/blog/secure-microvm-ci-gitlab.json similarity index 100% rename from _next/data/bR4Jv3N8T_1-64ExyobFe/blog/secure-microvm-ci-gitlab.json rename to _next/data/Cxoj3UCPrpnpf54sZEXpk/blog/secure-microvm-ci-gitlab.json diff --git a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/cncf-arm-march-update.json b/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/cncf-arm-march-update.json deleted file mode 100644 index 5671721..0000000 --- a/_next/data/bR4Jv3N8T_1-64ExyobFe/blog/cncf-arm-march-update.json +++ /dev/null @@ -1 +0,0 @@ -{"pageProps":{"post":{"slug":"cncf-arm-march-update","fileName":"2024-03-04-cncf-arm-march-update.md","contentHtml":"

It's now been 4 months since we kicked off the sponsored program with the Cloud Native Computing Foundation (CNCF) and Ampere to manage CI for the foundation's open source projects. But even before that, Calyptia, the maintainer of Fluent approached us to run Arm CI for the open source fluent repos, so we've been running CI for CNCF projects since June 2023.

\n

Over that time, we've got to work directly with some really bright, friendly, and helpful maintainers, who wanted to have a safe, fast and secure way to create release artifacts, test PRs, and to run end to end tests. Their alternative until this point was either to go against GitHub's own advice, and to run an unsafe, self-hosted runner on an open source repo, or to use QEMU that in the case of Fluent meant their 5 minute build took over 6 hours before failing.

\n

You can find out more about why we put this program together in the original announcement: Announcing managed Arm CI for CNCF projects

\n

Measuring the impact

\n

When we started out, Chris Aniszczyk, the CNCF's CTO wanted to create a small pilot to see if there'd be enough demand for our service. The CNCF partnered with Ampere to co-fund the program, Ampere sell a number of Arm based CPUs - which they brand as \"Cloud Native\" because they're so dense in cores and highly power efficient. Equinix Metal provide the credits and the hosting via the Cloud Native Credits program.

\n

In a few weeks, not only did we fill up all available slots, but we personally hand-held and onboarded each of the project maintainers one by one, over Zoom, via GitHub, and Slack.

\n

Why would maintainers of top-tier projects need our help? Our team and community has extensive experience porting code to Arm, and building for multiple CPUs. We were able to advise on best practices for splitting up builds, how to right-size VMs, were there to turn on esoteric Kernel modules and configurations, and to generally give them a running start.

\n

Today, our records show that the CNCF projects enrolled have run a total of 70.3k minutes. That's almost the equivalent of a computer running tasks 24/7 for a total of 2 months solid, without a break.

\n

Here's a list of the organisations we've onboarded so far, ordered by the total amount of build minutes. We added the date of their first actuated build to help add some context. As I mentioned in the introduction, fluent have been a paying customer since June 2023.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Rank for build minutesOrganisationDate of first actuated build
1etcd-io (etcd, boltdb)2023-10-24
2fluent2023-06-07
3falcosecurity2023-12-06
4containerd2023-12-02
5cilium (tetragon, cilium, ebpf-go)2023-10-31
6cri-o2023-11-27
7open-telemetry2024-02-14
8opencontainers (runc)2023-12-15
9argoproj2024-01-30
\n

Data sorted by most Arm minutes consumed

\n

Some organisations have been actuated on multiple projects like etcd-io, with boltdb adding to their minutes, and cilium where tetragon and ebpf-go are also now running Arm builds.

\n

It's tempting to look at build minutes as the only metric, however, now that containerd, runc, cilium, etcd, and various other core projects are built by actuated, the security of the supply chain has become far more certain.

\n

From 10,000ft

\n

Here's what we aimed for and have managed to achieve in a very short period of time:

\n\n

Making efficient use of shared resources

\n

After fluent, etcd was the second project to migrate off self-managed runners. They had the impression that one of their jobs needed 32 vCPU and 32GB of RAM, and when we monitored the shared server pool, we noticed barely any load on the servers. That led me to build a quick Linux profiling tool called vmmeter. When they ran the profiler, it turned out the job used a maximum of 1.3 vCPU and 3GB of RAM, that's not just a rounding error - that's a night and day difference.

\n

You can learn how to try out vmmeter to right-size your jobs on actuated, or on GitHub's hosted runners.

\n

Right sizing VMs for GitHub Actions

\n

The projects have had a fairly stable, steady-state of CI jobs throughout the day and night as contributors from around the globe send PRs and end to end tests run.

\n

But with etcd-io in particular we started to notice on Monday or Tuesday that there was a surge of up to 200 jobs all at once. When we asked them about this, they told us Dependabot was the cause. It would send a number of PRs to bump dependencies and that would in turn trigger dozens of jobs.

\n

\"Thundering

\n
\n

Thundering herd problem from dependabot

\n
\n

It would clear itself down in time, but we spent a little time to automate adding in 1-2 extra servers for this period of the week, and we managed to get the queue cleared several times quicker. When the machines are no longer needed, they drain themselves and get deleted. This is important for efficient use of the CNCF's credits and Equinix Metal's fleet of Ampere Altra Q80 Arm servers.

\n

Giving insights to maintainers

\n

I got to meet up with Phil Estes from the containerd project at FOSDEM. We are old friends and used to be Docker Captains together.

\n

We looked at the daily usage stats, looked at the total amount of contributors that month and how many builds they'd had.

\n

\"Phil

\n

Then we opened up the organisation insights page and found that containerd had accounted for 14% of the total build minutes having only been onboarded in Dec 2023.

\n

\"Detailed

\n

We saw that there was a huge peak in jobs last month compared to this month, so he went off to the containerd Slack to ask about what had happened.

\n

Catching build time increases early

\n

Phil also showed me that he used to have a jimmy-rigged dashboard of his own to track build time increases, and at FOSDEM, my team did a mini hackathon to release our own way to show people their job time increases.

\n

We call it \"Job Outliers\" and it can be used to track increases going back as far as 120 days from today.

\n

\"Job

\n

Clicking \"inspect\" on any of the workflows will open up a separate plot link with deep links to the longest job seen on each day of that period of time.

\n

So what changed for our own actuated VM builds in that week, to add 5+ minutes of build time?

\n

\"Maximum

\n

We started building eBPF into the Kernel image, and the impact was 2x 2.5 minutes of build time.

\n

This feature was originally requested by Toolpath, a commercial user of actuated with very intensive Julia builds, and they have been using it to keep their build times in check. We're pleased to be able to offer every enhancement to the CNCF project maintainers too.

\n

Wrapping up

\n

Through the sponsored program, actuated has now run over 70k build minutes for around 10 CNCF projects, and we've heard from a growing number of projects who would like access.

\n

We've secured the supply chain by removing unsafe runners that GitHub says should definitely not be used for open source repositories, and we've lessened the burden of server management on already busy maintainers.

\n

Whilst the original pilot program is now full, we have the capacity to onboard many other projects and would love to work with you. We are happy to offer a discounted subscription if your employer that sponsors your time on the said CNCF project will pay for it. Otherwise, contact us anyway, and we'll put you into email contact with Chris Aniszczyk so you can let him know how this would help you.

","title":"The state of Arm CI for the CNCF","description":"After running over 70k build minutes for top-tier CNCF projects, we give an update on the sponsored Arm CI program.","tags":["efficiency","githubactions","metering"],"author_img":"alex","image":"/images/2024-03-cncf-update/background.png","date":"2024-03-04"}},"__N_SSG":true} \ No newline at end of file diff --git a/_next/static/bR4Jv3N8T_1-64ExyobFe/_buildManifest.js b/_next/static/Cxoj3UCPrpnpf54sZEXpk/_buildManifest.js similarity index 100% rename from _next/static/bR4Jv3N8T_1-64ExyobFe/_buildManifest.js rename to _next/static/Cxoj3UCPrpnpf54sZEXpk/_buildManifest.js diff --git a/_next/static/bR4Jv3N8T_1-64ExyobFe/_ssgManifest.js b/_next/static/Cxoj3UCPrpnpf54sZEXpk/_ssgManifest.js similarity index 100% rename from _next/static/bR4Jv3N8T_1-64ExyobFe/_ssgManifest.js rename to _next/static/Cxoj3UCPrpnpf54sZEXpk/_ssgManifest.js diff --git a/blog.html b/blog.html index 6991e93..42cbd6a 100644 --- a/blog.html +++ b/blog.html @@ -4,4 +4,4 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Actuated Blog

The latest news, tutorials, case-studies, and announcements.

\ No newline at end of file +
ActuatedActuated logo

Actuated Blog

The latest news, tutorials, case-studies, and announcements.

\ No newline at end of file diff --git a/blog/amd-zenbleed-update-now.html b/blog/amd-zenbleed-update-now.html index 14c4688..e72ea0a 100644 --- a/blog/amd-zenbleed-update-now.html +++ b/blog/amd-zenbleed-update-now.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Update your AMD hosts now to mitigate the Zenbleed exploit

Learn how to update the microcode on your AMD CPU to avoid the Zenbleed exploit.

On 24th July 2023, The Register covered a new exploit for certain AMD CPUs based upon the Zen architecture. The exploit, dubbed Zenbleed, allows an attacker to read arbitrary physical memory locations on the host system. It works by allowing memory to be read after it's been set to be freed up aka "use-after-free". This is a serious vulnerability, and you should update your AMD hosts as soon as possible.

+
ActuatedActuated logo

Update your AMD hosts now to mitigate the Zenbleed exploit

Learn how to update the microcode on your AMD CPU to avoid the Zenbleed exploit.

On 24th July 2023, The Register covered a new exploit for certain AMD CPUs based upon the Zen architecture. The exploit, dubbed Zenbleed, allows an attacker to read arbitrary physical memory locations on the host system. It works by allowing memory to be read after it's been set to be freed up aka "use-after-free". This is a serious vulnerability, and you should update your AMD hosts as soon as possible.

The Register made the claim that "any level of emulation such as QEMU" would prevent the exploit from working. This is misleading because QEMU only makes sense in production when used with hardware acceleration (KVM). We were able to run the exploit with a GitHub Action using actuated on an AMD Epyc server from Equinix Metal using Firecracker and KVM.

"If you stick any emulation layer in between, such as Qemu, then the exploit understandably fails."

@@ -100,4 +100,4 @@

Verifying the mitigation

Wrapping up

Actuated uses Firecracker, an open source Virtual Machine Manager (VMM) that works with Linux KVM to run isolated systems on a host. We have verified that the exploit works on Firecracker, and that the mitigation works too. So whilst VM-level isolation and an immutable filesystem is much more appropriate than a container for CI, this is an example of why we must still be vigilant and ready to respond to security vulnerabilities.

-

This is an unfortunate, and serious vulnerability. It affects bare-metal, VMs and containers, which is why it's important to update your systems as soon as possible.

\ No newline at end of file +

This is an unfortunate, and serious vulnerability. It affects bare-metal, VMs and containers, which is why it's important to update your systems as soon as possible.

\ No newline at end of file diff --git a/blog/arm-ci-cncf-ampere.html b/blog/arm-ci-cncf-ampere.html index bbeb8ee..14bc6be 100644 --- a/blog/arm-ci-cncf-ampere.html +++ b/blog/arm-ci-cncf-ampere.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Announcing managed Arm CI for CNCF projects

Ampere Computing and The Cloud Native Computing Foundation are sponsoring a pilot of actuated's managed Arm CI for CNCF projects.

In this post, we'll cover why Ampere Computing and The Cloud Native Computing Foundation (CNCF) are sponsoring a pilot of actuated for open source projects, how you can get involved.

+
ActuatedActuated logo

Announcing managed Arm CI for CNCF projects

Ampere Computing and The Cloud Native Computing Foundation are sponsoring a pilot of actuated's managed Arm CI for CNCF projects.

In this post, we'll cover why Ampere Computing and The Cloud Native Computing Foundation (CNCF) are sponsoring a pilot of actuated for open source projects, how you can get involved.

We'll also give you a quick one year recap on actuated, if you haven't checked in with us for a while.

Managed Arm CI for CNCF projects

At KubeCon EU, I spoke to Chris Aniszczyk, CTO at the Cloud Native Computing Foundation (CNCF), and told him about some of the results we'd been seeing with actuated customers, including Fluent Bit, which is a CNCF project. Chris told me that many teams were either putting off Arm support all together, were suffering with the slow builds that come from using QEMU, or were managing their own infrastructure which was underutilized.

@@ -88,4 +88,4 @@

Learn more about actuated

Did you know? Actuated for GitLab CI is now in technical preview, watch a demo here.

-
\ No newline at end of file +
\ No newline at end of file diff --git a/blog/automate-packer-qemu-image-builds.html b/blog/automate-packer-qemu-image-builds.html index 32ca641..f35f3a9 100644 --- a/blog/automate-packer-qemu-image-builds.html +++ b/blog/automate-packer-qemu-image-builds.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Automate Packer Images with QEMU and Actuated

Learn how to automate Packer images using QEMU and nested virtualisation through actuated.

One of the most popular tools for creating images for virtual machines is Packer by Hashicorp. Packer automates the process of building images for a variety of platforms from a single source configuration. Different builders can be used to create machines and generate images from those machines.

+
ActuatedActuated logo

Automate Packer Images with QEMU and Actuated

Learn how to automate Packer images using QEMU and nested virtualisation through actuated.

One of the most popular tools for creating images for virtual machines is Packer by Hashicorp. Packer automates the process of building images for a variety of platforms from a single source configuration. Different builders can be used to create machines and generate images from those machines.

In this tutorial we will use the QEMU builder to create a KVM virtual machine image.

We will see how the Packer build can be completely automated by integrating Packer into a continuous integration (CI) pipeline with GitHub Actions. The workflow will automatically trigger image builds on changes and publish the resulting images as GitHub release artifacts.

Actuated supports nested virtualsation where a VM can make use of KVM to launch additional VMs within a GitHub Action. This makes it possible to run the Packer QEMU builder in GitHub Action workflows. Something that is not possible with GitHub's default hosted runners.

@@ -236,4 +236,4 @@

Taking it further

We exported the image in qcow2 format but you might need a different image format. The QEMU builder also supports outputting images in raw format. In our Packer template the output format can be changed by setting the format variable.

Additional tools like the qemu disk image utility can also be used to convert images between different formats. A post-processor would be the ideal place for these kinds of extra processing steps.

AWS also supports importing VM images and converting them to an AMI so they can be used to launch EC2 instances. See: Create an AMI from a VM image

-

If you'd like to know more about nested virtualisation support, check out: How to run KVM guests in your GitHub Actions

\ No newline at end of file +

If you'd like to know more about nested virtualisation support, check out: How to run KVM guests in your GitHub Actions

\ No newline at end of file diff --git a/blog/blazing-fast-ci-with-microvms.html b/blog/blazing-fast-ci-with-microvms.html index 2bc79ed..edca77c 100644 --- a/blog/blazing-fast-ci-with-microvms.html +++ b/blog/blazing-fast-ci-with-microvms.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Blazing fast CI with MicroVMs

Alex Ellis

I saw an opportunity to fix self-hosted runners for GitHub Actions. Actuated is now in pilot and aims to solve most if not all of the friction.

Around 6-8 months ago I started exploring MicroVMs out of curiosity. Around the same time, I saw an opportunity to fix self-hosted runners for GitHub Actions. Actuated is now in pilot and aims to solve most if not all of the friction.

+
ActuatedActuated logo

Blazing fast CI with MicroVMs

Alex Ellis

I saw an opportunity to fix self-hosted runners for GitHub Actions. Actuated is now in pilot and aims to solve most if not all of the friction.

Around 6-8 months ago I started exploring MicroVMs out of curiosity. Around the same time, I saw an opportunity to fix self-hosted runners for GitHub Actions. Actuated is now in pilot and aims to solve most if not all of the friction.

There's three parts to this post:

  1. A quick debrief on Firecracker and MicroVMs vs legacy solutions
    2. @@ -172,4 +172,4 @@

    What are people saying about actuated?

    This is awesome!" (After reducing Parca build time from 33.5 minutes to 1 minute 26s)

    Frederic Branczyk, Co-founder, Polar Signals

    -
\ No newline at end of file +
\ No newline at end of file diff --git a/blog/caching-in-github-actions.html b/blog/caching-in-github-actions.html index d6c4865..b3899a2 100644 --- a/blog/caching-in-github-actions.html +++ b/blog/caching-in-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Make your builds run faster with Caching for GitHub Actions

Han Verstraete

Learn how we made a Golang project build 4x faster using GitHub's built-in caching mechanism.

GitHub provides a cache action that allows caching dependencies and build outputs to improve workflow execution time.

+
ActuatedActuated logo

Make your builds run faster with Caching for GitHub Actions

Han Verstraete

Learn how we made a Golang project build 4x faster using GitHub's built-in caching mechanism.

GitHub provides a cache action that allows caching dependencies and build outputs to improve workflow execution time.

A common use case would be to cache packages and dependencies from tools such as npm, pip, Gradle, ... . If you are using Go, caching go modules and the build cache can save you a significant amount of build time as we will see in the next section.

Caching can be configured manually, but a lot of setup actions already use the actions/cache under the hood and provide a configuration option to enable caching.

We use the actions cache to speed up workflows for building the Actuated base images. As part of those workflows we build a kernel and then a rootfs. Since the kernel’s configuration is changed infrequently it makes sense to cache that output.

@@ -106,4 +106,4 @@

Conclusion

Want to learn more about Go and GitHub Actions?

Alex's eBook Everyday Golang has a chapter dedicated to building Go programs with Docker and GitHub Actions.

-
\ No newline at end of file +
\ No newline at end of file diff --git a/blog/calyptia-case-study-arm.html b/blog/calyptia-case-study-arm.html index e43d719..7991084 100644 --- a/blog/calyptia-case-study-arm.html +++ b/blog/calyptia-case-study-arm.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

How Calyptia fixed its Arm builds whilst saving money

Learn how Calyptia fixed its failing Arm builds for open-source Fluent Bit and accelerated our commercial development by adopting Actuated and bare-metal runners.

This is a case-study, and guest article by Patrick Stephens, Tech Lead of Infrastructure at Calyptia.

+
ActuatedActuated logo

How Calyptia fixed its Arm builds whilst saving money

Learn how Calyptia fixed its failing Arm builds for open-source Fluent Bit and accelerated our commercial development by adopting Actuated and bare-metal runners.

This is a case-study, and guest article by Patrick Stephens, Tech Lead of Infrastructure at Calyptia.

Introduction

Different architecture builds can be slow using the Github Actions hosted runners due to emulation of the non-native architecture for the build. This blog shows a simple way to make use of self-hosted runners for dedicated builds but in a secure and easy to maintain fashion.

Calyptia maintains the OSS and Cloud Native Computing Foundation (CNCF) graduated Fluent projects including Fluent Bit. We then add value to the open-source core by providing commercial services and enterprise-level features.

@@ -118,4 +118,4 @@

Actuated support

Conclusion

Alex Ellis: We've learned a lot working with Patrick and Calyptia and are pleased to see that they were able to save money, whilst getting much quicker, and safer Open Source and commercial builds.

We value getting feedback and suggestions from customers, and Patrick continues to provide plenty of them.

-

If you'd like to learn more about actuated, reach out to speak to our team by clicking "Sign-up" and filling out the form. We'll be in touch to arrange a call.

\ No newline at end of file +

If you'd like to learn more about actuated, reach out to speak to our team by clicking "Sign-up" and filling out the form. We'll be in touch to arrange a call.

\ No newline at end of file diff --git a/blog/case-study-bring-your-own-bare-metal-to-actions.html b/blog/case-study-bring-your-own-bare-metal-to-actions.html index c1b4a01..7319459 100644 --- a/blog/case-study-bring-your-own-bare-metal-to-actions.html +++ b/blog/case-study-bring-your-own-bare-metal-to-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
ActuatedActuated logo

Bring Your Own Metal Case Study with GitHub Actions

Alex Ellis

See how BYO bare-metal made a 6 hour GitHub Actions build complete 25x faster.

I'm going to show you how both a regular x86_64 build and an Arm build were made dramatically faster by using Bring Your Own (BYO) bare-metal servers.

+
ActuatedActuated logo

Bring Your Own Metal Case Study with GitHub Actions

Alex Ellis

See how BYO bare-metal made a 6 hour GitHub Actions build complete 25x faster.

I'm going to show you how both a regular x86_64 build and an Arm build were made dramatically faster by using Bring Your Own (BYO) bare-metal servers.

At the early stage of a project, GitHub's standard runners with 2x cores, 8GB RAM, and a little free disk space are perfect because they're free for public repos. For private repos they come in at a modest cost, if you keep your usage low.

What's not to love?

Well, Ed Warnicke, Distinguished Engineer at Cisco contacted me a few weeks ago and told me about the VPP project, and some of the problems he was running into trying to build it with hosted runners.

@@ -99,4 +99,4 @@

Want to work with us?

  • The efficient way to publish multi-arch containers from GitHub Actions
  • Is the GitHub Actions self-hosted runner safe for Open Source?
  • How to make GitHub Actions 22x faster with bare-metal Arm
    • -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/cncf-arm-march-update.html b/blog/cncf-arm-march-update.html index 05e7ebf..41c6a4a 100644 --- a/blog/cncf-arm-march-update.html +++ b/blog/cncf-arm-march-update.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    The state of Arm CI for the CNCF

    After running over 70k build minutes for top-tier CNCF projects, we give an update on the sponsored Arm CI program.

    It's now been 4 months since we kicked off the sponsored program with the Cloud Native Computing Foundation (CNCF) and Ampere to manage CI for the foundation's open source projects. But even before that, Calyptia, the maintainer of Fluent approached us to run Arm CI for the open source fluent repos, so we've been running CI for CNCF projects since June 2023.

    +
    ActuatedActuated logo

    The state of Arm CI for the CNCF

    After running over 70k build minutes for top-tier CNCF projects, we give an update on the sponsored Arm CI program.

    It's now been 4 months since we kicked off the sponsored program with the Cloud Native Computing Foundation (CNCF) and Ampere to manage CI for the foundation's open source projects. But even before that, Calyptia, the maintainer of Fluent approached us to run Arm CI for the open source fluent repos, so we've been running CI for CNCF projects since June 2023.

    Over that time, we've got to work directly with some really bright, friendly, and helpful maintainers, who wanted to have a safe, fast and secure way to create release artifacts, test PRs, and to run end to end tests. Their alternative until this point was either to go against GitHub's own advice, and to run an unsafe, self-hosted runner on an open source repo, or to use QEMU that in the case of Fluent meant their 5 minute build took over 6 hours before failing.

    You can find out more about why we put this program together in the original announcement: Announcing managed Arm CI for CNCF projects

    Measuring the impact

    @@ -16,7 +16,7 @@

    Measuring the impact

    - + @@ -109,4 +109,4 @@

    Measuring the impact

    Wrapping up

    Through the sponsored program, actuated has now run over 70k build minutes for around 10 CNCF projects, and we've heard from a growing number of projects who would like access.

    We've secured the supply chain by removing unsafe runners that GitHub says should definitely not be used for open source repositories, and we've lessened the burden of server management on already busy maintainers.

    -

    Whilst the original pilot program is now full, we have the capacity to onboard many other projects and would love to work with you. We are happy to offer a discounted subscription if your employer that sponsors your time on the said CNCF project will pay for it. Otherwise, contact us anyway, and we'll put you into email contact with Chris Aniszczyk so you can let him know how this would help you.

    \ No newline at end of file +

    Whilst the original pilot program is now full, we have the capacity to onboard many other projects and would love to work with you. We are happy to offer a discounted subscription if your employer that sponsors your time on the said CNCF project will pay for it. Otherwise, contact us anyway, and we'll put you into email contact with Chris Aniszczyk so you can let him know how this would help you.

    \ No newline at end of file diff --git a/blog/custom-sizes-bpf-kvm.html b/blog/custom-sizes-bpf-kvm.html index 57774fb..44f67ed 100644 --- a/blog/custom-sizes-bpf-kvm.html +++ b/blog/custom-sizes-bpf-kvm.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    December Boost: Custom Job Sizes, eBPF Support & KVM Acceleration

    You can now request custom amounts of RAM and vCPU for jobs, run eBPF within jobs, and use KVM acceleration.

    In this December update, we've got three new updates to the platform that we think you'll benefit from. From requesting custom vCPU and RAM per job, to eBPF features, to spreading your plan across multiple machines dynamically, it's all new and makes actuated better value.

    +
    ActuatedActuated logo

    December Boost: Custom Job Sizes, eBPF Support & KVM Acceleration

    You can now request custom amounts of RAM and vCPU for jobs, run eBPF within jobs, and use KVM acceleration.

    In this December update, we've got three new updates to the platform that we think you'll benefit from. From requesting custom vCPU and RAM per job, to eBPF features, to spreading your plan across multiple machines dynamically, it's all new and makes actuated better value.

    New eBPF support and 5.10.201 Kernel

    And as part of our work to provide hosted Arm CI for CNCF projects, including Tetragon and Cilium, we've now enabled eBPF and BTF features within the Kernel.

    @@ -68,4 +68,4 @@

    Wrapping up

    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/develop-a-great-go-cli.html b/blog/develop-a-great-go-cli.html index 5502411..202b41a 100644 --- a/blog/develop-a-great-go-cli.html +++ b/blog/develop-a-great-go-cli.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    How to develop a great CLI with Go

    Alex shares his insights from building half a dozen popular Go CLIs. Which can you apply to your projects?

    Is your project's CLI growing with you? I'll cover some of the lessons learned writing the OpenFaaS, actuated, actions-usage, arkade and k3sup CLIs, going as far back as 2016. I hope you'll find some ideas or inspiration for your own projects - either to start them off, or to improve them as you go along.

    +
    ActuatedActuated logo

    How to develop a great CLI with Go

    Alex shares his insights from building half a dozen popular Go CLIs. Which can you apply to your projects?

    Is your project's CLI growing with you? I'll cover some of the lessons learned writing the OpenFaaS, actuated, actions-usage, arkade and k3sup CLIs, going as far back as 2016. I hope you'll find some ideas or inspiration for your own projects - either to start them off, or to improve them as you go along.

    Just starting your journey, or want to go deeper?

    You can master the fundamentals of Go (also called Golang) with my eBook Everyday Golang, which includes chapters on Go routines, HTTP clients and servers, text templates, unit testing and crafting a CLI. If you're on a budget, I would recommend checkout out the official Go tour, too.

    @@ -228,4 +228,4 @@

    Wrapping up

  • faas-cli - CLI client for OpenFaaS
  • k3sup - Install K3s over SSH
  • arkade - Download CLI tools from GitHub releases
    • -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/faster-nix-builds.html b/blog/faster-nix-builds.html index 651ae5c..64f24a5 100644 --- a/blog/faster-nix-builds.html +++ b/blog/faster-nix-builds.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Faster Nix builds with GitHub Actions and actuated

    Speed up your Nix project builds on GitHub Actions with runners powered by Firecracker.

    faasd is a lightweight and portable version of OpenFaaS that was created to run on a single host. In my spare time I maintain faasd-nix, a project that packages faasd and exposes a NixOS module so it can be run with NixOS.

    +
    ActuatedActuated logo

    Faster Nix builds with GitHub Actions and actuated

    Speed up your Nix project builds on GitHub Actions with runners powered by Firecracker.

    faasd is a lightweight and portable version of OpenFaaS that was created to run on a single host. In my spare time I maintain faasd-nix, a project that packages faasd and exposes a NixOS module so it can be run with NixOS.

    The module itself depends on faasd, containerd and the CNI plugins and all of these binaries are built in CI with Nix and then cached using Cachix to save time on subsequent builds.

    I often deploy faasd with NixOS on a Raspberry Pi and to the cloud, so I build binaries for both x86_64 and aarch64. The build usually runs on the default GitHub hosted action runners. Now because GitHub currently doesn't have Arm support, I use QEMU instead which can emulate them. The drawback of this approach is that builds can sometimes be several times slower.

    @@ -107,4 +107,4 @@

    Wrapping up

    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/faster-self-hosted-cache.html b/blog/faster-self-hosted-cache.html index 3025afa..8153ee8 100644 --- a/blog/faster-self-hosted-cache.html +++ b/blog/faster-self-hosted-cache.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Fixing the cache latency for self-hosted GitHub Actions

    The cache for GitHub Actions can speed up CI/CD pipelines. But what about when it slows you down?

    In some of our builds for actuated we cache things like the Linux Kernel, so we don't needlessly rebuild it when we update packages in our base images. It can shave minutes off every build meaning our servers can be used more efficiently. Most customers we've seen so far only make light to modest use of GitHub's hosted cache, so haven't noticed much of a latency problem.

    +
    ActuatedActuated logo

    Fixing the cache latency for self-hosted GitHub Actions

    The cache for GitHub Actions can speed up CI/CD pipelines. But what about when it slows you down?

    In some of our builds for actuated we cache things like the Linux Kernel, so we don't needlessly rebuild it when we update packages in our base images. It can shave minutes off every build meaning our servers can be used more efficiently. Most customers we've seen so far only make light to modest use of GitHub's hosted cache, so haven't noticed much of a latency problem.

    But you don't have to spend too long on the issuer tracker for GitHub Actions to find people complaining about the cache being slow or locking up completely for self-hosted runners.

    Go, Rust, Python and other languages don't tend to make heavy use of caches, and Docker has some of its own mechanisms like building cached steps into published images aka inline caching. But for the Node.js ecosystem, the node_modules folder and yarn cache can become huge and take a long time to download. That's one place where you may start to see tension between the speed of self-hosted runners and the latency of the cache. If your repository is a monorepo or has lots of large artifacts, you may get a speed boost by caching that too.

    So why is GitHub's cache so fast for hosted runners, and (sometimes) so slow self-hosted runners?

    @@ -184,4 +184,4 @@

    Conclusion

    You can find out how to configure a container mirror for the Docker Hub using actuated here: Set up a registry mirror. When testing builds for the Discourse team, there was a 2.5GB container image used for UI testing with various browsers preinstalled within it. We found that we could shave off a few minutes off the build time by using the local mirror. Imagine 10x of those builds running at once, needlessly downloading 250GB of data.

    What if you're not an actuated customer? Can you still benefit from a faster cache? You could try out a hosted service like AWS S3 or Google Cloud Storage, provisioned in a region closer to your runners. The speed probably won't quite be as good, but it should still be a lot faster than reaching over the Internet to GitHub's cache.

    If you'd like to try out actuated for your team, reach out to us to find out more.

    -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/firecracker-container-lab.html b/blog/firecracker-container-lab.html index 126aa60..c1b538f 100644 --- a/blog/firecracker-container-lab.html +++ b/blog/firecracker-container-lab.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Grab your lab coat - we're building a microVM from a container

    No more broken tutorials, build a microVM from a container, boot it, access the Internet

    When I started learning Firecracker, I ran into frustration after frustration with broken tutorials that were popular in their day, but just hadn't been kept up to date. Almost nothing worked, or was far too complex for the level of interest I had at the time. Most recently, one of the Firecracker maintainers in an effort to make the quickstart better, made it even harder to use. (You can still get a copy of the original Firecracker quickstart in our tutorial on nested virtualisation)

    +
    ActuatedActuated logo

    Grab your lab coat - we're building a microVM from a container

    No more broken tutorials, build a microVM from a container, boot it, access the Internet

    When I started learning Firecracker, I ran into frustration after frustration with broken tutorials that were popular in their day, but just hadn't been kept up to date. Almost nothing worked, or was far too complex for the level of interest I had at the time. Most recently, one of the Firecracker maintainers in an effort to make the quickstart better, made it even harder to use. (You can still get a copy of the original Firecracker quickstart in our tutorial on nested virtualisation)

    So I wrote a lab that takes a container image and converts it to a microVM. You'll get your hands dirty, you'll run a microVM, you'll be able to use curl and ssh, even expose a HTTP server to the Internet via inlets, if (like me), you find that kind of thing fun.

    Why would you want to explore Firecracker? A friend of mine, Ivan Velichko is a prolific writer on containers, and Docker. He is one of the biggest independent evangelists for containers and Kubernetes that I know.

    So when he wanted to build an online labs and training environment, why did he pick Firecracker instead? Simply put, he told us that containers don't cut it. He needed something that would mirror the type of machine that you'd encounter in production, when you provision an EC2 instance or a GCP VM. Running Docker, Kubernetes, and performing are hard to do securely within a container, and he knew that was important for his students.

    @@ -208,4 +208,4 @@

    Wrapping up

    Did you enjoy the lab? Have you got a use-case for Firecracker? Let me know on Twitter @alexellisuk

    If you'd like to see how we've applied Firecracker to bring fast and secure CI to teams, check out our product actuated.dev

    Here's a quick demo of our control-plane, scheduler and bare-metal agent in action:

    -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/github-actions-usage-cli.html b/blog/github-actions-usage-cli.html index d78083d..8701039 100644 --- a/blog/github-actions-usage-cli.html +++ b/blog/github-actions-usage-cli.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Understand your usage of GitHub Actions

    Learn how you or your team is using GitHub Actions across your personal account or organisation.

    Whenever GitHub Actions users get in touch with us to ask about actuated, we ask them a number of questions. What do you build? What pain points have you been running into? What are you currently spending? And then - how many minutes are you using?

    +
    ActuatedActuated logo

    Understand your usage of GitHub Actions

    Learn how you or your team is using GitHub Actions across your personal account or organisation.

    Whenever GitHub Actions users get in touch with us to ask about actuated, we ask them a number of questions. What do you build? What pain points have you been running into? What are you currently spending? And then - how many minutes are you using?

    That final question is a hard one for many to answer because the GitHub UI and API will only show billable minutes. Why is that a problem? Some teams only use open-source repositories with free runners. Others may have a large free allowance of credit for one reason or another and so also don't really know what they're using. Then you have people who already use some form of self-hosted runners - they are also excluded from what GitHub shows you.

    So we built an Open Source CLI tool called actions-usage to generate a report of your total minutes by querying GitHub's REST API.

    And over time, we had requests to break-down per day - so for our customers in the Middle East like Kubiya, it's common to see a very busy day on Sunday, and not a lot of action on Friday. Given that some teams use mono-repos, we also added the ability to break-down per repository - so you can see which ones are the most active. And finally, we added the ability to see hot-spots of usage like the longest running repo or the most active day.

    @@ -156,4 +156,4 @@

    Wrapping up

    Check out self-actuated/actions-usage on GitHub

    I wrote an eBook writing CLIs like this in Go and keep it up to date on a regular basis - adding new examples and features of Go.

    Why not check out what people are saying about it on Gumroad?

    -

    Everyday Go - The Fast Track

    \ No newline at end of file +

    Everyday Go - The Fast Track

    \ No newline at end of file diff --git a/blog/how-to-run-multi-arch-builds-natively.html b/blog/how-to-run-multi-arch-builds-natively.html index 50000dd..f4d65e2 100644 --- a/blog/how-to-run-multi-arch-builds-natively.html +++ b/blog/how-to-run-multi-arch-builds-natively.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    How to split up multi-arch Docker builds to run natively

    Alex Ellis

    QEMU is a convenient way to publish containers for multiple architectures, but it can be incredibly slow. Native is much faster.

    In two previous articles, we covered huge improvements in performance for the Parca project and VPP (Network Service Mesh) simply by switching to actuated with Arm64 runners instead of using QEMU and hosted runners.

    +
    ActuatedActuated logo

    How to split up multi-arch Docker builds to run natively

    Alex Ellis

    QEMU is a convenient way to publish containers for multiple architectures, but it can be incredibly slow. Native is much faster.

    In two previous articles, we covered huge improvements in performance for the Parca project and VPP (Network Service Mesh) simply by switching to actuated with Arm64 runners instead of using QEMU and hosted runners.

    In the first case, using QEMU took over 33 minutes, and bare-metal Arm showed a 22x improvement at only 1 minute 26 seconds. For Network Service Mesh, VPP couldn't even complete a build in 6 hours using QEMU - and I got it down to 9 minutes flat using a bare-metal Ampere Altra server.

    What are we going to see and why is it better?

    In this article, I'll show you how to run multi-arch builds natively on bare-metal hardware using GitHub Actions and actuated.

    @@ -252,4 +252,4 @@

    Wrapping up

    Want to talk to us about your CI/CD needs? We're happy to help.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/is-the-self-hosted-runner-safe-github-actions.html b/blog/is-the-self-hosted-runner-safe-github-actions.html index 8785908..f96917c 100644 --- a/blog/is-the-self-hosted-runner-safe-github-actions.html +++ b/blog/is-the-self-hosted-runner-safe-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Is the GitHub Actions self-hosted runner safe for Open Source?

    Alex Ellis

    GitHub warns against using self-hosted Actions runners for public repositories - but why? And are there alternatives?

    First of all, why would someone working on an open source project need a self-hosted runner?

    +
    ActuatedActuated logo

    Is the GitHub Actions self-hosted runner safe for Open Source?

    Alex Ellis

    GitHub warns against using self-hosted Actions runners for public repositories - but why? And are there alternatives?

    First of all, why would someone working on an open source project need a self-hosted runner?

    Having contributed to dozens of open source projects, and gotten to know many different maintainers, the primary reason tends to be out of necessity. They face an 18 minute build time upon every commit or Pull Request revision, and want to make the best of what little time they can give over to Open Source.

    Having faster builds also lowers friction for contributors, and since many contributors are unpaid and rely on their own internal drive and enthusiasm, a fast build time can be the difference between them fixing a broken test or waiting another few days.

    To sum up, there are probably just a few main reasons:

    @@ -121,4 +121,4 @@

    Get involved today

  • Find a server for your builds
  • Register for actuated
    • -

    Follow us on Twitter - selfactuated

    \ No newline at end of file +

    Follow us on Twitter - selfactuated

    \ No newline at end of file diff --git a/blog/kvm-in-github-actions.html b/blog/kvm-in-github-actions.html index 765794e..cde6628 100644 --- a/blog/kvm-in-github-actions.html +++ b/blog/kvm-in-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    How to run KVM guests in your GitHub Actions

    Han Verstraete

    From building cloud images, to running NixOS tests and the android emulator, we look at how and why you'd want to run a VM in GitHub Actions.

    GitHub's hosted runners do not support nested virtualization. This means some frequently used tools that require KVM like packer, the Android emulator, etc can not be used in GitHub Actions CI pipelines.

    +
    ActuatedActuated logo

    How to run KVM guests in your GitHub Actions

    Han Verstraete

    From building cloud images, to running NixOS tests and the android emulator, we look at how and why you'd want to run a VM in GitHub Actions.

    GitHub's hosted runners do not support nested virtualization. This means some frequently used tools that require KVM like packer, the Android emulator, etc can not be used in GitHub Actions CI pipelines.

    We noticed there are quite a few issues for people requesting KVM support for GitHub Actions:

    Want to see a demo or talk to our team? Contact us here

    -

    Just want to try it out instead? Register your GitHub Organisation and set-up a subscription

    \ No newline at end of file +

    Just want to try it out instead? Register your GitHub Organisation and set-up a subscription

    \ No newline at end of file diff --git a/blog/local-caching-for-github-actions.html b/blog/local-caching-for-github-actions.html index 672e772..7ab67b2 100644 --- a/blog/local-caching-for-github-actions.html +++ b/blog/local-caching-for-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Testing the impact of a local cache for building Discourse

    We compare the impact of switching Discourse's GitHub Actions from self-hosted runners and a hosted cache, to a local cache with S3.

    We heard from the Discourse project last year because they were looking to speed up their builds. After trying out a couple of solutions that automated self-hosted runners, they found out that whilst faster CPUs were nice, reliability was a problem and the cache hosted on GitHub's network became the new bottleneck. We ran some tests to compare the hosted cache with hosted runners, to self-hosted with a local cache running with S3. This post will cover what we found.

    +
    ActuatedActuated logo

    Testing the impact of a local cache for building Discourse

    We compare the impact of switching Discourse's GitHub Actions from self-hosted runners and a hosted cache, to a local cache with S3.

    We heard from the Discourse project last year because they were looking to speed up their builds. After trying out a couple of solutions that automated self-hosted runners, they found out that whilst faster CPUs were nice, reliability was a problem and the cache hosted on GitHub's network became the new bottleneck. We ran some tests to compare the hosted cache with hosted runners, to self-hosted with a local cache running with S3. This post will cover what we found.

    Discourse logo

    Discourse is the online home for your community. We offer a 100% open source community platform to those who want complete control over how and where their site is run.

    @@ -96,4 +96,4 @@

    Conclusion

  • Make your builds run faster with Caching for GitHub Actions
  • Fixing the cache latency for self-hosted GitHub Actions
  • Is GitHub's self-hosted runner safe for open source?
    • -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/managing-github-actions.html b/blog/managing-github-actions.html index 865164c..ef22ecf 100644 --- a/blog/managing-github-actions.html +++ b/blog/managing-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Lessons learned managing GitHub Actions and Firecracker

    Alex Ellis

    Alex shares lessons from building a managed service for GitHub Actions with Firecracker.

    Over the past few months, we've launched over 20,000 VMs for customers and have handled over 60,000 webhook messages from the GitHub API. We've learned a lot from every customer PoC and from our own usage in OpenFaaS.

    +
    ActuatedActuated logo

    Lessons learned managing GitHub Actions and Firecracker

    Alex Ellis

    Alex shares lessons from building a managed service for GitHub Actions with Firecracker.

    Over the past few months, we've launched over 20,000 VMs for customers and have handled over 60,000 webhook messages from the GitHub API. We've learned a lot from every customer PoC and from our own usage in OpenFaaS.

    First of all - what is it we're offering? And how is it different to managed runners and the self-hosted runner that GitHub offers?

    Actuated replicates the hosted experience you get from paying for hosted runners, and brings it to hardware under your own control. That could be a bare-metal Arm server, or a regular Intel/AMD cloud VM that has nested virtualisation enabled.

    Just like managed runners - every time actuated starts up a runner, it's within a single-tenant virtual machine (VM), with an immutable filesystem.

    @@ -132,4 +132,4 @@

    Wrapping up

    Whilst there was a significant amount of very technical work at the beginning of actuated, most of our time now is spent on customer support, education, and improving the onboarding experience.

    If you'd like to know how actuated compares to hosted runners or managing the self-hosted runner on your own, we'd encourage checking out the blog and FAQ.

    Are your builds slowing the team down? Do you need better organisation-level insights and reporting? Or do you need Arm support? Are you frustrated with managing self-hosted runners?

    -

    Reach out to us take part in the pilot

    \ No newline at end of file +

    Reach out to us take part in the pilot

    \ No newline at end of file diff --git a/blog/multi-arch-docker-github-actions.html b/blog/multi-arch-docker-github-actions.html index 43f5543..5f16f9e 100644 --- a/blog/multi-arch-docker-github-actions.html +++ b/blog/multi-arch-docker-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    The efficient way to publish multi-arch containers from GitHub Actions

    Alex Ellis

    Learn how to publish container images for both Arm and Intel machines from GitHub Actions.

    In 2017, I wrote an article on multi-stage builds with Docker, and it's now part of the Docker Documentation. In my opinion, multi-arch builds were the proceeding step in the evolution of container images.

    +
    ActuatedActuated logo

    The efficient way to publish multi-arch containers from GitHub Actions

    Alex Ellis

    Learn how to publish container images for both Arm and Intel machines from GitHub Actions.

    In 2017, I wrote an article on multi-stage builds with Docker, and it's now part of the Docker Documentation. In my opinion, multi-arch builds were the proceeding step in the evolution of container images.

    What's multi-arch and why should you care?

    If you want users to be able to use your containers on different types of computer, then you'll often need to build different versions of your binaries and containers.

    The faas-cli tool is how users interact with OpenFaaS.

    @@ -222,4 +222,4 @@

    Putting it all together

    A word of caution

    QEMU can be incredibly slow at times when using a hosted runner, where a build takes takes 1-2 minutes can extend to over half an hour. If you do run into that, one option is to check out actuated or another solution, which can build directly on an Arm server with a securely isolated Virtual Machine.

    In How to make GitHub Actions 22x faster with bare-metal Arm, we showed how we decreased the build time of an open-source Go project from 30.5 mins to 1.5 mins. If this is the direction you go in, you can use a matrix-build instead of a QEMU-based multi-arch build.

    -

    See also: Recommended bare-metal Arm servers

    \ No newline at end of file +

    See also: Recommended bare-metal Arm servers

    \ No newline at end of file diff --git a/blog/native-arm64-for-github-actions.html b/blog/native-arm64-for-github-actions.html index 70d2722..c3919ff 100644 --- a/blog/native-arm64-for-github-actions.html +++ b/blog/native-arm64-for-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    How to make GitHub Actions 22x faster with bare-metal Arm

    Alex Ellis

    GitHub doesn't provide hosted Arm runners, so how can you use native Arm runners safely & securely?

    GitHub Actions is a modern, fast and efficient way to build and test software, with free runners available. We use the free runners for various open source projects and are generally very pleased with them, after all, who can argue with good enough and free? But one of the main caveats is that GitHub's hosted runners don't yet support the Arm architecture.

    +
    ActuatedActuated logo

    How to make GitHub Actions 22x faster with bare-metal Arm

    Alex Ellis

    GitHub doesn't provide hosted Arm runners, so how can you use native Arm runners safely & securely?

    GitHub Actions is a modern, fast and efficient way to build and test software, with free runners available. We use the free runners for various open source projects and are generally very pleased with them, after all, who can argue with good enough and free? But one of the main caveats is that GitHub's hosted runners don't yet support the Arm architecture.

    So many people turn to software-based emulation using QEMU. QEMU is tricky to set up, and requires specific code and tricks if you want to use software in a standard way, without modifying it. But QEMU is great when it runs with hardware acceleration. Unfortunately, the hosted runners on GitHub do not have KVM available, so builds tend to be incredibly slow, and I mean so slow that it's going to distract you and your team from your work.

    This was even more evident when Frederic Branczyk tweeted about his experience with QEMU on GitHub Actions for his open source observability project named Parca.

    @@ -131,4 +131,4 @@

    Wrapping up

  • Actuated docs
  • FAQ & comparison to other solutions
  • Follow actuated on Twitter
    • -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/oidc-proxy-for-openfaas.html b/blog/oidc-proxy-for-openfaas.html index 91b884d..3b4b053 100644 --- a/blog/oidc-proxy-for-openfaas.html +++ b/blog/oidc-proxy-for-openfaas.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Keyless deployment to OpenFaaS with OIDC and GitHub Actions

    Alex Ellis

    We're announcing a new OIDC proxy for OpenFaaS for keyless deployments from GitHub Actions.

    In 2021, GitHub released OpenID Connect (OIDC) support for CI jobs running under GitHub Actions. This was a huge step forward for security meaning that any GitHub Action could mint an OIDC token and use it to securely federate into another system without having to store long-lived credentials in the repository.

    +
    ActuatedActuated logo

    Keyless deployment to OpenFaaS with OIDC and GitHub Actions

    Alex Ellis

    We're announcing a new OIDC proxy for OpenFaaS for keyless deployments from GitHub Actions.

    In 2021, GitHub released OpenID Connect (OIDC) support for CI jobs running under GitHub Actions. This was a huge step forward for security meaning that any GitHub Action could mint an OIDC token and use it to securely federate into another system without having to store long-lived credentials in the repository.

    I wrote a prototype for OpenFaaS shortly after the announcement and a deep dive explaining how it works. I used inlets to set up a HTTPS tunnel, and send the token to my machine for inspection. Various individuals and technical teams have used my content as a reference guide when working with GitHub Actions and OIDC.

    See the article: Deploy without credentials with GitHub Actions and OIDC

    Since then, custom actions for GCP, AWS and Azure have been created which allow an OIDC token from a GitHub Action to be exchanged for a short-lived access token for their API - meaning you can manage cloud resources securely. For example, see: Configuring OpenID Connect in Amazon Web Services - we have actuated customers who use this approach to deploy to ECR from their self-hosted runners without having to store long-lived credentials in their repositories.

    @@ -177,4 +177,4 @@

    Wrapping up

    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/right-sizing-vms-github-actions.html b/blog/right-sizing-vms-github-actions.html index a20c2e6..ff467e4 100644 --- a/blog/right-sizing-vms-github-actions.html +++ b/blog/right-sizing-vms-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Right sizing VMs for GitHub Actions

    How do you pick the right VM size for your GitHub Actions runners? We wrote a custom tool to help you find out.

    When we onboarded the etcd project from the CNCF, they'd previously been using a self-hosted runner for their repositories on a bare-metal host. There are several drawbacks to this approach, including potential security issues, especially when using Docker.

    +
    ActuatedActuated logo

    Right sizing VMs for GitHub Actions

    How do you pick the right VM size for your GitHub Actions runners? We wrote a custom tool to help you find out.

    When we onboarded the etcd project from the CNCF, they'd previously been using a self-hosted runner for their repositories on a bare-metal host. There are several drawbacks to this approach, including potential security issues, especially when using Docker.

    actuated VM sizes can be configured by a label, and you can pick any combination of vCPU and RAM, there's no need to pick a pre-defined size.

    At the same time, it can be hard to know what size to pick, and if you make the VM size too large, then you won't be able to run as many jobs at once.

    There's three main things to consider:

    @@ -80,4 +80,4 @@

    Wrapping up

  • post.js communicates to vmmeter over a TCP port and tells it to dump its response to /tmp/vmmeter.log, then to exit

    • What if you're not using GitHub Actions?

    -

    You can run vmmeter with bash on your own system, and may also able to use vmmeter in GitLab CI or Jenkins. We've got manual instructions for vmmeter here. You can even just start it up right now, do some work and then call the collect endpoint to see what was used over that period of time, a bit like a generic profiler.

    \ No newline at end of file +

    You can run vmmeter with bash on your own system, and may also able to use vmmeter in GitLab CI or Jenkins. We've got manual instructions for vmmeter here. You can even just start it up right now, do some work and then call the collect endpoint to see what was used over that period of time, a bit like a generic profiler.

    \ No newline at end of file diff --git a/blog/sbom-in-github-actions.html b/blog/sbom-in-github-actions.html index 84076f3..40cbbcc 100644 --- a/blog/sbom-in-github-actions.html +++ b/blog/sbom-in-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    How to add a Software Bill of Materials (SBOM) to your containers with GitHub Actions

    Alex Ellis

    Learn how to add a Software Bill of Materials (SBOM) to your containers with GitHub Actions in a few easy steps.

    What is a Software Bill of Materials (SBOM)?

    +
    ActuatedActuated logo

    How to add a Software Bill of Materials (SBOM) to your containers with GitHub Actions

    Alex Ellis

    Learn how to add a Software Bill of Materials (SBOM) to your containers with GitHub Actions in a few easy steps.

    What is a Software Bill of Materials (SBOM)?

    In April 2022 Justin Cormack, CTO of Docker announced that Docker was adding support to generate a Software Bill of Materials (SBOM) for container images.

    An SBOM is an inventory of the components that make up a software application. It is a list of the components that make up a software application including the version of each component. The version is important because it can be cross-reference with a vulnerability database to determine if the component has any known vulnerabilities.

    Many organisations are also required to company with certain Open Source Software (OSS) licenses. So if SBOMs are included in the software they purchase or consume from vendors, then it can be used to determine if the software is compliant with their specific license requirements, lowering legal and compliance risk.

    @@ -204,4 +204,4 @@

    Wrapping up

  • Announcing Docker SBOM: A step towards more visibility into Docker images- Justin Cormack
  • Generating SBOMs for Your Image with BuildKit - Justin Chadwell
  • Anchore on GitHub
    • -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/blog/secure-microvm-ci-gitlab.html b/blog/secure-microvm-ci-gitlab.html index 950dd86..ad4a4a3 100644 --- a/blog/secure-microvm-ci-gitlab.html +++ b/blog/secure-microvm-ci-gitlab.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Secure CI for GitLab with Firecracker microVMs

    Learn how actuated for GitLab CI can help you secure your CI/CD pipelines with Firecracker.

    We started building actuated for GitHub Actions because we at OpenFaaS Ltd had a need for: unmetered CI minutes, faster & more powerful x86 machines, native Arm builds and low maintenance CI builds.

    +
    ActuatedActuated logo

    Secure CI for GitLab with Firecracker microVMs

    Learn how actuated for GitLab CI can help you secure your CI/CD pipelines with Firecracker.

    We started building actuated for GitHub Actions because we at OpenFaaS Ltd had a need for: unmetered CI minutes, faster & more powerful x86 machines, native Arm builds and low maintenance CI builds.

    And most importantly, we needed it to be low-maintenance, and securely isolated.

    None of the solutions at the time could satisfy all of those requirements, and even today with GitHub adopting the community-based Kubernetes controller to run CI in Pods, there is still a lot lacking.

    As we've gained more experience with customers who largely had the same needs as we did for GitHub Actions, we started to hear more and more from GitLab CI users. From large enterprise companies who are concerned about the security risks of running CI with privileged Docker containers, Docker socket binding (from the host!) or the flakey nature and slow speed of VFS with Docker In Docker (DIND).

    @@ -50,4 +50,4 @@

    Wrapping up

  • Browse the docs and FAQ for actuated for GitHub Actions
  • Read customer testimonials
    • -

    You can follow @selfactuated on Twitter, or find me there too to keep an eye on what we're building.

    \ No newline at end of file +

    You can follow @selfactuated on Twitter, or find me there too to keep an eye on what we're building.

    \ No newline at end of file diff --git a/index.html b/index.html index 70a7669..7586b21 100644 --- a/index.html +++ b/index.html @@ -4,4 +4,4 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo
    The team working collaborating on a project

    Fast and secure GitHub Actionson your own infrastructure.

    Standard hosted runners are slow and expensive, larger runners cost even more.

    Actuated runs on your own infrastructure with a predictable cost, low management and secure isolation with Firecracker.

    Get startedLive demo

    Trusted by a growing number of companies

    Riskfuel
    OpenFaaS Ltd
    Observability, simplified
    Swiss National Data and Service Center
    Kubiya.ai
    Cloud Native Computing Foundation (CNCF)
    Toolpath
    Waffle Labs
    Tuple

    After one week actuated has been a huge improvement! Even our relatively fast Go build seems to be running 30%+ faster and being able to commit to several repos and only wait 10 minutes instead of an hour has been transformative.

    Steven Byrnes
    VP Engineering, Waffle Labs
    SettleMint

    Finally our self-hosted GitHub Actions Runners are on fire 🔥. Thanks to Alex for all the help onboarding our monorepo with NX, Docker, x86 and Arm on bare-metal.

    Our worst case build/deploy went down from 1h to 20-30mins, for a repo with 200k lines-of-code.

    Roderik van der Veer
    Founder & CTO at SettleMint

    Keep in touch with us
    For news and announcements

    We care about your data. Read our privacy policy.

    Increase speed, security and efficiency.

    Learn what friction actuated solves and how it compares to other solutions: Read the announcement

    Secure CI that feels like hosted.

    Every job runs in an immutable microVM, just like hosted runners, but on your own servers.

    That means you can run sudo, Docker and Kubernetes directly, just like you do during development, there's no need for Docker-in-Docker (DIND), Kaniko or complex user-namespaces.

    What about management and scheduling? Provision a server with a minimal Operating System, then install the agent. We'll do the rest.

    Arm / M1 from Dev to Production.

    Apple Silicon is a new favourite for developer workstations. Did you know that when your team run Docker, they're using an Arm VM?

    With actuated, those same builds can be performed on Arm servers during CI, and even deployed to production on more efficient Ampere or AWS Graviton servers.

    Run directly within your datacenter.

    If you work with large container images or datasets, then you'll benefit from having your CI run with direct local network access to your internal network.

    This is not possible with hosted runners, and this is crucial for one of our customers who can regularly saturate a 10GbE link during GitHub Actions runs.

    In contrast, VPNs are complex to manage, capped on speed, and incur costly egress charges.

    Debug live over SSH

    We heard from many teams that they missed CircleCI's "debug this job" button, so we built it for you.

    We realise you won't debug your jobs on a regular basis, but when you are stuck, and have to wait 15-20 minutes to get to the line you've changed in a job, debugging with a terminal can save you hours.

    "How cool!!! you don't know how many hours I have lost on GitHub Actions without this." - Ivan Subotic, Swiss National Data and Service Center (DaSCH)

    Lower your costs, and keep them there.

    Actuated is billed by the maximum amount of concurrent jobs you can run, so no matter how many build minutes your team requires, the charge will not increase with usage.

    In a recent interview, a lead SRE at UK-based scale-up told us that their bill had increased 5x over the past 6 months. They are now paying 5000 GBP / month and we worked out that we could make their builds faster and at least half the costs.

    Lower management costs.

    Whenever your team has to manage self-hosted runners, or explain non-standard tools like Kaniko to developers, you're losing money.

    With actuated, you bring your own servers, install our agent, and we do the rest. Our VM image is built with automation and kept up to date, so you don't have to manage packages.

    Predictable billing.

    Most small teams we interviewed were spending at least 1000-1500 USD / mo for the standard, slower hosted runners.

    That cost would only increase with GitHub's faster runners, but with actuated the cost is flat-rate, no matter how many minutes you use.

    Get insights into your organisation

    When you have more than a few teammates and a dozen repositories, it's near impossible to get insights into patterns of usage.

    Inspired by Google Analytics, Actuated contrasts usage for the current period vs the previous period - for the whole organisation, each repository and each developer.

    Organisational level insights

    Learn about the actuated dashboard

    Improve your builds with our tips & tricks

    Learn how to improve the speed and efficiency your GitHub Actions with our examples and best practices.

    These are the results you've been waiting for

    “Our team loves actuated. It gave us a 3x speed increase on a Go repo that we build throughout the day. Alex and team are really responsive, and we're already happy customers of OpenFaaS and Inlets.”

    Shaked Askayo
    CTO, Kubiya.ai

    “We just switched from Actions Runtime Controller to Actuated. It only took 30s create 5x isolated VMs, run the jobs and tear them down again inside our on-prem environment (no Docker socket mounting shenanigans)! Pretty impressive stuff.”

    Addison van den Hoeven
    DevOps Lead, Riskfuel

    “From my time at Mirantis, I learned how slow and unreliable Docker In Docker can be. Compared to GitHub's 16 core runners, actuated is 2-3x faster for us.”

    Sergei Lukianov
    Founding Engineer, Githedgehog

    “This is great, perfect for jobs that take forever on normal GitHub runners. I love what Alex is doing here.”

    Richard Case
    Principal Engineer, SUSE

    “We needed to build public repos on Arm runners, but QEMU couldn't finish in 6 hours, so we had to turn the build off. Actuated now builds the same code in 4 minutes.”

    Patrick Stephens
    Tech Lead of Infrastructure, Calyptia/Fluent Bit.

    “We needed to build Arm containers for our customers to deploy to Graviton instances on AWS EC2. Hosted runners with QEMU failed to finish within the 6 hour limit. With actuated it takes 20 minutes - and thanks to Firecracker, each build is safely isolated for our open source repositories.”

    Ivan Subotic
    Head of Engineering, Swiss National Data and Service Center for the Humanities

    “One of our Julia builds was taking 5 hours of compute time to complete, and was costing us over 1500USD / mo. Alex's team got us a 3x improvement on speed and lowered our costs at the same time. Actuated is working great for us.”

    Justin Gray, Ph.D.
    CTO & Co-founder at Toolpath

    Frequently asked questions

    Workcation

    “It's cheaper - and less frustrating for your developers — to pay more for better hardware to keep your team on track.

    The upfront cost for more CPU power pays off over time. And your developers will thank you.”

     

    Read the article: The hidden costs of waiting on slow build times (GitHub.com)

    Natalie Somersall
    GitHub Staff

    Ready to go faster?

    You can try out actuated on a monthly basis, with no commitment beyond that.

    Make your builds faster today
    Matrix build with k3sup
    \ No newline at end of file +
    ActuatedActuated logo
    The team working collaborating on a project

    Fast and secure GitHub Actionson your own infrastructure.

    Standard hosted runners are slow and expensive, larger runners cost even more.

    Actuated runs on your own infrastructure with a predictable cost, low management and secure isolation with Firecracker.

    Get startedLive demo

    Trusted by a growing number of companies

    Riskfuel
    OpenFaaS Ltd
    Observability, simplified
    Swiss National Data and Service Center
    Kubiya.ai
    Cloud Native Computing Foundation (CNCF)
    Toolpath
    Waffle Labs
    Tuple

    After one week actuated has been a huge improvement! Even our relatively fast Go build seems to be running 30%+ faster and being able to commit to several repos and only wait 10 minutes instead of an hour has been transformative.

    Steven Byrnes
    VP Engineering, Waffle Labs
    SettleMint

    Finally our self-hosted GitHub Actions Runners are on fire 🔥. Thanks to Alex for all the help onboarding our monorepo with NX, Docker, x86 and Arm on bare-metal.

    Our worst case build/deploy went down from 1h to 20-30mins, for a repo with 200k lines-of-code.

    Roderik van der Veer
    Founder & CTO at SettleMint

    Keep in touch with us
    For news and announcements

    We care about your data. Read our privacy policy.

    Increase speed, security and efficiency.

    Learn what friction actuated solves and how it compares to other solutions: Read the announcement

    Secure CI that feels like hosted.

    Every job runs in an immutable microVM, just like hosted runners, but on your own servers.

    That means you can run sudo, Docker and Kubernetes directly, just like you do during development, there's no need for Docker-in-Docker (DIND), Kaniko or complex user-namespaces.

    What about management and scheduling? Provision a server with a minimal Operating System, then install the agent. We'll do the rest.

    Arm / M1 from Dev to Production.

    Apple Silicon is a new favourite for developer workstations. Did you know that when your team run Docker, they're using an Arm VM?

    With actuated, those same builds can be performed on Arm servers during CI, and even deployed to production on more efficient Ampere or AWS Graviton servers.

    Run directly within your datacenter.

    If you work with large container images or datasets, then you'll benefit from having your CI run with direct local network access to your internal network.

    This is not possible with hosted runners, and this is crucial for one of our customers who can regularly saturate a 10GbE link during GitHub Actions runs.

    In contrast, VPNs are complex to manage, capped on speed, and incur costly egress charges.

    Debug live over SSH

    We heard from many teams that they missed CircleCI's "debug this job" button, so we built it for you.

    We realise you won't debug your jobs on a regular basis, but when you are stuck, and have to wait 15-20 minutes to get to the line you've changed in a job, debugging with a terminal can save you hours.

    "How cool!!! you don't know how many hours I have lost on GitHub Actions without this." - Ivan Subotic, Swiss National Data and Service Center (DaSCH)

    Lower your costs, and keep them there.

    Actuated is billed by the maximum amount of concurrent jobs you can run, so no matter how many build minutes your team requires, the charge will not increase with usage.

    In a recent interview, a lead SRE at UK-based scale-up told us that their bill had increased 5x over the past 6 months. They are now paying 5000 GBP / month and we worked out that we could make their builds faster and at least half the costs.

    Lower management costs.

    Whenever your team has to manage self-hosted runners, or explain non-standard tools like Kaniko to developers, you're losing money.

    With actuated, you bring your own servers, install our agent, and we do the rest. Our VM image is built with automation and kept up to date, so you don't have to manage packages.

    Predictable billing.

    Most small teams we interviewed were spending at least 1000-1500 USD / mo for the standard, slower hosted runners.

    That cost would only increase with GitHub's faster runners, but with actuated the cost is flat-rate, no matter how many minutes you use.

    Get insights into your organisation

    When you have more than a few teammates and a dozen repositories, it's near impossible to get insights into patterns of usage.

    Inspired by Google Analytics, Actuated contrasts usage for the current period vs the previous period - for the whole organisation, each repository and each developer.

    Organisational level insights

    Learn about the actuated dashboard

    Improve your builds with our tips & tricks

    Learn how to improve the speed and efficiency your GitHub Actions with our examples and best practices.

    These are the results you've been waiting for

    “Our team loves actuated. It gave us a 3x speed increase on a Go repo that we build throughout the day. Alex and team are really responsive, and we're already happy customers of OpenFaaS and Inlets.”

    Shaked Askayo
    CTO, Kubiya.ai

    “We just switched from Actions Runtime Controller to Actuated. It only took 30s create 5x isolated VMs, run the jobs and tear them down again inside our on-prem environment (no Docker socket mounting shenanigans)! Pretty impressive stuff.”

    Addison van den Hoeven
    DevOps Lead, Riskfuel

    “From my time at Mirantis, I learned how slow and unreliable Docker In Docker can be. Compared to GitHub's 16 core runners, actuated is 2-3x faster for us.”

    Sergei Lukianov
    Founding Engineer, Githedgehog

    “This is great, perfect for jobs that take forever on normal GitHub runners. I love what Alex is doing here.”

    Richard Case
    Principal Engineer, SUSE

    “We needed to build public repos on Arm runners, but QEMU couldn't finish in 6 hours, so we had to turn the build off. Actuated now builds the same code in 4 minutes.”

    Patrick Stephens
    Tech Lead of Infrastructure, Calyptia/Fluent Bit.

    “We needed to build Arm containers for our customers to deploy to Graviton instances on AWS EC2. Hosted runners with QEMU failed to finish within the 6 hour limit. With actuated it takes 20 minutes - and thanks to Firecracker, each build is safely isolated for our open source repositories.”

    Ivan Subotic
    Head of Engineering, Swiss National Data and Service Center for the Humanities

    “One of our Julia builds was taking 5 hours of compute time to complete, and was costing us over 1500USD / mo. Alex's team got us a 3x improvement on speed and lowered our costs at the same time. Actuated is working great for us.”

    Justin Gray, Ph.D.
    CTO & Co-founder at Toolpath

    Frequently asked questions

    Workcation

    “It's cheaper - and less frustrating for your developers — to pay more for better hardware to keep your team on track.

    The upfront cost for more CPU power pays off over time. And your developers will thank you.”

     

    Read the article: The hidden costs of waiting on slow build times (GitHub.com)

    Natalie Somersall
    GitHub Staff

    Ready to go faster?

    You can try out actuated on a monthly basis, with no commitment beyond that.

    Make your builds faster today
    Matrix build with k3sup
    \ No newline at end of file diff --git a/pricing.html b/pricing.html index 08280d6..0743b71 100644 --- a/pricing.html +++ b/pricing.html @@ -4,4 +4,4 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Plans & Pricing

    You can get started with us the same day as your call.

      Simple, flat-rate pricing

      Actuated plans are based upon the total number of concurrent builds needed for your team. All plans include unmetered minutes, with no additional charges.

      The higher the concurrency level for your plan, the more benefits you'll receive.

      The onboarding process is quick and easy: learn more.

      In all tiers

      • Unlimited build minutes
      • Bring your own server
      • Free onboarding call with our engineers
      • Linux x86_64 and 64-bit Arm
      • Reporting and usage metrics
      • Support via email

      With higher concurrency

      • Debug tricky builds with SSH
      • Enhanced SLA
      • Private Prometheus metrics
      • Private Slack channel
      • Recommendations to improve build speed

      Early access

      • Self-hosted GitLab CI
      • GitHub Enterprise Server (GHES)
      • GPU pass-through

      Pay monthly, for up to 3x faster CI

      $100USD / concurrent build

      Talk to us

      You'll meet with our founder to discuss your current challenges and answer any questions you may have.

    \ No newline at end of file +
    ActuatedActuated logo

    Plans & Pricing

    You can get started with us the same day as your call.

      Simple, flat-rate pricing

      Actuated plans are based upon the total number of concurrent builds needed for your team. All plans include unmetered minutes, with no additional charges.

      The higher the concurrency level for your plan, the more benefits you'll receive.

      The onboarding process is quick and easy: learn more.

      In all tiers

      • Unlimited build minutes
      • Bring your own server
      • Free onboarding call with our engineers
      • Linux x86_64 and 64-bit Arm
      • Reporting and usage metrics
      • Support via email

      With higher concurrency

      • Debug tricky builds with SSH
      • Enhanced SLA
      • Private Prometheus metrics
      • Private Slack channel
      • Recommendations to improve build speed

      Early access

      • Self-hosted GitLab CI
      • GitHub Enterprise Server (GHES)
      • GPU pass-through

      Pay monthly, for up to 3x faster CI

      $100USD / concurrent build

      Talk to us

      You'll meet with our founder to discuss your current challenges and answer any questions you may have.

    \ No newline at end of file diff --git a/rss.xml b/rss.xml index c746da6..07b7c17 100644 --- a/rss.xml +++ b/rss.xml @@ -4,7 +4,7 @@ Actuated - bloghttps://actuated.devKeep your team productive & focused with blazing fast CI - Mon, 04 Mar 2024 12:29:27 GMT + Mon, 04 Mar 2024 12:30:34 GMThttps://validator.w3.org/feed/docs/rss2.htmlhttps://github.com/jpmonette/feed @@ -30,7 +30,7 @@
    Rank for build minutesRank Organisation Date of first actuated build
    - +
    Rank for build minutesRank Organisation Date of first actuated build