コンテナ

Save the date! NGINXがRed Hat Forum Tokyo 、Japan Container Daysに登壇します!

もうお申込みはお済みでしょうか?

NGINXが、11/8(木) 開催のRed Hat Forum Tokyoではゴールドスポンサーとして、12/4(火)-5(水) 開催のJapan Container Daysではランチスポンサーとして、出展します!

いずれのイベントでも、NGINX社による講演と、展示ブースでの参加を予定しています。また、どちらのイベントでも、サイオステクノロジーがパートナーとして、共同でブース運営に参加します。

お申し込みは以下のサイトから。

 

 

ぜひ、皆さまのご来場をお待ちしております!

OpenShift Container Platform 3.10用のNGINXおよびNGINX Plusルーターの紹介

この記事はNGINX,Inc.のブログ記事「Introducing NGINX and NGINX Plus Routers for OpenShift」を和訳した内容となります。

URL: https://www.nginx.com/blog/introducing-nginx-and-nginx-plus-routers-for-openshift/

 

Red Hat OpenShiftは、主要なコンテナオーケストレーションおよび管理システムであるKubernetesの上に構築されたコンテナプラットフォームです。OpenShiftは、オープンソースプロジェクト、OpenShift Origin、および市販の製品であるOpenShift Container Platformとして利用できます。

OpenShift Container Platform 3.10の今後のリリースでは、プロダクションOpenShiftクラスタへのトラフィックを最適化するルータとして、高度な機能と完全な商用サポートを備えたソフトウェアロードバランサNGINX Plusを利用することができます。

OpenShiftは、開発者やオペレーター中心のツールをKubernetes上に追加し、セキュリティやその他統合された機能で拡張します。ルータと呼ばれるこれらの機能の1つは、OpenShiftにデプロイされたアプリケーションのエッジリクエストルーティングとロードバランシングを提供します。私たちはNGINXとNGINX PlusがOpenShiftプラットフォームと完全に統合され、それぞれがルーターとして使用できることを確認しています。

ルーターとは?

ルーターは、ルータープラットフォームの最も重要な部分の一つで、OpenShift上で実行しているアプリケーションの外部リクエストのためのエントリポイントとして機能します。ルーターの仕事は、特定のリクエストに対して適切なアプリケーションを特定し、そのアプリケーションのインスタンスにリクエストをルーティングすることです。したがって、ルーターはOpenShift上のアプリケーションにエッジ負荷分散を提供します。

ルーターは、HTTPとWebSocketトラフィックの負荷分散を行い、ルーターインスタンスとアプリケーションインスタンス間のTLSターミネーションおよびTLS接続をサポートします。さらに、ルーターはパススルーモードでTLS接続の負荷分散を行うことができます(復号化はしません)。OpenShiftには、ルーターを設定するためのRouteという特別なリソースが含まれています。

ルーターがダウンしたり正常に動作しない場合、クライアント側からアプリケーションが使用できなくなります。従って、これは、ルーターが実績のある信頼性の高い技術の上に構築されていることが不可欠であると分かります。

ルーターは、OpenShiftのプラグインが可能な部分です。つまり、OpenShiftユーザーは、要件と環境設定を満たすルーター実装を選択できます。

Kubernetes Ingressに関する注記: OpenShiftでも利用可能な組み込みのKubernetes Ingressリソースは、ルーターと同様のエッジロードバランシング機能を提供します。NGINXとNGINX Plusはどちらも、Kubernetes用のNGINX Ingress Controllerを使用してIngressリソースをサポートしています。Red Hatの現在の推奨事項として、IngressリソースはまだOpenShiftの技術プレビュー機能であり、標準のIngress機能はRouteリソースが提供するものに比べて限られているため、Routeリソースを使用することです。

NGINXおよびNGINX Plusルーター

NGINXはコンテナプラットフォームでの採用実績があり、Docker Hubからコンテナイメージを1000万回以上、Kubernnetes のIngressコントローラーを 100万回以上使用されています。私たちは、既存サービスからOpenShiftユーザーへ拡張して、我々の技術の上に構築されたルーター実装/提供されることを喜ばしく思っています。

