Fedora 31あたりでサポートが薄くなっても。薄々気づいていても見ないふりをして、dockerを使っていたわけですが。
Fedora 32になってサポートが無くなっても、騙し騙し使っていたわけですが。
Raspberry Pi 4で遊びながら「どうせならPodmanを使ってみようかな」という感じで、Podmanの知識を補充させて頂きました。
Fedoraで構築したおうちサーバのWordPressを、Docker ComposeからPodmanに移行する手順を記録しておこうと思います。
目次
移行前Docker compose版のWordPress設定
wordpressディレクトリを作成、wordpressとmysqlの永続化用にディレクトリを2つ作成してコンテナからマウントしている構成です。WordPressのTCPポート番号は8000番。
この場合のdocker-compose.yamlファイルは次の内容です。
version: '3.3'
services:
db:
image: mysql:latest
volumes:
- "./mysql:/var/lib/mysql:z"
restart: always
environment:
MYSQL_ROOT_PASSWORD: wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
security_opt:
- seccomp:unconfined
wordpress:
depends_on:
- db
image: wordpress:latest
links:
- "db"
ports:
- "8000:80"
volumes:
- "./html:/var/www/html:z"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
WORDPRESS_DEBUG: 0
こちらと同じ構成になるように、Podmanを設定したいと思います。
docker compseによるコンテナは終了しておきます。
docker-compose down
移行後Podman版のWordPress設定
※21.1.31追記:
Podmanのバージョンアップの影響で、下記のYAMLファイルではポッドが正常に起動できない場合があります。
その場合、ポッドを手動で作成後、YAMLファイルを出力する必要が御座います。
手順は下記の記事を御覧ください。
Podmanでポッドを再生するために必要なKubernetesのpod.yamlファイルを作成します。
vi wordpress-pod.yaml
次の内容になります。
# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.9.3
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-09-19T23:15:42Z"
labels:
app: wordpress-pod
name: wordpress-pod
spec:
containers:
- name: wp-web
env:
- name: WORDPRESS_DB_NAME
value: wordpress
- name: WORDPRESS_DB_HOST
value: 127.0.0.1
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
value: wordpress
image: docker.io/library/wordpress:latest
ports:
- containerPort: 80
hostPort: 8000
protocol: TCP
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /var/www/html
volumeMounts:
- mountPath: /var/www/html
name: wp-volume
- name: wp-db
env:
- name: MYSQL_ROOT_PASSWORD
value: wordpress
- name: MYSQL_USER
value: wordpress
- name: MYSQL_PASSWORD
value: wordpress
- name: MYSQL_DATABASE
value: wordpress
image: docker.io/mysql:latest
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /
volumeMounts:
- mountPath: /var/lib/mysql
name: db-volume
volumes:
- name: wp-volume
hostPath:
path: /root/docker/wordpress/html
type: Directory
- name: db-volume
hostPath:
path: /root/docker/wordpress/mysql
type: Directory
status: {}
注意が必要なのは、volumesセクションの「/root/docker/wordpress/html」あたりでしょうか。永続化するディレクトリの場所に合わせて調整して下さい。
使用するコンテナ・イメージも、dockerの場合と同じものを指定していますので、何かコンバートしたり何だりは特に必要無いようです。volumesでマウントしたボリュームも、podmanでそのまま使用できるようです。
準備ができたところで。Podmanでポッドを起動します。
podman play kube /root/docker/wordpress/wordpress-pod.yaml
このような感じで、docker composeで起動していたコンテナを終了。
永続化ディレクトリはそのまま使用しつつ。
Podmanでポッドを起動することができました。
エラーなども特に無く、TCPポート番号8000でWordPressサイトにアクセスできました。(個人用のサイトですのでお見せできませんが
wordpressのpodの停止・削除はこちらのコマンドになります。
podman pod stop wordpress-pod;podman pod rm wordpress-pod
WordPressディレクトリのバックアップについて
夜間にcronでスクリプトを自動実行して、/usb/hdd1に接続した外付けHDDにwordpressディレクトリのバックアップを行っていました。
コンテナの実行をdocker-composeからpodmanに変更しましたが、バックアップスクリプトも少し手直しするだけで、問題なく動作しています。
※20.9.26追記:cronジョブからこのスクリプトを実行した場合、ポッドの起動に失敗しています。何か実行時の環境の問題なのでしょうね。ふむ。とりあえず手動でポッドを起動していますが、そのあたりの研究も進めないとです。
#!/bin/sh
#backup wordpress
SD=/root/docker/wordpress
BD=/usb/hdd1
TD=wordpress
BM=${BD}/`hostname`_${TD}
BF=${BM}_`date +%Y%m%d%H%M%S`.7z
pushd ${SD}
#/usr/bin/docker-compose down
/usr/bin/podman pod stop wordpress-pod;/usr/bin/podman pod rm wordpress-pod
pushd ..
/usr/bin/7za a ${BF} ${TD}
popd
# /usr/bin/docker-compose up -d
/usr/bin/podman play kube /root/docker/wordpress/wordpress-pod.yaml
popd
#delete old backup wordpress
BRC=2
BFS=${BM}*.7z
if [ ! -z ${BRC} ]; then
cd ${BD}
BRC=$((${BRC}+1))
rm `ls -t ${BFS} | tail --lines=+${BRC}`
fi
dockerの場合、docker-compose downでサービスを停止していましたが、podmanではpodman pod stopで停止。ディレクトリを7zaコマンドで圧縮しながらバックアップ後、docker-compose upの代わりにpodman play kubeコマンドでサービスを起動する流れです。
最後のほうはおまけですが、ディスクが溢れないように、バックアップファイルは最新の2つのみ残して、古いものを自動的に消すようにしています。
ポッドの自動起動は調整が必要
systemdからポッドを起動できるように、wordpress-pod.serviceファイルを作成してみました。
vi /etc/systemd/system/wordpress-pod.service
以下の内容になりますが。正常に動作していません。
[Unit]
Description=WordPress Pod in Systemd
After=network.target
[Service]
Type=simple
TimeoutStartSec=15
User=root
ExecStartPre=/usr/bin/podman pod rm -f wordpress-pod
ExecStart=/usr/bin/podman play kube /root/docker/wordpress/wordpress-pod.yaml
ExecReload=/usr/bin/podman pod stop wordpress-pod
ExecReload=/usr/bin/podman pod rm -f wordpress-pod
ExecStop=/usr/bin/podman pod stop wordpress-pod
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
下記のコマンドでsystemdに登録する感じです。
systemctl daemon-reload
systemctl enable podman.socket --now
systemctl enable wordpress-pod.service --now
# コピペ用
systemctl status wordpress-pod.service
systemctl restart wordpress-pod.service
おそらくsystemdのプロセスからpodmanを起動する場合の環境設定に問題があるのかと思いますが、あまり深く調べていない状況です。
rootではなく通常ユーザで設定ファイルを作成後
vi ~/.config/systemd/user/wordpress-pod.service
systemdに–userオプションを付けてサービスの登録・起動をするパターンもあると思いますが、wordpressやmysqlがTCPポート80番、3306番で動作するため、おそらくsudo付きではないとコンテナが動かないかと思いますので、あまり期待できない感じです。
このあたりは、Podmanの完成度の向上に合わせて調整しようと思います。
今のところは手動で起動していますorz
とりあえず、今まで(自分を)騙して使っていたdocker composeを、Podmanに移行することができました。
永続化データもそのまま移行できたため、データが消えたり何だりといったトラブルはありませんでした。
夜間のバックアップについても、スクリプトを少し手直ししただけで、問題なく行えそうです。
PC起動時のポッドの自動起動は、(私の腕前では)うまく起動できていない状況です。
このあたりは情報収集を続けて、追々起動できるようにしたいと思います。