docker実践入門の5

イメージの派生

上記の例では、アプリケーションが変更された場合、再buildが必要になります.問題は再buildの場合、前のコマンドの山を1回走る必要があります.特にソフトウェアのインストールが遅いので、不要な繰り返し作業です.実際にはアプリケーションを変更しただけです.そのため、より機知的な方法はこのイメージを2つのイメージに分けることです.1つはpython 3ベース環境です.一つはアプリケーションイメージです.
python 3環境のDockerfileを先に:

FROM alpine
MAINTAINER raptor
COPY repositories /etc/apk/
RUN apk update \
    && apk add python3 curl \
    && curl -O https://bootstrap.pypa.io/get-pip.py \
    && python3 get-pip.py \
    && rm get-pip.py

これはpython 3ベースimageです.

docker build -t python3 .

次はアプリケーションDockerfileです.

FROM python3
MAINTAINER raptor
EXPOSE 5000
RUN mkdir /var/app
COPY app /var/app/
WORKDIR /var/app/
RUN pip3 install -r requirements.txt
CMD python3 start.py

次に、アプリケーションイメージを作成します.

docker build -t app1 .

これにより、後でアプリケーションを変更するにはbuildの2番目のイメージだけが必要になります.ただし、依存パッケージのインストールも遅いので、アプリケーションのインフラストラクチャとしてimageを追加することも考えられます.

イメージのラベル

imageが階層化されると、新しい問題が発生します.例えば、2つのアプリケーションAとBを3層のimageで配置し、最下層はosimageで、py 3 imageで、それから2つのアプリケーション:Aimage、Bimageです.
最初はいつも簡単で、順番に一つ一つbuildすればいいです.しかし、しばらくしてから、例えばBが修正したり、新しい依存パッケージが追加されたりすると、再build py 3 imageが必要になりますが、Aimageはpy 3 imageにも依存しているので、直接buildを再構築できるとは限りません(例えばAアプリケーションは新しい依存パッケージと互換性がないところがあり、Aアプリケーションがいくつか修正してから切る必要があるかもしれません)、py 3 image 2を1つ作成して、新しいBimageにpy 3 image 2に依存させるしかありません.では、これからos層も変わったら?もう一つosimage 2をしますか?階層的な意味は何ですか?もし2つのアプリケーションだけでなく、10数個のアプリケーションがあれば?それは面倒で死ぬのではないでしょうか.
だからtag(ラベル)が必要です
tagはある意味でバージョン番号に相当し、latestは特殊なtagであり、build imageでtagを指定しない場合、デフォルトはこれであり、その利点は常に最新のバージョンに対応することである.
tagを指定しない場合、buildごとに同じ名前のimageが1つずつ上書きされます.ただし、このimageがcontainerまたは派生imageとして実行されている場合は、実際に上書きされません.古いバージョンは表示されず、削除とマークされます.他の参照がなくなると、実際に削除されます.
依然として簡単なABの2つの応用の情況を例にとります:
これでbuildはbaseimageになり、AimageとBimageが派生します.次に,このときAアプリケーションに新たな依存が必要であると仮定してbaseimageを修正したが,Bimageは必要なく,しばらくアップグレードに追随したくない場合は,このようにすることができる.

docker tag baseimage baseimage:1

すなわち、バージョン番号1のbaseimageを生成します.
注意、この操作はラベルを打つだけで、2つのimageは生成されません.imagesを見ると、IDが同じであることがわかります.

docker images

このとき修正したDockerfileで再ビルド:

docker build -t baseimage .

新しいbaseimage:latestが生成され、両者のIDが異なります.AアプリケーションのDockerfileでは、この文を保持する限り、latestに依存します.

FROM baseimage

Bアプリケーションは、再buildを1回行うだけで、同じように新しいlatestに更新できます.latestに更新したくない場合は、Dockerfileを変更して、次のように変更することもできます.

FROM baseimage:1

古いバージョンのbuildを使用できます.
以上の方法ではbuildの新版の前に旧版にラベルを付けるのですが、実際にはbuildと同時に新版にラベルを付けるのがもっと良い方法で、この時点以降に生成される派生イメージのデフォルトはこのバージョンのbaseであることがよくわかります.