There are no "production deployments" at home. You just do what you want. If it's down for a day that's fine. Putting something in a transient docker container and then bending over backwards to enable file persistence is just... wrong. And it'll lead to lots of extra work for no reason.
Do you mean declaring the volumes? What's so hard about that? There's a massive benefit when everything is homogenous. I can look at a docker-compose.yml file and instantly know where all the important data is. I can also copy volumes to a new host with a one-liner:
sudo docker run \
--rm \
--log-driver none \
--volume myservice_data:/data \
alpine \
tar -cf - -C /data . \
| ssh -o "StrictHostKeyChecking no" user@host.example.com \
'sudo docker run --rm -i \
-v myservice_data:/data \
alpine tar -C /data -xpvf -'
systemctl enable --now update-container@gitea.timer
Docker can be frustrating while you're learning it, but everything's like that and once you get proficient with it you'll never want to go back to the old way of doing things. Docker is the packaging format that won (for servers) IMO.
My setup is portainer for container management on top of docker-ce, running on debian.
I realize that homelab goes a bit beyond localhost, but we all start somewhere.
It's like writing a page on how to make bread at home but then spending most of the words on how to build an transient extra-oven outside with special parts instead of just using your oven and talking about the actual recipe steps.
It's not required, but, once you have a handle on it, you get to save a lot of time and hassle. For example, I just checked my old docs for installing and updating Nextcloud. It's 17 printed pages. My new docs are:
docker compose pull && docker compose up -d && docker logs -f nextcloud
In my experience I spend less time fixing issues related to containers than I used to maintaining everything by hand.
Updating & deploying is simple too. I can `git push` some changes from any of my computers, and then ssh (which is trivial to set up w/avahi using NixOS) into the server and `git pull && nixos-rebuild switch`.
It is, but as just any another tool it has it uses, as any other tool it has some footguns:
I see it as a waste of limited hardware resources, unless it is used for lightweight servers.
Setup caddy as a reverse proxy and it will automatically inject a local CA cert into your browsers and auto provision local SSL certs too so you can access local services by names instead of ports, and everything happily works with SSL automagically.
I really, really wish windows and mac had a similar behavior to just route all *.localhost queries to localhost.
I'm happy they don't: DNS queries should be routed to whatever I have in /etc/resolv.conf.
If I have a Pi-Hole or use 8.8.8.8, then *.localhost stuff should not be injected in some clever fashion.
If you happen to use 127.0.0.53 (or whatever) on Linux and 'magic' happens, that's on you. But the system should fiddle with things othwerise.
Windows 10 has it. Try `nslookup whatever.localhost`
** one.one.one.one can't find whatever.localhost: Non-existent domain
Tried on Win10Home 21H2 (19044.1766) and it doesn't work.
On Win10Enterprise 21H2 (19044.1706) it works.
I cannot find a documentation reference on the feature of resolving *.localhost
Sorry guys, it turned out that our corporate DNS server is giving the answers. Once I disconnected from VPN, no longer did it work :(
I think .local and .localhost domains are working on my home network for more than five years, even with systems which do not run systemd-resolved as of today.
> The hostnames "localhost" and "localhost.localdomain" as well as any hostname ending in ".localhost" or ".localhost.localdomain" are resolved to the IP addresses 127.0.0.1 and ::1.
mDNS only uses the .local suffix but AFAIK it will never resolve anything to localhost on that domain. I'm pretty sure having a mDNS service that advertises a .local domain as 127.0.0.1 would really break things too if it serves that address up to other machines on your network.
I will (and do) run Internet-facing services, but I can definitely empathise with the desire not to. And I'll only do it myself if the benefit over keeping it private outweighs the risk.
Of course this self-hosting approach does not work if you have many machines, but I have just my Laptop plus my phone.
If your apps listen on IPV6, they _are_ reachable from outside your home (provided your mobile ISP does IPV6, but they mostly do AFAIK)
It's great fun and I enjoy having the control over the few things I run. It's also super conveniant when it's running locally because I don't really have to worry much about securing the service behind reverse proxies and all that. I can just hit it however I like with any ol script.
It's not for everyone, but it works for me.
I know docker isn't the best tool for every task, but I very much enjoy how it allows me to treat my laptop and my cloud servers as almost identical machines and compartmentalize my services.
Today, few hours ago, I was thinking: "My nextcloud on SSD@RPI is superslow to render thumbnails for photos. I'v tried once to configure which thumbnails must be prerendered, but I failed and... isn't there a simple web photo album that I can hook my nextloud photos to?"
Yesterday I was disappointed that is doesn't show ANY thumbnail for my videos taken on Android.
And this post mentions PhotoPrism [1]! Feature page looks nice - exactly what I need for my mess of unorganized photos.
Have to try it out. Hope I don't find myself disappointed.
[1]
The fact that modern apps are web-apps is a living proof that the old model of document-based UIs was the right way against the widget/form model however old classic document-UIs was interactive, in the sense that the user can create and modify them inside themselves, web-apps might allow "a bit of customization" but are still FAR from being changeable at runtime by their users.
Perhaps in another 30+ years will finally rediscover the old model, sold as a very new high-tech thing, since nobody will remember the origin...
So far Emacs/org-mode/EXWM/org-roam can be used (I use them) as a document-based UI for almost anything, still integrated (thanks to EXWM) with modern/classic/raw-and-archaic GUIs like Firefox or GIMP. They are limited in GUI terms but at least they can have embedded images, live elements (org-mode headings, search&narrow UI to access them, attachments, links to anything that also just run live embedded code etc...
Of course, you need to secure your apps, period.