Posts

冒頭まとめ AWS CLIやboto3で次のエラーが出たら、その処理が参照できる場所に認証情報が見つかっていません。 Unable to locate credentials. You can configure credentials by running "aws configure". まず、エラーが出た環境でaws configure listを実行します。プロファイルを指定しているなら、確認コマンドにも同じ--profileを付けてください。手元のターミナルでは成功しても、DockerやCI、別の実行ユーザーでは設定ファイルも環境変数も異なります。 開発環境では使用するプロファイルとログイン状態、EC2ではインスタンスプロファイル、ECSではタスクロールを確認します。認証情報が見つからない段階なので、S3の権限を増やしてもこのエラーは解消しません。 Unable to locate credentialsの意味 Pythonでは次のように表示されます。 botocore.exceptions.NoCredentialsError: Unable to locate credentials botocoreの例外定義では、NoCredentialsErrorの本文をUnable to locate credentialsとしています。要求に署名する処理は、認証情報がNoneならこの例外を送出します。 これはAWSサービスが返すAccessDeniedとは異なります。署名付きの要求を送るための認証情報を、クライアント側で取得できていない状態です。boto3のクライアントを作成できても、実際にAPIを呼ぶときに初めてエラーが出ることがあります。 AWS CLIに表示されるaws configureの案内は、設定方法の一例です。組織がIAM Identity Centerを使っている場合や、EC2・ECSのロールを利用する場合まで、アクセスキーを手入力する必要があるわけではありません。 最初に取得元とプロファイルを確認する 失敗したコマンドと同じユーザー、同じコンテナ、同じCIのステップで確認します。 aws configure list access_keyとsecret_keyが<not set>なら、その実行条件では取得できていません。値が表示される場合は、TypeとLocationで取得元を確認します。環境変数から取得していればenv、共有認証情報ファイルならshared-credentials-fileなどが表示されます。取得処理自体に問題がある場合は、この確認コマンドもエラーになることがあります。 プロファイルを指定している場合は、次のように同じ指定で調べます。devは実際のプロファイル名に置き換えてください。 aws configure list --profile dev aws sts get-caller-identity --profile dev 後者が成功したら、返されたAccountとArnが想定したアカウントとロールか確認します。成功しても、S3などの個別の操作が許可されているとは限りません。 CLIでは成功し、Pythonだけ失敗する場合は、Pythonが同じプロファイルを使っているか確認します。 import boto3 session = boto3.Session(profile_name="dev") identity = session.client("sts", region_name="ap-northeast-1").get_caller_identity() print(identity["Account"], identity["Arn"]) この例はローカルのdevプロファイルを使う場合の確認です。EC2やECSのロールを使うプログラムでは、プロファイル名を固定せずboto3.Session()で既定の取得経路を使います。 認証情報の優先順位を確認する boto3は複数の取得元を順に調べ、認証情報を取得できたところで探索を止めます。公式の認証情報ガイドには、クライアントやSessionへの明示的な指定、環境変数、AssumeRole、Web Identity、IAM Identity Center、共有ファイル、コンテナ、EC2メタデータなどの順序が記載されています。取得元の種類はバージョンによって追加されるため、単に「環境変数かファイルのどちらか」と考えると、実際の取得元を見落とします。 ...

