+ 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, a gogs
+instance.
+When first creating this website, I just had my blog. I generated this blog
+using hugo: 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:
+# 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.
+
+
+ 
+
+