Docker コマンドの基本をマスターしよう：初心者向けにわかりやすく解説

はじめに

Dockerは、ソフトウェア開発や運用の現場で幅広く活用されているコンテナ型の仮想化技術です。

アプリケーションの動作環境をコンテナとしてまとめることで、開発マシンやサーバーなど、異なる環境であっても同じように動かしやすくなるというメリットがあります。

皆さんの周りでもDockerに触れる機会が増えてきていないでしょうか。

しかし初心者の方にとっては、「どんなコマンドがあるのか」「どのように使い分ければいいのか」がわかりにくいかもしれません。

そこでこの記事では、Dockerの基本コマンドとしてよく使われる docker run や docker ps、 docker stop などを中心に、実際の場面でどのように活用できるかをわかりやすく解説していきます。

コンテナを使った開発・運用の入り口として、みなさんの参考になれば幸いです。

この記事を読むとわかること

• Dockerでコンテナを利用するメリットと基本的な仕組み
• よく使うDockerコマンドの使い方と使用例
• 開発や運用でどのようにDockerを活用するかの具体的なイメージ
• コマンドを用いたコンテナ管理の流れとポイント
• Dockerを初めて導入する際に気をつけたいポイント

ここから順を追って解説していきます。

Dockerとは何か

コンテナ型仮想化とは

コンテナ型仮想化は、アプリケーションを動作させるのに必要な環境をひとまとめにしてパッケージ化したものを指します。

従来の仮想マシンではOSごとまるごと仮想化するため、重たいイメージが必要になりがちでした。

一方でDockerのようなコンテナ技術では、ホストOSとカーネルを共有しながら各アプリケーションの実行環境を隔離しています。

そのため、コンテナは起動や停止が軽量でスピーディーですし、メモリ消費やディスク使用量も従来の仮想マシンと比べて少なくなります。

このように、コンテナ型仮想化を使うと素早く動作環境を用意できるだけでなく、アプリケーションの配布やデプロイも簡単に行えるのが特徴です。

実務では、開発・テスト環境から本番環境への移行時に環境差異が生じにくいという強みも大きな利点となっています。

Dockerを使うメリット

Dockerにはさまざまなメリットがありますが、初心者の方がまず知っておくとよい代表的なメリットを挙げてみましょう。

1つは、環境構築が簡単になることです。

たとえば複数のアプリケーションを立ち上げるときでも、Dockerイメージを取得してコンテナを起動するだけで動作確認ができることがよくあります。

また、移植性が高いのも大きな魅力です。

開発マシンがWindowsであってもLinuxであっても、Dockerのコンテナを用いて動かせば同じ条件でソフトウェアが動くことが期待できます。

加えて、軽量かつ高速である点も注目に値します。

数千台以上のサーバーを運用する大規模環境でも、Dockerを使用するとコンテナのスケールアウトやスケールインを柔軟に行いやすくなります。

もちろん個人の開発マシンや小規模プロジェクトでも、軽量性とスピードは助けになりますので、幅広い場面で利用できるでしょう。

Dockerのインストール（簡易説明）

Dockerを実際に使うには、まずはホストマシンにDockerエンジンをインストールする必要があります。

インストール手順自体はOSごとに多少異なるものの、基本的には公式サイトからインストーラをダウンロードして設定すればOKです。

WindowsやmacOSの場合、Docker DesktopというGUIツールを導入するのが一般的です。

またLinuxの場合は、ディストリビューションのパッケージマネージャなどで簡単に導入することが多いです。

もしインストール後に docker version を実行してバージョン情報が表示されれば、基本的にセットアップ完了です。

ここでは詳細なインストール手順は省略しますが、環境が整ったら早速基本コマンドを試してみると理解が進むでしょう。

Dockerの基本コマンド一覧

docker run

コンテナを起動するための最も基本的なコマンドです。

使用例としては、すでにローカルにあるイメージを指定してコンテナを立ち上げる場合と、イメージがなければリポジトリから自動的に取得して実行する場合があります。

例えば、以下のように「hello-world」というイメージを指定して起動するとします。

コピー
docker run hello-world

まだ「hello-world」というイメージがダウンロードされていなければ、自動的に取得してコンテナを実行します。

コンテナの実行後、メッセージが表示されてプロセスが終了するタイプのイメージなら、そのままコンテナは停止します。