冒頭まとめ npm installやnpm ciでENOTFOUNDが出た場合、通信に必要なホスト名をIPアドレスへ変換できていません。最初に見るのは、ログのgetaddrinfo ENOTFOUNDの直後にあるホスト名です。 npm error code ENOTFOUND npm error network request to https://registry.npmjs.org/express failed, reason: getaddrinfo ENOTFOUND registry.npmjs.org この例ならregistry.npmjs.orgを調べます。社内の取得先やプロキシの名前が表示されているなら、そのホストの設定と名前解決を確認してください。取得先のURLだけを見て、npmの公開サーバーに障害があると判断するのは早い段階です。 同じ実行環境で名前解決を確認し、失敗するホストに対応する設定を直します。社内の取得先を使うプロジェクトでは、公開の取得先や外部のDNSへ一律に変更しないでください。 ENOTFOUNDが示す失敗 DNSは、ホスト名からIPアドレスを調べる仕組みです。ただし、ログにあるgetaddrinfoはOSの名前解決処理を指し、DNSへの問い合わせだけを行うとは限りません。Node.jsのdns.lookup()はこのOSの仕組みを使います。 Node.jsの公式文書は、ENOTFOUNDがホスト名の不存在だけでなく、ファイル記述子の不足など、ほかの理由で名前解決に失敗した場合にも出ると説明しています。したがって、この符号だけで「DNSサーバーに届き、その名前は存在しないと回答された」とは断定できません。 npmの表示はバージョンによってnpm errorやnpm ERR!などが異なります。共通して確認するのはENOTFOUNDと、解決できなかったホスト名です。 npmのエラー表示の実装では、ENOTFOUNDはECONNRESETやETIMEDOUTなどと同じ分岐で、ネットワークやプロキシを確認する案内を出しています。その案内が表示されたからといって、プロキシが原因だと決まるわけではありません。 ログのホスト名を同じ環境で確認する ログの取得先URLと、getaddrinfo ENOTFOUNDの後ろにある名前を分けて読みます。 request to https://registry.npmjs.org/leftpad failed, reason: getaddrinfo ENOTFOUND invalid この例で解決できていないのはregistry.npmjs.orgではなくinvalidです。npm/cliのIssue #6835には、npm 9.8.1でHTTPS_PROXY=http://invalidを指定した際のこのログが記録されています。プロキシの名前解決が失敗しても、要求先のURLにはnpmの取得先が表示されます。この報告は特定バージョンの比較なので、すべてのnpmで同じ挙動になる証拠としては扱いません。 まず、失敗した環境で次を実行します。最後の引数は、ログに表示された実際のホスト名に置き換えてください。URL全体ではなく、ホスト名だけを渡します。 node -e "require('node:dns').lookup(process.argv[1], {all:true}, (e,a)=>{if(e){console.error(e.code,e.message);process.exitCode=1}else{console.log(a)}})" registry.npmjs.org 成功した場合はアドレスの一覧、失敗した場合は符号と説明文が出ます。実際の値は環境によって異なります。 補助的な確認には次も使えます。 nslookup registry.npmjs.org nslookupとNode.jsのOS経由の名前解決は、同じ結果になるとは限りません。片方だけ成功する場合は、その違いも調査材料になります。Docker内で失敗しているならコンテナ内、CIで失敗しているなら該当ジョブで確認してください。 registryとスコープ別の設定を直す registryは、npmがパッケージを取得するサーバーの設定です。現在の設定を確認します。 npm config get registry @myorg/packageのように組織名付きのパッケージで失敗する場合は、スコープ別の設定も確認します。@myorgは実際のスコープに置き換えてください。 npm config get @myorg:registry npmの.npmrc公式文書には、スコープごとに別のregistryを指定する例があります。通常のregistryが正しくても、スコープ別の設定に古い社内ホストが残っていれば、そのパッケージだけ別の取得先を使います。 設定はプロジェクトの.npmrc、ユーザーの.npmrc、環境変数などから読み込まれます。どのファイルの設定か分からない場合は、次の出力で確認します。共有する際は、社内URLや認証情報を含んでいないか確認してください。 npm config list 公開のnpm registryを使うことが正しいプロジェクトで、プロジェクト設定に誤りがある場合は次のように修正できます。 ...

