Docker Desktop 代替シリーズ第三部、Podman です。(第一部 minkikube 編、第二部 Lima + nerdctl 編)
Podman については Red Hat さんのブログが大変参考になります。
今回の Docker 社によるライセンス周りの変更が発表されるよりだいぶ前に How to replace Docker with Podman on a Mac という記事もありました。Podman は Linux 上で稼働する daemon とそのクライアントという構成となっており、Windows と Mac にはクライアントしかありません。この時の記事では Vagrant を使って Linux 仮想サーバーを起動させるという処理を macOS app にしようという内容でした。現在は podman machine
というサブコマンドで仮想サーバーを起動させることができるようになっているようです。それでは試してみましょう。
podman のインストール
$ brew install podman
これにより podman
, podman-remote
, gvproxy
コマンドが $(brew --prefix)/bin/
にリンクされていました。
podman machine の起動
podman machine init
podman machine init
で初期設定。初回は仮想マシンのイメージのダウンロードも行われます。
$ podman machine init Downloading VM image: fedora-coreos-34.20210919.1.0-qemu.x86_64.qcow2.xz [=>------------------------] 52.7MiB / 598.3MiB Downloading VM image: fedora-coreos-34.20210919.1.0-qemu.x86_64.qcow2.xz: done Extracting compressed file
ホームディレクトリ配下、~/.local/share/containers/podman/machine/qemu/
に仮想マシンのイメージファイル (qcow2) が配置されています。
$ ls -lh ~/.local/share/containers/podman/machine/qemu total 2.1G -rw-r--r-- 1 teraoka staff 599M Sep 23 18:05 fedora-coreos-34.20210919.1.0-qemu.x86_64.qcow2.xz -rw------- 1 teraoka staff 1.5G Sep 23 18:06 podman-machine-default_fedora-coreos-34.20210919.1.0-qemu.x86_64.qcow2
podman machine start
podman machine start
で仮想マシンを起動させます。
$ podman machine start INFO[0000] waiting for clients... INFO[0000] listening tcp://0.0.0.0:7777 INFO[0000] new connection from to /var/folders/nd/8mk6834s31g8dymd1_9pnqq00000gn/T/podman/qemu_podman-machine-default.sock Waiting for VM ... qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
podman machine ls
コマンドで仮想マシンの状態を確認できます。
$ podman machine ls NAME VM TYPE CREATED LAST UP podman-machine-default* qemu 7 minutes ago Currently running
podman machine ssh
podman machine ssh
で仮想マシンに ssh でログインできます。
$ podman machine ssh Connecting to vm podman-machine-default. To close connection, use `~.` or `exit` Warning: Permanently added '[localhost]:54552' (ECDSA) to the list of known hosts. Fedora CoreOS 34.20210919.1.0 Tracker: https://github.com/coreos/fedora-coreos-tracker Discuss: https://discussion.fedoraproject.org/c/server/coreos/ [core@localhost ~]$
これまでの流れで hosts は確認しちゃいますね。ホスト(mac)へアクセスするための名前は設定されていないようです。
[core@localhost ~]$ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
lima や minikube (virtualbox) の仮想マシンでは default router となっているアドレスにアクセスすることでホストにアクセスできたので、podman machine でも同様かな?と思って 192.168.127.1 にアクセスしてみましたがダメでした。(ホスト(mac)のIPアドレスを指定すればアクセスはできるんですけど、DHCP なので場所とかによって変わってしまうんですよね)
[core@localhost ~]$ ip a s 1: lo:mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s2: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 5a:94:ef:e4:0c:ee brd ff:ff:ff:ff:ff:ff inet 192.168.127.2/24 brd 192.168.127.255 scope global dynamic noprefixroute enp0s2 valid_lft 3256sec preferred_lft 3256sec inet6 fe80::7a18:f299:cead:4ecc/64 scope link noprefixroute valid_lft forever preferred_lft forever [core@localhost ~]$ ip r default via 192.168.127.1 dev enp0s2 proto dhcp metric 100 192.168.127.0/24 dev enp0s2 proto kernel scope link src 192.168.127.2 metric 100
ところで、なんでしょう? この謎のメッセージは? curl じゃない何かがエラーメッセージを出しています。 tcp の proxy をするやつがいそうです。
$ curl http://192.168.127.1:8080/ ERRO[6288] net.Dial() = dial tcp 192.168.127.1:8080: connect: operation timed out ERRO[6322] net.Dial() = dial tcp 192.168.127.1:8080: connect: operation timed out curl: (7) Failed to connect to 192.168.127.1 port 8080: Connection refused
curl の connect timeout を 1 秒にしてみる
[core@localhost ~]$ curl --connect-timeout 1 http://192.168.127.1:8080/
curl: (28) Connection timed out after 1006 milliseconds
[core@localhost ~]$ ERRO[6616] net.Dial() = dial tcp 192.168.127.1:8080: connect: operation timed out
curl が Go で書かれた別物というわけではなさそうです。
[core@localhost ~]$ curl --version curl 7.76.1 (x86_64-redhat-linux-gnu) libcurl/7.76.1 OpenSSL/1.1.1l-fips zlib/1.2.11 brotli/1.0.9 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.0) libssh/0.9.5/openssl/zlib nghttp2/1.43.0 Release-Date: 2021-04-14 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
どうやら podman machine start
で起動した際に listening tcp://0.0.0.0:7777
と表示されていたのは gvproxy のログのようですね。これを起動した terminal で podman machine ssh
してたのでそこに出てきただけで仮想マシン内ででたメッセージではありませんでした。
mac 側で gvproxy プロセスを確認してみる。
$ pgrep -lf gvproxy 52708 /Users/teraoka/.homebrew/bin/gvproxy -listen tcp://0.0.0.0:7777 -listen-qemu unix:///var/folders/nd/8mk6834s31g8dymd1_9pnqq00000gn/T/podman/qemu_podman-machine-default.sock -pid-file /var/folders/nd/8mk6834s31g8dymd1_9pnqq00000gn/T/podman/podman-machine-default.pid -ssh-port 54552
podman machine ssh した時に localhost の 54552 ポートに接続しようとしているのもこの gvproxy が中継しているようですね。podman run
の -p
で port を expose すると mac から localhost でもアクセスできるようにしてくれているのがこの gvproxy らしいんですが、仮想マシンからの outbound にも絡んでいるとは… (嬉しくない)
仮想マシンのリソース設定
デフォルトでは 2GB のメモリと 1 コアの CPU が割り当てられてました。
[core@localhost ~]$ free -h total used free shared buff/cache available Mem: 1.9Gi 128Mi 1.6Gi 5.0Mi 208Mi 1.7Gi Swap: 0B 0B 0B [core@localhost ~]$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 40 bits physical, 48 bits virtual CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 15 Model: 107 Model name: QEMU Virtual CPU version 2.5+ Stepping: 1 CPU MHz: 2591.776 BogoMIPS: 5183.55 L1d cache: 32 KiB L1i cache: 32 KiB L2 cache: 4 MiB L3 cache: 16 MiB NUMA node0 CPU(s): 0 Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported Vulnerability L1tf: Mitigation; PTE Inversion Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Full generic retpoline, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr ss e sse2 syscall nx lm constant_tsc nopl xtopology cpuid pni cx16 hypervisor lahf_lm pti
CPU やメモリのサイズを調整するには podman machine init
時に設定する必要があるようです。
$ podman machine init --help Initialize a virtual machine Description: initialize a virtual machine Usage: podman machine init [options] [NAME] Examples: podman machine init myvm Options: --cpus uint Number of CPUs. The default is 1. (default 1) --disk-size uint Disk size in GB (default 10) --ignition-path string Path to ignition file --image-path string Path to qcow image -m, --memory uint Memory (in MB) (default 2048)
$ podman machine init --cpus 2 --disk-size 5 --memory 1024 vm2 Extracting compressed file
$ podman machine ls NAME VM TYPE CREATED LAST UP podman-machine-default* qemu 4 hours ago Currently running vm2 qemu About a minute ago About a minute ago
仮想マシンを複数作成できるから同時に起動させることもできるのかな?と思ったけど同時に起動させられるのは1つだけのようです。
$ podman machine start vm2 Error: cannot start VM vm2. VM podman-machine-default is currently running: only one VM can be active at a time
仮想マシンの設定は ~/.config/containers/podman/machine/
配下に作成されていました。
$ find .config/containers/podman/machine .config/containers/podman/machine .config/containers/podman/machine/qemu .config/containers/podman/machine/qemu/podman-machine-default.json .config/containers/podman/machine/qemu/podman-machine-default.ign .config/containers/podman/machine/qemu/vm2.json .config/containers/podman/machine/qemu/vm2.ign
podman run
コンテナを実行してみます。
まずは image を pull してみる。
$ podman pull nginx:alpine Error: failed to parse "X-Registry-Auth" header for /v3.3.1/libpod/images/pull?alltags=false&arch=&authfile=&os=&password=&policy=always&quiet=false&reference=nginx%3Aalpine&username=&variant=: error storing credentials in temporary auth file (server: "https://index.docker.io/v1/", user: ""): key https://index.docker.io/v1/ contains http[s]:// prefix
うーむ、~/.docker/config.json が悪さをしているらしいので rename して再チャレンジ。
ちなみにこの時の config.json は次のようになっていました。 (containers-auth.json(5))
{ "auths": { "https://index.docker.io/v1/": {} }, "credsStore": "osxkeychain" }
$ podman pull nginx:alpine Error: short-name resolution enforced but cannot prompt without a TTY
エラーメッセージが変わった。short-name の解決したいけど TTY が使えないとダメだよと言ってるみたいなので docker.io もつけてみる。 (podman は image のホスト名部分を省略した場合にリストを順に検索してくれる設定があるらしい。未調査)
$ podman pull docker.io/nginx:alpine Trying to pull docker.io/library/nginx:alpine... Getting image source signatures Copying blob sha256:61074acc7dd227cfbeaf719f9b5cdfb64711bc6b60b3865c7b886b7099c15d15 Copying blob sha256:a0d0a0d46f8b52473982a3c466318f479767577551a53ffc9074c9fa7035982e Copying blob sha256:4dd4efe90939ab5711aaf5fcd9fd8feb34307bab48ba93030e8b845f8312ed8e Copying blob sha256:c1368e94e1ec563b31c3fb1fea02c9fbdc4c79a95e9ad0cac6df29c228ee2df3 Copying blob sha256:3e72c40d0ff43c52c5cc37713b75053e8cb5baea8e137a784d480123814982a2 Copying blob sha256:969825a5ca61c8320c63ff9ce0e8b24b83442503d79c5940ba4e2f0bd9e34df8 Copying blob sha256:969825a5ca61c8320c63ff9ce0e8b24b83442503d79c5940ba4e2f0bd9e34df8 Copying blob sha256:3e72c40d0ff43c52c5cc37713b75053e8cb5baea8e137a784d480123814982a2 Copying blob sha256:61074acc7dd227cfbeaf719f9b5cdfb64711bc6b60b3865c7b886b7099c15d15 Copying blob sha256:4dd4efe90939ab5711aaf5fcd9fd8feb34307bab48ba93030e8b845f8312ed8e Copying blob sha256:c1368e94e1ec563b31c3fb1fea02c9fbdc4c79a95e9ad0cac6df29c228ee2df3 Copying blob sha256:a0d0a0d46f8b52473982a3c466318f479767577551a53ffc9074c9fa7035982e Copying config sha256:513f9a9d8748b25cdb0ec6f16b4523af7bba216a6bf0f43f70af75b4cf7cb780 Writing manifest to image destination Storing signatures 513f9a9d8748b25cdb0ec6f16b4523af7bba216a6bf0f43f70af75b4cf7cb780
TTY 問題ですが、仮想マシン内で podman を実行した場合は次のような選択 UI になります。
[core@localhost ~]$ podman pull nginx:latest ? Please select an image: ▸ registry.fedoraproject.org/nginx:latest registry.access.redhat.com/nginx:latest docker.io/library/nginx:latest quay.io/nginx:latest
この registry の選択肢は仮想マシン側の /etc/containers/registries.conf
に定義されていました。 (containers-registries.conf(5))この設定はホスト (mac) 側の ~/.config/containers/registries.conf に書くこともできます。次のように docker.io だけにしておけば docker の場合と同じように動作します。 ホスト側のファイルで制御できるというのは間違いでした。debian のイメージで試したのですが、実はこれは下で紹介する alias によって pull できただけでした。仮想マシン内の ~/.config/containers/registries.conf
に書いてください。
[core@localhost ~]$ cat ~/.config/containers/registries.conf unqualified-search-registries = ["docker.io"]
@tnk4on さんから情報をいただきました。short-name の選択は仮想マシン側でファイルに cache されるそうです。~/.cache/containers/short-name-aliases.conf
にありました。
[core@localhost containers]$ cat ~/.cache/containers/short-name-aliases.conf [aliases] nginx = "docker.io/library/nginx"
この状態で pull してみると Resolved "nginx" as an alias (/var/home/core/.cache/containers/short-name-aliases.conf)
って出力されてました。
$ podman pull nginx:1.19.1 Resolved "nginx" as an alias (/var/home/core/.cache/containers/short-name-aliases.conf) Trying to pull docker.io/library/nginx:1.19.1... Getting image source signatures Copying blob sha256:1f1070938ccd20f58e90d4a03e71b859274580306295ec8b68cf39c6d7f1978f (snip) Copying blob sha256:c57dd87d0b93cc883c4af602c0a8e1a6bd9083f723fb426432427812fe3c0e31 Copying config sha256:08393e824c32d456ff69aec72c64d1ab63fecdad060ab0e8d3d42640fc3d64c5 Writing manifest to image destination Storing signatures 08393e824c32d456ff69aec72c64d1ab63fecdad060ab0e8d3d42640fc3d64c5
これまた @tnk4on さんからの情報ですが、registries.conf によるレジストリの一覧だけでなく、この cache のような形式で /etc/containers/registries.conf.d/000-shortnames.conf
に alias の一覧がありました。 次のようになっていて、ここに列挙されたものは
[core@localhost ~]$ head /etc/containers/registries.conf.d/000-shortnames.conf [aliases] # centos "centos" = "quay.io/centos/centos" # containers "skopeo" = "quay.io/skopeo/stable" "buildah" = "quay.io/buildah/stable" "podman" = "quay.io/podman/stable" # docker "alpine" = "docker.io/library/alpine" "docker" = "docker.io/library/docker"
次に podman run を試してみる。
podman で特権ポート (1024 未満) は listen できないよというのは知ってるけど試してみる。
$ podman run -it -p 80:80 docker.io/nginx:alpine Error: error preparing container 800d78d0aecb23d5838d0cce77ebe7fa4ef4209c01a97d13e4979bcad387634f for attach: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied
事前の情報通りエラーになった。次は -p 8080:80
で試す。
$ podman run -it -p 8080:80 docker.io/nginx:alpine /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2021/09/23 12:56:00 [notice] 1#1: using the "epoll" event method 2021/09/23 12:56:00 [notice] 1#1: nginx/1.21.3 2021/09/23 12:56:00 [notice] 1#1: built by gcc 10.3.1 20210424 (Alpine 10.3.1_git20210424) 2021/09/23 12:56:00 [notice] 1#1: OS: Linux 5.13.16-200.fc34.x86_64 2021/09/23 12:56:00 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 524288:524288 2021/09/23 12:56:00 [notice] 1#1: start worker processes 2021/09/23 12:56:00 [notice] 1#1: start worker process 27
podman の仮想マシン内であれば curl http://localhost:8080/
でアクセスできましたが、ホストの mac からは connection refused でした。冒頭で紹介したブログを確認すると、podman 3.3.1 では既知の問題らしいです。
[Note:] Podman v3.3.1時点でこの機能には不具合があり、上記のように–network bridgeをつけるか、他にも事前にpodman network createで作成したネットワークを指定する方法やcontainers.confファイルの[containers]セクションにrootless_networking = “cni”を追加する、などのワークアラウンドがあります。 この不具合については私の上げた下記Issue(すでにClose済み)で対応がなされており、次のバージョン(v3.3.2?)に修正が適用される見込みです。
でも仮想マシン内の .config/containers/containers.conf
には rootless_networking = "cni"
が最初から入ってたんだけどなあ。
[core@localhost ~]$ cat .config/containers/containers.conf [containers] netns="bridge" rootless_networking="cni"
podman run に --network bridge
をつけたら mac からも localhost でアクセスできました。
$ curl -s http://localhost:8080/ <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
ホスト (mac) 側にも containers.conf がありました。そして、こっちの [containers]
に rootless_networking = "cni"
を書けば --network bridge
指定なしで mac から localhost でアクセスできました。
$ cat ~/.config/containers/containers.conf [containers] log_size_max = -1 pids_limit = 2048 userns_size = 65536 [engine] image_parallel_copies = 0 num_locks = 2048 active_service = "podman-machine-default" stop_timeout = 10 chown_copied_files = false [engine.service_destinations] [engine.service_destinations.podman-machine-default] uri = "ssh://core@localhost:54552/run/user/1000/podman/podman.sock" identity = "/Users/teraoka/.ssh/podman-machine-default" [engine.service_destinations.podman-machine-default-root] uri = "ssh://root@localhost:54552/run/podman/podman.sock" identity = "/Users/teraoka/.ssh/podman-machine-default" [engine.service_destinations.vm2] uri = "ssh://core@localhost:55656/run/user/1000/podman/podman.sock" identity = "/Users/teraoka/.ssh/vm2" [engine.service_destinations.vm2-root] uri = "ssh://root@localhost:55656/run/podman/podman.sock" identity = "/Users/teraoka/.ssh/vm2" [network] [secrets]
podman build
コンテナイメージをビルドしてみる。
手元にあったこの Dockerfile で試してみます。
FROM fluent/fluentd:v1.12.4-debian-1.0 USER root RUN fluent-gem install fluent-plugin-kinesis -v 3.4.0 RUN fluent-gem install fluent-plugin-s3 COPY fluent.conf /fluentd/etc/fluent.conf USER fluent
$ podman build . STEP 1/6: FROM fluent/fluentd:v1.12.4-debian-1.0 Error: error creating build container: short-name resolution enforced but cannot prompt without a TTY
ここでも FROM の image に docker.io を足す必要がありました。
FROM docker.io/fluent/fluentd:v1.12.4-debian-1.0 USER root RUN fluent-gem install fluent-plugin-kinesis -v 3.4.0 RUN fluent-gem install fluent-plugin-s3 COPY fluent.conf /fluentd/etc/fluent.conf USER fluent
これで build はできました。
podman push
docker hub に push するためにはログインが必要です。podman login docker.io
でログインできました。認証情報は ~/.config/containers/auth.json
に保存されました。
$ cat ~/.config/containers/auth.json { "auths": { "docker.io": { "auth": "44Om44O844K244O85ZCNOuimi+OBoeOCg+ODgOODoeOCiA==" } } }
ボリュームマウント
仮想マシン上のディレクトりをマウントすることは可能です。
$ podman run -it -v /usr:/work --privileged docker.io/ubuntu
しかし、mac 側のディレクトリはマウントさせられません。Docker Desktop のように仮想マシンレイヤーを意識せずにマウントさせられるようになることを期待。
ちなみに、上記の ubuntu の実行ですが、root で実行するコンテナだからか --privileged
が必要でした。また、port-forward のための rootless_networking = "cni"
が書いてあるとエラーになりました。
$ podman run -it -v /usr:/work --privileged docker.io/ubuntu Error: error preparing container 98a665c8090d1693a963b7da46c5dfc0337d060f5010def610a9bad5f312ec8a for attach: error configuring network namespace for container 98a665c8090d1693a963b7da46c5dfc0337d060f5010def610a9bad5f312ec8a: error adding pod agitated_wiles_agitated_wiles to CNI network "podman": unexpected end of JSON input
こちらも @tnk4on からの情報で、これは podman machine のバグで、すでにアップストリームでは修正されているそうです。(tweet)
podman-compose
試していませんが docker-compose が必要な場合は Python で書かれた podman-compose というものが使えるようです。
alias
shell の alias で docker=podman とすれば、ほぼそのまま使えると思います。
まとめ
イメージを build するだけなら問題なさそうですが、ローカルでの開発用だとまだツラそう。今後に期待