From 29a71aab7a8cd9f073022c28091c25476217e9f3 Mon Sep 17 00:00:00 2001 From: "Alex Ellis (OpenFaaS Ltd)" Date: Mon, 25 Mar 2024 11:18:07 +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 ...-study-bring-your-own-bare-metal-to-actions.json | 0 .../blog/cncf-arm-march-update.json | 0 .../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/gpus-for-github-actions.json | 0 .../blog/how-to-run-multi-arch-builds-natively.json | 0 ...-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/ollama-in-github-actions.json | 1 + .../blog/right-sizing-vms-github-actions.json | 0 .../blog/sbom-in-github-actions.json | 0 .../blog/secure-microvm-ci-gitlab.json | 0 .../blog/ollama-in-github-actions.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 ++-- ...-study-bring-your-own-bare-metal-to-actions.html | 4 ++-- blog/cncf-arm-march-update.html | 4 ++-- 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/gpus-for-github-actions.html | 4 ++-- blog/how-to-run-multi-arch-builds-natively.html | 4 ++-- ...-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/ollama-in-github-actions.html | 13 +++++++------ 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 | 11 ++++++----- 63 files changed, 71 insertions(+), 69 deletions(-) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/amd-zenbleed-update-now.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/arm-ci-cncf-ampere.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/automate-packer-qemu-image-builds.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/blazing-fast-ci-with-microvms.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/caching-in-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/calyptia-case-study-arm.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/case-study-bring-your-own-bare-metal-to-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/cncf-arm-march-update.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/custom-sizes-bpf-kvm.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/develop-a-great-go-cli.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/faster-nix-builds.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/faster-self-hosted-cache.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/firecracker-container-lab.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/github-actions-usage-cli.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/gpus-for-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/how-to-run-multi-arch-builds-natively.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/is-the-self-hosted-runner-safe-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/kvm-in-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/local-caching-for-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/managing-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/multi-arch-docker-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/native-arm64-for-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/oidc-proxy-for-openfaas.json (100%) create mode 100644 _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/ollama-in-github-actions.json rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/right-sizing-vms-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/sbom-in-github-actions.json (100%) rename _next/data/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/blog/secure-microvm-ci-gitlab.json (100%) delete mode 100644 _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/ollama-in-github-actions.json rename _next/static/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/_buildManifest.js (100%) rename _next/static/{ft9xR7T5DzM1kYRDk9ufG => 7jz0yb9MI_ho5GRVoWY_s}/_ssgManifest.js (100%) diff --git a/404.html b/404.html index 26dac34..4941379 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/ft9xR7T5DzM1kYRDk9ufG/blog.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/amd-zenbleed-update-now.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/amd-zenbleed-update-now.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/amd-zenbleed-update-now.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/amd-zenbleed-update-now.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/arm-ci-cncf-ampere.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/arm-ci-cncf-ampere.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/arm-ci-cncf-ampere.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/arm-ci-cncf-ampere.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/automate-packer-qemu-image-builds.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/automate-packer-qemu-image-builds.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/automate-packer-qemu-image-builds.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/automate-packer-qemu-image-builds.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/blazing-fast-ci-with-microvms.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/blazing-fast-ci-with-microvms.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/blazing-fast-ci-with-microvms.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/blazing-fast-ci-with-microvms.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/caching-in-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/caching-in-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/caching-in-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/caching-in-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/calyptia-case-study-arm.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/calyptia-case-study-arm.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/calyptia-case-study-arm.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/calyptia-case-study-arm.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/case-study-bring-your-own-bare-metal-to-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/case-study-bring-your-own-bare-metal-to-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/case-study-bring-your-own-bare-metal-to-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/case-study-bring-your-own-bare-metal-to-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/cncf-arm-march-update.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/cncf-arm-march-update.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/cncf-arm-march-update.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/cncf-arm-march-update.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/custom-sizes-bpf-kvm.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/custom-sizes-bpf-kvm.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/custom-sizes-bpf-kvm.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/custom-sizes-bpf-kvm.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/develop-a-great-go-cli.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/develop-a-great-go-cli.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/develop-a-great-go-cli.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/develop-a-great-go-cli.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/faster-nix-builds.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/faster-nix-builds.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/faster-nix-builds.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/faster-nix-builds.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/faster-self-hosted-cache.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/faster-self-hosted-cache.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/faster-self-hosted-cache.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/faster-self-hosted-cache.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/firecracker-container-lab.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/firecracker-container-lab.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/firecracker-container-lab.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/firecracker-container-lab.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/github-actions-usage-cli.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/github-actions-usage-cli.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/github-actions-usage-cli.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/github-actions-usage-cli.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/gpus-for-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/gpus-for-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/gpus-for-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/gpus-for-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/how-to-run-multi-arch-builds-natively.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/how-to-run-multi-arch-builds-natively.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/how-to-run-multi-arch-builds-natively.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/how-to-run-multi-arch-builds-natively.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/is-the-self-hosted-runner-safe-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/is-the-self-hosted-runner-safe-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/is-the-self-hosted-runner-safe-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/is-the-self-hosted-runner-safe-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/kvm-in-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/kvm-in-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/kvm-in-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/kvm-in-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/local-caching-for-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/local-caching-for-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/local-caching-for-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/local-caching-for-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/managing-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/managing-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/managing-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/managing-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/multi-arch-docker-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/multi-arch-docker-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/multi-arch-docker-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/multi-arch-docker-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/native-arm64-for-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/native-arm64-for-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/native-arm64-for-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/native-arm64-for-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/oidc-proxy-for-openfaas.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/oidc-proxy-for-openfaas.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/oidc-proxy-for-openfaas.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/oidc-proxy-for-openfaas.json diff --git a/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/ollama-in-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/ollama-in-github-actions.json new file mode 100644 index 0000000..280db61 --- /dev/null +++ b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/ollama-in-github-actions.json @@ -0,0 +1 @@ +{"pageProps":{"post":{"slug":"ollama-in-github-actions","fileName":"2024-03-25-ollama-in-github-actions.md","contentHtml":"

That means you can run real end to end tests in CI with the same models you may use in dev and production. And if you use OpenAI or AWS SageMaker extensively, you could perhaps swap out what can be a very expensive API endpoint for your CI or testing environments to save money.

\n

If you'd like to learn more about how and why you'd want access to GPUs in CI, read my past update: Accelerate GitHub Actions with dedicated GPUs.

\n

We'll first cover what ollama is, why it's so popular, how to get it, what kinds of fun things you can do with it, then how to access it from actuated using a real GPU.

\n

\"ollama

\n
\n

ollama can now run in CI with isolated GPU acceleration using actuated

\n
\n

What's ollama?

\n

ollama is an open source project that aims to do for AI models, what Docker did for Linux containers. Whilst Docker created a user experience to share and run containers using container images in the Open Container Initiative (OCI) format, ollama bundles well-known AI models and makes it easy to run them without having to think about Python versions or Nvidia CUDA libraries.

\n

The project packages and runs various models, but seems to take its name from Meta's popular llama2 model, which whilst not released under an open source license, allows for a generous amount of free usage for most types of users.

\n

The ollama project can be run directly on a Linux, MacOS or Windows host, or within a container. There's a server component, and a CLI that acts as a client to pre-trained models. The main use-case today is that of inference - exercising the model with input data. A more recent feature means that you can create embeddings, if you pull a model that supports them.

\n

On Linux, ollama can be installed using a utility script:

\n
curl -fsSL https://ollama.com/install.sh | sh\n
\n

This provides the ollama CLI command.

\n

A quick tour of ollama

\n

After the initial installation, you can start a server:

\n
ollama serve\n
\n

By default, its REST API will listen on port 11434 on 127.0.0.1.

\n

You can find the reference for ollama's REST API here: API endpoints - which includes things like: creating a chat completion, pulling a model, or generating embeddings.

\n

You can then browse available models on the official website, which resembles the Docker Hub. This set currently includes: gemma (built upon Google's DeepMind), mistral (an LLM), codellama (for generating Code), phi (from Microsoft research), vicuna (for chat, based upon llama2), llava (a vision encoder), and many more.

\n

Most models will download with a default parameter size that's small enough to run on most CPUs or GPUs, but if you need to access it, there are larger models for higher accuracy.

\n

For instance, the llama2 model by Meta will default to the 7b model which needs around 8GB of RAM.

\n
# Pull the default model size:\n\nollama pull llama2\n\n# Override the parameter size\n\nollama pull llama2:13b\n
\n

Once you have a model, you can then either \"run\" it, where you'll be able to ask it questions and interact with it like you would with ChatGPT, or you can send it API requests from your own applications using REST and HTTP.

\n

For an interactive prompt, give no parameters:

\n
ollama run llama2\n
\n

To get an immediate response for use in i.e. scripts:

\n
ollama run llama2 \"What are the pros of MicroVMs for continous integrations, especially if Docker is the alternative?\"\n
\n

And you can use the REST API via curl, or your own codebase:

\n
curl -s http://localhost:11434/api/generate -d '{\n    \"model\": \"llama2\",\n    \"stream\": false,\n    \"prompt\":\"What are the risks of running privileged Docker containers for CI workloads?\"\n}' | jq\n
\n

Access ollama from Python code

\n

Here's how to access the API via Python, the stream parameter will emit JSON progressively when set to True, block until done if set to False. With Node.js, Python, Java, C#, etc the code will be very similar, but using your own preferred HTTP client. For Golang (Go) users, ollama founder Jeffrey Morgan maintains a higher-level Go SDK.

\n
import requests\nimport json\n\nurl = \"http://localhost:11434/api/generate\"\npayload = {\n    \"model\": \"llama2\",\n    \"stream\": False,\n    \"prompt\": \"What are the risks of running privileged Docker containers for CI workloads?\"\n}\nheaders = {\n    \"Content-Type\": \"application/json\"\n}\n\nresponse = requests.post(url, data=json.dumps(payload), headers=headers)\n\n# Parse the JSON response\nresponse_json = response.json()\n\n# Pretty print the JSON response\nprint(json.dumps(response_json, indent=4))\n
\n

Putting it together for a GitHub Action

\n

The following GitHub Action will run on for customers who are enrolled for GPU support for actuated. If you'd like to gain access, contact us via the form on the Pricing page.

\n

The self-actuated/nvidia-run installs either the consumer or datacenter driver for Nvidia, depending on what you have in your system. This only takes about 30 seconds and could be cached if you like. The ollama models could also be cached using a local S3 bucket.

\n

Then, we simply run the equivalent bash commands from the previous section to:

\n\n
name: ollama-e2e\n\non:\n    workflow_dispatch:\n\njobs:\n    ollama-e2e:\n        name: ollama-e2e\n        runs-on: [actuated-8cpu-16gb, gpu]\n        steps:\n        - uses: actions/checkout@v1\n        - uses: self-actuated/nvidia-run@master\n        - name: Install Ollama\n          run: |\n            curl -fsSL https://ollama.com/install.sh | sudo -E sh\n        - name: Start serving\n          run: |\n              ollama serve &\n              sleep 5\n\n        - name: Pull llama2\n          run: |\n              ollama pull llama2\n\n        - name: Invoke via the CLI\n          run: |\n              ollama run llama2 \"What are the pros of MicroVMs for continous integrations, especially if Docker is the alternative?\"\n\n        - name: Invoke via API\n          run: |\n            curl -s http://localhost:11434/api/generate -d '{\n              \"model\": \"llama2\",\n              \"stream\": false,\n              \"prompt\":\"What are the risks of running privileged Docker containers for CI workloads?\"\n            }' | jq\n
\n

At time of writing, I couldn't find a way to detect when the HTTP serve was ready for ollama, so added a generous 5 second sleep in bash. Ideally, ollama will fix this issue for better use in scripting and automation. I created a GitHub issue that you can track here.

\n

Interactive access with SSH

\n

By modifying your CI job, you can drop into a remote SSH session and run interactive commands at any point in the workflow.

\n

That's how I came up with the commands for the Nvidia driver installation, and for the various ollama commands I shared.

\n

Find out more about SSH for GitHub Actions in the actuated docs.

\n

Wrapping up

\n

Within a very short period of time ollama helped us pull a popular AI model that can be used for chat and completions. We were then able to take what we learned and run it on a GPU at an accelerated speed and accuracy by using actuated's new GPU support for GitHub Actions and GitLab CI.

\n

ollama isn't the only way to find, download and run AI models, just like Docker wasn't the only way to download and install Nginx or Postgresql, but it provides a useful and convenient interface for those of us who are still learning about AI, and are not as concerned with the internal workings of the models.

\n

Over on the OpenFaaS blog, in the tutorial Stream OpenAI responses from functions using Server Sent Events, we covered how to stream a response from a model to a function, and then back to a user. There, we used the llama-api open source project, which is a single-purpose HTTP API for simulating llama2.

\n

One of the benefits of ollama is the detailed range of examples in the docs, and the ability to run other models that may include computer vision such as with the LLaVA: Large Language and Vision Assistant model or generating code with Code Llama.

\n

Right now, many of us are running and tuning models in development, some of us are using OpenAI's API or self-hosted models in production, but there's very little talk about doing thorough end to end testing or exercising models in CI. That's where actuated can help.

\n

Feel free to reach out for early access, or to see if we can help your team with your CI needs.

","title":"Run AI models with ollama in CI with GitHub Actions","description":"With the new GPU support for actuated, we've been able to run models like llama2 from ollama in CI on consumer and datacenter grade Nvidia cards.","tags":["ai","ollama","ml","localmodels","githubactions","openai","llama","machinelearning"],"author_img":"alex","image":"/images/2024-04-ollama-in-ci/background.png","date":"2024-04-25"}},"__N_SSG":true} \ No newline at end of file diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/right-sizing-vms-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/right-sizing-vms-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/right-sizing-vms-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/right-sizing-vms-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/sbom-in-github-actions.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/sbom-in-github-actions.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/sbom-in-github-actions.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/sbom-in-github-actions.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/secure-microvm-ci-gitlab.json b/_next/data/7jz0yb9MI_ho5GRVoWY_s/blog/secure-microvm-ci-gitlab.json similarity index 100% rename from _next/data/ft9xR7T5DzM1kYRDk9ufG/blog/secure-microvm-ci-gitlab.json rename to _next/data/7jz0yb9MI_ho5GRVoWY_s/blog/secure-microvm-ci-gitlab.json diff --git a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/ollama-in-github-actions.json b/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/ollama-in-github-actions.json deleted file mode 100644 index 49d6d74..0000000 --- a/_next/data/ft9xR7T5DzM1kYRDk9ufG/blog/ollama-in-github-actions.json +++ /dev/null @@ -1 +0,0 @@ -{"pageProps":{"post":{"slug":"ollama-in-github-actions","fileName":"2024-03-25-ollama-in-github-actions.md","contentHtml":"

That means you can run real end to end tests in CI with the same models you may use in dev and production. And if you use OpenAI or AWS SageMaker extensively, you could perhaps swap out what can be a very expensive API endpoint for your CI or testing environments to save money.

\n

If you'd like to learn more about how and why you'd want access to GPUs in CI, read my past update: Accelerate GitHub Actions with dedicated GPUs.

\n

We'll first cover what ollama is, why it's so popular, how to get it, what kinds of fun things you can do with it, then how to access it from actuated using a real GPU.

\n

\"ollama

\n
\n

ollama can now run in CI with isolated GPU acceleration using actuated

\n
\n

What's ollama?

\n

ollama is an open source project that aims to do for AI models, what Docker did for Linux containers. Whilst Docker created a user experience to share and run containers using container images in the Open Container Initiative (OCI) format, ollama bundles well-known AI models and makes it easy to run them without having to think about Python versions or Nvidia CUDA libraries.

\n

The project packages and runs various models, but seems to take its name from Meta's popular llama2 model, which whilst not released under an open source license, allows for a generous amount of free usage for most types of users.

\n

The ollama project can be run directly on a Linux, MacOS or Windows host, or within a container. There's a server component, and a CLI that acts as a client to pre-trained models. The main use-case today is that of inference - exercising the model with input data. A more recent feature means that you can create embeddings, if you pull a model that supports them.

\n

On Linux, ollama can be installed using a utility script:

\n
curl -fsSL https://ollama.com/install.sh | sh\n
\n

This provides the ollama CLI command.

\n

A quick tour of ollama

\n

After the initial installation, you can start a server:

\n
ollama serve\n
\n

By default, its REST API will listen on port 11434 on 127.0.0.1.

\n

You can find the reference for ollama's REST API here: API endpoints - which includes things like: creating a chat completion, pulling a model, or generating embeddings.

\n

You can then browse available models on the official website, which resembles the Docker Hub.

\n

Most models will download with a default parameter size that's small enough to run on most CPUs or GPUs, but if you need to access it, there are larger models for higher accuracy.

\n

For instance, the llama2 model by Meta will default to the 7b model which needs around 8GB of RAM.

\n
# Pull the default model size:\n\nollama pull llama2\n\n# Override the parameter size\nollama pull llama2:13b\n
\n

Once you have a model, you can then either \"run\" it, where you'll be able to ask it questions and interact with it like you would with ChatGPT, or you can send it API requests from your own applications using REST and HTTP.

\n

For an interactive prompt, give no parameters:

\n
ollama run llama2\n
\n

To get an immediate response for use in i.e. scripts:

\n
ollama run llama2 \"What are the pros of MicroVMs for continous integrations, especially if Docker is the alternative?\"\n
\n

And you can use the REST API via curl, or your own codebase:

\n
curl -s http://localhost:11434/api/generate -d '{\n    \"model\": \"llama2\",\n    \"stream\": false,\n    \"prompt\":\"What are the risks of running privileged Docker containers for CI workloads?\"\n}' | jq\n
\n

Access ollama from Python code

\n

Here's how to access the API via Python, the stream parameter will emit JSON progressively when set to True, block until done if set to False. With Node.js, Python, Java, C#, etc the code will be very similar, but using your own preferred HTTP client.

\n
import requests\nimport json\n\nurl = \"http://localhost:11434/api/generate\"\npayload = {\n    \"model\": \"llama2\",\n    \"stream\": False,\n    \"prompt\": \"What are the risks of running privileged Docker containers for CI workloads?\"\n}\nheaders = {\n    \"Content-Type\": \"application/json\"\n}\n\nresponse = requests.post(url, data=json.dumps(payload), headers=headers)\n\n# Parse the JSON response\nresponse_json = response.json()\n\n# Pretty print the JSON response\nprint(json.dumps(response_json, indent=4))\n
\n

Putting it together for a GitHub Action

\n

The following GitHub Action will run on for customers who are enrolled for GPU support for actuated.

\n

The initial set self-actuated/nvidia-run installs either the consumer or datacenter driver for Nvidia, depending on what you have in your system and takes about 30 seconds. This can be cached, if you like.

\n

Then, we simply run the equivalent bash commands from the previous section to:

\n\n
name: ollama-e2e\n\non:\n    workflow_dispatch:\n\njobs:\n    ollama-e2e:\n        name: ollama-e2e\n        runs-on: [actuated-8cpu-16gb, gpu]\n        steps:\n        - uses: actions/checkout@v1\n        - uses: self-actuated/nvidia-run@master\n        - name: Install Ollama\n          run: |\n            curl -fsSL https://ollama.com/install.sh | sudo -E sh\n        - name: Start serving\n          run: |\n              ollama serve &\n              sleep 5\n\n        - name: Pull llama2\n          run: |\n              ollama pull llama2\n\n        - name: Invoke via the CLI\n          run: |\n              ollama run llama2 \"What are the pros of MicroVMs for continous integrations, especially if Docker is the alternative?\"\n\n        - name: Invoke via API\n          run: |\n            curl -s http://localhost:11434/api/generate -d '{\n              \"model\": \"llama2\",\n              \"stream\": false,\n              \"prompt\":\"What are the risks of running privileged Docker containers for CI workloads?\"\n            }' | jq\n
\n

At time of writing, I couldn't find a way to detect when the HTTP serve was ready for ollama, so added a generous 5 second sleep in bash. Ideally, ollama will fix this issue for better use in scripting and automation. I created a GitHub issue that you can track here.

\n

Interactive access with SSH

\n

By modifying your CI job, you can drop into a remote SSH session and run interactive commands at any point in the workflow.

\n

That's how I came up with the commands for the Nvidia driver installation, and for the various ollama commands I shared.

\n

Find out more about SSH for GitHub Actions in the actuated docs.

\n

Wrapping up

\n

Within a very short period of time ollama helped us pull a popular AI model that can be used for chat and completions. We were then able to take what we learned and run it on a GPU at an accelerated speed and accuracy by using actuated's new GPU support for GitHub Actions and GitLab CI.

\n

ollama isn't the only way to find, download and run AI models, just like Docker wasn't the only way to download and install Nginx or Postgresql, but it provides a useful and convenient interface for those of us who are still learning about AI, and are not as concerned with the internal workings of the models.

\n

Over on the OpenFaaS blog, in the tutorial Stream OpenAI responses from functions using Server Sent Events, we covered how to stream a response from a model to a function, and then back to a user. There, we used the llama-api open source project, which is a single-purpose HTTP API for simulating llama2.

\n

One of the benefits of ollama is the detailed range of examples in the docs, and the ability to run other models that may include computer vision such as with the LLaVA: Large Language and Vision Assistant model or generating code with Code Llama.

\n

Right now, many of us are running and tuning models in development, some of us are using OpenAI's API or self-hosted models in production, but there's very little talk about doing thorough end to end testing or exercising models in CI. That's where actuated can help.

\n

Feel free to reach out for early access, or to see if we can help your team with your CI needs.

","title":"Run AI models with ollama in CI with GitHub Actions","description":"With the new GPU support for actuated, we've been able to run models like llama2 from ollama in CI on consumer and datacenter grade Nvidia cards.","tags":["ai","ollama","ml","localmodels","githubactions","openai","llama","machinelearning"],"author_img":"alex","image":"/images/2024-04-ollama-in-ci/background.png","date":"2024-04-25"}},"__N_SSG":true} \ No newline at end of file diff --git a/_next/static/ft9xR7T5DzM1kYRDk9ufG/_buildManifest.js b/_next/static/7jz0yb9MI_ho5GRVoWY_s/_buildManifest.js similarity index 100% rename from _next/static/ft9xR7T5DzM1kYRDk9ufG/_buildManifest.js rename to _next/static/7jz0yb9MI_ho5GRVoWY_s/_buildManifest.js diff --git a/_next/static/ft9xR7T5DzM1kYRDk9ufG/_ssgManifest.js b/_next/static/7jz0yb9MI_ho5GRVoWY_s/_ssgManifest.js similarity index 100% rename from _next/static/ft9xR7T5DzM1kYRDk9ufG/_ssgManifest.js rename to _next/static/7jz0yb9MI_ho5GRVoWY_s/_ssgManifest.js diff --git a/blog.html b/blog.html index d35559c..9493508 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 321231e..86a3f20 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 457a008..5f79c2f 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 0411bc8..dc53c64 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 1d2f0f1..8b92b2c 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 49b0def..7736962 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 0cab639..38bf048 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 1a4320d..efd9b90 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 84b6f6d..170d7d9 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

    @@ -123,4 +123,4 @@

    Wrapping up

    Summing up the program so far

    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 93bd534..1c207c5 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 6afae57..ec9c3bf 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 fa575d1..9a80ba6 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 4a6c4a9..296cc5a 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 c3c8c55..9e962fe 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 6ea4771..ab0bc17 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/gpus-for-github-actions.html b/blog/gpus-for-github-actions.html index 1157d83..246a9f9 100644 --- a/blog/gpus-for-github-actions.html +++ b/blog/gpus-for-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Accelerate GitHub Actions with dedicated GPUs

    You can now accelerate GitHub Actions with dedicated GPUs for machine learning and AI use-cases.

    With the surge of interest in AI and machine learning models, it's not hard to think of reasons why people want GPUs in their workstations and production environments. They make building & training, fine-tuning and serving (inference) from a machine learning model just that much quicker than running with a CPU alone.

    +
    ActuatedActuated logo

    Accelerate GitHub Actions with dedicated GPUs

    You can now accelerate GitHub Actions with dedicated GPUs for machine learning and AI use-cases.

    With the surge of interest in AI and machine learning models, it's not hard to think of reasons why people want GPUs in their workstations and production environments. They make building & training, fine-tuning and serving (inference) from a machine learning model just that much quicker than running with a CPU alone.

    So if you build and test code for CPUs in CI pipelines like GitHub Actions, why wouldn't you do the same with code built for GPUs? Why exercise only a portion of your codebase?

    GPUs for GitHub Actions

    One of our earliest customers moved all their GitHub Actions to actuated for a team of around 30 people, but since Firecracker has no support for GPUs, they had to keep a few self-hosted runners around for testing their models. Their second hand Dell servers were racked in their own datacentre, with 8x 3090 GPUs in each machine.

    @@ -125,4 +125,4 @@

    Reach out for more

    Do you want to fine-tune, train, or run a batch of inferences on a model? You can do that. GitHub Actions has a 6 hour timeout, which is plenty for many tasks.

    Would it make sense to run Stable Diffusion in the background, with different versions, different inputs, across a matrix? GitHub Actions makes that easy, and actuated can manage the GPU allocations for you.

    Do you run inference from OpenFaaS functions? We have a tutorial on OpenAI Whisper within a function with GPU acceleration here and a separate one on how to serve Server Sent Events (SSE) from OpenAI or self-hosted models, which is popular for chat-style interfaces to AI models.

    -

    If you're interested in GPU support for GitHub Actions, then reach out to talk to us with this form.

    \ No newline at end of file +

    If you're interested in GPU support for GitHub Actions, then reach out to talk to us with this form.

    \ 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 c252dee..61b656e 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 d920813..75280ff 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 43593e8..4f41b21 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 68db6bc..114ab15 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.

    @@ -167,4 +167,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 9c7ed84..870d5b1 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 7a119ff..fa7c3f3 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 ccb557f..397775b 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 71d5ad2..e6e695f 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/ollama-in-github-actions.html b/blog/ollama-in-github-actions.html index 3bae756..a100877 100644 --- a/blog/ollama-in-github-actions.html +++ b/blog/ollama-in-github-actions.html @@ -4,7 +4,7 @@ gtag('js', new Date()); gtag('config', 'G-M5YNDNX7VT'); -
    ActuatedActuated logo

    Run AI models with ollama in CI with GitHub Actions

    With the new GPU support for actuated, we've been able to run models like llama2 from ollama in CI on consumer and datacenter grade Nvidia cards.

    That means you can run real end to end tests in CI with the same models you may use in dev and production. And if you use OpenAI or AWS SageMaker extensively, you could perhaps swap out what can be a very expensive API endpoint for your CI or testing environments to save money.

    +
    ActuatedActuated logo

    Run AI models with ollama in CI with GitHub Actions

    With the new GPU support for actuated, we've been able to run models like llama2 from ollama in CI on consumer and datacenter grade Nvidia cards.

    That means you can run real end to end tests in CI with the same models you may use in dev and production. And if you use OpenAI or AWS SageMaker extensively, you could perhaps swap out what can be a very expensive API endpoint for your CI or testing environments to save money.

    If you'd like to learn more about how and why you'd want access to GPUs in CI, read my past update: Accelerate GitHub Actions with dedicated GPUs.

    We'll first cover what ollama is, why it's so popular, how to get it, what kinds of fun things you can do with it, then how to access it from actuated using a real GPU.

    ollama can run in CI with isolated GPU acceleration using actuated

    @@ -25,7 +25,7 @@

    A quick tour of ollama

    By default, its REST API will listen on port 11434 on 127.0.0.1.

    You can find the reference for ollama's REST API here: API endpoints - which includes things like: creating a chat completion, pulling a model, or generating embeddings.

    -

    You can then browse available models on the official website, which resembles the Docker Hub.

    +

    You can then browse available models on the official website, which resembles the Docker Hub. This set currently includes: gemma (built upon Google's DeepMind), mistral (an LLM), codellama (for generating Code), phi (from Microsoft research), vicuna (for chat, based upon llama2), llava (a vision encoder), and many more.

    Most models will download with a default parameter size that's small enough to run on most CPUs or GPUs, but if you need to access it, there are larger models for higher accuracy.

    For instance, the llama2 model by Meta will default to the 7b model which needs around 8GB of RAM.

    # Pull the default model size:
@@ -33,6 +33,7 @@ 
    A quick tour of ollama
    
 ollama pull llama2
 
 # Override the parameter size
+
 ollama pull llama2:13b

    Once you have a model, you can then either "run" it, where you'll be able to ask it questions and interact with it like you would with ChatGPT, or you can send it API requests from your own applications using REST and HTTP.

    @@ -50,7 +51,7 @@

    A quick tour of ollama

    }' | jq

    Access ollama from Python code

    -

    Here's how to access the API via Python, the stream parameter will emit JSON progressively when set to True, block until done if set to False. With Node.js, Python, Java, C#, etc the code will be very similar, but using your own preferred HTTP client.

    +

    Here's how to access the API via Python, the stream parameter will emit JSON progressively when set to True, block until done if set to False. With Node.js, Python, Java, C#, etc the code will be very similar, but using your own preferred HTTP client. For Golang (Go) users, ollama founder Jeffrey Morgan maintains a higher-level Go SDK.

    import requests
 import json
 
@@ -73,8 +74,8 @@ 
    Access ollama from Python code
    
 print(json.dumps(response_json, indent=4))

    Putting it together for a GitHub Action

    -

    The following GitHub Action will run on for customers who are enrolled for GPU support for actuated.

    -

    The initial set self-actuated/nvidia-run installs either the consumer or datacenter driver for Nvidia, depending on what you have in your system and takes about 30 seconds. This can be cached, if you like.

    +

    The following GitHub Action will run on for customers who are enrolled for GPU support for actuated. If you'd like to gain access, contact us via the form on the Pricing page.

    +

    The self-actuated/nvidia-run installs either the consumer or datacenter driver for Nvidia, depending on what you have in your system. This only takes about 30 seconds and could be cached if you like. The ollama models could also be cached using a local S3 bucket.

    Then, we simply run the equivalent bash commands from the previous section to:

    \ No newline at end of file +

    Feel free to reach out for early access, or to see if we can help your team with your CI needs.

    \ 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 8b47752..25d9aaa 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 2dcb580..3e88c2d 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 ed5baf7..267122c 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 970c17a..84f808e 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 2f8d274..55e5580 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 a886fb1..7148339 100644 --- a/rss.xml +++ b/rss.xml @@ -4,7 +4,7 @@ Actuated - blog https://actuated.dev Keep your team productive & focused with blazing fast CI - Mon, 25 Mar 2024 11:04:46 GMT + Mon, 25 Mar 2024 11:18:04 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed @@ -39,7 +39,7 @@

    By default, its REST API will listen on port 11434 on 127.0.0.1.

    You can find the reference for ollama's REST API here: API endpoints - which includes things like: creating a chat completion, pulling a model, or generating embeddings.

    -

    You can then browse available models on the official website, which resembles the Docker Hub.

    +

    You can then browse available models on the official website, which resembles the Docker Hub. This set currently includes: gemma (built upon Google's DeepMind), mistral (an LLM), codellama (for generating Code), phi (from Microsoft research), vicuna (for chat, based upon llama2), llava (a vision encoder), and many more.

    Most models will download with a default parameter size that's small enough to run on most CPUs or GPUs, but if you need to access it, there are larger models for higher accuracy.

    For instance, the llama2 model by Meta will default to the 7b model which needs around 8GB of RAM.

    # Pull the default model size:
@@ -47,6 +47,7 @@
 ollama pull llama2
 
 # Override the parameter size
+
 ollama pull llama2:13b

    Once you have a model, you can then either "run" it, where you'll be able to ask it questions and interact with it like you would with ChatGPT, or you can send it API requests from your own applications using REST and HTTP.

    @@ -64,7 +65,7 @@ ollama pull llama2:13b }' | jq

    Access ollama from Python code

    -

    Here's how to access the API via Python, the stream parameter will emit JSON progressively when set to True, block until done if set to False. With Node.js, Python, Java, C#, etc the code will be very similar, but using your own preferred HTTP client.

    +

    Here's how to access the API via Python, the stream parameter will emit JSON progressively when set to True, block until done if set to False. With Node.js, Python, Java, C#, etc the code will be very similar, but using your own preferred HTTP client. For Golang (Go) users, ollama founder Jeffrey Morgan maintains a higher-level Go SDK.

    import requests
 import json
 
@@ -87,8 +88,8 @@ response_json = response.json()
 print(json.dumps(response_json, indent=4))

    Putting it together for a GitHub Action

    -

    The following GitHub Action will run on for customers who are enrolled for GPU support for actuated.

    -

    The initial set self-actuated/nvidia-run installs either the consumer or datacenter driver for Nvidia, depending on what you have in your system and takes about 30 seconds. This can be cached, if you like.

    +

    The following GitHub Action will run on for customers who are enrolled for GPU support for actuated. If you'd like to gain access, contact us via the form on the Pricing page.

    +

    The self-actuated/nvidia-run installs either the consumer or datacenter driver for Nvidia, depending on what you have in your system. This only takes about 30 seconds and could be cached if you like. The ollama models could also be cached using a local S3 bucket.

    Then, we simply run the equivalent bash commands from the previous section to: