AWS DevAx::connect シーズン1「イベント駆動」が面白い

2021年6月よりAWSがDexAx::connect シーズン1「イベント駆動」というWebセミナーが開催しています。

pages.awscloud.com

毎週木曜日に2時間ほどの時間をかけて、「イベント駆動」を掘り下げて解説されているセミナーです。

この記事を書いている2021年7月23日時点ですでに6回のセッションが開催されていますが、過去のセッションはすべて動画&資料公開されていて、あとで見直すことができるものとなっています。

イベント駆動とは?

本Webセミナーの案内をいただいたとき『「イベント駆動って?」って何?』と思ったのが正直なところでした。少し調べたところ、AWSが以下のようなドキュメントを出しています。

aws.amazon.com

最初の一文に

An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices.

とあるので、最近何かと話題なマイクロサービスでシステムを設計する上で欠かせないアーキテクチャのようです。

本当はこれを読み込んでから参加しようと思ったのですが、英語ということもあり、あまり読まずにとりあえず第1回のWebセミナーを受けました。

詳細は、上記イベントページから参加登録して過去発表を参照してほしいのですが、

  • ドメイン駆動設計の紹介
  • イベントの紹介
  • 分散システムにおける課題
  • 非同期化による応答性の改善と依存性の削減
  • イベント駆動デザインパターンの紹介と実装例
  • イベントドリブンアーキテクチャ選択における観点
  • etc

と盛りだくさん。2時間って長いなと思っていたのですが、質疑応答含めあっという間に見終えました。

その後もどんどん深掘り

仕事柄、数多くのセミナーを勉強がてら受けるのですが大抵2時間という枠でも用語定義や概要だけ伝えて終了となるものが多いと感じています。 それはそれで有益なのですが、実際に案件適用をしようとすると早々により深掘りした知識を求められることになります。

このセミナーは毎週2時間の枠で一つのテーマをじっくりと深掘りされるので、色々な観点から考えるきっかけとなります。当日の資料だけでなく動画も公開されるので後でじっくり見直すことができます。

例えば第2回は『「疎結合」を実現するメッセージングサービスの選択と利用』と題して数あるAWSのサービスの中から何をどのような観点で選べばいいのかということがわかりますし、第6回は『How to Test your Events?』と題してテストの方法についてじっくり解説していただいています。

クラウド上でシステム設計に携わる方は聴講するとよいWebセミナーだと感じています。

Azureリソースのネーミングルールのベストプラクティス

今日は小ネタ。ちょっとやっていたことがうまくいかなかったので小ネタに逃げます。

はじめに

Azure上で仮想マシンとかWebアプリとかを作っている際には名前をつける必要がありますが、適当に名前をつけると後で「この仮想マシンって何のために作ったんだっけ?」と分からなくなります。

そのためにネーミングルールを設けることが多いのですが、こんなもの誰かが整理しているでしょと思い色々と探していたら、マイクロソフトが公開していたので紹介します。

マイクロソフトが公開しているネーミングルール

その公開しているネーミングルールは以下のもの。

docs.microsoft.com

リソースの種類やアプリケーション名などを要素ごとに"-"で繋げる形ですね。なんとなくハンガリアン記法に似ている感じがします。

リソースの種類を表す省略形については以下のドキュメントを参照すると良いでしょう。

docs.microsoft.com

あとはこれに従ってリソースを作ればOK。ただ、az cliとかでリソースを作成するときにデフォルト値はこのネーミングルールに従ったリソースを作ってはくれないので、そこはちょっと注意かもしれません。

Azure Web Appsお勉強メモ(4)Azure Web AppsにてデプロイするDockerイメージをAzure DevOpsで生成してAzure Container Registryに登録する

はじめに

先日からAzure Web AppsにRailsアプリを動かすことをやっています。動かすことは簡単にできたのですが、色々と手作業が多かったのでちょっとでも自動化しようと試してみました。前回はGitHub Actionsを使ってやりましたが、最後のWebAppsへの反映がうまくできなかったので、今回は手を変えてAzure DevOpsを使ってみることにしました。ほら、同じマイクロソフトのプロダクトならいい感じに連携できているのかなと(GitHubマイクロソフト傘下とか...いやなんでもないです)。

