Flynn
Moby
Our great sponsors
Flynn | Moby | |
---|---|---|
9 | 212 | |
7,923 | 67,716 | |
- | 0.4% | |
2.9 | 10.0 | |
over 2 years ago | about 21 hours ago | |
Go | Go | |
BSD 3-clause "New" or "Revised" License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Flynn
-
Why is kubernetes source code an order of magnitude larger than other container orchestrators?
Considering other orchestration tools like dokku, dcos, deis, flynn, docker swarm, etc.. Kubernetes is no where near to them in terms of lines of code, on an average those tools are around 100k-200k lines of code.
-
A Foolish Consistency: Consul at Fly.io
> we are indeed writing a new orchestration system in Go, called `flyd`.
I know it's just a wild coincidence, but I couldn't help but be reminded of https://github.com/flynn/flynn
-
Show HN: Coolify v2 An open-source and self-hostable Heroku/Netlify alternative
I love these projects and I'll definitely look into it more later. At the same time, I think it would be hard for me to want to leave Kubernetes. K8s isn't something that I love, but it's something that I know works and will continue to be supported in some fashion. I've seen Flynn (https://github.com/flynn/flynn) EOL. I've seen Docker Swarm's future be a bit hazy. I've seen Porter decide to put pretty restrictive limits on their free tier (though it is open source). I've seen Dokku lose steam and then pick up again - but still not be a solution for more than one server.
I love the idea of something that will Just Work, but a lot of stuff doesn't handle the parts I care about the most. Will my one-click PostgreSQL have a couple replicas in my cluster? Will it launch pg-backrest so I can have it backed up to S3? Will it deal with secret storage so I can just add my secrets in the UI and then have my apps grab those secrets as environment vars? Will it fail-over nicely?
Coolify looks really cool and I do want to check it out for real later (probably over the weekend to be realistic). However, it seems like it's single-server (for now) and that seems less compelling for me at the moment. It looks like you're planning on K8s support which would just be wonderful.
Part of me wishes I could get a much simplified UI for K8s. I use Lens at the moment and while it's very good, it doesn't really smooth over the rough bits of K8s, just kinda organizes and presents them. K8s isn't as bad as a lot of people say once you get past the pain of learning. Still, it misses the mark if what you just want a few simple things Heroku-style instead of every bell and whistle. Small users don't care about ingress, they just want their app to be accessible. Small users aren't interested in namespaces or storage classes or roles. Sure, it's important for K8s to support storage classes for large users who might have all sorts of opinions on how they want their data stored. For a small user, you often just want it stored on the local disk.
Likewise, I think there's a reasonably small set of things people often want to run. For example, the databases Coolify supports (MongoDB, MySQL, PostgreSQL, CouchDB, RedisDB) are probably what 95% of people want. There are K8s operators to run them, but like K8s itself it can often be "here's every knob we could think of, we documented 80% of them, now go write some yaml." Heroku lets me deploy PostgreSQL without that. Why can't I get something a bit more slimmed down like Heroku on K8s - so that if I need the additional power in the future, I can get my hands on it.
I'd even love it if this hypothetical K8s Heroku could commit the yaml it is going to apply to a GitHub repository for me so I can easily track infrastructure changes. It would even let people become more comfortable with K8s as they saw the changes they were making in the UI show up as commits in a repository.
I think the point of this rambling is that Coolify is kinda what people want from one perspective - something that seems nice and friendly and handle the cases that the vast majority of people need solved. However, it lacks the critical mass of K8s which can always leave its future in doubt (it looks like there are two of you on this project and open source can take a toll on people) and without high-availability/multi-server it feels a bit lacking for what so many people are looking for in a self-hosted Heroku. Coolify feels like what I'm looking for - I just want it with high-availability and the possibility of continuing on even if the project shuts down (because I can just use an underlying K8s layer, not because it's open source and I could become the new maintainer).
It feels like there's two camps that don't talk to each other: awesome UX people who know what people want and people building solutions that companies want while scaling up (but end up with a bit of a UX mess).
-
RIP Flynn.io
As others have mentioned, the current site (README.md) says very little about what Flynn is.
You can see a version of the repo and README.md, just before it became unmaintained, here:
https://github.com/flynn/flynn/tree/2c20757de8b32a40ba06f7e5...
IMHO it would have been much better if the maintainers had added the "Flynn is Unmaintained" information to the top of the README.md rather than removing all the existing information. I'll submit a GitHub issue suggesting it.
A plea to project maintainers in general: Please include enough information in your top-level README (or README.md, or README.whatever) so that someone who has never heard of your project can find get a good overview. I've also seen READMEs that only discuss the most recent changes. That's fine for readers who have already been following the project, but not for a more general audience.
- Flynn is no longer being developed
Moby
-
Release Radar • March 2024 Edition
Having been featured in our February 2023, and January 2024 Release Radars, Moby is the original Linux Container runtime. This new version adds a bunch of changes to the Docker CLI and Moby itself with additional features. There's bug fixes and enhancements, with the main thing for users to be on the look out for containers that were created using Docker Engine 25.0.0. These containers might have duplicate MAC addresses, and thus must be recreated. The same goes for those containers created with Moby 25.0+ and with user defined MAC addresses. Read up on all these changes in the release notes.
-
Choosing a Name for Your Computer
Formlabs does this as well for their 3d printers, my earliest encounter of this was when Docker started getting popular: https://github.com/moby/moby/blob/master/pkg/namesgenerator/...
- Docker Inc. refuses to patch HIGH vulnerabilities in Docker
-
Do not install Docker Desktop on GNU/Linux systems
Try to use moby instead since that is the engine in Docker.
https://github.com/moby/moby
-
Exploring Podman: A More Secure Docker Alternative
> Podman is designed to help with this by providing stronger default security settings compared to Docker. Features like rootless containers, user namespaces, and seccomp profiles, while available in Docker, aren't enabled by default and often require extra setup.
Seccomp has been enabled by default since 2015: https://github.com/moby/moby/pull/18780
It is true that Rootless isn't enabled by default but its "extra setup" can be done with a single command (`dockerd-rootless-setuptool.sh install`)
- Moby: Block io_uring_* syscalls in default profile
- Io_uring will be blocked by default on Docker
-
OpenZFS 2.2: Block Cloning, Linux Containers, BLAKE3
Perhaps.
Thing is, https://github.com/moby/moby/blob/670bc0a46c4ca03b75f1e72f73... is using https://github.com/mistifyio/go-zfs which features code like `out, err := zfsOutput("get", "-H", key, d.Name)` (Source: https://github.com/mistifyio/go-zfs/blob/master/zfs.go#L315) to get a single zfs property.
Somebody chose to use a library as abstraction that looks good but is implemented as a MVP (nothing wrong with that). "In the future, we hope to work directly with libzfs" should have raised an alarm somewhere, though.
-
The Twelve-Factor App
AppArmor can restrict /proc and this is even used by docker: https://github.com/moby/moby/blob/master/contrib/apparmor/te...
What are some alternatives?
easyssh-proxy - easyssh-proxy provides a simple implementation of some SSH protocol features in Go
podman - Podman: A tool for managing OCI containers and pods.
kubernetes - Production-Grade Container Scheduling and Management
containerd - An open and reliable container runtime
Gogs - Gogs is a painless self-hosted Git service
nerdctl - contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...
Gitea - Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
docker-openwrt - OpenWrt running in Docker
tsuru - Yet another script to install Tsuru and its dependencies.
ofelia - A docker job scheduler (aka. crontab for docker)
Apache Mesos - Apache Mesos
k3d - Little helper to run CNCF's k3s in Docker