David Laube：Openstockを使った失敗記

去年の初夏、同僚のZacさんは会社のCEOでもあります。現代的で何もない雲托管のプラットフォームをどうやって構築するかを助けてください。

今までの主な経験を振り返りますと、拡張可能なインフラを構築し、サポートして使った経験があります。思わずつぶやいてしまいました。

私は自分に聞きたいのですが、本当に必要ですか？いいインフラとサービスがたくさんあるじゃないですか？

コミュニケーションが深くなるにつれて、私は最終的に多くのクラウドサービスがユーザーフレンドリータイプではないことに気づきました。

また、私はDockerの初期のユーザーです。Dockerは容器エンジンを応用しています。このような容器サポートの配置案は高品質の物理裸体機を運行と維持の仕事にもっと力を入れます。

しかし、いくつかの公有クラウドの仮想化の状況は、いくつかのホストサービス業者の問題がありますが、複雑で変化に富む物理的なハードウェア発展のニーズにマッチできませんでした。

そこで私はこのために仕事をする必要があると思います。

これからはpacket.netの展開に合わせて、一緒に楽しみましょう。

私は展開packet.netの仕事に頭から突っ込んだ。

また、配置戦略とクラウド自動化の関連動態に注目し、特定の設置手順を最初から最後までチェックし、すべてのオープンソースクラウドプラットフォームと、すでに設置されたサービスを提供しています。

VoxelはInternapに買収されたクラウドホストの委託管理プラットフォームであり、私たちは利用する時に自分のプログラムをたくさん配置しました。この過程で持ってきたメリットを見ました。また、自分がソフトウェアプラットフォームを持っているという感覚を体験しました。

サーバーのインストール作業はとても容易に見えますが、いったん完成したら、いつまでも苦労してしまうようですよね？しかし、これは絶対的な錯覚です。インストールが完了したら、数え切れないほどのネット上の問題が発生します。また、いつでも発生するハードウェアの調整と各種の操作システムの違いがあります。

このような場合には、ユーザに対して割引できないものを提供する。

数千台のサーバーを設置して管理し、これらのサーバーが正常に動作するように確保し、5分以内にもZacの決定に応答することができます。

これは私にとって楽なことではない。

packet.netを到着させるために

数千台のサーバーを7 x 24時間継続的にインストールして起動し、数ヶ月後にオンラインします。

私はOpenStockのインターネットインフラにおけるユニークな点に注目し始めました。サービスを構築する手段として活用できます。

これは、ネットワークサービスの自動化、IPアドレスの管理、インストールプロセスの監視、ハードウェアの交換とインストールを含む。

私はOpenStockなどの核心プロジェクトに頼って仕事を完成できれば、私のチームはより多くの価値をユーザーにもたらすことができることに集中できます。

他の人が私にOpenStockの存在の隠れた危険を注意したことがありますが、自分で数週間をかけて最近のバージョンの記録を読みに行きました。いくつかのWikipenのIRLC公式チャットチャンネルに混じっています。そしてOpenStockのインストールスクリプトDevStockを遊びました。

私は正しいです

コアプロジェクトはもうそんなに珍しくないです。

過去2年間でDevStockは非常に成熟しており、タイミングもちょうどいいです。

世界的にリードするホストサーバとクラウドコンピューティングプロバイダのRackspaceは最近、OnMetal物理裸機サーバの配置案を発表し、その物理機にIreonicを使ってブログを公開して展開する方法を指摘しています。

アメリカ時間の2014年10月16日にOpenStockの重要なバージョンがJunno版で正式に発表されました。

ですから、OpenStockを使って、会社の物理サーバを展開するべきだと思います。

OpenStockを学ぶ過程は平坦ではないことを知っています。そして、これは一生懸命に勉強しなければならないことが分かります。インストールだけではないです。

私はOpenStockの各項目を詳しく研究して、Novaの動き、そしてIreonicのドライバ、特にNeutronを知るように努めます。

物理サーバにIreonicをインストールするだけでなく、packett.netホスティングサービスのネットワークモデルをサポートします。特にLayer 3をLayer 2とVLAN層ホストの機能に置き換えます。

この時、「えっと、読みたいと勉強する文書が多いですね」と言ってもいいかもしれません。過去の一ヶ月の間に、私たちが触れた文書は時代遅れではないということは間違いだということを明らかに感じました。

これは、以前の素晴らしい文書から内容を削除しなければなりません。例えば、ウィキペディアの文章、IRCの日記、そしてバージョン提出記録などから最新の正確な情報を探しに行きます。

これらの基礎作業が完了したら、私はpythonを使って大量のデバッグ作業を行い、文書の説明と一致しない様々な機能を検証したいです。

これが仕事かどうか、それが正しいかどうかは、長いプロセスです。

特にOpenStockのNovaと標準的なNeutronプロジェクトの関連部分があります。

規模的には他のオープンソースプロジェクトに匹敵するものがありますが、Ironicにとっては製品級の使用レベルに達する人はなかなかいません。

