Posts

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ AWSのエラーを検索して1件ずつ直しているのに、翌日は別のサービスで同じような壁に当たる。この繰り返しから抜けるには、覚える順序を変える必要があります。 AWSのエラーの多くは、4つの境界のどこかで起きています。誰として呼んでいるかという境界、何を許されているかという境界、自分の権限とサービスへ渡した権限の境界、そしてネットワークの到達性の境界です。エラー文はこの境界のどれで止まったかを示していますが、境界の存在を知らないと文言が読めません。 DockerやTerraformとの違いは、AWSがサービスの集まりであり、覚えるべきサービスの数に終わりがないことです。だからサービスを1つずつ潰す学び方は成立しません。代わりに、どのサービスでも共通して働く仕組みを先に押さえます。認証、認可、リージョン、ネットワーク、制限。この5つはS3でもLambdaでもRDSでも同じ形で現れます。 学ぶ順序は、認証情報とリージョン、IAMの評価順序、サービスへ渡す権限、ネットワークの到達性、制限と再試行、トラブルシューティングの6段階です。各段階には「次へ進む目安」を置きました。飛ばした段階は、後の段階のエラーとして別の顔で現れます。 個別に直すだけでは理解しにくい理由 検索で見つかる対処は、多くの場合その環境で有効だった手順です。なぜ有効だったかは書かれていないことがあります。 たとえば、アクセスが拒否されたときに管理者相当のポリシーを付けたら通った、という手順があります。確かにエラーは消えます。しかし何が足りなかったのかは分からないままです。次に同じ構成を作るとき、同じ広い権限を付けることになります。 同じことがネットワークでも起きます。繋がらないのでセキュリティグループを全開放したら通った、という手順は、どこで止まっていたのかを教えてくれません。セキュリティグループが原因だったのか、ルートテーブルが原因だったのかも区別できていません。 エラー文も同じです。AWSの拒否は、認証に失敗したのか、認証は通ったが許可がないのか、そもそも別のリージョンを見ているのかを示しています。この区別は、次に説明する全体像を知っていれば読み取れます。 最初に理解するべきAWSの全体像 先に、すべてのAWS操作が通る道筋を押さえます。ここを飛ばすと、後のすべての段階で判断がぶれます。 どのサービスへの操作も、同じ形をしています。まず、どの認証情報を使うかが決まります。次に、その認証情報が誰を表すのかが確定します。そのうえで、その相手にその操作が許されているかが判定されます。許されていれば、指定されたリージョンのそのサービスへ要求が届きます。 この道筋のうち、最初の2つと3つ目は別物です。認証情報が正しくても許可がなければ拒否されます。逆に、許可を持つ役割があっても、使っている認証情報が別人のものなら意味がありません。エラーを見るときは、この2つを分けて考えてください。 リージョンも独立した境界です。多くのサービスはリージョンごとに分かれており、東京リージョンで作ったものは大阪リージョンからは見えません。「作ったはずのものが一覧に出てこない」という症状は、リージョンの取り違えであることがよくあります。 まずは手元の環境が誰として動いているかを確認してください。 aws sts get-caller-identity aws configure list get-caller-identity は、いま使われている認証情報がどのアカウントの誰を表すかを返します。ここが想定と違えば、この先の調査はすべて無駄になります。 学習ステップ1：認証情報とリージョン 何を理解する段階か：認証情報がどこから読まれるか、そしてその優先順位です。 なぜエラー解決に必要か：手元では通るのに継続的インテグレーションでは拒否される、という症状の大半はここです。環境ごとに使われている認証情報が違います。 最低限覚える概念：公式ドキュメントによれば、AWS CLIはシステムやユーザーの環境変数、ローカルの設定ファイル、コマンドラインのパラメーターなど複数の場所にある認証情報と設定を使い、場所によって優先順位があります。優先順位は上から順に、コマンドラインオプション、環境変数、CLIの認証情報ファイル、CLIの設定ファイル、コンテナの認証情報、そしてEC2インスタンスプロファイルの認証情報です（Configuration settings and precedence）。 この順序が重要です。環境変数に古いキーが残っていると、設定ファイルを正しく直しても環境変数が優先されます。「設定を直したのに変わらない」という状況の典型です。 同じページには、認証情報ファイルと設定ファイルの両方に同じ名前のプロファイルがある場合、認証情報ファイルの値が優先されるという記述もあります。 実際に試すコマンド： # いま使われている認証情報の持ち主を確認する aws sts get-caller-identity # 各設定値がどこから来ているかを確認する（type 列に出所が出る） aws configure list # 環境変数に値が残っていないかを確認する env | grep -i "^AWS_" # プロファイルを明示して実行する aws sts get-caller-identity --profile <プロファイル名> # 現在のリージョンを確認する aws configure get region aws configure list の出力は、値そのものではなく出所を示します。env と出ていれば環境変数、shared-credentials-file と出ていればファイルから読まれています。ここを見れば、どこを直せばよいかが決まります。 ...

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ Dockerのエラーを検索して1件ずつ直しているのに、次の日には別のエラーで止まる。この繰り返しから抜けるには、覚える順序を変える必要があります。 Dockerのエラーの多くは、4つの境界のどこかで起きています。ホストとコンテナの境界、イメージとコンテナの境界、コンテナ間の境界、そして書き込み可能レイヤーと永続領域の境界です。エラー文はこの境界のどれで止まったかを示していますが、境界の存在を知らないと文言が読めません。 したがって学ぶ順序は、コマンドの数ではなく境界の数で決まります。この記事では、コンテナとイメージ、Dockerfileとビルド、ポートとネットワーク、ボリューム、Compose、ログとトラブルシューティングの6段階に分けて示します。 各段階には「次へ進む目安」を置きました。目安を満たさないまま先へ進むと、後の段階のエラーが前の段階の理解不足として現れます。急がずに順に進めてください。 エラーを個別に直すだけでは理解しにくい理由 検索で見つかる対処は、多くの場合その環境で有効だった手順です。なぜ有効だったかは書かれていないことがあります。 たとえば docker compose down -v を実行すれば起動時のエラーが消える、という手順があったとします。これはボリュームを削除して初期化し直す操作なので、確かにエラーは消えます。しかし同時にデータも消えます。ボリュームが何であるかを知らないまま実行すると、次は「データが消えた」という別の問題に変わります。 同じことがポートの公開でも起きます。-p 8080:80 を -p 80:80 に変えたら繋がった、という手順は、どちらの数字がホスト側でどちらがコンテナ側かを知らなければ再現できません。 エラー文そのものも同じです。Dockerのエラーは、どの部品が返したのかを示しています。CLIが返したのか、デーモンが返したのか、コンテナの中のプロセスが返したのかで、直す場所が変わります。この区別は、次に説明する全体像を知っていれば読み取れます。 最初に理解するべきDockerの全体像 先に部品の関係を押さえます。ここを飛ばすと、後のすべての段階で判断がぶれます。 Dockerはクライアントとサーバーに分かれています。公式ドキュメントによれば、docker コマンドがDockerクライアントで、利用者が最もよく使う操作の入口です。実際の作業はDockerデーモン（dockerd）が行い、イメージ、コンテナ、ネットワーク、ボリュームといったオブジェクトを管理します。両者はREST APIを使い、UNIXソケットまたはネットワークインターフェース経由で通信します。クライアントとデーモンは同じマシンで動かすことも、別のマシンに置くこともできます（Docker overview）。 この構造から、エラーの読み分けが1つ決まります。Cannot connect to the Docker daemon のような文言は、クライアントがデーモンへ届いていないという意味です。コンテナの設定を見直しても変わりません。逆に、コンテナの中のアプリケーションが出したエラーは、Dockerの設定ではなくアプリケーションの問題です。 もう1つの軸がイメージとコンテナの関係です。イメージは読み取り専用の層の集まりで、コンテナはその上に書き込み可能な層を1つ載せて動かしたものです。公式ドキュメントは、コンテナの中で作られたファイルは既定でこの書き込み可能なコンテナレイヤーに保存され、そのレイヤーはコンテナごとに固有だと説明しています（Data persistence overview）。 この2つの軸、つまりクライアントとデーモンの関係、イメージとコンテナの関係が、以降のすべての段階の土台になります。 まずは手元の環境が動いているかを確認してください。 docker version 出力はクライアント側とサーバー側に分かれます。サーバー側が表示されなければ、デーモンへ届いていません。この時点で次へ進んでも、以降のコマンドはすべて失敗します。 学習ステップ1：コンテナとイメージ 何を理解する段階か：イメージが設計図、コンテナがそれを動かした実体であること、そして両者が別々に管理されていることです。 なぜエラー解決に必要か：「イメージを更新したのに反映されない」という状況は、古いコンテナが動き続けているだけであることが多くあります。イメージとコンテナが別物だと分かっていないと、この判断ができません。 最低限覚える概念：イメージ、コンテナ、コンテナの状態（作成済み、実行中、停止）、そして名前とIDの関係です。 実際に試すコマンド： # 手元にあるイメージを一覧する docker images # イメージからコンテナを作って起動する docker run -d --name web nginx # 実行中のコンテナを一覧する docker ps # 停止中を含めて一覧する（-a を付けないと停止中は見えない） docker ps -a # コンテナの詳細な設定を確認する docker inspect web # 実行中のコンテナの中でコマンドを実行する docker exec -it web sh docker ps と docker ps -a の差は重要です。既定では実行中のものしか表示されません。停止したコンテナは見えないまま残り続け、名前を占有します。 ...

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ Google Cloudのエラーを検索して1件ずつ直しているのに、翌日は別のサービスで同じような壁に当たる。この繰り返しから抜けるには、覚える順序を変える必要があります。 Google Cloudのエラーの多くは、4つの境界のどこかで起きています。誰として呼んでいるかという境界、そのAPIがプロジェクトで有効になっているかという境界、何を許されているかという境界、そしてネットワークの到達性の境界です。エラー文はこの境界のどれで止まったかを示していますが、境界の存在を知らないと文言が読めません。 他のクラウドと比べたときの最大の違いは、2つ目です。Google Cloudでは、権限があってもAPIが有効でなければ呼べません。公式ドキュメントは、ほとんどのGoogle APIを使う前にGoogle Cloudプロジェクトで有効化する必要があると明記しています（Service Usage overview）。この段階を知らないと、権限の設定を延々と見直すことになります。 学ぶ順序は、認証情報とプロジェクト、APIの有効化、IAMの評価順序、サービスアカウント、ネットワークの到達性、トラブルシューティングの6段階です。各段階には「次へ進む目安」を置きました。飛ばした段階は、後の段階のエラーとして別の顔で現れます。 個別に直すだけでは理解しにくい理由 検索で見つかる対処は、多くの場合その環境で有効だった手順です。なぜ有効だったかは書かれていないことがあります。 たとえば、アクセスが拒否されたときに編集者や所有者の役割を付けたら通った、という手順があります。確かにエラーは消えます。しかし何が足りなかったのかは分からないままです。次に同じ構成を作るとき、同じ広い役割を付けることになります。 同じことがAPIの有効化でも起きます。gcloud services enable を実行したら動いた、という手順は、それが権限の問題ではなく有効化の問題だったことを教えてくれません。区別できないままだと、次は逆の場面で有効化を試して時間を使います。 エラー文も同じです。Google Cloudの拒否は、認証に失敗したのか、APIが無効なのか、権限が無いのかを示しています。この区別は、次に説明する全体像を知っていれば読み取れます。 最初に理解するべきGoogle Cloudの全体像 先に、すべての操作が通る道筋を押さえます。ここを飛ばすと、後のすべての段階で判断がぶれます。 どのサービスへの操作も、同じ関門を順に通ります。第一に、どの認証情報を使うかが決まります。第二に、対象のプロジェクトが決まります。第三に、そのプロジェクトでそのAPIが有効かどうかが確認されます。第四に、その主体にその操作が許されているかが判定されます。 この4つは独立しています。認証情報が正しくてもAPIが無効なら止まります。APIが有効でも権限が無ければ止まります。順番に確認しないと、直したはずのものが直っていない状態が続きます。 もう1つ、資源の階層が重要です。組織、フォルダ、プロジェクト、そして個々の資源という階層があり、上位に設定した内容は下位へ引き継がれます。したがって、プロジェクトの設定だけを見ても答えが出ないことがあります。 まずは手元の環境が誰として、どのプロジェクトに対して動いているかを確認してください。 gcloud auth list gcloud config list gcloud auth list は有効なアカウントを、gcloud config list は対象プロジェクトとリージョンを示します。ここが想定と違えば、この先の調査はすべて無駄になります。 学習ステップ1：認証情報とプロジェクト 何を理解する段階か：認証情報がどこから読まれるか、そして gcloud と自分のコードで使われる認証情報が別であることです。 なぜエラー解決に必要か：gcloud では通るのにコードでは拒否される、という症状の大半はここです。 最低限覚える概念：アプリケーションのデフォルト認証情報（ADC）は、認証ライブラリが実行環境に応じて自動的に認証情報を探す仕組みです。公式ドキュメントによれば、ADCは次の場所を順に探します。GOOGLE_APPLICATION_CREDENTIALS 環境変数、gcloud auth application-default login コマンドで作られた認証情報ファイル、そしてメタデータサーバーが返す接続済みのサービスアカウントです（How Application Default Credentials works）。 ここに重要な注意があります。公式ドキュメントは、gcloud CLI自体はGoogle Cloudの資源へアクセスするためにADCを使わないと明記しています（Set up Application Default Credentials）。つまり gcloud auth login で入れた認証情報と、ライブラリが使う認証情報は別管理です。 この2つを混同すると、手元では gcloud が動くのにコードだけ認証エラーになる、という状況が生まれます。コードを動かすなら gcloud auth application-default login が必要です。 ...

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ Kubernetesのエラーを検索して1件ずつ直しているのに、翌日は別のエラーで止まる。この繰り返しから抜けるには、覚える順序を変える必要があります。 Kubernetesのエラーの多くは、4つの境界のどこかで起きています。宣言した状態と実際の状態の境界、コントロールプレーンとノードの境界、Podの内と外の境界、そしてPodの寿命とデータの寿命の境界です。エラー文やイベントはこの境界のどれで止まったかを示していますが、境界の存在を知らないと文言が読めません。 Dockerとの最大の違いはここにあります。Dockerでは実行した命令がそのまま結果になりますが、Kubernetesでは「こうあってほしい」という宣言を出し、それを実現しようとする過程が延々と続きます。したがってエラーは、失敗した瞬間ではなく、実現できないまま繰り返している状態として現れます。 学ぶ順序は、Podとコンテナ、Deploymentと宣言、Serviceとネットワーク、設定とデータ、スケジューリングとリソース、ログとトラブルシューティングの6段階です。各段階には「次へ進む目安」を置きました。飛ばした段階は、後の段階のエラーとして別の顔で現れます。 個別に直すだけでは理解しにくい理由 検索で見つかる対処は、多くの場合その環境で有効だった手順です。なぜ有効だったかは書かれていないことがあります。 たとえば、Podが起動しないときに kubectl delete pod を実行したら直った、という手順があります。Deploymentの管理下にあるPodは削除すると作り直されるので、一時的な不具合であれば確かに解消します。しかし原因がマニフェストの側にあれば、作り直されたPodも同じ理由で止まります。Podが誰に管理されているかを知らないと、この区別ができません。 同じことがネットワークでも起きます。Serviceの port と targetPort を同じ値に揃えたら繋がった、という手順は、どちらがService側でどちらがコンテナ側かを知らなければ再現できません。 エラー文とイベントも同じです。Kubernetesの表示は、どの部品が判断したのかを示しています。スケジューラが置き場所を決められないのか、kubeletがイメージを取得できないのか、コンテナの中のプロセスが落ちているのかで、直す場所が変わります。この区別は、次に説明する全体像を知っていれば読み取れます。 最初に理解するべきKubernetesの全体像 先に部品の関係を押さえます。ここを飛ばすと、後のすべての段階で判断がぶれます。 公式ドキュメントによれば、Kubernetesクラスターはコントロールプレーンと1つ以上のワーカーノードで構成されます。コントロールプレーン側には、KubernetesのHTTP APIを公開する中核サーバーである kube-apiserver、APIサーバーの全データを保持するキーバリューストアの etcd、まだノードに割り当てられていないPodを探して適切なノードへ割り当てる kube-scheduler、APIの振る舞いを実装するコントローラーを動かす kube-controller-manager があります。ノード側には、Podとそのコンテナが動いていることを保証する kubelet、Serviceを実装するネットワーク規則を維持する kube-proxy、コンテナの実行を担うコンテナランタイムがあります（Cluster Architecture）。 この構造から、エラーの読み分けが決まります。kubectl はAPIサーバーへ要求を送るだけの道具です。マニフェストを適用した時点で成功と表示されても、それは「宣言が受け付けられた」という意味であり、動き出したという意味ではありません。実際に動くかどうかは、その後にスケジューラとkubeletが決めます。 したがってKubernetesの調査は、常に2段構えになります。宣言は正しく登録されたか。そしてその宣言を実現しようとした過程のどこで止まったか。前者は kubectl get で、後者は kubectl describe のイベント欄で確認します。 まずは手元の環境が動いているかを確認してください。 kubectl cluster-info kubectl get nodes ノードが Ready でなければ、この先のPodはどれも起動しません。この時点で次へ進んでも、以降のコマンドはすべて同じ理由で止まります。 学習ステップ1：Podとコンテナ 何を理解する段階か：Podが何の単位なのか、そしてコンテナとどう違うのかです。 なぜエラー解決に必要か：Kubernetesのエラーの大半はPod単位で現れます。Podの状態欄とコンテナの状態欄が別々にあることを知らないと、どちらの情報を読んでいるのか分からなくなります。 最低限覚える概念：公式ドキュメントによれば、PodはKubernetesで作成・管理できる最小のデプロイ単位で、1つ以上のコンテナのグループです。ストレージとネットワークの資源を共有し、コンテナをどう動かすかの仕様を持ちます。Podの中身は常に同じ場所に配置され、同時にスケジュールされ、共有された文脈で動きます（Pods）。 つまりPodは、複数のコンテナをまとめて1台の論理的なホストのように扱う入れ物です。同じPodの中のコンテナは同じネットワーク名前空間を共有するため、互いに localhost で通信できます。別のPodには届きません。 実際に試すコマンド： # Pod を一覧する kubectl get pods # 状態とノードと再起動回数まで表示する kubectl get pods -o wide # Pod の詳細とイベントを確認する（最も重要） kubectl describe pod <Pod名> # Pod 内のコンテナでコマンドを実行する kubectl exec -it <Pod名> -- sh # 複数コンテナがある場合はコンテナを指定する kubectl exec -it <Pod名> -c <コンテナ名> -- sh kubectl describe の出力は上半分が宣言された内容、下半分の Events が実現しようとした過程です。エラーの理由はほぼ常に下半分にあります。 ...

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ Terraformのエラーを検索して1件ずつ直しているのに、翌日は別のエラーで止まる。この繰り返しから抜けるには、覚える順序を変える必要があります。 Terraformのエラーの多くは、4つの境界のどこかで起きています。設定ファイルと状態ファイルの境界、状態ファイルと実際のインフラの境界、計画時に確定している値と適用後に決まる値の境界、そして自分の作業と他人の作業の境界です。エラー文はこの境界のどれで止まったかを示していますが、境界の存在を知らないと文言が読めません。 DockerやKubernetesとの最大の違いは、Terraformが3つの世界を突き合わせている点にあります。あなたが書いた設定、Terraformが記録している状態、そして実際に存在するインフラです。この3つがずれたときにエラーになります。どれとどれがずれているのかを特定できれば、直す場所は自動的に決まります。 学ぶ順序は、初期化とプロバイダー、状態ファイル、計画と適用、参照と依存関係、変数とモジュール、トラブルシューティングの6段階です。各段階には「次へ進む目安」を置きました。飛ばした段階は、後の段階のエラーとして別の顔で現れます。 個別に直すだけでは理解しにくい理由 検索で見つかる対処は、多くの場合その環境で有効だった手順です。なぜ有効だったかは書かれていないことがあります。 たとえば、エラーが出たときに terraform state rm を実行したら通った、という手順があります。これはTerraformの管理下から対象を外す操作なので、確かにエラーは消えます。しかし実際のインフラは残ったままです。次に terraform apply を実行すると、Terraformはその資源が存在しないものとして作りに行き、名前の重複で失敗します。状態ファイルが何であるかを知らないまま実行すると、症状が別の形に移るだけになります。 同じことが -lock=false でも起きます。ロックを取得できないエラーを消すために付けるという手順は広く共有されていますが、これはロックの仕組みそのものを止める操作です。 エラー文も同じです。Terraformのエラーは、設定の文法が誤っているのか、値が計画時に決まらないのか、状態と実物がずれているのかを示しています。この区別は、次に説明する全体像を知っていれば読み取れます。 最初に理解するべきTerraformの全体像 先に3つの世界の関係を押さえます。ここを飛ばすと、後のすべての段階で判断がぶれます。 公式ドキュメントによれば、Terraformは管理下のインフラと設定について状態を保存しなければなりません。この状態は、実世界の資源を設定へ対応付けること、メタデータを追跡すること、大規模なインフラでの性能を改善することに使われます。既定では terraform.tfstate という名前のローカルファイルに保存されます。そしてTerraformは、どの変更を加えるかを決めるために状態を使い、あらゆる操作の前に更新処理を行って状態を実際のインフラへ合わせます（State）。 つまり流れはこうです。あなたが設定を書く。Terraformが状態を読み、実物と突き合わせて更新する。設定と状態を比較して差分を出す。その差分を適用する。 terraform plan の説明も同じ構造です。公式ドキュメントによれば、計画の作成時にTerraformは、既存の遠隔オブジェクトの現在の状態を読んで状態が最新であることを確認し、現在の設定と以前の状態を比較して差異を記録し、適用すれば遠隔オブジェクトが設定と一致するようになる変更操作の集合を提案します（terraform plan）。 この3つの世界を分けて考えられるようになると、エラーの読み方が変わります。設定の書き間違いなら設定を直す。状態と実物がずれているなら状態を合わせる。実物が想定と違うなら実物を確認する。混ぜると迷います。 まずは手元の環境を確認してください。 terraform version terraform providers 学習ステップ1：初期化とプロバイダー 何を理解する段階か：Terraform本体が何もしないこと、実際の操作はプロバイダーが行うことです。 なぜエラー解決に必要か：エラー文の多くはプロバイダーが返しています。Terraform本体の問題とプロバイダーの問題を分けられないと、調べる先を間違えます。 最低限覚える概念：公式ドキュメントによれば、terraform init はTerraformの設定ファイルを含む作業ディレクトリを初期化するコマンドで、新しい設定を書いた後、あるいはバージョン管理から既存の設定を複製した後に最初に実行すべきものです。何度実行しても安全で、既存の設定や状態を削除することはありません。 ここで押さえるべきは、プロバイダーがバージョンを持つことです。同じ設定でも、プロバイダーの版が違えば挙動が変わります。ロックファイルが版を固定するのはこのためです。 実際に試すコマンド： # 作業ディレクトリを初期化する（プロバイダーの取得と設定の準備） terraform init # 使われているプロバイダーと版を確認する terraform providers # プロバイダーを更新する（ロックファイルの内容が変わる） terraform init -upgrade # 設定の文法と内部整合を検査する（遠隔操作を伴わない） terraform validate terraform validate は遠隔への問い合わせをしません。文法の誤りや、存在しない引数名を書いた場合は、ここで先に見つかります。計画を走らせる前に通しておくと切り分けが速くなります。 次の段階へ進む目安：エラー文を見て、Terraform本体が出したものかプロバイダーが出したものかを区別できることです。 関連して発生しやすいエラー：Unsupported argument は、その位置に存在しない引数名を書いた場合です。プロバイダーの版を上げた後に出ることがあり、その場合は該当の版の資料を確認します。 ...

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ ConoHa VPS で Docker を動かすとき、通信を止めたり通したりする設定は2か所にあります。ひとつは OS の中にある ufw、もうひとつは VPS の外側にあるセキュリティグループです。 ここで噛み合わなくなる理由が1つあります。Docker が -p で公開したポート宛の通信は、ufw が使う規則を迂回します。Docker の公式ドキュメントは、Docker と ufw が互いに相容れない使い方でファイアウォールの規則を使うと明記しており、公開されたコンテナへの通信は nat テーブルで転送されるため、ufw が使う INPUT と OUTPUT のチェーンに到達する前に迂回する、と説明しています（Packet filtering and firewalls）。 この性質から2つのことが言えます。第一に、ufw allow だけでは Docker の公開ポートを制御できません。第二に、ufw deny で拒否しても、Docker の公開ポートを塞いだことにはなりません。 したがって、ufw を変更したのに外部から接続できない場合は、ConoHa のセキュリティグループ側を確認する必要があります。逆に、ufw で塞いだつもりのポートについては、ufw の設定を根拠に安全だと判断できません。 症状の概要 現れ方は2通りあります。 ひとつは、開けたつもりで繋がらない状態です。ufw allow 8080 を実行し、ufw status の一覧にも出ているのに、外部のブラウザや curl から接続できません。 もうひとつは、塞いだつもりで開いている状態です。ufw deny 8080 を設定しても、docker run -p 8080:80 で公開したコンテナには通信が届きうる、という状態です。 どちらも、ufw の表示と実際の通信経路がずれていることから生じます。ufw の一覧はあくまで ufw が管理している規則を示すもので、Docker が別に作る規則は含まれません。 前提として、ConoHa の Docker テンプレートの仕様を押さえておきます。公式ドキュメントによれば、OS は Ubuntu 24.04、Docker CE は 29.2.1 で、OS 内のファイアウォールは既定で22番ポート（SSH）のみ許可となっています。また Minimum RAM は 1024 MB と明記されています（Docker｜ConoHaドキュメントサイト）。512 MB のプランはこの最小要件を下回ります。 ...

