GitLabの管理を始める
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
GitLabの管理を始めましょう。組織とその認証を設定し、GitLabのセキュリティ対策、モニタリング、バックアップを行います。
認証
認証は、インストールを安全に保つための最初のステップです。
- すべてのユーザーに2要素認証(2FA)を実施します。GitLab Self-Managedインスタンスには2FAを使用する必要があります。
- ユーザーに次の対策を徹底させます。
- 強力で安全なパスワードを選択させます。可能であれば、パスワード管理システムに保存させるようにしてください。
- すべてのユーザーに対して2要素認証(2FA)が設定されていない場合は、各自のアカウントで有効にさせてください。ワンタイムシークレットコードは追加の防御策となり、たとえパスワードが漏洩しても不正アクセスを防げます。
- バックアップメールアドレスを追加させてください。アカウントにアクセスできなくなった場合でも、GitLabサポートチームがより迅速に対応できるようになります。
- リカバリーコードを保存または印刷させてください。認証デバイスにアクセスできない場合でも、これらのリカバリーコードを使用してGitLabアカウントにサインインできるようになります。
- SSHキーをプロファイルに追加させてください。SSHを使用すると、必要に応じて新しいリカバリーコードを生成できます。
- パーソナルアクセストークンを作成させてください。2FAを使用している場合、これらのトークンを使用してGitLab APIにアクセスできます。
プロジェクトとグループ
グループとプロジェクトを設定して、環境を整理します。
- プロジェクト: ファイルやコードのホームを指定し、ビジネスカテゴリごとにイシューを追跡および整理します。
- グループ: ユーザーまたはプロジェクトのコレクションを整理します。これらのグループを使用して、ユーザーやプロジェクトをすばやく割り当てることができます。
- ロール: プロジェクトとグループのユーザーアクセスと表示レベルを定義します。
グループとプロジェクトの概要をご覧ください。
はじめに:
その他のリソース
- Run multiple Agile teams(複数のアジャイルチームを運用する)。
- LDAPを使用してグループメンバーシップを同期します。
- 継承された権限でユーザーアクセスを管理します。最大20レベルのサブグループを使用して、チームとプロジェクトの両方を整理できます。
プロジェクトをインポートする
GitHub、Bitbucket、または別のGitLabインスタンスなどの外部ソースからプロジェクトをインポートする必要が生じる場合があります。多くの外部ソースからGitLabへのインポートが可能です。
- GitLabプロジェクトに関するドキュメントをご確認ください。
- プロジェクトの移行の代替手段として、リポジトリミラーリングも検討してください。
- 一般的な移行パスについては、移行インデックスを参照してください。
- インポート/エクスポートAPIを使用して、プロジェクトのエクスポートのスケジュールを設定します。
一般的なプロジェクトのインポート
これらのデータタイプのサポートについては、GitLabアカウントマネージャーまたはGitLabサポートに、当社の専門的な移行サービスについてお問い合わせください。
GitLabインスタンスのセキュリティ
セキュリティは、オンボーディングプロセスにおける重要な要素です。インスタンスを保護することで、作業と組織を保護できます。
ここで挙げた内容は網羅的なものではありませんが、これらを実施することでインスタンスのセキュリティを確保するための良い第一歩となります。
- 長いrootパスワードを使用し、Vaultに保存します。
- 信頼できるSSL証明書をインストールし、更新と失効のプロセスを確立します。
- 組織のガイドラインに従ってSSHキーの制限を設定します。
- 新しいサインアップを無効にします。
- 確認メールを必須にします。
- パスワードの長さ制限を設定し、SSOまたはSAMLによるユーザー管理を設定します。
- サインアップを許可する場合は、Eメールのドメインを制限します。
- 2要素認証(2FA)を必須にします。
- HTTPS経由のGitのパスワード認証を無効にします。
- 不明なサインインのメール通知を設定します。
- ユーザーとIPレートの制限を設定します。
- Webhookのローカルアクセスを制限します。
- 保護されたパスに対してレート制限を設定します。
- セキュリティアラートの通知を受け取るようにするため、メール配信設定ページからサブスクライブしてください。
- GitLabのブログページで、セキュリティのベストプラクティスについて随時確認してください。
GitLabのパフォーマンスをモニタリングする
基本的なセットアップが完了したら、続いて、GitLabのモニタリングサービスを確認します。Prometheusは、GitLabの主要なパフォーマンスモニタリングツールです。他のモニタリングソリューション(Zabbix、New Relicなど)とは異なり、PrometheusはGitLabと緊密に統合されており、広範なコミュニティのサポートがあります。
- PrometheusがキャプチャするGitLabメトリクスをご確認ください。
- GitLabのバンドルされたソフトウェアメトリクスの詳細を参照してください。
- デフォルトでは、Prometheusとそのexporterは有効になっています。ただし、サービスを設定する必要があります。
- アプリケーションのパフォーマンスメトリクスが重要な理由をご確認ください。
- Grafanaを統合して、パフォーマンスメトリクスに基づいたビジュアルダッシュボードを構築できます。
モニタリングのコンポーネント
- Webサーバー: サーバーリクエストを処理し、他のバックエンドサービスのトランザクションを支援します。CPU、メモリ、ネットワークIOトラフィックをモニタリングして、このノードの健全性を追跡します。
- Workhorse: メインサーバーからのWebトラフィックの輻輳を軽減します。レイテンシーの急増をモニタリングして、このノードの健全性を追跡します。
- Sidekiq: GitLabのスムーズな動作を支えるバックグラウンド操作を処理します。未処理のタスクキューが長くなっていないかをモニタリングして、このノードの健全性を追跡します。
GitLabデータをバックアップする
GitLabは、データを安全に保ち復元可能にするためのバックアップ手段を提供しています。GitLab Self-ManagedまたはGitLab.comのデータベースを使用するかどうかにかかわらず、データを定期的にバックアップすることが重要です。
- バックアップ戦略を決めます。
- 毎日のバックアップを作成するcronジョブの作成を検討します。
- 設定ファイルを個別にバックアップします。
- バックアップから除外するものを決めます。
- バックアップのアップロード先を決めます。
- バックアップのライフタイムを制限します。
- バックアップと復元のテストを実行します。
- バックアップを定期的に検証する方法を準備します。
インスタンスをバックアップする
バックアップ手順は、デプロイに使用したのがLinuxパッケージかHelmチャートかによって異なります。
Linuxパッケージを使用するシングルノードインストール環境をバックアップするには、1つのRakeタスクを使用できます。
LinuxパッケージまたはHelmを使用している場合のバックアップ方法の詳細をご確認ください。このプロセスはインスタンス全体をバックアップしますが、設定ファイルはバックアップしません。設定ファイルは別途バックアップしてください。暗号化キーが暗号化されたデータと一緒に保存されないように、設定ファイルとバックアップアーカイブは別の場所に保管してください。
バックアップを復元する
バックアップは、作成時とまったく同じバージョンおよびタイプ(Community Edition/Enterprise Edition)のGitLabにのみ復元できます。
- Linuxパッケージ(Omnibus)を使用している場合のバックアップと復元に関するドキュメントをご確認ください。
- Helmチャートを使用している場合のバックアップと復元に関するドキュメントをご確認ください。
GitLab SaaSをバックアップする
本番環境データベースのバックアップは、ディスクスナップショットによって1時間ごと、wal-gのベースバックアップによって24時間ごとに取得され、アーカイブまたはWALトランザクションログファイルは継続的にGCSにストリーミングされ、ポイントインタイムリカバリー(特定の時点までのリカバリー)に使用されます。
すべてのバックアップは暗号化されています。90日後、バックアップは削除されます。
- GitLab SaaSは、データを安全に保つためにバックアップを作成しますが、これらの方法を使用してユーザー自身がデータをエクスポートまたはバックアップすることはできません。
- イシューはデータベースに保存され、Git自体に保存することはできません。
- 次の方法でプロジェクトをエクスポートできます。
- ファイルエクスポートをアップロードする方式のグループエクスポートでは、グループ内のプロジェクトはエクスポートされませんが、以下の項目がエクスポートされます。
- エピック
- マイルストーン
- ボード
- ラベル
- その他の項目
直接転送またはプロジェクトのエクスポートファイルは、データのバックアップに使用しないでください。データのバックアップにプロジェクトのエクスポートファイルを使用しても、必ずしも機能するとは限らず、またすべての項目がエクスポートされるわけではありません。
代替バックアップ戦略
状況によっては、バックアップ用のRakeタスクが最適なソリューションではない場合があります。Rakeタスクがうまく機能しない場合に検討すべき代替手段を次に示します。
オプション1: ファイルシステムスナップショット
GitLabサーバーに大量のGitリポジトリデータが含まれている場合、GitLabのバックアップスクリプトでは処理が遅すぎる可能性があります。特にオフサイトの場所にバックアップする場合は、さらに遅くなることがあります。
通常、Gitリポジトリデータのサイズが約200 GBに達したあたりから速度の低下が始まります。このような場合、バックアップ戦略の一部として、ファイルシステムスナップショットの使用を検討するとよいでしょう。たとえば、次のコンポーネントを使用しているGitLabサーバーを考えてみましょう。
- Linuxパッケージを使用している。
- AWS上にホストされ、
/var/opt/gitlabにマウントされたEBSドライブでext4ファイルシステムを使用している。
このEC2インスタンスは、EBSスナップショットを取得することで、アプリケーションデータのバックアップの要件を満たしています。このバックアップには、すべてのリポジトリ、アップロード、PostgreSQLのデータが含まれます。
仮想サーバー上でGitLabを実行している場合は、GitLabサーバー全体の仮想マシン(VM)スナップショットを作成できます。仮想マシン(VM)スナップショットを作成する際は、多くの場合サーバーのシャットダウンが必要となります。
オプション2: GitLab Geo
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
Geoは、GitLabインスタンスのローカルの読み取り専用インスタンスを提供します。
GitLab Geoは、ローカルのGitLabノードを使用することでリモートチームの作業効率を高めるだけでなく、ディザスターリカバリーソリューションとしても使用できます。Geoをディザスターリカバリーソリューションとして使用する方法の詳細をご覧ください。
Geoは、データベース、Gitリポジトリ、その他のいくつかの資産をレプリケートします。Geoがレプリケートするデータタイプの詳細をご覧ください。
GitLab Self-Managedのサポート
GitLabは、さまざまなチャンネルを通じてGitLab Self-Managedのサポートを提供します。
- 優先サポート: PremiumおよびUltimateのGitLab Self-Managedのお客様は優先サポートを受けることができ、プランごとに応答時間が設定されています。優先サポートへのアップグレードの詳細をご覧ください。
- ライブアップグレード支援: 本番環境のアップグレード中に、エキスパートによる1対1のガイダンスを受けられます。優先サポートプランをご契約の場合、サポートチームのメンバーとのライブセッションを予約し、画面を共有しながらサポートを受けることができます。
GitLab Self-Managedのサポートを受ける方法は、以下のとおりです。
- GitLabドキュメントを使用し、セルフサービスで解決する。
- GitLabフォーラムに参加して、コミュニティサポートを活用する。
- チケットを送信する前に、サブスクリプション情報を確認する。
- サポートチケットを送信する。
GitLab SaaSのサポート
GitLab SaaSは24時間365日、モニタリングされています。サイトの信頼性エンジニアや本番環境を担当するエンジニアからなる専任チームが、常に稼働しています。多くの場合、ユーザーが問題に気づくまでに、すでに誰かが対応しています。
GitLab SaaSのサポートを受ける方法は、以下のとおりです。
- GitLabドキュメントにアクセスし、セルフサービスで解決する。
- GitLabフォーラムに参加して、コミュニティサポートを活用する。
- チケットを送信する前に、サブスクリプション情報を確認する。
- 以下のケースについて、サポートチケットを送信する。
- GitLabのパフォーマンスやサービスの中断に関する最新情報については、ステータスページにサブスクライブしてください。
GitLab Self-ManagedのAPIとレート制限
レート制限は、サービス拒否攻撃やブルートフォース攻撃を防ぎます。ほとんどの場合、1つのIPアドレスあたりのリクエストレートを制限することで、アプリケーションやインフラストラクチャへの負荷を軽減できます。
レート制限は、アプリケーションのセキュリティ向上にもつながります。
GitLab Self-Managedのレート制限を設定する
デフォルトのレート制限は、管理者エリアから変更できます。設定の詳細については、管理者エリアのページを参照してください。
- イシューのレート制限を定義して、ユーザーごとの1分あたりのイシュー作成リクエストの最大数を設定します。
- 未認証のWebリクエストに対して、ユーザーとIPレートの制限を適用します。
- rawエンドポイントのレート制限を確認します。デフォルトでは、rawファイルアクセスは1分あたり300リクエストに制限されています。
- インポート/エクスポートのレート制限には、6つのアクティブなデフォルト設定がありますのでご確認ください。
APIとレート制限の詳細については、APIのページを参照してください。
GitLab SaaSにおけるAPIとレート制限
レート制限は、サービス拒否攻撃やブルートフォース攻撃を防ぎます。IPブロックは通常、GitLab.comが単一のIPアドレスから異常なトラフィックを受信した場合に発生します。システムは、レート制限設定に基づいて、異常なトラフィックを潜在的に悪意のあるものと見なします。
レート制限は、アプリケーションのセキュリティ向上にもつながります。
GitLab SaaSのレート制限を設定する
デフォルトのレート制限は、管理者エリアから変更できます。設定の詳細については、管理者エリアのページを参照してください。
- レート制限のページをご確認ください。
- APIとレート制限の詳細については、APIのページを参照してください。
GitLab SaaS固有のブロックとエラー応答
- 403 Forbiddenエラー: GitLab SaaSへのすべてのリクエストでこのエラーが発生する場合は、ブロックをトリガーした可能性がある自動プロセスを調べてください。さらにサポートが必要な場合は、影響を受けたIPアドレスなどのエラーの詳細を添えて、GitLabサポートにお問い合わせください。
- HAProxy APIスロットル: GitLab SaaSは、APIリクエスト数がIPアドレスごとに1秒あたり10件を超えた場合、HTTPステータスコード429を返します。
- 保護されたパスに対するスロットル: GitLab SaaSは、保護されたパスへのPOSTリクエスト数がIPアドレスごとに1分あたり10件を超えた場合、HTTPステータスコード429を返します。
- Gitおよびコンテナレジストリの認証失敗によるBAN: GitLab SaaSは、1つのIPアドレスから3分間に30件の認証失敗リクエストを受信した場合、1時間にわたってHTTPステータスコード403を返します。
GitLabのトレーニングリソース
GitLabを管理する方法について詳しく学ぶことができます。
- GitLabフォーラムに参加して、優れたコミュニティメンバーと情報交換しましょう。
- ブログで、以下の最新情報をご確認ください。
- リリース
- アプリケーション
- コントリビュート
- ニュース
- イベント
有料のGitLabトレーニング
- GitLabの教育サービス: 専門のトレーニングコースを通じて、GitLabとDevOpsのベストプラクティスについて詳しく学ぶことができます。全コースの詳細については、カタログをご確認ください。
無料のGitLabトレーニング
- GitLabの基本: GitとGitLabの基本に関するセルフサービスガイドをご覧ください。
- GitLab University: GitLab Universityの体系化されたコースで、新しいGitLabスキルを習得できます。
サードパーティのトレーニング
- Udemy: より手頃な価格でガイド付きのトレーニングをご希望の場合は、UdemyのGitLab CI: Pipelines, CI/CD, and DevOps for Beginners(パイプライン、CI/CD、DevOpsに関する初心者向けのコース)をご検討ください。
- LinkedIn Learning: 低コストで受講できるガイド付きトレーニングの選択肢として、LinkedIn LearningのGitLabによる継続的デリバリーもご覧ください。