クラウド ネイティブ 2.0: 今検討すべき 3 つの DevOps 戦略

[[408760]]

[51CTO.com クイック翻訳]クラウドネイティブ アプリケーション開発と Kubernetes などのツールを急いで活用した後、DevOps チームはさらに多くのことを考慮する必要があります。多くの場合、DevOps では、Jenkins などの初期の継続的インテグレーション/継続的デプロイメント (CI/CD) パイプライン ツールを採用しており、以前は適していなかったクラウド ネイティブ シナリオにそれらを適用しようとしています。

クラウド ネイティブでは、開発者がインフラストラクチャ関連の操作を行う必要があり、現在の CD ツールでは、マイクロサービス アーキテクチャに切り替える前に開発者が持っていたアプリケーション レベルのコンテキストを復元することができず、開発ワークフローが複雑になり、展開後のアプリケーション ソフトウェアの監視可能性が高まります。 DevOps チームは、クラウド ネイティブ環境で信頼とセキュリティを構築するためにプロセスを適応させるため、特に規制の厳しい業界において、アプリケーション ソフトウェア ポリシー管理における新たな課題にも直面しています。同時に、クラウドと Kubernetes の導入が再び非常に面倒な手作業に直面することになるため、DevOps では人為的エラーを排除するための自動化アプローチと戦略を再評価する必要があります。

ここでは、クラウド ネイティブ環境をより効果的に使用できるように、DevOps がクラウド ネイティブ 2.0 の将来に備えて (早めに) 戦略を慎重に検討する必要がある 3 つの領域を示します。

1. 相互運用性と構成性を高めたCI/CD

利用可能なオプションの範囲が拡大していることを考えると、Cloud Native 2.0 環境での CI/CD ツールの選択と実装はより重要な問題になりますが、これは戦略的な課題でもあります。一部のツールは開発パイプラインの早い段階で利点を提供し、他のツールは後になって利点を提供します。 CI から CD、リリース自動化 (RA) まで、DevOps チームは、潜在的なツールとそれらを組み合わせてエレガントで調和のとれたパイプラインを組み立てる方法を検討する必要があります。残念ながら、多くの DevOps チームがよく知っているように、これは言うほど簡単ではありません。一部のエンドツーエンド ソリューションでは、ロックインやその他の望ましくない側面が生じる可能性があり、クラス最高の断片的なソリューションがうまく連携しない場合もあります。

近い将来、相互運用性がさらに高まることを期待し、予測しています。 Cloud Native 2.0 の一部として、CI、CD、RA、さらにはガバナンスやコンプライアンスのソリューションも完全にプラグアンドプレイです。その時点で、DevOps は特定のニーズに最も適したソリューションを選択でき、それが機能するようになります。

今のところ、このプラグアンドプレイのビジョンが実現するのを待つ間、コンポーザビリティは DevOps が将来のソリューションに求めるべき重要な側面です。パイプライン コンポーネントが簡単に相互作用できるため、無数の使用シナリオが簡素化され、重要なセキュリティとコンプライアンスの問題も解決されます。クラウドネイティブ パイプライン全体にポリシー主導の制限を適用するには、幅広い構成可能性を実現する DevOps ツールチェーンが必要です。幸いなことに、多くの CI/CD システムはこれをうまく実行しており、拡張機能とプラグインによってパイプライン全体の構成可能性を実現しています。

2. アプリケーションポリシー管理を活用する

重要なセキュリティとガバナンスのルールが遵守されるようにするには、アプリケーションの開発と展開のライフサイクル全体にわたってポリシーを設定する必要があります。脆弱性をもたらす可能性のある手順をスキップすることはできません。クラウド ネイティブ環境で作業する DevOps チームにとって、Kubernetes とその代替手段の複雑さにより、これらの戦略の実装はより困難になります。

DevOps の戦略としては、1) 開発者を Kubernetes の複雑さから保護し、2) リスクから保護できるツールとフレームワークを活用する必要があります。たとえば、ビルド イメージを Docker Hub などの Docker リポジトリにデプロイすると、脆弱性やその他のセキュリティ障害を検出して報告するためのツールが含まれます。内部ソースコードスキャンにより、マージリクエストの脆弱性を特定できます。ツールは、チーム間のコラボレーションと重要な知識の共有もサポートする必要があります。構造的には、DevSecOps を開発チームに組み込み、通常のプロセスの一部としてセキュリティに対処するのが理にかなっています。

隣接する DevSecOps とツールが Kubernetes 成果物の生成や環境の維持などの課題に対処するため、開発者はコードの作成とビジネス上の問題の解決に集中できます。それが彼らのやりたいことであり、目的なのです。強力なアプリケーション フレームワークを備えたツールを使用して、危険なアクティビティやエラーを自動的に禁止する DevSecOps コントロールのポリシーを定義および適用する必要もあります。アプリケーション ポリシー管理フレームワークを導入すると、開発者が誤って汚染されたイメージを展開しようとしても、展開できなくなります。このようなフレームワークは、セキュリティ ポリシーとリソース制限を適用し、セキュリティ スキャンを有効または無効にし、CVE にフラグを付けるか無視するかを管理し、クラウド ネイティブ環境全体でのチームの Kubernetes およびサービスへのアクセスを制御できます。

3. 自動化と監査のバランスをとる

アプリケーション開発における人為的エラーは生産性を低下させる可能性があります。多くの場合、より大きな懸念はセキュリティとコンプライアンスのリスクの増大です。自動化と監査には興味深い関係があります。自動化により人的エラーが削減され、監査により自動化によって発生したエラーを人が修正できるようになります。

驚くべきことに、クラウド ネイティブ環境によって、非常に手動のプロセスへの回帰が促進され、開発者の生産性にとって新たな自動化がさらに重要になっています。たとえば、Helm チャートと YAML ファイルを備えたオリジナルの Kubernetes では、大量のスクリプト作成と手動によるデプロイメント作業が必要でした。 (Kubernetes に関する私自身の経験から言うと、YAML ファイルの記述でミスをするたびに 1 ドルずつ瓶に入れたら、瓶が何個もいっぱいになると思います。) 開発者が気にしない Kubernetes の細かい部分を抽象化する自動化は歓迎されます。

自動化は、セキュリティの問題のスキャン、コードが安全で検証済みのライブラリを使用しているかどうかの確認など、望ましい結果を生み出す繰り返し可能なタスクに最適です。効果的な自動化は、設定して忘れてしまうような自動化ではなく、監視とメンテナンスが必要です。たとえば、自動化されたシステムは実際には無害な CVE にフラグを立てる可能性があり、システムを改善するには人間の判断が必要になります。信頼できない悪いプロセスを自動化することは完全に可能であり、その結果、最終的にさらに多くの問題が発生するだけです。正しい戦略は、まず信頼できる手動システムを開発し、必要に応じて自動化することです。

構成可能な CI/CD ソリューションと慎重な戦略を活用して安全で合理化されたアプリケーション開発を自動化することにより、DevOps はクラウドネイティブ環境の課題を最小限に抑えながら、開発者の創造性と生産性を高めることができます。

原題: Cloud Native 2.0: 今検討すべき 3 つの DevOps 戦略、著者: Henrik Rosendahl

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。