正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

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 instancet3.xlarge最小 (4 vCPU、16 GB RAM)。t3.2xlarge (8 vCPU、32 GB) が本番環境に推奨されます。
ドメイン名EC2インスタンスを指す2つのDNSレコード: gitlab.example.comaigw.example.com
GitLab licensePremiumまたはUltimate。Classic Duo機能 (チャット、コード提案) には、Duo seat assignmentが必要です。オンラインライセンス (GitLab 18.9以降) を使用するDAPは、usage-based billing through GitLab Creditsを使用し、Duo Enterpriseシートは必要ありません。オフラインライセンスでDAPを使用する場合は、ELAオプションについてGitLabアカウントチームにお問い合わせください。
SSH accessEC2インスタンスへ。
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を設定する

これらの受信ポートを開放します:

ポートプロトコルソース目的
22TCPあなたのIPSSH
80TCP0.0.0.0/0HTTP (Let’s Encrypt検証)
443TCP0.0.0.0/0HTTPS (GitLabおよびAI Gatewayプロキシ)
8443TCP0.0.0.0/0gRPC 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 version

DNSをセットアップする

EC2パブリックIPを指す2つのAレコードを作成します:

レコードタイプ
gitlab.example.comAあなたのEC2パブリックIP
aigw.example.comAあなたの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/data

GitLabを実行する

このコマンドは、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_password

https://gitlab.example.comでユーザー名rootとコマンド出力のパスワードを使用してサインインします。すぐに変更してください。

ライセンスを適用する

  1. 管理者 > サブスクリプションに移動します。
  2. 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/.env

JWTキーを環境ファイルに埋め込むには、\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/.env

Docker 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: 30s

AI Gatewayを起動する

cd /srv/enterprise-sidecar
sudo docker compose up -d

AI 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.rb

letsencryptセクションを見つけて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 subjectAltName

DNS: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.rb

nginx['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 reconfigure

TLSを検証する

# 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モデルをアクティブ化する

このステップは必須であり、ほとんどの人が予期しないものです:

  1. AWSコンソールで、AWS console > Amazon Bedrock > Providers > Anthropicに移動します。
  2. Submit use case detailsユースケースの詳細フォームに記入します。
  3. アクティブ化まで約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-6400 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 URLhttps://aigw.example.com
ローカルDAPサービスURLaigw.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 ChatBedrock Claude Sonnet 4.6
GitLab Duo Agent Platform > エージェントチャットBedrock Claude Sonnet 4.6
コード提案GitLab管理 (デフォルト) またはBedrock
ChatGitLab管理 (デフォルト) または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-runner

GitLabインスタンスに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を有効にする

  1. グループの設定 > 一般に移動します。
  2. 権限とグループ機能を展開します。
  3. GitLab Duoの機能で、Enable GitLab Duo featuresを選択します。
  4. DAPを使用するには、Enable experiment and beta featuresフロー実行を許可 (有効にしたいフロータイプをチェック) も選択します。
  5. 変更を保存を選択します。

詳細については、GitLab Duoの有効化または無効化を参照してください。

プロジェクトでDuoを有効にする

  1. プロジェクトの設定 > 一般に移動します。
  2. 可視性、プロジェクトの機能、権限を展開します。
  3. GitLab Duoで、Use GitLab Duo featuresを有効にします。
  4. 変更を保存を選択します。

詳細については、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を使用してください。

  1. GitLabインスタンスで任意のプロジェクトを開きます。
  2. Duo Chatアイコンを選択します。
  3. 「マージリクエストとは何ですか?」のような簡単な質問をします。
  4. 応答があることを検証します。

BedrockアクティビティのAI Gatewayログを監視します:

sudo docker logs -f ai-gateway 2>&1 | grep -i "litellm\|bedrock\|chat"

DAPフローをテストする

これが実際のテストです。Bedrock上でDuo Agent Platformフローをエンドツーエンドで実行します:

  1. いくつかのコードを含むプロジェクトを作成または開きます。
  2. イシューを作成します (例: 「ログインフォームに入力検証を追加する」)。
  3. イシューページで、Duo > Start workflowを選択します。
  4. 待ちます。Bedrockを使用するDAPフローは通常3~10分かかります。
  5. パイプラインをチェックします: ビルド > パイプライン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/metricsAI Gateway (FastAPI) メトリクス: リクエスト数、レイテンシ
8083/metricsDWSメトリクス: 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 foundlatestタグを使用しました。self-hosted-v18.9.0-eeのような明示的なバージョンを使用してください。
AIGW_GITLAB_URL must be setdocker-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-6bedrock/us.anthropic.claude-sonnet-4-6に変更します (us.プレフィックスに注意してください)。

「モデルのユースケース詳細が提出されていません」

  1. AWSコンソールで、AWS console > Amazon Bedrock > Providers > Anthropicに移動します。
  2. ユースケース詳細フォームを送信します。
  3. アクティブ化まで約15分待ちます。
  4. 再試行。

TLSエラー

curl "https://aigw.example.com/monitoring/healthz"がSSLエラーを返す場合:

  1. gitlab.rbletsencrypt['alt_names']aigw.example.comを追加したことを検証します。
  2. gitlab-ctl renew-le-certsを実行したことを検証します。
  3. NGINX設定が正しい証明書パスを使用していることを検証します。
  4. NGINX設定ファイルが/var/opt/gitlab/nginx/conf/にあること (/etc/gitlab/nginx/ではないこと) を検証します。
  5. gitlab.rbcustom_nginx_configがファイルを参照していることを検証します。

DAPフローが開始しない

Start workflowを選択してもパイプラインが表示されない場合:

  1. Runnerが登録されオンラインであることを検証します (管理者 > CI/CD > Runners)。ステップ7を参照してください。
  2. グループとプロジェクトでDuoが有効になっていることを検証します。ステップ8を参照してください。
  3. ユーザーがGitLabクレジットまたはDuoシートを持っていることを検証します (管理者 > GitLab Duo > Seat assignment)。
  4. ポート8443がGitLabコンテナ上で公開されていることを検証します。

NGINX設定が有効にならない

gitlab.rbを編集し、再構成を実行した後:

  1. ファイルがランタイムディレクトリに存在することを検証します:

    sudo docker exec gitlab ls -la /var/opt/gitlab/nginx/conf/
  2. 見つからない場合は、再度コピーします:

    sudo docker cp /srv/gitlab/config/nginx/aigw-proxy.conf \
      gitlab:/var/opt/gitlab/nginx/conf/aigw-proxy.conf
  3. NGINXを再構成して再起動します:

    sudo docker exec gitlab gitlab-ctl reconfigure
    sudo docker exec gitlab gitlab-ctl restart nginx