Openstack Queensがリリースされ、その特徴は「コンテナ・タスティック」

2018-04-10

Machine-translated — the English original is authoritative.

コンテナ技術に関連するOpenStackプロジェクトの数は急速に増加しており、それらの異なるユースケースを取り巻く混乱もまた拡大しています。この投稿が、これらのプロジェクトをいつ、なぜ使用するべきかを明確にする手助けになれば幸いです。

しかしまず第一に、なぜコンテナなのでしょうか？何がそんなに画期的なのでしょうか？これらは単なる開発者主導の「今月の流行」に過ぎないのでしょうか？もしコンテナについてまだ読んでいない、あるいは開発/本番環境でまだ使用したことがないという場合、おそらく貴社はプライベートデータセンターまたはパブリッククラウドのいずれかに存在する、従来のモノリシックなアプリケーションとデプロイメント方法を使用しているエンタープライズ企業で働いている可能性が非常に高いです。

背景

過去5年間で、Dockerというコンテナ企業が、同じ名前で呼ばれるソフトウェアとツールセットをリリースしました（ただし、オープンソースプロジェクトは最近、混乱を招く形でMobyに改名されました）。これにより、オペレーティングシステム内でプロセスとそのリソースを他のプロセスから隔離するメカニズムの消費が大幅に簡素化されました。これらのメカニズム（ネットワーク名前空間、cgroupsなど）は長年存在していましたが、隔離を呼び出すために必要なシステムコールを理解するには、ロケットサイエンティスト（冗談ではありません）でなければなりませんでした。Dockerはこれらのシステムコールを非常に使いやすいAPIでラップし、コンテナの大量採用を促進しました – 私のような人々が突然力を得たのです。

当初、Linuxがサポートされている唯一のホストOSでしたが、過去2年間でMicrosoftはWindows上でコンテナ体験を「模倣」するために全力を尽くしました – まだ荒削りな部分もありますが、急速に改善されています。また、現在では一部のメインフレームでも実行できるようになりました。

しかし、Dockerはそれで終わりにせず、彼らは非常に賢明にも、コンテナイメージ（yamlファイル）を保存するために使用できる無料のグローバルリポジトリを設立しました。ソフトウェア業界はこの新技術とhttps://hub.docker.comリポジトリを急速に受け入れ、すぐに彼らのソフトウェア製品をパッケージ化した完成されたコンテナでリポジトリを満たしました。
これで今、私たちは素晴らしいアプリケーションライブラリを持つコンテナエンジンを持ち、標準的なコマンドセットで単純かつ、何より一貫性のあるデプロイが可能になりました。

このリポジトリと優れたAPIの結果、Dockerは現在コンテナエンジンの「事実上の」標準となりました – 幸いにも、Dockerが準拠しているOpen Container Initiative [OCI]があり、必要に応じて最小限の労力でコンテナエンジンを切り替えることができるはずです。
この革命（私はこれを進化ではなく革命と見なしています）は、開発者コミュニティに力を与えると同時に、不満も生み出しました。開発者の不満は、コンテナベースのアプリケーションをコンテナベースではない本番環境にデプロイしようとしたときに発生します。彼らは再び環境構築の長いリードタイムに戻り、これによりアプリケーションのサイクルタイムが長くなります。以下のOpenStackのコンテナプロジェクトが、これらの課題の多くを解決する手助けをしてくれることを願っています。

では、なぜコンテナを使用するのか？

• サーバー利用率の向上により、OSライセンスコストが削減されます。これは過去10年のVM革命に似ており、多くの物理サーバーを仮想サーバーにP2V化することで、必要な物理サーバーの数を削減しました。しかし、仮想マシンごとに独自のOS（オペレーティングシステム）が必要だったのに対し、コンテナは単一のホストOSを共有することができます。
  単一のホストOS内で多数のコンテナを起動することが可能であるため、リソース利用率とOSライセンス要件の両方で再び桁違いの改善が得られます。

• 伝統的アプリケーションの近代化。これはアプリケーションの変換と混同しないでください。これは、モノリシック（通常はステートフル）なアプリケーションをコンテナ内で構築するものです。
  これらは依然として伝統的なアプリケーションの制約に苦しみます – 一般的に、高可用性の観点からステートを管理するために高コストなサードパーティサービス/ソリューションが必要です。
  しかし、IaaSの抽象化の恩恵（プライベートクラウドまたはパブリッククラウドへのデプロイに関わらず同じ体験）と、一貫性のあるコード化されたデプロイメントの恩恵は得られます。あなたは伝統的なアプリケーションでContainers as a Service (CaaS) の空間でプレイしていることになります。
