Docker 入門

一。目標

Bring Portability, Security, And Efficiency To Your Traditional Applications Without Changing Application Code

アプリケーションコードを変更せずに、従来のアプリケーションに可移植性、セキュリティ、コスト効率をもたらします

二。特性

Docker は、アプリケーションをパッケージ化して緩やかに隔離された環境（コンテナと呼ばれる）で実行する機能と、コンテナのライフサイクルを管理するためのツールおよびプラットフォームを提供します

P.S.Docker は Go で書かれています

ハイブリッドクラウドの可移植性

アプリケーションのソースコードとその依存関係をすべて軽量な独立したコンテナにパッケージ化します。コンテナはworks on my machineという問題を解決します。図の通りです：

（画像は Digging Into the "Works On My Machine" Problem より）

これにより、環境間の差異を気にすることなく、アプリケーションを新しい環境で正常に実行できます。パッケージ化後は、シンプルな Docker コマンド 1 つで、コンテナをあらゆる環境に簡単にデプロイできます。クラウド移行を迅速に開始し、技術更新サイクルを加速したり、（パブリック）クラウドへの急な移行を可能にします

アプリケーションのセキュリティ向上

既存のアプリケーションを Docker コンテナにパッケージ化すると、ソースコードを変更せずに Docker 組み込みのセキュリティ機能を利用できます。Docker はコンテナの分離を提供し、制限的な設定を通じてアプリケーションの攻撃対象領域を削減し、適切なリソース割り当てを設定してホストリソースを節約できます

さらに、Docker はコンテナアプリケーションの作成、スキャン、署名、共有、デプロイのための安全なサプライチェーンを提供します。たとえばセキュリティスキャンは、すべての依存関係の既知の脆弱性リストを提供し、定期的なレポートで Docker 管理者に既知の公開脆弱性の修正を通知します。コンテナのデジタル署名も可能で、Docker クラスタ検証を有効にすることでアプリケーションの安全な転送を保証します

CapEx（資本的支出）と OpEx（運営コスト）のメリット

Docker はリソースのプロビジョニング、デプロイ、更新などの操作を簡素化し、Docker コンテナへの移行によりデプロイ時間を節約できます

構造的には、Docker コンテナは基盤となるオペレーティングシステムカーネルを共有するため、リソース消費は仮想マシンよりも少なく、比較的軽量です。コンテナ分離によりアプリケーションの競合を防止できるため、IT 管理者は既存のインフラストラクチャの負荷密度を向上させ、既存の仮想マシンとサーバーの利用率を最適化できます

P.S.ハイパーバイザーの追加オーバーヘッドは不要で、ホストのカーネル内で直接実行されるため、よりリソースを節約し、仮想マシンよりも軽量です。仮想マシン環境で Docker を実行することも可能です

DevOps

DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

ソフトウェア開発と運用（テスト、オペレーション）を統一し、製品リリースサイクルをさらに短縮し、効率を向上させることを目指すソフトウェアエンジニアリングの文化および実践です。同時に、自動化と監視を通じて信頼性を保証します

コンテナ技術は DevOps における重要な一环です。下の図の通りです：

（画像は Red Hat OpenShift V3 Overview and Deep Dive より）

前述の通り、ソースコードと依存関係をコンテナにパッケージ化することで、リソースのプロビジョニング、デプロイ、更新などの一連の運用操作を簡素化し、You build it, you run it を実現し、開発からリリースまでの不確実な环节を削減できます

P.S.DevOps に関する詳細情報は、DevOps の前世今生をご覧ください

三。構造と概念

C/S アーキテクチャの一種で、Client がコマンドを送信し、Server（デーモン）がそれを受け取って対応する操作を実行し、コンテナとイメージを管理します。Server は Client と同じ物理マシン上にある場合もあれば、別のリモートマシン上にある場合もあり、REST API を通じて通信します（UNIX socket によるプロセス間通信か、ネットワークによるリモート通信のいずれかです）

Docker デーモン

デーモン（dockerd）は Docker API リクエストをリッスンし、イメージ（image）、コンテナ（container）、ネットワーク、ディレクトリ（volume、ファイルシステム上の概念、巻）などの Docker オブジェクトを管理します。さらに、デーモンは他のデーモンと通信して Docker サービスを管理することもできます

Docker クライアント

クライアント（docker）は、Docker ユーザーが Docker と対話するための基本的な方法です。たとえば docker run コマンドを使用すると、クライアントはこれらのコマンドを dockerd に送信して実行します。1 つの client は複数のデーモンと通信できます

Docker レジストリ

npm registry に似ており、Docker registry はパブリック Docker イメージを保存するために使用され、デフォルトでは Docker Hub でイメージを検索します

docker pull または docker run コマンドを実行すると、設定された registry から必要なイメージを取得します。docker push はローカルイメージを設定された registry に公開するために使用されます

