- -
-- -
-
- Jan 1, 1 - 0 minute read
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
I go over the things I’ve learned about docker, and how I’ve used it to host my website.
diff --git a/public/posts/index.xml b/public/posts/index.xml
index b3249b8..89878d1 100644
--- a/public/posts/index.xml
+++ b/public/posts/index.xml
@@ -9,7 +9,7 @@
In this ‘series’ I will be walking you through my process of how I
-host everything on this server. 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 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. 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. 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: 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 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. e.g you might have this for starting a web server on port 3000: Or you could even have two servers, like, a gogs and a web server! 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. 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.
-
-
-
-
diff --git a/public/posts/setup_p1/index.html b/public/posts/setup_p1/index.html
index 7971cbc..31e43c0 100644
--- a/public/posts/setup_p1/index.html
+++ b/public/posts/setup_p1/index.html
@@ -45,7 +45,7 @@
-
+
@@ -55,7 +55,7 @@
-
+
@@ -147,13 +147,13 @@
-
-
-
-
-
-
-
-
- My Setup - p1
-
-
-
-
-
- Oct 25, 2024 - 5 minute read
-
-
-
-
-
-
-
- Podman
-git push, and not worry about the rest.Motivation
-Basics of podman
-# 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.
-
-
-
- My Setup - p1
+ My Setup
- Containers!
+ Containers! Docker!
- Oct 25, 2024 - 5 minute read
+ Oct 25, 2024 - 6 minute read
@@ -261,6 +261,35 @@ but that’s hardly elegant.
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.
+services:
+ web:
+ image: "nginx"
+ ports:
+ - 3000:80
+services:
+ web:
+ image: "nginx"
+ ports:
+ - 80:80
+ gogs-haha:
+ image: "gogs/gogs"
+ ports:
+ - 3000:3000
+ - 3022:22
+Conclusion
+