冒頭まとめ kubectl applyやkubectl getが、次のエラーで止まることがあります。 Error from server (NotFound): the server could not find the requested resource まず、接続先のクラスターが、指定した種類とバージョンのAPIを提供しているかを確認します。APIは、PodやDeploymentなどを作成・取得するための窓口です。マニフェストのapiVersionとkindを控え、現在の接続先とAPI一覧を調べてください。 kubectl config current-context kubectl api-versions kubectl api-resources --cached=false カスタムリソースなら、その種類を追加する定義であるCRD（CustomResourceDefinition）が必要です。CRDを先に適用して登録を待ち、その後にカスタムリソースを適用します。組み込みリソースなら、apiVersionの誤りや、クラスターの更新で提供されなくなった旧APIを確認します。 ただし、この文言だけでCRD不足と断定はできません。404は要求先が見つからなかった応答で、接続先や途中のプロキシが誤っている場合も調査対象になります。 3つのエラー文言の違い 似た状況で次の文言も出ますが、発生する処理は異なります。 文言 示していること the server could not find the requested resource 要求先から404相当の応答を受けた。要求したAPIのパスと応答元を確認する no matches for kind "MyApp" in version "myorg.example.com/v1" kubectl側で、指定したkindとAPIバージョンを対応するAPIへ変換できなかった the server doesn't have a resource type "myapps" kubectl側で、指定したリソース名に対応するAPIを見つけられなかった 最初の文言は、KubernetesのNewGenericServerResponse()がHTTP 404に対応して組み立てるメッセージです。要求した操作、リソースの種類、名前が分かる場合は、末尾に(get deployments.apps my-app)などが付きます。 すべての404がこの固定文言になるわけではありません。 client-goの応答処理は、Kubernetesの形式で返されたエラー情報を利用し、読み取れない応答には汎用的なエラーを作ります。そのため、固定文言だけで、リソースの種類がないのか、個別の名前がないのか、別のサーバーが応答しているのかを決めないでください。 残りの2つは、RESTMapperのエラー定義とkubectlの表示処理に由来します。RESTMapperは、種類やリソース名をAPIの宛先へ対応付ける仕組みです。対象オブジェクトの操作へ進む前に失敗しますが、対応付けに使うAPI一覧をサーバーから取得することがあります。接続を一度も試していないという意味ではありません。 接続先とAPI一覧を確認する 同じマニフェストでも、開発用クラスターにはCRDがあり、本番用にはない場合があります。最初に現在のcontext（接続先の設定）を確認します。 kubectl config current-context kubectl config get-contexts 接続先が正しければ、apiVersionとkindを照合します。たとえばapiVersion: apps/v1、kind: Deploymentなら、次を実行します。 ...

冒頭まとめ docker pullやdocker run、Dockerfileのビルドで次のように止まることがあります。 no matching manifest for linux/amd64 in the manifest list entries この場合、まず要求しているプラットフォームと、そのイメージのタグに用意されているプラットフォームを比べます。例のlinux/amd64は「Linux用、x86-64 CPU向け」という要求です。イメージの名前だけでなく、タグも含めて確認してください。 docker buildx imagetools inspect <image>:<tag> 表示されたPlatform:の一覧に要求したものがなければ、そのタグのまま同じプラットフォームを指定し直しても解決しません。対応するタグを選ぶか、利用可能な別のプラットフォームを指定します。自分で配布するイメージなら、そのプラットフォーム向けの版をビルドして公開します。Docker公式の確認コマンドに一覧の表示例があります。 no matching manifest forとは 複数の環境に対応したイメージのタグは、各環境向けのイメージを指す一覧（manifest listまたはOCI image index）を持ちます。Dockerは取得するときに、要求されたOS・CPUアーキテクチャに合う項目を選びます。Dockerのマルチプラットフォームの説明によると、ARM環境とx86-64環境では同じタグから異なる版が選ばれます。 no matching manifest for linux/amd64 in the manifest list entries no match for platform in manifest sha256:<digest>: not found 上は表示されることのある文言の例です。linux/amd64の部分やダイジェストは環境によって変わります。後者はcontainerdの実装にもある文言です。両者とも、対象のタグを参照したうえで、要求するプラットフォームに適合する版を選べなかった場合に調べるエラーです。Dockerやビルドの経路によって表示全体は異なり、二つの文言が連結される場合もあります。 たとえば公式Goイメージの報告では、golang:1.21.5をlinux/arm/v6向けにビルドしようとしてno match for platform in manifest: not foundが出ています。タグがあることと、必要な環境向けの版があることは別です。この報告だけで、現在の同じタグの対応状況までは判断できません。 タグの対応プラットフォームを確認する 失敗したコマンドのイメージ名とタグをそのまま使い、レジストリ上の一覧を調べます。FROMで止まった場合はDockerfileに書かれた基底イメージ、Composeの場合は該当サービスのimageを確認します。 docker buildx imagetools inspect registry.example.com/myapp:1.2 複数の版を持つ場合、出力のManifests:以下にPlatform: linux/amd64やPlatform: linux/arm64などが並びます。出力に要求した版があるかを見ます。タグによっては単一プラットフォームのmanifestを指すため、一覧ではなく単一のmanifestとして表示されます。unknown/unknownの項目は証明情報などの付随データの場合もあるので、それだけを見て実行環境の自動検出が失敗したと判断しないでください。imagetools inspectの出力例で形式を確認できます。 別のタグを候補にするときも、置き換える前にそのタグを同じコマンドで調べます。latestという名前だけでは、必要なCPU向けの版が存在する保証にはなりません。 要求しているプラットフォームを確認する エラーにlinux/amd64などが表示されていれば、まずその値を確認します。ローカルのDockerデーモンが報告するOSとアーキテクチャは次のように調べられます。リモートのDocker contextを使っている場合、表示されるのは接続先のデーモンです。 ...