これまでの内容は以下を参照してください。

Azure DevOpsとは

開発に必要な各種ツールをまとめて提供して、かつ無料から使い始めることができるサービスです。GitリポジトリやCI/CD基盤を持っています。詳細は以下を参照。

azure.microsoft.com

GitHub Actionsでも同様のことができますが、Azure DevOpsではサービスプリンシパルを明示的に用意する必要がなく、Service Connectionsを画面上で設定しておけば簡単に接続できます。

docs.microsoft.com

今回、きっと連携がうまいことできるであろうAzure DevOpsを使ってAzure Container Registoryにイメージをpushし、Azure Web Appsへのデプロイをしてみることにしました。

Docker Imageを作成してAzure Container Registoryにpushする

Azure DevOpsでCI/CDの機能を提供するのはAzure Pipelinesです。これを使うには、リポジトリazure-pipelines.ymlを記述します。

docs.microsoft.com

YAMLファイルを書くのは色々と調べないと大変なのですが、Azure Pipelines内では初回作成時におすすめの構成を提示してくれたりします。

f:id:miyohide:20210711181212p:plain

また、オンラインエディターがかなり充実しているので、それを利用するとあまり苦しまなくても実装できました。

docs.microsoft.com

今回、実装したazure-pipelines.ymlは以下の通り。

trigger:
- master

pool:
  vmImage: ubuntu-latest

steps:
- task: Gradle@2
  inputs:
    workingDirectory: ''
    gradleWrapperFile: 'gradlew'
    gradleOptions: '-Xmx3072m'
    javaHomeOption: 'JDKVersion'
    jdkVersionOption: '11'
    jdkArchitectureOption: 'x64'
    publishJUnitResults: true
    testResultsFiles: '**/TEST-*.xml'
    tasks: 'bootBuildImage'  # Spring BootでのDockerイメージ作成コマンド

- task: Docker@2
  inputs:
    containerRegistry: 'acr'    # service connectionの設定名
    repository: 'webapp'  # イメージ名
    command: 'push'
    tags: 'latest'

ここでは、Azure Web Appsへのデプロイは行いません。

Azure Web Appsへデプロイをする

できたDockerイメージをAzure Web Appsへデプロイするには、Azure Pipelinesのリリース機能を使います。Azure Pipelinesでもできそうですが、思想的にはリリース機能を使った方が良いかなと感じました。

docs.microsoft.com

以下のドキュメントにあるように、Azure Container Registryもトリガーにできそうです。

docs.microsoft.com

あらかじめデプロイ先のAzure Web Appsを作っておけば、項目をそれぞれ選択すれば設定は終わります。

f:id:miyohide:20210711183142j:plain

実際動かしてみると無事デプロイできたみたいです。

f:id:miyohide:20210711183246p:plain

Azure Web Apps上のデプロイセンターで確認してもAzure Pipelinesの内容が反映されました(デプロイ後すぐというわけではなく、5分ぐらい時間がかかりました)。

f:id:miyohide:20210711184943p:plain

ですが、実際にアプリにアクセスしてみるとアプリが動いていません。

f:id:miyohide:20210704164525p:plain

ログを見てみると、やはりDockerイメージの取得に失敗しているみたいです。

2021-07-11T08:12:25.960Z ERROR - DockerApiException: Docker API responded with status code=InternalServerError, response={"message":"Get xxxxxxxxxxxxxxxxxxxxx: unauthorized: authentication required, visit https://aka.ms/acr/authorization for more information."}
2021-07-11T08:12:25.963Z ERROR - Image pull failed: Verify docker image configuration and credentials (if using private repository)
2021-07-11T08:12:25.965Z INFO  - Stopping site miyoshisbapp because it failed during startup.
2021-07-11T08:15:46.854Z INFO  - Pulling image from Docker hub: miyohideacr.azurecr.io/webapp:latest

う〜んなんでだろう。

環境変数が設定されていない

