Posts

エラーの概要 GitLab の 400 エラーは、「Bad Request」を意味し、GitLab API またはウェブインターフェースへのリクエストの形式や内容に誤りがある場合に発生します。これは、サーバーがリクエストを正しく解析できない、または必須情報が不足していることを示します。CI/CD パイプラインの実行時やプロジェクト管理操作の際に頻出するエラーです。 実際のエラーメッセージ例 API リクエストの場合： { "message": "400 Bad Request", "error": "Invalid JSON body", "error_description": "The request body could not be parsed as JSON" } CI/CD パイプライン実行時： ERROR: (ci::pipeline:creation) This project does not have CI enabled 400 Bad Request - The request body contains invalid fields よくある原因と解決手順 原因1：JSON リクエストボディの形式エラーまたは必須フィールドの欠落 GitLab API への POST/PUT リクエストで、JSON の形式が壊れているか、API が必須とするフィールドが含まれていません。特に issue 作成や merge request の更新時に頻発します。 Before（エラーが起きるコード）： curl -X POST "https://gitlab.example.com/api/v4/projects/<project_id>/issues" \ -H "PRIVATE-TOKEN: <token>" \ -H "Content-Type: application/json" \ -d '{ "title": "New Issue" "description": "Missing comma and required labels field" }' After（修正後）： ...

エラーの概要 GitLab で 401 Unauthorized エラーが発生する場合、クライアントからのリクエストが認証されていない、または認証情報が無効であることを示しています。GitLab API へのアクセス、Git クローン、パイプラインからのリソース取得など、認証が必要な操作全般で発生する可能性があります。このエラーが出た場合、提供されたトークンや認証情報を確認し、それらの有効性と形式を検証する必要があります。 実際のエラーメッセージ例 GitLab API レスポンス： { "message": "401 Unauthorized" } curl コマンドの出力： $ curl -H "Authorization: Bearer invalid-token" https://gitlab.example.com/api/v4/user {"message":"401 Unauthorized"} Git クローン時のエラー： $ git clone https://gitlab.example.com/group/project.git Cloning into 'project'... fatal: Authentication failed for 'https://gitlab.example.com/group/project.git/' よくある原因と解決手順 原因1：パーソナルアクセストークン（PAT）が無効または期限切れになっている GitLab のパーソナルアクセストークンには有効期限が設定でき、期限を過ぎたトークンでリクエストを送信すると 401 エラーが返されます。また、トークンを無効化した場合や、ユーザーアカウント設定で特定のスコープを失った場合も認証に失敗します。特に CI/CD パイプラインやスクリプトで長期間使用するトークンは、期限切れに気づきにくいため注意が必要です。 Before（エラーが起きるコード）： # 2024年1月に作成したトークンを2024年12月に使用しようとしている場合 $ curl -H "PRIVATE-TOKEN: glpat-xxxxxxxxxxxx" \ https://gitlab.example.com/api/v4/user # → 401 Unauthorized が返される After（修正後）： # GitLab UI で新しいパーソナルアクセストークンを生成 # User Settings → Access Tokens → Add new token # スコープ: api, read_user, read_repository などを選択 $ curl -H "PRIVATE-TOKEN: <your-gitlab-token>" \ https://gitlab.example.com/api/v4/user # → 200 OK で成功 原因2：Authorization ヘッダーの形式が誤っている GitLab API にアクセスする際、Authorization ヘッダーの形式が仕様と異なると認証失敗になります。Bearer トークンを使う場合と PRIVATE-TOKEN ヘッダーを使う場合で形式が異なり、特に古いドキュメントを参照している場合に混同しやすいです。また、トークン前後の空白や特殊文字の誤りも 401 の原因になります。 ...