一方で、常駐型のアプリケーション(たとえばWebサーバーやDBサーバー)を起動するイメージの場合は、コンテナ内部でプロセスが動き続けます。

もしバックグラウンドで動かしたいときは、 -d オプションを付けてください。

たとえば下記のようにして、nginxをバックグラウンドで起動してみるとよいでしょう。

コピー
docker run -d -p 8080:80 --name mywebserver nginx

-p はポートマッピングを指定するオプションです。

ここではホストのポート8080をコンテナ内の80番ポートに割り当てるため、ブラウザで「http://localhost:8080」と入力すればnginxのデフォルトページが表示されます。

また --name オプションでコンテナ名をつけているので、後から管理しやすくなります。

docker ps

現在、稼働中のコンテナ一覧を表示するコマンドです。

バックグラウンドで動いているコンテナがどれなのかを確認したいときに使います。

コピー
docker ps

上記コマンドだけだと起動中のコンテナしか表示されませんが、停止したコンテナも含めて表示したいときは -a オプションを付けて実行します。

コピー
docker ps -a

コンテナが「Exited」となっている場合は停止中の状態です。

この一覧を見て、「あれ、いつの間にかいくつもコンテナが残っている…」というケースがあるかもしれませんが、そのようなときは後述の docker rm などで不要なコンテナを削除するとよいでしょう。

docker stop

動いているコンテナを正常に停止するコマンドです。

SIGTERMシグナルがコンテナ内のメインプロセスに送られ、少しの猶予を与えて停止を試みます。

使用例としては以下のように、コンテナ名またはコンテナIDを指定して実行します。

コピー
docker stop mywebserver

上の例で mywebserver は先ほど docker run --name で指定したコンテナ名です。

もし複数のコンテナをまとめて停止したい場合は、コンテナIDや名前を続けて指定することも可能です。

docker start

停止中のコンテナを再度起動するときに使うコマンドです。

すでに作成されているコンテナを再利用できるので、何度も環境を再構築する手間が省ける場合があります。

使い方は簡単で、停止しているコンテナ名またはコンテナIDを指定するだけです。

コピー
docker start mywebserver

ただし、コンテナによっては停止時に状態を失っていることもあります。

そのため、常にアプリケーションのデータが保存されるわけではない点には注意が必要です。

docker restart

コンテナを再起動するためのコマンドです。

停止→起動の手順を自動的に連続して行います。

コピー
docker restart mywebserver

一旦コンテナを完全にシャットダウンしてから起動し直すので、もし短時間のサービス停止が発生すると困るような場面では要注意です。

実務で本番サーバーのコンテナを再起動する際は、ダウンタイムを最小化するためにロードバランサーで切り離した上で行うといった工夫をすることが一般的です。

docker kill

docker stop では正常終了がうまくいかない場合、 docker kill を使います。

メインプロセスにSIGKILLシグナルを送り、ただちにコンテナを強制終了させるコマンドです。

コピー
docker kill mywebserver

強制終了なので、コンテナ内部でデータを書き込んでいる最中だと、データ破損のリスクが高くなります。

あくまで最終手段として使うのが望ましいでしょう。

docker rm

使わなくなったコンテナを削除するときに使います。

停止中のコンテナに対してしか削除できないため、稼働中のコンテナをまとめて削除したい場合は -f オプションで強制削除する方法もあります。

コピー
docker rm mywebserver

なお、コンテナを削除してしまうと、そのコンテナに紐づいた一時的なデータなども一緒に消えてしまう点に注意です。

また、コンテナを削除してもイメージ自体は残るので、後述の docker rmi コマンドで別途イメージも掃除することがあります。

docker images

ローカルに保存されているDockerイメージの一覧を表示するコマンドです。

コピー
docker images

各イメージのリポジトリ名、タグ、イメージID、作成日時やサイズなどが一覧で確認できます。

同じイメージ名でもタグが違えば別物として扱われることがあります。

イメージを扱う際は、イメージ名に続いてタグを指定する場合が多いので、どのタグを使っているかを確認しておくとトラブルを防ぎやすいです。

docker rmi

不要になったイメージを削除するためのコマンドです。

Dockerを長期間使っていると、古いバージョンのイメージがどんどん溜まってディスクを圧迫することがあります。

そういった場合は下記のようにイメージを削除し、ディスク容量を確保します。

コピー
docker rmi イメージ名またはID

