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

ワークスペースのトラブルシューティング

GitLabワークスペースを使用する場合、次の問題が発生する可能性があります。

エラー: Failed to renew lease

ワークスペースの作成時に、エージェントのログファイルに次のエラーメッセージが表示されることがあります:

{"level":"info","time":"2023-01-01T00:00:00.000Z","msg":"failed to renew lease gitlab-agent-remote-dev-dev/agent-123XX-lock: timed out waiting for the condition\n","agent_id":XXXX}

このエラーは、Kubernetes向けGitLabエージェントの既知の問題が原因です。このエラーは、エージェントインスタンスがリーダーシップリースを更新できず、remote_developmentなどのリーダーのみのモジュールがシャットダウンすることが原因で発生します。

この問題を解決するには、以下を実行します:

  1. エージェントインスタンスを再起動します。
  2. 問題が解決しない場合は、Kubernetesクラスターのヘルスと接続を確認してください。

エラー: No agents available to create workspaces

プロジェクトでワークスペースを作成するときに、次のエラーが発生することがあります:

No agents available to create workspaces. Please consult Workspaces documentation for troubleshooting.

このエラーは、いくつかの理由で発生する可能性があります。次のトラブルシューティングの手順を実行してください。

権限を確認する

  1. ワークスペースプロジェクトとエージェントプロジェクトの両方に対して、少なくともデベロッパーロールがあることを確認してください。
  2. エージェントがワークスペースプロジェクトの祖先グループで許可されていることを確認します。詳細については、エージェントを許可するを参照してください。

エージェントの設定

remote_developmentモジュールがエージェントの設定で有効になっていることを確認します:

remote_development:
  enabled: true

Kubernetes向けGitLabエージェントでremote_developmentモジュールが無効になっている場合は、enabledtrueに設定します。

エージェント名の不一致を確認する

KubernetesトークンのGitLabエージェントを作成するの手順で作成したエージェント名が、.gitlab/agents/FOLDER_NAME/のフォルダー名と一致していることを確認します。

名前が異なる場合は、エージェント名と正確に一致するようにフォルダーの名前を変更します。

エージェント接続ステータスを確認する

エージェントがGitLabに接続されていることを確認します:

  1. グループに移動します。

  2. 操作 > Kubernetesクラスターを選択します。

  3. 接続ステータス接続済みかどうかを確認します。接続されていない場合は、エージェントのログを確認してください。接続されていない場合は、エージェントのログを確認してください:

    kubectl logs -f -l app=gitlab-agent -n gitlab-workspaces

エラー: unsupported scheme in GitLab Kubernetes Agent Server address

このエラーは、KubernetesエージェントServer(KAS)アドレスに必要なプロトコルスキームがない場合に発生します。

この問題を解決するには、以下を実行します:

  1. TF_VAR_kas_address変数にwss://プレフィックスを追加します。例: wss://kas.gitlab.com
  2. 設定を更新して、エージェントを再デプロイします。

エラー: オフライン環境でワークスペースを起動するときのImagePullBackOff

オフライン環境でワークスペースを作成すると、次のエラーが表示されることがあります:

workspace-example-abc123-def456   0/1   Init:ImagePullBackOff   0

このエラーは、ワークスペースがregistry.gitlab.comからinitコンテナイメージをプルできない場合に発生します。オフライン環境では、initコンテナイメージがハードコードされており、devfileから上書きできません。

次の回避策はサポートされておらず、一時的なものです。issue 509983でサポートされているソリューションが提供されるまで、ご自身の責任で使用してください。

回避策は次のとおりです:

  1. コンテナイメージの参照を変更するために、Kubernetes mutating webhookをデプロイします。
  2. MutatingWebhookConfigurationを作成、更新、または削除するには、クラスターの管理者権限が必要です。

実装例については、シンプルなKubernetesアドミッションWebhookを参照してください。

エラー: redirect URI included is not valid

