GitLab、「Google Cloud」統合をパブリックベータ提供–認証の合理化などが可能に

今回は「GitLab、「Google Cloud」統合をパブリックベータ提供–認証の合理化などが可能に」についてご紹介します。

関連ワード （ソフトウェア等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　GitLabは米国時間4月9日、「GitLab」と「Google Cloud」の統合をパブリックベータ版として提供すると「Google Cloud Next ’24」で発表した。

　両サービスの統合に関する計画は、2023年に発表されていた。今回の統合では、認証の合理化、継続的インテグレーション／継続的デリバリー（CI/CD）の自動化、GitLabとGoogle Cloudの間を行き来する頻度の低減を可能にする。これにより、両サービスの利用に伴う摩擦を減らし、開発者がインフラの設定ではなくコードのデプロイに集中できるようにすることで、全体的な開発者体験を向上するという。

　認証の合理化では、業界標準手法であるIdentity and Access Management（IAM）とWorkload Identity Federation（WLIF）が認証で使用可能になった。組織がGitLabとGoogle Cloudを使う場合、Google CloudのリソースをGitLabからアクセスするにはサービスアカウントキーが必要になる。しかし、このアプローチは、不要なセキュリティリスクを生じ、保守負担を増加させるという。

　IAMとWLIFの利用は、システム間でのサービスアカウントの必要性をなくし、サービスアカウントキーに関連したリスクを軽減し、キーのローテーションに対する管理オーバーヘッドを最小限に抑えると同社は述べる。

　また、CI/CDパイプラインからの認証を効率化するため、新しいアイデンティティーキーワードを伴った開発者志向のアプローチも追加したという。

　GitLabとGoogle Cloudの提携は、組織がアプリケーションをGoogle Cloudにより早くデプロイできるようにすることを主な目的としているという。この目的を支援する仕組みが、ランナー構成の自動化とGoogle Cloud ServicesコンポーネントのライブラリーだとGitLabは語る。

　ランナーは、全CI/CDジョブを支える柱だが、インストール、管理、更新には時間がかかり、非効率だという。そのため、GitLabは、Infrastructure as code（IaC）のベストプラクティスに基づいて構築されたホステッドランナーを提供する。つまり、同社がランナーをプロビジョニングおよび管理する。これには、ジョブ完了済みのランナーの削除も含まれる。Google Cloud向けランナー構成の自動化により、GitLabを離れることなく、ホステッドランナーをGoogle Cloud上で利用できるようになる。

　GoogleコンポーネントのライブラリーがGitLabのCI/CDカタログで提供された。これらのコンポーネントは、「Google Kubernetes Engine」「Artifact Registry」「Cloud Deploy」を含んだGoogle Cloud Servicesでデプロイするユーザーのパイプラインを簡単に構成することを可能にする。適切なYAML構成をウェブで探す代わりに、GitLabのCI/CDカタログをブラウズし、コンポーネント構成をパイプラインの.ymlファイルにインポートするだけでよくなる。

　ソースコード管理からデプロイまでのソフトウェア開発の全ニーズに対応する単一のデータプレーンも作成された。これにより、複数システムのコンテキストを行き来することなく、製品のパフォーマンス指標、セキュリティとコンプライアンスのポリシー、ソフトウェアデリバリープロセスの最適化するためのインサイトが完全に可視化されるという。