the biggest selling point for me is that I’ll have a mounted folder or two, a shell script for creating the container, and then if I want to move the service to a new computer I just move these files/folders and run the script. it’s awesome. the initial setup is also a lot easier because all dependencies and stuff are bundled with the app.
in short, it’s basically the exe-file of the server world
runs everything as root (not many well built images with proper useranagement it seems)
that’s true I guess, but for the most part shit’s stuck inside the container anyway so how much does it really matter?
you cannot really know which stuff is in the images: you must trust who built it
you kinda can, reading a Dockerfile is pretty much like reading a very basic shell script for the most part. regardless, I do trust most creators of images I use. most of the images I have running are either created by the people who made the app, or official docker images. if I trust them enough to run their apps, why wouldn’t I trust their images?
lots of mess in the system (mounts, fake networks, rules…)
that’s sort of the point, isn’t it? stuff is isolated
I’ll answer your question of why with your own frustration - bare metal is difficult. Every engineer uses a different language/framework/dependencies/whathaveyou and usually they’ll conflict with others. Docker solves this be containing those apps in their own space. Their code, projects, dependencies are already installed and taken care of, you don’t need to worry about it.
Take yourself out of homelab and put yourself into a sysadmin. Now instead of knowing how packages may conflict with others, or if updating this OS will break applications, you just need to know docker. If you know docker, you can run any docker app.
So, yes, volumes and environments are a bit difficult at first. But it’s difficult because it is a standard. Every docker container is going to need a couple mounts, a couple variables, a port or two open, and if you’re going crazy maybe a GPU. It doesn’t matter if you’re running 1 or 50 containers on a system, you aren’t going to get conflicts.
As for the security concerns, they are indeed security concerns. Again imagine you’re a sysadmin - you could direct developers that they can’t use root, that they need to be built on OS’s with the latest patches. But you’re at home, so you’re at the mercy of whoever built the image.
Now that being said, since you’re at their mercy, their code isn’t going to get much safer whether you run it bare-iron or containerized. So, do you want to spend hours for each app figuring out how to run it, or spend a few hours now to learn docker and then have it standardized?
I previously used WikiJS, but since about a year ago I switched to Grav.
The really nice thing is not having an additional database anymore. It’s really just markdown pages, config files and php plugins.
By default it looks like a blogging platform, but with the learn2 theme it also works pretty well as a documentation website. The official docs are written using that theme.
I wasn’t completely happy with the defaults though so I did some modifications for my own wiki. Some limited knowledge in HTML, CSS is required and PHP or Javascript don’t hurt either.
You can find the theme, plugins and pages in my repo as well if you’d want to use any of it.
Portainer + caddy + watchtower, this will give you the benefits of containers without the complexity of Kubernetes. As someone who professionally works with Kubernetes, I agree with what other people have said here: “only run it if you want to learn it for professional use”.
Portainer is a friendly UI for running containers. It supports docker compose as well. It helps with observability and ops.
Caddy is an easy proxy with automatic Let’s Encrypt support.
Watchtower will update and restart your containers if there’s an update.
(Edit: formatting)
Icinga2 works reasonably well for us. It is easy to write new checks as small shell scripts (or any other binary that can print and set and exit status code).
Reduce your threat profile. Run sslh, 443 handles both SSL and ssh. Adjust your host based firewall to just 443 Attack yourself on that port, identify the logs Add the new profiles to fail2ban Enable fail2ban email If you don’t like email, use a service that translates email to notification. Ntfy.sh is free notifications Or… Use something like tailscale and don’t offer a remote login to the general Internet.
I submitted your post to got here’s what it thought
I used zabbix at some point, but I never looked at the data so I stopped. Zabbix shows all kind of stuff.
I have cockpit on my bare-metal that has some stats, and netdata on my firewall, I do not track any of my VM’s (except vnstat that runs on everything device).
I run Prometheus on a separate cluster, so I plug my servers with node_exporter and scrape metrics. I then alert with grafana. To be honest, the setup is heavier (resource usage-wise) than I would like for my use case, but it’s what I am used to, and scales well to multiple machines.
I have a huge datablob that I mirror off-site once monthly. I have a few services that provides things for my family, I take a backup of them nightly (and run a “backup-restoration” scenario every six months). For my desktop, none at all - but I have my most critical data synched / documented so they can be restored to a functional state.
selfhosted
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.