GitLab Duo Self-Hosted: AWS Bedrock BYOMデプロイガイド
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
このガイドでは、EC2インスタンスから動作するDuo Agent Platform (DAP)フローまで、AWS Bedrockを使用してセルフホスト型のAIモデルでGitLabをデプロイする手順を説明します。すべてのコマンドはコピー&ペースト可能です。すべてのよくある間違いは文書化されています。
このガイドでは、単一のEC2インスタンス上でGitLab (Docker) とAI Gateway (Docker Compose) を並行して実行し、AWS BedrockをLLMプロバイダーとして使用します。このアーキテクチャは、概念実証および評価デプロイに適しています。
本番環境でのデプロイについては、リファレンスアーキテクチャを参照してください。
前提条件
開始する前に、以下が必要です:
| 要件 | 詳細 |
|---|---|
| AWS account | ターゲット地域 (us-east-1推奨) でのBedrockアクセス。 |
| EC2 instance | t3.xlarge最小 (4 vCPU、16 GB RAM)。t3.2xlarge (8 vCPU、32 GB) が本番環境に推奨されます。 |
| ドメイン名 | EC2インスタンスを指す2つのDNSレコード: gitlab.example.comとaigw.example.com。 |
| GitLab license | PremiumまたはUltimate。Classic Duo機能 (チャット、コード提案) には、Duo seat assignmentが必要です。オンラインライセンス (GitLab 18.9以降) を使用するDAPは、usage-based billing through GitLab Creditsを使用し、Duo Enterpriseシートは必要ありません。オフラインライセンスでDAPを使用する場合は、ELAオプションについてGitLabアカウントチームにお問い合わせください。 |
| SSH access | EC2インスタンスへ。 |
| Security group | ポート80、443、8443が受信開放されています。 |
アーキテクチャの概要
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart LR
accTitle: GitLab Duo Self-Hosted with AWS Bedrock architecture
accDescr: Shows the flow from a browser to GitLab on EC2, which connects to the AI Gateway sidecar, which routes LLM requests to AWS Bedrock.
A[Browser / IDE] --> B[GitLab EE<br/>Port 443]
B --> C[AI Gateway<br/>Port 5052 HTTP<br/>Port 50052 gRPC]
C --> D[AWS Bedrock<br/>Claude / GPT]
AI Gatewayは、GitLabと並行してサイドカーコンテナとして動作します。組み込みのGitLab NGINXはHTTPSとgRPCのトラフィックをAI Gatewayにプロキシします。AI GatewayはLLMリクエストをAWS Bedrockに転送します。
ポート8443はDAPフローに必要です。DAPはgRPCを使用してAI Gateway Duo Workflow Service (DWS) と通信します。GitLab NGINXは、ポート8443のgRPC TLSをAI GatewayのgRPCポート (50052) にプロキシする必要があります。
ステップ1: AWSインフラストラクチャをプロビジョニングする
EC2インスタンスを起動する
Ubuntu 22.04以降のインスタンスを以下で起動します:
- Instance type:
t3.xlarge(最小) またはt3.2xlarge(推奨) - ストレージ: 100 GB gp3
- AMI: Ubuntu Server 22.04 LTSまたは24.04
Security groupを設定する
これらの受信ポートを開放します:
| ポート | プロトコル | ソース | 目的 |
|---|---|---|---|
| 22 | TCP | あなたのIP | SSH |
| 80 | TCP | 0.0.0.0/0 | HTTP (Let’s Encrypt検証) |
| 443 | TCP | 0.0.0.0/0 | HTTPS (GitLabおよびAI Gatewayプロキシ) |
| 8443 | TCP | 0.0.0.0/0 | gRPC TLS (DAPフロー) |
IDEクライアント (VS Code、JetBrains) は、DAPフローのためにポート8443に直接接続します。ユーザーがVPNの背後にいる場合、送信元IP範囲を制限できます。
Dockerをインストールする
インスタンスにSSHでログインし、Dockerをインストールします:
sudo apt-get update && sudo apt-get upgrade -y
# Install Docker (official method)
curl --fail --silent --show-error --location "https://get.docker.com" | sudo bash
# Install Docker Compose plugin
sudo apt-get install -y docker-compose-plugin
# Verify
sudo docker --version
sudo docker compose versionDNSをセットアップする
EC2パブリックIPを指す2つのAレコードを作成します:
| レコード | タイプ | 値 |
|---|---|---|
gitlab.example.com | A | あなたのEC2パブリックIP |
aigw.example.com | A | あなたのEC2パブリックIP |
両方のドメインは同じIPを指します。GitLab NGINXはホスト名に基づいてトラフィックをルーティングします。
DNS伝播を検証します:
dig gitlab.example.com +short
dig aigw.example.com +short両方のコマンドはあなたのEC2パブリックIPを返すべきです。
ステップ2: GitLabをインストールする
データディレクトリを作成する
sudo mkdir -p /srv/gitlab/config /srv/gitlab/logs /srv/gitlab/dataGitLabを実行する
このコマンドは、Let’s Encryptを使用してGitLab EEをインストールして起動します:
sudo docker run --detach \
--hostname gitlab.example.com \
--env GITLAB_OMNIBUS_CONFIG="
external_url 'https://gitlab.example.com';
letsencrypt['enable'] = true;
letsencrypt['auto_renew'] = true;
letsencrypt['contact_emails'] = ['you@example.com'];
gitlab_rails['gitlab_shell_ssh_port'] = 2222;
" \
--publish 443:443 \
--publish 80:80 \
--publish 2222:22 \
--publish 8443:8443 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
--shm-size 256m \
gitlab/gitlab-ee:latest--publish 8443:8443フラグはDAP (gRPC TLS) に必要です。これを省略すると、DAPフローはサイレントに失敗します。実行中のコンテナにポートを追加することはできません。再作成する必要があります。
GitLabが起動するまで待つ
GitLabは初回実行時に初期化に3~5分かかります:
until curl --silent --fail "https://gitlab.example.com/-/health" > /dev/null 2>&1; do
echo "Waiting for GitLab to start..."
sleep 10
done
echo "GitLab is up!"rootパスワードを設定する
sudo docker exec gitlab cat /etc/gitlab/initial_root_passwordhttps://gitlab.example.comでユーザー名rootとコマンド出力のパスワードを使用してサインインします。すぐに変更してください。
ライセンスを適用する
- 管理者 > サブスクリプションに移動します。
- GitLabライセンスファイルをアップロードします。
ステップ3: AI Gatewayをデプロイする
正しいイメージタグを見つける
AI GatewayイメージはDocker Hubのgitlab/model-gatewayにあります。GitLabバージョンに一致するバージョンタグを使用する必要があります。
latestタグはありません。gitlab/model-gateway:latestを使用すると、イメージが見つからないエラーで失敗します。
タグフォーマット: self-hosted-v{MAJOR}.{MINOR}.{PATCH}-ee
利用可能なタグをチェックします:
curl --silent "https://hub.docker.com/v2/repositories/gitlab/model-gateway/tags?page_size=10&ordering=last_updated" | \
python3 -c "import sys,json; [print(t['name'], ' ', t['last_updated'][:10]) for t in json.load(sys.stdin)['results']]"JWT署名キーを生成する
AI GatewayはDWSリクエストを認証するためにJWTキーが必要です:
sudo mkdir -p /srv/enterprise-sidecar
openssl genrsa -out /srv/enterprise-sidecar/duo_workflow_jwt.key 2048環境ファイルを作成する
/srv/enterprise-sidecar/.envを作成します:
cat << 'EOF' | sudo tee /srv/enterprise-sidecar/.env
# AWS Bedrock credentials
AWS_ACCESS_KEY_ID=<your-aws-access-key>
AWS_SECRET_ACCESS_KEY=<your-aws-secret-key>
AWS_REGION=us-east-1
# AI Gateway: JWT signing key (for DWS authentication)
AIGW_JWT_SIGNING_KEY=<paste contents of duo_workflow_jwt.key>
EOF環境ファイルに制限付き権限を設定します:
sudo chmod 600 /srv/enterprise-sidecar/.envJWTキーを環境ファイルに埋め込むには、\nのリテラルで改行を置き換えて、キーが1行に収まるようにします:
JWT_KEY=$(sudo awk '{printf "%s\\n", $0}' /srv/enterprise-sidecar/duo_workflow_jwt.key)
sudo sed -i "s|AIGW_JWT_SIGNING_KEY=.*|AIGW_JWT_SIGNING_KEY=${JWT_KEY}|" /srv/enterprise-sidecar/.envDocker Composeファイルを作成する
/srv/enterprise-sidecar/docker-compose.ymlを作成します:
services:
ai-gateway:
image: gitlab/model-gateway:self-hosted-v<VERSION>-ee # Replace <VERSION> with your GitLab version (for example, 18.11.0)
container_name: ai-gateway
restart: unless-stopped
environment:
AIGW_GITLAB_URL: https://gitlab.example.com
AIGW_GITLAB_API_URL: https://gitlab.example.com/api/v4/
DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY: ${AIGW_JWT_SIGNING_KEY}
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_REGION: ${AWS_REGION:-us-east-1}
AIGW_LOGGING__LEVEL: INFO
DUO_WORKFLOW_LOGGING__LEVEL: INFO
ports:
- "5052:5052"
- "50052:50052"
deploy:
resources:
limits:
memory: 2048M
reservations:
memory: 512M
healthcheck:
test: ["CMD", "curl", "--silent", "--fail", "http://localhost:5052/monitoring/healthz"]
interval: 30s
timeout: 10s
retries: 3
start_period: 30sAI Gatewayを起動する
cd /srv/enterprise-sidecar
sudo docker compose up -dAI Gatewayのヘルスチェックを検証する
# Check container is running
sudo docker ps | grep ai-gateway
# Check HTTP health endpoint (empty JSON means healthy)
curl --silent "http://localhost:5052/monitoring/healthz"
# Check logs for errors
sudo docker logs ai-gateway --tail 20ステップ4: AI GatewayのTLSを設定する
AI GatewayにはHTTPS (チャット、コード提案用) とgRPC TLS (DAPフロー用) が必要です。組み込みのGitLab NGINXをリバースプロキシとして使用し、そのLet’s Encrypt証明書を共有します。
AI GatewayサブドメインをLet’s Encryptに追加する
GitLab設定を編集します:
sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rbletsencryptセクションを見つけてalt_namesを追加します:
letsencrypt['alt_names'] = ['aigw.example.com']他のalt_names (レジストリサブドメインなど) がすでにある場合は、aigw.example.comを既存の配列に追加します:
letsencrypt['alt_names'] = ['registry.example.com', 'aigw.example.com']新しいSANを含めるために証明書を更新します:
sudo docker exec gitlab gitlab-ctl renew-le-certs証明書にAI Gatewayサブドメインが含まれていることを検証します:
echo | openssl s_client -connect gitlab.example.com:443 2>/dev/null | \
openssl x509 -noout -ext subjectAltNameDNS:aigw.example.comが出力に表示されるはずです。
NGINXプロキシ設定を作成する
ホスト上でプロキシ設定ファイルを作成します:
cat << 'NGINX' | sudo tee /srv/gitlab/config/nginx/aigw-proxy.conf
# AI Gateway reverse proxy: HTTPS for HTTP API, gRPC TLS for DAP
# HTTP API: Duo Chat, Code Suggestions
server {
listen 443 ssl;
server_name aigw.example.com;
ssl_certificate /etc/gitlab/ssl/gitlab.example.com.crt;
ssl_certificate_key /etc/gitlab/ssl/gitlab.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://172.17.0.1:5052;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
}
location /monitoring/healthz {
proxy_pass http://172.17.0.1:5052/monitoring/healthz;
access_log off;
}
}
# gRPC TLS: DAP / Duo Agent Platform flows
server {
listen 8443 ssl http2;
server_name aigw.example.com;
ssl_certificate /etc/gitlab/ssl/gitlab.example.com.crt;
ssl_certificate_key /etc/gitlab/ssl/gitlab.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
grpc_pass grpc://172.17.0.1:50052;
grpc_read_timeout 600s;
grpc_send_timeout 600s;
}
}
NGINXアドレス172.17.0.1はDockerのデフォルトブリッジゲートウェイIPです。GitLabコンテナ内から、このIPはホストマシンおよびAI Gatewayコンテナの公開ポートに到達します。
GitLab NGINXに設定を含める
設定ファイルをコンテナ内のNGINXランタイムディレクトリにコピーします:
sudo docker exec gitlab mkdir -p /var/opt/gitlab/nginx/conf
sudo docker cp /srv/gitlab/config/nginx/aigw-proxy.conf \
gitlab:/var/opt/gitlab/nginx/conf/aigw-proxy.conf/etc/gitlab/nginx/にファイルを置かないでください。gitlab.rb内のcustom_nginx_configによって参照されるファイルのみが読み込まれます。ランタイムディレクトリは/var/opt/gitlab/nginx/conf/です。
gitlab.rbにincludeディレクティブを追加します:
sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rbnginx['custom_nginx_config']行を見つけるか追加します:
nginx['custom_nginx_config'] = "include /var/opt/gitlab/nginx/conf/aigw-proxy.conf;"カスタムNGINX設定 (KeyCloakプロキシなど) がすでにある場合は、セミコロンで連結します:
nginx['custom_nginx_config'] = "include /var/opt/gitlab/nginx/conf/keycloak-proxy.conf; include /var/opt/gitlab/nginx/conf/aigw-proxy.conf;"GitLabを再構成する
sudo docker exec gitlab gitlab-ctl reconfigureTLSを検証する
# HTTPS for AI Gateway HTTP API
curl --silent "https://aigw.example.com/monitoring/healthz"
# Expected: {}
# gRPC TLS for DAP
openssl s_client -connect aigw.example.com:8443 < /dev/null 2>/dev/null | \
grep "Verify return code"
# Expected: Verify return code: 0 (ok)ステップ5: AWS Bedrockに接続する
Bedrock用のIAMユーザーを作成する
AWSコンソールで、IAM > ユーザー > ユーザーの作成に移動します:
- 名前:
gitlab-bedrock(または類似の名称) - 権限:
AmazonBedrockFullAccess管理ポリシーをアタッチします
アクセスキーを作成します(ユースケース: 「AWS外で実行されるアプリケーション」)。アクセスキーIDとシークレットアクセスキーを保存します。
代替案として、EC2インスタンスにBedrock権限を持つIAMロールがある場合、アクセスキーを省略できます。AI Gatewayはインスタンスプロファイルを自動的に使用します。
BedrockでAnthropicモデルをアクティブ化する
このステップは必須であり、ほとんどの人が予期しないものです:
- AWSコンソールで、AWS console > Amazon Bedrock > Providers > Anthropicに移動します。
- Submit use case detailsユースケースの詳細フォームに記入します。
- アクティブ化まで約15分待ちます。
このフォームがない場合、AnthropicモデルへのすべてのBedrock APIコールは以下を返します: "Model use case details have not been submitted for this account."古い「Model access」ページは廃止されました。モデルは初回呼び出し時に自動的に有効になりますが、Anthropicはユースケースフォームが必要です。
モデルの推論プロファイルIDを見つける
新しいClaudeモデル (Claude 4.5 Sonnet以降) には、直接のモデルIDではなく、inference profile IDが必要です。
aws bedrock list-inference-profiles --region us-east-1 --output json | \
python3 -c "
import sys, json
profiles = json.load(sys.stdin)['inferenceProfileSummaries']
for p in profiles:
if 'claude' in p['inferenceProfileId'].lower():
print(p['inferenceProfileId'])
"us.プレフィックス (例: us.anthropic.claude-sonnet-4-6) を使用し、基本モデルID (anthropic.claude-sonnet-4-6) は使用しないでください。
| モデル識別子 | 結果 |
|---|---|
bedrock/anthropic.claude-sonnet-4-6 | 400 Bad Request: 「オンデマンドスループットはサポートされていません」 |
bedrock/us.anthropic.claude-sonnet-4-6 | 動作します |
us.プレフィックスは米国のみの地域にルーティングします。global.プレフィックスは有効なすべての地域にルーティングします。
認証情報を使用してAI Gatewayを再起動する
まだ行っていない場合は、AWS認証情報を/srv/enterprise-sidecar/.envに追加してから再起動します:
cd /srv/enterprise-sidecar
sudo docker compose down ai-gateway
sudo docker compose up -d ai-gatewayステップ6: GitLab管理者設定を設定する
AI Gateway URLを設定する
管理者 > GitLab Duoに移動し、設定の変更を選択します。
| 設定 | 値 |
|---|---|
| 接続方法 | GitLab Self-Managedを介した間接接続 |
| ローカルAI Gateway URL | https://aigw.example.com |
| ローカルDAPサービスURL | aigw.example.com:8443 |
| AI Gatewayリクエストタイムアウト | 300 (秒) |
Bedrockの場合、デフォルトの60秒のタイムアウトは短すぎます。単一のDAPフローには5~10分かかる場合があります。これを少なくとも300に設定します。
変更を保存を選択します。
ヘルスチェックを実行する
同じページで、ヘルスチェックを実行するを選択します。4つの緑色のチェックが表示されるはずです:
| チェック | 予想 |
|---|---|
| AIゲートウェイ | 接続済み |
| ネットワーク | 到達可能 |
| コード提案 | 利用可能 |
| DAP | 利用可能 |
セルフホストモデルを追加する
管理者 > GitLab Duo > GitLab Duoのモデルを設定するに移動します。
セルフホストモデルの追加を選択し、以下を記入します:
| フィールド | 値 |
|---|---|
| デプロイ名 | Bedrock Claude Sonnet 4.6 (または説明的な名前) |
| プラットフォーム | Amazon Bedrock |
| モデルファミリー | Claude |
| モデル識別子 | bedrock/us.anthropic.claude-sonnet-4-6 |
モデル識別子はbedrock/で始まる必要があります。
接続をテストを選択します。以下が表示されるはずです: 「セルフホストモデルへの接続に成功しました。」
「400 Bad Request」が表示される場合、誤ったモデル識別子を使用しています。直接のモデルIDではなく、推論プロファイルID (us.anthropic.claude-sonnet-4-6) を使用してください。
Add modelを選択します。
モデルを機能に割り当てる
同じページで、AIネイティブ機能タブを選択します。
Bedrockを介してルーティングしたい各機能について、ドロップダウンリストからセルフホストモデルを選択します:
| 機能 | 推奨される割り当て |
|---|---|
| GitLab Duo Agent Platform > All agents, except Agentic Chat | Bedrock Claude Sonnet 4.6 |
| GitLab Duo Agent Platform > エージェントチャット | Bedrock Claude Sonnet 4.6 |
| コード提案 | GitLab管理 (デフォルト) またはBedrock |
| Chat | GitLab管理 (デフォルト) またはBedrock |
| コードレビュー | GitLab管理 (デフォルト) またはBedrock |
まずDAP機能のみをBedrockに割り当て、チャットとコード提案はGitLab管理のデフォルトのままにします。これにより、日常的なデベロッパーエクスペリエンスを危険にさらすことなく、Bedrock接続を検証することができます。すべてが動作することを確認した後、より多くの機能を切り替えます。
ステップ7: DAPフローのためにRunnerを登録する
DAPフローはCI/CDパイプラインを作成します。登録済みのランナーがない場合、DAPフローは無期限に保留状態のままになります。
Runnerをインストールして登録する
EC2インスタンス (または別のマシン) に、GitLab Runnerをインストールします:
curl --location "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt-get install -y gitlab-runnerGitLabインスタンスにRunnerを登録します。管理者 > CI/CD > Runnersに移動し、New instance runnerを選択して登録トークンを取得し、以下を実行します:
sudo gitlab-runner register \
--url "https://gitlab.example.com" \
--token "<REGISTRATION_TOKEN>" \
--executor docker \
--docker-image "ruby:3.2" \
--tag-list "docker" \
--description "Docker runner for DAP"詳細については、GitLab RunnerのインストールとRunnerの作成と登録を参照してください。
DAPフローはDocker-in-Dockerワークフローを使用します。Runnerはdocker executorを使用する必要があります。
ステップ8: グループとプロジェクトでDuo機能を有効にする
管理者レベルの設定 (ステップ6) はDuo機能をインスタンス全体で利用可能にしますが、グループとプロジェクトレベルでも有効にする必要があります。
グループでDuoを有効にする
- グループの設定 > 一般に移動します。
- 権限とグループ機能を展開します。
- GitLab Duoの機能で、Enable GitLab Duo featuresを選択します。
- DAPを使用するには、Enable experiment and beta featuresとフロー実行を許可 (有効にしたいフロータイプをチェック) も選択します。
- 変更を保存を選択します。
詳細については、GitLab Duoの有効化または無効化を参照してください。
プロジェクトでDuoを有効にする
- プロジェクトの設定 > 一般に移動します。
- 可視性、プロジェクトの機能、権限を展開します。
- GitLab Duoで、Use GitLab Duo featuresを有効にします。
- 変更を保存を選択します。
詳細については、GitLab Duoの有効化または無効化を参照してください。
ステップ9: エンドツーエンドを検証する
ヘルスチェック
# AI Gateway HTTP health
curl --silent "https://aigw.example.com/monitoring/healthz"
# Expected: {}
# gRPC TLS connectivity
openssl s_client -connect aigw.example.com:8443 < /dev/null 2>/dev/null | \
grep "Verify return code"
# Expected: Verify return code: 0 (ok)ブラウザで管理者 > GitLab Duoに移動し、設定の変更を選択し、次にヘルスチェックを実行するを選択します。4つのチェックすべてが緑色であるはずです。
Rake検証タスクを実行する
sudo docker exec gitlab gitlab-rake "gitlab:duo:verify_self_hosted_setup[your_username]"これにより、ライセンス、機能フラグ、AI Gateway接続、およびモデル設定の完全なチェーンが検証されます。
Rakeタスクのモデル接続テストはプレースホルダーURL (bedrockselfhostedmodel.com) を使用しており、デプロイが正しく機能している場合でも失敗を報告する可能性があります。他のすべてのチェック (ライセンス、AI Gateway、機能割り当て) は有効です。
Duo Chatをテストする
Bedrockを使用したDuo Chatは、一部のAI Gatewayバージョンで400エラー ("This model does not support assistant message prefill") を返す場合があります。これはDuo Chatのみに影響します。DAPフローは異なるコードパスを使用し、正しく動作します。このエラーが表示された場合は、チャットをGitLab管理モデルのままにし、DAP機能にのみBedrockを使用してください。
- GitLabインスタンスで任意のプロジェクトを開きます。
- Duo Chatアイコンを選択します。
- 「マージリクエストとは何ですか?」のような簡単な質問をします。
- 応答があることを検証します。
BedrockアクティビティのAI Gatewayログを監視します:
sudo docker logs -f ai-gateway 2>&1 | grep -i "litellm\|bedrock\|chat"DAPフローをテストする
これが実際のテストです。Bedrock上でDuo Agent Platformフローをエンドツーエンドで実行します:
- いくつかのコードを含むプロジェクトを作成または開きます。
- イシューを作成します (例: 「ログインフォームに入力検証を追加する」)。
- イシューページで、Duo > Start workflowを選択します。
- 待ちます。Bedrockを使用するDAPフローは通常3~10分かかります。
- パイプラインをチェックします: ビルド > パイプライン。
source: duo_workflowを探します。
フロー中にAI Gatewayログを監視します:
sudo docker logs -f ai-gateway 2>&1 | grep -i "workflow\|bedrock\|litellm"DAPフロー中の予想されるログ出力:
LiteLLM completion() model= us.anthropic.claude-sonnet-4-6; provider = bedrockフローが約10秒で完了する場合、何かが間違っています。正常なフローは秒単位ではなく分単位かかります。AI Gatewayログでエラーをチェックします。
ステップ10: モニタリング (オプション)
AI GatewayPrometheusメトリクス
AI Gatewayは2つのポートでメトリクスを公開します:
| ポート | エンドポイント | コンテンツ |
|---|---|---|
| 8082 | /metrics | AI Gateway (FastAPI) メトリクス: リクエスト数、レイテンシ |
| 8083 | /metrics | DWSメトリクス: gRPCコール数 |
これらをPrometheusスクレイピングのために公開するには、docker-compose.ymlポートに追加します:
ports:
- "5052:5052"
- "50052:50052"
- "8082:8082"
- "8083:8083"そして、対応する環境変数を追加します:
environment:
AIGW_FASTAPI__METRICS_HOST: "0.0.0.0"
AIGW_FASTAPI__METRICS_PORT: "8082"
PROMETHEUS_METRICS__ADDR: "0.0.0.0"
PROMETHEUS_METRICS__PORT: "8083"トラブルシューティング
AI Gatewayが起動しない
コンテナがすぐに終了するか、ヘルスチェックが一度もパスしない場合:
sudo docker logs ai-gateway --tail 50| Error | 修正 |
|---|---|
Image not found | latestタグを使用しました。self-hosted-v18.9.0-eeのような明示的なバージョンを使用してください。 |
AIGW_GITLAB_URL must be set | docker-compose.ymlに環境変数を追加します。 |
| ヘルスチェックで接続が拒否されました | 起動まで30秒待ちます。永続する場合は、ポートバインディングをチェックします。 |
管理者UIでのヘルスチェックが失敗する
| チェック | 一般的な原因 | 修正 |
|---|---|---|
| AI Gateway: 未接続 | 管理者設定のURLが間違っています | https://aigw.example.comを使用します (http://ではありません、ポート5052ではありません)。 |
| ネットワーク: 到達不能 | コンテナ内でDNSが解決されていません | docker exec gitlab dig aigw.example.comで検証します。 |
| DAP: 利用不可 | ポート8443が公開されていません | --publish 8443:8443を使用してGitLabコンテナを再作成します。 |
モデル接続テスト時に400 Bad Request
推論プロファイルIDではなく、直接のモデルIDを使用しています。
bedrock/anthropic.claude-sonnet-4-6をbedrock/us.anthropic.claude-sonnet-4-6に変更します (us.プレフィックスに注意してください)。
「モデルのユースケース詳細が提出されていません」
- AWSコンソールで、AWS console > Amazon Bedrock > Providers > Anthropicに移動します。
- ユースケース詳細フォームを送信します。
- アクティブ化まで約15分待ちます。
- 再試行。
TLSエラー
curl "https://aigw.example.com/monitoring/healthz"がSSLエラーを返す場合:
gitlab.rbのletsencrypt['alt_names']にaigw.example.comを追加したことを検証します。gitlab-ctl renew-le-certsを実行したことを検証します。- NGINX設定が正しい証明書パスを使用していることを検証します。
- NGINX設定ファイルが
/var/opt/gitlab/nginx/conf/にあること (/etc/gitlab/nginx/ではないこと) を検証します。 gitlab.rbのcustom_nginx_configがファイルを参照していることを検証します。
DAPフローが開始しない
Start workflowを選択してもパイプラインが表示されない場合:
- Runnerが登録されオンラインであることを検証します (管理者 > CI/CD > Runners)。ステップ7を参照してください。
- グループとプロジェクトでDuoが有効になっていることを検証します。ステップ8を参照してください。
- ユーザーがGitLabクレジットまたはDuoシートを持っていることを検証します (管理者 > GitLab Duo > Seat assignment)。
- ポート8443がGitLabコンテナ上で公開されていることを検証します。
NGINX設定が有効にならない
gitlab.rbを編集し、再構成を実行した後:
ファイルがランタイムディレクトリに存在することを検証します:
sudo docker exec gitlab ls -la /var/opt/gitlab/nginx/conf/見つからない場合は、再度コピーします:
sudo docker cp /srv/gitlab/config/nginx/aigw-proxy.conf \ gitlab:/var/opt/gitlab/nginx/conf/aigw-proxy.confNGINXを再構成して再起動します:
sudo docker exec gitlab gitlab-ctl reconfigure sudo docker exec gitlab gitlab-ctl restart nginx