alexellisuk

Hey - it's Alex here. Someone sent me a link to the parent comment.

Thank you John - for the support.

Tremon - I get it - Hacker News users are super sceptical and fastidious.

Here's a link to the "call to arms" as John calls it: https://blog.alexellis.io/docker-is-deleting-open-source-ima...

Alex

The cost of Heroku was 50 USD / mo for 1GB of application RAM. I can't imagine that a GKE cluster, plus nodes, plus cloud SQL (and you refer to AWS S3 too?), plus bandwidth all adds up to less than 50 USD / mo.

What's your cost breakdown like?

And how are you finding it so far?

Hi - Alex - maintainer of OpenFaaS here.

This mainly affects Community Edition users (free users) who haven't updated their cluster in over two years.

It may also affect you if you maintain your own fork of our official templates, or your own custom templates.

I posted a link to this tool a couple of weeks ago, since then we've made it work for personal users accounts with community contributions and produce some more insights like the longest build - total amount of committers over the period and average build time.

Hosting a forwarding / redirect server instead of actually hosting images is probably a decent idea.

The K8s proxy is redirecting from only hosting on GCR to community-owned registries - https://kubernetes.io/blog/2023/03/10/image-registry-redirec...

You can view the code here - https://github.com/kubernetes/registry.k8s.io

But because everyone is already pointing at gcr.io (just like many openfaas users point at docker.io/) - they're having to do a huge campaign to announce the new URL - the same would apply with the author's solution here.

I wrote some automation for hosting (not redirects) in arkade with the OSS registry - Get a TLS-enabled Docker registry in 5 minutes - https://blog.alexellis.io/get-a-tls-enabled-docker-registry-...

The registry is also something you can run on a VM if you so wish, and have act as a pull through cache.

Apart from reliability - GitHub's container registry is the current next best option - but we have to ask ourselves, what happens when they start charging or the outages start to last longer or are more frequent than 1-2 times per week as we've seen in Q1 2023.

> Not have a pathway to commercialization. Your organization must not seek to make a profit through services or by charging for higher tiers. Accepting donations to sustain your efforts is permissible.

You only get help if you live in poverty without any path to being paid for your time and work. Tips are "permissible"

We publish openfaas images to ghcr.io and have no complaints. GitHub has had a rough time of it lately with numerous outages, but overall the registry is solid.

https://www.githubstatus.com/history?page=1

Utterly confusing messaging from Docker once again, and this is from a prior advocate for early Docker, and part of their Captains program for several years.

The wording seems clear that they are going to delete all data and lock access unless payment is received within 30 days, whether there are public or private repos in the organisation.

I pay for a personal account, however my main concern is people taking over the official account names and publishing poison images which people are used to pulling already, and won't even think to check if the account ownership has changed.

I've asked the CTO to comment on Twitter.

https://twitter.com/alexellisuk/status/1635679295891812359?s...

I couldn't find an announcement for this, other than the email.

The implication is that any organisation on the Docker Hub, including OSS / public orgs need to be attached to separate paying subscriptions or will be deleted in 30 days?

Why is this Show HN? It's an OSS project, in the blog post, I add colour and talk more about how the libraries work and the rapid prototyping style I used to write the tool.

There's also an incoming PR that fixes the first feature request - to run on a personal account.

I’m also having issues pulling images from ghcr.io

Hi, I'm the founder of inlets. I often hear folks getting confused about VPNs like Wireguard and network tunnels. This post is covering some of the options for getting ingress, and what it looks like to expose an Ingress Controller or Istio Gateway publicly.

I cover VPNs, port-forwarding and other options where you just want private access to the cluster with something like Wireguard.

VPNs and network tunnels are both awesome tools - just different use-cases. I know a bunch of inlets users who also use ZeroTier, Wireguard and etc.

Alex

Hi, I'm the original author of inlets and current lead of the product.

Over the past three years we’ve seen inlets has become a hit with developer advocates, but why? And how does it stack up against Tailscale, Ngrok and Wireguard?

Join me to look at examples from users and how it stacks up for different use-cases.

In 2017, I thought multi-stage builds were one of the most important things we'd see for Docker builds. Today I wrote up why I think multi-arch builds are just as important, and how you can start implementing them in your GitHub Actions.

"This is my guide to troubleshooting applications deployed on a Kubernetes cluster. It's based upon my experience with the technology since I switched over from Docker in early 2017."

Already an expert? Send this to your colleagues and customers. I hope it will save you as much time as it's saved me.

The more I talk to OSS projects and VC backed software companies who need to not only build on ARM, but also test, the more I think we can do better here.

Until recently it looked like the older AWS a1.metal chip was the cheapest way to get bare-metal, but the offering from Hetzner is really something else. (No affiliation)

If you'd like to try out faster bare-metal feel free to reach out to me using the form on the website. Since we're doing "things that don't scale" because this is the beginning of the journey, we can even hook you up to one of our ARM servers if you want to see how much quicker builds will be.

