【Dockerコマンド】よく使うものpull image run execなど

Dockerを使うには、
Linuxと同様にいくつかの典型的なコマンドを使いこなす必要があります。

ただ、種類が多いことから
「どれがどれだったっけ？」ってなることもしばしば。

本記事では、とりあえずこれだけは知っておきたいDockerコマンドの紹介と解説をします。
忘れてしまったときなど本記事を見返せば、
思い出せるようにある種のチートシート的にも
構成していますので、ぜひご参考ください。

また、本記事の内容は、
下記動画でも視聴できるので、
併せてご参考ください。

Dockerコマンドの基本構成

dockerのコマンドは、一般的には下記の書式に従って実行します。

docker コマンド オプション

前回の記事で、「Dockerとは？」というDockerの基礎について触れたもので、
runやstartなどが出てきたと思いますが、コマンドというのはこれらに該当します。

オプションというのは、docker runコマンドなどでいうと、
コンテナ名を指定する、--nameやポート番号を指定する-pなどが該当します。

コンテナ起動から終了まで

コマンドの個別解説の前に、
コンテナの起動から終了までのライフサイクルをまとめます。

例えば、前回の記事(上の参考リンクの記事です)で登場した、
docker runコマンドは、pull、create、startの３つのコマンドをまとめて実行するコマンドでもあります。

docker run -dit --name sample -p 8080:80 -v "$PWD":/usr/local/apache2/htdocs/ httpd:2.4

これは下記と同様です。

docker pull httpd:2.4
docker create --name sample -p 8080:80 -v "$PWD:/usr/local/apache2/htdocs/ httpd:2.4
docker start sample

つまりdocker runコマンドの場合は、
ローカルにイメージがなければリポジトリが持ってきて、
作成、起動までやってくれるわけです。

なので、リポジトリからイメージを持ってくるだけに留めたい場合は、
上記で使っているdocker pullコマンドを使用します。

ローカルに何もイメージがない状態での
大まかなライフサイクルをまとめると、

pull(リポジトリからイメージを取得) → 作成 → 起動 → 停止 → 削除

という風になるのが一般的かと思います。
（作成してimage削除とかもあったりするので、必ずしもこの限りではないですが、
大まかな流れとしては上記のような感じです)

それでは次から、コマンドの個別解説に移りたいと思います。

Dockerコマンド使い方

docker pull

docker pullコマンドは、docker hubなどのレジストリから、
イメージを取得するコマンドです。docker hubなどを見るとわかりやすいと思います。

https://hub.docker.com/_/ubuntu

ここで、下記のようなコマンドが記載されてあったと思います。

docker pull ubuntu

これはまさにubuntuというイメージを取得するコマンドですね。

イメージ名には、タグをつけることも可能です。

タグというのは、そのイメージの分類名のようなものを指しており、
主にversionや安定版・開発版などを示したりするときに使われています。

これは例えばrubyイメージとかだとわかりやすいですね。

https://hub.docker.com/_/ruby

docker pull ruby:3.0

この場合は、rubyの3.0系を設定します。
dockerのメリットとして、このようにプログラミング言語などの
versionをコンテナごとに設定できるというのがあるので、
tag設定はこういうときに便利ですね。

slimとalpine

rubyなどのプログラミング言語のイメージのタグには、
しばしば、こうしたslimやalpineというタグが存在します。

おそらく、プログラミング言語間で大きな差異はないかと思いますが、
Rubyの場合で解説します。

slimは、公式では次のように説明されています。

This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run ruby. Unless you are working in an environment where only the ruby image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

https://hub.docker.com/_/ruby

最小限のパッケージしか入っていないので、
容量などの制約が大きいなどの事情がなければ、
そこまでおすすめはしないということですね。

slimを使わずとも、defaultのtagsの方がすんなり環境構築できるかと思いますし、
ニーズがよくわからないときは、default(ruby:3.0みたいなもの)を使うことを
公式も推奨していました。

なので、slimを使うのは軽量化したいというニーズがあることに加え、
自分で必要なパッケージとかを見極められる場合になると思うので、
割と上級者向けのタグですかね。

これに対して、alpineについては、次のように説明されています。

This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is useful when final image size being as small as possible is your primary concern. The main caveat to note is that it does use musl libc instead of glibc and friends, so software will often run into issues depending on the depth of their libc requirements/assumptions. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

https://hub.docker.com/_/ruby

これも、軽量系のタグで、Alpine Linuxという軽量のOSをベースにしているものです。
なので、slimと同じく軽量化のニーズがある場合には有用かもしれませんが、
musl libcというのを使っているようなので、それ関係の要件や依存関係に引っかかったりする懸念が
あるようです。

こちらは、そもそもベースが大きく異なるので、
思わぬエラーに遭遇しがちだと思うので、ある程度慣れている人向けの印象があります。

alpineを普段から使っている方であれば、
slimよりもalpine系の方が良いかと思います。

結論、軽量化したいニーズが強くなければ、
これらのタグは選択しなくて大丈夫です。

latestタグ

こちらのタグは最新版という意味で、
タグ名を省略したときは、latestタグが設定されたものとして扱われます。

