Big update

.gitea/workflows/main-build.yaml

@@ -0,0 +1,14 @@
+name: Build & Deploy
+
+on:
+    push:
+        branches:
+            - main
+
+jobs:
+    build-or-sth:
+        runs-on: ubuntu-latest
+        steps:
+            - run: echo "hi!"
+            - name: Get hugo
+              run: apt install hugo

.gitignore

@@ -1,6 +1,7 @@
-/public/
+resources/_gen/
-/resources/_gen/
+assets/jsconfig.json
-/assets/jsconfig.json
+public/*
 hugo_stats.json
 
+
 .hugo_build.lock

config/_default/menus.yaml

@@ -5,3 +5,6 @@ main:
   - name: About
     url: /about/
     weight: 20
+  - name: Posts
+    url: /posts/
+    weight: 30

content/about.md

@@ -1,21 +1,26 @@
 +++
+type = 'misc'
 title = 'About'
 date = 2024-10-24T23:17:52+03:00
 draft = false
+bio = true
 +++
-# About me
 
 Hi, I'm Emin!
 
-I am a second year Computer Engineering student at Izmir University of Economics.
+I am a second year Computer Engineering student at Izmir University of
-I like all things programming and computers.
+Economics. I like all things programming and computers.
 
-I mostly do systems programming - I feel most at home when I use C++ or C, though
+I mostly do systems programming - I feel most at home when I use C++ or
-I've used Rust, Java and many other languages to varying degrees. I *did* have a phase
+C, though I've used Rust, Java and many other languages to varying
-when I was really into Common Lisp.
+degrees. I also had a phase when I was *really* into Common Lisp.
+Seriously, using a language with true macros is an entirely different
+experience.
 
-This website exists to be my blog/toy. It's hosted on a VPS, so that I can practice
+This website exists to be my blog/toy. It's hosted on a VPS, so that I
-my hosting/web skills. I use [Hugo](https://gohugo.io/) with the [Qubt](https://themes.gohugo.io/themes/qubt/) 
+can practice my hosting/web skills. I use [Hugo](https://gohugo.io/)
-theme to generate pages from my content. I think it looks pretty good, check them out.
+with the [Qubt](https://themes.gohugo.io/themes/qubt/) theme to
+generate pages from my content. I think it looks pretty good, check
+them out.
 
 Hopefully I'll post a bit more on here soon.

content/posts/podman-setup.md

@@ -1,132 +0,0 @@
-+++
-title = 'My Setup - p1'
-date = 2024-10-25T23:11:17+03:00
-draft = false
-+++
-
-# My Setup
-
-In this 'series' I will be walking you through my process of how I
-host everything on this server.
-
-I'm currently running, on top of [my blog](https://emin.software), a [gogs
-instance](https://git.emin.software).
-
-When first creating this website, I just had my blog. I generated this blog
-using [hugo](https://hugo.io): a static site generator. Hugo allowed me to
-focus on writing whatever I wanted in Markdown format, it would take care of
-converting my writing into HTML and CSS.
-
-I had a small issue with how I wrote my code and deployed it though: whenever I
-made a small change to the page, I had to manually rebuild it, then upload the
-updated version to my server and put it in the web directory.
-
-This is a cumbersome process. The whole point of using hugo is to *focus on the
-writing*, so having to rebuild and reupload for every typo is... not great. I
-wanted to be able to do a simple `git push`, and not worry about the rest.
-
-The previous "manual" approach also depends on me having already installed all
-necessary software. If you have a dedicated server that you're running yourself,
-that's probably okay, you just have to setup once, but I'm running this on a VPS
-that I'm not sure I'll keep forever. The ability to reproduce this exact setup
-within minutes actually matters.
-
-After reading a bit on this topic, I decided I would use podman for this. Docker
-would work just as nicely (any containerization software would work, really),
-but I decided on podman because it can run without a daemon and without root
-privilages. Also, it has pretty neat support for kubernetes pods (which are
-honestly a lot more useful than I would've given them credit for before I started
-this whole project).
-
-That's really why I'm writing this. So that you, the reader (or possibly my future self) can
-understand the methodology of podman, how to create pods, run containers and configure all
-of this automatically, and so that I may demonstrate and share what I've learnt during
-this process.
-
-## Motivation
-
-Basically, I'm already running a web server. Why shouldn't I also host several other services
-for friends and family while I'm at it? Why shouldn't I make the entire setup reproducable?
-
-Here are some of the services I wanted to self-host:
-    - Web server: obviously, who doesn't want a website?
-    - Some git server: having my own place to show off all the things I've done is certainly really cool.
-    - Wireguard: Free VPN along with the website? sign me up.
-    - CI/CD: automatic testing and releases of my software is cool, and also incredibly useful because that's
-how I plan to handle the website as well.
-
-Of course, there are always more things I could be self-hosting. So it makes sense to automate
-the setup, and that's where podman comes in.
-
-## Basics of podman
-
-Before we can get to the exciting stuff, we need to go over what podman is, and how to
-use it. Essentially, podman is a container engine: it lets you build and run applications in
-a containerized environment. Containers are useful because they provide security,
-easy setup and most importantly, reproducability.
-
-I'm not going to spend any more time explaining what containers are and why they're
-good, that's been done to death already. Right now, what matters is the actual setup,
-so let's get on with it.
-
-If you've used docker before, you'll feel right at home. Many commands are unchanged
-from docker, making podman a suitable drop-in replacement. Some things like network
-setups tend to be a little different, but that won't matter too much right now.
-
-In case you're unfamiliar with docker, here are some basic commands:
-
-```sh
-# Search for container images (on docker.io unless you configure otherwise)
-$ podman search <image name>
-
-# Download (pull) an image from remote repo
-$ podman pull <image name>
-
-# list the images you have pulled.
-$ podman images
-
-# run a container.
-$ podman run <image name>
-
-# run a container, but with a LOT of flags. I just listed the most useful ones.
-$ podman run
-    -i # interactive, so you can e.g. run a shell in the container
-    -t # allocates a tty. useful with -i so that shell completion etc. can work
-    -d # opposite of -i, detach and run in the background
-    --port <HOST PORT>:<CONTAINER PORT> # port forwarding, for when you need a server.
-    -v <HOST DIR>:<CONT DIR>:<FLAGS> # give the container access to some directory
-    <image name>
-    <command> # ... want a shell?
-
-# list running containers. add -a to list ALL containers, running or stopped.
-# podman ps <-a>
-
-# stop a running container.
-$ podman stop <id>
-
-# stopped containers don't automatically get removed. This command removes it.
-$ podman rm <id>
-```
-
-## Pods are nice.
-
-Pods are basically just a collection of containers - multiple programs working
-with each other.
-
-Usually, on a server, each application *isn't* totally separate from each other
-- for my own usecase, I want my git server (e.g. gogs) to automatically build
-and update my website whenever I push to its git repository. That means my git
-server and web server can't be *totally* separate, there's some amount of relation.
-Pods can help with this.
-
-Pods allow you to create a "pod" containing several containers, sharing resources
-with each other, etc. For example, I could run a pod with nginx and gogs running
-in seperate containers - then, the nginx server could act as a reverse proxy based
-on host name, showing the web page on emin.software, and the git server on
-git.emin.software. Nginx redirects to gogs which only binds to *the pod's
-localhost address*, so only nginx can reach it. Likewise, a database server can
-be added to the pod only for the git server to use, so that it can't be reached
-from the outside the pod - and it is logically grouped along with the rest of the pod.
-
-On top of this, pods can be built purely from a kubernetes-compatible configuration
-file, so setting them up is relatively easy.

content/posts/setup_p1.md

@@ -0,0 +1,193 @@
++++
+title = 'My Setup '
+subtitle = 'Containers! Docker!'
+summary = "I go over the things I've learned about docker, and how I've used it to host my website."
+date = 2024-10-25T23:11:17+03:00
+draft = false
++++
+
+# My Setup
+
+In this 'series' I will be walking you through my process of how I
+host everything on this server.
+
+I'm currently running, on top of [my blog](https://emin.software), a [gogs
+instance](https://git.emin.software).
+
+When first creating this website, I just had my blog. I generated this blog
+using [hugo](https://hugo.io): a static site generator. Hugo allowed me to
+focus on writing whatever I wanted in Markdown format, it would take care of
+converting my writing into HTML and CSS.
+
+I had a small issue with how I wrote my code and deployed it though: whenever I
+made a small change to the page, I had to manually rebuild it, then upload the
+updated version to my server and put it in the web directory.
+
+This is a cumbersome process. The whole point of using hugo is to *focus on the
+writing*, so having to zip and reupload for every typo is... not great. I
+wanted to be able to do a simple `git push`, and not worry about the rest.
+
+The "manual" approach also depends on me having already installed all
+necessary software. If you have a dedicated server that you're running yourself,
+that's probably okay, you just have to setup once, but I'm running this on a VPS
+that I'm not sure I'll keep forever. The ability to reproduce this exact setup
+within minutes actually matters.
+
+After reading a bit on this topic, I decided I would use docker for this. Podman
+would work just as nicely (any containerization software would work, really),
+but I decided on docker because it's been the standard for a while now
+
+## Motivation
+
+Basically, I'm already running a web server. Why shouldn't I also host several
+other services for friends and family while I'm at it? Why shouldn't I make the
+entire setup reproducible?
+
+Here are some of the services I wanted to self-host:
+
+- Web server: obviously, who doesn't want a website?
+- Some git server: having my own place to show off all the things I've done is
+certainly really cool. For this, something like [Gitea](https://about.gitea.com/)
+would normally be great. I went with [Gogs](https://gogs.io/) instead, because
+it is far more lightweight.
+- Wireguard: Free VPN along with the website? sign me up.
+- CI/CD: automatic testing and releases of my software is cool, and also
+incredibly useful.
+
+Of course, there are always more things I could be self-hosting. So it makes
+sense to automate the setup, and that's where docker comes in.
+
+## Basics of docker
+
+Before we can get to the exciting stuff, we need to go over what docker is, and how to
+use it. Essentially, docker is a container engine: it lets you build and run
+applications in a containerized environment. Containers are useful because they
+provide security, easy setup and most importantly, reproducibility.
+
+I'm not going to spend any more time explaining what containers are and why they're
+good, that's been done to death already. Right now, what matters is the actual setup,
+so let's get on with it.
+
+If you've used docker before, you'll feel right at home. Many commands are unchanged
+from docker, making docker a suitable drop-in replacement. Some things like network
+setups tend to be a little different, but that won't matter too much right now.
+
+In case you're unfamiliar with docker, here are some basic commands (run these
+either as root, or as a user in the `docker` group):
+
+```sh
+# Search for container images (on docker.io unless you configure otherwise)
+$ docker search <image name>
+
+# Download (pull) an image from remote repo
+$ docker pull <image name>
+
+# list the images you have pulled.
+$ docker images
+
+# run a container.
+$ docker run <image name>
+
+# run a container, but with a LOT of flags. I just listed the most useful ones.
+$ docker run
+    -i # interactive, so you can e.g. run a shell in the container
+    -t # allocates a tty. useful with -i so that shell completion etc. can work
+    -d # opposite of -i, detach and run in the background
+    --port <HOST PORT>:<CONTAINER PORT> # port forwarding, for when you need a server.
+    -v <HOST DIR>:<CONT DIR>:<FLAGS> # give the container access to some directory
+    <image name>
+    <command> # ... want a shell?
+
+# list running containers. add -a to list ALL containers, running or stopped.
+$ docker ps <-a>
+
+# stop a running container.
+$ docker stop <id>
+
+# stopped containers don't automatically get removed. This command removes it.
+$ docker rm <id>
+```
+
+## Compose is nice.
+
+Docker compose is a nice way to essentially "group together" some containers,
+and ship them in an easy way.
+
+Usually, on a server, each application *isn't* totally separate from each other
+- for my own use case, I want my git server (e.g. gogs) to automatically build
+and update my website whenever I push to its git repository. That means my git
+server and web server can't be *totally* separate, there's some amount of
+relation.
+
+At the same time... I don't really want to set up both containers, then their
+volumes, and their ports etc. by hand. Sure I could stick it in a shell script,
+but that's hardly elegant.
+
+Docker compose helps with this: you can create a
+`compose.yaml` file, and define containers, ports, volumes, secrets all inside
+this file. Then, when you run `docker compose up` this configuration is read,
+and all of it is processed as you would want it to.
+
+e.g you might have this for starting a web server on port 3000:
+
+```yaml
+services:
+    web:
+        image: "nginx"
+        ports:
+            - 3000:80
+```
+
+Or you could even have *two* servers, like, a Gogs and a web server!
+
+```yaml
+services:
+    web:
+        image: "nginx"
+        ports:
+            - 80:80
+    gogs-haha:
+        image: "gogs/gogs"
+        ports:
+            - 3000:3000
+            - 3022:22
+```
+
+See how we got multiple services to run, very very easily? Isn't that just
+really nice? You can just keep adding stuff. And compose even sets up dns for
+these containers! That means, for example, you can have your web server act as
+a reverse proxy by having it access http://gogs-haha:3000 in the above config!
+It just works!
+
+Of course, you can add volumes to tie it all, and 'secrets' to manage sensitive
+files (like keys and certificates). I won't go into those here though.
+
+## Automation
+
+Yeah, okay. I like automating, I know I talked big game up in the introduction.
+It's obvious. I just love it when things do themselves instead of me having to
+do them. I remember wanting to make a robot to do my homework when I was a kid.
+I still want to do that. Of course, the fact that it would be easier to just do
+my homework is irrelevant. It was always irrelevant. It's not about doing less
+work, it's about the ***principle***.
+
+Anyway, so the point is that I want to automate the process of deploying from a
+git repository directly to my blog. Thankfully, gitea provides a nice feature
+for Continuous Integration (CI), gitea actions. It's similar to GitHub actions.
+
+Essentially, you install gitea normally, then register an act_runner to it with
+a registration token you get from the instance. I use docker compose and the
+gitea/act_runner image to automate this step as well.
+
+Once a runner is registered, you can write a workflow file, which tells the
+runner what it should do once you push some changes. In my case, for example,
+this would be building the website using hugo, then putting the files into the
+web directory.
+
+# Conclusion
+
+Docker and Docker Compose are a lot more useful than my younger self would have
+given them credit for. It was really fun learning about them, and hopefully I'll
+use this knowledge in the future.
+
+Thank you for reading.

content/posts/setup_p2.md

@@ -1,5 +0,0 @@
-+++
-title = 'Setup_p2'
-date = 2024-10-28T23:41:06+03:00
-draft = true
-+++

hugo.toml

@@ -1,4 +1,4 @@
-baseURL = 'http://emin.software/'
+baseURL = 'https://emin.software/'
 languageCode = 'en-us'
 title = 'haxala1r'
 theme = 'qubt'