色々と原因を探していたときに、ふと「アプリケーション設定」の「DOCKER_」で始まる環境変数の値を見てみると、適切な値が設定されていないことがわかりました。下図は「DOCKER_REGISTRY_SERVER_USERNAME」の値を見ていますが、何も値が設定されていません。

f:id:miyohide:20210711183820p:plain

なんじゃそら...と思いつつ、Azure Container Registryの管理者アカウントを有効にして「DOCKER_」の各種値を設定しておきます。

docs.microsoft.com

  • DOCKER_CUSTOM_IMAGE_NAME → デプロイしたいDockerイメージ名
  • DOCKER_REGISTRY_SERVER_PASSWORD → Azure Docker Registryの管理者アカウントのパスワード(どちらでもOK)
  • DOCKER_REGISTRY_SERVER_URL → https://名前.azurecr.io
  • DOCKER_REGISTRY_SERVER_USERNAME → Azure Docker Registryの管理者名

これを設定して、リロードするとアプリが動くことが確認できました。

再度Azure DevOpsで再度デプロイしても上記の環境変数が上書きされることはありませんでした。

ちなみに

Azure Web Apps for ContainerにてAzure Container Registryを参照する際、Admin権限が必要な状況については、以下のFeedbackが出ていて現在開発中のようです。

started
We welcome user feedback and feature requests!
  • 108 votes
  • 13 comments

Web App for Containers - ACR access requires admin account enabled on repository

It looks as though Web App for Containers requires the use of the admin account on the repository in ACR.

The notes on use of the admin account suggest to use that account only for testing purposes and describe some of the downsides to having it enabled.

Is there a plan to support Serv...

feedback.azure.com

Ruby/Railsの情報の探し方(2021年7月版)

はじめに

少し前に「技術系の情報をどう探すか」ということが私の周りで話題となりました。その場では「検索」が第一候補として上がったのですが、「なんかヒットしないんだよねぇ。」ということになりました。それはそれで正しいと思うのですが、世の中もっと信頼できる情報ソースがあるのにもったいないと思っています。ただその場ではうまく整理できなかったので、個人的にやっているRuby/Railsの情報の探し方を記します。

結論

はじめに結論ぽいものを。

  • 書籍は持っておく
  • RailsについてはRuby on Railsガイド
  • 細かいAPIの使い方などはgem serverでGemのRDocを見る
  • 公式サイト/Gemのソースが置いているGitHubに目を通す
  • やってみる
  • 最後に検索

書籍について

RubyRailsについては、日本語での情報がオンラインでも書籍でもたくさん出ています。個人的には「パーフェクト」シリーズを手元に置いていつでも目を通せるようにしています。

紙でも電子書籍でもどちらでもお好みで。

RailsについてはRuby on Railsガイド

体系的にRailsを学ぶのであればRuby on Railsガイドがよいと思います。はじめのうちは頭から読んでおくと良いかなと思います。

railsguides.jp

細かいAPIの使い方はgem server

細かいAPIの使い方はgem serverでドキュメントサーバーを立てておくところからスタートします。

guides.rubygems.org

あとはブラウザでlocalhost:8808にアクセスして調べます。

f:id:miyohide:20210707205820p:plain

個人的に良くやるのは、Railsでformを書くときにclass属性ってどうやって書くんだっけ?というときに調べます。この場合はactionview gemのActionView::Helpers::FormBuilderを見ればOK。ここら辺はある程度の経験が必要かもしれません。

f:id:miyohide:20210707210502p:plain

公式サイト/Gemのソースが置いているGitHubに目を通す

RubyならRubyの公式ページにあるドキュメントページからリンクが貼ってあるリファレンスマニュアルをみます。

www.ruby-lang.org

Gemでしたら、ソースが置いてあるGitHubの特にReadmeには目を通しておくとやりたいことが書かれていることが多いです。具体的にはRubyGemsにて調べたいGemのページを見つけ、「ホームページ」や「ソースコード」に書かれているページを見ると該当のものが見つかると思います。

f:id:miyohide:20210707212024p:plain

やってみる

私はドキュメントに書いてあることを読んだだけで理解できる人ではないので、たいてい手を動かしてみることにします。Rubyにはirbというコマンドがあるので、ちょっとしたお試しで処理内容を確認するにはいいかなと思います。

