134 lines
5.8 KiB
Markdown
134 lines
5.8 KiB
Markdown
+++
|
|
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 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 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.
|