冒頭まとめ PostgreSQLでSQLの実行やデータベースの復元を行ったとき、次のエラーが出ることがあります。 ERROR: role "app_user" does not exist app_userというロールを参照しましたが、接続先のPostgreSQLクラスタにその名前のロールがありません。GRANT ... TO app_user、ALTER TABLE ... OWNER TO app_user、SET ROLE app_user、ダンプの復元など、どの操作から発生したかによって直す場所は変わります。 まず、**エラー直前のSQL**と接続先を確認してください。接続できるロールで対象クラスタに入り、次のSQLでロールの存在を調べます。 SELECT rolname, rolcanlogin FROM pg_roles WHERE rolname = 'app_user'; 結果が0行で、必要なロールなら適切な権限を持つ利用者が作成します。別名のロールへ移行する設計なら、SQLや復元時の所有者指定を見直します。必要のないロールをエラーを消すためだけに作ると、意図しない所有者や権限を残すことがあります。 role does not existとは PostgreSQLのロールはクラスタ全体で共有されます。pg_rolesはロールの情報を参照できるビューで、パスワードを隠したpg_authidの内容を表示します。データベースに接続できているなら、公式のpg_rolesの説明に従い、このビューで対象名を確認できます。 ERROR: role "..." does not existは、すでに接続したセッションで、存在しないロール名をSQLが参照したときの一つの表示です。SQLSTATEは42704（undefined_object）です。PostgreSQL本体のget_role_oid()など、ロール名を解決する処理で発生します。 ただし、role "..." does not existという文字列だけで接続後のエラーと決めることはできません。接続時に存在しない利用者を指定した場合、認証方式などによってはFATAL: role "..." does not existと表示されます。先頭がERRORかFATALか、接続が成立したかを先に確認してください。 どのSQLがロールを参照したか確認する 同じエラー文でも、直前に実行したSQLによって原因が異なります。 エラーが出た操作 最初に確認するもの GRANT ... TO app_user、REVOKE ... FROM app_user 権限の対象として指定したロールと作成順序 ALTER TABLE ... OWNER TO app_user 移行先の所有者名 CREATE DATABASE ... OWNER app_user 作成先クラスタのロール SET ROLE app_user アプリケーションが切り替えようとしているロール pg_restore、psql -f ダンプ内の所有者、権限、ロール設定 まず、実行されたSQLに書かれた名前の大文字・小文字や引用符を確認します。PostgreSQLでは引用符を付けない識別子は小文字へ変換されます。たとえばapp_userと"App_User"は異なる名前です。識別子の公式仕様も参照してください。 ...

