CI またはテスト環境に Docker-in-Docker を使用する前によく考えてください。

Docker-in-Docker は、コンテナー自体内で実行され、コンテナー イメージを構築する仮想化された Docker デーモン環境です。 Docker-in-Docker を作成する主な目的は、Docker 自体の開発を支援することでした。 多くの人が Jenkins CI を実行するためにこれを使用しています。 これは最初は正常なことのように見えますが、その後問題が発生します。この問題は、Jenkins CI コンテナーに Docker をインストールすることで回避できます。 この記事では、これを行う方法について説明します。 詳細なしで最終的な解決策に興味がある場合は、記事の最後のセクション「問題の解決」だけを読んでください。

ドッカーインドッカー: 「良いです」

XNUMX 年以上前、私は Docker を導入しました フラグ –特権を持って書いた dind の最初のバージョン。 目標は、コア チームが Docker をより迅速に開発できるようにすることでした。 Docker-in-Docker が登場する前は、一般的な開発サイクルは次のようになっていました。

• ハッキングハック。
• 建てる;
• 実行中の Docker デーモンを停止します。
• 新しい Docker デーモンを起動します。
• テスト
• サイクルを繰り返します。

美しく再現可能なアセンブリ (つまり、コンテナー内) を作成したい場合は、さらに複雑になります。

• ハッキングハック。
• Docker の動作バージョンが実行されていることを確認してください。
• 古い Docker を使用して新しい Docker を構築します。
• Docker デーモンを停止します。
• 新しい Docker デーモンを開始します。
• テスト;
• 新しい Docker デーモンを停止します。
• 繰り返す。

Docker-in-Docker の出現により、プロセスはよりシンプルになりました。

• ハッキングハック。
• 組み立てと打ち上げを XNUMX つの段階で行います。
• サイクルを繰り返します。

こっちの方がずっと良くないですか？

Docker-in-Docker: 「悪い」

しかし、一般に信じられていることに反して、Docker-in-Docker は 100% スター、ポニー、ユニコーンではありません。 私が言いたいのは、開発者が認識する必要がある問題がいくつかあるということです。

そのうちの XNUMX つは、AppArmor や SELinux などの LSM (Linux セキュリティ モジュール) に関するものです。コンテナの実行時に、「内部 Docker」が「外部 Docker」と競合または混乱させるセキュリティ プロファイルを適用しようとする可能性があります。 これは、-privileged フラグの元の実装をマージしようとするときに解決するのが最も難しい問題です。 私の変更は機能し、私の Debian マシンと Ubuntu テスト VM ではすべてのテストが成功しましたが、Michael Crosby のマシン (私の記憶では、彼は Fedora を使用していました) ではクラッシュして燃えてしまいます。 問題の正確な原因は思い出せませんが、Mike が SELINUX=enforce を使用する賢い人 (私は AppArmor を使用しました) であり、私の変更が SELinux プロファイルを考慮していなかったことが原因かもしれません。

ドッカー・イン・ドッカー: 「悪」

4 番目の問題は、Docker ストレージ ドライバーに関するものです。 Docker-in-Docker を実行すると、外部 Docker は通常のファイル システム (EXTXNUMX、BTRFS、その他のファイル システム) 上で実行され、内部 Docker はコピー オン ライト システム (AUFS、BTRFS、デバイス マッパー) 上で実行されます。など)。外部 Docker を使用するように構成されている内容に応じて異なります)。 これにより、機能しない組み合わせが多数作成されます。 たとえば、AUFS の上で AUFS を実行することはできません。

BTRFS の上で BTRFS を実行すると、最初は機能するはずですが、ネストされたサブボリュームが存在すると、親サブボリュームの削除に失敗します。 Device Mapper モジュールには名前空間がないため、複数の Docker インスタンスが同じマシン上で実行されている場合、すべてのインスタンスが相互に、およびコンテナ バックアップ デバイス上のイメージを参照 (および影響) することができます。 これは悪いです。

これらの問題の多くを解決するための回避策があります。 たとえば、内部 Docker で AUFS を使用したい場合は、/var/lib/docker フォルダーをボリュームに変えるだけで問題ありません。 Docker は、複数の Docker 呼び出しが同じマシン上で実行されている場合に、それらが互いにステップしないよう、デバイス マッパーのターゲット名にいくつかのベース名前空間を追加しました。

ただし、これらのことから分かるように、このようなセットアップはまったく簡単ではありません。 物品 GitHub の dind リポジトリにあります。

