インフラ管理を始める
(トップページはこちら)
DevOpsやSREの普及により、インフラ管理はコード化され、ソフトウェア開発のベストプラクティスが適用できるようになりました。運用チームの業務は開発に近づき、開発者もデプロイや運用を担当する時代です。GitLabは、このようなインフラ管理を統合的にサポートします。
1. GitLab DevOpsライフサイクルにおける位置づけ
インフラ管理は、リリースセクションに位置する重要なプロセスです。計画から監視まで、一貫したワークフローの中で管理できます。
2. Infrastructure as Code による管理
2.1 Terraform統合の利点
GitLabはTerraformと深く統合されており、クラウドインフラのプロビジョニングを標準化できます。主な利点は以下の3点です。
即座に開始できる環境
Terraform Backendの設定やState管理のためのストレージ準備が不要です。GitLabが自動的にHTTPバックエンドを提供し、Stateファイルを安全に管理します。
コードレビューと同じプロセス
インフラ変更もマージリクエストで管理できます。terraform planの結果がマージリクエストに表示され、レビュアーは変更内容を正確に把握できます。これにより、本番環境への意図しない変更を防げます。
# .gitlab-ci.yml の例
stages:
- validate
- plan
- apply
variables:
TF_ROOT: ${CI_PROJECT_DIR}/terraform
TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/production
validate:
stage: validate
image:
name: hashicorp/terraform:latest
entrypoint: [""]
script:
- cd ${TF_ROOT}
- terraform init -backend-config=address=${TF_ADDRESS}
- terraform validate
plan:
stage: plan
image:
name: hashicorp/terraform:latest
entrypoint: [""]
script:
- cd ${TF_ROOT}
- terraform init -backend-config=address=${TF_ADDRESS}
- terraform plan -out=plan.tfplan
artifacts:
paths:
- ${TF_ROOT}/plan.tfplan
only:
- merge_requests
apply:
stage: apply
image:
name: hashicorp/terraform:latest
entrypoint: [""]
script:
- cd ${TF_ROOT}
- terraform init -backend-config=address=${TF_ADDRESS}
- terraform apply -auto-approve
only:
- main
when: manual
モジュールレジストリによる再利用
組織内で共通のインフラパターンをTerraformモジュールとして登録し、複数のプロジェクトで再利用できます。VPCの構成、セキュリティグループの設定、データベースのプロビジョニングなど、標準化されたモジュールにより、一貫性のあるインフラを構築できます。
2.2 実践例
例えば、AWSのECSクラスタをプロビジョニングする場合、以下のようなワークフローになります。
3. Kubernetes統合
3.1 GitLab Agent for Kubernetesの機能
GitLab Agent for Kubernetesは、セキュアで柔軟なクラスタ管理を実現します。
ファイアウォール越しの接続
従来のKubernetes統合では、クラスタのAPIサーバーをインターネットに公開する必要がありました。GitLab Agentはクラスタ内から外向きの接続を確立するため、ファイアウォールやプライベートネットワーク内のクラスタも安全に管理できます。
リアルタイムな状態監視
Agentを通じてKubernetes APIに直接アクセスできるため、Pod、Deployment、Serviceなどのリソース状態をリアルタイムで確認できます。トラブルシューティング時に、GitLabのUIから直接クラスタの状態を把握できます。
プル型とプッシュ型のデプロイメント
本番環境ではプル型(GitOps)、開発環境ではプッシュ型(CI/CD)など、環境に応じた最適なデプロイ方式を選択できます。
# .gitlab/agents/production/config.yaml の例
gitops:
manifest_projects:
- id: gitlab-org/my-app
paths:
- glob: 'manifests/**/*.yaml'
default_namespace: production
reconcile_timeout: 3600s
3.2 デプロイメントフロー
3.3 クラスタの作成と接続
GitLabでは、主要なクラウドプロバイダー上にKubernetesクラスタを作成できます。また、既存のオンプレミスクラスタやマネージドKubernetesサービス(EKS、GKE、AKSなど)も接続可能です。
4. 実行可能なランブック
4.1 ランブックとは
ランブックは、システムの運用手順を文書化したものです。GitLabのランブックは単なるドキュメントではなく、実行可能な手順として機能します。
4.2 Markdownによる柔軟な記述
テキスト、コードスニペット、画像、表など、技術文書に必要な要素をすべて含められます。
## データベース障害時の復旧手順
### 1. 現状確認
接続状態を確認します。
```bash
psql -h db.example.com -U admin -c "SELECT version();"
2. レプリカへの切り替え
プライマリが応答しない場合、レプリカに切り替えます。
./scripts/failover_to_replica.sh replica-01
3. アプリケーションの再起動
接続先を変更後、アプリケーションを再起動します。
kubectl rollout restart deployment/app -n production
### 4.3 CI/CDパイプラインとの統合
ランブックは、特定の条件で自動実行できます。例えば、パイプラインの失敗時に診断スクリプトを実行したり、デプロイ成功時にヘルスチェックを実行したりできます。
```yaml
# .gitlab-ci.yml の例
deploy:
stage: deploy
script:
- ./deploy.sh
after_script:
- ./runbooks/post_deploy_check.sh
on_failure:
stage: diagnose
script:
- ./runbooks/diagnose_failure.sh
when: on_failure
artifacts:
reports:
dotenv: diagnosis.env
4.4 イシューとの連携
ランブックをイシューやマージリクエストにリンクすることで、トレーサビリティが向上します。障害対応の履歴、実行した手順、結果を一元管理できます。
4.5 実践例
例えば、データベースのバックアップ手順をランブックとして作成し、毎日のCI/CDパイプラインで自動実行できます。失敗時には自動的にイシューが作成され、担当者に通知されます。成功時にはバックアップファイルの情報がアーティファクトとして保存されます。
もっとスマートなやり方は・・・? 詳細はこちら
5. 始め方
GitLabでインフラ管理を始めるには、以下の順序で進めることをお勧めします。
- 既存のインフラをTerraformコード化する - 小さな範囲(例: 開発環境の1つのサービス)から始め、GitLabのTerraform統合を試します
- Kubernetesクラスタを接続する - GitLab Agentをインストールし、既存のクラスタに接続します
- よく使う運用手順をランブック化する - デプロイ手順、障害対応手順など、頻繁に実行する作業から文書化します
- CI/CDパイプラインと統合する - ランブックを自動実行できるようにし、手作業を減らします
これらのステップを通じて、インフラ管理の可視性、再現性、自動化レベルを段階的に向上させられます。
