Docker・Podman コマンドジェネレーター

よく使う docker・podman コマンド: shell、logs、exec、run、build、compose。

このツールについて

コンテナーでシェルを開く、ログを追跡する、コマンドを実行する、ファイルをコピーする、調べる、イメージをビルド・削除する、Docker Compose を操作するなど、やりたいことを選ぶと、すべてのフラグの説明付きで正確な docker・podman コマンドが得られます。run ビルダーではコンテナーを Compose ファイルに変換することもでき、貼り付けた run コマンドをインポートして編集することもできます。

使い方

  1. Docker または Podman を選びます。プログラム名以外はコマンドは同じです。
  2. 左側から「シェルを開く」「ログを表示」「ディスク容量を空ける」などのタスクを選びます。
  3. コンテナー名とオプションを入力します。入力した名前は他のタスクにも引き継がれます。
  4. コマンドをコピーし、各部分の意味を確認します。「新しいコンテナーを実行」では Compose ファイルも取得できます。

よくある質問

実行中のコンテナー内でシェルを使うには?
docker exec -it CONTAINER sh を実行します。イメージに bash があれば sh の代わりに bash を使えます。slim や Alpine のイメージには通常 sh しかありません。コンテナーを停止せずに抜けるには exit と入力します。
コンテナーのログを追跡するには?
docker logs -f --tail 100 CONTAINER で最後の 100 行を表示し、そのままストリーミングを続けます。最近の行だけなら --since 10m を追加し、grep -i --line-buffered error にパイプすれば、届いた行を順次絞り込めます。
docker run コマンドを docker compose に変換するには?
コマンドをインポート欄に貼り付け、結果を「Compose ファイル」に切り替えます。ポート、ボリューム、環境変数、再起動ポリシー、ネットワーク、リソース制限が引き継がれます。
-p 8080:80 はどういう意味ですか?
左の数字は手元のマシンのポート、右の数字はコンテナー内のポートです。先頭に 127.0.0.1: を付けると、そのポートには自分のコンピューターからしかアクセスできなくなります。
名前付きボリュームとバインドマウントの違いは何ですか?
./data:/data のようなバインドマウントは、手元のマシンのフォルダーを割り当てます。pgdata:/var/lib/postgresql/data のような名前付きボリュームは Docker が管理するストレージで、コンテナーが削除されても残るため、データベースではこちらが一般的です。
Docker と Podman のコマンドは同じですか?
ほぼ同じです。podman run は同じフラグを受け付けます。主な違いはデフォルトでルートレスであることで、1024 未満のホストポートには追加設定が必要です。また、SELinux のシステムではバインドマウントに :Z が必要になることがよくあります。
パスワードを -e フラグで渡してもよいですか?
シェルの履歴や docker inspect に残ってしまいます。ローカルでのテスト以外では、バージョン管理の対象外にした --env-file や、プラットフォームのシークレット機能を使ってください。
コンテナーの IP アドレスを調べるには?
「コンテナーを調べる」を選んで「IP アドレス」を選ぶと、ツールが docker inspect --format のテンプレートを書いてくれます。ただし、IP が必要になることはまれです。同じユーザー定義ネットワークや Compose プロジェクトにあるコンテナーは、db:5432 のように名前で互いにアクセスでき、IP はコンテナーを作り直すたびに変わる可能性があります。
停止したコンテナーからファイルをコピーできますか?
はい。docker cp CONTAINER:/var/log/app.log ./ はコンテナーが実行中でも停止中でも使えるため、障害の後にログやクラッシュダンプを取り出すのに便利です。フォルダーごとコピーすることもできます。「ファイルをコピー(コンテナーとの間)」を使えば、どちらの方向のコマンドも得られます。
docker stop と docker kill の違いは?
docker stop は SIGTERM を送り、10 秒待って(-t で変更可能)から SIGKILL を送ります。docker kill はすぐに SIGKILL を送るため、後片付けの機会はありません。stop が毎回 10 秒まるごとかかる場合、プログラムが SIGTERM を無視している可能性が高く、多くはシェルがプロセス 1 として動いていてシグナルを渡していないことが原因です。

docker exec と docker run の違い

docker run は、イメージから新しいコンテナーを作成して起動します。docker exec は、すでに実行中のコンテナー内でコマンドを実行します。よくある間違いは、サーバーの中に「入る」ために docker run -it nginx bash を使うことです。これは本物のコンテナーの隣に新しいコンテナーを起動するだけで、そこで変更したものはすべて消えます。--rm を付けないと、試すたびに停止したコンテナーが残り、docker ps -a で表示されます。

docker exec はコンテナーが実行中のときしか使えないため、起動時にクラッシュするコンテナーには役立ちません。まず docker logs --tail 50 CONTAINER を読んでください。次に、通常のプログラムの代わりにシェルでイメージを起動します。例: docker run -it --rm --entrypoint sh IMAGE。run コマンドのビルダーには、そのために「その他のオプション」の中に「エントリーポイント」と「コマンドと引数」の欄があります。

Docker が使うディスク容量を空ける方法

まず docker system df を実行すると、イメージ、コンテナー、ローカルボリューム、ビルドキャッシュがどれだけの容量を使っているかがわかります。docker image prune は、再ビルドで残ったタグのないイメージ(dangling イメージ)だけを削除します。docker image prune -a はコンテナーが使っていないすべてのイメージを削除するため、次回は再ダウンロードが必要になります。docker container prune は停止したコンテナーを削除し、その書き込み可能レイヤーも解放します。

ボリュームには注意してください。データベースのファイルやアップロードされたファイルが入っています。docker volume prune はコンテナーが使っていないボリュームを削除し、Docker 23 以降では -a を付けない限り匿名ボリュームだけを削除します。docker system prune -a --volumes は、使われていないほぼすべてのものを一度に削除します。prune 系のコマンドは -f を付けない限り確認を求めますが、削除したものはゴミ箱に入らないため、確認する前にプロンプトをよく読んでください。

Docker の再起動ポリシー: unless-stopped と always の違い

--restart always を指定すると、Docker はコンテナーが終了するたびに再起動し、Docker デーモンの起動時にも、以前に手で停止したコンテナーであっても再起動します。unless-stopped も同じ動作ですが、自分で停止したコンテナーはマシンを再起動した後も停止したままです。on-failure は終了コードが 0 以外の場合にだけ再起動します。デフォルトの no は再起動しません。常駐させるサービスには、通常 unless-stopped が適しています。

Compose ファイルでは、同じ設定を restart: unless-stopped と書きます。値 no は "no" のようにクォートする必要があります。古い YAML パーサーはクォートなしの no を false として読むためで、ここでの Compose の出力では自動的にクォートされます。Podman は異なり、常駐するデーモンがないため、再起動ポリシーを設定したコンテナーがマシンの再起動後に復帰するのは、podman-restart サービスが有効になっている場合か、systemd の下で実行している場合だけです。

うまく動かない、または結果がおかしいですか? このツールの問題を報告