2025-12-16

【github Actions => deploy to AWS】Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

AWS github Actions

GitHub Actionsを使用してAWSのAppRunnerに自動デプロイを設定していたところ、表題のようなエラーが発生。AWS側のIAM Roleの信頼ポリシーは以下のように設定していた。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": [
                        "repo:myname/my-repo-name:ref:refs/heads/main",
                        "repo:myname/my-repo-name:ref:refs/heads/develop"
                    ]
                }
            }
        }
    ]
}

「Condition」内でどのリポジトリのどのブランチというのを指定していたが、これがworkflow側ではGitHub Environmentを使用していたため実際は以下のようになり、信頼ポリシー側とマッチしていなかったことで許可されない、という事象だった。

repo:myname/my-repo-name:environment:development,
repo:myname/my-repo-name:environment:production,

なので対応としてはもっと以下のようにもっとザックリと許可するように変更してやることで、無事実行できるようになった。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:myname/my-repo-name:*",
                }
            }
        }
    ]
}

2025-11-11

CodePipelineでのDeployが突然エラーになった（Invalid CEN header）

4年ほど問題なくDeployできていたFargate運用JavaアプリケーションのCodePipelineでのDeployが、突然Fargate起動時に以下エラーを吐くようになった。

Caused by: java.util.zip.ZipException: Invalid CEN header (invalid zip64 extra data field size)

調べてみるとどうやらtomcatを起動する時に今までは普通のzipで展開していたwar/jarファイルを、あるタイミングから突然zip64で展開しようとするようになったっぽい。

回避策として、環境変数「JAVA_OPTS」に「-Djdk.util.zip.disableZip64ExtraFieldValidation=true」というオプションを追加するとzip64のフィールドを見ないようになるっぽかったので、Dockerfile内で指定していた「JAVA_OPTS」を以下の通り修正しDeloyできるようになった。

- ENV JAVA_OPTS="$JAVA_OPTS -Duser.timezone=Asia/Tokyo"
+ ENV JAVA_OPTS="$JAVA_OPTS -Duser.timezone=Asia/Tokyo -Duser.language=ja -Djdk.util.zip.disableZip64ExtraFieldValidation=true"

Fargateのパッチ適用の直後に発生したため、それによる影響かAWSサポートに問い合わせてみたものの、セキュリティの観点でパッチの具体的な内容は教えてられないとのことで、原因は闇のまま。散々アプリ側で何かしたからだみたいなことを言われたけど、こんなの知らねーよ。。

2024-11-15

【AWS/Lambda/Python3.12バージョンアップ対応】No module named 'psycopg2._psycopg' エラー解消方法

課題

PostgreSQLへの接続があるLambdaでPython3.8を利用していたが、AWSでPython3.8のサポートが終了するとのことで3.12にバージョンアップしたら「No module named 'psycopg2._psycopg' 」というエラーが出るようになった

解決方法

Web上に同じような記事が多数あり、多くはDockerを使用して「psycopg2-binary」を取得し、zipに固めてLambdaLayerに登録するという内容でしたが、DockerDescktopが有料化されてから会社で使えない状況なので、AmazonLinuxのEC2上で行った（Dockerを使うのはあくまでLambdaの実行環境と同じOS環境でpip installを行うためのため、同じ環境のEC2があればそこで対応しても問題ない。今Docker環境がない人、もしくは会社の事情で使えない人はAmazonLinuxで一時的にEC2を立ち上げてやった方が早いと思います）。

1.EC2内の任意の場所で以下を実行してrequirements.txtファイルを作成

echo 'psycopg2-binary' > requirements.txt

2.実行場所に「python」フォルダを作成し、そこにpsycopg2-binaryをインストール

pip install --platform manylinux2014_x86_64 --target . --python-version 3.12 --only-binary=:all: -r requirements.txt -t python/

3.「python」フォルダを「layer.zip」にzipする

zip -r layer.zip python

4.「layer.zip」を実態としてLambdaLayerを作成

aws lambda publish-layer-version --layer-name psycopg2-binary-3-12 --zip-file fileb://layer.zip --compatible-runtimes python3.12

5.後は対象のLambdaにLambdaLayerを設定すればOK

2024-10-30

【Vite + React】import文内の「src」を「@」で表記する設定

React Vite bulletproof-react

Vite + React環境でimport文内の「src」を「@」で表記する設定がうまく機能せず少し苦労したので解消方法を共有。

やりたいこと

bulletproot-reactの仕様に倣って、import文内でsrc配下のパスを指定する際に、

import Layout from '../../../../components/templates/Layout';

と表記するところを、

import Layout from '@/components/templates/Layout';

と絶対パスで表記できるように設定し、node_modulesからの呼び出しとsrc内からの呼び出しを区別できるようにしたい。

設定方法

多くのサイトでは「tsconfig.json」の「compilerOptions」に以下のような設定を追加するだけだと記述されているが、なぜかそうしても一向に機能しない

"baseUrl": ".",
"paths": {
      "@/*": ["./src/*"]
}

調べたところ、Viteを利用している時は「vite-tsconfig-paths」という別のパッケージが必要ということだったので、以下コマンドでインストール

npm install --save-dev vite-tsconfig-paths

さらに「vite.config.js」を以下のように書き換え (変更前)

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
});

(変更後)

import { defineConfig } from 'vite';
// import react from '@vitejs/plugin-react';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  // plugins: [react()],
  plugins: [tsconfigPaths()],
});

この設定でうまく機能するようになった

2024-10-30

