GitLab AIゲートウェイをインストールする

AIゲートウェイは、AIネイティブGitLab Duoの機能へのアクセスを提供する2つのサービスを組み合わせたものです:

AIゲートウェイサービス
GitLab Duo Agent Platformサービス。

Dockerを使用してインストールする

GitLab AIゲートウェイDockerイメージには、必要なコードと依存関係がすべて1つのコンテナに含まれています。

前提要件:

DockerなどのDockerコンテナエンジンをインストールします。
ネットワークからアクセスできる有効なホスト名を使用します。localhostは使用しないでください。
linux/amd64アーキテクチャの場合、約340MB（圧縮）、RAMが最小512MBであることを確認してください。
GitLab Duo Agent Platform機能のJWT署名キーを生成します:
```
openssl genrsa -out duo_workflow_jwt.key 2048
```
duo_workflow_jwt.keyファイルを安全に保管し、公開しないでください。このキーはJWTトークンの署名に使用され、機密性の高い認証情報として扱う必要があります。

特に高負荷時には、パフォーマンスを向上させるために、最小要件よりも多くのディスク容量、メモリ、リソースを割り当てることを検討してください。RAMとディスク容量を増やすことで、ピーク負荷時のAIゲートウェイの効率性を高めることができます。

GitLab AIゲートウェイにはGPUは不要です。

AIゲートウェイイメージを探す

GitLabの公式Dockerイメージは、以下で入手できます:

コンテナレジストリで表示:
- Stable（安定版）
- Nightly (ナイトリー)
DockerHubの場合:
- Stable（安定版）
- Nightly (ナイトリー)

セルフホストAIゲートウェイのリリースプロセスを表示する。

GitLabのバージョンがvX.Y.*-eeの場合、最新のself-hosted-vX.Y.*-eeタグが付いたAIゲートウェイDockerイメージを使用します。たとえば、GitLabのバージョンがv18.2.1-eeで、AIゲートウェイDockerイメージに以下がある場合:

バージョンself-hosted-v18.2.0-ee、self-hosted-v18.2.1-ee、およびself-hosted-v18.2.2-eeの場合は、self-hosted-v18.2.2-eeを使用します。
バージョンself-hosted-v18.2.0-eeおよびself-hosted-v18.2.1-eeの場合は、self-hosted-v18.2.1-eeを使用します。
バージョンが1つのみself-hosted-v18.2.0-eeの場合は、self-hosted-v18.2.0-eeを使用します。

新しい機能はナイトリービルドから利用できますが、下位互換性は保証されていません。

ナイトリーバージョンを使用すると、GitLabのバージョンがAIゲートウェイのリリースより前または後の場合、互換性の問題が発生する可能性があるため、not recommended（推奨されません）。常に明示的なバージョンタグを使用してください。

イメージからコンテナを起動する

次のコマンドを実行し、<your_gitlab_instance>と<your_gitlab_domain>をGitLabインスタンスのURLとドメインに置き換えます:
```
docker run -d -p 5052:5052 -p 50052:50052 \
 -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="$(cat duo_workflow_jwt.key)" \
 registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:<ai-gateway-tag> \
```
<ai-gateway-tag>をGitLabインスタンスに一致するバージョンに置き換えます。たとえば、GitLabのバージョンがvX.Y.0の場合は、self-hosted-vX.Y.0-eeを使用します。コンテナホストから、http://localhost:5052にアクセスすると、{"error":"No authorization header presented"}が返されるはずです。
ポート5052と50052がホストからコンテナに転送されていることを確認します。
AIゲートウェイURLとGitLab Duo Agent PlatformサービスURLを設定します。
GitLab Duo Agent Platformに独自のセルフホストモデルを使用する予定で、URLがTLSで設定されていない場合は、GitLabインスタンスでDUO_AGENT_PLATFORM_SERVICE_SECURE環境変数を設定する必要があります:
- Linuxパッケージインストールの場合は、gitlab_rails['env']で、'DUO_AGENT_PLATFORM_SERVICE_SECURE' => falseを設定します
- セルフコンパイルインストールの場合、/etc/default/gitlabでexport DUO_AGENT_PLATFORM_SERVICE_SECURE=falseを設定します
GitLab Duo Agent PlatformにGitLab AIベンダーモデルを使用する場合は、GitLabインスタンスでDUO_AGENT_PLATFORM_SERVICE_SECURE環境変数を設定しないでください。