docs.ruby-lang.org

最後に検索

ここまでやっても見つからなかった場合は検索で。キーワードが悩みの種ですが、ここまで来ると自分がやりたいことが整理できていて、情報も探しやすいのかなと思ったりします。

Azure Web Appsお勉強メモ(3)Azure Web AppsにてデプロイするDockerイメージをGitHub Actionsで作成してAzure Container Registryにpushする(2)

はじめに

先日からAzure Web AppsにRailsアプリを動かすことをやっています。動かすことは簡単にできたのですが、色々と手作業が多かったのでちょっとでも自動化しようと試してみました。前回は結局Azure Container Registryへのpushについては手作業で実施してしまったのですが、今日はそこも自動化します。

先週の内容は以下を参照してください。

サービスプリンシパルとは?

そもそもサービスプリンシパルがあまりよく分かっていなかったので復習から。以下のQiitaの記事(「Azure AD のサービスプリンシパルを 3 つのユースケースから眺めてみた」)を参考にしました。

qiita.com

完璧に理解したとは言えませんが、少なくとも前回でやろうとしていた以下の記事の内容は理解することができました。

docs.microsoft.com

併せてaz ad sp create-for-rbacのコマンドのマニュアルにも目を通しておきます。

docs.microsoft.com

ものすごく簡単に書くと以下のことをやることが目的。

  • Azure Container Registryにpushできる仮想的なユーザをaz ad sp create-for-rbacで作成する
  • 作成する仮想的なユーザができることはできるだけ絞り込みたいので、scopeにAzure Container Registryのidを指定しておく
  • また、同じ理由でroleもpushしかできないようにしておく

実際にaz ad sp create-for-rbacを実行すると以下の結果が得られました。

Creating 'acrpush' role assignment under scope 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
'name' property in the output is deprecated and will be removed in the future. Use 'appId' instead.
{
  "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
  "displayName": "acrsp",
  "name": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
  "password": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
  "tenant": "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"
}

得られた結果からappIdpasswordを使うことになります。

GitHub Actionsでの実装

前回では、tagをつけたらDockerイメージをGitHub Actionsで作成することを実装しました。今回は作成したDockerイメージをAzure Container RegistryにGitHub Actionsでpushします。

まずは、ログインです。以下のように実装しました。

# 省略
    steps:
    - uses: actions/checkout@v2
    - uses: azure/docker-login@v1
      with:
        login-server: miyohidecontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
# 省略

ここでAzure Container Registryにログインするためのユーザー名とパスワードを指定する必要があります。これらの値は先ほど作成したサービスプリンシパルappIdpasswordが該当するのですが、それをそのまま入力すると第三者による悪用が起こるので、それはできません。そこで上記で使っているのがsecrets.REGISTRY_USERNAMEsecrets.REGISTRY_PASSWORDです。これはGitHub Actionsで用意されている「暗号化されたシークレット」という機能です。詳細は、以下を参照してください。

docs.github.com

これを使うと、安全にappIdpasswordGitHub Actionsに渡すことができます。

GitHub Actionsはログも出力されるのですが、以下の画面のように該当部分が***でマスク化されています。

f:id:miyohide:20210704163345j:plain

あとはdocker pushするだけ。以下のように実装しました。

# 省略
    - name: create Docker Image
      run: |
        IMAGE_TAG=$(echo ${{ github.ref }} | sed -e 's/refs\/tags\///')
        docker build -f Dockerfile.prd -t miyohidecontainer.azurecr.io/runlog:$IMAGE_TAG .
        docker push miyohidecontainer.azurecr.io/runlog:$IMAGE_TAG

実行

あとはGitHub Actionsを起動します。適当なタグをつけてgit pushし、しばらく待つとAzure Container Registryにpushされていることが確認できました。

f:id:miyohide:20210704163538j:plain

Azure Container RegistryからAzure Web Appsへのデプロイを試みる

ここまでできたので、あとはAzure Web Appsへのデプロイをやってみようと思います。しかしながらAzure Web Appsの作成でDockerイメージを選択するときに以下の画面のようになり作成できませんでした。

