コンテナそれ！ Fuelとは何ですか？

特許戦争はOpenStackエコシステムに対する隠れた脅威のままですが、 OpenStackをほぼワンクリックで展開できるテクノロジーについて話しましょう。 このプロジェクトの名前はブログの投稿で繰り返し確認されましたが、 Fuel専用のテキストはありませんでした。 一方、このプロジェクトはOpenStackの展開プロセスを大幅に簡素化し、さらなるクラウド管理のプロセスを労働集約的にしませんでした。 もちろん、あなたは昔ながらの方法で行動することができます。 OpenStackを使用する場合、Fuelの使用はオプションです。 ただし、劇場がハンガーから始まる場合、OpenStackはFuelから始まると考えています。 少なくともMirantis OpenStack（MOS）。

燃料についてのいくつかの一般的な言葉

Fuelは、OpenStackデプロイメントツールおよびその後のクラウド管理です。 より多くの情報上の理由を提供するプロジェクトに名前を付けることは困難です。 これで、FuelはDockerコンテナを使用するようになりましたが、プラグインサポートの開始については既に知っています。 しかし、最初に、コンテナについて話しましょう。 最初のロシアのDocker-mitapの前夜、そのような会話は正当化される以上のものです。



すでにOpenStackを試した人（それが何であるかを伝えるだけではありませんが、2年前に私たちの注目を集め、まだそれを手放さない技術の実験に時間を費やすよう説得したいと思います）手動によるインストールが面倒で複雑であり、最も重要なこととして、多くの間違いを抱えていることを確認できます。 燃料は、手動での展開の問題に対する答えです。 これは、Webベースのユーザーインターフェイスを備えた直感的なツールです。実際には、クラウドを数回クリックして展開し、さらに操作するためのコントロールパネルです。 Fuelは、OpenStack構成の大規模な（これまで、100ノードの環境への展開がテストされていました）展開、テスト、およびサポートを簡素化することに注意することが重要です。 OpenStackエコシステムのプロジェクトの1つであるFuelプロジェクトは、特定のブランド（私たちのブランドでさえも）に関連付けられていません。



この開発に何度も戻ります。 次に、Dockerについて説明します。

Docker：時間とエネルギーを節約

MOS 5.0以降、MirantisはDockerを使用して、Fuelのシンプルで信頼性の高いトランザクション更新を実装しました：新しいコンテナーを作成し、チェックし、何か問題が発生した場合は古いコンテナーを返します。 それがどうだったかについて話しましょう。

回顧

MOS 5.0

変更により、ユーザーはスクリプトを使用して環境を元の状態に戻すことなく、30秒未満でFuelを再デプロイできました。 これで、変更を加え、それらをすばやくテストし、必要に応じて繰り返し「ロールバック」できます。



変更の速度は「コンテナ」の使用の結果であり、実際にはその範囲は非常に広いです。 対応する環境は、Mac OS XまたはWindows（boot2dockerを使用）を搭載したラップトップ、クラウドのUbuntuの下のQAサーバー、およびRed Hat Enterprise Linuxに基づく実際のデータセンターの仮想マシンに基づいて作成できます。



DockerのFuelアプリケーションを更新するには、古いコンテナを削除して新しいコンテナを起動するだけで、Fuel ISOを再構築して変更をテストするのに必要な1-2時間を節約できます。

MOS 5.1

Mirantis OpenStack 5.1では、マスターノードにFuelをインストールするのに必要な時間を短縮しました。 SSDでの仮想化展開では、イメージのブート時間が半分になりました（コンテナの場合は18分から9分）-9分から8分になりました。 ラボ（物理サーバー）に展開すると、バージョン5.1のイメージの読み込み時間が20％短縮されました。



マスターノードで一時ファイルストレージ（tmpfs）を使用してインストール時間を短縮するというアイデアがありましたが、RAMが不十分な環境では信頼性が低いため、プロセスが遅くなりました。 私たちの主な目標は時間を稼ぐことです。



しかし、Docker更新中にFuelの設定のアクティビティを監視するdockerctlユーティリティのおかげで、バージョン5.1でFuelの安定性を高めることができました。このユーティリティでは、13のコンテナで数百のパラメータが転送されます。 dockerctlユーティリティは、アプリケーションをデプロイするために各コンテナの構成ファイル（astute.yaml）から5〜6個のパラメーターを必要とするアプリケーションに対して多数の一致が確立されるという事実を考慮すると、特に重要です。



systemdの使用を必要とするetcdや他のツールの代わりに、astute.yamlパラメーターを使用し、YAML形式のローカルファイルを残し、コンテナー内でPuppetを実行して、Fuelマスターノードにアプリケーションをデプロイしました。 将来的には必ずしもこれを行う必要はありませんが、この方法は他の利用可能な手段を使用するよりも単純で破壊的ではありませんでした。 ローカルのYAMLとPuppetファイルにはいくつかの欠点がありました。たとえば、Dockerでの多数の接続の確立が容易になり、Puppetと依存モジュールのインストールにより各コンテナのディスクリソースが大量に消費されました。 それでも、Docker OSの最もコンパクトで完全に機能するイメージのいくつかを使用しています。 UbuntuベースのDockerイメージのサイズは非常に大きく、PuppetをインストールしたCentOSベースのイメージのサイズは39MBに圧縮されています。

