DockerでWebサーバーを立てて片付けるまでを通しでやってみよう(総合演習)

まずdocker --versionで、Dockerが動いていることを確かめます。これが返らないときは、Dockerそのものが起動していません。

次がdocker images。手元にあるイメージの一覧で、いまは見出しだけで中身が空です。この「空の状態」を先に見ておくのが大事で、次のコマンドで何が増えたのかがはっきり分かります。

docker pull nginxで、Webサーバーの公式イメージを取ってきます。イメージは「設計図」、コンテナは「そこから起動した実物」——この2つの区別が、Dockerを理解する土台になります。

取得の途中でPull completeやDigestが流れます。イメージは層(レイヤー)の積み重ねでできており、すでに持っている層は再取得されません。2回目以降が速いのはこのためです。

もう一度docker imagesを打つと、nginx が1件だけ増えています。まだ起動はしていません。設計図を手に入れただけの状態です。

いよいよ起動です。docker run -d --name web -p 8080:80 nginx——3つのオプションにそれぞれ役割があります。

-dは「裏で動かす」。付けないとログが画面に流れ続け、そのターミナルが使えなくなります。動かし続けるものには、ほぼ必ず付けます。

--name webは名前付けです。付けないとDockerがvibrant_einsteinのような名前を勝手に付けます。以降のコマンドをすべてwebという名前で指定できるので、付けておくと後が楽になります。

-p 8080:80が、この演習でいちばん間違えやすいところです。左がパソコン側、右がコンテナ側。「パソコンの8080番に来た通信を、コンテナの80番へ渡す」という意味で、逆に書くと繋がりません。

返ってきた長い英数字がコンテナIDです。docker psで確認すると、STATUS が running、PORTS に 8080:80と出ています。ここまで来れば、ブラウザでlocalhost:8080を開けばnginxの画面が見える状態です。

-dで裏に回したので、画面には何も出てきません。動いているかどうかを知る手段が要ります。

docker logs webが最初の一手です。コンテナの中のプログラムが出力した内容が読めます。listening on port 80と出ていれば、nginxはちゃんと待ち受けています。

うまく動かないときも、まずここを見ます。設定ファイルの書き間違いも、必要なファイルが無いことも、たいていログに出ています。「起動したのにすぐ終わる」ときは、docker ps -aで見つけてからdocker logs——これが調査の型です。

docker top webでは、コンテナの中で動いているプロセスが見えます。nginxのマスタープロセスとワーカープロセスが並んでいます。

ここにコンテナの正体が現れています。コンテナの中のプロセスは、ホストから見れば普通のプロセスです。仮想マシンのように別のOSが丸ごと動いているわけではなく、隔離されているだけ——だからコンテナは数秒で起動します。

docker inspect webは、そのコンテナの設定をすべて表示するコマンドです。IDや元になったイメージ、いまの状態が読み取れます。

これが必要になる理由があります。ポートの公開も名前も、docker runを打った瞬間に固定されます。あとから変えることはできません。だから「このコンテナはどんなオプションで起動したのか」を後から知る手段が要るのです。

実際の出力は数百行になるので、実務では--formatで必要な項目だけを取り出します。

次にdocker cpで、手元のindex.htmlをコンテナの中に送り込みます。nginxが公開しているフォルダに置けば、ブラウザに映る内容が自分のページに変わります。

ただし、この方法は覚え書きにしないでください。docker cpで入れたファイルは、コンテナを作り直すと消えます。本来はDockerfileのCOPYで焼き込むか、-vで外のフォルダを繋ぎます。どちらも「作り直しても同じ結果になる」やり方です。手作業で中身を直した環境は、再現できません——これはDockerを使う意味そのものに関わる話です。

docker stop webで停止します。いきなり切るのではなく、まず「終わってください」という合図を送り、10秒待ってから強制終了します。この猶予のあいだに、コンテナの中のプログラムは書きかけのファイルを保存したり、接続を閉じたりできます。

止めた直後にdocker psを打つと、何も出てきません。ここで「消えた」と思うのが、Dockerを始めた人がまず引っかかる場所です。

docker ps -aを打ってください。-aを付けると、停止中のものも含めて全部が出ます。webはexitedという状態で、ちゃんと残っています。

コンテナは停止しても消えません。中のファイルもログもそのままです。だから落ちたコンテナのログを後から読める——さっき見たdocker logsが、失敗の調査に使える理由がこれです。

docker start webで再開します。停止する前の状態がそのまま戻ります。docker runとの違いがここで、runは毎回新しいコンテナを作り、startは既にあるものを動かし直します。何度もrunを打つと停止したコンテナが溜まっていくのは、この違いを知らないときに起こります。

最後は片付けです。順序に決まりがあります。

動いているコンテナは削除できません。まずdocker stop webで止め、それからdocker rm webで消します。

ここで何が失われるかを、はっきり意識してください。docker rmすると、そのコンテナの中で作ったファイルも、さっきdocker cpで送り込んだファイルも、全部消えます。コンテナは「イメージの上に載った書き込み層」で動いていて、削除するとその層ごと捨てられるからです。残したいデータは、あらかじめボリュームで外に置いておく必要があります。

次にdocker rmi nginxでイメージを消します。rmiはremove imageの略です。コンテナが残っているとイメージは消せません——だからコンテナが先、イメージが後、という順序になります。

最後にdocker ps -aとdocker imagesで確かめます。どちらも見出しだけ——ステップ1で見た、あの空の状態に戻りました。

これで完走です。取得 → 起動 → 確認 → 停止 → 削除。この一周を自分の手で回せたなら、Dockerの日常操作はもう扱えます。あとはDockerfileで自分のイメージを作る、Composeで複数のコンテナをまとめて動かす——どちらもこの一周の上に乗っているだけです。

ページ下の疑似ターミナルで、ここまでを最初から自分の手で通してみてください。読んで分かるのと打てるのは、別物です。

下は本物の疑似ターミナルです。まっさらな状態から始まるので、STEP1のコマンドから順に打って、マージまで辿り着いてください。読んで分かった気になるのと、自分で打てるのとは別物です。

詰まったら上のステップに戻って構いません。resetと打てば最初からやり直せます。