8 changed files with 150 additions and 229 deletions
--- a/.gitea/workflows/main-build.yaml
+++ b/.gitea/workflows/main-build.yaml
@ -1,14 +0,0 @@
 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
--- a/.gitignore
+++ b/.gitignore
@ -1,7 +1,6 @@
-resources/_gen/
+/public/
-assets/jsconfig.json
+/resources/_gen/
-public/*
+/assets/jsconfig.json
 hugo_stats.json
 .hugo_build.lock
--- a/config/_default/menus.yaml
+++ b/config/_default/menus.yaml
@ -5,6 +5,3 @@ main:
  - name: About
    url: /about/
    weight: 20
  - name: Posts
    url: /posts/
    weight: 30
--- a/content/about.md
+++ b/content/about.md
@ -1,26 +1,21 @@
 +++
 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
+I am a second year Computer Engineering student at Izmir University of Economics.
-Economics. I like all things programming and computers.
+I like all things programming and computers.
-I mostly do systems programming - I feel most at home when I use C++ or
+I mostly do systems programming - I feel most at home when I use C++ or C, though
-C, though I've used Rust, Java and many other languages to varying
+I've used Rust, Java and many other languages to varying degrees. I *did* have a phase
-degrees. I also had a phase when I was *really* into Common Lisp.
+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
+This website exists to be my blog/toy. It's hosted on a VPS, so that I can practice
-can practice my hosting/web skills. I use [Hugo](https://gohugo.io/)
+my hosting/web skills. I use [Hugo](https://gohugo.io/) with the [Qubt](https://themes.gohugo.io/themes/qubt/) 
-with the [Qubt](https://themes.gohugo.io/themes/qubt/) theme to
+theme to generate pages from my content. I think it looks pretty good, check them out.
 generate pages from my content. I think it looks pretty good, check
 them out.
 Hopefully I'll post a bit more on here soon.
--- a/content/posts/podman-setup.md
+++ b/content/posts/podman-setup.md
@ -0,0 +1,132 @@
 +++
 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.
--- a/content/posts/setup_p1.md
+++ b/content/posts/setup_p1.md
@ -1,193 +0,0 @@
 +++
 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.
--- a/content/posts/setup_p2.md
+++ b/content/posts/setup_p2.md
@ -0,0 +1,5 @@
 +++
 title = 'Setup_p2'
 date = 2024-10-28T23:41:06+03:00
 draft = true
 +++
--- a/hugo.toml
+++ b/hugo.toml
@ -1,4 +1,4 @@
-baseURL = 'https://emin.software/'
+baseURL = 'http://emin.software/'
 languageCode = 'en-us'
 title = 'haxala1r'
 theme = 'qubt'