homelab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Begins work on server documentation.
All checks were successful
CI / release (push) Successful in 5m55s
Details

Browse Source
This commit is contained in:
Michael Housh
2025-04-04 15:33:07 -04:00
parent b44e1b45b0
commit 76a57b4560
5 changed files with 137 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

109
content/articles/2025-04-04-servers.md Normal file
View File

@@ -0,0 +1,109 @@
---
date: 2025-04-04
tags: servers, infrastructure, homelab
---
# Servers
Documentation about how the servers are setup.
## Hardware
Currently there are (3) mac-mini's that run `Fedora Linux`, one of which is
owned by the company, two are my personal machines. I try to segment the
services based on that. Meaning services that I run primarily for personal items
are running on servers that I own, while services that are supporting business
functionality run on the companies server.
All of the servers run the services in `Docker Containers`.
There is also a `Raspberry-Pi` that runs `Home Assitant`, which is another one
of my personal devices.
| Server | DNS Name | IP Address |
| --------------------- | ---------------------- | ------------ |
| mighty-mini (company) | mightymini.housh.dev | 192.168.50.6 |
| franken-mini (mine) | frankenmini.housh.dev | 192.168.50.5 |
| rogue-mini (mine) | roguemini.housh.dev | 192.168.50.4 |
| home-assistant (mine) | homeassitant.housh.dev | 192.168.30.5 |
You can read more about the network setup
[here](https://docs.housh.dev/articles/2025/network/).
## Containers
Services run inside of docker containers that are spread between several
servers, which run them. The containers are deployed using a container
orchestrator, currently using [komo](https://komo.housh.dev).
[Click here for komo's documentation](https://komo.do/docs/intro)
All of the services have a corresponding repository for their configuration that
is hosted on an [internal git server](https://git.housh.dev/homelab). The
configuration will consist of a docker compose file (generally named
`compose.yaml`). There is often an `example.env` file for the service, these are
examples for documentation and variable naming purposes. The environment
variables themselves are setup in the container orchestrator for the service.
### Container orchestrator
The container orchestrator is where the actual configuration for the service is
done. It configures which physical server that the service will run on, it is
responsible for pulling the proper container images, pulls the configuration /
`compoose.yaml` file from the repository, sets up environment variables, and
deploys the service onto the server. It also has some features for monitoring
CPU and Memory usage of the servers.
The primary reason for the orchestrator is automate the deployment of services
when there is a change. It also has a web interface that allows all of it to be
managed by a single "pane of glass", essentially.
All services are automated, except for the primary load balancer / reverse proxy
(explained later).
## Service Overview
This section gives an overview of how the services are setup / routed.
### Caddy (Reverse Proxy)
All of the containers are accessed through the primary load balancer / reverse
proxy (caddy). This is responsible for routing traffic to the appropriate
service and server based on the domain name. It also handles / automates `TLS`
certificates via Let's Encrypt.
[Click here for caddy's documentation.](https://caddyserver.com/docs/)
Each server has a reverse proxy, this allows services to also be accessed on the
server's domain name, but is an implementation detail that doesn't matter very
much. Most services are accessed via the primary reverse proxy at a
`*.housh.dev` address.
Below is an overview:
![network-overview](/static/img/Network_Server_Diagram.png)
> Note: The primary caddy instance is the only service that is currently not
> automated when changes are made to it. Because it is what routes traffic to
> basically everything, the communication loop is broken during an update which
> stalls the update. Currently the changes are pushed to the server properly,
> but I then have to ssh into the server and restart the caddy instance. This is
> something that is on my list of things to fix / figure out a different
> solution for.
### DNS / Access
Currently services are only available when connected to our network, remote
access may be implemented in the future. If access is required outside of our
network then using our VPN is required. The VPN setup is done automatically via
unifi (our network router).
`DNS` is what translates domain names to `IP` addresses, currently the public
DNS records are handled by cloudflare. Cloudflare is used to validate that we
own the `housh.dev` domain name in order for Let's Encrypt to issue free `TLS`
certificates. TLS is used to encrypt traffic over the web (`https://`).
Internal DNS records are setup in our unifi router `Settings -> Routing -> DNS`.
The internal DNS is fairly simple and just needs to map to servers appropriately
(primarily just to the primary caddy instance, which then handles all the
routing to the individual service that is requested).