First release of my homelab setup
reddit / selfhosted

----------------------------------------------------------------------
toutons · 2023-10-27 03:53

Hey! So, I’ve been self-hosting things for a long, long time. If any
of you remember ss-plex, well, 👋, that was me.
I’d probably place this at “intermediate” level. You should already
have a grasp on things like docker, reverse proxies, and environment
variables.
It’s definitely not a “start and it all works immediately”, or a
“guided installation” type thing. But, I do think it strikes a good
balance between being able to add new services very fast and keep them
running for a long time, without having to pull your hair out.
This past Christmas I decided to build a small set-top-boxes for
friends, and in doing that I got the idea for \`homelab-shell-env\`,
which consolidates a lot variables that would normally be repeated
across all services. It also gave me the idea for \`USER\_GUIDE.md\`,
and the documentation “service” that gathers all those up and turns
them into a nicely formatted HTML file for them to read.
And this past week I finally decided to give Tailscale + Tailscale DNS
a whirl since someone at work has been trying to get a similar setup
working. Turns out it integrates very well with this homelab setup.
Now that it’s possible to set this all up without exposing any of it
to the actual internet, and still get valid HTTPS certs, I figured it
was finally time to open source it.
Hope it can help others!

----------------------------------------------------------------------
s_91 · 2023-10-27 14:02

This something I wanted to do for myself to re-build my unorganized
homelab. I'm so glad to find an excellent starting point.

I skimmed through the repo and found no mention of backup solution? My
current setup lacks (Docker volume / Mounted volume) backups. How
would you incorporate a backup solution here?

----------------------------------------------------------------------
toutons · 2023-10-27 14:56

To be honest I just kinda fly by the seat of my pants WRT that. My
storage is all just games, ROMs, and media, nothing that I couldn't
recover if lost.

Nextcloud was a recent addition, and with that I've been considering
something. I've got some redundancy with my storage, and I use zfs so
snapshots are an option. But not much more than that at the moment.

To incorporate backups in this, you could get somewhere with just
backing up `/opt/homelab`. It would be better if the versions of any
databases in use were pinned, and it would be even better than that to
use proper database dump tools.

----------------------------------------------------------------------
Nagashitw · 2023-10-27 19:01

It's similar to my own setup. I just do it in kubernetes instead of
docker. One thing you can consider is a CI that runs renovate on a
schedule to PR you when it finds new container image versions.

Here's my setup so you can take some inspiration if you want.

https://github.com/rafaribe/home-
ops/blob/main/.github/workflows/schedule-renovate.yaml

----------------------------------------------------------------------
toutons · 2023-10-27 21:27

Nice, the GitHub link I posted is slightly cleaned up and orphaned
from my actual homelab repo. Not sure if I can use this, because to
update these services I need to run `systemctl restart`, or hope that
watchtower eventually supports docker-compose.

So is does your homelab respond to changes in that repo?

----------------------------------------------------------------------
rocket1420 · 2023-10-27 21:46

Watchtower works fine with docker compose. I'm not sure what you're
trying to say.

----------------------------------------------------------------------
toutons · 2023-10-27 21:57

As far as I could tell, you can use docker-compose to manage your
running of watchtower, but it has issues working with containers that
were started via docker-compose:
https://github.com/containrrr/watchtower/issues/1019

----------------------------------------------------------------------
rocket1420 · 2023-10-27 22:17

Still not following. Are you setting up containers with portainer or
something? My whole docker setup is in one docker-compose.yml. I use
docker compose, not docker-compose. Maybe that's the issue?

----------------------------------------------------------------------
rocket1420 · 2023-10-27 22:25

I think I'm going to have to spin up a VM to understand why you're
doing things the way they are, instead of using a .env file with the
docker-compose.yml, or docker secrets. The built-in way to run
containers is very straightforward, and it seems at first glance that
you're making it a bit more complicated than it needs to be. There's
no need to mess with systemctl at all, for example.

----------------------------------------------------------------------
toutons · 2023-10-28 00:27

Using systemd is just a preference, and splitting up the services vs
one file is just how I like to keep things separated. Seems too
brittle doing it the other way. People can ignore the systemd stuff
and just add `restart: ...` to whatever services to switch.

The `docker-compose-up` script runs little more than `pull`, `build
--pull`, and `up`.

I suppose you could turn the homelab-shell-env into a regular .env
file and link it into each service, but then I'd still want a script
to do the pulling and building for me anyway, and that script can just
infer a lot of the configuration I'd be setting anyways, and help out
with creating some files a service might need.

----------------------------------------------------------------------
toutons · 2023-10-28 00:30

Using systemd is just a preference, and splitting up the services vs
one file is just how I like to keep things separated. Seems too
brittle doing it the other way. People can ignore the systemd stuff
and just add `restart: ...` to whatever services to switch.

The docker-compose-up script runs little more than `pull`, `build
--pull`, and `up`.

I suppose you could turn the homelab-shell-env into a regular .env
file and link it into each service, but then I'd still want a script
to do the pulling and building for me anyway, and that script can just
infer a lot of the configuration I'd be setting anyways, and help out
with creating some files a service might need.

----------------------------------------------------------------------
rocket1420 · 2023-10-28 04:00

I mean, docker compose up -d 'servicename' already does this. The way
you explain it, you seem to just be reinventing the wheel here. Did
you rewrite every docker compose command? If not, users will still
need to learn that as well.

There's nothing 'brittle' about using one docker-compose.yml file.

It seems to me, and correct me if I'm wrong, but you never really
learned the preferred way by the docker compose maintainers to use it.
Or it's been several years. I have one docker-compose.yml file. One
.env file. I can start, stop, force recreate, whatever, any single
container from the commandline. Watchtower seamlessly updates every
container and sends notifications to my private Discord server.

Not trying to shit on what you've done, just really confused.

----------------------------------------------------------------------
toutons · 2023-10-28 13:46

I'm really confused about how you're confused. Have you shared your
setup with people?

Like, what do you do about the "paper cuts" where people need to make
sure some files exists in the persistent storage with certain
environment variables. See the DNS service in my repo. Docker Compose
got .env file support years after I started using it, and even if I
did use .env files, I couldn't plop the contents of those variables in
another file when starting the service easily

And when you add another service, do you take everything down when
starting it, or do people have to run a different command to bring up
just the new entry added to the docker-compose.yml file? Because I
find it easier to just always use the one docker-compose-up command

And if that service depends on multiple other containers, do you have
to remember those and restart all of them when you've changed
something? Because the way I do it, you'd just ctrl-c and run docker-
compose-up again and bring everything up. Then, when everything is
good, you would start the service. You don't have to care about the
names of individual containers in my setup, just the name you've given
the folders

----------------------------------------------------------------------
rocket1420 · 2023-10-28 17:14

I mean, I can answer your questions, but you seem like you want to be
hostile.

You use one .env file. You put variables in it. You use variable names
in your single docker-compose.yml file.

Why would you take everything down when starting a new service? You
just type 'docker compose up -d 'servicename.' Simple.

If a service depends on another service, you put depends_on: in the
file and docker takes care of it.

And I mean, yeah, if you want to swing dicks, the setup I use has been
used by thousands https://github.com/htpcBeginner/docker-traefik

----------------------------------------------------------------------
toutons · 2023-10-28 19:11

You're really misinterpreting my tone here. Literally said not trying
to posture, aka not "measuring dicks" or whatever you want to call it,
I wanted to see how you do things to compare

I do use one env file, it's just not the same type as you, and it can
infer a lot of the variables you would want to set, so if you do
something like switch to a bridge interface, or change your machines
ip, you don't have to also change the env file

I don't need to know docker-compose service names, it's always docker-
compose-up. Bonus, if a service uses its own Dockerfiles, I can be
sure that when it's up, it's truly running what I want, instead of
going "shit forgot compose build --pull ..."

I don't need any `depends_on`, because all my services are self
contained (unless a service truly depends on another being healthy
before it starts, which only happened when gitea + elastic search,
which I ended up ditching due to eating too much ram)

-d and systemd are related, as they're both used for running services
in the background. Bonus, systemd can easily disable a something
rather than making sure I've commented out / removed multiple things
from a compose file / always make sure I'm using --profile

And yeah, a 1300 line long .yml file is not how I like to manage
things. I like to keep their persistent data with them, not in one
folder with multiple unrelated other services data. That also makes
wiping everything out for a service really easy

----------------------------------------------------------------------
rocket1420 · 2023-10-29 01:50

But you're saying this is your "first release." I have no idea how
long docker compose has supported the things, but it always has for
me, so.... at least a year? (profiles, networks, env files, restarting
services, etc)

How does something "infer" that you want a bridge network or change
your IP without telling it?

If it's always docker-compose-up then how do you start, stop, restart,
or force-recreate a single container? In any case, if you don't
provide it a container name, it simply assumes all. So you don't need
to know it with 'docker compose up -d' either.

You literally asked me "what if a service depends on another service?"
I answered your question and then you tell me you'll never need that.
What do you want from me?

I mean, I guess if you want to look at it like that. If you don't use
-d, it doesn't disconnect from the console. Systemd is a lot more than
that. How does systemd disable a something if you don't know the name
of it?

Every single container has its persistent data in its own directory
(and I put easily replaceable metadata from Plex, radarr, etc in a
separate subdirectory to making backing up even easier). I don't even
know what you mean. There's literally a separate directory specified
for each container in docker-compose.yml.

And there's nothing stopping you from using a different yaml file for
each container, either.

----------------------------------------------------------------------
toutons · 2023-10-29 06:21

Oh yeah, sorry you're really not understanding what I'm saying, and
that could be my fault.

This is my "first release", but the history goes back almost a decade.
The second paragraph in the readme says that

By "infer" I mean responds to changes. Outside of your docker setup,
you might change your default nic, or might add qemu and need bride
networking, which changes your default nic, or if the IP of your
machine happens to change. And you don't have to repeat your timezone
in your docker-compose .env file, for instance, because that can just
be read from the system. This stuff increases fault tolerance and
makes it super easy to move around and drop on new systems without you
changing much (heck I could just make that something that happens at
boot, but then it's a little less responsive to changes)

I'll try to be better about the name service, because I've been
overloading it. I'll try to be more clear and say "docker compose
project" (which is the name you give a folder, which I've internalized
as "homelab service name"), and "docker compose service" (the
containers, things I never have to think about)

Because the docker-compose-up script pulls, builds, stops, and then
starts the docker compose project. I don't do anything with single
containers because I don't have to think about single containers. It's
always just the docker compose project as a whole.

During the "evaluation period", or when a container or set of
containers is acting up, the command you run is always docker-compose-
up followed by ctrl-c, repeated as much as you need. And you can be
sure all the services are running as fresh as can be, while avoiding
issues docker compose has had over the years with making sure
everything has been restarted / rebuilt

Then when I do need to hose things, it's

```
docker-compose rm
# and if I want to blow away any state
sudo rm -rf ./persistent
```

> What do you want from me?

In that instance, honestly all the commands you do when you have to
restart a service, and all the services it depends on

You'll know the name of what service to disable because it's the name
you give the docker-compose project (aka the folder name, aka what I
call the "homelab service name"). When I said I don't care about the
service name, I meant the individual container names. The name you
give a folder is the name you care about. (And yes, of course, you
need to worry about individual container names to exec when debugging,
there's no way around that, but I rarely have to do that)

In the repository you linked, the reverse proxy logs are right next to
the home theater data, the db used for the remote gateway, and the VPN
proxy. That's just way too noisy for me. Think of the removing of the
persistent folder I just talked about earlier, I don't have to worry
about affecting another container because nothing unrelated is there.
I have the same feeling towards a single giant docker compose yml
file, way too much noise when all I'm looking for is a few entries

Yes, you can split it up. And if you do, you're not far off what I
have. Just with mine, for example when I set up a set top box for
friends, I remove everything but the reverse proxy + documentation +
soulseek + tailscale + DVR + home-theatre folders. There's no jumping
around a giant yml file making sure I've gotten everything, and same
for the folder where container state is kept. The user guide updates
to only show whats available, and I have scripts linked on their
desktop if they ever need to give debug information (thanks to
tailscale I've never had to do this)

If you wanna know why I call them "homelab services" instead of
anything docker related, it's because I have had homelab services that
have nothing to do with docker