GitLab の管理を始めましょう

GitLabの管理を始めましょう。組織とその認証を設定し、GitLabのセキュリティ、監視、バックアップを行います。

認証

認証はインストールをセキュアにするための最初のステップです。

  • すべてのユーザーに二要素認証 (2FA) を適用します。自己管理インスタンスには2FAを強く推奨します。
  • ユーザーが以下を実行することを確認します：
    • 強力でセキュアなパスワードを選択します。可能であれば、パスワード管理システムに保存してください。
    • 全員に設定されていない場合は、アカウントの2要素認証（2FA）を有効にしてください。このワンタイムシークレットコードは、たとえパスワードを知られても侵入者を防ぐ追加的な安全策です。
    • バックアップメールを追加します。アカウントにアクセスできなくなった場合、GitLabサポートチームが迅速に対応します。
    • リカバリーコードを保存または印刷してください。認証デバイスにアクセスできない場合、これらのリカバリーコードを使ってGitLabアカウントにサインインできます。
    • プロフィールにSSHキーを追加します。SSHを使って、必要に応じて新しいリカバリーコードを生成することができます。
    • 個人アクセストークンを有効にします。2FAを使用する場合、これらのトークンを使用してGitLab APIにアクセスできます。

プロジェクトとグループ

グループとプロジェクトを設定して環境を整理しましょう。

  • プロジェクト：ファイルやコードのホームを指定したり、ビジネスカテゴリでイシューを追跡して整理したりできます。
  • グループ：ユーザーやプロジェクトをまとめて整理できます。グループを使って、ユーザーやプロジェクトをすばやく割り当てましょう。
  • ロール：プロジェクトやグループのユーザーアクセスと可視性を定義します。

グループとプロジェクトの概要をご覧ください。

始めましょう：

その他のリソース

プロジェクトのインポート

GitHub、Bitbucket、GitLabの別のインスタンスなどの外部ソースからプロジェクトをインポートする必要があるかもしれません。多くの外部ソースはGitLabにインポートすることができます。

これらのデータタイプのマイグレーションについては、GitLabアカウントマネージャーまたはGitLabサポートまでお問い合わせください。

GitLabインスタンスセキュリティ

セキュリティはオンボーディングプロセスの重要な部分です。インスタンスのセキュリティを確保することは、あなたの仕事と組織を守ります。

これは完全なリストではありませんが、これらのステップに従うことで、インスタンスのセキュリティを確保するための確実なスタートを切ることができます。

GitLab パフォーマンスの監視

基本的なセットアップができたら、GitLabのモニタリングサービスをレビューする準備ができました。PrometheusはGitLabのコアとなるパフォーマンスモニタリングツールです。他のモニタリングソリューション（例えば、ZabbixやNew Relic）とは異なり、PrometheusはGitLabと密接にインテグレーションされており、コミュニティによるサポートも充実しています。

モニタリングの構成要素

  • ウェブサーバー：サーバーのリクエストを処理し、他のバックエンド・サービスのトランザクションを促進します。CPU、メモリ、ネットワークIOトラフィックを監視して、このノードの健全性を追跡します。
  • Workhorse：メインサーバーからのウェブトラフィックの混雑を緩和します。レイテンシ・スパイクを監視して、このノードの健全性を追跡します。
  • Sidekiq：GitLabをスムーズに動かすためのバックグラウンドオペレーションを処理します。このノードの健全性を追跡するために、長い未処理のタスクキューを監視します。

GitLabデータのバックアップ

GitLabはデータを安全に保ち、復元できるバックアップ方法を提供しています。GitLab SaaSデータベースを使用している場合でも、定期的にデータをバックアップすることが重要です。

  • バックアップ戦略を決めましょう。
  • 毎日バックアップを取るcronジョブを書くことを検討してください。
  • 設定ファイルは別途バックアップしてください。
  • バックアップから除外するものを決めます。
  • バックアップのアップロード先を決めます。
  • バックアップの有効期間を制限します。
  • テストバックアップと復元を実行します。
  • バックアップを定期的に検証する方法を設定します。