結論 npm error code EAI_AGAIN は、名前を引く処理が一時的に失敗したという意味です。syscall の行には getaddrinfo が入ります。宛先のサーバーへ接続する前の段階で止まっており、レジストリの応答内容は関係ありません。 注意すべき点があります。npm はこのコードに専用の説明を持っていません。実装のコードごとの分岐には ENOTFOUND や EAI_FAIL はありますが、EAI_AGAIN は含まれておらず既定の扱いになります。したがって、ECONNRESET のときに出る「中継設定を確認してください」という案内も表示されません。表示されるのは、失敗した要求の内容を示す1文だけです。 切り分けの材料はエラー文の末尾にあります。getaddrinfo EAI_AGAIN の後ろに、引こうとした名前が入ります。ここがレジストリの名前なのか、中継先の名前なのかで、疑う場所が変わります。 最初に確認すること まず、失敗している名前を特定します。 npm install 2>&1 | grep -o "EAI_AGAIN [^ ]*" 次に、レジストリへ届くかを npm 自身の手段で確かめます。 npm ping このコマンドは現在の向き先へ疎通を試み、往復にかかった時間を表示します。ここで同じコードが返れば、原因は取得処理ではなく経路にあります。成功したり失敗したりする場合は、一時的な不調です。 名前を引く側の設定も確認してください。 cat /etc/resolv.conf npm config get registry npm config get proxy 原因別の確認方法と解決策 原因1：コンテナから名前を引く先へ届いていない コンテナの中でのみ失敗する場合です。実行環境が参照している宛先が、そのコンテナからは到達できません。 確認方法は、コンテナの内側から見ることです。 docker compose exec app sh -c 'cat /etc/resolv.conf' 記載されている宛先が、コンテナの外側でしか使えないものになっていることがあります。その場合、外側では成功して内側でだけ失敗します。 対処は、届く宛先を指定し直すことです。 services: app: dns: - 1.1.1.1 組織のネットワークでは、内部の宛先を指定する必要がある場合があります。管理者の指定に従ってください。 原因2：中継先を経由せず自分で名前を引いている 社内の回線で、中継の設定は入っているのに失敗する場合です。エラー文の末尾に出ている名前が、中継先ではなく接続先になっていれば、中継を経由していません。 確認方法は設定値と失敗名の突き合わせです。 npm config get proxy npm config get https-proxy npm config get noproxy 除外の一覧に接続先が含まれていると、その宛先だけ中継を通しません。結果として自分で名前を引こうとして失敗します。 ...