Alex

We use Firecracker in (actuated.dev) and I've personally noodled with it for OpenFaaS and a few other experiments. There seems to be a growing number of folks jumping into the Slack and asking 101 questions.

I may find that personally quite testing since this info is very easy to find with a Google search - but that's the nature of having a public Slack. Plenty of low-bar folks turning up, mixed in with the more experienced users.

In any case, the AWS team answered a question like "What's the difference between Firecracker and a VM?" by posting a link to this paper.

I hope you like it, even if you think you know what it is, there are some insights into the original creation, the use-case and what it isn't supposed to be.

And if you find yourself needing more than what Firecracker does - i.e. PCI or dynamic resizing of live VMs, check out Cloud Hypervisor, which is essentially a fork that took the code in a different direction.

As the founder of OpenFaaS, the author doesn't know how true this rings - given all the myriad enterprise users of the community edition/OSS code. Even with smaller projects like K3sup, where I've seen defence contractors have k3sup references in their codebases and issue comments, go on to ask for changes, yet publicly stating they've never used it.

We did pivot the business model in ~ 2019 to open core, and I've tried to apply that to future endeavours like inlets, with the latest "actuated" - self-hosted CI in microVMs - it's a SaaS, with no open source components.

The common retort from users is "when we're in production, we'll pay for support / sponsor the project" - this literally never happens.

I applaud the author for laying it out how it is - there is no business relationship, open source maintainers are not suppliers, but if you want us to become your suppliers, have procurement reach out. Because we may well be able to offer you a relationship that would be mutually beneficial.

Who spotted the GitHub commit graph towards the end of the page? Looks like they were busy.

That is the old verbiage, with the current plan, hitting a certain level gets you down to 3% including all fees.

Turns out this poor communication from Gumroad actually means a 13+% fee since the Stripe fee is no longer included in what Gumroad take.

So 10% + 2.9% + 50c?

As a big user of Gumroad for eBooks and subscriptions this will really hurt our business. The timing couldn’t have been worse in this economy.

I don’t mind paying more, but this is 3x. It incentivises customers to move SaaS subscriptions off the platform.

The fact that Sahil thinks this is fair game makes me worry he’ll get overconfident and increase it further to 20% at a moment’s notice. What can he do to restore credibility after this move?

Hi, I'm Alex the founder of actuated. We've been following the monetising innovation and The Right It playbooks here, and only investing as much time and money as it seems to make sense given customer interest.

NB: for the mods, we are calling actuated "blazing fast CI", but we also understand that you want to rename the post to just "fast CI". I've settled on "faster CI" for Hacker News, hope this is OK with you?

It was great to see our message resonate so much on the front page a couple of weeks ago. Thanks for your support.

Here's the next iteration, our website. It's made with Tailwind UI and there'll be more to come.

If what we're building resonates with you, please reach out for a quick user interview and to get started with actuated.

We have live customers and they've had good results. But we want to prove that we can help more teams like yours.

https://actuated.dev/

The hosted Actions Runners are super convenient. I use them a lot for OSS.

For private repos and work stuff, we are working on actuated, which comes with unmetered billing minutes because you BOY machines or cloud instances.

ARM builds show to be ~ 20-30x faster than using QEMU too.

https://docs.actuated.dev/

It was up on Hacker News recently, so you may have already seen it.

https://blog.alexellis.io/blazing-fast-ci-with-microvms/

If folks do need to SSH into a runner to get over some humps, come and talk to me. No point in waiting to get to that 5 or 25 minute mark in a job just to change one line and have to wait again.

https://www.youtube.com/watch?v=l9VuQZ4a5pc

https://twitter.com/alexellisuk/status/1577977820055310336

Users provide a number of hosts and run a simple agent. We maintain the OS image, Kernel configuration and control plane service, with support for ARM64 too.

That is a benefit over DIND and socket sharing, however it doesn't allow for running containers or K8s itself within a job. Any tooling that depends on running "docker" (the CLI) will also break or need adapting.

This also comes to mind: "root in the container is root on the host" - https://suraj.io/post/root-in-container-root-on-host/

You still have those same problems with hosted runners, don't you?

We're trying to re-create the hosted experience, but with self-hosted, faster, infrastructure, without needing to account for metered billing.

Hi, I'd not heard of webapp.io before so thanks for mentioning it. Actuated is not a preview branch product, that's an interesting area but not the problem we're trying to solve.

actuated is not trying to be a CI system or a replacement for one like webapp.

It's a direct integration with GitHub Actions, and as we get interest from pilot customer for GitLab etc, we'll consider adding support for those platforms too.

Unopinionated, without lock-in. We want to create the hosted experience, with safety and speed built in.

There is a misconception that Kaniko means non-root, but in order to build a container it has to work with layers which requires root.

Using Kaniko also doesn't solve for:

How do you run containers within that build in order to test them? How do you run KinD/K3s within that build to validate the containers e2e?