イメージを消したら、それを元に作成されたコンテナは起動できなくなることに注意が必要です。

同じイメージを再度利用したいときは再ダウンロードする必要があります。

docker pull

Docker Hubなどのリポジトリからイメージを取得するコマンドです。

これにより、ローカルに存在しないイメージも手軽に入手できます。

コピー
docker pull ubuntu:20.04

タグを指定しないと最新の安定タグを取得するケースが多いですが、実務では明示的にタグを指定することを推奨します。

同じ「ubuntu」でもバージョンが異なるとライブラリ構成などが変わるため、予期せぬ動作につながることもあるからです。

docker push

ローカルのDockerイメージをリポジトリにアップロードするコマンドです。

一般的にはDocker Hubやプライベートリポジトリに自分のイメージを保存するときに使います。

コピー
docker push リポジトリ名/イメージ名:タグ

このコマンドを使うには、あらかじめリポジトリにログインしておく必要がある場合があります。

実務ではチームメンバーと共有するため、自分のカスタムイメージをプライベートリポジトリにpushしておくケースがよくあります。

docker exec

起動中のコンテナに対してコマンドを実行するために使うコマンドです。

例えば、コンテナ内に入って作業したいときに、 -it オプションを付けてシェルに入ることがよくあります。

コピー
docker exec -it mywebserver /bin/bash

コンテナの中にログインした後は、Linuxコマンドなどを実行したりログファイルを確認したりできます。

Webサーバーの設定を一時的に変更して試してみる、というような用途で使う場面が多いです。

docker logs

コンテナが標準出力や標準エラー出力に吐き出したログを確認できるコマンドです。

コピー
docker logs mywebserver

もしリアルタイムでログを追いかけたい場合は -f オプションを付けると便利です。

コピー
docker logs -f mywebserver

Webアプリケーションが想定どおりに起動しているか、エラーが出ていないかを確認するのに活躍します。

docker build

Dockerfileをもとに新しいDockerイメージを作成するコマンドです。

独自のアプリケーションやライブラリをまとめたイメージを作成したいとき、Dockerfileを書いて docker build を使います。

たとえば、現在のディレクトリにあるDockerfileを用いてイメージを作成したい場合は、以下のように指定します。

コピー
docker build -t myapp:1.0 .

-t オプションでイメージ名とタグを指定し、最後の . はDockerfileのあるディレクトリを意味しています。

こうして作成したイメージをpushすれば、チームや他の環境でも同じ環境を手軽に再現できるわけです。

docker commit

実行中または停止中のコンテナから、変更後の状態をイメージとして保存するコマンドです。

コピー
docker commit mywebserver mywebserver_image:latest

Dockerfileにまとめて構築するのが理想ですが、一時的にコンテナ内での変更をイメージ化したいときに使うこともあります。

ただし、大規模なプロジェクトでは手動のcommitは管理しにくくなるため、Dockerfileを作成して docker build を使う方が一般的です。

実際のコンテナ管理フロー

1. イメージ取得からコンテナ起動まで

まずは必要なイメージがローカルに存在しない場合、 docker pull で取得します。

続いて docker run でコンテナを起動し、バックグラウンドで動かすときは -d を付けておくと便利です。

起動したコンテナが正常に動いているかは docker ps でチェックできるので、コンテナ名やIDをひかえておきましょう。

2. ログの確認とアプリケーションのテスト

コンテナがきちんと動いているかを調べるには、 docker logs や docker exec でコンテナの内部ログや状態を確認します。

アプリケーションがエラーを出していないかや、環境変数がどう設定されているかなどを調べたいときは、 docker exec -it コンテナ名 /bin/bash で入ってみると理解が深まります。

もしコンテナが応答しなくなった場合は docker stop で停止させ、必要があれば docker kill で強制終了することも視野に入れます。

3. 不要になったコンテナやイメージの整理

開発を繰り返していると、使わなくなったコンテナやイメージが増えてきます。

そんなときは docker ps -a で停止中のコンテナを洗い出し、 docker rm で適宜削除します。

また docker images で一覧を確認し、古いイメージや使わないイメージを docker rmi で消しておけばディスクを節約できます。

定期的にこうしたお掃除をすることで、トラブルが起きにくくなります。

4. カスタムイメージの作成

自分専用のコンテナ環境を用意したい場合は、Dockerfileを作成して docker build でイメージ化するのが一般的です。

