mirror of
https://github.com/skoobasteeve/skoobasteeve.github.io.2.git
synced 2026-03-20 07:58:57 +00:00
Compare commits
10 Commits
d52620607b
...
podman-aut
| Author | SHA1 | Date | |
|---|---|---|---|
|
974e6abc64
|
|||
|
1677407e63
|
|||
|
|
5069405ad6
|
||
|
|
7149fca6e5 | ||
|
|
4fd878bf88
|
||
|
|
268a2688c2
|
||
|
|
b9479367aa
|
||
|
|
7cad06cd58
|
||
|
|
ba178e07c7
|
||
|
|
38548ac908
|
@@ -276,7 +276,7 @@ defaults:
|
||||
author_profile: true
|
||||
read_time: true
|
||||
comments: true
|
||||
share: true
|
||||
share: false
|
||||
related: true
|
||||
classes: wide
|
||||
show_date: true
|
||||
|
||||
@@ -69,7 +69,7 @@ Enter [Ansible](https://www.ansible.com/). Anything you could possibly think to
|
||||
|
||||
This post talked about the ideas and goals I had going into this project, and in Part 2 I'll talk about the details of the implementation, and how sometimes things seem a lot easier in a blog post than they turn out to be in reality! If you're interested in the nitty-gritty of how these tools work for a project like this, stay tuned for the next post in the series.
|
||||
|
||||
[*Link to Part two*]({% link _posts/2023-08-28-nextcloud-podman-part2.md %})
|
||||
[*Link to Part two*]({% link _posts/2023-10-03-nextcloud-podman-part2.md %})
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: single
|
||||
title: "Building a Reproducible Nextcloud Server, Part two: Podman containers and Systemd units"
|
||||
date: 2023-08-28 10:00:00
|
||||
date: 2023-10-03 08:00:00
|
||||
excerpt: "In the second installment of my Nextcloud server rebuild, we'll get our containers set up with Podman and deploy them on a public-facing server."
|
||||
categories: [Self-Hosting, Linux Administration]
|
||||
tags: linux nextcloud podman docker container vps
|
||||
@@ -18,7 +18,7 @@ Now that I've established the stack, let's dive in to setting up the Nextcloud a
|
||||
* [Create a Podman Pod](#create-a-pod)
|
||||
* [Create the containers](#create-the-containers)
|
||||
* [Generate Systemd service files](#generate-systemd-files)
|
||||
* [Moving to production](#move-to-production)
|
||||
* [Move to production](#move-to-production)
|
||||
* [Troubleshooting](#troubleshooting)
|
||||
|
||||
### Requirements
|
||||
@@ -40,12 +40,13 @@ Podman "pods" are logical groupings of containers that depend on one another. Th
|
||||
For a much more thorough explanation on what pods are and how they work, check out this [excellent post](https://developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods) on the Red Hat developer blog.
|
||||
|
||||
**Rootless Gotcha #1**
|
||||
In most Linux distributions, unprivileged applications are not allowed to bind themselves to ports below 1024. To fix this, we'll need to update a system parameter via `sysctl`:
|
||||
In most Linux distributions, unprivileged applications are not allowed to bind themselves to ports below 1024. Before we get started, we'll need to update a system parameter via `sysctl` to solve this issue:
|
||||
``` shell
|
||||
sudo sysctl net.ipv4.ip_unprivileged_port_start=80
|
||||
sudo echo "net.ipv4.ip_unprivileged_port_start=80" > /etc/sysctl.d/99-podman.conf
|
||||
```
|
||||
\
|
||||
|
||||
To make the change persist on reboot, create a new file under `/etc/sysctl.d/` named `99-podman.conf` and paste the line `net.ipv4.ip_unprivileged_port_start=80`. You'll need to use `sudo` privileges for this.
|
||||
|
||||
After that's done, let's create a new pod called "nextcloud".
|
||||
|
||||
``` shell
|
||||
@@ -373,7 +374,7 @@ your.server.com {
|
||||
|
||||
The above configuration will use Caddy's built-in automatic HTTPS to pull a certificate from Let's Encrypt. It also blocks web access to certain directories in your Nextcloud folder and adds redirects for Nextcloud's CalDAV and CardDAV endpoints.
|
||||
|
||||
### Mariadb optimizations
|
||||
### MariaDB optimizations
|
||||
|
||||
After running this setup in production for a couple months and going through my first Nextcloud version upgrade, I had issues with Nextcloud losing access to the database during the upgrade process. I did some research and found this [helpful article](https://docs.nextcloud.com/server/latest/admin_manual/configuration_database/linux_database_configuration.html) in Nextcloud's documentation which points to some MariaDB options we can use to fix these issues.
|
||||
|
||||
@@ -471,23 +472,23 @@ Restart=on-failure
|
||||
TimeoutStopSec=70
|
||||
ExecStartPre=/bin/rm -f %t/%n.ctr-id
|
||||
ExecStart=/usr/bin/podman run \
|
||||
--cidfile=%t/%n.ctr-id \
|
||||
--cgroups=no-conmon \
|
||||
--rm \
|
||||
--pod-id-file %t/pod-nextcloud-pod.pod-id \
|
||||
--sdnotify=conmon \
|
||||
--replace \
|
||||
--detach \
|
||||
--env MYSQL_DATABASE=${MYSQL_DATABASE} \
|
||||
--env MYSQL_USER=${MYSQL_USER} \
|
||||
--env MYSQL_PASSWORD=${MYSQL_PASSWORD} \
|
||||
--env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} \
|
||||
--volume %h/.podman/nextcloud/mariadb:/var/lib/mysql:z \
|
||||
--name mariadb docker.io/library/mariadb:11 \
|
||||
--transaction-isolation=READ-COMMITTED \
|
||||
--cidfile=%t/%n.ctr-id \
|
||||
--cgroups=no-conmon \
|
||||
--rm \
|
||||
--pod-id-file %t/pod-nextcloud-pod.pod-id \
|
||||
--sdnotify=conmon \
|
||||
--replace \
|
||||
--detach \
|
||||
--env MYSQL_DATABASE=${MYSQL_DATABASE} \
|
||||
--env MYSQL_USER=${MYSQL_USER} \
|
||||
--env MYSQL_PASSWORD=${MYSQL_PASSWORD} \
|
||||
--env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} \
|
||||
--volume %h/.podman/nextcloud/mariadb:/var/lib/mysql:z \
|
||||
--name mariadb docker.io/library/mariadb:11 \
|
||||
--transaction-isolation=READ-COMMITTED \
|
||||
--log-bin=binlog \
|
||||
--binlog-format=ROW \
|
||||
--max_allowed_packet=256000000
|
||||
--max_allowed_packet=256000000
|
||||
ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
|
||||
ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id
|
||||
Type=notify
|
||||
@@ -527,8 +528,10 @@ If you haven't done so already, make the change to update the unprvivileged port
|
||||
|
||||
``` shell
|
||||
sudo sysctl net.ipv4.ip_unprivileged_port_start=80
|
||||
sudo echo "net.ipv4.ip_unprivileged_port_start=80" > /etc/sysctl.d/99-podman.conf
|
||||
```
|
||||
|
||||
Don't forget to create the file at `/etc/sysctl.d/99-podman.conf` so it persists on reboot!
|
||||
|
||||
\
|
||||
Finally, start the Nextcloud service!
|
||||
|
||||
@@ -536,7 +539,7 @@ Finally, start the Nextcloud service!
|
||||
systemctl --user start pod-nextcloud
|
||||
```
|
||||
\
|
||||
Verify everything is running with `podman ps`.
|
||||
On the first run, it may take a few mintues for Podman to pull down the container images. Check the output of `podman ps` and you should see the containers appearing there one after the other, eventually showing all three.
|
||||
|
||||
``` shell
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
@@ -548,11 +551,23 @@ b29486a99286 docker.io/library/caddy:2 caddy run --confi... 4 minute
|
||||
\
|
||||
At this point you should have rootless Nextcloud accessible at your FQDN on the public internet with HTTPS!
|
||||
|
||||
{:class="img-responsive"}
|
||||
|
||||
Walk through the first-time setup of Nextcloud to create your admin account and install apps.
|
||||
|
||||
{:class="img-responsive"}
|
||||
|
||||
{:class="img-responsive"}
|
||||
|
||||
I recommend navigating to **Administration Settings -> Overview** and reading the "Security & setup warnings". The Nextcloud app always has a few recommendations for fixes and changes to the configuration, with documentation to back it up.
|
||||
|
||||
{:class="img-responsive"}
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If the Nextcloud page isn't loading as expected or you're getting an error when launching your service, the container output logs are your friends! Run `podman ps` to see if your containers are running. If they are, use `podman logs <container name>` to see the latest output from each container. It's usually pretty easy to spot red flags there.
|
||||
|
||||
If the containers aren't running, use `sudo journalctl -xe` to check the output of each service. You may have to scroll up a bit to get useful information, since services will often try to restart multiple times after an error and fill up the output in process. Make sure you scroll up past the messages that say "service start request repeated too quickly" and try to find the first messages shown from each container's service.
|
||||
If the containers aren't running, use `sudo journalctl -xe` to check the output of each service. You may have to scroll up a bit to get useful information, since services will often try to restart multiple times after an error and fill up the output. Make sure you scroll up past the messages that say "service start request repeated too quickly" and try to find the first messages shown from each container's service.
|
||||
|
||||
**Common problems**
|
||||
* Directory or file referenced in the `*.service` file doesn't exist or is in the wrong location (your container directories and Caddyfile). Make sure the paths are consistent in all your files.
|
||||
@@ -567,8 +582,8 @@ If the containers aren't running, use `sudo journalctl -xe` to check the output
|
||||
|
||||
## Next steps
|
||||
|
||||
Now that we have a working server, let's make sure we never have to do it by hand again! In Part 3 of the series, I'll go over how you can automate the entire configuration with an [Ansible playbook](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html). Not only can you re-use that playbook to spin up multiple servers or re-deploy on a new hosting provider, it's also documentation that writes itself.
|
||||
Now that we have a working server, let's make sure we never have to do it by hand again! In Part 3 of the series, I'll go over how you can automate the entire configuration with an [Ansible playbook](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html). Not only can you re-use that playbook to spin up multiple servers or re-deploy on a new hosting provider, it also acts as documentation that writes itself.
|
||||
|
||||
As always, feel free to leave a comment below with any questions or suggestions. You can also reach me by [email](mailto:blog@rayagainstthemachine.net) or [Mastodon](https://fosstodon.org/@skoobasteeve).
|
||||
As always, feel free to leave a comment below with any questions or suggestions. You can also reach me by [email](mailto:ray@rayagainstthemachine.net) or [Mastodon](https://fosstodon.org/@skoobasteeve).
|
||||
|
||||
Happy hacking!
|
||||
108
_posts/2023-10-08-podman-auto-update.md
Normal file
108
_posts/2023-10-08-podman-auto-update.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
layout: single
|
||||
title: "Easily Update Your Containers with Podman Auto-Update"
|
||||
date: 2023-10-08 16:00:00
|
||||
excerpt: "Use this handy built-in feature of Podman to update all your container images with a single command."
|
||||
categories: [Linux Administration]
|
||||
tags: linux nextcloud podman docker container update
|
||||
comments: true
|
||||
---
|
||||
|
||||
I've written previously about the joys of using Podman to manage your containers, including the benefits of using it over Docker, but one of my favorite quality-of-life features is the [podman auto-update](https://docs.podman.io/en/stable/markdown/podman-auto-update.1.html) command.
|
||||
|
||||
In short, it replaces the series of commands you would normally run to update containers, for example:
|
||||
|
||||
1. `podman pull nextcloud-fpm:27`
|
||||
2. `podman stop nextcloud-fpm`
|
||||
3. `podman rm nextcloud-fpm`
|
||||
4. `podman run [OPTIONS] nextcloud-fpm:27`
|
||||
5. Repeat for each container.
|
||||
|
||||
Not only does podman auto-update save you all these steps, it will also automatically roll back to the previous image version if there are errors starting the new version, giving you some peace of mind when updating important applications.
|
||||
|
||||
## Requirements
|
||||
* Podman installed
|
||||
* Containers [managed with systemd](https://docs.podman.io/en/stable/markdown/podman-generate-systemd.1.html)
|
||||
* Containers you want to update must use the `--label "io.containers.autoupdate=registry"` run option
|
||||
|
||||
## Instructions
|
||||
|
||||
Recreate your existing systemd-managed containers with the `--label "io.containers.autoupdate=registry"` option. To do this, just edit your container's service file to include the option. See the below partial example for my Nextcloud container:
|
||||
|
||||
``` systemd
|
||||
ExecStartPre=/bin/rm -f %t/%n.ctr-id
|
||||
ExecStart=/usr/bin/podman run \
|
||||
--cidfile=%t/%n.ctr-id \
|
||||
--cgroups=no-conmon \
|
||||
--rm \
|
||||
--pod-id-file %t/pod-nextcloud-pod.pod-id \
|
||||
--sdnotify=conmon \
|
||||
--replace \
|
||||
--detach \
|
||||
--env MYSQL_HOST=mariadb \
|
||||
--env MYSQL_DATABASE=nextcloud \
|
||||
--env MYSQL_USER=${MYSQL_USER} \
|
||||
--env MYSQL_PASSWORD=${MYSQL_PASSWORD} \
|
||||
--volume %h/.podman/nextcloud/nextcloud-config:/var/www/html:z \
|
||||
--volume /mnt/nextcloud-data/data:/var/www/html/data:z \
|
||||
--label "io.containers.autoupdate=registry" \
|
||||
--log-driver=journald \
|
||||
--name nextcloud-app docker.io/library/nextcloud:${NEXTCLOUD_VERSION}-fpm
|
||||
ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
|
||||
```
|
||||
\
|
||||
Once you're done, reload the systemd daemon and restart the service.
|
||||
``` shell
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user restart container-nextcloud.service
|
||||
```
|
||||
\
|
||||
Next, run the auto-update command with the `--dry-run` option. With this option, you'll get a preview of which containers will be updated without the update taking place.
|
||||
|
||||
``` shell
|
||||
podman auto-update --dry-run
|
||||
|
||||
UNIT CONTAINER IMAGE POLICY UPDATED
|
||||
pod-nextcloud-pod.service 643fd5d3e2cb (nextcloud-app) docker.io/library/nextcloud:27-fpm registry pending
|
||||
pod-nextcloud-pod.service 71e48b691447 (mariadb) docker.io/library/mariadb:10 registry pending
|
||||
pod-nextcloud-pod.service 9ed555fecdfa (caddy) docker.io/library/caddy registry pending
|
||||
```
|
||||
|
||||
### Output explained
|
||||
* `podman auto-update` will show updates for every container that has the "io.containers.autoupdate=registry" label and do them all at once
|
||||
* The `UNIT` column shows the same "pod" service for each container. This is because my containers are all managed by a single Podman pod.
|
||||
* The `UPDATED` column shows "pending", which means there is an update available from the container registry.
|
||||
|
||||
\
|
||||
Once you're ready to update, run the command again without the `--dry-run` option.
|
||||
|
||||
``` shell
|
||||
podman auto-update
|
||||
```
|
||||
\
|
||||
Podman will begin pulling the images from the registry, which may take a few minutes depending on your connection speed. If it completes successfully, you'll get fresh output with the `UPDATED` column changed to `true`.
|
||||
|
||||
``` shell
|
||||
UNIT CONTAINER IMAGE POLICY UPDATED
|
||||
pod-nextcloud-pod.service 643fd5d3e2cb (nextcloud-app) docker.io/library/nextcloud:27-fpm registry true
|
||||
pod-nextcloud-pod.service 71e48b691447 (mariadb) docker.io/library/mariadb:10 registry true
|
||||
pod-nextcloud-pod.service 9ed555fecdfa (caddy) docker.io/library/caddy registry true
|
||||
```
|
||||
\
|
||||
During this process, the containers were restarted automatically with the latest image. You can verify this with `podman ps`.
|
||||
|
||||
``` shell
|
||||
podman ps
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
0c5523997648 localhost/podman-pause:4.6.1-1692961071 2 minutes ago Up 2 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp 0e075fb7b67b-infra
|
||||
4ba992e83eeb docker.io/library/caddy:latest caddy run --confi... 2 minutes ago Up 2 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp caddy
|
||||
2a7d448b1b6b docker.io/library/nextcloud:27-fpm php-fpm 2 minutes ago Up About a minute 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp nextcloud-app
|
||||
9ec017721f16 docker.io/library/mariadb:10 --transaction-iso... 2 minutes ago Up 2 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp mariadb
|
||||
```
|
||||
\
|
||||
That's it! Your Podman containers were updated to the latest image version with a single command. This is a small feature, but one I've come to love in my time using Podman. If you get stuck, check out the project's [documentation for the auto-update command](https://docs.podman.io/en/stable/markdown/podman-auto-update.1.html). If you have broader questions about running Podman, I recommend reading my [series on building a reproducible Nextcloud server with Podman]({% link _posts/2023-08-27-nextcloud-podman.md %}).
|
||||
|
||||
Happy hacking!
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 612 KiB After Width: | Height: | Size: 335 KiB |
BIN
assets/images/screenshots/nextcloud-podman02.png
Normal file
BIN
assets/images/screenshots/nextcloud-podman02.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 575 KiB |
BIN
assets/images/screenshots/nextcloud-podman03.png
Normal file
BIN
assets/images/screenshots/nextcloud-podman03.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 662 KiB |
BIN
assets/images/screenshots/nextcloud-podman04.png
Normal file
BIN
assets/images/screenshots/nextcloud-podman04.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 563 KiB |
BIN
assets/images/screenshots/nextcloud-podman05.png
Normal file
BIN
assets/images/screenshots/nextcloud-podman05.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 541 KiB |
Reference in New Issue
Block a user