7,439 karma · joined March 31, 2016
It seems like buildjet is competing directly with GitHub on price (GitHub has bigger runners available now, pay per minute), and GitHub will always win because they own Azure, so I'm not sure what their USP is and worry they will get commoditised and then lose their market share.
Actuated is hybrid, not self-hosted. We run actuated as a managed service and scheduler, you provide your own compute and run our agent, then it's a very hands-off experience. This comes with support from our team, and extensive documentation.
Agents can even be cheap-ish VMs using nested virtualisation, you can learn a bit more here: https://docs.actuated.dev/add-agent/
But if you just want to try out Firecracker, I've got a free lab listed in the blog post.
I hear Podman desktop is also getting some traction, if you have particular issues with Docker Desktop.
Yeah a lot of people have talked about Firecracker in the past, that's why I focus on the pain and the problem being solved. The tech is cool, but it's not the only thing that matters.
People need to know that there are better alternatives to sharing a docker socket or using DIND with K8s runners.
Fly has a lot of ideas here, and we've also been able to optimize how things work in terms of downloads and as for boot-up speed, it's less than 1-2s before a runner is connected.
https://github.com/firecracker-microvm/firecracker/blob/main...
The VMs launch super quick in < 1s they are actually running a job.
That video covers this is great detail. Click on the the video under 1) and have a watch, it should answer all your questions.
I didn't want to repeat the content there
To get hands on, you can run my Firecracker lab that I shared in the blog post, then add a runner can be done with "arkade system install actions-runner"
We also explain how it works here: https://docs.actuated.dev/faq/
https://www.youtube.com/watch?v=CYCsa5e2vqg
For info on actuated, check out the FAQ or the docs: https://docs.actuated.dev
We're running a pilot and looking for customers who want to make CI faster for public or self-hosted runners, want to avoid side-effects and security compromise of DIND / sharing a Docker socket or need to build on ARM64 for speed.
Feel free to reach out
inletsctl - automates a VM with the inlets tunnel server preinstalled, including with HTTPS termination with Let's Encrypt, or pure TCP pass-through
inlets-operator - the same for Kubernetes Load Balancer services
Feel free to take a look at https://inlets.dev/
We talk a lot about the community adoption here in the first half -https://inlets.dev/blog/2022/11/16/service-provider-uplinks....
(I'm the original founder of inlets)
https://twitter.com/alexellisuk/status/1585562359254421504?s...
Support for the Qualcomm chip did land in v6.0 of the Kernel - https://github.com/torvalds/linux/commit/b6a6535b339776d32fa...
I just had mine arrive today, which I wanted to enroll as an ARM64 build agent (with Firecracker) for self-actuated ( https://docs.actuated.dev ) - this does actually work with Asahi Linux and the Mac Mini M1, but that was double the price for half the RAM.
So far, it's not looking good, with Ubuntu Server 22.04 and 22.10 both crashing after the Grub menu. I'm sharing progress here:
https://twitter.com/alexellisuk/status/1585562359254421504?s...
Here's a quick overview:
> We’ll show you how to access any part of the Kubernetes API or a Custom Resource using a ServiceAccount and granular permissions
> You’ll learn how you’re already using the Kubernetes API, what an Operator is, and why a Function may be a better fit some of the time. We’ve also included a code-example so you can get going with that today.
Disclaimer: we both work at OpenFaaS Ltd and maintain the OSS project full time.
So they'd been writing pretty verbose / obtuse HAProxy configs. They also needed a Linux host for HAProxy, which they couldn't guarantee.
I knew that a tiny Go binary could do this task and give us more control over configuration for the future. I asked them to give me an hour, then wrote up this tool and sent it over for them.
> If you’ve ever run a reverse proxy, tunnel or load balancer (LB) and wondered why you saw internal IP addresses in your logs, then you’re not alone. The plaintext HTTP protocol has a number of “X-Forwarded-*” headers that covers this for proxies which decrypt traffic. But what if you’re using TLS, or TCP which works at a lower level in the Open Systems Interconnection model (OSI model)?
> That’s where Proxy Protocol comes in.
Chris has a video demo here (also featuring K9s) - https://www.youtube.com/watch?v=nupRBh9Iypo
This is quite a revolution - similar to when the micro services got melted down into "istiod".
Hope this is useful and entertaining for some of you that read it.
The idea is that some of you will go on to adapt the example for your own use at work / home.
If you can see yourself using it, let me know. Try it out.
This is how it's being used in OpenFaaS to help support customers: https://github.com/openfaas/config-checker
A similar and more generic tool from Replicated is: https://github.com/replicatedhq/troubleshoot
And if you wanted to see how easy it is to play around with the K8s API with Go, hopefully this example will give you a bit more confidence to try some hacking.
My question is how are you guaranteeing uniqueness, or do you only clone snapshots for a single tenant? [3]
[1] https://github.com/self-actuated/actuated [2] https://github.com/firecracker-microvm/firecracker-go-sdk [3] https://github.com/firecracker-microvm/firecracker/blob/main...
What if you're not using OpenFaaS yet? Glad you asked. The examples work with any chart or CRD, so if you're using K8s, you can probably use what we've written here.
Check out other articles on CD on the blog.
What prompted you to invest your time in this project vs the others that you were probably considering?
There's a thread on Twitter where I'm happy to take questions, suggestions, etc. https://twitter.com/openfaas/status/1550063046663569409
Feel free to try out the steps in the post, or hit me up on Twitter @alexellisuk to chat.
Alex