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

feat: Updates readme to be more descriptive.

Browse Source
This commit is contained in:
Michael Housh
2025-03-20 11:09:43 -04:00
parent 784aee9397
commit b8178b14af
1 changed files with 11 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
README.md
View File

@@ -9,7 +9,7 @@ added to run services in the future, however the primary point is that there is
that acts as the entry point to all the services that are running. This server also may run services
as well, but is beyond the scope of the overview.
![network](img/housh.dev.network.svg)
![network](img/housh.dev.network.svg){height:400 width=100%}
The `primary` server runs an instance of [caddy](https://caddyserver.com/docs/) that is used as a
reverse proxy to the internal services. It manages SSL certificates and routes traffic to the
@@ -22,12 +22,17 @@ to our network directly or through a VPN.
## DNS
DNS is what translates human readable URL's, such as `po.housh.dev`, and translates it to an IP
address (i.e. 192.168.50.5). The DNS is handled by our unifi router which just points any domain
that ends in `housh.dev` to the `primary` server which can then route the traffic appropriately.
address (i.e. 192.168.50.5). The internal DNS is handled by our unifi router which just points any
domain that ends in `housh.dev` to the `primary` server which can then route the traffic
appropriately.
The unifi router does also have DNS records for each backend servier that works in a similar
fashion, this is primarily an implementation detail that doesn't really matter, however it allows
routes declared on the `primary` caddy server to route traffic based on the server domain name (i.e.
External DNS is handled by [cloudflare](htts://cloudflare.com) and is used to prove that we own the
`housh.dev` domain in order to get free SSL certificates through
[Let's Encrypt](https://letsencrypt.org).
The unifi router does also have DNS records for each backend server that works in a similar fashion,
this is primarily an implementation detail that doesn't really matter, however it allows routes
declared on the `primary` caddy server to route traffic based on the server domain name (i.e.
frankenmini.housh.dev) vs. needing the internal IP address of the server.
This setup allows a fairly easy transition if the `primary` server that runs caddy is changed in the