1.プロジェクト移行の背景
1.1なぜ「タイスイ」に着手したいのですか？
現在、同社のテスト環境、UAT環境、本番環境はすべてk8を使用して保守管理を行っており、ほとんどのプロジェクトはコンテナ化されており、長い間オンラインでスムーズに稼働しています。大小のプロジェクトのコンテナ化が完了した後、テスト、UAT、本番環境、CICDプロセスのリリースツールは徐々に統合管理を実現し、k8sに基づく内部リリースレビュープラットフォームを開発すると同時に接続しましたJiraなどのプロジェクト管理ツール。
自己研究プラットフォームがリリースされると、プロジェクトの開発進捗状況とリリースバージョンを自動的に関連付けることができます。最も重要なことは、リリース権限、統合リリースツール、リリースモードを制御でき、複数のプロジェクトのワンクリックリリースをサポートできることです。の複数のモジュールには、失敗したアプリケーションの統合ロールバックと個々のアプリケーションのロールバックも含まれます。
プロジェクトは開始以来リリースにGitRunnerを使用しており、仮想マシンの展開に基づいているため、リリースレビュープラットフォームに統合されていませんが、プロジェクトはより重要であり、より多くのサービスとマシンが含まれるため、プロジェクトはコンテナ化され、リリースツールは統合されて、会社の環境によりよく適応し、次世代のクラウドコンピューティングの開発によりよく対応します。
1.2なぜGitRunnerを放棄する必要があるのですか？
まず、Git Runnerのリリースページを見てみましょう。シンプルでさわやかな見た目ですが、問題が発生することは避けられません。
1.2.1マルチブランチ並列開発の問題
複数のブランチが並行して開発されている場合、または実稼働環境にリリースできるブランチが多数ある場合、手動展開段階でミスを犯しやすく、シリアルを見ると、もちろんこの可能性は非常に低くなります。
ただし、別の問題が発生する可能性があります。コミットまたはマージするたびにビルドがトリガーされます。GitFlowブランチフローを使用すると、並行開発、並行テスト、並行構築が同時に行われるブランチが多数存在する可能性があります。GitRunnerが仮想ベースの場合機械で作成した場合、キューイング状態になる可能性が高いですが、もちろん、このキューイングの問題は解決できます。
1.2.2マルチマイクロサービス構成のメンテナンスの問題
第二に、プロジェクトが少し大きい場合、維持するのはあまり便利ではありません。たとえば、移行するこのプロジェクト、フロントエンド、20を超えるビジネスアプリケーション、およびZuul、ConfigServer、Eurekaの約30のサービス、各サービスはGitウェアハウスに対応し、各サービスは同時に開発ブランチにあります。 GitLab CIスクリプトまたはマイクロサービスマシンをアップグレードしてノードを追加したい場合、これは面倒な作業になります。
1.2.3セキュリティの問題
最後に、セキュリティの問題があります。GitLabのCIスクリプトは通常、コードリポジトリに組み込まれています。つまり、プッシュまたはマージのアクセス許可を持っている人は誰でもCIスクリプトを自由に変更でき、予期しない結果が発生します。 、サーバーやビジネスのセキュリティも脅かします。リリースの場合、開発者は誰でもリリースボタンをクリックできます。これらは常にセキュリティリスクになる可能性があります。
ただし、これはGitRunnerが推奨されないツールであることを意味するものではありません。GitLabの組み込みAutoDevOpsと統合されたKubernetesの新しいバージョンは依然として非常に人気があります。しかし、私たちにとっては、リリースにGit Runnerを使用するプロジェクトはそれほど多くないため、リリースツールとCIスクリプトの統合管理を統合して、他のCIツールの方が適している可能性があります。
1.3なぜコンテナ化するのですか？
1.3.1ポートの競合
コンテナ化の前に、このプロジェクトは仮想マシンを使用して展開されました。各仮想マシンは2つまたは3つのマイクロサービスを開始しました。これにより、ポートの競合の問題という問題が発生しました。プロジェクトに新しいアプリケーションを追加するときは、サーバーを考慮する必要があります。ポートの競合の問題については、仮想マシンを使用してアプリケーションを展開するときに、アプリケーションの手動移行を必要とするマシンノード障害が発生する可能性があるため、各マイクロサービスのポートを同じにすることはできないことも考慮する必要があります。一部のマイクロサービスポートが同じ場合、移行プロセスブロックされている可能性があります。
また、アプリケーションの数が少ないプロジェクトの場合は、ポートのメンテナンスに問題がない場合がありますが、このプロジェクトでは30以上のマイクロサービスが関与するため、大変な苦労があります。コンテナ展開を使用する場合、各コンテナは互いに分離され、すべてのアプリケーションが同じポートを使用できるため、ポートについて心配する必要はありません。
1.3.2プログラムの健康問題
Javaプログラムを使用したことのある人のほとんどは、プログラム中断アニメーションに遭遇しました。たとえば、ポートは明らかに開いていますが、要求は処理されません。これは、プログラム中断アニメーションの現象です。仮想マシンを使用して展開する場合、適切なヘルスチェックを実行できないことがよくあります。おそらく、仮想マシンでインターフェイスレベルのヘルスチェックが実行されないため、プログラムがフリーズして自動的に処理できず、仮想マシン上にあるという問題が発生します。一部のインターフェイスレベルのヘルスチェックと処理操作を実行することは簡単なことではありませんが、特にプロジェクトにマイクロサービスが多すぎてヘルスチェックインターフェイスに一貫性がない場合は退屈なことでもあります。
ただし、k8sでは、組み込みの読み取りプローブとライブプローブを使用すると、上記の問題を簡単に処理できます。図に示すように、現在、次の3つのヘルスチェック方法がサポートされていることがわかります。
- tcpSocket：ポートヘルスチェック
- exec：指定されたコマンドの戻り値による
- httpGet：インターフェースレベルのヘルスチェック
同時に、これらのヘルスチェックの柔軟性も非常に高く、チェック間隔、エラー数、成功数、およびホストチェックパラメータをカスタマイズできます。また、上記のインターフェイスレベルのヘルスチェックhttpGetは、カスタムホスト名、要求ヘッダー、およびチェックパスもサポートします。 HTTPまたはHTTPSの構成だけでなく、k8sに付属のヘルスチェックを使用すると、多くの作業を節約でき、多くの煩わしいスクリプトを維持する必要がなくなることがわかります。
1.3.3障害回復の問題
仮想マシンを使用してアプリケーションを展開する場合、ホスト障害が発生したり、シングルノードアプリケーションを使用できなかったり、他のコピーが利用できないためにマルチノードアプリケーションが展開されたりして、高圧とサービスの遅延が発生する場合があります。まさにホストがすぐに回復できないのですが、このような問題を解決するために、手動でノードを追加したり、新しいサーバーを追加したりする必要があるかもしれません。独自のアプリケーションをデプロイする前に依存環境を準備する必要があり、場合によってはCIスクリプトを変更する必要があるためです。。。
k8sオーケストレーションを使用する場合、このような問題を気にする必要はありません。すべての障害回復および耐災害性メカニズムは、強力なk8sによって処理されます。コーヒーを飲みに行くか、この問題に対処するためにコンピューターの電源を入れるだけで、すべてが復元されます。いつものように。
1.3.4その他の小さな問題
もちろん、k8sがもたらす利便性と問題は、上記よりもはるかに優れています。コンテナミラーリングは、環境に依存する問題の解決に役立ちます。サービスオーケストレーションは、障害耐性の問題の解決に役立ちます。k8sパッケージ管理を使用できます。このツールは、ワンクリックで新しい環境を作成します。k8sサービス検出を使用して、開発者がネットワークパーツの開発に注意を払う必要がなくなります。k8sアクセス許可制御を使用して、運用および保守担当者が各サーバーのアクセス許可を管理する必要がなくなります。 k8sの強力なアプリケーション公開戦略を使用すると、ダウンタイムゼロのアプリケーション公開やアプリケーションロールバックなどを実現する方法についてあまり考える必要がなくなります。これらの便利さはすべて、私たちの行動を静かに変えています。
2.移行計画
2.1青緑色の移行
移行前にまずアーキテクチャを確認してください
ほとんどのSpringCloudアーキテクチャと同様に、NodeJSはフロントエンドとして使用され、Eurekaはサービス検出に使用され、Zuulはルーティング配布に使用され、ConfigServerは構成センターとして使用されます。このアーキテクチャは、企業で最も一般的なSpringCloudのアーキテクチャでもあり、追加のコンポーネントを使用しないため、初めて移行するときはあまり考慮しませんでした。他のプロジェクトの移行で使用した計画、つまりk8sで新しいプロジェクトを作成する計画に従いました。一連の環境（ミドルウェアはこの移行に関与しません）、つまりコンテナ化された環境で、同じドメイン名を構成してから、テスト用のホスト解決を追加します。問題がない場合は、ドメイン名を直接切り替えて移行を完了します。この方法は、プログラムリリースの青緑色の展開と同様に、最も単純で最も一般的に使用される方法です。現時点では、k8sのアーキテクチャ図に対応する新しい環境セットは次のとおりです。
テスト中、このプロジェクトは、仮想マシン環境とコンテナ環境の2つの環境セットを並列化しました。コンテナ環境は、テスターからのトラフィックのみを受信します。他のプロジェクトは大規模であるため、2つの環境は同じミドルウェアサービスのセットに接続されます。一部もこのように移行されており、テスト環境でも問題なく同じプロセスを経ているため、この方法で問題が発生することはないと考えられます。ただし、現実は常に予想とは異なります。テストプロセス中に2セットの環境が共存し、本番データの問題が発生しました。コンテナ環境の整合性がテストされておらず、ドメイン名が強制的に切り替えられなかったため、緊急時にすべてがシャットダウンされました。コンテナの問題が復元されました。時間の制約から、慎重に調査はしませんでしたが、一部のデータを修復しました。その後、一部のマイクロサービスのマスターブランチと移行中の本番コードの不一致が原因である可能性があると考えました。もちろん、それほど単純ではないかもしれません。このような問題の再発を回避するために、移行計画は変更することしかできません。
2.2グレースケール移行
上記の移行計画にいくつかの問題があったため、計画が再定義されました。これは、アプリケーションリリースのグレースケールリリースと同様に、マイクロサービスを使用してk8に移行することで前回よりも少し面倒でした。
単一のアプリケーションを移行する場合、コンテナ環境と仮想マシン環境のコードに一貫性があることを確認する必要があります。移行中、マイクロサービスはドメイン名登録の方法を採用します。つまり、各マイクロサービスは内部ドメイン名で構成され、コンテナのIPとポートを使用して登録する代わりに（k8sの内部IPと仮想マシンが接続されていないため）、ドメイン名を介してEurekaに登録されます。このときの環境を次の図に示します。 ：
このとき、ServiceCを指すドメイン名service-c.interservice.k8sがあり、ServiceCがEurekaに登録すると、そのアドレスがこのドメイン名（デフォルトはホストIP +ポート）に変更され、他のアプリケーションはこのアドレスを介してServiceCを呼び出します。ServiceCがテストするとき問題が発生しないと、仮想マシンのServiceCがオフラインになり、最終的なアーキテクチャが次の図に示されます。
Zuul、フロントエンドUI、Eurekaに加えて、他のサービスは青緑色の形式よりも複雑なグレースケールのk8sに移行されます。マイクロサービスごとに個別のサービスとドメイン名を作成し、移行の完了後に削除する必要があります。このステップの後、Eurekaを除くすべてのサービスがk8にデプロイされ、Eurekaの移行には詳細が含まれます。
2.3ユーレカの移行
このステップの後、サービスアクセスに他の問題はありません。Eureka以外のサービスがk8sにデプロイされており、Eurekaの移行移行設計にはさらに問題がある可能性があります。可用性の高いEurekaクラスターのセットをk8sに直接デプロイしてから、ConfigServerのマイクロサービス登録アドレスをk8sのEurekaアドレスに直接変更することはできません。これは、現時点では2つのEurekaクラスターが独立したゾーンであり、登録情報がないためです。共有されません。構成を変更する過程で登録情報が失われます。このとき、アーキテクチャ図は次のように表示される場合があります。
つまり、構成を置き換えるプロセスで、以前のEurekaに登録されたServiceAとk8sでEurekaに登録されたServiceBが存在する可能性があります。これにより、ServiceAはServiceBを検出できなくなります。
したがって、k8sでEurekaクラスターを構築した後、各Eurekaインスタンスの一時ドメイン名を構成してから、前のEurekaクラスターとk8sのEurekaクラスターのゾーン構成を変更して、k8sのEurekaと仮想マシンのEurekaが新しいものを形成するようにする必要があります。このようにして、登録情報が同期されます。ユーレカに登録されているかどうかに関係なく、サービスは見つかりません。現時点でのアーキテクチャ図は次のとおりです（現時点では、すべてのサービスは元のユーレカクラスターに登録されています）。
次に行うことは、マイクロサービスの構成を変更することです。現時点で変更する場所は3つあります。
- Eurekaに登録されたマイクロサービスのアドレスはより多くのコンテナIPとポートであり、ドメイン名登録は使用されなくなりました。これは、現時点ではマイクロサービスがすでにk8にあり、内部ポッドIPを介して直接接続できるためです。
- サービスによって登録されたEurekaアドレスをk8sEurekaのサービスアドレスに変更します。EurekaはStatefulSetを使用して展開し、eureka-0 / 1 /2.eureka-headless-svcを介して直接接続できます。
- すべてのマイクロサービスが移行されたら、k8s Eurekaクラスターのゾーンをeureka-0 / 1 / 2.eureka-headless-svcに変更し、他のマイクロサービスのサービス名とドメイン名を削除します。
最終的なアーキテクチャ図は次のとおりです。
3.まとめ
サービスの可用性を確保するために、移行にはしぶしぶグレースケール方式を採用しましたが、これはブルーグリーン方式よりもはるかに面倒であり、考慮すべき多くの問題があります。プログラムに問題がないことを前提に、問題が少ないだけでなく、より便利で迅速な青緑色の移行方法を使用することをお勧めします。もちろん、グレースケール方式は、大規模なプロジェクトや中断できないプロジェクトの場合、テストが必要な領域を一度に切り替えると見落とされる可能性があるため、より安全な場合があります。もちろん、いずれにせよ、アプリケーションのコンテナ化とKubernetesへの移行はより重要なことです。結局のところ、クラウドコンピューティングは未来であり、Kubernetesはクラウドコンピューティングの未来です。
元のリンク：https：//www.cnblogs.com/dukuan/p/13285941.html