f:id:miyohide:20210704163730j:plain

よくよくエラーメッセージを読むと、adminを有効にしないとダメっぽいです...。ここまでadminを有効化しないで頑張ってきたのに...

GitHub Actionsからのデプロイを試みる

というわけで、当初参考にした下記ドキュメントにある通り、GitHub Actionsで実行してみたいと思います。

docs.microsoft.com

適当にDockerアプリを作成したのち、GitHub Actionsで以下の処理を末尾に追加し、ドキュメントにあるようにAZURE_WEBAPP_PUBLISH_PROFILEも設定しておきます。

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'miyohiderailsapp'
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        images: miyohidecontainer.azurecr.io/runlog:$IMAGE_TAG

これで適当なタグをつけてgit pushすると、GitHub Actionsはうまく動いてくれたのですが、実際のアプリがうまく動いてくれず...

f:id:miyohide:20210704164525p:plain

デプロイメントセンターにあるログを見てみましたが、どうもDockerイメージをうまくpullできないようです。う〜ん...

f:id:miyohide:20210704164617p:plain

というわけで今日はここで時間切れ。残念...

macOSをクリーンインストールした(2021年6月版)

はじめに

最近、使っているMacBook Proの調子があまり良くなく、挙動がちょっと怪しい。Finderが突如落ちたり、バッテリーは十分あるはずなのに突如落ちたり。「OS Xは安定している」という触れ込みはどこに行ったのか?と思いつつ、よく訓練されているApple信者なのでmacOSクリーンインストールすることにしました。これでダメなら新しく買うかなあ。

手順の確認

Appleが「Mac を売却、譲渡、下取りに出す前にやっておくべきこと」というドキュメントを公開しているので、これに目を通しておきます。

support.apple.com

バックアップは言わずもがなで、Timemachineでバックアップは取れているはずですが、USBメモリとかで二重三重にバックアップを取ることにしました。

バックアップを取る対象は人それぞれかと思いますが、個人的には、

  • 書類フォルダー
  • Chromeの設定&パスワード
    • Googleアカウントで同期されているとはいえ、念の為
  • Day One(無課金)のデータエクスポート

を取りました。

クリーンインストールするには、「Intel 搭載の Mac を消去する方法」というドキュメントがありますので、これにも目を通しておきます(Intel Mac用。Appleシリコンはまた別)。

support.apple.com

実際にやってみる

自分の環境は、Catalina(10.15)だったので、ついでにBigSur(11)にしようとするために、「macOS を再インストールする方法」というドキュメントの下部に以下の記述があります。

起動時に「option + command + R」を使った場合は、たいていは、お使いの Mac と互換性があるうちでいちばん新しい macOS がインストールされます。

support.apple.com

この方法で最初はやってみましたが、1時間ぐらいしたあとにエラーコード「-2001F」が表示されて失敗したっぽいので、「command + R」でCatalina(10.15)をクリーンインストールした後にBigSur(11)をインストールしました。作業自身は、ネットワークのスピードにもよりますが、macOS再インストールは大体1時間ぐらい。BigSurインストールで1時間でした。

Macintosh HD - Dataが二つ?

BigSurインストール後、アプリの新規インストールをしようFinderを開くと、Macintosh HD - Dataというドライブが表示されます。あれ?これって何?と思いつつ、TimeMachineの設定をしようとすると

「バックアップを作成する2つのディスクに同じ名前がついています。"Macintosh HD - Data"というディスクのいずれか1つの名前を変更してください」

と出て、TimeMachineのバップアップに失敗します。これはやってしまったか...。とりあえず時間も遅かったことですし、頭を冷やすために一旦ここで作業を中断しました。

再度、再インストール

TimeMachineの設定ができないのはちょっと困りものなので、再度クリーンインストールをすることにします。

よくよく手順を確認すると、Macを消去するときに「ボリュームグループを消去」ではなく「消去」を押したのが間違った原因っぽい。今回は「ボリュームグループを消去」をちゃんとクリックして、Macintosh HD - Dataを削除します。また、ボリュームの削除ボタン (-) をクリックして、残っていた他のボリュームも削除しました。