そのイメージを docker push すれば、他のチームメンバーやサーバー環境でも同じ構成を使えます。

運用が軌道に乗ってきたら、CI/CDパイプラインにDockerのビルドとpushを組み込むことも珍しくありません。

自動化によって環境差異を極小化し、作業効率を上げることができます。

実務でのDocker活用シーン

ローカル開発環境の統一

開発者によってOSやツールのバージョンが異なると、アプリケーションの動作に差が出ることがあります。

Dockerを使えば、イメージを共通化して「同じコンテナ上で開発する」という方法をとることができるため、「自分の環境では動くのに、他の人の環境では動かない」といった問題が減ります。

しかもコンテナを立ち上げるのに時間がかからないため、すぐに開発作業に取りかかれるメリットもあります。

テスト用の一時的な環境構築

新しいライブラリを試したい、アプリケーションがバージョンアップしたときに動作検証したいといった場合も、Dockerを使うと気軽に環境を作れます。

例えば docker pull でベースとなるLinuxイメージを取ってきて、そこに追加のパッケージを入れて動作確認を行うという流れです。

問題が起きればコンテナを削除してやり直せばいいので、テスト環境を壊す心配が少なくて安心です。

サーバーサイドの本番運用

Dockerは本番環境にも使われます。

Webサーバー、アプリケーションサーバー、データベースなどをコンテナとして立ち上げると、クラウド上の任意のサーバーに容易にデプロイ可能です。

複数のDockerコンテナを管理する仕組みとしては、オーケストレーションツールを利用するケースもあります。

そうした大規模環境ではコンテナの基本コマンドだけでは管理しきれない部分が出てきますが、まずは今回紹介しているコマンドをしっかり理解しておけば、オーケストレーションツールを学ぶときもスムーズです。

バックアップや移行作業

コンテナ内のデータをボリュームとしてマウントしておけば、コンテナ自体を再構築してもデータは残せます。

さらに、 docker commit でイメージ化しておけば、ある時点のコンテナ状態を保管しておくことも可能です。

ただし実務では、アプリケーションの中身やデータの一貫性をどう確保するかが重要になります。

Dockerだけで解決できるわけではありませんが、少なくとも環境移行の際にコンテナ化されていると手間が減るケースが多いでしょう。

よくある疑問とトラブルシュート

コンテナ内にデータを保存しても大丈夫？

基本的にDockerコンテナは「使い捨て」の概念があり、再作成すると変更が消えてしまうことがあります。

そのためデータの永続化にはボリュームを活用するか、ホスト側のディレクトリをマウントする方法がよく使われます。

たとえばDBのデータディレクトリをホスト上にマウントしておけば、コンテナを再作成してもデータを失わずにすみます。

stopコマンドでコンテナが停止しない

アプリケーションがSIGTERMを無視しているケースや、正常に終了するまで時間がかかるケースがあります。

タイムアウト時間を調整する方法もありますが、どうしても停止しないなら docker kill を使う手段もあります。

ただし強制終了はデータ破損のリスクがあるため、慎重に扱いましょう。

イメージがどんどん増えてディスクが足りない

利用しなくなったイメージが溜まっていると、ディスクが圧迫されやすくなります。

定期的に docker images でチェックし、不要なイメージは docker rmi で削除します。

あるいは docker system prune などを活用して、一気にクリーンアップすることも可能です。

ポートが衝突してコンテナが起動できない

ホスト側で同じポートを使っている別のコンテナやアプリケーションがあると、ポート競合が起きます。

その場合は -p オプションでホスト側のポート番号を変えてみるか、不要なコンテナを停止する必要があります。

競合が多発する現場では、ポート管理ルールを決めて混乱を防ぐことが重要です。

よく使うDockerコマンドのまとめ表

以下のような表で、Dockerコマンドをざっくり覚えておくのもおすすめです。

コンテナ運用時に気をつけたいポイント

イメージのバージョンを明示的に使う

タグを省略すると自動的に「latest」のイメージを取ってきがちですが、開発チーム内でどのタグを使うか明確に決めておくほうが混乱を防げます。

また、イメージ名に独自のタグを付けておくことで「どの時点でビルドしたイメージなのか」を区別しやすくなるでしょう。

リソース制限とコンテナ間の競合

DockerはホストマシンのCPUやメモリを必要に応じて使いますが、大規模運用ではコンテナごとのリソース割り当てを細かく制御したいことがあります。