結論 npm error code ECONNRESET は、接続が相手側から切られたという意味です。npm はこのコードを他のネットワーク系と同じ分岐で扱うため、固有の説明は出ません。表示されるのは「ネットワーク接続に関する問題である」「多くの場合は中継の設定かネットワーク設定に問題がある」という2文と、中継設定の確認を促す1文だけです。 つまり文言からは原因を絞れません。切り分けの材料は3つあります。どの回線で起きるか、失敗する対象が毎回同じか変わるか、そして失敗するまでの時間です。 npm は取得に失敗した場合、既定で2回まで再試行します。待ち時間は10秒から始まり、上限は1分です。これを踏まえると、実行してすぐ落ちる場合と、数十秒かけて落ちる場合では見るべき場所が違います。 最初に確認すること まず、経路の設定を並べて確認します。 npm config get proxy npm config get https-proxy npm config get registry npm config get maxsockets proxy と https-proxy が null なのに社内の回線から実行している場合、原因1に当たります。環境変数側だけに設定されていることもあるため、そちらも見てください。 printenv | grep -i proxy 次に、失敗する対象が毎回同じかを確かめます。 npm install --loglevel verbose 2>&1 | tail -40 対象が実行ごとに変わるなら、特定のパッケージではなく接続の総量が問題です。同じ対象で止まるなら、その向き先が届いていません。 原因別の確認方法と解決策 原因1：中継の設定が npm に渡っていない 社内の回線からのみ失敗する場合です。npm の説明文も、まずこの可能性を挙げます。 確認方法は設定値の突き合わせです。公式の説明によれば、HTTP_PROXY や http_proxy の環境変数が設定されていれば、その内容が利用されます。npm 側の設定と環境変数のどちらか一方だけに値が入っていると、経路が定まりません。 対処は、組織から指定されている中継先へ揃えることです。 npm config set proxy http://proxy.example.com:8080 npm config set https-proxy http://proxy.example.com:8080 中継先を通さない宛先がある場合は、除外する一覧も設定してください。 ...