冒頭まとめ kubectl get podsなどを実行したとき、次のエラーが出ることがあります。 Unable to connect to the server: dial tcp: lookup api.example.com: no such host The connection to the server 127.0.0.1:6443 was refused - did you specify the right host or port? どちらもkubectlからKubernetes APIサーバーへ接続できていません。ただし、直す場所は後半の文言によって異なります。 後半の文言 最初に疑う場所 connection refused APIサーバーの停止、ホスト、ポート no such host DNS、VPN、kubeconfig内のホスト名 i/o timeout、TLS handshake timeout 経路、VPN、ファイアウォール、負荷 x509:、tls: CA証明書、接続先名、証明書の期限 no configuration has been provided kubeconfigの有無と読み込み元 最初に、kubectlが選んでいるcontextとAPIサーバーのURLを確認してください。 kubectl config current-context kubectl config view --minify kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}{"\n"}' 想定外のクラスターが表示された場合は、ネットワークを調べる前にkubeconfigの読み込み元を直します。 ...

冒頭まとめ terraform planは成功したのに、terraform applyの途中で次のエラーが出ることがあります。 Error: Provider produced inconsistent final plan When expanding the plan for aws_example.main to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .id: was known, but now unknown. This is a bug in the provider, which should be reported in the provider's own issue tracker. このエラーは、apply中に新しく確定した値を使って計画を更新したところ、providerが最初のplanと両立しない結果を返したことを示します。エラー本文にもあるとおり、基本的にはprovider側の不整合として扱います。 ただし、エラーに表示されたリソースが不具合の発生元とは限りません。そのリソースが参照している上流リソースの値がapply中に変わり、下流で不整合として検出される場合があります。 失敗後は同じapplyをすぐに繰り返さず、次の順番で確認してください。 terraform version terraform providers terraform plan applyの途中まで変更が反映されている可能性があります。取り直したplanを確認したうえで、providerの既知の不具合、直前のバージョン変更、外部からのインフラ変更を調べます。 Provider produced inconsistent final planとは Terraformのplanには、作成時にAPIから発行されるIDやIPアドレスなど、applyするまで確定しない値が含まれることがあります。planでは、このような値が(known after apply)と表示されます。 ...

冒頭まとめ AWS CLIやSDKの実行中に次のエラーが出た場合、使用中の一時的な認証情報が期限切れになっています。 ExpiredToken: The security token included in the request is expired 最初にaws configure listと環境変数を確認し、AWS CLIやSDKがどこから認証情報を取得しているかを特定します。AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENを手動で設定している場合は、3つをまとめて削除し、新しい認証情報を取得してください。 一時的な認証情報を毎回環境変数へコピーする運用では、期限切れが再発します。AWS CLIではロールを指定したプロファイル、EC2ではインスタンスプロファイル、ECSではタスクロールを使い、CLIやSDKに取得と更新を任せる方法へ変更します。 ExpiredTokenの意味 一時的な認証情報は、アクセスキーID、シークレットアクセスキー、セッショントークンの3つで構成され、有効期限があります。AWS IAMの公式文書によると、期限を過ぎた認証情報は再利用できません。 代表的な表示は次のとおりです。 An error occurred (ExpiredToken) when calling the ListBuckets operation: The provided token has expired. The security token included in the request is expired エラー名やHTTP状態コードはサービスによって異なります。STSの共通エラー文書ではExpiredTokenExceptionを403、Amazon S3のエラー文書ではExpiredTokenを400としています。そのため、HTTP状態コードだけで判断せず、ExpiredToken、ExpiredTokenException、説明文を確認してください。 IAMユーザーの長期アクセスキーには、ロールセッションのような有効期限はありません。ただし、無効化や削除は可能です。ExpiredTokenが出た場合は、セッショントークンを含む一時的な認証情報、または有効期限のあるIDプロバイダーのトークンを使っていないか確認します。 認証情報の取得元を確認する まず、AWS CLIが現在どこからアクセスキーなどを取得しているかを確認します。 aws configure list このコマンドは、プロファイル、アクセスキー、シークレットアクセスキー、リージョンの値と取得元を表示します。TypeやLocationがenvや環境変数名になっていれば、環境変数が使われています。セッショントークン自体はこの一覧に通常表示されないため、別に確認します。 LinuxとmacOSでは次のコマンドを使います。 env | grep '^AWS_' PowerShellでは次のコマンドで確認できます。 Get-ChildItem Env:AWS_* AWS_SESSION_TOKENがあれば、環境変数に一時的な認証情報が設定されています。ただし、表示されない場合でも、プロファイル、EC2のインスタンスプロファイル、ECSのタスクロールなどから一時的な認証情報を取得している可能性があります。 有効な認証情報へ更新した後は、呼び出し元も確認します。 aws sts get-caller-identity このコマンドで返るアカウントとARNが想定どおりかを確認してください。期限切れの状態ではこのコマンド自体も失敗するため、更新後の確認に使います。 環境変数の期限切れを直す aws sts assume-roleの結果を環境変数へ手動設定した場合、その値は期限が来ても自動更新されません。古い3要素をすべて削除してから、新しい認証情報を取得します。 ...

