Iron.ioで運用中のDocker


今年の初め（2014年頃）に、各タスクをIronWorkerで独自のDockerコンテナー内で実行することにしました。 それ以来、クラウド内の独自のDockerコンテナ内で3億以上のプログラムを開始しています。

数ヶ月使用した後、Dockerに基づいてインフラストラクチャを構築する際に直面したいくつかの課題、それらを克服した方法、および価値がある理由をコミュニティと共有したいと思います。

IronWorkerは、開発者がインフラストラクチャの作成と保守を気にせずにタスクを計画、処理、およびスケーリングできるタスク実行サービスです。 3年以上前にサービスを開始したとき、すべての言語とパッケージを含む唯一のLXCコンテナを使用してタスクを開始しました。 Dockerを使用すると、一連のコンテナーを簡単に更新および管理できるようになりました。これにより、はるかに広範な言語環境とインストール済みパッケージを顧客に提供できます。

いくつかのバグに気づいたDockerバージョン0.7.4で作業を開始しました（最大の1つ-コンテナが適切に閉じられなかったため 、後で修正されました）。 ほぼすべてを克服し、Dockerがニーズを満たすだけでなく、期待をはるかに超えていることを徐々に発見し、インフラストラクチャ全体でDockerの使用範囲を拡大しました。 今日の経験を考えると、それは理にかなっています。

メリット

ここに、私たちが見たいくつかの利点のリストを示します。


数が少ない

イメージの更新とサポートが簡単

Dockerのgitアプローチは非常に強力であり、常に展開されている多数の環境を簡単に管理できます。また、イメージ管理システムにより、個々のイメージの詳細を微調整してディスク領域を節約できます。 すぐに更新される言語に対応できるようになりました。また、メディア処理専用に設計された新しいFFmpegスタックなどの特別な画像を提供することもできます。 現在、約15の異なるスタックがあり、このリストは急速に増加しています。

リソースの割り当てと分析

LXCコンテナーは、オペレーティングシステムレベルでの仮想化手法であり、コンテナーがコアをコア間で分割できるようにしますが、プロセッサー、メモリー、入出力デバイスなどの一定量のリソースの使用で各コンテナーを制限できるようにします。 Dockerは、REST API、バージョン管理システム、イメージの更新、さまざまなメトリックへの簡単なアクセスなど、他の多くの機能と同様にこれらの機能を提供します。 さらに、Dockerは、CoWファイルシステムを使用してデータを分離するより安全な方法をサポートしています 。 これは、タスクの一部としてファイルに加えられたすべての変更が個別に保存され、単一のコマンドでクリアできることを意味します。 LXCはこのような変更を追跡できません。

簡単なDockerfiles統合

私たちのチームは世界中に散らばっています。 シンプルなDockerfileを公開し、落ち着いて感じることができるという事実は、私たちが目を覚ますと、他の誰かがあなたとまったく同じ画像を収集できることを知っている-私たちと私たちの睡眠モードの大きな利益です。 また、クリーンなイメージを使用すると、展開とテストがはるかに高速になります。 私たちの開発サイクルはずっと速くなり、すべてのチームメンバーはずっと幸せになりました。


Dockerで構築されたカスタム環境

成長するコミュニティ

Dockerの更新は非常に頻繁に公開されます（Chromeよりも頻繁に更新されます）。 新しい機能の追加とバグの修正に対するコミュニティの関与の度合いは急速に高まっています。 画像のサポート、Docker自体の更新、Dockerと連携するための追加ツールの追加など、これらの問題に対処する優秀な人がたくさんいるので、その必要はありません。 Dockerコミュニティは非常に前向きであり、 Dockerコミュニティに参加することで多くのメリットがもたらされることがわかります。

Docker + CoreOS

私たちはまだ研究プロセスにありますが、DockerとCoreOSの組み合わせは、スタックの中で重要な位置を占めることを約束します。 Dockerは、安定したイメージ管理とコンテナー化を提供します。 CoreOSは、簡素化されたクラウドOS、分散管理、構成管理を提供します。 この組み合わせにより、問題をより論理的に分離し、現在よりも優れたインフラストラクチャスタックを実現できます。

欠点

特にスケーリングの場合、各サーバーテクノロジーは微調整が必​​要であり、Dockerも例外ではありません。 （1か月に約5,000万のタスクと500,000時間のプロセッサ時間を実行し、利用可能にしたイメージをすばやく更新するとします。）

大容量でDockerを使用するときに発生したいくつかの問題を以下に示します。


Dockerエラー-小さく修正可能

限定的な下位互換性

速いペースでの開発は確かに利点ですが、欠点もあります。 それらの1つは、下位互換性に制限があります。 ほとんどの場合、発生するのはコマンドライン構文とAPIメソッドの変更であるため、これは生産の観点からはそれほど重要な問題ではありません。

ただし、他のケースでは、これがパフォーマンスに影響を与えています。 たとえば、コンテナの起動後にDockerエラーが発生した場合、STDERRを分析し、エラーの種類に応じて対応します（たとえば、タスクを再度実行しようとします）。 残念ながら、エラー出力形式はバージョンごとに変更されたため、その場でデバッグを行うことにしました。

これらの問題を解決するのは比較的簡単ですが、これはすべての更新を数回チェックする必要があることを意味し、多数の世界にリリースするまであなたはまだあいまいです。 数か月前にバージョン0.7.4で開始し、最近システムをバージョン1.2.0に更新し、この分野で大きな進歩が見られたことに注意してください。

限られたツールとライブラリ

