はじめに：クラウドネイティブDevOpsとは正確には何ですか？クラウドネイティブのDevOpsは、マイクロサービス/ノーサービスアーキテクチャシステムとオープンソース標準に基づいて、言語やフレームワークに依存せず、継続的デリバリーとインテリジェントな自己運用およびメンテナンス機能を備えたクラウドネイティブインフラストラクチャを最大限に活用することであると確信しています。従来のDevOpsサービスよりも高い品質を実現し、開発と運用のコストを削減することで、R＆Dは迅速なビジネスの反復に集中できます。
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.AlibabaクラウドネイティブDevOpsアップグレードケース
まず、AlibabaチームのクラウドネイティブDevOps変換のケースを見てみましょう。
事例の背景：アリの海外eコマースチームは、多くのサイト、高いサイト建設コスト、迅速な需要変化、遅い配信、高い運用および保守コストなど、海外市場で多くの課題に直面しています。クラウドネイティブにスムーズにアップグレードする方法これらの問題を解決し、ビジネスの提供効率を向上させるためのDevOps何ですか？これが私たちの仕事です。
（1）アーキテクチャのアップグレード-サービスガバナンスのサイドカーとメッシュ
最初のステップは、アーキテクチャをアップグレードすることです。最初に、サービスガバナンスコードをアプリケーションの外部のサイドカー部分に沈め、サービスグリッドを使用して環境ルーティングなどの機能を実行します。上の図に示すように、緑色の点はサービスアプリケーションコードを表し、オレンジ色の点はサービス管理コードを表します。これらのコードは、2者間パッケージの形式でこのコンテナに格納されます。サービスガバナンスシステムの構築により、ログの収集、埋設ポイントの監視、運用および保守の介入など、多くのことが含まれます。この種のコンテナリッチコンテナと呼ばれます。問題は明らかです。ログ収集のアップグレードまたは調整であっても、アプリケーションを再度アップグレード、ビルド、およびデプロイする必要があります。ただし、これはアプリケーション自体とは何の関係もありません。同時に、懸念事項が分離されていないため、ログ収集のバグがアプリケーション自体に影響を与えます。
アプリケーションがアプリケーション自体にさらに集中できるようにするために、最初に行ったのは、すべてのサービスガバナンスコードをアプリケーションコンテナから分離してサイドカーに配置し、2つのサービスガバナンスコードとアプリケーションコードがあるようにすることでした。コンテナ。同時に、テストルーティングやリンクトラッキングなど、元のサービス管理タスクの一部をメッシュサイドカーに引き渡しました。このように、アプリケーションはスリムであり、アプリケーションはアプリケーションコード自体を気にするだけで済みます。
これの利点は、ビジネスがサービスガバナンスに依存することなくビジネス関連のアプリケーションコードに集中できることです。
これは最初のステップであり、移行の過剰なコストを心配することなくサービスガバナンスをサイドカーに徐々に移行できるため、このステップはスムーズです。
（2）アーキテクチャのアップグレード-建設デカップリング、リリースデカップリングから運用および保守デカップリングへ
2番目のステップでは、建設デカップリング、リリースデカップリング、および運用および保守デカップリングの3つのレベルのデカップリングを実行しました。
マイクロサービスとサービスレスアーキテクチャを理解している人は、ビジネスを独立して開発、テスト、リリース、運用できる場合にのみ、ビジネスをより速く、より良く実行できることを知っておく必要があります。これは他の人との結合を最小限に抑えるためです。
しかし、サービスがますます複雑になり、アプリケーションが進化し続けるにつれて、アプリケーションに含まれるビジネスコードが増えることもわかっています。たとえば、次の図のアプリケーションでは、その中の一部のコードは特定のビジネス用です。たとえば、支払いアプリケーションとして、一部はHemaの特定のニーズ用、一部はTmallの特定のニーズ用、一部は一般的なコード、またはプラットフォームコードは、すべてのビジネスシナリオに対応しています。
もちろん、開発効率の向上という観点から、ビジネスパーティは関連するビジネスコードを変更して、通信コストを削減し、研究開発効率を向上させることができます。しかし、これは新しい問題を引き起こします。特定のビジネスに変更が必要であるが、一般的なビジネスロジックが含まれていない場合は、アプリケーション全体のすべてのビジネスに完全に戻る必要もあります。この期間中に他のビジネスの変更がある場合は、統合して一緒に公開する必要があります。ビジネスに多くの変更がある場合は、統合のために全員が列に並ぶ必要があります。この場合、統合テストと通信および調整のコストは非常に高くなります。
私たちの目標は、各ビジネスを独立して開発、リリース、運用できるようにすることです。この目標をスムーズに達成するために、最初に行う必要があるのは、建設段階でそれらを切り離すことです。たとえば、比較的独立したビジネスの場合、コンテナイメージとして個別に構築し、オーケストレーションによってポッドのinitコンテナに配置します。ポッドが起動すると、メインアプリケーションコンテナのストレージスペースにマウントされます。
しかし、現時点では、アプリケーションのリリースと運用および保守はまだ一緒であるため、それらを分離する必要があります。
アプリケーションの親密さは、大きく3つのカテゴリに分類できます
。1。同じプロセスの関数呼び出しを介して通信する超親密さ
。2 。同じポッドにある異なるコンテナがIPCを介して通信する。3。
同じネットワーク内。RPC通信により、
一部のビジネスコードをビジネスの特性に応じてRPCまたはIPCサービスに段階的に分割し、それらを独立してリリースおよび運用できるようにします。
これまでに、アプリケーションコンテナの構築デカップリング、リリースデカップリング、および操作とメンテナンスのデカップリングを完了しました。
（3）IACとGitOps
3番目のステップでは、開発、運用、および保守のステータスを確認します。多くのR＆Dシナリオでは、厄介な問題は次のとおりです。さまざまな環境やビジネスには独自の構成が多数あります。リリース、運用、保守の際に、状況に応じて正しい構成を変更して選択する必要があります。この構成はおよびアプリケーションコードこれは実際にはリリース自体の一部であり、コンソールを介した従来のメンテナンスのコストは非常に高くなります。
クラウドネイティブのコンテキストでは、IaC（Infrastructure as Code）とGitOpsの方が適していると思います。各アプリケーションのコードベースに加えて、IaCリポジトリもあります。このリポジトリには、アプリケーションのイメージバージョンと関連するすべての構成情報が含まれます。コードの変更をリリースする必要がある場合、または構成の変更が必要な場合、それらはすべてコードプッシュの形式でIaCウェアハウスにプッシュされます。GitOpsエンジンは、IaCの変更を自動的に検出し、それらをOAM仕様に準拠する構成に自動的に変換してから、OAMモデルに基づいて対応する環境に変更を適用できます。開発であろうと運用と保守であろうと、I aCコードバージョンを通じてシステムにどのような変更が発生したかを知ることができ、各リリースは完了しています。
（4）リソースのBaaS化
最後のステップは、リソースのBaaS化です。
アプリケーションでリソースを使用する方法を想像してみましょう。通常、最初に対応するコンソールに移動してリソースアプリケーションを送信し、必要なリソースの仕様と要件を記述し、承認に合格した後、リソースの接続文字列と認証情報を取得します。アプリケーションの構成にリソース構成を追加します。その後変更があった場合は、対応するコンソールに移動して操作し、コードリリースに協力して承認を受けます。もちろん、そのようなリソースの操作、保守、および監視は、通常、独立したコンソールで実行されます。
リソースの種類が増えると、特に新しいサイトを構築する場合、運用と保守のコストが非常に高くなります。
リソースを宣言的に記述し、オンデマンドで使用するという原則に基づいて、IaCでこれらのリソースを定義することにより、すべてのアプリケーションによるリソースの使用を簡素化します。すべてのリソースは宣言的な方法で記述され、リソースのインテリジェントな管理とオンデマンドの使用を可能にします。同時に、すべてのリソースがクラウド上の共通のリソースと標準プロトコルを使用するため、移行コストが大幅に削減されます。このようにして、ビジネスチームをクラウドネイティブインフラストラクチャに徐々に移行します。
したがって、リソースBaaS化の2つの重要なポイントは次のとおりです。
- リソース要件、インテリジェントな管理、およびオンデマンドでの使用を宣言的に記述します
- クラウド上の共通のリソースを使用して、標準プロトコルを調整します
3.クラウドの効率性により、クラウドネイティブのDevOpsの効率的な実装が促進されます
上記で共有したのは、Aliの内部R＆DコラボレーションプラットフォームAoneに依存するAliの内部プラクティスです。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の専門家による相談の助けを借りて、迂回を回避し、達成することができます。私たちの目標をより速く..
著者：小さな攻撃Cloud Raiders
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。