冒頭まとめ KubernetesでPodがPendingのままになり、kubectl describe podのEventsに次のような警告が出ることがあります。 Warning FailedScheduling default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had taints that the pod didn't tolerate. FailedSchedulingは、kube-schedulerがPodを配置できるノードを見つけられなかったことを示すイベントです。エラー名だけでは原因を判断できません。0/3 nodes are available:の後ろにある理由を、最後まで確認する必要があります。 最初に次のコマンドを実行してください。 kubectl describe pod <pod-name> -n <namespace> kubectl get events -n <namespace> \ --field-selector reason=FailedScheduling \ --sort-by=.metadata.creationTimestamp 理由がInsufficient cpuならCPUの要求量、didn't match Pod's node affinity/selectorならラベルと配置条件、had taints that the pod didn't tolerateならTaintとTolerationを調べます。複数の理由が並んでいる場合は、1つ直しただけでは配置できないことがあります。 FailedSchedulingとは FailedSchedulingはPodの状態ではなく、スケジューラーが記録するイベントのReasonです。Podの状態はPendingのままで、PodScheduled条件はFalseになります。 kube-schedulerは、まだ配置先が決まっていないPodを監視し、次のような条件で候補ノードを絞り込みます。 Podが要求するCPUやメモリを確保できるか nodeSelectorやNode Affinityに一致するか ノードのTaintをPodが許容しているか 使用するボリュームの配置条件を満たすか すべてのノードがいずれかの条件で候補から外れると、配置に失敗してFailedSchedulingが記録されます。この仕組みはKubernetes Schedulerの公式ドキュメントで確認できます。 同じPendingでも、すでに配置先ノードが決まり、イメージ取得やコンテナ作成を待っている場合はスケジューラーの問題ではありません。FailedSchedulingが出ている場合は、Podを起動する処理より前の「配置先を決める段階」で止まっています。 0/N nodes are availableの読み方 イベントは、次の形式で表示されます。 ...

冒頭まとめ terraform planで次のエラーが出る場合、countに渡した値をリソース数として確定できません。 Error: Invalid count argument この見出しだけでは原因は分かりません。直後の説明文を確認してください。主な原因は、適用後でないと決まらない値、null、一時値、整数に変換できない値、負数です。 最も多いのは、別のリソースを作成した後で決まる属性からcountを計算している場合です。countは計画時にインスタンス数を確定する必要があるため、入力変数やローカル値など、計画時に分かる値から計算する形へ変更します。 Invalid count argumentの意味 countは、同じリソースやモジュールを指定した数だけ作るためのメタ引数です。たとえばcount = 3なら、example[0]からexample[2]までの3インスタンスが計画されます。 Terraform公式のcount文書によると、countが受け付けるのは整数です。さらに、一般的な引数と違い、Terraformが遠隔のリソースを操作する前に値が確定していなければなりません。 現在のTerraform実装では、Invalid count argumentの見出しが複数の検査で共通して使われています。説明文には次のような違いがあります。 The "count" value depends on resource attributes that cannot be determined until apply... The given "count" value is derived from an ephemeral value... The given "count" argument value is null. An integer is required. The given "count" argument value is unsuitable: <変換時のエラー>. The given "count" argument value is unsuitable: must be greater than or equal to zero. 一時値については処理経路の違いにより、ほぼ同じ内容の説明文が2種類あります。どちらも、計画と適用の間で保存できない値をcountに使ったことを示します。正確な文面はTerraformの版によって変わる可能性があるため、見出しではなく説明の内容で判断してください。 ...