feat: Begins work on server documentation.

Sources/Docs/Templates/RenderArticles.swift

@@ -50,7 +50,7 @@ func renderTag<T>(context: PartitionedRenderingContext<T, ArticleMetadata>) -> N
     div(class: "border-b border-light grid lg:grid-cols-2 mb-12") {
       a(href: "/articles") {
         div(class: "flex flex-row gap-2") {
-          img(src: "/static/images/tag.svg", width: "40")
+          img(src: "/static/img/tag.svg", width: "40")
           h1(class: "text-4xl font-extrabold") { "\(context.key)" }
           h1(class: "[&:hover]:border-b border-green text-2xl font-extrabold text-orange px-4") { "«" }
         }

content/articles/2025-04-04-servers.md

@@ -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).

content/static/input.css

@@ -147,6 +147,21 @@ article code {
   @apply bg-amber-700;
 }
 
+table,
+th,
+td {
+  border: 1px solid;
+  border-collapse: collapse;
+}
+
+table {
+  @apply mb-8;
+}
+
+table td {
+  @apply px-6;
+}
+
 .container {
   @apply px-10;
 }
@@ -155,3 +170,11 @@ article code {
   padding-top: 10px;
   padding-bottom: 10px;
 }
+
+blockquote {
+  @apply border-2 border-blue-600 bg-blue-300 rounded-lg;
+}
+
+blockquote p {
+  @apply px-6 pt-6 text-blue-600 font-semibold;
+}