この記事は 富士通クラウドテクノロジーズ Advent Calendar 2020 の6日目の記事です。
5日目は @tmtms さんの「 Ruby Net::SMTP 」という記事でした。 2021年に向けて、普段何気なく使っているSMTPをプロトコルから改めて振り返る機会になりましたね。
はじめに
仕事では、ITインフラストラクチャサービスの企画・設計・開発・運用を担当している @ysaotome です。
この記事では、会社で GItLab Enterprise Edition (EE) の Premium を導入した話を書きたいと思います。
※社内のLT大会でプレゼンした内容を改編した内容になります。
会社で GitLab Community Edition (CE) を導入したのは遡ること 6 年前の 2014 年頃になりますが、遂に今年 GitLab EE 導入に至りました。
日本においては、無償で利用可能な GitLab CE や GitLab Core の導入方法解説や採用事例は良く見るのですが、 GitLab EE の導入例を公開する会社はあまり無さそうですので、この記事が何かの参考になれば幸いです。
* Community EditionとEnterprise Editionの違い : gitlab.jp
GitHub?? GitLab?? プロジェクト管理ツール大戦
良く、 「なぜ GitHub Enterprise じゃなくて GitLab Enterprise Edition を導入したんですか？」 と聞かれるのですが、GitHub 、GitLab に限らず多くのプロジェクト管理ツールは一長一短があると感じています。
それぞれのツールにおける長所や短所を自社の状況と合わせて見たときにマッチするツールを導入する事になるんでしょう。
※最近だと、 Wikimedia財団がコード管理をGitLabへ移行する事を発表 して 話題 になっていましたね。
導入担当者として GItLab を選んだポイント
※下記内容はツール選定していた2014年当時の状況も影響していますが、多くは現時点においても変わりないと思います。
今でこそ、会社全体で統一した GitLab 環境を利用していますが、当時はプロジェクト毎に管理されており、BitbucketやGitbucket、Trac、Redmineであったり、Version Control System(VCS)すらバラバラで、SubversionやMercurialだけでなくRCSやCVSも残っている状況でした。
個人的にこの状況に 危機感 を感じていた事もあり、「まずは自分の周りから変えていこう。」と インフラ部門統一の GitLab 環境 を立ち上げて部門内で整理統合する所から始めました。
※この辺で感じていた 危機感 は、昔投稿した ニフティ株式会社にモダンな開発・運用環境を導入するために奮闘した(している)話 にまとめてあります。
この時点で GitLab CE を選んだポイントは下記でした。
- DevOps を実践する上で必要な機能を一通り持つ事
- 安価もしくは無償で検証開始出来き、開発が活発である事
DevOps を実践する上で必要な機能を一通り持つ事
今でも一番気に入っているポイントなのですが、 GitLab は自らの事を The complete DevOps platform と表現しています。
当時は文言違った気がしますが（ All in DevOps Tools だったかな？）、趣旨は変わらず、 DevOps を実践する上で必要な機能を一通り持っていると思います。
※柔軟性もあって、API連携により CI 部分を外部の別ツールに渡すといった連携をする事も出来まし、逆に GitHub 上のプロジェクトの CI を GitLab CI Runner で実行する。なんて事も出来ます。
丁度インフラ部隊として「同一作業の手作業禁止」や「ノウハウの共有」といった号令の元、スピードや品質を上げるために Infrastructure as Code を実践していた時期だったので、コード管理や CI/CD といった一連の流れのツール連携をする事自体で手間取ってしまい、本来注力したい所に集中出来ないという事態を避けたかった自分としては、 DevOps を具現化するツールチェーンを単一ツールで実現出来る GitLab はとても有りがたかったです。
コートを書き始めたばかりのメンバー比率が高かった当時のインフラ部隊において、単一ツールで統合され、迷わずに CI/CD まで実装出来る事で、抵抗感少なく利用開始出来たと思います。
ツールの運用管理面でも、他ツールの導入をしなくても良い事で大変ありがたかったです。
この点は、 GItHub も近年 GitLab を追従する様に CI/CD の要素が実装されたりと、機能一覧としては大分近似してきていると感じます。
安価もしくは無償で検証開始出来き、開発が活発である事
バラバラとは言え、既に類似するツールが多数導入されている中、まずは試験的に導入を進めるにあたって、目的実現に必要な機能が安価もしくは無償の範囲で検証開始出来る事は大事でした。
また、導入後にツールのバージョンアップが無くなる事で、「続々と登場する便利や開発手法や、時代の流れに追従出来なくなる事」が無い様、ツール自体の開発が活発である事は大事でした。
GitLab は毎月22日頃に新機能を含んだ多くの機能がリリースされており、毎月追加される機能により、出来なかった事が出来る様になったり、困っていた所が改善されるとテンションが上がります。
その後、インフラ部隊でGit環境運用していた自分と、ウェブ部隊でGit環境運用していた方との間で、 「せっかくなら、インフラ・ウェブ・ISP等事業の区別なく全事業で社内のノウハウやコードを気軽に共有出来る様にしたいね」 と盛り上がり、社内で大きいモノで8箇所ほど存在したプロジェクト管理ツールを 全社共通環境 として統合すべく動き出しました。
この時点では「エンジニア採用の事も考えて GitHub Enterprise も検討しよう」といった声や、各ツールそれぞれの良さを押す声も多く、統合は難航を極め、実際に各ツールを比較検討したのですが、自分が GitLab の The complete DevOps platform の考え方に強く共感していたのと、下記がポイントになって GitLab が選択されました。
- 日本の法規やビジネス環境に合った認可を実現出来る事
日本の法規やビジネス環境に合った認可を実現出来る事
実現したかったのは 「社員は全プロジェクトの情報を自由に閲覧・改編出来るが、パートナーや協業先は対象となるプロジェクトのみ閲覧や適切なロールを割り当てたい」 というモノです。
特に、 「パートナーや協業先の方には、対象プロジェクトにおいてはリポジトリ作成削除を含めたフル権限付与したいが、対象プロジェクト以外は派遣法や機密の問題から閲覧もさせらない」 という相反する部分です。
この難問に対して、Permissions の External users という Role とは別に存在する概念と、 Subgroups という複数のプロジェクト（リポジトリ）を束ね Role を継承出来る概念を組み合わせる事で完全に両立させる事出来ました。
運用管理面でも、全てのアカウントを OneLogin の SAML で管理している中で、アカウントの所属情報に応じて Permissions や Role を自動付与出来るのでかなり助かっています。
富士通クラウドテクノロジーズにおける利用状況
そんな課題や要望を乗り越えて、 全社共通環境 としての 全社 GitLab 環境 は 2015 年に走り出しました。
最初に作られたプロジェクトは devops/docker-gitlab という全社 GitLab 環境自体のイメージ管理をするプロジェクトでした。
徐々に個別環境を巻き取りながら利用が広がっていき、現在は名実ともに 全社 GitLab 環境 として利用されています。
- 全社 GitLab 環境の利用状況
GitLab Premium 導入の目的と効果
主目的
全社 GitLab 環境の利用が広がるにつれて、相対的な重要度も上がり GitLab CE では解決出来ない様々な問題が発生しました。
まとめると主に下記がポイントとなって GitLab EE Premium の導入を推進しました。
- 重要度の増した全社 GitLab 環境の可用性向上施策
- 重大課題発生時における早期解決対策（サポートで QA 出来る体制）
- 来るべき監査社会(第三者認証対応を求める声の高まり)への対策準備
重要度の増した全社GitLab環境の可用性向上施策
全社共通基盤として標準的に利用される様になった事で重要度が格段と上がりました。いわゆる 「GitHub.com が落ちてるから仕事にならない問題」 と類似する状態ですね。
Infrastructure as Code 化が推進され環境構築や運用で欠かせない存在になっていたり、サービスの開発・運用において、高度な自動化・自律化が推進された事で、中核を担う GitLab 環境の重要度、可用性向上が必要となりました。
GItLab CE 時点でも、 単体サーバーに対して SLA 99.99% という高い可用性を提供するニフクラ 上で環境を作っており、環境としての可用性はかなり高いのですが、パフォーマンスのスケールアウトであったり、海外を含めた多数の拠点を持っている事から地理的要素も含めたアクセス経路の可用性向上施策が必要と考えました。
重大課題発生時における早期解決対策（サポートでQA出来る体制）
GitLab は膨大なドキュメントを公開してくれており、また、基本的な部分のソースコードは公開され、公開された Issue で課題管理がされているので、探せば大抵の事が分かって解決出来ます。
ただ、全社 GitLab 環境として重要度が高まった事で、急いで原因究明したい問題も増えました。
全社 GItLab 環境の運用メンバーで解決っは出来るだろうが、時間がかかる。という課題に対して、 GitLab Inc. による Production Support 体制で課題解決の最終防衛ラインとして利用させて頂いています。
緊急度の高い課題に対して24/365で受け付けて対応を開始してくれます。
GitLab のドキュメントや公開資料は全て英語で、 サポートページ も英語での案内しか無く、サポートリクエストを作成するフォームも英語での表記しか無いため、英語エレルギーな方には厳しいかもしれませんが、一応このサポートフォームは、日本語で記載しても受付してもらえますので、その点は安心です。
既に何度かサポートリクエストを発行させて頂いていますが、単純な QA だけでなく、システム構成やそもそもの使い方といった細かい所にアドバイスも含めて回答頂けるのでとても助かります。
来るべき監査社会(第三者認証対応を求める声の高まり)への対策準備
監査において、プロジェクト管理に対するトレーサビリティ要件が増える中、都度対応するのでは無く、統合的に適切に対応し折り合いをつけられる様にしておきたいと思いました。
これは自分が結構大事に思っている所で、ISMS/PCI-DSS/SOC2/ISMSP等、第三者認証の要件がより詳細になっていく中、ある日突然、「第三者認証対応のために開発・運用フロー全部変更してください。」と言われてしまうと大打撃です。
全社 GItLab 環境によって、プロジェクトを一カ所へ集めトレーサビリティを取りやすい状況にはなったので、 Premium 導入で、利用者があまり意識せず、楽々にトレーサビリティを確保出来る様にしていきたいと考えています。
副次的効果
これはなんと言っても、Premium から追加利用可能となる、数々の開発・運用を支援する機能が使えるという点ですね。
Premium によって得られる価値については、公式サイトの Why Premium/Silver? がかなり詳しいのでおすすめです。
GitLab EE Premium 導入で苦労した事
「全社共通環境」を名乗るには全社的な利用が必要だろうという事で利用者を広げる活動。
エンジニア部門は特に何もしなくても利用が広がっていく（環境を個別に管理しなくて良くなった分楽なぐらい）。しかし、当初、非エンジニア部門での採用が凄く伸び悩みました。結局地道な導入支援活動によって、採用事例が増え全社的な共有環境と名乗れる程度の利用状況になったと思います。
今では、セールスチームが顧客毎に課題やプジェクトの進捗管理に使っていたり、サイト制作チームがキャンペーンサイトの進行管理につかっていたり、監査チームが第三者認証の監査項目対応状況の管理に使っていたりと、幅広い採用がされています。
おわりに
いかがでしょうか。
我々の GitLab Enterprise Edition Premium 導入までの道のりや考え方が何かの参考になれば幸いです。
社内では GitLab を導入している弊社ですが、 GitHub もとても良いツールだと思っていて、ソーシャル・コーディング（Social Coding）の場として弊社も活用しています。
最近もニフクラのGo言語SDKやTerraformプロバイダーを公開しました。
2020年はコロナ禍に起因する緊急事態宣言により急遽全面テレワークへ移行といった大変な事態もありましたが、ここで説明した GitLab 環境や Slack/Zoom といった環境を準備していた事で比較的スムーズに体制移行出来たかと思います。
元々個人的な危機感から推進し始めたプロジェクトですが、メンバーと楽しく仕事する環境として今後も活用していければと思っています。