BigSurをインストールした後だったので、Command + RでインストールされるmacOSもBigSur。ちょっとだけ手順が省略されました。

環境復旧

綺麗な環境になったので、復旧作業を実施します。「システム環境設定」から以下の設定を実施します。

  • 「キーボード」にて
    • 「キーボード」ページにて
      • 「キーのリポート」を一番「速い」に
      • 「リポート入力認識までの時間」を一番「短い」に
    • 「ユーザ辞書」ページにて
      • 「Touch Barに入力候補を表示」をオフに
        • これをしないと遅い
  • アクセシビリティ」にて
  • 「Dockとメニューバー」にて
    • 「画面上の位置」を「左」に

アプリケーションは今後徐々に整備していきますが、まずは以下のものを。おいおい増えてくるかなとは思います。

トラブル対応などに身軽に動きたいため、基本はあまりカスタマイズせずに使う方向で。

Chromeをインストール後、Googleアカウント同期を有効にすると、ブックマークやらパスワードなどが一瞬で復旧されました。いちいちバックアップ取らなくてもよかったかもしれませんが、バックアップは何重にも取ったほうが良いかなと思ったりもします。

これで安定してくれればいいんだけれども、安定しなきゃしないで新しくmacを買う理由ができるわけでそれはそれで良いかも。

Azure Web Appsお勉強メモ(2)Azure Web AppsにてデプロイするDockerイメージをGitHub Actionsで作成してAzure Container Registryにpushする

はじめに

先週からAzure Web AppsにRailsアプリを動かすことをやっています。動かすことは簡単にできたのですが、色々と手作業が多かったのでちょっとでも自動化しようと試してみました。

先週の内容は以下を参照してください。

Dockerイメージを作成する

手始めにDockerイメージを自動ビルドするようにします。DockerHubにはAutobuildという機能がありましたが、先日の発表で無料ではできなくなりました。

www.docker.com

そこで、GitHub Actionsを使って実装したいと思います。以下のドキュメントが参考になりました。

docs.microsoft.com

上のドキュメントではpushするごとにイメージを作りますが、GitのタグをDockerイメージのタグと紐付けるため、少し修正します。

name: Create Docker Image

on:
  push:
    tags:
      - v*

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - run: |
        IMAGE_TAG=$(echo ${{ github.ref }} | sed -e 's/refs\/tags\///')
        docker build -f Dockerfile.prd -t イメージ名:$IMAGE_TAG .

タグ名を取得するには、${{ github.ref }}を使えば良さそうです。詳しくは以下のドキュメントを参照してください。

docs.github.com

DockerイメージをAzure Container Registryにpushする

Dockerイメージが作れたので、Azure Container Registryにイメージをpushします。Azure Container Registryには複数の認証方式があるようです。

docs.microsoft.com

docker loginコマンドを使う場合、管理者ユーザを使うのがいちばんお手軽っぽいですが、CI/CD上で使うにはあまりよくない気がしたので、サービスプリンシパルを使う方式をとることにします。

サービスプリンシパルを使う場合については、丁寧なドキュメントがあるので、これに沿ったらできそうです。

docs.microsoft.com

なお、上記ドキュメント中にあるSP_PASSWD=$(az ad sp create-for-rbac --name http://$SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query password --output tsv)SP_PASSWD=$(az ad sp create-for-rbac --name http://$SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpush --query password --output tsv)にしないと、イメージのpushができないので注意です。

ただ、私がやったところ、SP_APP_ID=$(az ad sp show --id http://$SERVICE_PRINCIPAL_NAME --query appId --output tsv)を実行した時にERROR: Service principal 'xxxxxxx' doesn't existと出てしまいました。

f:id:miyohide:20210620185216j:plain

アプリケーションIDを取れば良いので、Azure ADの「アプリの登録」画面から当該のものを選択してアプリケーションIDを取得しました。

f:id:miyohide:20210620185720j:plain

これでdocker loginコマンドのユーザー名とパスワードに相当するものが得られたので、それを使ってログインしてpushすればOKです。テストとして手元でやってみると無事、pushできました。

f:id:miyohide:20210620190047p:plain