PEMファイルの読み込みでJWKErrorのようなエラーが発生した場合は、SSL証明書エラーを解決する必要があるかもしれません。

この問題を修正するには、次の環境変数を使用して、Dockerコンテナに適切な証明書バンドルパスを設定します:

SSL_CERT_FILE=/path/to/ca-bundle.pem
REQUESTS_CA_BUNDLE=/path/to/ca-bundle.pem

/path/to/ca-bundle.pemを証明書バンドルへの実際のパスに置き換えます。

NGINXとSSLを使用してDockerをセットアップする

このNGINXまたはCaddyをリバースプロキシとしてデプロイする方法は、イシュー455854が実装されるまでSSLをサポートする一時的な回避策です。

Docker、リバースプロキシとしてのNGINX、Let’s Encrypt for SSL証明書を使用して、AIゲートウェイインスタンスにSSLを設定できます。

NGINXは外部クライアントとのセキュアな接続を管理し、受信HTTPSリクエストを復号化してから、AIゲートウェイに渡します。

前提要件:

DockerとDocker Composeがインストールされている
DNSレコードが登録され、設定されたドメイン名

設定ファイルを作成

まず、作業ディレクトリに次のファイルを作成します。

nginx.conf:

user  nginx;
worker_processes  auto;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    keepalive_timeout  65;
    include /etc/nginx/conf.d/*.conf;
}

default.conf:

# nginx/conf.d/default.conf
server {
    listen 80;
    server_name _;

    # Forward all requests to the AI gateway
    location / {
        proxy_pass http://gitlab-ai-gateway:5052;
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
        proxy_buffering off;
    }
}

server {
    listen 443 ssl;
    server_name _;

    # SSL configuration
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # Configuration for self-signed certificates
    ssl_verify_client off;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # Proxy headers
    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 $scheme;

    # WebSocket support (if needed)
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Forward all requests to the AI gateway
    location / {
        proxy_pass http://gitlab-ai-gateway:5052;
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
        proxy_buffering off;
    }
}

Let’s Encryptを使用してSSL証明書を設定する

次に、SSL証明書を設定します:

DockerベースのNGINXサーバーの場合、CertbotはLet’s Encrypt証明書を実装する自動化された方法を提供します。
または、Certbot手動インストールを使用することもできます。

環境変数ファイルを作成する

JWT署名キーを保存するための.envファイルを作成します:

echo "DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY=\"$(cat duo_workflow_jwt.key)\"" > .env

Docker-composeファイルを作成する

次に、docker-compose.yamlファイルを作成します。

version: '3.8'

services:
  nginx-proxy:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /path/to/nginx.conf:/etc/nginx/nginx.conf:ro
      - /path/to/default.conf:/etc/nginx/conf.d/default.conf:ro
      - /path/to/fullchain.pem:/etc/nginx/ssl/server.crt:ro
      - /path/to/privkey.pem:/etc/nginx/ssl/server.key:ro
    networks:
      - proxy-network
    depends_on:
      - gitlab-ai-gateway

  gitlab-ai-gateway:
    image: registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:<ai-gateway-tag>
    expose:
      - "5052"
    environment:
      - AIGW_GITLAB_URL=<your_gitlab_instance>
      - AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/
    env_file:
      - .env
    networks:
      - proxy-network
    restart: always

networks:
  proxy-network:
    driver: bridge

デプロイして検証する

ソリューションをデプロイして検証するには:

nginxとAIGWのコンテナを起動し、実行されていることを確認します:
```
docker-compose up
docker ps
```
AIゲートウェイにアクセスするようにGitLabインスタンスを設定する。
GitLab Duo Agent PlatformサービスのURLにアクセスするようにGitLabインスタンスを設定します。
ヘルスチェックを実行し、AIゲートウェイとエージェントプラットフォームの両方にアクセスできることを確認します。

Helm Chartを使用してインストールする

前提要件:

以下が必要です:
- DNSレコードを追加できる、所有しているドメイン
- Kubernetesクラスター。
- kubectlの動作インストール。
- Helmの動作インストール、バージョンv3.11.0以降。

詳細については、GKEまたはEKSでGitLabチャートをテストするを参照してください。

AIゲートウェイHelmリポジトリを追加する

AIゲートウェイHelmリポジトリをHelm設定に追加します:

helm repo add ai-gateway \
https://gitlab.com/api/v4/projects/gitlab-org%2fcharts%2fai-gateway-helm-chart/packages/helm/devel

AIゲートウェイをインストールする

ai-gatewayネームスペースを作成します:
```
kubectl create namespace ai-gateway
```
AIゲートウェイを公開するドメインの証明書を生成します。

以前に作成したネームスペースにTLSシークレットを作成します:

kubectl -n ai-gateway create secret tls ai-gateway-tls --cert="<path_to_cert>" --key="<path_to_cert_key>"

AIゲートウェイがAPIにアクセスするには、GitLabインスタンスがどこにあるかを知る必要があります。これを行うには、gitlab.urlとgitlab.apiUrlをingress.hostsとingress.tlsの値とともに次のように設定します:

helm repo add ai-gateway \
  https://gitlab.com/api/v4/projects/gitlab-org%2fcharts%2fai-gateway-helm-chart/packages/helm/devel
helm repo update

helm upgrade --install ai-gateway \
  ai-gateway/ai-gateway \
  --version 0.5.0 \
  --namespace=ai-gateway \
  --set="image.tag=<ai-gateway-image-version>" \
  --set="gitlab.url=https://<your_gitlab_domain>" \
  --set="gitlab.apiUrl=https://<your_gitlab_domain>/api/v4/" \
  --set "ingress.enabled=true" \
  --set "ingress.hosts[0].host=<your_gateway_domain>" \
  --set "ingress.hosts[0].paths[0].path=/" \
  --set "ingress.hosts[0].paths[0].pathType=ImplementationSpecific" \
  --set "ingress.tls[0].secretName=ai-gateway-tls" \
  --set "ingress.tls[0].hosts[0]=<your_gateway_domain>" \
  --set="ingress.className=nginx" \
  --set "extraEnvironmentVariables[0].name=DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY" \
  --set "extraEnvironmentVariables[0].value=$(cat duo_workflow_jwt.key)" \
  --timeout=300s --wait --wait-for-jobs

image.tagとして使用できるAIゲートウェイバージョンのリストは、レジストリにあります。

この手順では、すべてのリソースが割り当てられ、AIゲートウェイが起動するまでに数秒かかる場合があります。

既存のnginxIngressコントローラーが別のネームスペースでサービスを提供しない場合は、AIゲートウェイ用に独自のIngress Controllerを設定する必要があるかもしれません。Ingressがマルチネームスペースデプロイ用に正しく設定されていることを確認してください。

ai-gatewayHelm Chartのバージョンについては、helm search repo ai-gateway --versionsを使用して、適切なチャートバージョンを見つけてください。

ポッドが起動して実行されるのを待ちます:

kubectl wait pod \
  --all \
  --for=condition=Ready \
  --namespace=ai-gateway \
  --timeout=300s

ポッドが起動して実行されたら、IP IngressとDNSレコードを設定できます。

自己署名SSL証明書を使用してGitLabインスタンスまたはモデルエンドポイントに接続する

GitLabインスタンスまたはモデルエンドポイントが自己署名証明書で設定されている場合は、ルート認証局（CA）証明書をAIゲートウェイの証明書バンドルに追加する必要があります。

これを行うには、次のいずれかの方法があります:

ルートCA証明書をAIゲートウェイに渡し、認証が成功するようにします。
ルートCA証明書をAIゲートウェイコンテナのCAバンドルに追加します。

ルートCA証明書をAIゲートウェイに渡す

ルートCA証明書をAIゲートウェイに渡し、認証が成功するようにするには、REQUESTS_CA_BUNDLE環境変数を設定します。GitLabはベースの信頼できるCAリストにCertifiを使用しているため、次のようにカスタムCAバンドルを設定します:

Certifi cacert.pemファイルをダウンロードします:

curl "https://raw.githubusercontent.com/certifi/python-certifi/2024.07.04/certifi/cacert.pem" --output cacert.pem

自己署名ルートCA証明書をファイルに追加します。たとえば、mkcertを使用して証明書を作成した場合:
```
cat "$(mkcert -CAROOT)/rootCA.pem" >> path/to/your/cacert.pem
```
REQUESTS_CA_BUNDLEをcacert.pemファイルのパスに設定します。たとえば、GETでは、$GDK_ROOT/env.runitに次を追加します:
```
export REQUESTS_CA_BUNDLE=/path/to/your/cacert.pem
```

AIゲートウェイコンテナのCAバンドルにルートCA証明書を追加する

AIゲートウェイがカスタムCAによって署名されたGitLab Self-Managedインスタンスの証明書を信頼できるようにするには、ルートCA証明書をAIゲートウェイコンテナのCAバンドルに追加します。

この方法では、チャートのバージョンが新しい場合にルートCAバンドルに加えられた変更は許可されません。

AIゲートウェイのHelm Chartデプロイでこれを行うには:

カスタムルートCA証明書をローカルファイルに追加します:
```
cat customCA-root.crt >> ca-certificates.crt
```
/etc/ssl/certs/ca-certificates.crtバンドルファイルをAIゲートウェイコンテナからローカルファイルにコピーします:
```
kubectl cp -n gitlab ai-gateway-55d697ff9d-j9pc6:/etc/ssl/certs/ca-certificates.crt ca-certificates.crt.
```

ローカルファイルから新しいシークレットを作成します:

kubectl create secret generic ca-certificates -n gitlab --from-file=cacertificates.crt=ca-certificates.crt

チャットvalues.ymlでシークレットを使用して、volumeとvolumeMountを定義します。これにより、コンテナに/tmp/ca-certificates.crtファイルが作成されます:

volumes:
  - name: cacerts
    secret:
      secretName: ca-certificates
      optional: false

volumeMounts:
  - name: cacerts
    mountPath: "/tmp"
    readOnly: true

REQUESTS_CA_BUNDLEとSSL_CERT_FILE環境変数を、マウントされたファイルを指すように設定します:

extraEnvironmentVariables:
  - name: REQUESTS_CA_BUNDLE
    value: /tmp/ca-certificates.crt
  - name: SSL_CERT_FILE
    value: /tmp/ca-certificates.crt

チャートを再デプロイします。

イシュー3は、Helm Chartでネイティブにこれをサポートするために存在します。

Dockerデプロイの場合

Dockerデプロイの場合は、同じ方法を使用します。唯一の違いは、コンテナにローカルファイルをマウントするには、--volume /root/ca-certificates.crt:/tmp/ca-certificates.crtを使用することです。

AIゲートウェイDockerイメージをアップグレードする

AIゲートウェイをアップグレードするには、最新のDockerイメージタグをダウンロードします。

実行中のコンテナを停止します:
```
sudo docker stop gitlab-aigw
```
既存のコンテナを削除します:
```
sudo docker rm gitlab-aigw
```
プルして新しいイメージを実行します。
環境変数がすべて正しく設定されていることを確認します。

代替インストール方法

AIゲートウェイをインストールする別の方法については、イシュー463773を参照してください。

ヘルスチェックとデバッグ

セルフホストDuoインストールの問題をデバッグするには、次のコマンドを実行します:

sudo gitlab-rake gitlab:duo:verify_self_hosted_setup

以下を確認してください:

AIゲートウェイURLが正しく設定されている（Ai::Setting.instance.ai_gateway_urlを使用）。
/admin/code_suggestionsを介して、ルートユーザーに対してDuoアクセスが明示的に有効になっている。

アクセスに関する問題が解決しない場合は、認証が正しく設定されていること、およびヘルスチェックに合格していることを確認してください。

問題が解決しない場合は、エラーメッセージでAIGW_AUTH__BYPASS_EXTERNAL=trueによる認証の回避が提案されることがありますが、これはトラブルシューティングの場合にのみ行ってください。

ヘルスチェックは、管理者 > GitLab Duoに移動して実行することもできます。

これらのテストはオフライン環境で実行されます:

Test	説明
ネットワーク	以下をテストします: - AIゲートウェイURLが`ai_settings`テーブルを介してデータベースで正しく設定されているか。 - インスタンスが設定されたURLに接続できるか。インスタンスがURLに接続できない場合は、ファイアウォールまたはプロキシサーバーの設定で接続を許可されていることを確認してください。環境変数`AI_GATEWAY_URL`はレガシー互換性のために引き続きサポートされていますが、データベースを介してURLを設定することを推奨します。
ライセンス	ライセンスにコード提案機能へのアクセス機能があるかどうかをテストします。
システム交換	コード提案をインスタンスで使用できるかどうかをテストします。システム交換評価が失敗した場合、ユーザーはGitLab Duo機能を使用できない可能性があります。

AIゲートウェイはオートスケールする必要がありますか?

オートスケールは必須ではありませんが、変動するワークロード、高い並行処理要件、または予測できない使用パターンを持つ環境に推奨されます。GitLabの本番環境の場合:

ベースライン設定: 2つのvCPUコアと8GBのRAMを搭載した単一のAIゲートウェイインスタンスは、約40件の同時リクエストを処理できます。
スケールのガイドライン: より大規模な設定（AWS t3.2xlargeインスタンス（8つのvCPU、32GBのRAMなど））の場合、ゲートウェイは最大160件の同時リクエストを処理でき、ベースライン設定の4倍に相当します。
リクエストスループット: GitLab.comでの利用状況の観察から、アクティブユーザー1,000人あたり7 RPS（1秒あたりのリクエスト数）が計画の妥当なメトリクスであることが示唆されています。
オートスケールオプション: Kubernetes Horizontalポッドオートスケールs（HPA）または同様のメカニズムを使用して、CPU、メモリ使用率、要求レイテンシーのしきい値などのメトリクスに基づいてインスタンス数を動的に調整します。

デプロイサイズ別の設定例

小規模なデプロイ:
- 2 vCPUと8 GBのRAMを搭載した単一インスタンス。
- 最大40件の同時リクエストを処理します。
- 最大50人のユーザーと予測可能なワークロードを持つチームまたは組織。
- 固定インスタンスで十分な場合があります。オートスケールは、コスト効率性のために無効にできます。
中規模なデプロイ:
- 8 vCPUと32 GBのRAMを搭載した単一のAWS t3.2xlargeインスタンス。
- 最大160件の同時リクエストを処理します。
- 50 ～ 200人のユーザーと適度な並行処理要件を持つ組織。
- 50% のCPU使用率または500ミリ秒を超える要求レイテンシーのしきい値でKubernetes HPAを実装します。
大規模なデプロイ:
- 複数のAWS t3.2xlargeインスタンスまたは同等のもののクラスター。
- 各インスタンスは160件の同時リクエストを処理し、複数のインスタンスを持つ数千人のユーザーにスケールします。
- 200人を超えるユーザーと、変動する高並行処理ワークロードを持つ企業。
- HPAを使用して、リアルタイムの需要に基づいてポッドをスケールし、クラスター全体のリソース調整のためにノードオートスケールと組み合わせます。

AIゲートウェイコンテナがアクセスできる仕様は何ですか？また、リソースの割り当てはパフォーマンスにどのように影響しますか？

AIゲートウェイは、次のリソース割り当てで効果的に動作します:

コンテナごとに2つのvCPUコアと8 GBのRAM。
コンテナは通常、GitLabの本番環境で約7.39% のCPUと比例したメモリを使用し、成長やバーストアクティビティーの処理に対応できる余地を残しています。

リソースの競合を軽減するための戦略

Kubernetesのリソースリクエストと制限を使用して、AIゲートウェイコンテナが保証されたCPUおよびメモリ割り当てを受け取るようにします。例:
```
resources:
  requests:
    memory: "16Gi"
    cpu: "4"
  limits:
    memory: "32Gi"
    cpu: "8"
```
PrometheusやGrafanaなどのツールを実装して、リソース使用率（CPU、メモリ、レイテンシー）を追跡し、ボトルネックを早期に検出します。
ノードまたはインスタンスをAIゲートウェイ専用にして、他のサービスとのリソース競合を防ぎます。

スケーリング戦略

Kubernetes HPAを使用して、次のようなリアルタイムのメトリクスに基づいてポッドをスケールします:
- 平均CPU使用率が50% を超える。
- 要求レイテンシーが常に500ミリ秒を超える。
- ノードオートスケールを有効にして、ポッドの増加に応じてインフラストラクチャリソースを動的にスケールします。

スケーリングに関する推奨事項

デプロイサイズ	インスタンスタイプ	リソース	キャパシティ（同時リクエスト数）	スケーリングに関する推奨事項
S	2 vCPU、8 GB RAM	シングルインスタンス	40	固定デプロイ；オートスケールなし。
中程度	AWS t3.2xlarge	シングルインスタンス	160	CPUまたはレイテンシーのしきい値に基づくHPA。
L	複数のt3.2xlarge	クラスター化されたインスタンス	インスタンスあたり160	高需要に対応するHPA + ノードオートスケール。

複数のGitLabインスタンスのサポート

単一のAIゲートウェイをデプロイして複数のGitLabインスタンスをサポートしたり、インスタンスごとまたは地理的リージョンごとに個別のAIゲートウェイをデプロイしたりできます。どちらが適切かを判断するために、以下を考慮してください:

1,000人の請求対象ユーザーあたり、1秒あたり約7件のトラフィックが予想される。
すべてのインスタンスにわたる合計の同時リクエスト数に基づくリソース要件。
各GitLabインスタンスのベストプラクティス認証設定。

AIゲートウェイとインスタンスのコロケーション

AIゲートウェイは、場所に関係なく、ユーザーに最適なパフォーマンスを確保するために、グローバルに複数のリージョンで利用できます:

Duo機能の応答時間の改善。
地理的に分散したユーザーのレイテンシーの削減。
データの主権要件へのコンプライアンス。

GitLabインスタンスと同じ地理的リージョンにAIゲートウェイを配置して、特にコード提案のようなレイテンシーの影響を受けやすい機能に対して、摩擦のないDevExを提供するのに役立ちます。

トラブルシューティング

AIゲートウェイの操作中に、以下の問題が発生する可能性があります。

OpenShiftのパーミッションに関するイシュー

OpenShiftにAIゲートウェイをデプロイすると、OpenShiftのセキュリティモデルが原因で、パーミッションエラーが発生する可能性があります。

`/tmp`ディレクトリの読み取り専用ファイルシステム

AIゲートウェイは/tmpに書き込む必要があります。ただし、セキュリティが制限されているOpenShift環境では、/tmpが読み取り専用になっている可能性があります。

このイシューを解決するには、新しいEmptyDirボリュームを作成し、/tmpにマウントします。これを行うには、次のいずれかの方法があります:

コマンドラインから:

oc set volume <object_type>/<name> --add --name=tmpVol --type=emptyDir --mountPoint=/tmp

次の場所に追加: values.yaml:

volumes:
- name: tmp-volume
  emptyDir: {}

volumeMounts:
- name: tmp-volume
  mountPath: "/tmp"

HuggingFaceモデル

デフォルトでは、AIゲートウェイはHuggingFaceモデルをキャッシュするために/home/aigateway/.hfを使用しますが、これはOpenShiftのセキュリティが制限された環境では書き込み可能ではない可能性があります。これにより、次のようなパーミッションエラーが発生する可能性があります:

[Errno 13] Permission denied: '/home/aigateway/.hf/...'

これを解決するには、HF_HOME環境変数を書き込み可能な場所に設定します。/var/tmp/huggingfaceまたは、コンテナが書き込み可能な他のディレクトリを使用できます。

これを行うには、次のいずれかの方法があります:

次の場所に追加: values.yaml:

extraEnvironmentVariables:
  - name: HF_HOME
    value: /var/tmp/huggingface  # Use any writable directory

または、Helmアップグレードコマンドに含めます:

--set "extraEnvironmentVariables[0].name=HF_HOME" \
--set "extraEnvironmentVariables[0].value=/var/tmp/huggingface"  # Use any writable directory

この設定により、AIゲートウェイは、OpenShiftのセキュリティ制約を尊重しながら、HuggingFaceモデルを適切にキャッシュできます。選択する正確なディレクトリは、特定のOpenShiftの設定およびセキュリティポリシーによって異なる場合があります。

自己署名証明書エラー

AIゲートウェイがカスタムCA（CA）によって署名された証明書、または自己署名証明書を使用してGitLabインスタンスまたはモデルエンドポイントに接続しようとすると、[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chainエラーがAIゲートウェイによってログに記録されます。

これを解決するには、自己署名SSL証明書を使用してGitLabインスタンスまたはモデルエンドポイントに接続するを参照してください。

GitLab AIゲートウェイをインストールする

Dockerを使用してインストールする

AIゲートウェイイメージを探す

イメージからコンテナを起動する

NGINXとSSLを使用してDockerをセットアップする

設定ファイルを作成

Let’s Encryptを使用してSSL証明書を設定する

環境変数ファイルを作成する

Docker-composeファイルを作成する

デプロイして検証する

Helm Chartを使用してインストールする

AIゲートウェイHelmリポジトリを追加する

AIゲートウェイをインストールする

自己署名SSL証明書を使用してGitLabインスタンスまたはモデルエンドポイントに接続する

ルートCA証明書をAIゲートウェイに渡す

AIゲートウェイコンテナのCAバンドルにルートCA証明書を追加する

Dockerデプロイの場合

AIゲートウェイDockerイメージをアップグレードする

代替インストール方法

ヘルスチェックとデバッグ

AIゲートウェイはオートスケールする必要がありますか?

デプロイサイズ別の設定例

AIゲートウェイコンテナがアクセスできる仕様は何ですか？また、リソースの割り当てはパフォーマンスにどのように影響しますか？

リソースの競合を軽減するための戦略

スケーリング戦略

スケーリングに関する推奨事項

複数のGitLabインスタンスのサポート

AIゲートウェイとインスタンスのコロケーション

トラブルシューティング

OpenShiftのパーミッションに関するイシュー

/tmpディレクトリの読み取り専用ファイルシステム

HuggingFaceモデル

自己署名証明書エラー

`/tmp`ディレクトリの読み取り専用ファイルシステム