OpenShiftを本番環境に導入する前に解決すべき7つのこと

ビジネスでのコンテナ使用の爆発的な成長は印象的です。コンテナは、コストを削減し、技術的能力を拡張し、機敏性と開発の旅を前進させたいと考えている人々の期待とニーズに完全に一致しています。コンテナ革命は、ITシステムの更新が遅れている人々に新しい機会をもたらします。コンテナとKubernetesは、アプリケーションとITインフラストラクチャを管理するための完全かつ根本的に新しい方法です。







ベアメタルから仮想マシンへの以前の同様に革新的な移行とは異なり、コンテナはソフトウェアスタックの冗長性を劇的に減らし、企業のオペレーティングシステム管理の本質を変えます。



多くの人が、エンタープライズセクター向けの業界をリードするKubernetesプラットフォームであるRed Hat OpenShift ContainerPlatformを使用してコンテナへの移行を加速することを選択しています。このソリューションは、初日のタスクの多くを自動的に実行し、厳密にテストされた高度にセキュリティ保護された単一のプラットフォームで最高のKubernetesエコシステムを提供します。これは、企業にとって最も包括的で機能的なソリューションであり、開始するために必要なすべてのものが含まれており、Kubernetesプラットフォームを構築する際の多くの技術的な障壁や困難を取り除きます。



ただし、OpenShiftは、すべての問題を単独で解決する魔法の杖ではありません。はい、その機能のおかげで、このプラットフォームは、発売時によく考えられた計画を持っていれば、多くのメリットをもたらし、顧客にすぐに利益をもたらすことができます。成功するには、ワークロードをOpenShiftに移動する前に慎重に検討する必要がある7つの領域があります。

1.命名規則とメタデータの標準化

コンピュータサイエンスでは、キャッシュの無効化とエンティティの命名という2つの難しいことがあります。

-フィル・カールトン

OpenShiftとKubernetesのすべてのエンティティには独自の名前があります。また、各サービスには独自のDNS名が必要 です。ここでの唯一の制限は、DNS命名規則です。ここで、モノリシックアプリケーションが100,500の個別のマイクロサービスに分解され、それぞれに独自のデータベースがあると想像してください。はい、OpenShiftでは、すべてが階層的、関連的、またはパターンに従う必要があります。したがって、すべての質量と質量に名前を付ける必要があります。そして、事前に基準を準備しなければ、それは本当のワイルドウェストであることがわかります。



すでにサービス実装スキームを計画しましたか？たとえば、「データベース」のように、全員がデータベースをホストする1つの大きな名前空間になるとします。 OK、そして誰もがそうすると仮定しましょう、しかしそれから彼らは彼ら自身の名前名で彼らのKafkaクラスターをホストし始めます。はい。ただし、名前名「ミドルウェア」を作成する必要がありますか？それとも「メッセージング」と呼んだほうがいいですか？そしていつものように、ある時点で、常に自分の道を進み、自分自身を特別だと考え、自分の名前名が必要だと言う人がいます。聞いてください。組織には17の部門があります。おそらく、すべての名前名に標準の部門プレフィックスを付ける必要がありますか？



何かを本番環境に移行する前に、命名と照合の標準を検討してください。事前にこれを行うと、時間と労力を大幅に節約できます。すべての基準を設定します。さらに、ここで重要なのは品質ではなく、可用性、整合性、および実装です。



もう1つの非常に便利なのは メタデータです。追跡する資産を標準化し、適切なメタデータが適切なリソースに書き込まれるようにします。推奨ラベルから始める ..。たとえば、名前名メタデータで「support_email」に注釈を付けると、重大な障害が発生した場合にTier2サポートに連絡する際の貴重な時間を節約できます。さらに、メタデータを使用すると、必要なすべての情報をハイフンでつなぐのではなく、リソース名を意味のある長さに短縮できます。アプリケーションアーキテクトからITオペレーターまで、すべての人を巻き込み、ブレインストーミングを行い、OpenShiftのリリース時に堅実な標準を実現するために何が必要かを考えます。

2.企業ベースイメージの標準化

コンテナの重要な機能の1つは、ソフトウェアスタックのすべての部分を組み合わせて一致させる機能です。もちろん、お気に入りの種類のOSを使用してすべてを構築することはできますが、 このように行動することで、組織は大きなチャンスを逃してしまいます。結局のところ、コンテナイメージの本当にクールな点は何ですか？レイヤリング。開発者から多くの重要なタスクを削除し、画像を標準化することでそれらを解決できます。



