2022年5月18日
DevOps
GitOpsをDevOpsのデリバリーコンポーネントの代わりと考える人もいるかもしれませんが、GitOpsはDevOpsの方法論の自然な延長線上にあるものなのです。さ らに、優れたGitOpsは、より広範なDevOpsの文化とエコシステムに依存して繁栄します。では、その違いについてもっと学びましょう。
死、税金、そしてソフトウェア開発における新しいトレンドは、最近の人生ではほとんど唯一の当てになるものです。DevOps」という言葉が13歳(元々は2009年にPatrick Deboisが作ったとされている)になるにつれ、開発者界隈ではすでに最新のホットな新語に追い越されつつある。GitOps(ウィーブワークスによる2017年の造語)です。今日はまず、いくつかの定義から始めて、GitOpsとDevOpsとは何かを比較し、そしてあなたもどちらがどちらなのかを知ることにしましょう。
ソフトウェア・デリバリーのベストプラクティスといえば、デリバリーの最適な処理方法についての議論が絶えません。あなたの組織で言えば、デリバリーへのアプローチ方法を検討する上で、多くの要因を考慮する必要があります。ほとんどの組織では、2つのアプローチを組み合わせることで、望ましい結果を得られるという結論に達するでしょう。
この質問をすると、たくさんの答えが返ってきますが、そのほとんどが正解です。何よりも、ソフトウェア開発において、より速いスピード、より高い品質、そして持続可能性を達成するための、開発チームと運用チームのコラボレーションである。これらの目標は、ツール、運用手法、文化的慣習の組み合わせによって達成される。
実際には、DevOpsは継続的インテグレーションと継続的デリバリーの包括的なプロセスであり、主にソフトウェア開発ライフサイクルを加速させるという最終目標に焦点を合わせています。どの組織においても、テスト、インフラ管理、パッケージング、アーティファクト管理、ソフトウェアデプロイメントなど、特定の領域をカバーする多くのDevOpsツールが含まれます。
この記事の実用的な目的では、DevOpsはバージョン管理から生産に至るまでの道を開き、ソフトウェアをエンドユーザーの手に届けるための反復可能で持続可能なフレームワークを提供します。
GitOpsは、デプロイや変更などは、Gitにコミットするのと同じくらいシンプルであるべきだという哲学です。GitOpsは、開発チームと彼らが選択したバージョン管理システムを中心としたアプローチを取ります。このプロセスは、マージ・リクエストに始まり、コード・レビュー、そして関連環境へのコードの自動デプロイメントと続きます。
GitOpsの方が新しいので、原則についてもう少し詳しく説明します。もっと詳しく知りたい方は、「GitOpsとは何か」という質問を深く掘り下げています。もし、改善したいと考えているのであれば、GitOps Best Practicesをチェックしてみてくださ い。
アプリケーションを実行するために必要なすべてのものは、設定ファイルやコードとしての設定に記述されます。これには、ロードバランサー、データベース設定、システム立ち上げに必要なものなど、サポートするすべてのインフラストラクチャの設定が含まれます。
バージョン管理におけるシステムの状態は、本番環境でシステムがどのように動作するかの最終決定となります。プルリクエストやマージなどのプロセス外で本番環境に加えられた変更は、真実のソースと一致するように戻されなければなりません。
純粋な実装では、メインブランチにマージされたすべての変更は、ゲーティングや承認なしで、下流の環境に直ちに現れます。
プッシュ型とは対照的に、GitOpsオペレータは、ソース管理システムとターゲット環境との間の差異を自動的に調 整します。
GitOpsは、Continuous Deliveryから真のContinuous Deploymentに移行するための、デプロイメントの新しいアプローチとして登場しました(そのニュアンスについては、こちらの解説をご覧ください)。
GitOps は、イノベーションとデリバリー・ベロシティーに対するニーズの高まりに対応するものです。DevOpsがデリバリーサイクルを標準化し、開発と運用の間に必要な一貫性をもたらしたのに対し、GitOpsは開発者にコード変更を直ちに実行する力を与え、開発者がエンドユーザーにアプリケーションサービスを提供しながらITサービスを消費する方法を変えることで、その関係を超強化しています。
従来のモデルでは、DNS、ロードバランサー、コンピュート、ストレージなどのITサービスは大きくサイロ化され、プロビジョニングに数週間から数カ月かかっていました。DevOpsは、このプロ セスを数ヶ月から数週間、時には数週間から数日に短縮しました。DevOpsを実践している成熟した組織では、多くの場合、インフラの自動化が進んでおり、中にはオンデマンドIaCモデルを利用するところも増えてきています。
GitOps が提供する基本的なシフトは、Terraform のような Infrastructure as Code ツールを使って、デプロイされたインフラを作成することです。GitOpsでは、最新のクラウドインフラの管理は、従来のゲートキーパーではなく、開発者の指先に委ねられています。
インターネット上では、両者を対立させる議論が行われていますが、実際には、両者は同僚として働くことが多いのです。高い次元では、いくつかの重要な違いがあります。
すべてのGitOpsはDevOpsですが、すべてのDevOpsがGitOpsというわけではありません。GitOpsはデリバリーにフォーカスしていますが、DevOpsはCI、可視性、ガバナンスなど、より大きな問題群に関係しているため、その範囲はより広範です。
GitOpsはより規定的なものです。DevOpsは、同じ結果を得るために多くの道を用意していますが、GitOpsは、サービスの構築とデプロイの方法について、いくつかの具体的な処方箋を用意しています。
GitOpsはDevOpsの一部なのか?GitOpsとDevOpsはどのように関係しているのでしょうか?GitOpsをDevOpsのデリバリー・コンポーネントの代わりと考える人もいるかもしれませんが、GitOpsはDevOpsの方法論の自然な延長線上にあるものなのです。さらに、優れたGitOpsは、より広範なDevOpsの文化とエコシステムに依存して繁栄しています。迅速なイテレーションと迅速なプロダクションデプロイメントは、強力なテストレジーム、メトリクスと遠隔測定に対する高い可視性、プロダクションの問題を軽減するためのよく設計されたシステムなど、より広いシステムにおいてのみ機能するのです。
DevOps は、GitOps の前に道を切り開くのに役立つかもしれません。GitOps ソリューションの採用で最も成功している企業は、すでに成熟した DevOps の実践を実施していることでしょう。GitOps プロセスを採用するまでの道のりは組織によって異なりますが、一般的には、次のような特徴を持つアプリケーションを採用するのが最も適していると言われています。
アプリケーション全体がコードで記述されています。デプロイに必要なものはすべて説明され、バージョン管理されています。ロードバランサーやデータベースなど、ゼロから立ち上げるために必要なものがすべて含まれています。GitOpsのワークフローでは、追加のパラメータは必要ありません。
モダン/クラウド・ネイティブなアプリケーション。Gitベースのアプローチでは、基盤となるインフラが宣言的なプロビジョニングをサポートできなければなりません。Kubernetesベースのインフラがまず思い浮かびますが、Kubernetes以外のシステムでも、サービスを宣言的な方法で公開することが増えてきています。
テストカバレッジの自動化。自動的にデプロイされるアプリケーションは、手動プロセスを待つことはできません。テストの実行は、CI/CDプロセスですでに完全に自動化されているはずです。
GitOps についてしっかり理解したところで、次は、デリバリーを最適化するために積極的に採用されている DevOps 技術の中で GitOps がどのように機能するかを見ていきましょう。GitOps がデリバリーを強化することで、DevOps チームが DevOps のベストプラクティスを完全に採用するためには、いくつかの重要な検討事項があります。
聞き覚えはありませんか?私たちは、クラウドのコストについてもお手伝いしています。
モニタリングとロールバックのための適切な戦略を立てる。実生産量、不適切な変更の影響を軽減することは非常に重要です。典型的なGitOpsのワークフローは、意図的にかなり無駄を省いており、これが多くの組織が本番環境へのデプロイ時にパイプラインベースのアプローチを選択する理由です。Harness Continuous Verificationで、この問題を解決するユニークな方法をご確認ください。
DevOpsは、ログに平文のパスワードが記録されてい た時代から、最新のツールは劇的に改善されましたが、適切なガバナンスと監査に愛憎半ばする関係を持っています。GitOpsにもこの問題があり、あらゆるものが記録されていますが、Gitログの数ヶ月前の変更を掘り起こすのは開発者の仕事であり、監査人の仕事ではありません。
GitOpsは高性能なマシンですが、そのような強力なものを大規模に実装するには、必然的に苦労が伴います。プロビジョニング・オペレーターからGitリポジトリの乱立、Kubernetesクラスターの管理まで、DevOpsチームには仕事がつきものです。
あらゆる技術的な問題と同様に、正しい答えに至る道はたくさんあります。技術的な質問をする前に、あなたの組織のニーズを理解しましょう。GitOpsの驚異的なデリバリースピードの恩恵を受けない組織はほとんどありませんが、あなたのビジネスを取り巻く他のドライバーに常に気を配る必要があります。
GitOps が真に機能するためには、完全に自動化された品質管理システムを導入しておく必要があります。気ままなデプロイと不十分な品質管理プロセスとは相容れません。
規制産業に携わる人にとって、ベロシティを維持しながらコンプライアンスのニーズを満たす方法で GitOps を拡張するには、効果的な実装をするのに時間がかかります。すべてのアクションはGitの履歴に記録されますが、既存の監査証跡を集約し、検索し、利用するには、ドメイン固有の知識が必要です。
GitOpsは、既存の強力なDevOpsエコシステムで成長します。何事もそうですが、実行する前に歩いてみてください。自分のプロセスがDevOpsをサポートできるほど成熟しているかどうかを検討し、オール・オア・ナッシングの提案ではないことを理解しましょう。
アプリケーション開発に対するマイクロサービス・アプローチが普及したとき、多くの組織が素早く動き、最新の技術トレンドのトップにいたにもかかわらず、解決されないまま技術的な成熟度と基礎的な問題が豊富にあることに気づきました。GitOpsについても、根本的な技術的問題をすべ て解決できるわけではないという点で、同じ真実が存在します。CI/CD、システム・アーキテクチャ、プル・リクエスト・プロセスなどが現在壊れている場合、GitOpsを採用した後も壊れ続けることになります。
このブログでは、GitOps と DevOps の細かい点、そしてそれらがより広いソフトウェア開発ライフサイクルの中でどのように位置づけられるかについて、理解を深めていただければと思います。Harnessでは、両方のアプローチをサポートしており、1つのサイズですべての解決策が得られるわけではないことを理解しています。
さらに、GitOps の強力なエンジンをサポートするために必要なソリューションの完全なプラットフォームを開発者に提供するよう取り組んでいます。テストとビルドのサイクルを最適化するCIに始まり、パイプラインに統合されたセキュリティ、そしてリリース後に組み込まれた機能フラグとモニタリング・フィードバックで締めくくられます。私たちは、あなたのすべてのDevOpsの野望をサポートします。今すぐデモを予約してください。
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。