I would never go back installing something without docker. Never.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
i use it for gitea, nextcloud, redis, postgres, and a few rest servers and love it!, super easy
it can suck for things like homelab stablediffusion and things that require gpu or other hardware.
postgres
I never use it for databases. I find I don't gain much from containerizing it, because the interesting and difficult bits of customizing and tayloring a database to your needs are on the data file system or in kernel parameters, not in the database binaries themselves. On most distributions it's trivial to install the binaries for postgres/mariadb or whatnot.
Databases are usually fairly resource intensive too, so you'd want a separate VM for it anyway.
Don't learn Docker, learn containers. Docker is merely one of the first runtimes, and a rather shit one at that (it's a bunch of half-baked projects - container signing as one major example).
Learn Kubernetes, k3s is probably a good place to start. Docker-compose is simply a proprietary and poorly designed version of it. If you know Kubernetes, you'll quickly be able to pick up docker-compose if you ever need to.
You can use buildah bud
(part of the Podman ecosystem) to build containerfiles (exactly the same thing as dockerfiles without the trademark). Buildah can also be used without containerfiles (your containerfiles simply becomes a script in the language of your choice - e.g. bash), which is far more versatile. Speaking of Podman, if you want to keep things really simple you can manually create a bunch of containers in a pod and then ask Podman to create a set of systemd units for you. Podman supports nearly all of what docker does (with exception to docker's bjorked signing) and has identical command line syntax. Podman can also host a docker-compatible socket if you need to use it with something that really wants docker.
I'm personally a big fan of Podman, but I'm also a fan of anything that isn't Docker: LXD is another popular runtime, and containerd is (IIRC) the runtime underpinning docker. There's also firecracker or kubevirt, which go full circle and let you manage tiny VMs like containers.
There are teachings I have read/ discovered through YouTube (can't remember exactly where) about the reasons and the philosophy behind moving to docker, or having it as a state machine.
Have you considered looking into dockers alternatives, also ?
Here is 1 of the sources that may give you insights:
https://www.cloudzero.com/blog/docker-alternatives/
-- There has been some concerns over docker's licensing and, as such, some people have started preferring solutions such as podman and containerd.
Both are good in terms of compatibility and usability, however I have not used them extensively.
Nonetheless, I am currently using docker for my own hyperserver [Edit2: oops, I meant hypervisor ✓, not hyperserver] purposes. And I am also a little concerned about the future of docker, and would consider changing sometime in the future.
[Edit1: I am using docker because it is easy to make custom machines, with all files configurations, and deploy them that way. It is a time saver. But performance wise, I would not recommend it for major machines that contain major machine processes and services. And that's just the gist of it].
I am a network engineer and I am learning it. I see it in the next step from the bare metal -> virtualisation evolution