1.クラウドネイティブDevOpsとは
まず、簡単な例を使用して、クラウドネイティブのDevOpsとは何か、およびそれがDevOpsとどのように異なるかを理解しましょう。
上の写真は屋台です。写真のシェフは、カット、フライ、各種食品の製作、販売に一生懸命取り組んでいます。原材料の購入から加工、販売、アフターセールスまで、1〜2名で完了します。これは非常に典型的なDevOpsシナリオであり、チームがすべてをエンドツーエンドで処理します。この場合、シェフのレベルが比較的高く、販売能力が高い場合、高効率、低廃棄物を実現できます。しかし、問題はスケーリングが難しいということです。そのプロセスは非標準であるため、シェフには強い個人的な能力が必要です。
この南京の屋台の写真を見てみましょう。名前には屋台がありますが、それは明らかに上記の屋台ではありません。南京の屋台に足を踏み入れると、南京の屋台のシェフは、顧客により良い料理を提供し、新しい料理を開発してテストし、少数のユーザーを通じてそれらを宣伝することに集中できることがわかります。ユーザー数が増減しても、すぐに適応できます。ショップの拡大も迅速に行うことができます。これは、クラウドネイティブのDevOpsとして理解できます。
では、クラウドネイティブのDevOpsとは正確には何ですか？クラウドネイティブのDevOpsは、マイクロサービス/ノーサービスアーキテクチャシステムとオープンソース標準に基づいて、言語やフレームワークに依存せず、継続的な配信とインテリジェントな自己運用および保守機能を備えたクラウドネイティブインフラストラクチャを最大限に活用して、従来のDevOpsよりも高いレベルを実現すると考えています。サービス品質と開発および運用コストの削減により、R＆Dは迅速なビジネスの反復に集中できます。
上の図に示すように、クラウドネイティブDevOpsは2つの原則に基づいています。オープンスタンダードへの準拠、言語とフレームワークは関係ありません。マイクロサービス/ノーサービスアーキテクチャ、サーバーレスインフラストラクチャBaaS / FaaSの2つの基盤があり、インテリジェントな自己運用とメンテナンスの2つの機能を提供します。 、連続配信。
オープンスタンダードに準拠しているため、言語やフレームワークはそれとは何の関係もありません。特定の言語やフレームワークと比較して、テクノロジーのアップグレードや反復の際の柔軟性、開発力、活力が向上し、エコロジーが向上します。
2つの基盤：マイクロサービスとノーサービスアーキテクチャに基づいて、DevOpsを可能にすることができます。サーバーレスベースのインフラストラクチャは、リソース指向と需要指向であり、柔軟性が向上します。
これらの2つの原則と2つの基盤に基づいて、継続的な配信とインテリジェントな自己運用および保守という2つの機能が実現されます。
2.アリババクラウドネイティブDevOpsアップグレードケース
まず、AlibabaチームのクラウドネイティブのDevOps変換のケースを見てみましょう。
事例の背景：アリの海外eコマースチームは、多くのサイト、高いサイト建設コスト、迅速な需要の変化、遅い配信、高い運用および保守コストなど、海外市場で多くの課題に直面しています。これらの問題を解決し、ビジネス配信効率を向上させるためにクラウドネイティブDevOpsにスムーズにアップグレードする方法何？これが私たちの仕事です。
（1）アーキテクチャのアップグレード-サービスガバナンスのサイドカーとメッシュ
最初のステップはアーキテクチャをアップグレードすることです。最初に、サービスガバナンスコードをアプリケーションの外部のサイドカー部分に沈め、サービスグリッドを使用して環境ルーティングなどの機能を実行します。上の図に示すように、緑色の点はサービスアプリケーションコードを表し、オレンジ色の点はサービス管理コードを表します。これらのコードは、2者間パッケージの形式でこのコンテナに格納されます。サービスガバナンスシステムの構築に伴い、ログの収集、埋設ポイントの監視、運用と保守の介入など、多くのことが含まれています。この種のコンテナリッチコンテナと呼ばれます。問題は明らかです。ログ収集のアップグレードまたは調整であっても、アプリケーションを再度アップグレード、ビルド、およびデプロイする必要があります。ただし、これはアプリケーション自体とは何の関係もありません。同時に、懸念事項が分離されていないため、ログ収集のバグがアプリケーション自体に影響を与えます。
アプリケーションがアプリケーション自体にさらに集中できるようにするために、最初に行ったのは、すべてのサービスガバナンスコードをアプリケーションコンテナから分離してサイドカーに配置し、2つのサービスガバナンスコードとアプリケーションコードがあるようにすることでした。コンテナ内。同時に、テストルーティングやリンクトラッキングなど、元のサービス管理タスクの一部をメッシュサイドカーに引き渡しました。このように、アプリケーションはスリムであり、アプリケーションはアプリケーションコード自体を気にするだけで済みます。
これの利点は、サービスガバナンスに依存することなく、ビジネスがビジネス関連のアプリケーションコードに集中できることです。
これは最初のステップであり、移行の過剰なコストを心配することなくサービスガバナンスをサイドカーに徐々に移行できるため、このステップはスムーズです。
2）アーキテクチャのアップグレード-構造のデカップリング、リリースのデカップリングから運用および保守のデカップリングまで
2番目のステップでは、3つのレベルのデカップリングを実行しました。構築デカップリング、リリースデカップリング、および運用と保守のデカップリングです。
マイクロサービスとサービスレスアーキテクチャを理解している人は、ビジネスを独立して開発、テスト、リリース、および運用できる場合にのみ、ビジネスをより速く、より良く実行できることを知っておく必要があります。これは他の人との結合を最小限に抑えるためです。
しかし、サービスがますます複雑になり、アプリケーションが進化し続けるにつれて、アプリケーションに含まれるビジネスコードが増えることもわかっています。たとえば、次の図のアプリケーションでは、その中の一部のコードは特定のビジネス用です。たとえば、支払いアプリケーションとして、一部はHemaの特定のニーズ用、一部はTmallの特定のニーズ用、一部は一般的なコードです。 、またはプラットフォームコードは、すべてのビジネスシナリオに対応しています。
もちろん、開発効率の向上という観点から、ビジネスパーティは関連するビジネスコードを変更して、通信コストを削減し、R＆D効率を向上させることができます。しかし、これは新しい問題を引き起こします。特定のビジネスに変更が必要であるが、一般的なビジネスロジックが含まれていない場合は、アプリケーション全体のすべてのビジネスに完全に戻る必要もあります。この期間中に他のビジネスの変更がある場合は、彼らは一緒に統合して公開する必要があります。ビジネスに多くの変更がある場合は、統合のために全員が列に並ぶ必要があります。この場合、統合テストと通信および調整のコストは非常に高くなります。
私たちの目標は、各事業を独立して開発、リリース、運営できるようにすることです。この目標をスムーズに達成するために、最初に行う必要があるのは、構築段階でそれらを分離することです。たとえば、比較的独立したビジネスの場合、コンテナイメージとして個別に作成し、オーケストレーションによってポッドのinitコンテナに配置します。ポッドが起動すると、メインアプリケーションコンテナのストレージスペースにマウントされます。
しかし、現時点では、アプリケーションのリリースと運用および保守はまだ一緒であるため、それらを分離する必要があります。
アプリの親密さは、大きく3つのカテゴリに分類できることがわかっています。
1.スーパークローズ、同じプロセスの関数呼び出しを介して通信します
2.同じポッド内の異なるコンテナがIPCを介して通信し
ます3.同じネットワーク内で、RPCを介して通信します
一部のビジネスコードは、ビジネスの特性に応じてRPCサービスまたはIPCサービスに段階的に分割できるため、独立してリリースおよび運用できます。
これまでに、アプリケーションコンテナの構築デカップリング、リリースデカップリング、および操作とメンテナンスのデカップリングを完了しました。
（3）IACとGitOps
3番目のステップでは、開発、運用、および保守のステータスを確認します。多くのR＆Dシナリオでは、厄介な問題は次のとおりです。さまざまな環境やビジネスには独自の構成が多数あります。リリース、運用、および保守中に、状況に応じて正しい構成を変更および選択する必要があります。この構成とアプリケーションコードこれは実際にはリリース自体の一部であり、コンソールを介した従来のメンテナンスのコストは非常に高くなります。
クラウドネイティブのコンテキストでは、IaC（コードとしてのインフラストラクチャ）とGitOpsがより良い選択であると考えています。各アプリケーションのコードベースに加えて、IaCリポジトリもあります。このリポジトリには、アプリケーションのイメージバージョンと関連するすべての構成情報が含まれます。コードの変更をリリースする必要がある場合、または構成の変更が必要な場合、それらはすべてコードプッシュの形式でIaCウェアハウスにプッシュされます。GitOpsエンジンは、IaCの変更を自動的に検出し、それらをOAM仕様に準拠する構成に自動的に変換してから、OAMモデルに基づいて対応する環境に変更を適用できます。開発であろうと運用と保守であろうと、I aCコードバージョンを通じてシステムにどのような変更が発生したかを知ることができ、各リリースは完了しています。
（4）リソースのBaaS化
最後のステップは、リソースのBaaS化です。
アプリケーションでリソースを使用する方法を想像してみましょう。通常、最初に対応するコンソールに移動してリソースアプリケーションを送信し、必要なリソースの仕様と要件を記述し、承認に合格した後、リソースの接続文字列と認証情報を取得します。アプリケーションの構成にリソース構成を追加します。その後に変更があった場合は、対応するコンソールに移動して操作し、コードリリースを確認して承認します。もちろん、そのようなリソースの操作、保守、および監視は、通常、独立したコンソールで実行されます。
リソースの種類が増えると、特に新しいサイトを構築する場合、運用と保守のコストが非常に高くなります。
リソースを宣言的に記述し、オンデマンドで使用するという原則に基づいて、これらのリソースをIaCで定義し、すべてのアプリケーションによるリソースの使用を簡素化します。すべてのリソースは宣言的な方法で記述され、インテリジェントな管理とリソースのオンデマンド使用を可能にします。同時に、すべてのリソースがクラウド上の共通のリソースと標準プロトコルを使用するため、移行コストが大幅に削減されます。このようにして、ビジネスチームをクラウドネイティブインフラストラクチャに徐々に移行します。
したがって、リソースBaaS化の2つの重要なポイントは次のとおりです。
- リソース要件、インテリジェントな管理、およびオンデマンドでの使用を宣言的に説明します
- クラウド上の共通のリソースを使用して、標準プロトコルを調整します
3.クラウドの効率により、クラウドネイティブのDevOpsの効率的な実装が促進されます
上記で共有したのは、Aliの内部プラクティスであり、Aliの内部R＆DコラボレーションプラットフォームAoneに依存しています。AoneのパブリッククラウドバージョンはAliyunクラウドエフェクトです。どうすればAlibabaCloudクラウドエフェクトを介してクラウドネイティブのDevOpsを実装できますか？
前のケースから、クラウドネイティブのDevOpsの実装は、メソッド、アーキテクチャ、コラボレーション、エンジニアリングを含む体系的なプロジェクトであることがわかります。その中で、クラウドネイティブのDevOpsの実装は、リーンデリバリーのカテゴリに属します。
上の図は、クラウド効果のクラウドネイティブDevOpsソリューション図です。
ここでは、ユーザーを2つの役割に分けます。
- テクニカルリードまたはアーキテクト
- 開発、テスト、運用、保守などを含むエンジニア。
テクニカルディレクターまたはアーキテクトとして、彼は企業全体のR＆D動作を定義および制御する必要があります。広い観点から、R＆Dプロセスには、操作可能、監視可能、管理可能、および変更可能の4つの側面が含まれます。
まず、アジャイルR＆Dを採用するか、リーンカンバンを採用するかなど、企業のR＆Dコラボレーションモデルを定義します。次に、使用する必要のあるクラウド製品や、これらのクラウド製品の調整方法や管理方法など、製品アーキテクチャ全体を習得する必要があります。次に、チームのR＆Dモデルを決定します。R＆Dコラボレーションの方法、R＆D品質の制御方法などです。3番目のステップでは、リリース戦略、グレースケールリリースとブルーグリーン展開のどちらを使用するか、グレースケール戦略とは何かなどを決定する必要があります。最後に、サービスがアクセスする必要のある監視プラットフォーム、サービスステータスの検出方法、グローバル監視構成など、サービスの監視戦略です。
最前線の開発、テスト、運用および保守のエンジニアは、スムーズで効率的な作業プロセスに重点を置いています。クラウドエフェクトプロジェクトコラボレーションプラットフォームが要件またはタスクを受け取った後、クラウドエフェクトを介してコーディング、送信、構築、統合、リリース、およびテストし、プレリリースおよび本番環境にデプロイし、管理者がR＆Dモードとリリースを構成できます。戦略は本当に上陸しました。同時に、各環境は、人間による調整やプルなしで、自動的にトリガーされ、フローされます。
R＆Dプロセス全体で生成されるデータは有機的な全体であり、大量のデータインサイトを生成し、チームを継続的な改善に駆り立てることができます。チームがR＆Dプロセスでボトルネックや混乱に遭遇した場合、クラウド効率の専門家チームから専門的な診断アドバイスやR＆Dガイダンスを得ることができます。
要約すると、クラウド効率のクラウドネイティブDevOpsソリューションは、専門家が推奨するベストプラクティスに基づいて、ALPD手法によって導かれ、完全なDevOpsツールチェーンに深く統合されて、企業がクラウドネイティブDevOpsに徐々に移行できるようにします。
次に、特定のケースを見ていきます。
インターネット会社には、約30人の研究開発チームがあり、常勤の運用および保守担当者はいません。その製品には、20を超えるマイクロサービスと数十のフロントエンドアプリケーション（Web、アプリレット、アプリなど）が含まれます。そのビジネスは非常に急速に成長しています。急速に成長する顧客と増大する需要に直面して、Jenkins + ECSに基づく元のスクリプトベースの展開方法は、需要、特にゼロダウンタイムの展開とアップグレードの問題を徐々に満たすことができませんでした。 。その結果、私はクラウド効率の助けを必要とし始め、最終的にクラウド効率クラウドネイティブDevOpsに完全に移行しました。
このR＆Dチームは、次の3つの大きな問題に直面しています。
- 多数のお客様と多くの緊急のニーズ
- フルタイムの運用と保守はなく、K8Sなどのクラウドネイティブテクノロジーには高い学習しきい値があります
- 複雑なITインフラストラクチャ、時間と労力を要するリリース
これらの問題に対応するため、クラウドの効率は、基本機能、リリース機能、運用および保守機能の3つの側面から始まります。
まず、Alibaba Cloud ACKを導入して、既存のECSリソースの上にインフラストラクチャをアップグレードし、アプリケーションをコンテナ化に変換します。サービスガバナンスとアプリケーションアーキテクチャの観点から、Spring CloudファミリバケットはSpringBootに単純化され、サービスの検出とガバナンスはK8S標準機能によってサポートされます。
第二に、自動コンテナ展開はクラウド効果パイプラインを通じて実現され、グレースケール展開戦略を使用して、グレースケールオンライン、自動拡張、および障害発生時の自動再起動を実現できます。同時に、クラウド効率パイプラインに基づいて、ダウンタイムをゼロにし、コストを迅速にロールバックして、マシンコストを節約できます。同時に、企業内に常勤の運用・保守要員がいないという問題も解決されます。
第三に、クラウド効率の自動化された組立ラインとブランチ保護の標準的な研究開発モデル（コードレビュー、コード検査、テストカードポイントなど）を通じて、フィードバック効率とリリース品質を向上させます。
次の図は、ソリューション全体のアーキテクチャ図です。
4.クラウドネイティブDevOpsアップグレードパス
クラウドネイティブDevOpsの実装を5つの段階に分けます。
最初の段階：すべての手動配信と操作および保守。これは私たちの初期段階です。アプリケーションアーキテクチャはまだサービスの変革を受けておらず、クラウドインフラストラクチャやIaaSのみを使用していません。継続的な統合、テストの自動化、手動による展開、リリース、手動による操作と保守はありません。この段階にとどまっている企業は少ないと思います。
第2段階：ツールベースの配信と操作および保守。最初に行うことは、アプリケーションアーキテクチャを提供し、マイクロサービスアーキテクチャを使用してサービスの品質を向上させることです。次に、gitlab、jenkins、その他のアイランドスタイルのツールなどのいくつかの問題を解決するための研究開発ツールを導入します。同時に、単一モジュールの継続的な統合の実装を開始しましたが、通常、自動化された品質の行き詰まりはなく、リリースは自動化されたツールによって支援されることがよくあります。
第3段階：限られた継続的な配達と自動化された操作とメンテナンス。基本機能をさらに改善し、インフラストラクチャをCaaSベースのコンテナに変換しました。一方、クラウドエフェクトDevOpsなどのツールプラットフォームを使用してすべてのデータの完全な相互通信を実現するなど、研究開発データを開くための完全なツールチェーンの導入を開始しました。リリース機能の観点からは継続的な展開を実現できますが、ある程度の手動介入が必要です。このとき、自動テストが主流になり、サービス全体を監視でき、運用と保守はサービス指向で宣言的なものになります。
第4段階：継続的な配送と手動による自己操作および保守。さらに、開発学生にビジネス開発に集中してもらいます。まず、アプリケーションアーキテクチャに多数のサービスレスアーキテクチャを採用し始め、無人の継続的な展開を実現しました。リリースのグレースケールとロールバックは、介入によって可能な限り自動化できます。 。観察能力は、アプリケーションレベルからビジネスレベルにアップグレードされ、ビジネスの観察可能性を実現し、手動の支援で自己運用と保守の一部を実行できるようになります。
第5段階：リンクを介した継続的な配信と自己運用および保守。これが私たちが求める究極の目標です。この段階では、すべてのアプリケーションとインフラストラクチャがサービスレスアーキテクチャを採用し、リリースロールバックやグレースケールを含むエンドツーエンドの無人連続配信も自動化されています。技術的な設備とサービスは完全に自己運用され、維持されています。 。開発者は、実際にはビジネスの開発と反復についてのみ気にする必要があります。
しかし、詳細には悪魔がいます。もちろん、実際に着陸するときに解決しなければならない問題はまだたくさんあります。CloudEffectなどのツールプラットフォームとALPDの専門家による相談の助けを借りて、迂回を回避し、目標をより早く達成できます。 。
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。