Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
Moby
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
They've also got Longhorn, a distributed container-attached storage solution that's very simple to understand and easy to deploy. Performance is another thing but that's the same with all of the general networked storage solutions (Ceph included).
Rancher's got a well deserved good impression in my mind, though early on I avoided it since it seemed like they were building a walled garden.
[0]: https://github.com/longhorn/longhorn
Rancher's, and Podman's, efforts on Mac are exciting, but you can also just run the Docker daemon in a VM on Mac and install the free docker CLI using homebrew. This is what I do using Canonical's Multipass to create the VM. I wrote a simple script that makes it a simple `dockerhost create`. https://github.com/leighmcculloch/dockerhost
Dropping by to express healthy interest in this project.
Rancher have a pretty good track record so far:
- the Rancher platform itself (https://rancher.com/) is a really powerful and user friendly way to manage container clusters of all sorts, giving you a self-hosted dashboard for both your cloud and on prem clusters, for a variety of Kubernetes distributions; you can even manage the available drivers and also create deployments graphically
- the K3s distribution (https://k3s.io/) is in my eyes one of the best ways to run Kubernetes yourself, both in development environments and production ones. I benchmarked K3s alongside Docker Swarm as a part of my Master's thesis and it was surprising to see that its overhead was actually very close to that of Docker Swarm (a more lightweight orchestrator that's included with Docker and uses the Docker Compose format), only exceeding it by a few hundred MB with similar deployments being active, making K3s passable for small nodes
The problem with this is that if Docker Inc goes under, you can say goodbye to Docker Hub: https://hub.docker.com/
Sure, there are alternative repositories and for your own needs you can use anything from Sonatype Nexus, JFrog Artifactory, Gitlab Registry or any of the cloud based ones, but Hub disappearing would be a 100 times worse than the left pad incident in the npm world.
Thus, whenever Docker Inc releases a new statement about some paid service that may or may not get more money from large corporations, i force myself to be cautiously optimistic, knowing that the community of hackers will pick up the slack and work around those tools on a more personal scale (e.g. Rancher Desktop vs Docker Desktop). That said, it might just be a Stockholm Syndrome of sorts, but can you imagine the fallout if Hub disappeared?
> Hub disappearing would be a 100 times worse than the left pad incident in the npm world
This is really overdramatic. If Docker Inc. went out of business and Docker Hub was shutdown then the void would be filled very quickly. Many cloud providers would step in to fill the void. Also, swapping in a new registry for your base images is really easy (docker’s is the default registry). Not to mention the tons of lead time you’d get before docker hub goes down to swap them. Maybe they’d even fix https://github.com/moby/moby/issues/33069 on their way out, so we can just swap out the default registry in the config and be done with it.
As i said, if it's not exposed to the outside world and doesn't work with untrusted data, that claim is not entirely valid.
Imagine something like this getting abandoned, or someone running a year old version of it: https://github.com/crazy-max/swarm-cronjob/blob/master/READM...
Its only job is to run containers on a particular schedule, no more no less. There are very few attack vectors for something like that, considering that it doesn't talk to the outside world, nor processes any user input data.
Then again, it's not my job to pass judgement on situations like that, merely acknowledge that they exist and therefore the consequences of those suddenly breaking cannot be ignored.
Recently, I found Tilt [0] to be a good partner of mine to run "all services locally". It can be compared to "webpack (live-reloading, a lot of configuration possibilities) for backend". You want to run a bunch of services directly? Use local_resource()/local(). You have Procfile? There is procfile() function. You have docker-compose.yml with databases? You can run it too with docker_compose(). You want have Tiltfile and include them all-together? There is load(). You need some web-ui for frontend devs and a nice log browser? It is there too. You need to do some extra steps before running a service? You want to update your local cluster with newly built image on file save? No problem, tilt will do that with k8s_yaml() function. Tilt uses Titlfiles for configuration, which are written Pythonish Starlark language and you use them to run any specific logic there.
Also, I am not very lucky in having resemble 1:1 k8s cluster locally. You could be close but as long as you don't run already in cloud you will have different configuration (additional annotations, various quirks that do not exist in kind/k3s but they are on GCP). However, making dedicated dev environments in the cloud might be very costly and incur a lot of additional tinkering.
[0]: https://tilt.dev/
Shameless plug, I had the exact same problem with wanting to deploy some apps to a server (either home, on production at work, or IoT/Raspberry Pis), and I didn't like any of the options (Ansible is too dependent on the machine's state, Kubernetes is too complicated and heavy), so I wrote 200 lines of code and made this, which I love:
https://gitlab.com/stavros/harbormaster
It basically pulls the repos you specify and runs `docker-compose up` on them, but does it in an opinionated way to make it easy for you to administrate the machines.
- https://dokku.com/
It took me an hour to figure out the necessary arguments until I learned about some Electron-specific behavior in the installer[1].
[0] https://github.com/rancher-sandbox/rancher-desktop/releases
[1] https://stackoverflow.com/a/66906851