私はこのような状況に遭遇したことがあります。核心開発者に実施の問題を聞いてみましたが、彼らは答えられませんでした。

これらの問題をGoogleから検索しても、問題に関する情報は指折り数えるほどしか得られません。

Neutronの部分を同僚に任せて処理しましたが、自分はIronicを深く理解しました。

しかし、実際の状況はOpenStockの各部分の特定の開発者を必要としています。彼らにコードバンクを理解してもらえば、OpenStockの各プロジェクトの更新についていけます。

私たちはどのように自分のニーズを満たすために行くべきですか？そこで、IRCを通じてRackspaceからのOnMetalチームのメンバーと接触し、メールで連絡します。

OpenStock開発者フォーラムを見に行きます。

私は切符を保証します。自分で関連文書を読みました。フォーラムの中のすべての招待状もあります。Googleで検索した関連情報を通じてIreonicを調整します。これらは全部やり遂げました。

以前のIreonicプロジェクトにとってOpenStock Nova版の物理サーバ配置案はブレークスルー的に進展しましたが、OpenStockは仮想化技術を中心に設計されました。

まだ多くの機能とドキュメントの修正が残されています。Novaの物理機械配置案と駆動付きIronic配置案の間です。

このような状況をパワーの限られたIronic技術サポート部門にフィードバックしましたが、仮想技術に関するopenvswitchとlinuxbridgeの使用を強く求められました。

私たちのネットワークモデルはこれと深刻な衝突があった。

そこで、OpenStockのNeutronプロジェクトは、特定のネットワーク製品メーカーに対する技術サポートだけでなく、異なるネットワークモデルへの拡張能力にも欠けていることを発見しました。

OpenStockのコアコードをより深く理解している大ユーザー（典型的なのはRackspace社）は、OpenStockのプロジェクトを高度に固定化して、物理マシンを実際の物理ネットワーク上に配置できるようにする。

いくつかのパッチはすでに公開されていますが、多くの重要なパッチは公開されていません。ユーザー自身で新たに作成する必要があります。

この時点で、OpenStockを使って会社のサービスを展開することに対して、重大な疑問が生じました。

これだけ多くのことを知る必要があります。また、各項目と同期して仕事をするということが怖いです。

そして、NovaとIreonicに対して行う固定化の仕事は小さなことではないということを認識し始めました。これはOpenStockの開源面でのメリットを解消します。

しかし、Neutronの詳細を完全に知ることはとても重要だと思います。

物理的なスイッチとサーバーにとっては、サーバーの配置が難しくなく、解決策が十分に成熟していて、信頼できる。

自動化の仕事は多くのツールを必要とします。仕事に協力してこそ完成できます。

私の経験から見ると、基本的な配置作業のほとんどは、ネットワーク部分の自動化です。

物理交換機のオペレーティングシステムにはまだ足りないところがたくさんあります。

現在の自動化作業とAPIの相互作用に対する支持は四苦八苦しています。

実は、私が使ったもう一つのネット自動化ツールの下手な表現はOpenStockを使う主な原因を考えさせられました。

Neutronプロジェクトは非常にエキサイティングな使命があります。必要に応じて拡張可能なサービスを提供し、関連するライブラリを含めて任意の技術に制限されないです。

私もそう望んでいます。

しかし、現実は約束した通りではない。

ソフトウェア定義ネットワーク（SDN，Software Defined Networking）によると、ほとんどは仮想マシンモニタに基づく仮想ネットワークで動作するプロジェクトは、実際のスイッチではない。

交換機メーカーにとっては時代遅れのNeutron駆動だけでなく、OpenStock最新のJunnoバージョンのサポートも限られています。

また、Neutronは、自身の不完全なIPアドレスマネージャ（IPAM）を使用しており、外部アクセス方式を自分で割り当てるという概念はまったくなく、IPアドレス管理に関する書面上の説明と権限も提供していません。

ユーザー体験を犠牲にしてNeutronの不足に適応することはできません。

短く言ってください。

クリスマスの前の週にOpenStockをなくしました。そして、三週間をかけて、固定化された自動化配置プラットフォームを開発しました。

12月初めに自分のIP管理システムを構築した後、チームはシステムをカスタマイズツールに構築することに力を入れました。

新しいプロジェクトはすべて自分の使命があります。

会社としてのビジョンは常に向上しており、OpenStockの調査と展開の過程で、存在する問題の大部分を解決したと思います。柔軟でサービス機能を提供できるIPAMシステムを構築しました。

施設管理プラットフォームと物理インフラの間に、ユーザーと権限モデルも確立しました。

現存するものが必ずしも一番いいとは限らないし、必ずしも自分の需要を満足させるとは限らない。

私たちはOpenStockを使ってpacket.netを展開する過程でこの道理を完全に説明しました。

同時に、私たちは自分のNeutronプラグインをリリースするように努力します。OpenStockプロジェクトの発展に適応して、今やっています。

その後の一週間で、最終的にCoreOSシステムのインストールが完了しました。