GitLabセルフマネージドインスタンスのバックアップ

Linux パッケージでデプロイしたか Helm チャートでデプロイしたかによって、ルーチンは異なります。

Linuxパッケージを使ってインストールした（シングルノードの）GitLabサーバーをバックアップする場合、単一のRakeタスクを使うことができます。

LinuxパッケージやHelmのバリエーションのバックアップについてはこちらをご覧ください。このプロセスはインスタンス全体をバックアップしますが、設定ファイルはバックアップしません。別途バックアップしてください。暗号化キーが暗号化されたデータと一緒に保管されないように、設定ファイルとバックアップアーカイブを別の場所に保管してください。

バックアップのリストア

バックアップをリストアできるのは、作成したGitLabと全く同じバージョンとタイプ（Community Edition/Enterprise Edition）のみです。

GitLab SaaSのバックアップ

GitLabデータベースとファイルシステムのバックアップは24時間ごとに行われ、ローリングスケジュールで2週間保存されます。すべてのバックアップは暗号化されています。

  • GitLab SaaSはデータのセキュリティを確保するためにバックアップを作成しますが、これらの方法を使用して自分でデータをエクスポートしたりバックアップしたりすることはできません。
  • イシューはデータベースに保存されます。Git自体には保存できません。
  • プロジェクトのエクスポートオプションを使うことができます：
  • ファイルエクスポートのアップロードによるグループエクスポートは、その中のプロジェクトをエクスポートしませんが、エクスポートはします：
    • エピック
    • マイルストーン
    • 役員一覧
    • ラベル
    • 追加アイテム

GitLab SaaSのバックアップについて詳しくは、バックアップFAQページをご覧ください。

別のバックアップ戦略

状況によっては、Rakeタスクによるバックアップが最適な解決策でない場合があります。ここでは、Rakeタスクが機能しない場合に考慮すべき代替策をいくつか紹介します。

オプション1：ファイルシステムのスナップショット

GitLabサーバーにたくさんのGitリポジトリデータがある場合、GitLabバックアップスクリプトが遅すぎると感じるかもしれません。特に、オフサイトにバックアップするときに遅くなることがあります。

Gitリポジトリのデータサイズが200GB程度になると、一般的に遅くなります。この場合、バックアップ戦略の一環としてファイルシステムのスナップショットを使うことを検討するとよいでしょう。例えば、以下のコンポーネントを持つGitLabサーバーを考えてみましょう：

  • Linuxパッケージを使用。
  • /var/opt/gitlabにマウントされたext4ファイルシステムを含むEBSドライブでAWS上にホストされています。

EC2インスタンスは、EBSスナップショットを取得することで、アプリケーションデータのバックアップの要件を満たしています。バックアップには、すべてのリポジトリ、アップロード、PostgreSQLデータが含まれます。

一般的に、仮想化サーバー上でGitLabを実行している場合は、GitLabサーバー全体のVMスナップショットを作成することができます。VMスナップショットでは、サーバーの電源を落とす必要があるのが一般的です。

オプション2：GitLab Geo

GeoはGitLabインスタンスの読み込み専用のローカルインスタンスを提供します。

GitLab GeoはローカルのGitLabノードを使用することでリモートチームの作業効率を高める一方で、ディザスタリカバリソリューションとしても使用することができます。ディザスタリカバリソリューションとしてのGeoの使い方についてはこちらをご覧ください。

Geoはデータベース、Gitリポジトリ、その他いくつかの資産をレプリケートします。レプリケーションの制限についてはこちらをご覧ください。

GitLab 自己管理のサポート