• クラウドネイティブアプリケーション開発。これらのアプリケーションは今日、マイクロサービスパターンを広く利用する傾向があり、コンテナでラップされたマイクロサービスは非常に強力かつ補完的な組み合わせです。
• DevOpsパイプラインデプロイメント。継続的インテグレーションと継続的デプロイメントを想像してください。アプリケーションのデプロイメントのベストプラクティスとしてコンテナを標準化することで、基盤となるインフラストラクチャの不必要な複雑さを抽象化します。開発者は、ターゲットが自分のラップトップ、開発サーバー、あるいはFujitsuのK5、AmazonのAWS、MicrosoftのAzureパブリッククラウドのいずれであっても、同じデプロイメント体験を確保できます。これら3つの最後のパブリッククラウドはすべて非常に異なるインフラストラクチャ技術とAPIによって支えられていますが、もはや気にする必要はありません！これらの環境すべてに必要なのは、同じコンテナエンジンを実行する能力だけです。

OpenStackはコンテナとどのような関係があるのか？

OpenStackのさまざまなコンテナイニシアチブは、OpenStackソフトウェアスイートを使用して構築されたベアメタルおよび仮想マシン上での本番環境におけるコンテナのデプロイメントと管理を解決するために存在します。これらのプロジェクトは、自分自身のOpenStackデプロイメントにコンテナの恩恵を活用できるインフラストラクチャオペレーターを対象としていますが、プロジェクトはまた、パイプラインデプロイメントの悩みを軽減し、アプリケーションを迅速に本番環境に移行するための一貫性があり、高速でアジャイルなプロセスを持てるようにする開発者にも配慮して設計されています。

Magnum
これはコンテナオーケストレーションエンジンのAPIです。Kubernetesクラスター、および/またはDocker Swarmクラスター、および/またはApache Mesosクラスターをデプロイして管理したいとしましょう。OpenStack Magnumは、これらの異なる技術をラップし、インフラストラクチャオペレーターに一貫したインターフェースを提供する一貫したAPIを提供します。これにより、オペレーターは、これらの非常に異なる製品をデプロイするために、同じプロセスと馴染みのあるAPI呼び出しを活用できるはずです。

Zun
プロジェクトウェブサイトからの引用「Zun（旧Higgins）はOpenStackのコンテナサービスです。サーバーやクラスターを管理する必要なく、アプリケーションコンテナを実行するためのAPIサービスを提供することを目指しています。」基本的に、ZunはコンテナにとってNovaが仮想マシンにとって、Ironicがベアメタルサーバーにとってであるようなものです。Nova-Dockerサービスは、NovaコンピューティングAPIを通じてコンテナを管理しようとした初期の試みでした。ZunはNova APIに縛られていません。

Kuryr
再び、プロジェクトウェブサイトが良好な要約を提供しています – 「Kuryrの背後にあるアイデアは、Neutronとそのプラグインおよびサービスに投入された抽象化とすべてのハードワークを活用し、それを使用してコンテナユースケースに対する本番グレードのネットワークを提供できるようにすることです。各独立したNeutronプラグインまたはソリューションがギャップを見つけ閉じようとするのではなく、努力を集中し、1か所に焦点を当てることができます – Kuryr。Kuryrは、2つのコミュニティ、Docker（または別のコンテナエンジン）とNeutronの間の「統合ブリッジ」になることを目指し、コンテナネットワークに特に必要とされるユースケースを満たすためにNeutron（またはDocker）で必要とされる変更を提案し、推進します。Kuryr自体がネットワークソリューションではなく、そのようなものになろうとすることも重要に留意してください。Kuryrの取り組みは、NeutronのネットワークとサービスをDockerに届ける配達業者となることに焦点を当てています。」

Kolla
これは、完成されたコンテナとして提供される本番グレードのOpenStackサービスです。これを読んでいる開発者は、これがどれほど力強いものであるかをすぐに理解するでしょう – OpenStackがコンテナとしてデプロイされる！顧客のデータセンターでOpenStackの大規模なbashインストールの苦痛を経験した私のような人にとって、D:reamの曲が言うように「物事は良くなる一方だ」… そして実際、良くなりました。コンテナは確かにアプリケーションデプロイメントの未来です。彼らは迅速なデプロイメント（または必要に応じてロールバック）のための一貫性があり、コード化され、したがって制御可能なメカニズムを提供します。これらのKollaコンテナイメージは、LOCIプロジェクト/モジュールと組み合わせて使用されます。

LOCI
「LOCIの目標は、OpenStackサービスのためにCI/CDに親和性が高く、軽量なOCI準拠のイメージとツールリングを提供することです。git、パッケージ、pypiミラーがあることを前提として、変更なしでエアギャップ環境でLOCIイメージを構築できます。」Telecommunications sector, big adopters of OpenStack, envisage LOCI as a vital component in driving the future of Openstack in the Edge Computing space. Imagine your BT, Virgin Media or AT&T home router or set-top box running a container. This would give these companies AND home users much greater agility and flexibility. You could potentially swap providers in seconds without the need for new hardware – Win win all around. For small businesses and edge datacentres this can also remove the need for single task dedicated hardware devices – IoT, Big Data and Government regulation will rapidly drive growth in the edge compute space in the coming years.

今回のリリースでは、特にGPU仮想化を中心に、OpenStackに対する多くの他の重要な強化が行われました。完全な詳細については、https://www.openstack.org/software/queens/をお読みください

Happy Stacking!

Graham

Originally published on allthingscloud.eu (2018-04-10).