また、npm package とは異なり、パブリックイメージ仍然是イメージレベル（ブラックボックス）であり、npm package のようにソースコードがすべて公開されているわけではありません。そのため、Docker は有料エコシステムDocker store を発展させました。信頼できるモジュール/アプリケーションパッケージを直接購入でき、アップグレードメンテナンス（イメージ更新）などのサービスも受けられます。非常に興味深いです

P.S.たとえば Foopipes は有料のイメージです

Docker オブジェクト

イメージ（image）、コンテナ（container）、サービス（service）、ネットワーク、volume（ディレクトリ）、プラグインなどを含みます。よく扱うのはイメージとコンテナです

イメージ

イメージは読み取り専用のテンプレートで、Docker コンテナを作成するための指示が付いています

3 つの特徴があります：

可移植性：registry に公開したり、圧縮ファイルとして保存したりできます
階層化：イメージを生成するステップは（イメージに）レイヤーを追加することであり、これにより最後の数ステップを除き、ほとんどのイメージは親レイヤーを共有してディスク使用量を削減できます
静的（読み取り専用）：コンテンツは不変であり、新しいイメージを作成しない限り変更できません

一般的には、別のイメージをベースに追加のカスタマイズを行って新しいイメージを作成します。たとえば ubuntu イメージをベースにイメージを構築し、Apache と自分のアプリケーションをインストールし、必要な Apache 設定項目を指定できます

独自のイメージを作成するには Dockerfile を作成し、シンプルな構文で作成および実行に必要なステップを定義します。Dockerfile の各指示はイメージ内にレイヤーを作成します。Dockerfile を変更してイメージを再構築する際、変更されたレイヤーのみを構築します。他の仮想化技術と比較して、より軽量で高速です

コンテナ

コンテナはイメージの実行可能インスタンスです

コンテナにも 3 つの特徴があります：

実行時の概念：プロセスが置かれる環境
可変（書き込み可能）：実質的には短期保存の一種です
階層化：イメージはコンテナの「レイヤー」です

Docker API または CLI を通じてコンテナを作成、起動、停止、移動、削除できます。コンテナを複数のネットワークに接続し、ストレージを添付することもでき、コンテナの現在の状態に基づいて新しいイメージを作成することもできます

コンテナはそのイメージと、作成および起動時に指定された設定項目によって定義されます。コンテナが削除されると、永続化されていないすべての状態変更は失われます

例：

docker run -i -t ubuntu /bin/bash

このコマンドを実行すると、6 つのことが発生します：

ローカルに ubuntu イメージがない場合、registry からプルします（手動で docker pull ubuntu を実行するのと同じです）
新しいコンテナを作成します（手動で docker create を実行するのと同じです）
コンテナに読み書き可能なファイルシステムを割り当て、最終レイヤーとして、実行中のコンテナがローカルファイルを操作できるようにします
ネットワークインターフェースを作成し、コンテナをデフォルトネットワークに接続します（ネットワークオプションを指定しない場合）。これによりコンテナに IP アドレスが割り当てられ、デフォルトではコンテナはホストのネットワーク接続を通じて外部ネットワークに接続できます
コンテナを起動し、/bin/bash を実行します。コンテナは対話モード（-i）で実行され、ターミナルに接続（-t）されます。その後、キーボードから入力し、出力をターミナルに記録できます
exit を入力して /bin/bash コマンドを終了すると、コンテナは停止しますが、削除はされません。再起動または削除できます

サービス

サービスは、複数の Docker デーモン間でコンテナを拡張することを可能にします。まるで複数の管理者と労働者がクラスターとして協働するかのように。クラスターの各メンバーは Docker デーモンであり、すべてのデーモンは Docker API を通じて通信します。サービスは必要な状態を定義することを可能にします。たとえば、特定の時間にコンテナが提供する必要があるレプリカ数など。デフォルトでは、サービスはすべてのワークノード間でロードバランシングされます。ユーザーにとって、Docker サービスは単一のアプリケーションのように見えます

基盤技術

Docker は実装上、いくつかの Linux カーネル機能を利用しています：

Namespaces による独立したワークスペース（container）の実現
Control groups によるコンテナ利用可能リソースの制限
Union file systems によるレイヤー（layer）の実現
Container format によるコンテナ管理（上記 3 つの機能を総合的に利用し、抽象化した概念）

四。例

環境

cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

インストールと有効化

# インストール
yum install docker
# 起動
sudo service docker start
# 起動時自動起動
sudo chkconfig docker on

試用

CentOS イメージをベースに新しいイメージを作成します：

# CentOS イメージを取得
docker pull centos
# イメージの存在を確認
docker images centos

正常であれば、以下のような出力が得られ、ローカルに最新の CentOS イメージが存在することが示されます：

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
docker.io/centos    latest              3fa822599e10        3 weeks ago         203.5 MB

