Dockerが（ほぼ）不可能を達成するのにどのように役立ったか

Iron.ioの作業を開始してから、新しいLinuxランタイムとパッケージに関するIronWorkerコンテナーを最新の状態に保つ問題を解決しようとしています。 IronWorkerは、過去2年間にわたって同じランタイム環境を変更せずに使用しています。 これまでのところ、数週間前、私たちは実稼働環境でプログラミング言語のさまざまな環境をリリースしていませんでした。



サービスの作成以来、Ruby、Python、PHP、Java、.NET、その他の言語、ImageMagick、SoXなどのライブラリなど、一連の言語環境とバイナリパッケージを含むコンテナを1つだけ使用しました。



このコンテナとその使用戦略は、Ruby 1.9.1、Node 0.8、Mono 2、およびデフォルトでスタックで使用されていた古いバージョンのその他の言語と同様に、時代遅れになり始めました。 時間が経つにつれて、人々は新しいものを使用し始めるにつれて問題はさらに深刻になりましたが、古いバージョンの言語で動作するようにコードを変更することを余儀なくされました。

1つのLXCコンテナーに限定

IronWorkerはLXCコンテナーを使用して、タスクを実行しながらリソースを分離し、セキュリティを提供します。 LXCはパフォーマンスコンポーネントとしてはうまく機能しましたが、タスクを処理するために必要なあらゆる種類の環境との統合に関しては時々クラッシュしました。 ランタイム環境の作成に関しては、行き詰まりました。 一方では、既存のコンテナのバージョンを更新することはできません。さもないと、毎日実行される100万以上のタスクが破壊される危険があります。 （サービスの開始時に一度試してみましたが、良い結果にはなりませんでした）



また、オペレーティングシステムとライブラリの完全なコピー（つまり、画像ごとに〜2 GB）が含まれているため、異なるバージョンの言語でさまざまなLXCコンテナーを保存できませんでした。 実際、これはプロセスが永遠に続くHerokuなどのPaaS環境では問題なく機能し、プロセスを開始する前に適切なコンテナーを取得できます。 このような状況では、各クライアントに大きなユーザー画像がありますが、IronWorkerの場合、すべてが異なります。



IronWorkerは、ユーザーがタスクをキューに追加する大規模なマルチユーザータスク処理システムであり、これらのタスクは数千のハンドラーで実行されます。 バックグラウンドで実行する、スケジュールされたタスクを起動する、トランザクションとメッセージフローを継続的に処理する、または多数のコアで並列処理を実行することにより、メイン実行スレッドをオフロードするために使用できます。 利点は、ユーザーがオンデマンドで処理すると同時に、非常に大きな同時実行性を労力なしで処理できることです。



内部では、サービスは次のように機能します。一連のキューからタスクを受け取り、特定のVMにランタイムをインストールし、タスクコードをダウンロードしてからプロセスを開始します。 このサービスの本質は、すべての顧客がすべてのマシンを常に使用していることを意味します。 マシンを特定のアプリケーションまたは顧客に長期間割り当てません。 原則として、タスクは長時間実行されません。 数秒または数分で動作するものもあり、最大実行時間は60分に制限されています。



LXCは正常に機能しましたが、後方互換性を損なうことなく、異常な量のディスク領域を使用せずに、既存のコンテナーに何かを更新または追加する方法を考えました。 私たちの選択肢はかなり限られているように見えたため、決定を先送りしました。

...そしてDockerが来ました

Dockerについて最初に聞いたのは1年前です。 GoSF MeetUpとDockerの作成者であるSolomon Heiksの組織化を支援し、2013年3月のカンファレンスに参加し、Goで書かれた新しいDockerプロジェクトのデモを行いました。 実際、彼はその日にそれを発表しました。これは誰かが彼を見たのは初めてでした。



デモは素晴らしく、聴衆の中の100人以上の開発者が彼と彼のチームが行ったことに感銘を受けました。 （そしてすぐに、彼のコメントの1つが証言するように、ソロモンはShame Driven Developmentと呼ばれる新しい開発方法論を始めました）



「残念ながら、それはあまりにも粗野なものでした」と前日、「プロジェクトの生産準備はできていませんでしたが、本当に賞賛に値するものでした。」





2013 OpenStack SummitでのSolomon HykesとTravis Reader。



1か月後、ポートランドで開催されたOpenStack SummitでSolomonと会い、協力してDockerを使用して問題を解決する方法を確認しました。 （私は1つの会議にしか行かないと思っていましたが、代わりにSolomonや他の開発者との作業に多くの時間を費やしました）。