Docker-in-Docker: 状況はさらに悪化します

ビルドキャッシュについてはどうですか? これも非常に難しい場合があります。 「Docker-in-Docker を実行している場合、すべてを内部 Docker に戻す代わりに、ホスト上でホストされているイメージを使用するにはどうすればよいですか?」とよく質問されます。

進取的な人々の中には、/var/lib/docker をホストから Docker-in-Docker コンテナーにバインドしようとした人もいます。 場合によっては、/var/lib/docker を複数のコンテナーと共有します。

データを破損したいですか? なぜなら、これはまさにデータにダメージを与えるものだからです。

Docker デーモンは明らかに /var/lib/docker に排他的にアクセスできるように設計されています。 このフォルダー内にある Docker ファイルには、他に何も「触れたり、突き刺したり、突き刺したり」してはなりません。

なぜそうなるのでしょうか? これは、dotCloud の開発中に学んだ最も難しい教訓の XNUMX つであるためです。 dotCloud コンテナ エンジンは、複数のプロセスが /var/lib/dotcloud に同時にアクセスすることで実行されました。 (インプレース編集ではなく) アトミックなファイル置換、勧告ロックや必須ロックをコードに追加するなどの狡猾なトリック、SQLite や BDB などの安全なシステムを使用したその他の実験は、常に機能するとは限りませんでした。 最終的に Docker となるコンテナ エンジンを再設計していたとき、設計上の大きな決定事項の XNUMX つは、すべての同時実行性のナンセンスを排除するために、すべてのコンテナ操作を XNUMX つのデーモンに統合することでした。

誤解しないでください。複数のプロセスと最新の並列制御を使用して、優れた、信頼性が高く、高速なものを作成することは完全に可能です。 しかし、Docker を唯一のプレーヤーとして使用してコードを作成および保守する方がシンプルで簡単であると私たちは考えています。

これは、複数の Docker インスタンス間で /var/lib/docker ディレクトリを共有すると問題が発生することを意味します。 もちろん、これは特にテストの初期段階では機能します。 「聞いてください、お母さん、私は ubuntu を Docker として実行できます!」 しかし、XNUMX つの異なるインスタンスから同じ画像を取得するなど、より複雑なことを試してみると、世界が燃え上がるのがわかります。

これは、CI システムがビルドとリビルドを実行する場合、Docker-in-Docker コンテナを再起動するたびに、そのキャッシュに核が投下される危険があることを意味します。 これはまったくクールではありません!

ソリューション

一歩下がってみましょう。 本当に Docker-in-Docker が必要ですか? それとも、CI システム自体がコンテナー内にある間に Docker を実行して、CI システムからコンテナーとイメージを構築して実行できるようにしたいだけですか?

きっとほとんどの人は後者のオプションを望んでいるでしょう。つまり、Jenkins のような CI システムでコンテナを実行できるようにしたいということです。 これを行う最も簡単な方法は、単純に Docker ソケットを CI コンテナーに挿入し、それを -v フラグに関連付けることです。

簡単に言うと、CI コンテナー (Jenkins など) を実行するときに、Docker-in-Docker と一緒に何かをハッキングするのではなく、次の行で開始します。

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

このコンテナは Docker ソケットにアクセスできるようになり、コンテナを実行できるようになります。 ただし、「子」コンテナを実行する代わりに、「兄弟」コンテナを起動します。

公式の Docker イメージ (Docker バイナリを含む) を使用してこれを試してください。

docker run -v /var/run/docker.sock:/var/run/docker.sock 
           -ti docker

これは Docker-in-Docker のように見え、動作しますが、Docker-in-Docker ではありません。このコンテナが追加のコンテナを作成するとき、それらはトップレベルの Docker に作成されます。 ネストによる副作用は発生せず、アセンブリ キャッシュは複数の呼び出し間で共有されます。

注: この記事の以前のバージョンでは、Docker バイナリをホストからコンテナーにリンクすることが推奨されていました。 Docker エンジンが静的ライブラリまたは静的ライブラリに近いライブラリをカバーしなくなったため、これは信頼できなくなりました。

したがって、Jenkins CI から Docker を使用したい場合は、2 つのオプションがあります。
基本的なイメージ パッケージ システム (つまり、イメージが Debian に基づいている場合は、.deb パッケージを使用します)、Docker API を使用して Docker CLI をインストールします。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com