開発環境などでは、最新版を使うことに問題はないでしょうが、
latestタグは頻繁に更新されるものなので、
本番環境などでタグを指定しなかったりするのは、
意図せずversionなどが変わってしまい、不具合の原因になるので、
避けるのが無難です。

docker image

docker image系のコマンドは、
イメージの管理を行うコマンドです。
下位コマンドがいくつかあります。
よく使うのだけ紹介します。

https://matsuand.github.io/docs.docker.jp.onthefly/engine/reference/commandline/image/

docker image ls

これは、イメージの一覧を出力します。

https://matsuand.github.io/docs.docker.jp.onthefly/engine/reference/commandline/image_ls/

docker image prune

こちらは、使っていないイメージをまとめて削除してくれるコマンドです。

https://matsuand.github.io/docs.docker.jp.onthefly/engine/reference/commandline/image_prune/

オプションが色々あり、
何も設定しないと、確認のプロンプトが表示されます。

docker image prune

プロンプトが不要であれば、
-fオプションで表示させずに実行できます。

docker image prune -f

--fileterオプションを指定すると、
untilやlabelなどのフィルタリングを行うことができますが、
やや高度で細かいので、untilなどで、特定の時刻前に生成されたイメージを削除するfilterを紹介します。

まず、--formatオプションを使って、
作成日時を表示します。

--formatオプションは、
Go言語のテンプレートを使って、
色々操作できるオプションです。

https://docs.docker.jp/config/formatting.html

例えば下記で使われている、tableは、
表示するフィールドを指定します。

docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.CreatedAt}}\t{{.Size}}'

そして、ここで表示されたCreatedAtを元に、
いつ起点から削除したいか決めます。
2020-09-12T03:23:27以前のイメージを消したければ、

docker image prune -a --force --filter "until=2020-09-12T03:23:27"

とする。

シンプルに10日以上(240h)前のイメージを消したければ、

docker image prune --filter "until=240h"

でも行えます。

docker image inspect

これは、詳細情報を出力します。

詳細情報を知りたいイメージを一つか複数指定します。

docker image inspect vue-sigh-api vue-sigh-front

上記は、vue-sigh-apiというイメージとvue-sigh-frontというイメージの
詳細情報を出力します。

docker image rm

こちらはシンプルに削除したいイメージを削除できるコマンドです。
inspectと同様で、一つか複数指定できます。

docker run

こちらは、コンテナの作成から起動までやってくれる、
いわゆる全部のせコマンドなので、
docker createなどの単体作成コマンドよりも、
圧倒的に使用頻度が高いです。

また、ローカルに存在しないイメージをrunした場合、
リモートから取得してくれるので、pullに相当することもやってくれるので、
まさに全部のせコマンドですね。

-itオプション

runコマンドなので、よく見かける、
-itオプションですが、
これは、-iオプションと-tオプションを繋げて表現したものです。

ただ、そうはいっても、それぞれを単体で使うことは
あまりないので、実質-itオプションと思ってしまっても、
そこまで差し支えないと思います。

ドキュメントでは、

-it は疑似 TTY（pseudo-TTY）をコンテナの標準入力に接続するよう、 Docker に対して命令します。つまり、コンテナ内でインタラクティブな bash シェルを作成します。

https://docs.docker.jp/engine/reference/commandline/run.html

と説明しています。

要するに、-itオプションを指定することで、
dockerコンテナとhostのターミナルを繋げているようなイメージですね。

-itオプションを指定しないと、
コンテナのシェルに接続できないので、
statusはextiedになります。

ちなみに、-iと-tの違いについては、
下記の記事がわかりやすかったです。

https://qiita.com/k_uchida_____/items/8ca31226bd6d10850791

--rmオプション

こちらもよく使うオプションで、
runで起動するコンテナは一時的な用途が多いので、
使わなくなったら、--rmオプションをしないと、
どんどんコンテナが蓄積されていきます。

なので、通常はこちらの--rmオプションを指定し、
コンテナを削除したくないときだけ、
オプションをつけないというふうにするといいと思います。

コンテナでシェルを実行する

コンテナの中に入って、特定のコマンドを実行したりしたいとき、
そのコンテナに対して、シェルを実行して、コンテナの中に入ることがよくあります。
upしているコンテナに対して、

docker exec -it sample-container /bin/bash

Ctrl + p、Ctrl + qを続けて押すとでデタッチすることができます。
シェルを終了するには、exitと入力します。

runでシェルを実行した場合、
exitを入力すると、コンテナも停止しますが、
execの場合、upのままです。

基本的には、execですでに起動中のコンテナに対して、
実行することがほとんどかと思います。

基本的に、docker runは、停止中のコンテナに実行して、
シェル終了時は、コンテナ終了するのに対して、
docker execは、実行中のコンテナに実行して、
シェル終了時は、コンテナは実行中のままという違いがあります。

基本的に、Railsとかで開発をしている際に、
使いたいコマンドは、
このコンテナに対して実行するコマンドを使って実行するので、

例えば、rails db:migrateとかは、
docker compose exec コンテナ名 rails db:migrateに変化します。