123 lines
5.4 KiB
Markdown
123 lines
5.4 KiB
Markdown
---
|
|
date: 2025-04-04
|
|
updated: 2025-04-08
|
|
tags: servers, infrastructure, homelab
|
|
primaryTag: infrastructure
|
|
---
|
|
|
|
# Servers Overview
|
|
|
|
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`, which allows for
|
|
them to be isolated from the host system (server) and makes them more easily
|
|
portable between servers if needed.
|
|
|
|
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 | mightymini.housh.dev | 192.168.50.6 |
|
|
| franken-mini | frankenmini.housh.dev | 192.168.50.5 |
|
|
| rogue-mini | roguemini.housh.dev | 192.168.50.4 |
|
|
| home-assistant | homeassitant.housh.dev | 192.168.30.5 |
|
|
| NAS | nas.housh.dev | 192.168.10.105 |
|
|
| Backup NAS | nas.hhe | 192.168.1.10 |
|
|
|
|
You can read more about the network setup
|
|
[here](https://docs.housh.dev/articles/2025/network/).
|
|
|
|
> Note: The backup NAS is used to backup our primary NAS, for now it is not easy
|
|
> to use, and will be used for camera / security footage in the future.
|
|
|
|
## 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 to
|
|
prevent sensitive data being "leaked".
|
|
|
|
### 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:
|
|
|
|
|
|
|
|
> 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). All devices that connect
|
|
to the network will be able to use the internal DNS to resolve host names
|
|
properly (meaning it all should just work automatically without any knowledge
|
|
from the user).
|