Docker コンテナを実行します

docker run -i -t centos /bin/bash

新規作成されたターミナル（centos コンテナ環境内）でやりたいことを実行します：

# nvm をインストール
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
# 環境変数を更新
source ~/.bashrc
# node v4.6.2 をインストール
nvm install 4.6.2
# グローバルモジュールをインストール
npm install -g ionic @1.7.16
npm install -g cordova @6.2.0
# ... 一通りの操作を実行
# 対話型ターミナルを終了
exit

P.S.なぜここでの node バージョンとグローバルモジュールのバージョンが固定されているのか？古いおもちゃがあり、この環境でしか実行できないからです。Docker はこのようなシナリオに非常に適しています。そうでなければ、他人のローカル環境で実行するのは困難です。したがって、環境に特別な要件があるオープンソースプロジェクトは、Docker イメージを公開するか、Dockerfile を同梱することをお勧めします

最後に現在の状態からイメージを作成します：

# 先ほど変更したコンテナの ID を確認
docker ps -a -q -l
# 変更をコミットして新しいイメージを作成
docker commit 887a377fa369 ayqy/rsshelper

これにより、centos イメージをベースにした ayqy/rsshelper カスタムイメージがローカルに作成されます：

# 新規生成されたイメージを確認
docker images ayqy/rsshelper
# 一键で RSSHelper 実行に必要な環境に入る
docker run -it ayqy/rsshelper /bin/bash
# 環境を検証
node -v
# v4.6.2 正解

基本的な使い方はこの通りで、実際のアプリケーションでは Dockerfile を通じてカスタムイメージを作成するのが合理的です

Dockerfile

まず 1 つ作成します：

mkdir -p ~/projs/docker/rsshelper/
vi ~/projs/docker/rsshelper/Dockerfile

内容を編集します：

FROM centos:latest
MAINTAINER ayqy "nwujiajie @163.com"

ENV NODE_VERSION 4.6.2

RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash \
&& source ~/.bashrc \
&& nvm install "$NODE_VERSION" \
&& nvm alias default "$NODE_VERSION" \
&& nvm use default \
&& nvm install -g ionic @1.7.16 cordova @6.2.0

注意：

1 行目の FROM 指示は必須で、ソースイメージを指定するために使用され、指定されたイメージはローカルに存在している必要があります。FROM は docker run に相当します
RUN 指示はデフォルトで /bin/bash を使用し、各 RUN は新しい bash プロセスを開始するため、環境変数を共有するには && で接続する必要があり、複数の RUN 指示を使用しません

イメージを作成します：

docker build -t="ayqy/rsshelper_image" ~/projs/docker/rsshelper/
# 作成完了後に新しいイメージを確認
docker images ayqy/rsshelper_image

注意：いずれかのコマンドの戻り値が 0 でない場合、イメージは構築に失敗します

P.S.Dockerfile に関する詳細情報は、快速掌握 dockerfile をご覧ください

常用コマンド

# registry から指定イメージをプル
docker pull fedora
# ローカルイメージを確認
docker images
# Dockerfile からイメージを作成、カレントディレクトリに Dockerfile が必要
docker build -t myimage .
# 対話モードでコンテナを実行
docker run -it myimage
# 実行中のコンテナを確認
docker ps -l
# コンテナの実行を停止（id は docker ps 出力から確認）
docker kill <id>
# コンテナを削除
docker rm <id>

P.S.docker help でより多くの Docker クライアントコマンドを確認できます

五。アプリケーションシナリオ

コンテナ技術はローカル開発環境と実際の本番環境の差異を排除し、CI/CD ワークフローの保証を簡素化します：

コンテナでアプリケーションを開発し、依存関係を管理
コンテナをデプロイおよびテストの基本単位として使用
本番環境にデプロイ、本番環境がどのようなものであっても（ローカルデータセンター、クラウドプロバイダー、またはそれらのハイブリッド）

いくつかのアプリケーションシナリオ例：

デモ共有

開発デモをコンテナにパッケージ化して共有し、他人は自分のローカル環境ですぐに実行できます

自動化テスト

開発環境のアプリケーションをテスト環境にデプロイし、手動テスト/自動化テストを実行します。環境の差異を気にする必要はありません

迅速な再デプロイ/公開

開発環境でバグを修正した後、テスト環境に再デプロイしてテスト検証を実行します。テスト通過後、最新イメージを本番環境にデプロイします

リソース利用率の最適化

各アプリケーションのリソース割り当てを制限するか、Docker コンテナを仮想マシンの代わりに使用して、リソース利用率をさらに向上させます

参考資料

Docker overview
A beginners guide to Docker：正確で包括的な入門ガイド
Modernize Traditional Applications with Docker Enterprise Edition
What is Docker?