ルーター実装の主な特長は次のとおりです。

  • Route仕様の完全サポート。NGINXルーターは、Routeリソースによって定義された機能を完全にサポートしています。
  • カスタマイズオプション。さまざまなカスタマイズオプションと追加の機能は、環境変数とRouteアノテーションを介して利用できます。これは、他のルーター実装における共通のアプローチです。
  • おなじみの運用経験。NGINX Routerは、デフォルトルーターの実装を支えるのと同じソフトウェアであるTemplate Routerソフトウェアを介してOpenShiftに統合されています。その結果、使い慣れた運用経験が得られ、デフォルトのルータ実装からの移行が容易になります。
  • NGINXのパフォーマンスと安定性。NGINXルーターを使用すると、NGINXソフトウェアの性能と信頼性を得ることができます。
  • 最新のnginxの特徴。gRPCロードバランシングのネイティブサポートなどの新機能をOpenShift Routerでも発揮されることは非常に喜ばしいことです。新しい機能がNGINXおよびNGINX Plusで利用可能になると、それらをルーターの機能に組み込むことができます。
  • オープンソース。NGINXルーターの実装は、OpenShift Originリポジトリでホストされている完全オープンソースです。
  • 高度な機能。NGINX Plus Routerを使用すると、監視APIやダッシュボードなど、NGINX Plusの追加の利点が得られます。

どうやって始めるのか

NGINXルーターはOpenShift Container Platform 3.10に含まれており、OpenShift Originプロジェクトの最新ソースですでに利用可能です。NGINX Plus RouterはGitHub repoで別途ホストされています。

まず、NGINXルーターNGINX Plusルーターのインストール手順を参照してください。

概要

NGINXとNGINX Plus Routersは、信頼性、性能、および必要な機能をOpenShiftプラットフォームの中核コンポーネント、つまりルーターとして機能を発揮します。

OpenShift Container PlatformとOpenShift Originの両方でこのフル機能のソリューションの作成に携わってくれたRed Hatに感謝します。

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************

 

サービスメッシュとは?

この記事はNGINX,Inc.のブログ記事「What Is a Service Mesh?」を和訳した内容となります。

URL: https://www.nginx.com/blog/what-is-a-service-mesh/

サービスメッシュは 、マイクロサービスアプリケーションの構成ができるインフラストラクチャ層です。これにより、サービスインスタンス間の通信が柔軟で信頼性が高く、高速になります。このメッシュは、サービスのディスカバリ、ロードバランシング、暗号化、認証と認可、サーキットブレーカーパターンのサポート、およびその他の機能を提供します。

サービスメッシュは、通常、各サービスインスタンスに対して、サイドカーと呼ばれるプロキシインスタンスを提供して実装されます。サイドカーは、サービス間の通信、監視、セキュリティ関連の懸念(個々のサービスから抽象化できるもの)を処理します。このようにして、開発者はサービス内のアプリケーションコードの開発、サポート、メンテナンスを処理し、運用担当者はサービスメッシュを維持して、アプリケーションを実行できます。

Google、IBM、Lyftの支援を受けているIstioは、現在、最もよく知られているサービスメッシュアーキテクチャです。もともとGoogleによってデザインされたKubernetesは、現在Istioにサポートされている唯一のコンテナオーケストレーションフレームワークです。

サービスメッシュには、コンポーネントサービスと機能に関する独自の用語があります。

  • コンテナ オーケストレーション フレームワーク アプリケーションインフラに次々とコンテナが追加されるにつれ、一連のコンテナを監視および管理するための別のツールである、コンテナ オーケストレーション フレームワークが不可欠になります。Kubernetesは、この市場を独占したようです。主要な競合相手であるDocker SwarmやMesosphere DC / OSでさえ、Kubernetesとの統合を代案として提示しています。
  • サービスとサービスインスタンス  具体的に言うと、開発者が作成するのはサービスではなく、サービスインスタンスのサービス定義またはテンプレートです。アプリケーションはこれらからサービスインスタンスを作成し、インスタンスは実際の作業を行います。ただし、サービスという用語は、多くの場合、インスタンス定義とインスタンス自体の両方に使用されます。
  • サイドカープロキシ  サイドカープロキシは、特定のサービスインスタンス専用のプロキシインスタンスです。他のサイドカープロキシと通信し、オーケストレーションフレームワークによって管理されます。
  • サービス・ディスカバリ インスタンスが別のサービスとやりとりする必要がある場合、他のサービスの健全で利用可能なインスタンスを見つける必要があります。コンテナ管理フレームワークは、リクエストを受信する準備ができているインスタンスのリストを保持します。
  • ロードバランシング サービスメッシュでは、ロードバランシングは一番下から機能します。サービスメッシュが管理している利用可能なインスタンスは、順に並べてリスト化され、最も負荷の軽いインスタンス(ここが負荷分散部分になります)が一番上に配置されます。
  • 暗号化 サービスメッシュは、リクエストとレスポンスを暗号化および復号化し、各サービスからその負担を取り除くことができます。サービスメッシュは、既存のパーシステントコネクションの再利用に優先順位を付け、コンピューティングリソース的に高価となる新規の接続を作る必要性を低減することで、パフォーマンスを向上させることができます。
  • 認証と承認 サービスメッシュは、アプリケーションの外部と内部の両方から行われたリクエストを認証し、検証されたリクエストのみをサービスインスタンスに送信することができます。
  • サーキットブレーカーパターンのサポート サービスメッシュは、不健全なインスタンスを分離し、それらが保証された段階で、健全なインスタンスプールに徐々に戻していくサーキットブレーカーパターンをサポートします。