私はDockerでプレイしましたが、ソロモンは彼が何ができるか、そしてそれがどのように機能するかを理解するのを助けました。 これは単なる良いプロジェクトではなく、うまく設計された方法で難しいタスクを解決しました。 そして、少なくとも私の観点からすれば、彼が囲wasで書かれた先駆者であり、まともな技術的義務を持っていなかったことは彼を傷つけませんでした。

研究開発

Dockerの前に、Ni​​xで作業するなど、さまざまなパッケージマネージャーを試しました。 Nixは素晴らしいプロジェクトであり、多くの良い点がありますが、残念なことに、これは私たちが必要としていたものではありませんでした。 Nixはアトミック更新、ロールバックをサポートし、システム構成への宣言的なアプローチを持っています。



残念ながら、画像で使用するさまざまなプログラムやライブラリのスクリプトを維持することは難しく、カスタムパッケージやプログラムを追加することも困難でした。 スクリプトやライブラリなどを統合するために必要な努力は、システムのパッチのようなものでした。 要件を満たすためにより近いものを探していました。



初めにそのような要件がありました：

同じ言語の異なるバージョンを提供する（すなわち、ruby 1.9とruby 2.1）

他の部分を壊さずにシステムの一部を更新する安全な方法がある（たとえば、Pythonライブラリのみを更新し、Rubyライブラリには触れない）

システム構成に宣言型アプローチを使用します（イメージ内にあるべきものを記述する単純なスクリプト）

更新を簡単に更新してロールバックする方法を作成する



その過程で、Dockerを使用することには他にもいくつかの利点があることが明らかになりました。 これらには以下が含まれます。

ランタイム/言語ごとに個別の分離された環境を作成する

CoWファイルシステムのサポートの取得（これにより、 画像管理のレベルがより安全かつ効率的になります）。

さまざまなランタイム環境をオンザフライで切り替える信頼できる方法を取得する

Dockerでの作業

Dockerを使用する場合、すでにLXCを使用しているため、統合することは難しくありませんでした。 （Dockerは、LXCを高レベルのプロセスレベルAPIで補完します。以下のStackOverflowリンク。）



既存のシェルスクリプトをDockerfilesに移行し、イメージを作成した後、LXCを直接使用することから切り替えるには、lxc-executeではなくdocker runを実行し、各タスクに必要なイメージIDを指定する必要がありました。 。



LXCイメージを開始するコマンドは次のとおりです。



lxc-execute -n VM_NAME -f CONFIG_FILE COMMAND







Dockerイメージを起動するコマンド：



docker run -i -name=VM_NAME worker:STACK_NAME COMMAND







コンテナを作成およびインストールするための推奨アプローチから少し離れていることに注意してください。

標準的なアプローチは、Dockerfilesを使用して実行時にイメージを作成するか、クラウドのプライベート/オープンリポジトリに保存することです。 代わりに、イメージを作成し、それらからスナップショットを取得して、システムに接続されたEBSに保存します。 これは、システムを非常に迅速に起動する必要があるためです。 実行時にイメージを作成することは悪いオプションでした。外部ストレージからイメージをロードすることでさえ遅すぎます。

ベースイメージと差分

また、Dockerを使用することで、ディスク容量の問題も解決されました。これは、各イメージがベースイメージからの変更（差分）のセットにすぎないためです。 これは、すべてのイメージで使用するオペレーティングシステムとLinuxライブラリを含む1つの基本イメージを作成し、それを他の多くのイメージの基盤として使用できることを意味します。 継承されたイメージのサイズには、ベースイメージとの差分のサイズのみが含まれます。



たとえば、Rubyをインストールすると、新しいイメージにはRubyでインストールされたファイルのみが含まれます。 これが混乱しないように、コンピューター上のすべてのファイルを含むGitリポジトリーと考えてみましょう。ベースイメージはマスターブランチであり、他のすべてのイメージはベースイメージから生成された異なるブランチです。 既存のコンテナに基づいて差異を組み込み、イメージを作成するこの機能は、常に新しいバージョンをリリースし、ライブラリ、パッケージを追加し、問題の解決に集中できるため、非常に便利です。

いくつかの問題

Dockerを使用して新しい環境を作成および実装する際にいくつかの問題がありましたが、深刻な問題はありませんでした。

タスクの開始後、コンテナを削除するのに苦労しました。 コンテナの取り外しプロセスは時々落ちましたが、かなりきれいな解決策が見つかりました。

