Add table of contents to old blogs

content/2024/09/06/2024090601.md

@@ -1,6 +1,14 @@
 title: Some changes have ocurred
 tags: servers, server layout, gitops, devops
 date: 2024-09-06 03:27
+edited: 2024-09-27 13:53
+
+# Table of Contents <!-- omit in toc -->
+
+- [Some changes have ocurred](#some-changes-have-ocurred)
+- [Pi os](#pi-os)
+- [How I do gitops](#how-i-do-gitops)
+- [How the deployment server works.](#how-the-deployment-server-works)
 
 # Some changes have ocurred
 
@@ -11,17 +19,17 @@ Server layout has undergone some changes, most notably:
 - how the deployment works
 
 
-## Pi os
+# Pi os
 
 I needed docker on my pi, so i abandoned freebsd. It was a good run and taught me a lot about unix. But implementing a custom freebsd server is just. not my thing anymore. Docker is so much easier for versioning. And if i want to compile from scratch? I have that option, too, with docker.
 
 The pi now runs openSUSE Leap 15.6.
 
-## How I do gitops
+# How I do gitops
 
 I've more or less solidified how I do gitops. When I need to version control files on a remote server, I make a local git repo with those files that also contains a script which is used to deploy any of said files on the remote server. This is achieved over SSH. A bare git repo is initialized on the remote server, and added as a remote in the gitops repo. Then, that remote is pushed to in a way that it is always synced perfectly with the local copy. Then, a script in the git repo can SSH into the remote, clone the repo from the local copy, and do stuff with the files.
 
-## How the deployment server works.
+# How the deployment server works.
 
 Before, i used rootless docker and usernames to sort of namespace things in an ineffective way. I was also using gitea actions configs to do things on the deployment server with an ssh key that had unlimited access to the user account. This provided a false sense of security.
 

content/2024/09/26/configuration-management.md

@@ -2,6 +2,14 @@ title: Managing configs on my homeservers.
 description: Managing configuration files - some lessons I've learned over the years.
 tags: post, git, gitops, devops, cicd, tech, scripting
 date: 2024-09-26 05:21
+edited: 2024-09-27 13:53
+
+# Table of Contents <!-- omit in toc -->
+
+- [Managing homeserver configs](#managing-homeserver-configs)
+- [So how do I do things?](#so-how-do-i-do-things)
+- [conclusion](#conclusion)
+
 
 # Managing homeserver configs
 
@@ -11,7 +19,7 @@ Similarly, I seek to reduce complexity of my configuration management. I like to
 
 > __Speaking of k3s/k8s - Fuck that noise entirely in a home environment. Unless you're doing it to learn, I recommend staying away from kubernetes. Its just docker with extra steps and its far more trouble than its worth for the home - in my very strong opinion.__
 
-## So how do I do things?
+# So how do I do things?
 
 Well, as I alluded to earlier - I work in my text editor, out of git repositories. All of my services are deployed with docker - its just... easier, this way. I've run services so many different ways over the years and docker is simply the easiest to deal with. I can grab premade containers. Or I can make my own, push them to my gitea deployment, and pull them for use later. Its great. And its distro agnostic. Sure there are some security issues associated with it. But there are also well documented methods to nullify them. I can also use docker volumes to store everything in `/opt/{container_name}` which is super handy when it comes time to archive/back up the host since all I need to do to grab any important data is backup `/opt`!
 
@@ -24,7 +32,7 @@ These manually managed repos are pushed directly to a bare repo on the deploymen
 In the case of the main config repo, there also resides an ssh authorized_keys file, some scripts in a folder called `ci`, docker configs, and a big folder of scripts to deploy the thing, manually run actions on the docker configs, and more. The authorized_keys file and `ci` folder allow me to use gitea actions to deploy docker images on the host. I generate an ssh keypair, I store the private key as a secret in each individual repo that deploys to the host, then i put the public key in the authorized_keys file with a command that points to a script in `ci` that pulls and redeploys docker images.
 
 
-## conclusion
+# conclusion
 
 This is more or less some rambling about how I manage configs in git. I hope any amount of this made sense.