サービスインスタンス、サイドカープロキシ、それらの間の相互作用など、サービスメッシュで作業を実行している部分は、サービスメッシュアプ​​リケーションのデータプレーンと呼ばれます。(名前には含まれませんが、データプレーンも処理を実行します)。でも、サービスメッシュアプ​​リケーションには、コントロールプレーンと呼ばれる監視および管理レイヤーも含まれています。

コントロールプレーンは、新しいインスタンスの作成、不健全または不必要なインスタンスの終了、監視、監視と管理の統合、アプリケーション全体のポリシーの実装、およびアプリケーション全体の正常なシャットダウンなどのタスクを処理します。コントロールプレーンは、通常、アプリケーションプログラミングインタフェース、コマンドラインインタフェース、およびアプリケーションを管理するためのグラフィカルユーザインタフェースを含むか、またはそれらに接続するように設計されています。

nginMesh、コントロールプレーン、データプレーン、サイドカープロキシとしてのNGINXを含むIstioサービスメッシュ

 

NGINXには、nginMeshと呼ばれるIstio互換のサービスメッシュがあります。このnginMeshアーキテクチャの図は、典型的なIstioコンポーネントとともに、サイドカープロキシの役割を果たすNGINXを示しています。

サービスメッシュアーキテクチャの一般的な使用例は、コンテナとマイクロサービスを使用して非常に要求の厳しいアプリケーション開発の問題を解決する場合です。マイクロサービスの先駆者には、Lyft、Netflix、Twitterなどの企業があります。これらの企業は、1時間単位で出入りする世界中の何百万人ものユーザーに、堅牢なサービスを提供しています。(Netflixが直面しているいくつかのアーキテクチャ上の課題についての詳細な説明を参照してください)。アプリケーションのニーズがそれほど厳しくない場合、より単純なアーキテクチャで十分でしょう。

サービスメッシュ・アーキテクチャーが、すべてのアプリケーション開発およびデリバリーの問題に対する答えとなることはないでしょう。建築家や開発者は非常に多くのツールを持っていますが、ハンマーはそのうちの1つに過ぎず、彼らが対処しなければならないたくさんの問題の中で、釘もまたそのうちの1つにすぎないからです。たとえば、NGINX Microservices Reference Architectureには、マイクロサービスで問題を解決するために、連続的なアプローチを提供するいくつかの異なるモデルが含まれています。

サービスメッシュアーキテクチャ(NGINX、コンテナ、Kubernetes、構造的なアプローチとしてのマイクロサービスなど)に付随する要素は、非サービスメッシュ実装で生産的に使用できます。たとえば、サービスメッシュアーキテクチャとして開発されたIstioはモジュール式に設計されているため、開発者は必要なものを選択して使えます。サービスメッシュアプ​​リケーションをいつ、完全に実装するかどうかわからなくても、これを念頭に置いて、サービスメッシュの概念を確実に理解する価値はあります。

このブログの投稿は、シリーズの最初のものになります。現在、予定されている投稿は次のとおりです:

  1. サービスメッシュとは?ー  本投稿です。
  2. サービスメッシュアーキテクチャの利点と欠点 いつサービスメッシュが正解か、代替案がより良いかもしれないかを説明します。
  3. サービスメッシュとAPIゲートウェイ  APIゲートウェイが問題の大部分を解決しうる時、サービスメッシュに直ちに移行するべき時、およびそれらをミックスしたアプローチを使用する時を示します。
  4. KubernetesとService Meshアーキテクチャ サービスメッシュを含むさまざまなアーキテクチャでKubernetesを使用する方法について説明します。
  5. サービスメッシュアーキテクチャにおけるNGINXの使用 NGINXは、サービスメッシュ・アーキテクチャ(サイドカー・プロキシIngressコントローラ、またはその両方)の中で、ロードバランシング、サービス・ディスカバリ、キャッシングなどの機能を提供しながら、いくつかの重要な役割を果たします

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************