一部のソフトウェアコンポーネントを構成する際、Dockerがfuseなどの低レベルの機能を誤ってエミュレートすることがわかりました。 その結果、正しく機能するJavaイメージを取得するために、魔法に頼らなければなりませんでした。



まあ、それだけです。 Docker'aの開発者への質問は、主にいくつかの修正に要約されていますが、Docker'aの新機能については、これで十分です。 （既存の一連の関数は非常に広範囲に及ぶため、関数には何も追加しようとしませんでした）。

LXC、コンテナおよびDocker

LXC（LinuX Containers）は、同じLinuxシステムで実行されている他のプロセスから1つ以上のプロセスを安全に分離するオペレーティングシステムレベルの仮想化システムです。 コンテナを使用すると、リソースを分離でき、サービスが制限され、プロセスにはオペレーティングシステムの分離されたスペースが割り当てられ、ファイルシステムとネットワークインターフェイスの独自の構造が使用されます。 複数のコンテナが同じコアを使用できますが、各コンテナは、CPU、メモリ、I / Oなどの特定の量のリソースのみを使用するように制限できます。 その結果、アプリケーション、タスク、およびその他のプロセスを、同じマシン上で複数の軽量の分離されたLinuxインスタンスとして実行するように構成できます。



DockerはLXCの上に構築されているため、イメージと展開を管理できます。 以下は、 LXCとDockerの違いと互換性に関する SolomonのStackOverflowに関する記事です。

Dockerの機能を見ると、それらのほとんどは既にLXCで提供されています。 それでは、Dockerは何を追加しますか？ なぜ単純なLXCではなくDockerを使用する必要があるのですか？

DockerはLXCの代替ではありません。 「LXC」とは、Linuxカーネルの機能（特に名前空間と制御グループ）を指し、プロセスを相互に分離し、リソースの分配を制御することを可能にします。

Dockerは、低レベルのカーネル機能に加えていくつかの強力な機能を備えた高レベルのツールを提供します。

続きを読む>>

生産中のDocker

Docker-IronWorkerのスタックの基礎



現在、IronWorkerサービスの一部として、本番環境でDockerを使用しています。 コードをロードするときに「stack」パラメーターを設定することにより、タスク用に10個の異なる「スタック」（コンテナー）のいずれかを選択できます。 考えてみれば、これは便利な機会です。任意の数のコアで実行される短期タスクの言語バージョンを指定できます。



イメージ管理にDockerを使用すると、システムの他の部分を損傷することを恐れずにイメージを更新できます。 つまり、Ruby 2.1イメージに触れることなくRuby 1.9イメージを更新できます。 （特に大規模な言語セットをサポートする場合、大規模システムでは一貫性を維持することが最重要です）。



また、Dockerfilesを使用してイメージを更新するためのより自動化されたプロセスがあり、予測可能なスケジュールに従って更新を展開できます。 さらに、カスタムイメージを作成する機能もあります。 それらは、言語の特定のバージョンに応じて、および/または特定のフレームワークとライブラリを含むように形成できます。

未来に目を向ける

本番環境でDockerを使用するという決定は、非常に危険なステップではありませんでした。 一年前はおそらくそうでしたが、今では安定した製品です。 これが新製品であるという事実は、私たちの目には利点です。 最小限の機能セットがあり、当社のような大規模で動的なクラウド環境向けに構築されています。



Dockerを内側から見て、背後の人々を認識しましたが、DockerがなくてもDockerは自然な選択です。 多くのプラスがありますが、マイナスはほとんどありません。



また、アドバイスの権利については、「すぐに使用できる」Dockerfile、スクリプト、および公開されている画像を使用することをお勧めします。 最初に役立つものがたくさんあります。 実際、おそらくDockerfilesとイメージを一般公開します。これは、人々が簡単にローカルでワーカーを実行できることを意味し、プルリクエストを送信して改善することもできます。



ほとんどすべての言語で毎日数万時間のCPU時間と数百万のタスクを処理するのは簡単ではありません。 Dockerを使用すると、少しの労力でいくつかの深刻な問題を解決することができました。 これにより、IronWorkerの革新と新しい機会の創出が可能になりました。 しかし、同様に重要なことは、これにより、私たちが多くの改善を行うために、保証されたサービス条件を維持し、さらには超えることができることです。



Dockerには素晴らしい未来があります。Dockerをテクノロジースタックに含めることに決定しました。