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

blog update 20240906
Some checks failed
/ Connect to deployment host, update, and redeploy docs website. (push) Blocked by required conditions
Details
/ Build static site, docker image, upload artifact... (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Freyja Odinthrir
2024-09-06 03:37:13 -07:00
parent aa54a8f2cd
commit 87244e2545
1 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
content/2024/09/06/2024090601.md Normal file
View File

@@ -0,0 +1,30 @@
title: Some changes have ocurred
tags: servers, server layout, gitops, devops
date: 2024-09-06 03:27
# Some changes have ocurred
Server layout has undergone some changes, most notably:
- the OS on my pi
- how i do gitops
- how the deployment works
## 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
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.
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.
Now, I'm just running a single rootful docker instance. I'm mindful of network segregation, ensuring no unsafe directories are given to containers, and I'm also not allowing any privileged containers.
I'm also doing CI a different way. An SSH keypair is made for each CI repository on gitea. Then, the private key is stored as a secret in the repo's actions settings. Then, a script is written and pushed to the deployment server that is called by the SSH public key. This ensures that no rogue activity happens, essentially locking each SSH key to a specific deployment script.