基本的なJavaアプリケーションを例にとってみましょう。開発者がOpenJDKを間違える可能性はほとんどありません 、ただし、脆弱性の管理、ライブラリの更新、およびIT衛生に関するその他の問題があれば可能です。古いバージョンのJavaを故意に使用するなど、技術的な妥協を犠牲にしてビジネス上の問題が解決されることがよくあることは誰もが知っています。幸い、これらのタスクは企業レベルで簡単に自動化および管理できます。ベンダーのベースイメージを引き続き使用できますが 、同時に、独自のベースイメージを作成することにより、更新サイクルを設定および制御します。



上記の例に戻って、開発者がJava 11を必要とし、常に最新バージョンのJava 11を使用するようにしたいとします。次に、開始点として使用して企業ベースイメージ（registry.yourcompany.io/java11）を作成します。 OSベンダーからのベースイメージ（registry.redhat.io/ubi8/openjdk-11）。また、このベースイメージが更新されると、開発者が最新の更新を実装するのを自動的に支援します。さらに、これにより、必要なライブラリまたはLinuxパッケージを使用して標準イメージをシームレスに拡張できる抽象化レイヤーが提供されます。

3.健康と準備チェックの標準化

保守性の監視、それはほとんどどこでも必要です。人は年1回の診察で十分だと考えられています。もちろん、アプリケーションの状態はもっと頻繁にチェックする必要があり、2つの重要なことを監視する必要があります。

• アプリケーションが実行されているかどうか（ヘルスチェック）。
• アプリケーションの準備ができているかどうか（準備チェック）。

アプリケーションの監視を容易にするためのメトリックは他にもたくさんありますが、これら2つは、監視だけでなくスケーリングの基盤でもあります。正常性は通常、ネットワーク接続の可用性と、アプリケーションを実行しているホストが要求に応答する能力によって決まります。準備に関する限り、ここではすでに各アプリケーションが独自の基準に従って要求に応答する必要があります。たとえば、待ち時間が非常に短いアプリケーションを起動すると、キャッシュの更新やJVMのウォームアップに時間がかかる場合があり ます。したがって、「開始済み」と「準備完了」の応答の間の一時停止は数分に達する可能性があります。ただし、たとえば、リレーショナルデータベースを備えたステートレスREST APIの場合、これらの応答は同時に発生します。



これらのチェックで最も重要なことは、純粋なバイナリロジックから逸​​脱しないことです。ローンチとは、「ローンチの種類」がなく、ローンチされたことを意味します。完了とは準備ができていることを意味し、「そのような要求に答える準備はできているが、そのような要求はない」などのグラデーションはありません。原則は単純です：すべてまたは何も。



このようなチェックの2番目の側面は、標準化です。準備状況を確認する方法は？あなたが基準を持っていないなら、そのような単純な質問でさえ、本当の監視の悪夢になる可能性があります。Quarkus標準と SpringBoot標準がどのように異なるかを比較して ください。しかし、誰もそれを望んでいませんでしたが、標準は常に当てはまります。唯一の違いは、組織が標準を設定および実施する権限を持っていることです。

余白に注意してください。独自の基準を考案しないでください。既製のものを見つけて使用するだけ です。

4.ログの標準化

監視のトピックを続けると、安価なストレージとビッグデータソリューションの組み合わせにより、企業に新たなモンスター、つまりトータルロギングが生まれたことに注目します。以前は、これらは構造化されていない古風なコンソールログであり、長続きせず、時々作成されていました。現在、彼らはすべてを記録し、機械学習を使用してデータサイエンスを構築し、最も革新的な方法で運用と監視を最適化するよう努めています。残念ながら、明らかなことを認める必要があります。何百ものアプリケーションのログの収集を開始しようとすると、標準がまったくなく、それらについても考えずに、開始するだけでログとデータ変換を管理するためのツールに無意味で法外な費用がかかることになります。作業。つまり、あなたが理解する前でさえ「移行が完了しました」または「このブロックがトリガーされました」というメッセージは、操作とは関係がない可能性があります。



