122 lines
5.5 KiB
Markdown
122 lines
5.5 KiB
Markdown
+++
|
|
title = 'Podman Setup - p1'
|
|
date = 2024-10-25T23:11:17+03:00
|
|
draft = false
|
|
+++
|
|
|
|
# Podman
|
|
|
|
In this 'article' I will be walking you through my process of how I
|
|
host everything on this server.
|
|
|
|
When first creating this website, I had a small issue with how I wrote
|
|
my code and deployed it: whenever I made a small change to the page, I had
|
|
to manually rebuild it, then upload the updated version to server and put it
|
|
in the web directory.
|
|
|
|
This is a cumbersome process. For comparison, in my new setup, all I have to
|
|
do is to run `git commit` and `git push` after any change and my website will be
|
|
automatically built and deployed.
|
|
|
|
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 containerisation 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.
|