freyjagp/blog.raer.me
1
0
Fork 0
Code Actions Packages Releases Activity

Add table of contents to old blogs

Browse Source
This commit is contained in:
Freyja Odinthrir
2024-09-27 13:56:48 -07:00
parent a93700b334
commit b357ab14b4
6 changed files with 70 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
content/2024/01/17/post-01.md
View File

@@ -2,7 +2,17 @@ Title: First blog post built with blag
Description: Because every new blog needs a new post. Description: Because every new blog needs a new post.
Date: 2024-01-17 10:28 Date: 2024-01-17 10:28
Tags: personal, gitops, devops, technical Tags: personal, gitops, devops, technical
Edited: 2024-01-18 00:18 Edited: 2024-09-27 13:50
# Table of Contents <!-- omit in toc -->
- [A new post for a new blog](#a-new-post-for-a-new-blog)
- [Fixing that old mess](#fixing-that-old-mess)
- [Static Site Generation](#static-site-generation)
- [Using blag](#using-blag)
- [Automation](#automation)
- [Conclusion](#conclusion)
# A new post for a new blog # A new post for a new blog
@@ -14,13 +24,13 @@ Previously, <https://blog.raer.me/> was an html-only website. The pages were cre
That's terribly inconvenient. To boot, the thing wasn't version managed and it was deployed entirely manually directly to a folder on my reverse proxy server ([see more...](../../../2023/06/28/automating-some-things.md)) Yikes! None of this was ideal at all! That's terribly inconvenient. To boot, the thing wasn't version managed and it was deployed entirely manually directly to a folder on my reverse proxy server ([see more...](../../../2023/06/28/automating-some-things.md)) Yikes! None of this was ideal at all!
## Fixing that old mess # Fixing that old mess
So building the blog with html manually was a pain in the ass. But doing something like an MVC framework or a CMS for a simple blog seemed like too much hassle as well. I don't want a WYSIWYG, or something that's browser-based. I hate dealing with browser frontends. Afterall, a blog is mostly - if not *entirely* - text-based. Why should I have to deal with the overhead of a server-side scripted website? I just want to write my blog in markdown - like i do with all my documentation already. Then I could even keep it in a git repo, backed up to my private gitea instance. So building the blog with html manually was a pain in the ass. But doing something like an MVC framework or a CMS for a simple blog seemed like too much hassle as well. I don't want a WYSIWYG, or something that's browser-based. I hate dealing with browser frontends. Afterall, a blog is mostly - if not *entirely* - text-based. Why should I have to deal with the overhead of a server-side scripted website? I just want to write my blog in markdown - like i do with all my documentation already. Then I could even keep it in a git repo, backed up to my private gitea instance.
The answer to all of that, is `static site generation`. Turns out, there are plenty of other people out there who have looked at available tools, thought something similar to me, then built their own new tool that can take markdown, then generate a whole-ass website with it. Simple, and clean. You write content, maybe tweak some CSS/HTML templates, then the generator handles all the dirty work. No more searching for dozens of instances of a link when I change something in the navbar. That navbar is now a single template file that's reused by the generator. The answer to all of that, is `static site generation`. Turns out, there are plenty of other people out there who have looked at available tools, thought something similar to me, then built their own new tool that can take markdown, then generate a whole-ass website with it. Simple, and clean. You write content, maybe tweak some CSS/HTML templates, then the generator handles all the dirty work. No more searching for dozens of instances of a link when I change something in the navbar. That navbar is now a single template file that's reused by the generator.
## Static Site Generation # Static Site Generation
This all sounds very complicated, yes? Well, sure. But really, its not. This all sounds very complicated, yes? Well, sure. But really, its not.
@@ -187,6 +197,8 @@ jobs:
``` ```
# Conclusion
Bear in mind, this all required a bit of setup and learning to self-host. But, when the hosts & runners are all set up and running properly, with the above workflow, updating this blog is a simple matter of committing to a git repo then pushing it to my remote. The runners handle everything else. Bear in mind, this all required a bit of setup and learning to self-host. But, when the hosts & runners are all set up and running properly, with the above workflow, updating this blog is a simple matter of committing to a git repo then pushing it to my remote. The runners handle everything else.
Ain't gitops grand? Ain't gitops grand?

15
content/2024/01/18/baja-tacos.md
View File

@@ -3,6 +3,21 @@ description: Some seafood tacos.
tags: cooking, recipes tags: cooking, recipes
date: 2024-01-19 05:59 date: 2024-01-19 05:59
# Table of Contents <!-- omit in toc -->
- [Baja Tacos](#baja-tacos)
- [Ingredients](#ingredients)
- [Fresh](#fresh)
- [Spices](#spices)
- [Protein](#protein)
- [Directions](#directions)
- [Prep](#prep)
- [Slaw](#slaw)
- [Sauce](#sauce)
- [Rub](#rub)
- [Assemble](#assemble)
# Baja Tacos # Baja Tacos
## Ingredients ## Ingredients

10
content/2024/01/18/cheesecake-recipe.md
View File

@@ -2,6 +2,16 @@ title: Cheesecake
description: My birthday is soon, here's a cheesecake recipe. description: My birthday is soon, here's a cheesecake recipe.
tags: baking, cooking, cheesecake, recipes tags: baking, cooking, cheesecake, recipes
date: 2024-01-18 12:05 date: 2024-01-18 12:05
edited: 2024-09-27 13:52
# Table of Contents <!-- omit in toc -->
- [New York style cheesecake](#new-york-style-cheesecake)
- [Ingredients](#ingredients)
- [For the Crust](#for-the-crust)
- [For the Filling](#for-the-filling)
- [Directions](#directions)
- [How to Slice Cheesecake](#how-to-slice-cheesecake)
# New York style cheesecake # New York style cheesecake

11
content/2024/01/18/increasing-complexity.md
View File

@@ -2,6 +2,13 @@ title: Increasing complexity
description: A small issue snowballs because I want independence description: A small issue snowballs because I want independence
tags: technical, gitops, devops tags: technical, gitops, devops
date: 2024-01-18 01:09 date: 2024-01-18 01:09
edited: 2024-09-27 13:52
# Table of Contents <!-- omit in toc -->
- [Increasing Complexity](#increasing-complexity)
- [Actually doing the thing](#actually-doing-the-thing)
- [Getting my fork on my package repo](#getting-my-fork-on-my-package-repo)
# Increasing Complexity # Increasing Complexity
@@ -88,11 +95,11 @@ This isn't my first rodeo with setting these things up, though. I've got a simil
Okay. Enough talk, already! Lets do this! Okay. Enough talk, already! Lets do this!
## Actually doing the thing # Actually doing the thing
So all that stuff I was talking about before was more-or-less me brainstorming what I needed to do. Here's some reporting back from me doing the stuff. So all that stuff I was talking about before was more-or-less me brainstorming what I needed to do. Here's some reporting back from me doing the stuff.
### Getting my fork on my package repo ## Getting my fork on my package repo
Turns out, the makefile is fine. Super easy. Just gotta hit it with a `make` command and its primo. So what I did, was I made the mirrors org and moved my blag mirror over there. Then I forked it to my personal gitea account. Then I cloned the fork, and made a `v2.3.0` branch because it was on `v2.2.x`. I updated the version in the source. Then I added the dependency for the new package `pymdown-extensions` in the appropriate files. Then I modified the `markdown.py` file to include the `footnotes` and `pymdownx.tilde` (strikethrough) extensions. Then I ran the makefile, which did its magic and made the stuff. Then I simply run twine to upload to my personal gitea package repo. Done. Version 2.3.0 is on my repo. Turns out, the makefile is fine. Super easy. Just gotta hit it with a `make` command and its primo. So what I did, was I made the mirrors org and moved my blag mirror over there. Then I forked it to my personal gitea account. Then I cloned the fork, and made a `v2.3.0` branch because it was on `v2.2.x`. I updated the version in the source. Then I added the dependency for the new package `pymdown-extensions` in the appropriate files. Then I modified the `markdown.py` file to include the `footnotes` and `pymdownx.tilde` (strikethrough) extensions. Then I ran the makefile, which did its magic and made the stuff. Then I simply run twine to upload to my personal gitea package repo. Done. Version 2.3.0 is on my repo.

14
content/2024/09/06/2024090601.md
View File

@@ -1,6 +1,14 @@
title: Some changes have ocurred title: Some changes have ocurred
tags: servers, server layout, gitops, devops tags: servers, server layout, gitops, devops
date: 2024-09-06 03:27 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 # Some changes have ocurred
@@ -11,17 +19,17 @@ Server layout has undergone some changes, most notably:
- how the deployment works - 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. 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. 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. 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. 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.

12
content/2024/09/26/configuration-management.md
View File

@@ -2,6 +2,14 @@ title: Managing configs on my homeservers.
description: Managing configuration files - some lessons I've learned over the years. description: Managing configuration files - some lessons I've learned over the years.
tags: post, git, gitops, devops, cicd, tech, scripting tags: post, git, gitops, devops, cicd, tech, scripting
date: 2024-09-26 05:21 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 # 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.__ > __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`! 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. 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. This is more or less some rambling about how I manage configs in git. I hope any amount of this made sense.