結論 npm error code ENOENT は、何かが見つからなかったという意味です。npm が加える説明も2文しかありません。「npm がファイルを見つけられないことに関係している」と述べ、file の値がある場合だけ「そのファイルが存在するか確認してください」と続きます。 したがって、原因を絞る材料は説明文ではなく、npm が併記する診断用の項目にあります。実装では code、syscall、file、path、dest、errno の6つのうち、値が入っているものだけを並べて出力します。このうち syscall が何をしようとして失敗したか、path がどこで失敗したかを示します。 読み方は単純です。syscall が open で path が package.json で終わっていれば、そのディレクトリにプロジェクトの定義が無いという意味になります。syscall が spawn git であれば、ファイルではなく外部コマンドが見つかっていません。path が node_modules の下を指していれば、導入済みのはずの中身が欠けています。 この2項目を見ないまま npm install を繰り返しても状況は変わりません。まず対象を特定してください。 エラーが発生する処理段階 npm の処理は段階に分かれており、ENOENT はどの段階でも起こります。ただし失敗した対象を見れば段階は特定できます。 第一段階はプロジェクトの読み取りです。npm はカレントディレクトリから package.json を探します。ここで見つからなければ、依存の解決にも取得にも進みません。 第二段階は依存の解決です。レジストリからの取得だけであれば外部コマンドは不要ですが、git の場所を指定した依存が含まれる場合、npm は git を起動します。この起動に失敗すると syscall が spawn git になります。 第三段階は取得と展開で、node_modules の下に書き込みます。前回の実行が途中で終わっていると、この段階の読み取りで欠けた対象に当たります。 第四段階は導入後のスクリプト実行です。ここで外部コマンドが見つからない場合も、同じ形の失敗になります。 段階が違えば path の指す場所も変わります。逆に言えば、path を見れば段階が分かります。 最初に確認すること まず、出力の診断用の行だけを抜き出します。 npm install 2>&1 | grep -E "npm error (code|syscall|path|file|dest|errno)" 出力はこの形になります。 ...