構造を標準化する必要があります。繰り返しになりますが、標準の整合性は、その正確さよりも重要です。エンタープライズ内のアプリケーションごとに個別のログパーサーを作成できる必要があります。はい、これらは複製されたものではなく、純粋に断片的なものになります。はい、特にボックス化されたアプリケーションでは、制御できない多数の例外が発生します。ただし、赤ちゃんを水と一緒に捨てないでください。詳細に注意してください。たとえば、各ログのタイムスタンプは適切なISO標準を満たしている必要があり ます。出力自体は、マイクロ秒単位の5桁目の精度でUTCである必要があります（2018-11-07T00：25：00.07387Z）。ログレベルはCAPSで発行する必要があり、要素TRACE、DEBUG、INFO、WARN、ERRORが存在する必要があります。一般に、構造を設定してから、詳細を処理します。



構造の標準化により、全員が同じルールを順守し、同じアーキテクチャパターンを使用する必要があります。これは、アプリケーションログとプラットフォームログの両方に当てはまります。また、どうしても必要な場合を除いて、既製のソリューションから逸脱しないでください。OpenShiftプラットフォームのEFKスタック（Elasticsearch、Fluentd、およびKibana）は 、すべてのスクリプトを処理できる必要があります。結局のところ、彼は理由でプラットフォームに入りました、そしてそれが更新されるとき、これはあなたが心配する必要がないもう一つのことです。

5.GitOpsへの切り替え

OpenShiftの優れた点の1つは、ここにあるすべて（文字通り、すべて）が最終的に構成またはコードのいずれかであるということです。つまり、バージョン制御システムを介して制御できます。これにより、配信方法に革命を起こし、本番環境に移行する際の官僚主義を取り除くことができます。



特に、従来のチケットベースのスキームは、完全にgitpullモデルに置き換えることができます 。..。アプリケーションの所有者が、新しい機能を実装した後にアプリケーションに割り当てられたリソースを調整したいとします。たとえば、メモリを8GBから16GBに増やします。従来のスキームでは、開発者はチケットを作成し、他の誰かが対応するタスクを完了するのを待つ必要があります。この他の誰かは、ほとんどの場合、このプロセスに価値を追加せずに、またはさらに悪いことに、このプロセスに不要な追加サイクルを追加せずに、変更を実装するプロセスに具体的な遅延を導入するだけのITオペレーターです。実際、オペレーターには2つのオプションがあります。最初に、彼はアプリケーションを確認して実行することを決定し、そのために実稼働環境に入り、要求された変更を手動で行い、アプリケーションを再起動します。

オペレーターは、原則として、実行要求のキュー全体を常に持っているため、作業自体を実行する時間に加えて、ここでは追加の遅延があります。さらに、16GBではなく160GBの入力など、人為的なエラーのリスクがあります。 2番目のオプション：オペレーターはアプリケーションに疑問を投げかけ、それによって連鎖反応を開始して、要求された変更の理由と結果を見つけます。そのため、当局が介入しなければならない場合があります。



それでは、これがGitOpsでどのように行われるかを見てみましょう。変更要求はgitリポジトリに送られ、プル要求になります。その後、開発者はこのプルリクエストを送信して（特にこれらが本番環境の変更である場合）、関係者による承認を受けることができます。このようにして、セキュリティの専門家は早い段階で関与することができ、変更のシーケンスを追跡することが常に可能です。この分野の標準は、CI / CDツールチェーンの適切なツールを使用してプログラムで実装できます。承認されると、プルリクエストはバージョン管理され、簡単に監査されます。さらに、標準プロセスの一部として実稼働前環境でテストできる ため、人的エラーのリスクを完全に排除できます。



ご覧のとおり、変更は根本的なものです。しかし、システム管理者やセキュリティスペシャリストのように、バージョン制御システムに精通している開発者にとってはそれほど新しいものではありません。しかし、彼らが新しいパラダイムを掘り下げ、その強さとシンプルさを評価するとすぐに、アイデアは大成功を収めます。

6.青写真

モノリシックアプリケーションからマイクロサービスへの移行により、アプリケーション設計パターン（パターン）の役割が強化されます。確かに、典型的なモノリシックアプリケーションはあまり分類できません。通常、REST API、バッチ処理、およびイベント駆動型があります。HTTP、FTP、kafka、JMS、 Infinispan？はい、お願いします。同時に3つの異なるデータベースでも機能します。そして、ここに多数のエンタープライズアプリケーション統合パターンが混在している場合、どのように図を作成するように注文しますか？ありえない。



しかし、そのようなモノリシックアプリケーションを別々の部分に分解すると、テンプレートははるかに簡単に区別されます。現在、4つの個別のアプリケーションがあり、それらが次のテンプレートを使用しているとします。