ワークスペースにアクセスすると、無効なリダイレクトURIに関するOAuthエラーが発生することがあります。

このエラーは、次の理由で発生する可能性があります:

  • OAuthアプリケーションが正しく設定されていません。この問題を解決するには、以下を実行します:

    1. GitLabのOAuthアプリケーションのリダイレクトURIがドメインと一致することを確認します。
    2. OAuthアプリケーションのリダイレクトURIを更新します。例: https://YOUR_DOMAIN/auth/callback
  • ワークスペースプロキシが古いOAuth認証情報を使用しています。この問題を解決するには、次のようにします:

    1. プロキシが最新のOAuth認証情報を使用していることを確認します。

    2. ワークスペースプロキシを再起動します:

      kubectl rollout restart deployment -n gitlab-workspaces gitlab-workspaces-proxy

エラー: Workspace does not exist

VS Codeで次のエラーが表示されることがあります。

Workspace does not exist

Please select another workspace to open.

この問題は、ワークスペースは正常に起動するものの、Gitクローン操作が失敗したために、予期されるプロジェクトディレクトリが見つからない場合に発生します。Gitクローン操作は、ネットワークの問題、インフラストラクチャの問題、または失効したリポジトリ権限が原因で失敗します。

この問題を解決するには、以下を実行します:

  1. エラーダイアログで別のワークスペースを選択するように求められたら、キャンセルを選択します。

  2. VS Codeメニューから、ファイル > Open Folder(フォルダーを開く) を選択します。

  3. /projectsディレクトリに移動し、OKを選択します。

  4. EXPLORER(エクスプローラー)パネルで、プロジェクトと同じ名前のディレクトリがあるかどうかを確認します。

    • ディレクトリが見つからない場合は、Gitクローン操作が完全に失敗しました。
    • ディレクトリが存在するが空の場合は、クローン操作は開始されたものの完了しませんでした。
  5. ターミナルを開きます。メニューからターミナル > New Terminal(新しいターミナル) を選択します。

  6. ワークスペースのログディレクトリに移動します:

    cd /tmp/workspace-logs/
  7. Gitクローンが失敗した理由を示すエラー出力がないかログを確認します:

    less poststart-stderr.log
  8. 特定された問題を解決し、ワークスペースを再起動します。

問題が解決しない場合は、Gitを含む作業中のコンテナイメージを使用して、新しいワークスペースを作成します。

postStartイベントをデバッグする

カスタムpostStartイベントが失敗した場合、または期待どおりに動作しない場合は、ワークスペースログディレクトリを使用して問題をデバッグできます。

一般的なpostStartデバッグシナリオとその解決策:

  • Command not found: コンテナイメージに依存関係がないことを示すエラーがないかpoststart-stderr.logを確認してください。
  • Permission denied: poststart-stderr.logで、ファイルの権限またはユーザー設定の調整が必要な権限エラーがないか確認します。
  • Network issues: postStartイベントが依存関係をダウンロードしたり、外部リソースにアクセスしたりするときに、接続タイムアウトまたはDNS解決の失敗がないか確認します。
  • Long-running commands: postStartイベントがハングアップする場合は、poststart-stdout.logを調べて、コマンドがまだ実行中か、正常に完了したかを確認します。

postStartコマンド実行ログを確認するには:

  1. ワークスペースでターミナルを開きます。

  2. ワークスペースのログディレクトリに移動します:

    cd /tmp/workspace-logs/
  3. ログファイルを表示します:

    # Monitor postStart execution output in real-time
    tail -f poststart-stdout.log
    
    # Check postStart errors
    cat poststart-stderr.log
    
    # Check VS Code server startup
    cat start-vscode.log
  4. エラーがないか確認します:

    # Search for error messages across all logs
    grep -i error *.log
    
    # Search for specific command output
    grep "your-command-name" poststart-stdout.log
  5. 特定された問題を解決し、ワークスペースを再起動します。

詳細については、ワークスペースログディレクトリ利用可能なログファイルを参照してください。