Dockerには4か月前に安定したリリースがありましたが、Docker用に作成されたツールの多くはまだ不安定なままです。 Dockerシステムで多数のツールを使用することは、大きなオーバーヘッドの採用も意味します。 新しい機能を考慮してエラーを修正するために、チームの誰かがすべてを最新の状態に保ち、何度も調整する必要があります。 ただし、Docker用に作成された多くのツールが気に入っており、これらの戦いに勝ったのが誰なのか待ちきれません（インフラストラクチャ管理を見て）。 特に関心があるのは、etcd、fleet、kubernetesです。

困難を乗り越える

私たちの経験をもう少し深く明らかにするために、私たちが遭遇した問題とその解決策のいくつかを以下に示します。


デバッグセッションからの抜粋

このリストは、IronWorkerの主要な開発者であり、インフラストラクチャ管理のディレクターであるRoman Kononovと、Dockerでの作業のデバッグと最適化で重要な役割を果たすSam Wardによって提供されました。

Dockerまたはその他のシステムの問題に関連するエラーになると、ユーザーに影響を与えることなくタスクを自動的に再処理できることに注意してください（再処理タスク-組み込みプラットフォーム機能）。

長時間の取り外しプロセス

コンテナの取り外しに時間がかかる問題の解決

コンテナの削除には時間がかかりすぎ、多くの読み取り/書き込み操作も必要です。 これにより、大幅な遅延が発生し、システムの脆弱性が明らかになりました。 使用可能なコアの数を増やす必要がありましたが、これは必要ありませんでした。

devicemapper（Dockerファイルシステムドライバー）を調べて調査した結果、特別なオプション `--storage-opt dm.blkdiscard = false`が見つかりました。 このオプションは、コンテナを削除するときに、重いディスク操作をスキップするようにDockerに指示します。これにより、コンテナの切断プロセスが大幅に高速化されます。 それ以来、問題は解決されました。

マウントできないボリューム

Dockerがボリュームを適切にアンマウントしなかったため、コンテナーは正しくシャットダウンしませんでした。 このため、タスクが完了した後でも、コンテナはノンストップで機能しました。 別の方法は、標準スクリプトのセットを使用してボリュームをアンマウントし、フォルダーを明示的に削除することです。 幸いなことに、Docker v0.7.6を使用したのはかなり前のことです。 このアンマウントの問題はDockerバージョン0.9.0で解決されたため、この長いスクリプトを削除しました。


スタック使用量の分布

メモリ制限の切り替え

Dockerリリースの1つで、メモリを制限する機能が突然追加され、LXCオプションが削除されました。 この結果、ワークフローの一部がメモリ制限を超え、システム全体が応答しなくなりました。 サポートされていないオプションを使用していても、Dockerが破損することはないため、これには驚きました。 それを修正するのは難しくありませんでした-Dockerでメモリ制限を適用します-しかし、すべて同じように、変更は驚きました。

今後の計画

既にお気付きのように、私たちはDockerに非常に積極的に投資し、これを毎日続けています。 IronWorkerでカスタムコードを実行するためのコンテナとして使用することに加えて、私たちはビジネスの他の多くの領域にそれを導入する過程にあります。

これらの領域は次のとおりです。

鉄工バックエンド

Dockerをタスクのコンテナーとして使用することに加えて、作業タスクを制御および実行する各サーバーの処理管理ツールとしてDockerを実装しています。 （各アーティストのメインタスクは、キューからタスクを取得し、Dockerを適切な環境にロードし、タスクを実行して制御し、タスクの完了後、環境をクリアします。）同じ車。 IronWorkerインフラストラクチャ全体をDockerコンテナに移動すると、CoreOSでそれらを簡単に実行できます。

IronWorker、IronMQ、およびIronCache API

チューニングとデプロイを好まない他の開発チームと違いはありません。 したがって、すべてのサービスをDockerコンテナーにパックして、シンプルで予測可能な作業環境を作成できることを非常に嬉しく思います。 サーバーを構成する必要はなくなりました。 必要なのは、Dockerコンテナを実行できるサーバーだけです。 また、ビルドサーバー（特定の環境でソフトウェア製品のリリースをビルドするサーバー）をDockerコンテナーに置き換えていることにも注意してください。 ここでの利点は、柔軟性が高く、スタックがシンプルで信頼性が高いことです。 連絡を取り合いましょう。

ワーカーの組み立てと読み込み

また、Dockerコンテナを使用してIronWorkerでタスクを作成およびロードする実験も行っています。 ここでの大きな利点は、特定のタスクのロードプロセスとワークプロセスをカスタマイズし、ロードしてから実行およびスケーリングする便利な方法をユーザーに提供することです。 ここでのもう1つの利点は、ユーザーがサービスと同じ環境でワーカーをローカルでテストできることです。

オンプレミスビルドを実装する

IronMQ Enterpriseの最新バージョンの主要な配布方法としてDockerを使用すると、作業が簡素化され、事実上あらゆるクラウド環境にデプロイするためのシンプルで汎用性の高い方法が提供されます。 クラウドで実行するサービスに加えて、すべてのクライアントにはDockerコンテナーを実行できるサーバーが必要であり、テストまたは運用環境で比較的簡単にマルチサーバークラウドサービスを取得できます。

生産以降

テクノロジーの進化（docker.comから入手）

過去1年半にわたって、ソロモンハイクスがGoSFミートアップでデモバージョンを紹介して以来、Dockerは大きな進歩を遂げました。 バージョン1.0のリリース以来、Dockerは非常に安定しており、実稼働の準備が整っていることが実証されています。

Dockerの開発は非常に印象的です。 上記のリストからわかるように、新しい機会を楽しみにしていますが、現在の機能にも満足しています。

Dockerベースのインフラストラクチャ管理ツールを入手できた場合のみ。