• DBMS内のデータを管理するためのRESTAPI。
• FTPサーバーの更新をチェックし、それをkafkaトピックに送信するバッチ処理。
• Camelは、このkafkaトピックからデータを取得し、それをRESTAPIに送信するアダプターです。
• ステートマシンのように機能するデータグリッドから収集された集約情報を公開するRESTAPI。

これで回路図ができました。スキーマを標準化できます。REST APIは、OpenAPI標準に準拠している必要があり ます。バッチジョブは、OpenShiftバッチジョブとして管理され ます。統合はCamelを使用します ..。API、バッチジョブ、AI / ML、マルチキャストアプリケーションなどのスキーマを作成できます。そして、これらのスキームを展開する方法、それらを構成する方法、使用するテンプレートを決定できます。これらの標準が設定されていれば、毎回ホイールを作り直す必要はなく、新しいビジネス機能の作成など、本当に重要なタスクに集中できます。スキームの作成は時間の無駄に思えるかもしれませんが、費やした労力は将来100倍になります。

7.APIの準備をします

APIには、マイクロサービスアーキテクチャが付属しています。また、事前に管理し、これに備える必要があります。



まず、ここでも標準が必要です。Open API標準を出発点として使用でき ますが、ジャングルを深く掘り下げる必要があります。ここでバランスを取り、多くの制限で過剰な規制に陥らないことが重要ですが。次の質問を見てください。POSTを使用して新しいエンティティを作成する場合、201または200を返す必要がありますか？ PUTではなくPOSTを使用してエンティティを更新することは許可されていますか？ 400と500の応答の違いは何ですか？ -必要な詳細レベルとほぼ同じです。



次に、サービスメッシュが必要です ..。これは本当に強力なことであり、時間の経過とともに、Kubernetesの不可欠な部分になります。どうして？トラフィックは遅かれ早かれ問題になり、データセンター内（いわゆる「東西」トラフィック）とデータセンターと外界の間（「北-」）の両方で管理する必要があるためです。南"）。アプリケーションから認証と承認を引き出して、プラットフォームレベルにする必要があります。サービスメッシュ内のトラフィックを視覚化するためのKialiの機能 、および青緑色とカナリアのアプリケーション展開スキーム、または動的トラフィ​​ック制御などが必要になります。一般に、サービスメッシュは、問題なく1日目のタスクのカテゴリに分類されます。



第三に、一元化されたAPI管理ソリューションが必要になります ..。 APIを見つけて再利用するための「1つのウィンドウ」が必要になります。開発者は、APIストアにアクセスして、必要なAPIを見つけ、その使用方法に関するドキュメントを入手できる必要があります。バージョンと非推奨を一貫して管理する必要があります。外部コンシューマー用のAPIを構築している場合、それはセキュリティと負荷管理のための南北のエンドポイントになる可能性があります。 3Scaleは、APIの収益化にも役立ちます。遅かれ早かれ、あなたの経営陣は「どのAPIがありますか？」という質問に答えるレポートを受け取りたいと思うでしょう。



結論として、標準化の領域を特定し、企業標準を文書化すること自体が困難な場合がありますが、その努力の大部分はこれに費やされるのではなく、標準への準拠を監視および実施することに費やされます。組織エントロピーの強力なブレンド そして、最初から標準に反する仕事をしている同僚と対立することへの完全に自然な抵抗。戦いは無数の小さな、時には目に見えない戦いに分かれます。必要なラベルがここにありません。この名前は完全ではありませんが、それでも十分に基準を満たしています。標準は通常、千回のカットで死にますが、組織内でそれを知っている人はほとんどいません。ある意味で、基準は運動のようなものです。誰も汗をかいたり緊張したりしたくないのですが、基準なしでは長く健康的な生活は不可能であることは誰もが知っています。



しかし、希望があり、それは自動化にあります。上記の標準はいずれも、自動化を使用して実装できます。 GitOpsプロセスは、必要なすべてのラベルと注釈がすべての関連するyamlファイルに存在することを確認できます。 CI / CDプロセスは、企業イメージの標準を適用できます。すべてを体系化し、テストし、調和させることができます。さらに、新しい標準を導入したり、既存の標準を変更したりすると、自動化を改善できます。自動化による標準化の疑いのない利点は、コンピューターが競合を回避せず、単に事実を述べることです。したがって、自動化への十分な洗練と投資により、今日あなたが多大な投資をしているプラ​​ットフォームはパフォーマンスと安定性の向上という形で、将来的にはるかに大きな投資収益率をもたらすことができます。