GitLabはセルフマネージドGitLabのサポートを様々なチャネルで提供しています。

  • 優先サポート：PremiumとUltimateのセルフマネジメントのお客様には、段階的なレスポンスタイムで優先的にサポートを提供します。優先サポートへのアップグレードについてはこちらをご覧ください。
  • ライブアップグレードアシスタンス：本番アップグレード中に、1対1の専門家によるガイダンスを受けることができます。プライオリティ・サポート・プランでは、サポート・チームのメンバーとの定期的なライブ画面共有セッションを受けることができます。

自己管理型GitLabのサポートを受けるには：

GitLab SaaSのサポート

GitLab SaaSをご利用の場合、サポートを受けたり回答を見つけたりできるチャンネルがいくつかあります。

  • 優先サポート：GitLab SaaSのGoldとSilverのお客様は、段階的なレスポンスタイムで優先的にサポートを受けることができます。優先サポートへのアップグレードについてはこちらをご覧ください。
  • GitLab SaaS 24時間365日モニタリング：サイトの信頼性とプロダクションエンジニアのフルチームが常に稼働しています。多くの場合、あなたがイシューに気づいた時には、すでに誰かがそれを調べています。

GitLab SaaSのサポートを受けるには：

セルフマネージメントGitLabのAPIとレート制限

レート制限は、DoS攻撃やブルートフォース攻撃を防ぎます。ほとんどの場合、単一の IP アドレスからのリクエストのレートを制限することで、アプリケーションとインフラストラクチャの負荷を減らすことができます。

レート制限はアプリケーションのセキュリティも向上させます。

セルフマネジメントGitLabのレートリミットの設定

デフォルトのレートリミットは、管理エリアから変更することができます。設定の詳細については、管理エリアのページをご覧ください。

APIとレート制限の詳細については、APIのページを参照してください。

GitLab SaaSのAPIとレート制限

レートリミットはDoS攻撃やブルートフォース攻撃を防ぎます。IPブロックは通常、GitLab.comが単一のIPアドレスから異常なトラフィックを受信した場合に発生します。システムはレートリミットの設定に基づき、異常なトラフィックを悪意のある可能性があると見なします。

レート制限はアプリケーションのセキュリティも向上させます。

GitLab SaaSのレート制限の設定

デフォルトのレートリミットは、管理エリアから変更することができます。設定の詳細については、管理エリアのページをご覧ください。

  • レートリミットのページをレビューします。
  • APIとレート制限の詳細については、APIページをお読みください。

GitLab SaaS特有のブロックレスポンスとエラーレスポンス

  • 403 forbiddenエラー：すべてのGitLab SaaSリクエストでエラーが発生する場合は、ブロックをトリガーした可能性のある自動プロセスを探してください。より詳しいサポートが必要な場合は、GitLabサポートまでエラーの詳細（影響を受けたIPアドレスを含む）をご連絡ください。
  • HAProxy API スロットル：GitLab SaaSは、IPアドレスごとに毎秒10リクエストを超えるAPIリクエストに対してHTTPステータスコード429で応答します。
  • 保護されたパスのスロットル：GitLab SaaS は、IP アドレスごとに、1 分間に 10 リクエストを超える保護されたパスでの POST リクエストに対して HTTP ステータスコード 429 で応答します。
  • Git とコンテナレジストリの認証禁止に失敗しました：GitLab SaaS は、1 つの IP アドレスから 3 分間に 30 回の認証失敗リクエストを受けた場合、HTTP ステータスコード 403 で 1 時間応答します。

GitLab トレーニングリソース

GitLabの管理方法について詳しく学ぶことができます。

  • GitLabフォーラムに参加して、才能あるコミュニティとヒントを交換しましょう。
  • ブログで最新情報をチェック
    • リリース
    • アプリケーション
    • 貢献する者
    • ニュース
    • イベント

GitLab 無料トレーニング

  • GitLabの基本：GitとGitLabの基礎に関するセルフサービスガイドをご覧ください。
  • GitLab Learn：GitLab Learnの体系的なコースで新しいGitLabスキルを学びましょう。

サードパーティトレーニング