ハマりどころ集
学習中に実際に遭遇した問題をカテゴリ別にまとめました。詳しい経緯は各 Phase のページを参照してください。
Windows / PowerShell
| 現象 |
原因 |
対策 |
出典 |
-backend-config=backend.hcl が 2 つの引数に分割される |
PowerShell 5.1 が . の位置で引数を分割する |
引数全体を引用符で囲む："-backend-config=backend.hcl"（-out=、-generate-config-out= も同様） |
Phase 3 |
| zip が Linux（Cloud Shell / リソース・マネージャ（Resource Manager））で展開できない |
Compress-Archive のパス区切り文字が \ |
tar.exe -a -c -f x.zip -C <dir> . または tar.gz を使う |
Phase 5b |
pip install oci-cli → FileNotFoundError |
Windows のパス長の上限が 259 文字 |
まず wheel 内の最長パスを調べる。Python SDK に切り替えるか、短いパスにインストールする（公式インストール・スクリプトでも同様にインストールできない） |
Phase 5b、Phase 7 |
git push が固まる：auto-detection of host provider took too long |
Git Credential Manager がサービスの種類を判定する処理でタイムアウト |
git config credential.<URL>.provider generic |
Phase 7 |
checkov → UnicodeDecodeError: 'cp932' |
システム・エンコーディングでファイルを読むため、UTF-8 で書いた日本語・中国語のコメントが読めない |
$env:PYTHONUTF8 = '1' |
Phase 5a |
インストールしたばかりの terraform / tflint が見つからない |
PATH はターミナル起動時に読み込まれる |
ターミナルを開き直す |
Phase 0 |
OCI の設定
| 現象 |
原因 |
対策 |
出典 |
did not find a proper configuration for private key |
key_file=... # TODO。config は行末コメントに対応していない |
# TODO を削除 |
Phase 0 |
削除したリソースが Resource Search でまだ ACTIVE |
検索インデックスに遅延がある |
get_xxx API で直接確認する |
Phase 4 |
dnf install が成功しても、NAT ゲートウェイ（NAT Gateway）の疎通確認にはならない |
OCI の dnf リポジトリは Oracle Services に属し、サービス・ゲートウェイ（Service Gateway）を経由する |
curl ifconfig.me で送信元 IP を確認する |
Phase 4 |
| NSG（ネットワーク・セキュリティ・グループ）ルールの import ID がコンソール（GUI）で見つからない |
ルール ID が表示されない |
data source oci_core_network_security_group_security_rules で調べる |
Phase 3 |
SDK のドリフト（drift）結果に json.loads を使うと TypeError |
すでに dict になっている |
そのまま dict として使う |
Phase 5b |
Cloud Shell
| 現象 |
原因 |
対策 |
出典 |
ED25519 keys are not allowed in FIPS mode |
Cloud Shell は FIPS モード |
RSA を使う（-t rsa -b 4096） |
Phase 4 |
ansible.posix.firewalld → couldn't resolve module |
Cloud Shell の Ansible は 2.9 |
短い名前 firewalld を使う |
Phase 2 |
| サブネット（Subnet）が削除できない（Terraform がリトライし続ける） |
Cloud Shell の private network の VNIC がまだサブネットに接続されている |
destroy の前に Network を Public に戻す |
Phase 6 |
| Upload で 1 ファイルしか送れない |
仕様 |
tar.gz にまとめてから送る |
Phase 2 |
| ビルドしたイメージが Function で動かない |
Cloud Shell のデフォルトは ARM（aarch64） |
Actions → Architecture → x86_64 |
Phase 8 |
docker push のあとに digest: が出ない |
Cloud Shell の docker は Podman |
最後の Writing manifest to image destination を確認 |
Phase 8 |
ネットワーク / 利用環境
| 現象 |
原因 |
対策 |
出典 |
ローカル PC から SSH → Connection timed out |
利用中のネットワークが送信方向の 22 番ポートをブロックしている |
Cloud Shell + private network、または OCI の要塞（Bastion、Cloud Shell から使う） |
Phase 2 |
| Cloud Shell の IP を許可したい |
送信元 IP は Oracle の共用で、しかも変わる |
パブリック IP は許可せず、private network を使う |
Phase 2 |
| ブラウザで GitHub が開けない（コマンドラインからはつながる） |
利用中のネットワークでブロックされている |
回避はしない → CI/CD は OCI DevOps に切り替える |
Phase 7 |
| OCI DevOps のリポジトリに SSH でつながらない |
22 番ポートがブロックされている |
HTTPS + 認証トークン（Auth Token） |
Phase 7 |
| 要塞のセッションがつながらない（セキュリティ・リストで Oracle サービスの 443 だけを許可） |
要塞のプライベート・エンドポイントは同じサブネットにあり、そこから VM の 22 は「送信」 |
「サブネット内の 22 の送信」を追加 |
Phase 9 |
curl ifconfig.me がフロー・ログに記録されない |
ルートのない通信は記録されない（ルーティングの段階で破棄されると推測） |
インターネットに出られないことの確認は curl の結果で行い、フロー・ログに頼らない |
Phase 9 |
OCI DevOps
| 現象 |
原因 |
対策 |
出典 |
Unable to fetch build_spec file ... RelatedResourceNotAuthorizedOrNotFound |
repos はコンテナ・レジストリ（OCIR）のリソース・タイプ |
read devops-repository |
Phase 7 |
ランナーで pip → ProxyError ... Name or service not known |
ランナー・イメージの pip の設定に Oracle 社内のプロキシが書かれている |
PIP_CONFIG_FILE=/dev/null |
Phase 7 |
| 最初の push が拒否される（non-fast-forward） |
リポジトリ作成時に空の「Initial Commit」が自動で作られる |
git push --force（空のコミットだけを上書き） |
Phase 7 |
default_branch で plan のたびに差分が出る |
API が refs/heads/main として保存する |
コードにも refs/heads/main と書く |
Phase 7 |
モニタリング / ファンクション
| 現象 |
原因 |
対策 |
出典 |
| アラームのメールが JSON |
message_format = "PRETTY_JSON" |
ONS_OPTIMIZED（変わるのはメールだけで、Function が受け取るのは JSON のまま） |
Phase 8 |
| 復旧したサイトがまた止まる |
アラーム回復（FIRING_TO_OK）のメッセージでも Function が呼ばれる |
Function で FIRING_TO_OK / RESET をスキップ |
Phase 8 |
| ほかの予算のアラートでもサイトが止まる |
イベント・ルールにはすべての予算・すべてのルールのイベントが届く |
Function はイベントの内容を見ず、予算の実際の費用を自分で確認 |
Phase 8 |
予算を新規作成 → 400-LimitExceeded |
1 つのコンパートメントに予算は 1 つだけ |
データ・ソースで既存の予算を読み、アラート・ルールだけを追加（import しない） |
Phase 8 |
OCIR への docker push が 403 |
Cloud Shell のアーキテクチャを切り替えると認証情報がなくなる |
もう一度 docker login |
Phase 8 |
OCIR への docker login が失敗 |
ユーザー名の形式が git と違う |
<ネームスペース>/<ユーザー名> |
Phase 8 |
ボールト / ロギング
| 現象 |
原因 |
対策 |
出典 |
バケット（CMK）を新規作成 → 404-NotAuthorizedOrFoundKmsKey |
ポリシーを作成した直後で IAM がまだ反映されていない（depends_on が保証するのは順序だけ） |
少し待ってからもう一度 apply |
Phase 9 |
コネクタ → Invalid batchRolloverTimeInMs |
範囲は 60000〜420000 ms |
最長 7 分（420000） |
Phase 9 |
シークレットの読み取り → NotAuthorizedOrNotFound（404） |
権限がない場合も存在しない場合も 404 |
ポリシー（read secret-bundles）と動的グループを確認 |
Phase 9 |
| フロー・ログに Oracle サービス → VM のエフェメラル・ポートの REJECT がある |
接続終了後に遅れて届いたパケットと推測 |
正常な現象 |
Phase 9 |
| 現象 |
原因 |
対策 |
出典 |
in-place（~）の apply 後にロード・バランサ（Load Balancer、LB）が 502 を返す |
変更した属性で VM が再起動し、2 台が同時に再起動した |
1 台ずつ変更する（-target で apply を分けるなど） |
Phase 5a |
user_data を変えると VM が再作成される |
cloud-init の内容は # forces replacement |
構成管理は Ansible に任せる |
Phase 2 |
| 新しいイメージ（Image）が公開されると VM が再作成されそうになる |
data source が新しいイメージを取得した |
ignore_changes = [source_details[0].source_id] |
Phase 3 |
| ノード・プール（Node Pool）が "complete" でも、ノードがまだ ready でない |
Terraform は API の応答を待つだけ |
SDK でノードの状態を確認する |
Phase 6 |
| checkov が失敗と判定するが、コードは正しい |
checkov は launch_options 内の書き方しか認識しない |
checkov の書き方に合わせて直す、または checkov のソースコードを見る |
Phase 5a |
If LaunchOptions is provided, NetworkType must be specified |
launch_options を書くと必須 |
network_type = "PARAVIRTUALIZED"（イメージのデフォルトと同じ値） |
Phase 9 |
| VM 作成時に転送中の暗号化が無視される（API では false） |
作成時の指定が反映されない |
2 回目の apply（in-place update、再起動あり）。API で確認する |
Phase 9 |
(sensitive value) のパスワードが state では平文 |
sensitive は表示しないだけ |
パスワードはボールトに生成させ（enable_auto_generation）、Terraform は枠だけを作る |
Phase 9 |
Kubernetes / OKE
| 現象 |
原因 |
対策 |
出典 |
| Service LB を作成すると Terraform でドリフトが出る |
OKE がセキュリティ・リスト（Security List）に自動でルールを追加する |
NodePort を事前に許可し、annotation security-rule-management-mode: "None" |
Phase 6 |
terraform destroy で LB が削除できない |
LB は K8s が作ったもので、state に含まれない |
先に kubectl delete、そのあと destroy |
Phase 6 |
| drain 後に uncordon しても、Pod が 1 台のノードに偏ったまま |
K8s は自分から再配置しない |
rollout restart。本番環境では topologySpreadConstraints を使う |
Phase 6 |