Clean up the setup page a little
This commit is contained in:
parent
6beeb53eac
commit
08bc8dfe2a
@ -1,5 +1,7 @@
|
|||||||
+++
|
+++
|
||||||
title = 'My Setup - p1'
|
title = 'My Setup - p1'
|
||||||
|
subtitle = 'Containers!'
|
||||||
|
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
|
date = 2024-10-25T23:11:17+03:00
|
||||||
draft = false
|
draft = false
|
||||||
+++
|
+++
|
||||||
@ -25,71 +27,69 @@ 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
|
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.
|
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
|
The "manual" approach also depends on me having already installed all
|
||||||
necessary software. If you have a dedicated server that you're running yourself,
|
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'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
|
that I'm not sure I'll keep forever. The ability to reproduce this exact setup
|
||||||
within minutes actually matters.
|
within minutes actually matters.
|
||||||
|
|
||||||
After reading a bit on this topic, I decided I would use podman for this. Docker
|
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),
|
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
|
but I decided on docker because it's been the standard for a while now
|
||||||
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
|
## Motivation
|
||||||
|
|
||||||
Basically, I'm already running a web server. Why shouldn't I also host several other services
|
Basically, I'm already running a web server. Why shouldn't I also host several
|
||||||
for friends and family while I'm at it? Why shouldn't I make the entire setup reproducable?
|
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:
|
Here are some of the services I wanted to self-host:
|
||||||
|
|
||||||
- Web server: obviously, who doesn't want a website?
|
- 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.
|
- 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.
|
- 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
|
- CI/CD: automatic testing and releases of my software is cool, and also
|
||||||
how I plan to handle the website as well.
|
incredibly useful.
|
||||||
|
|
||||||
Of course, there are always more things I could be self-hosting. So it makes sense to automate
|
Of course, there are always more things I could be self-hosting. So it makes
|
||||||
the setup, and that's where podman comes in.
|
sense to automate the setup, and that's where docker comes in.
|
||||||
|
|
||||||
## Basics of podman
|
## Basics of docker
|
||||||
|
|
||||||
Before we can get to the exciting stuff, we need to go over what podman is, and how to
|
Before we can get to the exciting stuff, we need to go over what docker is, and how to
|
||||||
use it. Essentially, podman is a container engine: it lets you build and run applications in
|
use it. Essentially, docker is a container engine: it lets you build and run
|
||||||
a containerized environment. Containers are useful because they provide security,
|
applications in a containerized environment. Containers are useful because they
|
||||||
easy setup and most importantly, reproducability.
|
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
|
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,
|
good, that's been done to death already. Right now, what matters is the actual setup,
|
||||||
so let's get on with it.
|
so let's get on with it.
|
||||||
|
|
||||||
If you've used docker before, you'll feel right at home. Many commands are unchanged
|
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
|
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.
|
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:
|
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
|
```sh
|
||||||
# Search for container images (on docker.io unless you configure otherwise)
|
# Search for container images (on docker.io unless you configure otherwise)
|
||||||
$ podman search <image name>
|
$ docker search <image name>
|
||||||
|
|
||||||
# Download (pull) an image from remote repo
|
# Download (pull) an image from remote repo
|
||||||
$ podman pull <image name>
|
$ docker pull <image name>
|
||||||
|
|
||||||
# list the images you have pulled.
|
# list the images you have pulled.
|
||||||
$ podman images
|
$ docker images
|
||||||
|
|
||||||
# run a container.
|
# run a container.
|
||||||
$ podman run <image name>
|
$ docker run <image name>
|
||||||
|
|
||||||
# run a container, but with a LOT of flags. I just listed the most useful ones.
|
# run a container, but with a LOT of flags. I just listed the most useful ones.
|
||||||
$ podman run
|
$ docker run
|
||||||
-i # interactive, so you can e.g. run a shell in the container
|
-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
|
-t # allocates a tty. useful with -i so that shell completion etc. can work
|
||||||
-d # opposite of -i, detach and run in the background
|
-d # opposite of -i, detach and run in the background
|
||||||
@ -99,35 +99,31 @@ $ podman run
|
|||||||
<command> # ... want a shell?
|
<command> # ... want a shell?
|
||||||
|
|
||||||
# list running containers. add -a to list ALL containers, running or stopped.
|
# list running containers. add -a to list ALL containers, running or stopped.
|
||||||
# podman ps <-a>
|
$ docker ps <-a>
|
||||||
|
|
||||||
# stop a running container.
|
# stop a running container.
|
||||||
$ podman stop <id>
|
$ docker stop <id>
|
||||||
|
|
||||||
# stopped containers don't automatically get removed. This command removes it.
|
# stopped containers don't automatically get removed. This command removes it.
|
||||||
$ podman rm <id>
|
$ docker rm <id>
|
||||||
```
|
```
|
||||||
|
|
||||||
## Pods are nice.
|
## Compose is nice.
|
||||||
|
|
||||||
Pods are basically just a collection of containers - multiple programs working
|
Docker compose is a nice way to essentially "group together" some containers,
|
||||||
with each other.
|
and ship them in an easy way.
|
||||||
|
|
||||||
Usually, on a server, each application *isn't* totally separate from each other
|
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
|
- 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
|
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
|
server and web server can't be *totally* separate, there's some amount of
|
||||||
relation. Pods can help with this.
|
relation.
|
||||||
|
|
||||||
Pods allow you to create a "pod" containing several containers, sharing resources
|
At the same time... I don't really want to set up both containers, then their
|
||||||
with each other, etc. For example, I could run a pod with nginx and gogs running
|
volumes, and their ports etc. by hand. Sure I could stick it in a shell script,
|
||||||
in seperate containers - then, the nginx server could act as a reverse proxy
|
but that's hardly elegant.
|
||||||
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
|
Docker compose helps with this: you can create a
|
||||||
configuration file, so setting them up is relatively easy.
|
`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.
|
||||||
|
@ -13,7 +13,7 @@
|
|||||||
<link>https://emin.software/posts/setup_p1/</link>
|
<link>https://emin.software/posts/setup_p1/</link>
|
||||||
<pubDate>Fri, 25 Oct 2024 23:11:17 +0300</pubDate>
|
<pubDate>Fri, 25 Oct 2024 23:11:17 +0300</pubDate>
|
||||||
<guid>https://emin.software/posts/setup_p1/</guid>
|
<guid>https://emin.software/posts/setup_p1/</guid>
|
||||||
<description>My Setup In this &lsquo;series&rsquo; I will be walking you through my process of how I host everything on this server.
I&rsquo;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.</description>
|
<description>I go over the things I&rsquo;ve learned about docker, and how I&rsquo;ve used it to host my website.</description>
|
||||||
</item>
|
</item>
|
||||||
<item>
|
<item>
|
||||||
<title>About</title>
|
<title>About</title>
|
||||||
|
@ -158,9 +158,7 @@
|
|||||||
My Setup - p1
|
My Setup - p1
|
||||||
</h4>
|
</h4>
|
||||||
<p class="mb-4 line-clamp-6 text-base text-slate-500 dark:text-slate-400">
|
<p class="mb-4 line-clamp-6 text-base text-slate-500 dark:text-slate-400">
|
||||||
My Setup In this ‘series’ I will be walking you through my process of how I host everything on this server.
|
I go over the things I’ve learned about docker, and how I’ve used it to host my website.
|
||||||
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.
|
|
||||||
</p>
|
</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="flex flex-row justify-between">
|
<div class="flex flex-row justify-between">
|
||||||
|
@ -13,7 +13,7 @@
|
|||||||
<link>https://emin.software/posts/setup_p1/</link>
|
<link>https://emin.software/posts/setup_p1/</link>
|
||||||
<pubDate>Fri, 25 Oct 2024 23:11:17 +0300</pubDate>
|
<pubDate>Fri, 25 Oct 2024 23:11:17 +0300</pubDate>
|
||||||
<guid>https://emin.software/posts/setup_p1/</guid>
|
<guid>https://emin.software/posts/setup_p1/</guid>
|
||||||
<description>My Setup In this &lsquo;series&rsquo; I will be walking you through my process of how I host everything on this server.
I&rsquo;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.</description>
|
<description>I go over the things I&rsquo;ve learned about docker, and how I&rsquo;ve used it to host my website.</description>
|
||||||
</item>
|
</item>
|
||||||
</channel>
|
</channel>
|
||||||
</rss>
|
</rss>
|
||||||
|
@ -46,9 +46,7 @@
|
|||||||
<meta property="og:url" content="https://emin.software/posts/setup_p1/">
|
<meta property="og:url" content="https://emin.software/posts/setup_p1/">
|
||||||
<meta property="og:site_name" content="haxala1r">
|
<meta property="og:site_name" content="haxala1r">
|
||||||
<meta property="og:title" content="My Setup - p1">
|
<meta property="og:title" content="My Setup - p1">
|
||||||
<meta property="og:description" content="My Setup In this ‘series’ I will be walking you through my process of how I host everything on this server.
|
<meta property="og:description" content="I go over the things I’ve learned about docker, and how I’ve used it to host my website.">
|
||||||
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.">
|
|
||||||
<meta property="og:locale" content="en_us">
|
<meta property="og:locale" content="en_us">
|
||||||
<meta property="og:type" content="article">
|
<meta property="og:type" content="article">
|
||||||
<meta property="article:section" content="posts">
|
<meta property="article:section" content="posts">
|
||||||
@ -58,9 +56,7 @@ When first creating this website, I just had my blog. I generated this blog usin
|
|||||||
|
|
||||||
<meta name="twitter:card" content="summary">
|
<meta name="twitter:card" content="summary">
|
||||||
<meta name="twitter:title" content="My Setup - p1">
|
<meta name="twitter:title" content="My Setup - p1">
|
||||||
<meta name="twitter:description" content="My Setup In this ‘series’ I will be walking you through my process of how I host everything on this server.
|
<meta name="twitter:description" content="I go over the things I’ve learned about docker, and how I’ve used it to host my website.">
|
||||||
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.">
|
|
||||||
|
|
||||||
|
|
||||||
<script>
|
<script>
|
||||||
@ -154,7 +150,7 @@ When first creating this website, I just had my blog. I generated this blog usin
|
|||||||
My Setup - p1
|
My Setup - p1
|
||||||
</h1>
|
</h1>
|
||||||
<h2 class="mt-4 text-2xl text-slate-500 dark:text-slate-400">
|
<h2 class="mt-4 text-2xl text-slate-500 dark:text-slate-400">
|
||||||
|
Containers!
|
||||||
</h2>
|
</h2>
|
||||||
<div class="mb-4 mt-2 text-sm text-slate-500 dark:text-slate-400">
|
<div class="mb-4 mt-2 text-sm text-slate-500 dark:text-slate-400">
|
||||||
Oct 25, 2024 - 5 minute read
|
Oct 25, 2024 - 5 minute read
|
||||||
@ -180,58 +176,58 @@ updated version to my server and put it in the web directory.</p>
|
|||||||
<p>This is a cumbersome process. The whole point of using hugo is to <em>focus on the
|
<p>This is a cumbersome process. The whole point of using hugo is to <em>focus on the
|
||||||
writing</em>, so having to zip and reupload for every typo is… not great. I
|
writing</em>, so having to zip and reupload for every typo is… not great. I
|
||||||
wanted to be able to do a simple <code>git push</code>, and not worry about the rest.</p>
|
wanted to be able to do a simple <code>git push</code>, and not worry about the rest.</p>
|
||||||
<p>The previous “manual” approach also depends on me having already installed all
|
<p>The “manual” approach also depends on me having already installed all
|
||||||
necessary software. If you have a dedicated server that you’re running yourself,
|
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’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
|
that I’m not sure I’ll keep forever. The ability to reproduce this exact setup
|
||||||
within minutes actually matters.</p>
|
within minutes actually matters.</p>
|
||||||
<p>After reading a bit on this topic, I decided I would use podman for this. Docker
|
<p>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),
|
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
|
but I decided on docker because it’s been the standard for a while now</p>
|
||||||
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).</p>
|
|
||||||
<p>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.</p>
|
|
||||||
<h2 id="motivation">Motivation</h2>
|
<h2 id="motivation">Motivation</h2>
|
||||||
<p>Basically, I’m already running a web server. Why shouldn’t I also host several other services
|
<p>Basically, I’m already running a web server. Why shouldn’t I also host several
|
||||||
for friends and family while I’m at it? Why shouldn’t I make the entire setup reproducable?</p>
|
other services for friends and family while I’m at it? Why shouldn’t I make the
|
||||||
<p>Here are some of the services I wanted to self-host:
|
entire setup reproducible?</p>
|
||||||
- Web server: obviously, who doesn’t want a website?
|
<p>Here are some of the services I wanted to self-host:</p>
|
||||||
- Some git server: having my own place to show off all the things I’ve done is certainly really cool.
|
<ul>
|
||||||
- Wireguard: Free VPN along with the website? sign me up.
|
<li>Web server: obviously, who doesn’t want a website?</li>
|
||||||
- CI/CD: automatic testing and releases of my software is cool, and also incredibly useful because that’s
|
<li>Some git server: having my own place to show off all the things I’ve done is
|
||||||
how I plan to handle the website as well.</p>
|
certainly really cool. For this, something like <a href="https://about.gitea.com/">Gitea</a>
|
||||||
<p>Of course, there are always more things I could be self-hosting. So it makes sense to automate
|
would normally be great. I went with <a href="https://gogs.io/">Gogs</a> instead, because
|
||||||
the setup, and that’s where podman comes in.</p>
|
it is far more lightweight.</li>
|
||||||
<h2 id="basics-of-podman">Basics of podman</h2>
|
<li>Wireguard: Free VPN along with the website? sign me up.</li>
|
||||||
<p>Before we can get to the exciting stuff, we need to go over what podman is, and how to
|
<li>CI/CD: automatic testing and releases of my software is cool, and also
|
||||||
use it. Essentially, podman is a container engine: it lets you build and run applications in
|
incredibly useful.</li>
|
||||||
a containerized environment. Containers are useful because they provide security,
|
</ul>
|
||||||
easy setup and most importantly, reproducability.</p>
|
<p>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.</p>
|
||||||
|
<h2 id="basics-of-docker">Basics of docker</h2>
|
||||||
|
<p>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.</p>
|
||||||
<p>I’m not going to spend any more time explaining what containers are and why they’re
|
<p>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,
|
good, that’s been done to death already. Right now, what matters is the actual setup,
|
||||||
so let’s get on with it.</p>
|
so let’s get on with it.</p>
|
||||||
<p>If you’ve used docker before, you’ll feel right at home. Many commands are unchanged
|
<p>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
|
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.</p>
|
setups tend to be a little different, but that won’t matter too much right now.</p>
|
||||||
<p>In case you’re unfamiliar with docker, here are some basic commands:</p>
|
<p>In case you’re unfamiliar with docker, here are some basic commands (run these
|
||||||
|
either as root, or as a user in the <code>docker</code> group):</p>
|
||||||
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span><span style="color:#75715e"># Search for container images (on docker.io unless you configure otherwise)</span>
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span><span style="color:#75715e"># Search for container images (on docker.io unless you configure otherwise)</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman search <image name>
|
</span></span><span style="display:flex;"><span>$ docker search <image name>
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># Download (pull) an image from remote repo</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># Download (pull) an image from remote repo</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman pull <image name>
|
</span></span><span style="display:flex;"><span>$ docker pull <image name>
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># list the images you have pulled.</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># list the images you have pulled.</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman images
|
</span></span><span style="display:flex;"><span>$ docker images
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># run a container.</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># run a container.</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman run <image name>
|
</span></span><span style="display:flex;"><span>$ docker run <image name>
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># run a container, but with a LOT of flags. I just listed the most useful ones.</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># run a container, but with a LOT of flags. I just listed the most useful ones.</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman run
|
</span></span><span style="display:flex;"><span>$ docker run
|
||||||
</span></span><span style="display:flex;"><span> -i <span style="color:#75715e"># interactive, so you can e.g. run a shell in the container</span>
|
</span></span><span style="display:flex;"><span> -i <span style="color:#75715e"># interactive, so you can e.g. run a shell in the container</span>
|
||||||
</span></span><span style="display:flex;"><span> -t <span style="color:#75715e"># allocates a tty. useful with -i so that shell completion etc. can work</span>
|
</span></span><span style="display:flex;"><span> -t <span style="color:#75715e"># allocates a tty. useful with -i so that shell completion etc. can work</span>
|
||||||
</span></span><span style="display:flex;"><span> -d <span style="color:#75715e"># opposite of -i, detach and run in the background</span>
|
</span></span><span style="display:flex;"><span> -d <span style="color:#75715e"># opposite of -i, detach and run in the background</span>
|
||||||
@ -241,34 +237,30 @@ setups tend to be a little different, but that won’t matter too much right
|
|||||||
</span></span><span style="display:flex;"><span> <command> <span style="color:#75715e"># ... want a shell?</span>
|
</span></span><span style="display:flex;"><span> <command> <span style="color:#75715e"># ... want a shell?</span>
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># list running containers. add -a to list ALL containers, running or stopped.</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># list running containers. add -a to list ALL containers, running or stopped.</span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># podman ps <-a></span>
|
</span></span><span style="display:flex;"><span>$ docker ps <-a>
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># stop a running container.</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># stop a running container.</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman stop <id>
|
</span></span><span style="display:flex;"><span>$ docker stop <id>
|
||||||
</span></span><span style="display:flex;"><span>
|
</span></span><span style="display:flex;"><span>
|
||||||
</span></span><span style="display:flex;"><span><span style="color:#75715e"># stopped containers don't automatically get removed. This command removes it.</span>
|
</span></span><span style="display:flex;"><span><span style="color:#75715e"># stopped containers don't automatically get removed. This command removes it.</span>
|
||||||
</span></span><span style="display:flex;"><span>$ podman rm <id>
|
</span></span><span style="display:flex;"><span>$ docker rm <id>
|
||||||
</span></span></code></pre></div><h2 id="pods-are-nice">Pods are nice.</h2>
|
</span></span></code></pre></div><h2 id="compose-is-nice">Compose is nice.</h2>
|
||||||
<p>Pods are basically just a collection of containers - multiple programs working
|
<p>Docker compose is a nice way to essentially “group together” some containers,
|
||||||
with each other.</p>
|
and ship them in an easy way.</p>
|
||||||
<p>Usually, on a server, each application <em>isn’t</em> totally separate from each other</p>
|
<p>Usually, on a server, each application <em>isn’t</em> totally separate from each other</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li>for my own use case, I want my git server (e.g. gogs) to automatically build
|
<li>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
|
and update my website whenever I push to its git repository. That means my git
|
||||||
server and web server can’t be <em>totally</em> separate, there’s some amount of
|
server and web server can’t be <em>totally</em> separate, there’s some amount of
|
||||||
relation. Pods can help with this.</li>
|
relation.</li>
|
||||||
</ul>
|
</ul>
|
||||||
<p>Pods allow you to create a “pod” containing several containers, sharing resources
|
<p>At the same time… I don’t really want to set up both containers, then their
|
||||||
with each other, etc. For example, I could run a pod with nginx and gogs running
|
volumes, and their ports etc. by hand. Sure I could stick it in a shell script,
|
||||||
in seperate containers - then, the nginx server could act as a reverse proxy
|
but that’s hardly elegant.</p>
|
||||||
based on host name, showing the web page on emin.software, and the git server on
|
<p>Docker compose helps with this: you can create a
|
||||||
git.emin.software. Nginx redirects to gogs which only binds to <em>the pod’s
|
<code>compose.yaml</code> file, and define containers, ports, volumes, secrets all inside
|
||||||
localhost address</em>, so only nginx can reach it. Likewise, a database server can
|
this file. Then, when you run <code>docker compose up</code> this configuration is read,
|
||||||
be added to the pod only for the git server to use, so that it can’t be reached
|
and all of it is processed as you would want it to.</p>
|
||||||
from the outside the pod - and it is logically grouped along with the rest of
|
|
||||||
the pod.</p>
|
|
||||||
<p>On top of this, pods can be built purely from a kubernetes-compatible
|
|
||||||
configuration file, so setting them up is relatively easy.</p>
|
|
||||||
|
|
||||||
</span>
|
</span>
|
||||||
</article>
|
</article>
|
||||||
|
Loading…
Reference in New Issue
Block a user