Container RegistryからArtifact Registryへの変更の影響

動機

 少し古い話ですが、Container Registryは2025/3くらいから徐々に停止しています。プロダクトによって具体的な停止のタイミングはいくらか異なるようです。これに伴いContainer Registry→Artifact Registryへの移行が必須となるのですが、この移行により思わぬ影響があったので、ここに記しておきます。

手順

移行は「Container Registry から Artifact Registry に自動的に移行する」による自動移行ではなく、「標準リポジトリへの移行」に従って手作業で移行しています。具体的に変わるのは、Cloud Buildによるコンテナのレジストリへの保存や、レジストリから取り出してCloud Runにデプロイする部分のみだと認識していました。

実際のコマンドだと以下のようになります。

Container Registry

gcloud builds submit --tag gcr.io/プロジェクト名/イメージ名

gcloud run deploy apply --image gcr.io/プロジェクト名/イメージ名 --region=リージョン名

 

Artifact Registry

gcloud builds submit . --pack image=リージョン名-docker.pkg.dev/プロジェクト名/リポジトリ名/イメージ名

gcloud run deploy apply --image リージョン名-docker.pkg.dev/プロジェクト名/リポジトリ名/イメージ名 --region=リージョン名

その他のソースなどは変更不要の認識です。

現象

ところがCloud Runでデプロイしたイメージを実行してみると、動作が違います。ソースとログから解析して、環境変数がなくなっていると判断しました。

Container Registryを使っていたころの該当環境変数は、以下のような感じでDockerfileで指定していました。

ENV 環境変数名 値の文字列

Artifact RegistryだとDockerfileの環境変数は反映されない様子です。

対処

DockerfileをあきらめてgcloudコマンドでCloud Runにデプロイする際に環境変数を指定することにしました。これはContainer Registryでも実績がある方法です。

実際の指定は以下のような感じ。

gcloud run deploy apply --image リージョン名-docker.pkg.dev/プロジェクト名/リポジトリ名/イメージ名 --set-env-vars="環境変数名=値の文字列" --region=リージョン名

これで解決しました。 

ちなみに、複数の環境変数を定義したい場合、"--set-env-vars"の値をコンマで区切って並べます。こんな感じ。

--set-env-vars="環境変数名1=値の文字列1","環境変数名2=値の文字列2"

 

LotteryServアップデート

　LotteryServを更新しました。今回の更新はセキュリティの強化のみです。そのために利用方法が若干変わった点があり、また新たな制限を追加しています。

3Dセキュア対応

　LotteryServのご利用料金はクレジットカード払いです。クレジットカードの不正利用のリスクを下げるため、EMV 3Dセキュアに対応しました。これは経済産業省の「クレジットカード‧セキュリティガイドライン」に準じるものです。

　以下に説明します今回の更新のその他の変更は、これに伴うものとなっています。

募集の開始・再開ができるユーザを制限

　募集の開始および、休止中の募集の再開ができるユーザを、主催者の支払い方法を登録しているユーザのみに制限しました。

　募集の開始・再開時にご利用料金の上限を決め、クレジットカードに対して支払いの予約を行うため、この制限が必要になりました。

　練習モードではこの制限はありません。

多要素認証に対応

　ログインの際に多要素認証を利用できるようにしました。今回の更新では第2要素に利用できるのは、SMS認証のみです。

　主催者の支払い方法を登録するユーザは、多要素認証の追加を必須としています。

SMS認証登録のログ「Failed to initialize reCAPTCHA Enterprise config. Triggering the reCAPTCHA v2 verification.」

(2025/04/23)

タイトルに「エラー」と表記していましたが、「ログ」に修正しました。

 現象

Identity Platform/Firebase Authenticationを使用して多要素認証にSMS認証の登録を実装する場合、PhoneAuthProvider.verifyPhoneNumber()で表題のログがブラウザのコンソールに出て失敗することがあります。

Failed to initialize reCAPTCHA Enterprise config. Triggering the reCAPTCHA v2 verification.

実装はGoogleのスニペットどおりですが、web8とweb9で実行結果に違いが出たりします。

対象	結果
web8 (namespaced)	期待どおり成功
web9 (modular)	失敗

調査

Googleのドキュメントにはこのような現象についての記述は見当たりません。

ネットで検索してみると、redditの記事「Firebase Phone Auth reCAPTCHA Error」が見つかりました。他の記事はこの記事の別言語版と、リンク切れのみでしたので、実質たった1つです。

この記事ではReact Nativeで発生しているようですが、私が発生を確認したのはweb9 + Angularの組み合わせです。またこの記事は多要素認証ではなく電話認証のようです。しかし発生している現象はほぼ同じの様子です。この記事でも解決はしていません。

解決

手がかりが全くないので、思い当たるところを勘で変更して動作を確認するという地味な作業を繰り返し、解決方法にたどり着けました。

失敗していた実装は以下のような感じです。MultiFactorUserインスタンスをあらかじめ取得しておき、それを使いまわしていました。

class MfaComponent {
    multiFactorUser: MultiFactorUser;
    ...
    constructor(...) {
        ...
        this.multiFactorUser = multiFactor(ログインユーザのUser);
        ...
    }

    sendSms() {
        this.multiFactorUser.getSesstion()		←ここが原因
        .then((multifactorsession) => {
            const options = {
                phoneNumber: 電話番号,
                session: multifactorsesstion,
            };
            const provider = new PhoneAuthProvider(auth);
            provider.verifyPhoneNumber(options, recaptcha).then((verificationid) => {
                ...
            });

MultiFactorUserインスタンスを必要な時に取得するように変更することで、成功するようになりました。

class MfaComponent {
    ...
    constructor(...) {
        ...
    }

    sendSms() {
        multiFactor(ログインユーザのUser).getSesstion()		←修正
        .then((multifactorsession) => {
            const options = {
                phoneNumber: 電話番号,
                session: multifactorsesstion,
            };
            const provider = new PhoneAuthProvider(auth);
            provider.verifyPhoneNumber(options, recaptcha).then((verificationid) => {
                ...
            });

最後に

無事SMSは送信できるようになったものの、表題のログは出続けています。このログがPhoneAuthProvider.verifyPhoneNumber()が期待動作しなかったことと関係あるのかは不明です。動作には影響してなさそうですが、ちょっと不安です。