【React / ESLint 】React' must be in scope when using JSXeslintreact/react-in-jsx-scope

React ESLint

実行環境

React ^18.2.0

ESLint ^9.13.0

エラー内容

ESLintをinstallした瞬間以下文言のエラーが大量発生

React' must be in scope when using JSXeslintreact/react-in-jsx-scope

解消方法

eslint.config.jsを以下のように修正することで解消した (修正前)

import globals from "globals";
import pluginJs from "@eslint/js";
import tseslint from "typescript-eslint";
import pluginReact from "eslint-plugin-react";
export default [
  {files: ["**/*.{js,mjs,cjs,ts,jsx,tsx}"]},
  {languageOptions: { globals: globals.browser }},
  pluginJs.configs.recommended,
  ...tseslint.configs.recommended,
  pluginReact.configs.flat.recommended,
];

(修正後)

import globals from 'globals';
import pluginJs from '@eslint/js';
import tseslint from 'typescript-eslint';
import pluginReact from 'eslint-plugin-react';
export default [
  { files: ['**/*.{js,mjs,cjs,ts,jsx,tsx}'] },
  pluginJs.configs.recommended,
  ...tseslint.configs.recommended,
  pluginReact,
  {
    languageOptions: { globals: globals.browser },
    rules: {
      'react/react-in-jsx-scope': 'off',
      'react/jsx-uses-react': 'off',
    },
  },
];

2024-04-19

【AWS】【Amplify Auth】Can't resolve '@aws-amplify/core/internals/utils

AWSのAmplifyで認証機能を入れてHostedUIのログインページを表示させようとしたら、以下のようなエラーが発生。

Can't resolve '@aws-amplify/core/internals/utils

とりあえずないと言われてるので、以下コマンドでaws-amplify/coreを入れてみる

npm install @aws-amplify/core --save --legacy-peer-deps

すると～フォルダが空っぽじゃありません、みたいなエラーが発生

npm ERR! ENOTEMPTY: directory not empty, rmdir 'D:\narejiro\node_modules\axios'

指摘されたフォルダを手で削除して再度実行

npm install @aws-amplify/core --save --legacy-peer-deps

するとまた～フォルダが空っぽじゃありません、みたいなエラーが発生

npm ERR! ENOTEMPTY: directory not empty, rmdir 'D:\narejiro\node_modules\@aws-crypto\sha256-browser\node_modules\@aws-crypto'

再び指摘されたフォルダを手で削除して再度実行

npm install @aws-amplify/core --save --legacy-peer-deps

するとインストール成功したっぽい。npmで立ち上げてみると、

Module not found: Error: Can't resolve 'axios' in 'D:\project\src\graphql'

あれ、これさっきこれのフォルダが空じゃないっていうエラーが出たから消したフォルダですよね。確かにこれ使ってるからそりゃないとエラーになるよね。なので再度インストール

npm install axios

すると今度は別の依存関係のエラーが発生

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: aws-amplify-react@5.1.43
npm ERR! Found: @aws-amplify/core@6.0.27
npm ERR! node_modules/@aws-amplify/core
npm ERR!   @aws-amplify/core@"^6.0.27" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @aws-amplify/core@"3.x.x" from aws-amplify-react@5.1.43
npm ERR! node_modules/aws-amplify-react
npm ERR!   aws-amplify-react@"^5.1.43" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: @aws-amplify/core@3.8.24
npm ERR! node_modules/@aws-amplify/core
npm ERR!   peer @aws-amplify/core@"3.x.x" from aws-amplify-react@5.1.43
npm ERR!   node_modules/aws-amplify-react
npm ERR!     aws-amplify-react@"^5.1.43" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! D:\Users\a2182258\AppData\Local\npm-cache\_logs\2024-04-20T05_39_59_400Z-eresolve-report.txt

このフォルダは古いバージョン用で不要なので「aws-amplify-react」フォルダも手で削除。さらにpackage.jsonやpackage-lock.jsonの中の「aws-amplify-react」の部分も削除して再度axiosをインストール

npm install axios

さらに以下コマンドを実行し、package.jsonの内容をpackage-lock.jsonに反映させる

npm install

エラーがなくなったことを確認し、起動

npm start

→成功 !!! やっぱりamplifyみたいな全部やってくれる系ライブラリは一発でいけば便利だけど、つまづくと大変。。

2024-04-19

【AWS】【Amplify】Downloading release from https://package.cli.amplify.aws/12.10.3/amplify-pkg-win-x64.tgz Error fetching release: Request failed with status code 407

AWS AWS Amplify

amplifyの最新バージョンをインストールしようと以下コマンドを実行した。

npm install -g @aws-amplify/cli

さっそく「amplify init」を実行してみると以下のようなエラーが。。

Downloading release from https://package.cli.amplify.aws/12.10.3/amplify-pkg-win-x64.tgz
Error fetching release: Request failed with status code 407

たぶん会社のプロキシが原因だとは思うけど、ブラウザからURLをたたくとちゃんとtgzファイルがダウンロードできる。

環境変数を設定しなおしたりあれこれやったけどうまくいかず、結局ブラウザでダウンロードしたtgzファイルを適当なフォルダに解凍してそのファイルを直接実行するやり方で回避した。

C:/amplify/amplify-pkg-win-x64.exe init

※「C:/amplify/amplify-pkg-win-x64.exe」がamplifyの実行ファイルのため、このコマンドで「amplify init」と同じ挙動になる

同じ問題に直面したけどちゃんと解決する時間がない方向けに取り急ぎの解消方法でした。