結論 npm error code ENOTEMPTY は、移動しようとした先が空でないディレクトリだったという意味です。npm はこのコードに専用の説明を持っておらず、既定の扱いになるため、画面に出るのは OS が返した1文だけです。 ここで押さえるべき点があります。npm は導入の過程で、置き換える対象を一度別名へ退避します。この移動が ENOTEMPTY で失敗した場合、実装は例外を握りつぶし、退避先を中身ごと削除してから移動をやり直します。つまり、単に古い退避先が残っていただけなら表には出ません。 したがって画面に出た時点で、それは2回目の失敗です。退避先を削除できなかったか、削除した直後に誰かが作り直したかのどちらかに絞れます。前者はファイルシステムの制約、後者は同時に動いている別のプロセスです。 読む場所は path と dest の2行です。path が退避される元、dest が退避先で、後者はドットで始まる名前になります。この名前は元の経路から機械的に決まるため、実行のたびに変わりません。 エラーが発生する処理段階 ENOTEMPTY は取得の段階では出ません。依存の解決も取得も終わり、実際に node_modules を書き換える段階で起きます。 第一段階は差分の計算です。npm は今ある木と目標の木を比べ、変更するものと削除するものを列挙します。 第二段階が退避です。変更または削除の対象になった浅い階層のものを、別名へ移動します。ここが ENOTEMPTY の主な発生場所です。退避しておく理由は、途中で失敗したときに元へ戻せるようにするためです。 第三段階が展開で、新しい内容を書き込みます。第四段階で退避したものを片付けます。 失敗が第二段階で起きると、npm は元へ戻す処理を試みます。このとき戻す方向の移動でも同じコードが出ることがあります。path と dest の関係が逆になっていれば、戻す側で失敗しています。 最初に確認すること まず、診断用の行を抜き出します。 npm install 2>&1 | grep -E "npm error (code|syscall|path|dest|errno)" 出力はこの形になります。 npm error code ENOTEMPTY npm error syscall rename npm error path /app/node_modules/lodash npm error dest /app/node_modules/.lodash-Ab3dEf9x dest の名前に注目してください。ドットに続けて元の名前があり、その後ろに8文字の英数字が付きます。実装では、元の経路をもとに固定の手順で短い文字列を作り、.<元の名前>-<その文字列> という名前にします。経路が同じであれば同じ名前になるため、何度実行しても変わりません。 次に、その退避先が実際に残っているかを見ます。 ls -a node_modules | grep "^\." dest と同じ名前が出てくれば、前回の中断が残っています。出てこないのに失敗する場合は、削除した直後に作り直されています。 ...