現状：MOS 6.0

燃料設定のエラーを修正し、ログのローテーションを実装してディスク領域を解放しました。 さらに、システム要件を6.0に設定する際、logrotateユーティリティを考慮しました。これはデフォルトで最後の5つのアーカイブを保存します（これは不均衡なディスクスペースを必要としますが、Docker自体はすべての空きスペースを埋めることができるログ用のディスクスペースを必要としますファイルシステムをクラッシュさせます）。 この問題には自動解決策がないため、Mirantisによってログストレージが改善されたとしても、生成されるログの量を予測できないため、ディスク容量を監視する必要があります。 logrotateは1時間ごとにログを更新するという事実にもかかわらず、空きディスク領域を監視せず、Dockerログでフォルダーのサイズを増やすオプションはありません。 実際、logrotateの設定により、単一のログファイルのサイズが制限され、そのサイズに達するとアーカイブされます。 そのため、パラメーターを増やしても、ログ専用に30GBを割り当てる必要があります（20ノードに展開する場合）。 ただし、デバッグモード（デバッグ）を有効にすると、大きなファイルのローテーションは1時間ごとではなく10分ごとに発生します。



Mirantis OpenStack 6.0のDockerベースの燃料のその他の革新には、マスターノードのオペレーティングシステムとしてCentOS 6.5を使用することが含まれます。

CentOS 6.5には常にサービスを実行するsystemd初期化デーモンがないため、Mirantisはスーパーバイザー管理ユーティリティを使用してDockerコンテナーを起動および追跡し、Webアプリケーションを起動します。 広告主が言いたいように、「ツーインワン」。



さらに、単純なtry-or-failスキームを使用して解決します

依存関係追跡ツールを継承していないDockerコンテナーを停止する問題。 ソリューションでは、PostgreSQLまたはRabbitMQがまだ実行されていないためにDockerコンテナーが起動してから停止しようとすると、Supervisorは数秒待機してからコンテナーを再度起動しようとしますが、すべてのコンテナーが起動するまで失敗しました起動されます。 この方法は、優先順位に基づいたコンテナの試運転の複雑なシーケンスよりも保守がはるかに簡単です。

依存関係。 また、すべてのコンテナを起動するときにdockerctlが適切なシーケンスを持っているという事実にもかかわらず、このシーケンスは初期展開にのみ適用されます。



繰り返しになりますが、FuelはOpenStackエコシステム全体のプロジェクトなので、このツールを使用してOpenStackプラットフォームをデプロイ、テスト、およびサポートできます。 もちろん、 Mirantis OpenStackディストリビューションの一部として入手するのが最も簡単だと考えています。 それにもかかわらず、私たちは私たちの配布に対して責任があり、その使用が生態系全体の評判を傷つけないことを保証することができます。

モスクワでの最初のDockerイベント

Dockerが便利なツールであることを確認したので、この知識を共有したいと思います。 2月26日、18：00から21:00に、Mirantisはモスクワでの最初のDocker集会に参加し、参加を希望する人を招待します。 参加は無料です。 このイベントの詳細については、 ロシアのOpenStackコミュニティ Webサイトをご覧ください 。 会議への参加をご希望の場合-登録が必要です。



燃料サポートチームのエンジニアであり、Linux Journalの著者であり、OpenStackの愛好家であるFabrizio Soppelsaが会議を開始します。 彼はDockerテクノロジーの簡単な説明を定式化し、この強力なプラットフォームを使用する利点と開発者の間で人気のあるものを説明します。



次に、 Matthew MosesohnはMirantisのシニア開発者です。 マシューはDockerの展開について「オフザグリッド」について説明します。 ちなみに、この資料を準備する際に頼ったのは、FuelからDockerへの移行に専念している企業ブログの彼の投稿でした。



YandexのクラウドプラットフォームおよびCDN運用グループの責任者であるDenis Zaitsevが 、Dockerレジストリのスケーリングについて説明します。 Muranoを使用したOpenStackクラウドでのDockerアプリケーションの起動について-Mirantisのシニア開発者であるSergey Melikyan氏。



この会議は、Parallels Linux Kernelチームの開発者であるAndrey Vaginが完了します。 彼のテーマは「Libcontainer：一つの屋根の下で力を合わせる」です。 アンドレイは、計画の説明とこのタスクの現在のステータスを作成します。



おそらくまだ質問があります（またはあります）。 イベントは彼らに尋ねるのにふさわしい場所です。 ただし、何らかの理由で会議に出席できない場合は、コメントに質問を書いてください。専門家に説明を求めます。