エラーの概要 GitLab の 403 エラーは、認証済みのユーザーがプロジェクトやリソースへのアクセス権限を持たないときに返されるアクセス拒否エラーです。認証自体は成功していますが、実行しようとしたアクション（プッシュ、マージリクエストの作成、設定変更など）の権限がないことを示します。GitLab での権限管理はロールベースアクセス制御（RBAC）に基づいており、プロジェクトメンバーシップ、グループ設定、ブランチ保護ルールなどの複数の層で管理されるため、原因の特定には段階的な確認が必要です。 実際のエラーメッセージ例 Git コマンドライン実行時： $ git push origin feature-branch remote: GitLab: You are not allowed to push code to this project. fatal: unable to access 'https://gitlab.example.com/group/project.git/': The requested URL returned error: 403 GitLab Web UI のレスポンス： { "message": "403 Forbidden", "error": "You do not have permission to perform this action" } パイプラインや API 呼び出し時： $ curl -H "PRIVATE-TOKEN: <your-token>" https://gitlab.example.com/api/v4/projects/123/issues {"message":"403 Forbidden"} よくある原因と解決手順 原因1：プロジェクトメンバーのロール権限が不足している GitLab では、プロジェクトへのアクセスレベルが細分化されています。Guest（ゲスト）や Reporter（レポーター）ロールでは、コードのプッシュやマージリクエストの承認などの重要な操作ができません。ユーザーが必要な操作を実行しようとしても、割り当てられたロールに権限がなければ 403 エラーが発生します。 修正方法： GitLab の Web UI から、対象プロジェクトの Settings → Members に移動し、ユーザーのロールを Developer 以上に変更します。変更後、ユーザーはコードをプッシュできるようになります。 ...