--cpus や -m オプションなどを活用することで、コンテナに割り当てるCPUコア数やメモリ量を制限可能です。

そうすることで、あるコンテナがリソースを占有しすぎて他のコンテナに悪影響を与えるリスクを軽減できます。

ネットワーク設定の理解

コンテナ同士を通信させたい場合は、Dockerネットワークの概念を理解すると便利です。

基本的には docker run で --network オプションを指定する、あるいは docker network create で独自のネットワークを作るなどの方法があります。

ネットワークを分けておくと、ステージング環境と本番環境での通信経路を分離できるので、構成が複雑になる現場では重宝します。

ログやモニタリングの仕組み

Dockerはコンテナ内部の標準出力をログとして収集しやすい反面、大量のログが出ると追いきれなくなる可能性があります。

特に本番運用では、集中管理できる仕組みを用意するか、コンテナ内部でログをローテーションする設定が必要になるかもしれません。

クラウドのサービスや外部のログ管理ツールと連携して、効率よくモニタリングするやり方がよく見られます。

セキュリティへの配慮

Dockerコンテナは隔離されていますが、ホストOSから完全に独立しているわけではありません。

コンテナ実行ユーザーの権限設定や、使わないポートを閉じるなどの基本的なセキュリティ対策は欠かせません。

加えて、Dockerイメージの脆弱性をチェックしてくれるツールもあるので、可能な範囲で導入しておくと安心です。

Dockerのカスタムイメージ作成フロー例

1. Dockerfileの作成

たとえば、単純なWebアプリを動かすイメージを作るなら、次のようなDockerfileを用意します。

コピー
FROM nginx
COPY ./myapp /usr/share/nginx/html

ここではベースイメージに nginx を指定し、ローカルの myapp ディレクトリの中身をコンテナ内部の nginx のドキュメントルートにコピーしています。

2. docker build でイメージ化

次にDockerfileがあるディレクトリで以下を実行します。

コピー
docker build -t mycustomnginx:1.0 .

これで mycustomnginx:1.0 という名前のイメージが作られます。

3. コンテナ起動と確認

あとは下記のようにコンテナを起動して、アプリの動作を確認できます。

コピー
docker run -d -p 8080:80 mycustomnginx:1.0

ブラウザで http://localhost:8080 にアクセスし、アプリが表示されればOKです。

4. リポジトリにpush（必要に応じて）

チーム共有やサーバーへのデプロイのためにリポジトリにpushする場合、以下のようなコマンドを実行します。

コピー
docker push リポジトリ名/mycustomnginx:1.0

これで他のマシンからも docker pull リポジトリ名/mycustomnginx:1.0 で同じイメージを取得できます。

こうした一連の流れで、独自イメージを作って使いまわすことができるようになるのです。

Dockerのメリットを最大化するには

Dockerの特徴は、コンテナを通じて同じ環境を何度でも再現できることにあります。

そのため、イメージ管理の仕組みと合わせて、ソースコードや設定ファイルもバージョン管理システムで一元管理しておくとスムーズです。

また、チームで開発する際には「このイメージはどのソースコードのバージョンを元に作ったのか」が追跡できるように運用ルールを整備すると、トラブルが起きたときにも原因を特定しやすくなります。

さらに、CI/CDパイプラインと連動させて自動的にDockerイメージをビルドしテストする手順を組み込むと、開発効率が上がる場面も多いでしょう。

まとめ

Dockerを使うと、環境構築やアプリケーションの配布がとても簡単になります。

コンテナ同士の依存関係を分離しやすく、ローカル開発と本番運用で動作が大きく異なるリスクを減らせるのも大きなメリットです。

初心者の方はまず、 docker run や docker ps、 docker stop などの基本コマンドを使いこなせるようにしてみてください。

バックグラウンドでコンテナを起動し、ポートをマッピングしてアプリにアクセスする流れを身につけるだけでも、多くの場面で役に立ちます。

運用に慣れてきたら、独自イメージの作成やネットワークの設定、リソース制限などを活用していくとよいでしょう。

Dockerを上手に使いこなせるようになると、開発のスピードや移植性が大きく向上します。

気軽にコンテナを立ち上げて試行錯誤できるという点は、学習にも実務にも便利です。

ぜひ本記事を参考にしながら、まずは小さなアプリケーションをDockerで動かすところから始めてみてください。 ``