エラーの概要 Terraform の 409 エラーは、Terraform が作成・更新しようとするリソースが既にクラウド環境に存在し、状態ファイル（tfstate）に記録された期待値と実際のリソース状態に競合が生じていることを示します。このエラーは特にマルチユーザー環境や手動でリソースを作成した後に Terraform で管理を開始する場合に発生しやすくなります。 実際のエラーメッセージ例 Error: Error creating XXX: XXX (xxx): InvalidParameterException: Resource already exists on main.tf line 42, in resource "aws_instance" "web": 42: resource "aws_instance" "web" { Error: ConflictException { "error": "conflict", "message": "The resource with name 'my-bucket' already exists", "status_code": 409 } よくある原因と解決手順 原因 1：手動で作成したリソースを Terraform で管理しようとしている クラウド管理コンソールやコマンドラインで直接作成したリソースに対して、Terraform コードで同じリソースを定義すると、Terraform はそのリソースが「新規作成される対象」だと判断します。しかし実際にはリソースが存在するため、作成時に 409 エラーで競合が検出されます。 この場合、terraform import コマンドを使い、既存のリソースを Terraform の管理下に移す必要があります。 Before（エラーが起きるコード）： resource "aws_s3_bucket" "data_bucket" { bucket = "my-existing-bucket" } AWS マネジメントコンソールで my-existing-bucket が既に存在している場合、terraform apply 実行時に 409 エラーが発生します。 ...

エラーの概要 HTTP 429 エラーは「Too Many Requests」を意味し、Terraform の実行時にクラウドプロバイダーの API レート制限に達したことを示します。AWS・Google Cloud・Azure など複数のプロバイダーが API 呼び出しの頻度を制限しており、Terraform がこの上限を超えたときに発生します。特に大規模なインフラストラクチャをコード化する際に、並列処理による過度な API 呼び出しが原因となることが多くあります。 実際のエラーメッセージ例 Terraform 実行時に以下のようなエラーが出力されます。 { "error": "error creating Security Group: RequestLimitExceeded: Request limit exceeded", "status_code": 429 } また、Terraform の標準出力では以下のように表示されることもあります。 Error: Error creating load balancer: InvalidParameterValue on main.tf line 42, in resource "aws_lb" "example": 42: resource "aws_lb" "example" { 429 Too Many Requests よくある原因と解決手順 原因 1：Terraform の並列実行数が多すぎる Terraform はデフォルトで 10 個のリソースを同時に作成する設定になっており、これが API レート制限に抵触します。特に AWS や Google Cloud のプロバイダーでは、単位時間あたりの API 呼び出し数に制限があり、デフォルトの並列度では超過しやすくなります。 修正前： terraform apply -auto-approve # デフォルトの並列度 10 で実行 修正後： ...

エラーの概要 Terraform の 401 エラーは、クラウドプロバイダー（AWS・Azure・GCP等）または Terraform Cloud/Enterprise への認証に失敗したときに発生します。認証情報の不足・期限切れ・形式エラーなどが原因で、リソースの操作やプランの実行が中断されます。 実際のエラーメッセージ例 Error: error configuring Terraform AWS Provider: error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid on main.tf line 1, in provider "aws": 1: provider "aws" { Error: Failed to retrieve available provider versions from Terraform Registry (registry.terraform.io). This may be caused by network connectivity issues, or an incorrect API token. HTTP status code: 401 Unauthorized よくある原因と解決手順 原因1：AWS アクセスキーの認証情報が不正または期限切れ AWS のアクセスキーが間違っているか、IAM（AWS Identity and Access Management）ユーザーの権限が削除されている場合に発生します。特に複数の AWS アカウントを扱う環境では、設定ミスが起こりやすくなります。 Before（エラーが起きるコード）： # 期限切れまたは不正なキーを使用 export AWS_ACCESS_KEY_ID=<your-access-key-id> export AWS_SECRET_ACCESS_KEY=<your-secret-access-key> terraform plan After（修正後）： # 最新の認証情報を取得・確認 aws sts get-caller-identity # 有効なキーを再設定 export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7NEWKEY export AWS_SECRET_ACCESS_KEY=<your-secret-access-key> # または ~/.aws/credentials ファイルで管理 cat ~/.aws/credentials terraform plan 原因2：環境変数が設定されていない Terraform が認証情報を探すとき、環境変数（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY など）が未設定の場合、プロバイダー認証に失敗します。特に CI/CD パイプラインやサーバーレス環境では見落としやすい原因です。 ...

エラーの概要 Terraform が AWS などのクラウドプロバイダーにリソースの作成・更新・削除を要求したとき、IAM ポリシーまたは SCP（Service Control Policy）により操作が拒否される状態です。このエラーは実行ロールに必要な権限がないか、組織レベルの制限によって操作が許可されていないことを示しています。 実際のエラーメッセージ例 { "Error": { "Code": "AccessDenied", "Message": "User: arn:aws:iam::123456789012:user/terraform-user is not authorized to perform: ec2:RunInstances on resource: arn:aws:ec2:us-east-1:123456789012:instance/* with an implicit deny in user-based policy" } } Error: error creating EC2 Instance: UnauthorizedOperation.Unavailable: You are not authorized to perform this operation. status code: 403, request id: <request-id> on main.tf line 10, in resource "aws_instance" "example": 10: resource "aws_instance" "example" { よくある原因と解決手順 原因1：実行ロールに IAM ポリシーの権限が不足している Terraform を実行するユーザーまたはロールに、リソース作成に必要な IAM 権限がアタッチされていません。例えば EC2 インスタンスを起動する場合、ec2:RunInstances アクションの許可が必要です。IAM ポリシーシミュレーター（ポリシーが実際に機能するかを事前検証するツール）で実際に権限が付与されているかを確認し、不足している権限をポリシーに追加します。 ...

エラーの概要 Terraform の 404 エラーは、設定ファイルで参照しているクラウドリソースが実際には存在しないか、削除されている状態を示します。このエラーが発生すると、terraform plan や terraform apply の実行が中断され、リソース間の依存関係が解決できません。特に data source を使ってリソース情報を取得する場合や、既存リソースを参照する設定で頻出します。 実際のエラーメッセージ例 AWS Provider での例： Error: error reading EC2 Instance: InvalidInstanceID.NotFound on main.tf line 12, in data "aws_instance" "existing": 12: data "aws_instance" "existing" { │ │ InvalidInstanceID.NotFound: The instance ID 'i-0123456789abcdef0' does not exist Google Cloud Provider での例： Error: Error when reading or editing Compute Instance: googleapi: Error 404: The resource 'projects/my-project/zones/us-central1-a/instances/old-instance' was not found よくある原因と解決手順 原因 1：data source で参照しているリソースがまだ作成されていないか削除されている リソースを作成する前に、そのリソース情報を data source で参照しようとするケースがよくあります。また、クラウドコンソールから手動でリソースを削除した場合、Terraform の state ファイルにはまだ存在するとして記録されたままになり、再度参照しようとすると 404 エラーになります。 Before（エラーが起きるコード）： # EC2 インスタンスを作成する前に参照しようとしている data "aws_instance" "existing" { instance_ids = ["i-0123456789abcdef0"] } resource "aws_instance" "new" { ami = data.aws_instance.existing.ami instance_type = "t3.micro" } After（修正後）： ...

エラーの概要 Terraform で 400 エラーが発生する場合、これはクラウドプロバイダーの API が「不正なリクエスト」と判定したことを意味します。HCL の構文自体は正しくても、リソース定義のパラメーター型や値がプロバイダーの期待形式と一致していない場合に起こります。terraform apply 実行時に最も頻繁に遭遇するエラーで、本来なら terraform plan で事前に検出すべき問題です。 実際のエラーメッセージ例 Error: error creating DB Instance: BadRequest: 400 Bad Request on main.tf line 15, in resource "aws_db_instance" "example": 15: resource "aws_db_instance" "example" { with aws_db_instance.example, on main.tf line 15, in resource "aws_db_instance" "example": 15: resource "aws_db_instance" "example" { Error: Error making API call: status code 400, message: invalid parameter value $ terraform apply Error: error creating resource: BadRequest: The request body is malformed │ │ with module.vpc.aws_security_group.allow_ssh: │ on vpc/main.tf line 42, in resource "aws_security_group" "allow_ssh": │ 42: resource "aws_security_group" "allow_ssh" { よくある原因と解決手順 原因 1：リソースパラメーターの型が不正 Terraform のプロバイダーが期待する型（文字列、数値、リスト等）と異なる型で値を指定すると、API リクエスト生成時に 400 エラーが発生します。特に、数値として指定すべきポート番号を文字列で渡したり、ブール値を文字列で指定したりするケースが多く見られます。 Before（エラーが起きるコード）： resource "aws_security_group" "example" { name = "example-sg" description = "Example security group" ingress { from_port = "80" # 型エラー：文字列ではなく数値であるべき to_port = "443" # 型エラー protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } depends_on = true # 型エラー：ブール値ではなく string の list } After（修正後）： ...

エラーの概要 Azure 503 エラーは「Service Unavailable」を意味し、Azureサービスが一時的に利用できない状態を示します。リクエストがサーバーに到達しても、システムの過負荷、メンテナンス、インフラ障害などによってレスポンスを返すことができません。このエラーは一時的な場合が多いため、リトライ戦略を実装することが重要です。 実際のエラーメッセージ例 Azure Portal の HTTP レスポンス： HTTP/1.1 503 Service Unavailable Content-Type: application/json Retry-After: 60 { "error": { "code": "ServiceUnavailable", "message": "The service is currently unavailable. Please try again later.", "target": "App Service" } } Azure CLI からのエラー出力： ERROR: (BadRequest) Service Unavailable: The service is temporarily unavailable. Please retry the request after some time. RequestId: abc123def456 よくある原因と解決手順 原因1：Azureリージョンで障害が発生している Azure のデータセンター障害やメンテナンス作業により、特定のリージョン全体がサービス停止している場合があります。この場合、アプリケーション側での修正では解決できず、Azure のサービス復旧を待つか、別リージョンへの切り替えが必要です。 Before（エラーが起きるコード）： # 単一のリージョンにのみデプロイされている from azure.storage.blob import BlobServiceClient account_url = "https://mystorageaccount.blob.core.windows.net" blob_service_client = BlobServiceClient(account_url=account_url) try: container_client = blob_service_client.get_container_client("mycontainer") blobs = container_client.list_blobs() except Exception as e: print(f"Error: {e}") # リージョン障害時は対応策がない After（修正後）： ...