COBOLは事務処理系の処理を得意としております。また、基幹システムでも使用されていることもありますが、主に「事務処理用プログラムを効率的に開発できる」ことが最適となります。人間の言葉に近い文法でプログラムを記述できるため、比較的に習得が容易です。プログラミング入門として、入りやすい言語となります。

どんな業務に最適な言語なのか

ファイルの読み込みや書き込みが行えます。また、ファイルに大量のデータを書き込んだり、ソートやマージしてデータを並び替える作業を、高速で処理することが可能です。さらに事務処理で作成された帳票の出力も行うことができます。データを10進数で表現できるため、金額や各種データの確認を容易に行うこともできます。また、COBOLはWindowsやLinux／Unixなど、様々なコンピューターで利用できるため、移植性が極めて高い言語になります。

どんなことができるのか

COBOLは大きく分けて、4つの部で構成されます。それぞれの部には「見出し」があります。プログラムは「見出し部（IDENTIFICATION DIVISION）」から始まり、「環境部（ENVIRONMENT DIVISION）」、「データ部（DATA DIVISION）」、「手続き部（PROCEDURE DIVISION）」と処理を順に記載していきます。見出し部以外は省力可能で、部（DIVISION）の中にはいくつかの節（SECTION）や段落があります。 ・見出し部（IDENTIFICATION DIVISION）見出し部はCOBOLプログラムを識別するための部で、見出し部のみ節はありません。PROGRAM-IDには作成するプログラム名などの情報を記述します。<pre><code>IDENTIFICATION DIVISION.
PROGRAM-ID. [プログラム名など].</code></pre> ・環境部（ENVIRONMENT DIVISION）環境部はプログラムを適用するコンピュータ名や、環境変数などの情報の定義を行う構成節（CONFIGURATION SECTION）と、プログラムファイルを使用する場合に記述する入出力節（INPUT-OUTPUT SECTION）があります。<pre><code>ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT ファイル項目 ASSIGN TO 'ファイル名'</code></pre> ・データ部（DATA DIVISION）データ部はファイル節（FILE SECTION）、作業場所節（WORKING-STORAGE SECTION）、連絡節（LINKAGE SECTION）、通信節（COMMUNICATION SECTION）などから構成されます。主にプログラムで使用するデータ項目やファイルのレコードの宣言を行います。<pre><code>DATA DIVISION.
FILE SECTION.
FD ファイル項目.
01 ファイルレコード.
05 データ項目1 PIC 9(5).
05 データ項目2 PIC X(3).</code></pre>上記の例では、ファイル節にファイル記述項（FD）とファイルのレコード定義を行っています。 ・手続き部（PROCEDURE DIVISION）手続き部では主に各種処理を宣言したり、実行される手続きやエラーになった場合の処理内容を記述します。また、STOP文を記述すれば、プログラムを終了させることができます。<pre><code>PROCEDURE DIVISION.
MAIN SECTION.

実行処理...

STOP RUN.</code></pre>

プログラムの書き方

以上になります。古い言語と言われるCOBOLですが、まだ需要はあります。やってみると意外に簡単に読むことができますし、形式さえ覚えてしまえば処理も容易に記述が可能です。この機会に一度、触ってみるのはいかがでしょうか。構成やどのような場面で使われているかの概要のみでしたが、以下のサイトに詳しく書いてあります。 <blockquote>参考：<a href="https://www.cobol.co.jp/cobol-nyuumon/kiso/k001/" target="_blank" rel="noopener noreferrer">COBOL入門</a></blockquote>

最後に

COBOLの特徴

COBOL言語の概要

QlikViewは、連想データモデル技術を使用しており、ユーザーがデータの関係性を直感的に探索できるように設計されています。これにより、データの中から新たな洞察を得ることが容易になります。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/cb515e16b54244fcb640a55860b91244/image.png" alt="">引用先：<a href="https://www.infinityinsight.com/business-intelligence.php?id=57" target="_blank" rel="noopener noreferrer">Infinity Insight - データモデル設計</a>

連想データモデル

QlikViewは予めデータを圧縮してメモリ内に保持し、高速なデータ処理と分析を実現します。その為、大規模なデータセットの場合でも、データソースに直接接続して効率的に処理できます。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/39a28e463b9e481d961a328349ee821a/image.png" alt="">引用先：<a href="https://www.hitachi-systems.com/solution/s108/qlikview/" target="_blank" rel="noopener noreferrer">インメモリ型BIツール 「QlikView」（クリックビュー）：株式会社日立システムズ (hitachi-systems.com)</a>

インメモリ技術

ユーザーはインタラクティブなダッシュボードを迅速に作成し、データの視覚化や分析を行うことができます。これにより、ビジネスの意思決定をサポートします。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/781d674970834db79288cd7dd3c1075f/image.png" alt="">引用先：<a href="https://knowledge.insight-lab.co.jp/qlikview/knowledge/loadscript/set-period-of-analysis" target="_blank" rel="noopener noreferrer">QlikViewで分析期間の選択を設定する方法 (insight-lab.co.jp)</a>

インタラクティブなダッシュボード

QlikViewは、ユーザーが自分自身でデータを探索し、必要な情報を見つけ出すことができるように設計されています。事前に定義された検索ルーチンに頼ることなく、自由にデータを選択して分析できます。

ユーザー主導の分析

QlikViewの主な特徴

企業の経営層やマネージャーが、リアルタイムでビジネスの状況を把握し、迅速な意思決定を行うために利用されます。

ビジネスインテリジェンス

データサイエンティストやアナリストが、複雑なデータセットを分析し、トレンドやパターンを発見するために使用します。

データ分析

定期的なレポートやアドホックなレポートを簡単に作成し、共有することができます。

レポート作成

利用シーン

QlikViewの概要について

まず、<code>Gemfile</code> に以下の行を追加します。<pre><code>gem 'omniauth'
gem 'omniauth-openid-connect'</code></pre> その後、以下のコマンドを実行して gem をインストールします。<pre><code>bash
bundle install</code></pre>

OmniAuth gem のインストール

<code>.env</code> に <code>CLIENT_ID</code> , <code>CLIENT_SECRET</code> を記載します。<pre><code>COGNITO_DOMAIN= 'https://aaaa.com'
CLIENT_ID= 'xxxxx'
CLIENT_SECRET= 'yyyy'</code></pre> <code>COGNITO_DOMAIN</code>: Cognito のドメイン<code>CLIENT_ID</code>: Cognito のクライアント ID<code>CLIENT_SECRET</code>: Cognito のクライアントシークレット

環境変数の設定

次に、<code>config/initializers/omniauth.rb</code> に以下の設定を追加します。<pre><code>Rails.application.config.middleware.use OmniAuth::Builder do
&nbsp; provider :openid_connect, {
&nbsp; &nbsp; name: :cognito,
&nbsp; &nbsp; scope: [:openid, :email, :profile],
&nbsp; &nbsp; response_type: :code,
&nbsp; &nbsp; discovery: true,
&nbsp; &nbsp; client_options: {
&nbsp; &nbsp; &nbsp; port: 443,
&nbsp; &nbsp; &nbsp; scheme: 'https',
&nbsp; &nbsp; &nbsp; host: ENV['COGNITO_DOMAIN'],
&nbsp; &nbsp; &nbsp; identifier: ENV['CLIENT_ID'],
&nbsp; &nbsp; &nbsp; secret: ENV['CLIENT_SECRET'],
&nbsp; &nbsp; &nbsp; redirect_uri: 'http://localhost:3000/auth/cognito/callback'
&nbsp; &nbsp; }
&nbsp; }
end</code></pre> <code>redirect_uri</code>: 認証後のリダイレクト先 (ローカル環境の場合: <code>http://localhost:3000/auth/cognito/callback</code>)

config の設定

<code>app/sesson_controller.rb</code> を設定します。<pre><code>class SessionsController &lt; ApplicationController
&nbsp; def create
 reset_session
&nbsp; &nbsp; auth = request.env['omniauth.auth']
&nbsp; &nbsp; user = User.find_or_create_by(uid: auth.uid, provider: auth.provider) do |u|
&nbsp; &nbsp; &nbsp; u.email = auth.info.email
&nbsp; &nbsp; &nbsp; u.name = auth.info.name
&nbsp; &nbsp; end

&nbsp; &nbsp; session[:user_id] = user.id
&nbsp; &nbsp; redirect_to root_path, notice: 'Signed in!'
&nbsp; end

&nbsp; def destroy
&nbsp; &nbsp; reset_session
&nbsp; &nbsp; redirect_to root_path, notice: 'Signed out!'
&nbsp; end

&nbsp; def failure
&nbsp; &nbsp; redirect_to root_path, alert: 'Authentication failed, please try again.'
&nbsp; end
end</code></pre>

コントローラの設定

ルーティングに OmniAuth のコールバック URL を追加するために、<code>config/routes.rb</code> を編集します。<pre><code>Rails.application.routes.draw do
&nbsp; get '/auth/:provider/callback', to: 'sessions#create'
&nbsp; get '/auth/failure', to: 'sessions#failure'
&nbsp; delete '/logout', to: 'sessions#destroy'

&nbsp; root 'home#index'
end</code></pre>

ルーティングの設定

ユーザー情報を保存するための <code>User</code> モデルを作成します。<pre><code>rails generate model User provider:string uid:string name:string email:string
rails db:migrate</code></pre>

User モデルの設定

ログインボタンやログアウトリンクをビューに追加します。例えば、<code>app/views/home/index.html.erb</code> に以下のように記述します。<pre><code>&lt;% if session[:user_id] %&gt;
&nbsp; &lt;p&gt;Signed in as &lt;%= current_user.name %&gt;&lt;/p&gt;
&nbsp; &lt;%= link_to 'Sign out', logout_path, method: :delete %&gt;
&lt;% else %&gt;
&nbsp; &lt;%= link_to 'Sign in with Cognito', '/auth/cognito' %&gt;
&lt;% end %&gt;</code></pre> <code>current_user</code> ヘルパーを追加するために、<code>app/controllers/application_controller.rb</code> に以下のメソッドを追加します。<pre><code>class ApplicationController &lt; ActionController::Base
&nbsp; helper_method :current_user

&nbsp; def current_user
&nbsp; &nbsp; @current_user ||= User.find(session[:user_id]) if session[:user_id]
&nbsp; end
end</code></pre>

ビューの設定

以上で、SSO認証(openid_connect) の実装が完了します。簡単に認証が実装できていいですね！

実装

AWS Cognito を使って SSO 認証してみた

今使っている gem のバージョンと最新の gem のバージョンがどれくらい異なっているか確認します。下記コマンドで、最新でない gem のリストが取得できますので、確認してみましょう。<pre><code>bundle outdated</code></pre>

gem の状態を確認する

rubocop を使って、記述に問題がないかを確認します。また、 rspec を使って自動テストがすべて通ることを確認します。

コードの状態を最新に保つ

Ruby on Rails アップデート手順

下記コマンドで、 develop, test の gem をアップデートします。<pre><code>bundle update -g development -g test</code></pre>

develop, test の gem をアップデートする

<code>bundle outdated</code>の結果を見て、メジャーバージョン番号が変わっているgemを1つずつ慎重にアップデートします。<pre><code>bundle update [gem]</code></pre><code>bundle update [gem]</code> の実行結果が依存関係でエラーになる場合、最新バージョンではなく、古いバージョンを指定するなどして、エラーが発生しないようにします。どうしても依存関係エラーが発生する場合は、バージョンアップをスキップすることも選択肢にいれましょう。

gem のアップデートをする

rubocop で記述に問題ないか確認したり、rspec で自動テストを実行したり、実際に画面を操作したりして、今まで通り使えているかどうかを確認します。

動作確認

Ruby on Rails のマイナーバージョン、またはメジャーバージョンを上げる前に、パッチバージョンを最新に上げます。たとえば、Rails 6.0.5.9 を Rails 6.1 に上げる前に、Rails 6.0.6.1 に上げます。<pre><code>Gemfile
 # Railsのパッチバージョンを上げる
-gem 'rails', '6.0.5.9'
+gem 'rails', '6.0.6'</code></pre> <pre><code>bundle update rails</code></pre>

rails gem 最新のパッチバージョンに更新する

rails gem メジャーバージョン、もしくはマイナーバージョンを更新します。<pre><code>Gemfile
 # Railsのパッチバージョンを上げる
-gem 'rails', '6.0.6'
+gem 'rails', '6.1.7.8'</code></pre> <pre><code>bundle update rails</code></pre> エラーが発生する場合は、エラーメッセージをよく見て、依存関係に問題がないかよく確認します。<code>~&gt; </code> がついている部分など、バージョンを手動で上げないとエラーになったりします。

rails gem メジャーバージョン、もしくはマイナーバージョンを更新する

<code>rails app:update</code>　を実行します。<pre><code>rails app:update</code></pre> <blockquote>上書き更新されるファイルは次のように対応方法を質問されるので、 Y/n/a/q/d/hのいずれかのキーを入力します。</blockquote><pre><code>Overwrite /myapp/config/application.rb? (enter "h" for help) [Ynaqdh]</code></pre> <blockquote>各キーの意味は次の通りです。</blockquote><pre><code>Y - Yes。上書き実行
n - No。上書きしない
a - All。このファイル以降の全ファイルを上書き
q - Quit。処理中断
d - Diff。新旧ファイルのdiffを表示
h - Help。入力する各キーの意味を表示</code></pre>

rails app:update の実行

<blockquote><code>rails app:update</code> にて、Y で上書き実行すると、それまで使っていた重要な設定が失われることがあります。 その場合は git の diff をチェックしながら、上書きされて消えてしまった設定を自力で戻していきます。</blockquote>

重要な設定を元に戻す

<blockquote>新しいバージョンの Ruby on Rails では、前のバージョンとデフォルト設定が異なるものがあります。 <code>app:update</code>タスクでは、アプリケーションを新しいデフォルト設定に1つずつアップグレードできるように、 <code>config/initializers/newframeworkdefaults_X.Y.rb</code>ファイルが作成されます。 このファイル内のコメントを解除して、新しいデフォルト設定を有効にする必要があります。 アプリケーションを新しいデフォルト設定で動かせる準備が整ったら、 このファイルを削除して<code>config.load_defaults</code>の値を反映させてやります。</blockquote>

フレームワークのデフォルトを設定する

<blockquote><code>app:update</code>コマンドを実行しても、Gemfile のようにまったく更新されないファイルもあります。 ですが、<code>rails new</code>した直後の Gemfile を比較すると、デフォルトでインストールされる gem の種類やバージョンには違いがあります。 Ruby on Railsのバージョンを上げたのであれば、こういった部分も新しいRailsに合わせておく方が安心です。</blockquote> https://railsdiff.org/6.0.6.1/6.1.7.8

新しく追加された gem を確認する

rubocop で記述に問題ないか確認したり、rspec で自動テストを実行したり、実際に画面を操作したりして、今まで通り使えているかどうかを確認します。﻿

繰り返し実施

繰り返し実施しているなかで、Ruby on Rails アプリで使用している Ruby のバージョンが古い場合は、最新にする必要があります。<blockquote>Rubyは後方互換性をかなり重視しているので、バージョンを上げてもトラブルが起きる可能性は低いはずです。 ですが、それでもゼロとは言えないので、Rubyのバージョンを上げたらテストがすべてパスすることを確認してください。</blockquote>

ruby のバージョンを上げる

バージョンアップはこまめに行おう

Ruby On Rails のアップデート手順

docker-compose.yml に簡単な Docker Compose のサンプルを書いてあげます。<pre><code>version: '3'
services:
 db:
 image: mysql:5.7
 environment:
 MYSQL_ROOT_PASSWORD: password
 MYSQL_DATABASE: mydb
 web:
 image: httpd:2.4
 ports:
 - "8081:80"
 volumes:
 - ./public-html:/usr/local/apache2/htdocs/</code></pre>

Docker Compose について

Docker Compose を起動します。<pre><code>docker compose up</code></pre>

Docker Compose の起動

Docker の立ち上がっている Container を確認します。この時の "httpd:2.4" の CONTAINER ID をコピーしときます。<pre><code>docker ps
CONTAINER ID&nbsp; &nbsp;IMAGE&nbsp; &nbsp; &nbsp; &nbsp;COMMAND&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CREATED&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; STATUS&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PORTS&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; NAMES
2d6d95e99d90&nbsp; &nbsp;mysql:5.7&nbsp; &nbsp;"docker-entrypoint.s…"&nbsp; &nbsp;About a minute ago&nbsp; &nbsp;Up 38 seconds&nbsp; &nbsp;3306/tcp, 33060/tcp&nbsp; &nbsp; docker_sample-db-1
9b9d3fdb400c&nbsp; &nbsp;httpd:2.4&nbsp; &nbsp;"httpd-foreground"&nbsp; &nbsp; &nbsp; &nbsp; About a minute ago&nbsp; &nbsp;Up 38 seconds&nbsp; &nbsp;0.0.0.0:8081-&gt;80/tcp&nbsp; &nbsp;docker_sample-web-1</code></pre>

Docker Container の確認

Docker Container に入るには次のコマンドを実行します。<pre><code>docker exec -it 9b9d3fdb400c bash
root@9b9d3fdb400c:/usr/local/apache2#&nbsp;</code></pre> ここからは、Container 内の設定値を確認するなり、ログを見るなり好きにできます。ということで、簡単ではありますが、Docker Container に入ってみました。

Docker Container に入る

Docker Container の入りについて

Docker Container に入ってみた

さっそくですが本題のMakefileをお見せします。<code>Makefile</code>というファイルをプロジェクトのルートディレクトリに作成し、以下の内容を記載します。<pre><code># makeを打った時のコマンド
.DEFAULT_GOAL := help


.PHONY: up down build ps api mysql help


up: ## コンテナ起動
	docker-compose up
down: ## コンテナ停止
	docker-compose down
build: ## コンテナビルド
	docker-compose build
ps: ## コンテナのステータス確認
	docker-compose ps
project-api: ## project-apiコンテナに入る
	docker-compose exec -it project-api /bin/bash
mysql: ## mysqlコンテナに入る
	docker-compose exec -it mysql /bin/bash


help: ## ヘルプ
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | \
		awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'

</code></pre> 作成したらMakefileと同じ階層で<code>make</code>もしくは<code>make help</code>コマンドを実行して、ヘルプが使用可能なコマンドとそれぞれのコマンドの説明が表示されることを確認しましょう。<pre><code>$ make
up&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; コンテナ起動
down&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; コンテナ停止
build&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; コンテナビルド
ps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;コンテナのステータス確認
project-api&nbsp; &nbsp; &nbsp; &nbsp; manager-apiコンテナに入る
mysql &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mysqlコンテナに入る
help&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ヘルプ</code></pre>

Makefileを作成する

使い方は他のコマンドと同じです。<code>$ make ターゲット</code>という形式でターミナルに入力して実行するだけで使えます。 例えば、<code>$ docker compose up</code>をしたい場合には、ターミナルに<code>$ make up</code>と入力して実行します。同様にコンテナを停止する場合は<code>$ make down</code>、ビルドする場合は<code>$ make build</code>で実行できます。

Makefileの使用方法

Makefile内の各項目について解説していきます。 <h3 id="h1eaa05f1fe">.DEFAULT_GOAL</h3>コマンドラインでターゲットが指定されなかった場合に使用されるデフォルトの動作を定義します。今回はコマンドの説明を表示するために help をデフォルトのターゲットとして設定しています。 <h3 id="hb88a63c6c5">.PHONY</h3>ターゲットと同名のファイルが作成された場合にコマンドが正しく動作しなくなることを回避するために定義します。 例えば、cleanというターゲットがあるとします。<pre><code>clean:
	rm *.o temp</code></pre> このままの状態だと、同じディレクトリ内にcleanという名前のファイルが作成された場合に、<code>$ make clean</code>コマンドが正常に動作しなくなります。このような名前の衝突を避けるため、.PHONYにcleanターゲットを記載する必要があります。<pre><code>.PHONY: clean
clean:
&nbsp;&nbsp;&nbsp;&nbsp;rm *.o temp</code></pre> <h3 id="h0c03e9cae9">up, down, build, ps ターゲット</h3>それぞれdocker-composeのup, down, build, psコマンドを実行します。up: がターゲット、その下の行が実際に実行するコマンドという構成です。 <h3 id="h390dd1d079">project-api, mysql ターゲット</h3>APIサーバー用のコンテナやmysqlコンテナに入るためのdocker-compose execコマンドを実行します。コマンドが長いのでよく設定していますが意外と便利です。ご自身のプロジェクトのコンテナ名に書き換えて使用してください。<pre><code>&lt;コンテナ名&gt;:
	docker-compose exec -it &lt;コンテナ名&gt; /bin/bash</code></pre> <h3 id="h6487ef0f90">help ターゲット</h3>Makefile内のターゲットと説明を出力するために設定しています。ファイル内で<code>## コンテナ起動</code>のようにシャープ2つの後に続けて説明を記載しておくと以下のように説明として出力されます。<pre><code>$ make
up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;コンテナ起動
down&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;コンテナ停止
build&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;コンテナビルド
ps&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;コンテナのステータス確認
project-api&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;manager-apiコンテナに入る
mysql&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mysqlコンテナに入る
help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ヘルプ</code></pre>

Makefileの解説

本題

いかがでしたでしょうか。他にもテスト用のコマンドなどを作成してみてもいいかもしれないですね。Makefileを作成してmakeコマンドが使えるようになると開発の効率がかなり上がるので、皆さんもぜひやってみてください。 参考：・<a href="https://www.gnu.org/software/make/manual/html_node/index.html" target="_blank" rel="noopener noreferrer">Top (GNU make)</a>・<a href="https://qiita.com/sun33/items/d728bc9ec27129b53e17" target="_blank" rel="noopener noreferrer">docker-composeを詠唱する黒魔術「Makefile」入門 #Docker - Qiita</a>・<a href="https://zenn.dev/yuki_tu/articles/ad7f95b0b2482e" target="_blank" rel="noopener noreferrer">Makefileで開発効率をあげよう！</a>

まとめ

5分で作る「Makefile」 for docker-compose

今回は<a href="https://docs.pact.io/pact_nirvana/step_5" target="_blank" rel="noopener noreferrer">こちら</a>の構成を作成することをゴールとします。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ae228997ae7a4bd4968001c45a18a40e/image.png" alt="">※厳密には上記の構成とは少し異なり、PRパイプラインには組み込みません。コンシューマ・プロバイダ共にデプロイパイプラインに組み込みます。今回実装するのは以下の流れです。 <ol><li>コンシューマ側のパイプライン<ol><li>mainブランチにコミットで発火</li><li>Pactテスト実行</li><li>テストが通ったらBrokerに契約ファイルをpublish</li><li>デプロイ</li></ol></li><li>プロバイダ側のパイプライン<ol><li>mainブランチにコミットで発火</li><li>Brokerから契約ファイルをimport</li><li>Pactテスト実行</li><li>テスト結果をBrokerにpublish</li><li>テストが通ったらデプロイ</li></ol></li></ol>

今回のゴール

前回の記事を読んでいただけたらおわかりのように、コンシューマ側でテストに成功すると契約ファイル（JSON）が作成され、それをプロバイダ側に連携する必要がありました。 そこで前回はローカルで直接ファイルをコピペして置いていましたが、CI/CDに組み込むにはリモートのサーバにファイルを置く必要があります。単にファイルを共有するだけであれば、S3で事足ります。ただ、当然のことながらS3だと本当にファイルを共有することしかできないです。 Pactではコンシューマとプロバイダの間を取り持つBrokerを提供しています。これを使うと、単にJSONを共有するだけでなく、<a href="https://docs.pact.io/pact_broker#why-do-i-need-one" target="_blank" rel="noopener noreferrer">色々便利な使い方</a>ができるようです。なのでせっかくコンシューマ駆動を導入するなら、個人的には積極的にBrokerも使っていきたいです。 Pact BrokerにはRuby製アプリ、Docker、Pact Flow（インフラ込み）の3種類があります。前の2つは自分でホスティングする必要があるので、大きく分類するなら2種類ですね。<a href="https://pactflow.io/pricing/" target="_blank" rel="noopener noreferrer">Pact Flowの料金</a>は無料プランもありますが、制約が色々あり（特に2 integrationsが気になります。2つのサービス間までしか利用できないということでしょうか？）有料プランになると万単位のお金がかかるので、実際に導入するのはなかなかハードルが高いと思います。というわけで今回は、Dockerを自分でホスティングする方向で検討しました。 次にDockerをどこに配置するかですが、個人利用でたまに動かす程度なので今回はシンプルにEC2 on Dockerの構成でグローバルIPを付与して直接外部からアクセスできるようにしました。

Broker

Brokerにpublishする方法(Pact Broker CLI)ですが、Dockerイメージ、Ruby製のスタンドアロン実行可能ファイル、NodeJS製のコマンドがあります。NodeJSであればビルド環境にそのまま組み込めるため楽かなと思ったのですが、CodeBuildで実行したところ以下のように依存関係でエラーが出て解決に時間がかかりそうだったので断念しました。<pre><code>[Container] 2024/07/22 13:29:50.176274 Running command npm run test:publish
&gt; auth0-next-custom@0.1.0 test:publish
&gt; ./node_modules/.bin/pact-broker publish ./pacts --consumer-app-version=$(git rev-parse HEAD) --auto-detect-version-properties --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
XXXXXXXXXXXXXXXXX/auth0-next-custom/node_modules/@pact-foundation/pact-cli/standalone/linux-x64-2.4.6/pact/lib/ruby/bin.real/ruby: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
[Container] 2024/07/22 13:29:50.529456 Command did not exit successfully npm run test:publish exit status 127
[Container] 2024/07/22 13:29:50.534863 Phase complete: PRE_BUILD State: FAILED_WITH_ABORT
[Container] 2024/07/22 13:29:50.534880 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: npm run test:publish. Reason: exit status 127</code></pre> したがって環境起因の問題が起こりにくいDockerイメージを使うことにしました。 ところで、コンシューマはNextJSアプリであり、Amplifyでホスティングしています。なのでCI/CDもAmplifyで行っていました。そこで問題なのはAmplifyのCI/CDでは<a href="https://zenn.dev/ncdc/articles/f959131cf5f4b5" target="_blank" rel="noopener noreferrer">Dockerを動かすことはできない</a>ようです。調べたところ、AmplifyのCI/CDをトリガーすることは可能なので、<a href="https://qiita.com/eyuta/items/ababeedc051690b4cc15" target="_blank" rel="noopener noreferrer">こちら</a>を参考にCodeBuildから呼び出すようにしました。なお、CodeBuildからDockerを呼び出す場合、<a href="https://zenn.dev/ymiz/articles/0b81d72c66d1e7" target="_blank" rel="noopener noreferrer">特権を付与</a>する必要があるので注意が必要です。 そうすると逆にAmplifyの自動デプロイが邪魔になってくるので、設定をオフにしました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/766e266e9c85438b9e76020cba9d1f1b/Screenshot%20from%202024-07-23%2023-45-14.png" alt=""> あとは、publishする際アプリバージョンを指定する必要がありますが、Gitの<a href="https://docs.pact.io/getting_started/versioning_in_the_pact_broker" target="_blank" rel="noopener noreferrer">コミットハッシュが推奨</a>なのでその場合はCodeBuildからGitコマンドを実行する必要があります。そのためソースステージの出力アーティファクトで完全クローンを選択する必要があるのでご注意ください。また、リポジトリがGitHubを利用している場合は完全クローンするための<a href="https://docs.aws.amazon.com/codepipeline/latest/userguide/troubleshooting.html#codebuild-role-connections" target="_blank" rel="noopener noreferrer">権限</a>をCodeBuildのサービスロールに付与する必要もあります。権限を付与するために必要なConnectionArnはCodePipelineのソースステージの「詳細を表示」から確認できます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/66bcddbabb294227990ab933b6b641c7/Screenshot%20from%202024-07-24%2000-09-05.png" alt=""> コンシューマ側のCI/CDのための修正は以下のようになりました。<pre><code>diff --git a/buildspec.yml b/buildspec.yml
new file mode 100644
index 0000000..7d35759
--- /dev/null
+++ b/buildspec.yml
@@ -0,0 +1,16 @@
+version: 0.2
+
+phases:
+&nbsp; install:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - npm ci
+&nbsp; pre_build:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - npm run test
+&nbsp; &nbsp; &nbsp; - npm run publish
+&nbsp; build:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - aws amplify start-job --app-id XXXXXXXXXX --branch-name main --job-type RELEASE
diff --git a/package.json b/package.json
index 3d79d38..22c0710 100644
--- a/package.json
+++ b/package.json
@@ -6,7 +6,9 @@
&nbsp; &nbsp; &nbsp;"dev": "next dev",
&nbsp; &nbsp; &nbsp;"build": "next build",
&nbsp; &nbsp; &nbsp;"start": "next start",
-&nbsp; &nbsp; "lint": "next lint"
+&nbsp; &nbsp; "lint": "next lint",
+&nbsp; &nbsp; "test": "jest",
+&nbsp; &nbsp; "publish": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest publish ${PWD}/pacts --consumer-app-version=$(git rev-parse HEAD) --branch=$(git branch --contains | cut -d ' ' -f 2) --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
&nbsp; &nbsp;},
&nbsp; &nbsp;"dependencies": {
&nbsp; &nbsp; &nbsp;"@auth0/nextjs-auth0": "^3.5.0",</code></pre>

Consumer

Providerはpythonで実装されていてAPI Gateway+Lambda構成でCodeBuildでデプロイしていました。Consumerの方はtestとpublishを別々に実行する必要がありましたが、<a href="https://github.com/reecetech/pactman" target="_blank" rel="noopener noreferrer">pactman</a>の場合はtestの際のオプションの<code>--pact-broker-url</code>でURLを指定することでBrokerから契約ファイルをダウンロードし、<code>--pact-publish-results</code>で結果をアップロードすることが可能です。こちらもコンシューマ同様Gitのコミットハッシュでバージョンを指定する場合はそのための設定が必要になってきます。ですがDockerを使う必要がない分簡単で、CI/CDのための差分は以下のようになりました。<pre><code>diff --git a/buildspec.yml b/buildspec.yml
index 09cffeb..216944e 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -1,15 +1,22 @@
&nbsp;version: 0.2
&nbsp;
&nbsp;phases:
+&nbsp; install:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - pip install -r requirements.txt
+
&nbsp; &nbsp;pre_build:
&nbsp; &nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp; &nbsp;commands:
&nbsp; &nbsp; &nbsp; &nbsp;- aws s3 cp s3://XXXXXXXXXXXXXXXXXXXXXXXXX/google_login_back/dev.json .chalice/deployed/dev.json || true
+&nbsp; &nbsp; &nbsp; - ./test.sh
+
&nbsp; &nbsp;build:
&nbsp; &nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp; &nbsp;commands:
-&nbsp; &nbsp; &nbsp; - pip install -r requirements.txt
&nbsp; &nbsp; &nbsp; &nbsp;- chalice deploy
+
&nbsp; &nbsp;post_build:
&nbsp; &nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp; &nbsp;commands:
diff --git a/docker-compose.yml b/docker-compose.yml
index cca3044..815fa32 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -11,7 +11,8 @@ services:
&nbsp; &nbsp; &nbsp;environment:
&nbsp; &nbsp; &nbsp; &nbsp;DB_ENDPOINT: http://dynamo:8000
&nbsp; &nbsp; &nbsp; &nbsp;TEST_PORT: 8008
-&nbsp; &nbsp; &nbsp; PYTEST_ADDOPTS: "-v --pact-files=pacts/*.json"
+&nbsp; &nbsp; &nbsp; PACT_BROKER_BASE_URL: ${PACT_BROKER_BASE_URL}
+&nbsp; &nbsp; &nbsp; PACT_BROKER_AUTH: ${PACT_BROKER_USERNAME}:${PACT_BROKER_PASSWORD}
&nbsp; &nbsp; &nbsp;command: chalice local --host=0.0.0.0 --port=8002
&nbsp; &nbsp;dynamo:
&nbsp; &nbsp; &nbsp;image: amazon/dynamodb-local
diff --git a/test.sh b/test.sh
new file mode 100755
index 0000000..2bca591
--- /dev/null
+++ b/test.sh
@@ -0,0 +1,5 @@
+#!/bin/bash
+
+GIT_VERSION=$(git rev-parse HEAD)
+
+pytest tests/ -v --pact-broker-url=${PACT_BROKER_BASE_URL} --pact-provider-name=google-login-back --pact-publish-results --pact-provider-version=${GIT_VERSION}</code></pre> BrokerでBasic認証している場合は<code>PACT_BROKER_AUTH</code>環境変数に設定することで通すことが可能です。（もしくはURLに付与するやり方もあるようです）

Provider

対応内容

今回はPact Brokerを使って契約ファイルをコンシューマ・プロバイダ間で共有し、CI/CDにPactの検証を組み込むまでを行いました。気をつけるポイントは以下です。<ul><li>Broker<ul><li>インフラをどうするか。ユースケースにもよるが一旦動けばいいレベルならEC2 on Dockerが早い＆安い＆楽？</li></ul></li><li>Consumer<ul><li>testとは別にpublishコマンドを叩く必要がある</li><li>Pact CLIはDockerが無難。CodeBuildに組み込むなら特権が必要</li><li>Consumer=フロントエンドかつAmplifyを使っているならデプロイをトリガーするコマンドが使える</li><li>Gitコマンドを打つなら完全クローンで</li></ul></li><li>Provider<ul><li>testの中でpublishもしてくれる(pactmanの場合)</li><li>Gitコマンドを打つなら完全クローンで</li></ul></li></ul>

現状のパイプラインだと、コンシューマ側で契約を変更した際に、変更後もプロバイダが引き続きサポートしているかどうかがわからないという問題があります。もしサポートしていなかった場合、そのままデプロイされてしまい、不具合が発生する可能性があります。あるべきとしては、コンシューマ側で契約を変更したら、プロバイダが契約を満たすかどうかをチェックしに行くようにコンシューマ側のパイプラインを組む必要があります。こちらは今後の課題として、でき次第また記事にしようと思います。

課題

さいごに

コンシューマ駆動契約テストに入門してみた〜CI/CD編〜

Hello Worldの本題に入る前に、まずは前提としてコンシューマ駆動契約テストとは何かについて説明させてください（自分の理解の為）。 マイクロサービスアーキテクチャを採用した場合に、特定のサービスAが、複数のサービスB,C,D...から呼ばれる、というような依存関係が生まれます。その場合に、例えばサービスBのために新しい機能をサービスAに実装したとして、サービスAをリリースする際に、サービスBが正しく動くのはもちろんですが他のサービスC,D...も正しく動くことが保証されなければなりません。そこで、サービスBだけでなくサービスC,D...についても結合テストを全て網羅しなければならない、となると非常にリリースのコストが大きくなってしまいます。これでは、マイクロサービスの本来のメリットである、サービス単位の素早いリリースが実現不可能になってしまいます。 コンシューマ駆動契約テストでは、コンシューマ（＝呼び出す側）がプロバイダ（＝呼び出される側）に対して、どんな状況でどんなリクエストを投げた場合に、どんな応答をしてほしいかという「契約」を発行します。具体的には、コンシューマ側で「コラボレーターオブジェクト（APIを呼び出し、結果をオブジェクトにエンコードする層）に対するテストコード」という形で実装します。このテストを実行し成功すると、（Pactの場合はJSON形式の）「契約」が記載されたファイルが出力されます。この契約ファイルをプロバイダに（何らかの方法で）共有し、プロバイダ側で契約が正しく守られているかを（統合テストの形で）検証する、というのが一連の流れです。 コンシューマ駆動契約テストの特徴はその名の通り、コンシューマが自身の求めるインターフェースを率先して規定することです。コンシューマB,C,Dがそれぞれ自身が必要とする最低限のインターフェースを規定し、プロバイダAはそれら全ての契約を満たすように実装できて初めて、プロバイダAの変更をリリースできます。これにより、リリースプロセスを素早く回すことが可能になります。

前提知識ーコンシューマ駆動契約テストとはなんぞや

御託はこれくらいにして、そろそろ実装してみます。前提として、今回テストするAPIの仕様は以下の通りです。<ul><li>エンドポイント: <code>/ping</code></li><li>レスポンス: <code>{"message": "pong"}</code></li></ul>これ以上ないほどシンプルですね。 以前短い文章を投稿する簡単なデモアプリを作成したので、それを流用して上記のエンドポイントを新たに生やします。デモアプリに関しては<a href="https://build.yoku.co.jp/articles/yvg_k7jpwezo" target="_blank" rel="noopener noreferrer">別のテーマで過去に記事にしている</a>ので、興味のある方はそちらをご覧くださいmm

前提

フロントエンドの実装は以下のようになりました。テストコードライブラリにはJestを使用しています。<pre><code>diff --git a/.gitignore b/.gitignore
index fd3dbb5..afa95f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,6 +8,7 @@
&nbsp;
&nbsp;# testing
&nbsp;/coverage
+/pacts
&nbsp;
&nbsp;# next.js
&nbsp;/.next/
diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
new file mode 100644
index 0000000..24979c6
--- /dev/null
+++ b/app/api/microposts/service.ts
@@ -0,0 +1,11 @@
+export default function MicropostService(baseUrl: string) {
+&nbsp; &nbsp; const ping = async (): Promise&lt;{message: string}&gt; =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; const res = await fetch(`${baseUrl}/ping`, {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; headers: {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Content-Type": "application/json",
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; &nbsp; &nbsp; });
+&nbsp; &nbsp; &nbsp; &nbsp; return res.json();
+&nbsp; &nbsp; }
+&nbsp; &nbsp; return {ping}
+}
\ No newline at end of file
diff --git a/jest.config.js b/jest.config.js
new file mode 100644
index 0000000..7113c5a
--- /dev/null
+++ b/jest.config.js
@@ -0,0 +1,8 @@
+/** @type {import('ts-jest/dist/types').InitialOptionsTsJest} */
+module.exports = {
+&nbsp; preset: 'ts-jest',
+&nbsp; testEnvironment: 'node',
+&nbsp; moduleNameMapper: {
+&nbsp; &nbsp; '^@/app/(.*)$': '&lt;rootDir&gt;/app/$1'
+&nbsp; },
+};
\ No newline at end of file
diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
new file mode 100644
index 0000000..330712b
--- /dev/null
+++ b/tests/api.pact.spec.ts
@@ -0,0 +1,33 @@
+import MicropostService from "@/app/api/microposts/service";
+import { MatchersV3, PactV3 } from "@pact-foundation/pact";
+import path from "path";
+
+const provider = new PactV3({
+&nbsp; &nbsp; dir: path.resolve(process.cwd(), 'pacts'),
+&nbsp; &nbsp; consumer: 'auth0-next-custom',
+&nbsp; &nbsp; provider: 'google-login-back'
+});
+
+describe('GET /ping', () =&gt; {
+&nbsp; &nbsp; it('200レスポンス(pong)を返すこと', async () =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; provider.addInteraction({
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; states: [{description: 'pongレスポンスに成功する場合'}],
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; uponReceiving: 'pingリクエストを送信する',
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; withRequest: {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; method: 'GET',
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; path: '/ping',
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; willRespondWith: {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; status: 200,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; headers: {'Content-Type': 'application/json'},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; body: MatchersV3.equal({message: 'pong'}),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; &nbsp; &nbsp; });
+
+&nbsp; &nbsp; &nbsp; &nbsp; await provider.executeTest(async (mockserver) =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const service = MicropostService(mockserver.url);
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const response = await service.ping();
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; expect(response.message).toStrictEqual('pong');
+&nbsp; &nbsp; &nbsp; &nbsp; })
+&nbsp; &nbsp; })
+});</code></pre> Pactは記載した契約の通りに動作してくれるモックサーバを提供してくれます。今回の実装ではAPIサービスの名前が<code>MicropostService</code>となっていますがこれは将来的に投稿に関するAPIをサポートしたいという意味であまり気にしないでください。テストを実行すると<code>/pacts</code>に契約ファイル(JSON)が置かれます。

フロントエンド（コンシューマ）

上記を実行したところ以下のファイルが生成されていました。 pacts/auth0-next-custom-google-login-back.json<pre><code>{
 "consumer": {
 "name": "auth0-next-custom"
 },
 "interactions": [
 {
 "description": "pingリクエストを送信する",
 "providerStates": [
 {
 "name": "pongレスポンスに成功する場合"
 }
 ],
 "request": {
 "method": "GET",
 "path": "/ping"
 },
 "response": {
 "body": {
 "message": "pong"
 },
 "headers": {
 "Content-Type": "application/json"
 },
 "matchingRules": {
 "body": {
 "$": {
 "combine": "AND",
 "matchers": [
 {
 "match": "equality"
 }
 ]
 }
 },
 "header": {},
 "status": {}
 },
 "status": 200
 }
 }
 ],
 "metadata": {
 "pact-js": {
 "version": "13.1.0"
 },
 "pactRust": {
 "ffi": "0.4.21",
 "models": "1.2.2"
 },
 "pactSpecification": {
 "version": "3.0.0"
 }
 },
 "provider": {
 "name": "google-login-back"
 }
}</code></pre>

生成された契約ファイル(JSON)

バックエンドの実装は以下のとおりです。テストコードライブラリにはpytestを使用しています。<pre><code>diff --git a/.gitignore b/.gitignore
index 25a656d..7a5766a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
&nbsp;__pycache__/
&nbsp;.vscode/
&nbsp;dynamodb/
+pacts/
diff --git a/app.py b/app.py
index fead48f..51b7f80 100644
--- a/app.py
+++ b/app.py
@@ -179,3 +179,8 @@ def get_micropost_for_auth0():
&nbsp; &nbsp; &nbsp;posts = Microposts.query(payload.get("sub"))
&nbsp; &nbsp; &nbsp;res = [post.to_simple_dict() for post in posts]
&nbsp; &nbsp; &nbsp;return Response(body=res, status_code=200)
+
+
+@app.route("/ping", methods=["GET"])
+def ping():
+&nbsp; &nbsp; return Response(body={"message": "pong"})
diff --git a/docker-compose.yml b/docker-compose.yml
index e3d4662..cca3044 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -10,6 +10,8 @@ services:
&nbsp; &nbsp; &nbsp; &nbsp;- 8002:8002
&nbsp; &nbsp; &nbsp;environment:
&nbsp; &nbsp; &nbsp; &nbsp;DB_ENDPOINT: http://dynamo:8000
+&nbsp; &nbsp; &nbsp; TEST_PORT: 8008
+&nbsp; &nbsp; &nbsp; PYTEST_ADDOPTS: "-v --pact-files=pacts/*.json"
&nbsp; &nbsp; &nbsp;command: chalice local --host=0.0.0.0 --port=8002
&nbsp; &nbsp;dynamo:
&nbsp; &nbsp; &nbsp;image: amazon/dynamodb-local
diff --git a/tests/conftest.py b/tests/conftest.py
new file mode 100644
index 0000000..80d7fd0
--- /dev/null
+++ b/tests/conftest.py
@@ -0,0 +1,18 @@
+import pytest
+import subprocess
+import time
+import os
+
+
+@pytest.fixture(scope="session")
+def start_chalice_local():
+&nbsp; &nbsp; process = subprocess.Popen(
+&nbsp; &nbsp; &nbsp; &nbsp; ["chalice", "local", "--host=0.0.0.0", f"--port={os.getenv('TEST_PORT')}"],
+&nbsp; &nbsp; &nbsp; &nbsp; stdout=subprocess.PIPE,
+&nbsp; &nbsp; &nbsp; &nbsp; stderr=subprocess.PIPE,
+&nbsp; &nbsp; )
+&nbsp; &nbsp; # サービスが完全に起動するまで待機
+&nbsp; &nbsp; time.sleep(5)
+&nbsp; &nbsp; yield
+&nbsp; &nbsp; process.terminate()
+&nbsp; &nbsp; process.wait()
diff --git a/tests/test_pacts.py b/tests/test_pacts.py
new file mode 100644
index 0000000..e103c0c
--- /dev/null
+++ b/tests/test_pacts.py
@@ -0,0 +1,9 @@
+import os
+
+
+def provider_state(name, **params):
+&nbsp; &nbsp; pass
+
+
+def test_pacts(pact_verifier, start_chalice_local):
+&nbsp; &nbsp; pact_verifier.verify(f"http://localhost:{os.getenv('TEST_PORT')}", provider_state)</code></pre> 契約ファイルはフロント側で生成されたものをバックエンドのリポジトリ配下の<code>/pacts</code>に手動でコピーしています。実運用ならもちろん手動なんてありえないですが、今後の課題とします。 上記で、実質的なテストの中身は以下の1行だけです。<pre><code>pact_verifier.verify(f"http://localhost:{os.getenv('TEST_PORT')}", provider_state)</code></pre> 実行時に参照するpactファイルの場所を指定する必要がありますが、pytestの実行オプション(<code>--pact-files=pacts/*.json</code>)として指定します。毎回指定するのは面倒なので、<code>PYTEST_ADDOPTS</code>環境変数に指定しました。 工夫した点としてはconftest.pyでテスト実行ごとにchaliceサーバを立ち上げるようにしたことです。dockerで起動しているのでそこに直に接続でもいいのですが、テスト環境はローカル開発環境とは切り離したいです。またchaliceは基本的にはホットリロードですがグローバル変数などの変更は再起動が必要だったと思うので、そういった意味でもテストごとに起動したほうが何かと都合がいいと思います。また<code>scope="session"</code>にすることで1回のテスト実行の中ではサーバの起動は最初の1回だけでいいようにしています。

バックエンド（プロバイダ）

Hello World

今回はとりあえずPactにHello Worldしてみました。今後やってみたいことを以下にリストアップしておきます。<ul><li>CI/CDパイプラインに組み込む</li><li>契約ファイルの共有を自動化する<ul><li>ドキュメントとしても活用できたら最高</li></ul></li><li>状態を定義する<ul><li>DBの状態や認証状態など</li></ul></li><li>プロバイダ自身が外部に依存している場合</li><li>プロバイダがAPIではなくキューを使ったイベント駆動の場合</li></ul>上記でき次第また記事にしようと思います。ご覧頂きありがとうございました。

今後の課題

コンシューマ駆動契約テストに入門してみた〜とりあえずHello World編〜

<a href="https://github.com/zricethezav/gitleaks" target="_blank" rel="noopener noreferrer">Gitleaks</a>は、機密情報をハードコードすることを防ぐ静的解析ツールです。つまり、クレデンシャルなどの情報がソースコード上にあった場合、「そんな大切な情報載せてええんか！？」って叱ってくれます。例えば、gitleaks detect -vとコマンドを打つと、検出された機密情報が表示されます。 以下は直打ちしたCognitoのClient IDが入っていた場合です。<pre><code> $ gitleaks detect -v

 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

Finding: clientId: 'XXXXXXXXXXXXXXXXXX',
Secret: XXXXXXXXXXXXXXXXXX
RuleID: generic-api-key
Entropy: 4.209867
File: nuxt.config.ts
Line: 12
Commit: e9d73...
Author: daichiccchi
Email: daichi.aoki@example.com
Date: 2024-05-07T06:21:24Z
Fingerprint: e9d73d2236826a222ef27386b9ce7aa2cd6a1821:nuxt.config.ts:generic-api-key:12

8:11AM INF scan completed in 541ms
8:11AM WRN leaks found: 1</code></pre>

そもそもgitleaksって何ぞや

今回はCloud9(Amazon Linux 2)にインストールしていきます。<pre><code># 1.ダウンロード
$ curl -OL https://github.com/zricethezav/gitleaks/releases/download/v8.13.0/gitleaks_8.13.0_linux_x64.tar.gz

# 2.解凍
$ tar -zxvf gitleaks_8.13.0_linux_x64.tar.gz 
LICENSE
README.md
gitleaks
$ ls
gitleaks gitleaks_8.13.0_linux_x64.tar.gz LICENSE README.md

# 3.実行権限付与
$ chmod +x gitleaks

# 4.パスの通っているディレクトリに移動
$ sudo mv gitleaks /usr/local/bin/

# 5.動作確認（バージョンが表示されればOK）
$ gitleaks version
8.13.0

</code></pre>

gitleaksのインストール手順

今回はhuskyというライブラリを使用しました。<pre><code>$ mkdir project-dir
$ cd project-dir
$ git init
$ npm init -y
# huskyをインストール
$ npx husky-init &amp;&amp; npm install</code></pre>ここまでコマンドを実行すると、project-dir直下に<code>.husky/pre-commit</code>ファイルが作成されます。このファイルに記述したコマンドがgit commitの際に実行されます。<code>.husky/pre-commit</code>ファイルを下記のように修正して、コミット時に機密情報を検出するようにします。 （ちなみに<code>--staged</code> オプションで<code>git add</code> 済みのファイルを検出の対象としています。）<pre><code>#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

gitleaks protect --staged // 追記</code></pre> 動作確認試しに機密情報を載せた状態でコミットしてみます。コミット時にgitleaksコマンドが実行されており、「そんな情報載せたコードのコミットなんて許しまへんで」と、しっかり怒られました。コミットもされていません。<pre><code>$ git commit -m 'test'

 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

Finding: clientId: 'XXXXXXXXXXXXXXXXXX',
Secret: XXXXXXXXXXXXXXXXXX
RuleID: generic-api-key
Entropy: 4.209867
File: nuxt.config.ts
Line: 12
Commit: e9d73...
Author: daichiccchi
Email: daichi.aoki@example.com
Date: 2024-05-07T06:21:24Z
Fingerprint: e9d73d2236826a222ef27386b9ce7aa2cd6a1821:nuxt.config.ts:generic-api-key:12

8:11AM INF scan completed in 541ms
8:11AM WRN leaks found: 1
husky - pre-commit hook exited with code 1 (error)</code></pre>

git commit時にハードコーディングがないかをチェックする方法

こちらはGithubActionsを使ってワークフローに組み込んでいきます。 ワークフローを記述するファイルを作成<code>.github/workflows/ci-gitleaks.yml</code>をリポジトリに置きます。以下のようにファイルを編集します。<pre><code>name: CI-gitleaks
on:
 push:　// 1.
jobs:
 asciidoctor_job:
 runs-on: self-hosted
 name: Scan secrets using gitleaks
 steps:
 - name: Check out code
 uses: actions/checkout@v3 // 2.
 - name: gitleaks
 run: |
 gitleaks detect -v --redact // 3.</code></pre>こちらの内容は<ol><li>プッシュしたときに</li><li>リポジトリを引っ張ってきて</li><li>gitleaksコマンドで検出するよ</li></ol>というものです。 動作確認次は機密情報がソースコードに無い状態でgitleaksが動くことを確認します。まずはコミット<pre><code>$ git add .
$ git commit -m 'テスト'
 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

8:32AM INF scan completed in 605ms
8:32AM INF no leaks found</code></pre> 次にプッシュします。<pre><code>$ git push origin feature/gitleaks</code></pre>無事にプッシュ後、GithubActionsのワークフロー上でgitleaksコマンドが実行されていることが確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3b5d669f11af4381b632eb136a3ae6c0/Untitled.png" alt="">

git push時にハードコーディングがないかをチェックする方法

<ul><li>gitleaksとは、機密情報をハードコードすることを防ぐ静的解析ツールである。</li><li><code>husky</code>というライブラリを使用することで、コミット時のハードコードを自動検出することができる。</li><li>GithubActionsのワークフローに組み込むことで、プッシュ時のハードコードを自動検出することができる。</li></ul> 何事もダブルチェックが大事ですね。

機密情報の漏洩を防ごう！～gitleaksの運用方法～

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c38e31d48b89483994121a397960e31f/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c81a04c0dd554f2caca8a3a45fbb7a36/Screenshot%20from%202024-04-19%2001-07-56.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b3a756028d65467fbed31c31726ec1d0/Screenshot%20from%202024-04-19%2021-45-31.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fc2d78eb63284e3c8761d846bd09316c/Screenshot%20from%202024-04-17%2023-39-52.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/9a37ba0f0285471b895ed33f60a68f79/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/149388bf8cd1483988cec54829a694c6/Screenshot%20from%202024-04-17%2023-41-34.png" alt="">APIの疎通を確認したいだけなので今回はレスポンスをそのまま貼ってます。

成果物

図にするまでもないほど単純ですがインフラ構成図は以下のとおりです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/03dcccc7c27b48fea22130c63db88996/image.png" alt="">NextJSアプリはAmplifyでホスティングしました。下のAPI Gateway + Lambdaは自作のAPIで、前回までで使っていたMicropost APIのインフラをそのまま活用します。

インフラ

設計

雛形アプリには元々External APIとして<code>read:shows</code>というスコープが必要なAPIが定義されています。今回は追加で<code>read:microposts</code>というスコープを要求する自作のAPIを認可して呼んでみようと思います。 IDトークンのaudはクライアントアプリケーション（今回であればNextJSアプリ）ですがアクセストークンのaudは<code>AUTH0_AUDIENCE</code>環境変数で設定したものになります。 注意点としてAuth0のアクセストークンのaudは一つしか取れないようです（userinfoエンドポイント用のものを除いて）。複数のAPIを使いたい場合はどうすればいいかというと、audは共通のものを使い、scopeで区切ればいいみたいです。（<a href="https://zenn.dev/tatsuyasusukida/articles/auth0-multiple-api" target="_blank" rel="noopener noreferrer">こちら</a>の記事を参考にさせていただきました）今回は、<code>my-custom-api</code>というaud(API)を登録し要求するスコープとして<code>read:shows read:microposts</code>を定義しました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b5bcada393f340daadc03efd81a3aaef/image.png" alt="">

概要

<pre><code>diff --git a/app/api/microposts/route.js b/app/api/microposts/route.js
new file mode 100644
index 0000000..b16ab50
--- /dev/null
+++ b/app/api/microposts/route.js
@@ -0,0 +1,23 @@
+import { getAccessToken, withApiAuthRequired } from '@auth0/nextjs-auth0';
+import { NextResponse } from 'next/server';
+
+export const GET = withApiAuthRequired(async function shows(req) {
+&nbsp; try {
+&nbsp; &nbsp; const res = new NextResponse();
+&nbsp; &nbsp; const { accessToken } = await getAccessToken(req, res, {
+&nbsp; &nbsp; &nbsp; scopes: ['read:microposts']
+&nbsp; &nbsp; });
+&nbsp; &nbsp; const apiPort = process.env.API_PORT || 8000;
+&nbsp; &nbsp; const apiHost = process.env.API_HOST;
+&nbsp; &nbsp; const response = await fetch(`${apiHost}:${apiPort}/auth0/microposts`, {
+&nbsp; &nbsp; &nbsp; headers: {
+&nbsp; &nbsp; &nbsp; &nbsp; Authorization: `Bearer ${accessToken}`
+&nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; });
+&nbsp; &nbsp; const shows = await response.json();
+
+&nbsp; &nbsp; return NextResponse.json(shows, res);
+&nbsp; } catch (error) {
+&nbsp; &nbsp; return NextResponse.json({ error: error.message }, { status: error.status || 500 });
+&nbsp; }
+});
diff --git a/app/microposts/page.jsx b/app/microposts/page.jsx
new file mode 100644
index 0000000..edf0e43
--- /dev/null
+++ b/app/microposts/page.jsx
@@ -0,0 +1,75 @@
+'use client';
+
+import React, { useState } from 'react';
+import { Button } from 'reactstrap';
+import { withPageAuthRequired } from '@auth0/nextjs-auth0/client';
+
+import Loading from '../../components/Loading';
+import ErrorMessage from '../../components/ErrorMessage';
+import Highlight from '../../components/Highlight';
+
+function External() {
+&nbsp; const [state, setState] = useState({ isLoading: false, response: undefined, error: undefined });
+
+&nbsp; const callApi = async () =&gt; {
+&nbsp; &nbsp; setState(previous =&gt; ({ ...previous, isLoading: true }));
+
+&nbsp; &nbsp; try {
+&nbsp; &nbsp; &nbsp; const response = await fetch('/api/microposts');
+&nbsp; &nbsp; &nbsp; const data = await response.json();
+
+&nbsp; &nbsp; &nbsp; setState(previous =&gt; ({ ...previous, response: data, error: undefined }));
+&nbsp; &nbsp; } catch (error) {
+&nbsp; &nbsp; &nbsp; setState(previous =&gt; ({ ...previous, response: undefined, error }));
+&nbsp; &nbsp; } finally {
+&nbsp; &nbsp; &nbsp; setState(previous =&gt; ({ ...previous, isLoading: false }));
+&nbsp; &nbsp; }
+&nbsp; };
+
+&nbsp; const handle = (event, fn) =&gt; {
+&nbsp; &nbsp; event.preventDefault();
+&nbsp; &nbsp; fn();
+&nbsp; };
+
+&nbsp; const { isLoading, response, error } = state;
+
+&nbsp; return (
+&nbsp; &nbsp; &lt;&gt;
+&nbsp; &nbsp; &nbsp; &lt;div className="mb-5" data-testid="external"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;h1 data-testid="external-title"&gt;Microposts&lt;/h1&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;div data-testid="external-text"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p className="lead"&gt;Ping an external API by clicking the button below&lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This will call a local API on port 3001 that would have been started if you run &lt;code&gt;npm run dev&lt;/code&gt;.
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; An access token is sent as part of the request's &lt;code&gt;Authorization&lt;/code&gt; header and the API will validate
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; it using the API's audience value. The audience is the identifier of the API that you want to call (see{' '}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a href="https://auth0.com/docs/get-started/dashboard/tenant-settings#api-authorization-settings"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; API Authorization Settings
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/a&gt;{' '}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for more info).
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;Button color="primary" className="mt-5" onClick={e =&gt; handle(e, callApi)} data-testid="external-action"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Ping API
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;/Button&gt;
+&nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &nbsp; &lt;div className="result-block-container"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; {isLoading &amp;&amp; &lt;Loading /&gt;}
+&nbsp; &nbsp; &nbsp; &nbsp; {(error || response) &amp;&amp; (
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;div className="result-block" data-testid="external-result"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;h6 className="muted"&gt;Result&lt;/h6&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {error &amp;&amp; &lt;ErrorMessage&gt;{error.message}&lt;/ErrorMessage&gt;}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {response &amp;&amp; &lt;Highlight&gt;{JSON.stringify(response, null, 2)}&lt;/Highlight&gt;}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; )}
+&nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &lt;/&gt;
+&nbsp; );
+}
+
+export default withPageAuthRequired(External, {
+&nbsp; onRedirecting: () =&gt; &lt;Loading /&gt;,
+&nbsp; onError: error =&gt; &lt;ErrorMessage&gt;{error.message}&lt;/ErrorMessage&gt;
+});
diff --git a/components/NavBar.jsx b/components/NavBar.jsx
index bf4eea4..c393d66 100644
--- a/components/NavBar.jsx
+++ b/components/NavBar.jsx
@@ -54,6 +54,11 @@ const NavBar = () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;External API
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/PageLink&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/NavItem&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;NavItem&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;PageLink href="/microposts" className="nav-link" testId="navbar-external"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Microposts
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/PageLink&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/NavItem&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;)}
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/Nav&gt;</code></pre> 中身はほぼテンプレにあったExternal APIのコピペです。

フロントエンド

<pre><code>diff --git a/app.py b/app.py
index df4073e..c6791ef 100644
--- a/app.py
+++ b/app.py
@@ -6,6 +6,7 @@ import urllib
&nbsp;from datetime import datetime, timedelta, timezone
&nbsp;from chalicelib.models import Microposts
&nbsp;from chalicelib.utils import login
+import jwt
&nbsp;
&nbsp;
&nbsp;app = Chalice(app_name="XXXXXXXXXXXXXXXXXXX")
@@ -16,6 +17,7 @@ ssm = boto3.client("ssm")
&nbsp;CLIENT_ID = ssm.get_parameter(Name="/google_oauth/client_id")["Parameter"]["Value"]
&nbsp;CLIENT_SECRET = ssm.get_parameter(Name="/google_oauth/client_secret")["Parameter"]["Value"]
&nbsp;REDIRECT_URI = ssm.get_parameter(Name="/google_oauth/redirect_uri")["Parameter"]["Value"]
+AUTH0_CLIENT_ID = ssm.get_parameter(Name="/auth0/client_id")["Parameter"]["Value"]
&nbsp;
&nbsp;
&nbsp;@app.route("/get_token", methods=["POST"], cors=CORSConfig(allow_origin="https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"))
@@ -112,3 +114,33 @@ def _parse_schedule(schedule_str):
&nbsp; &nbsp; &nbsp;summary = " ".join(parts[5:])
&nbsp;
&nbsp; &nbsp; &nbsp;return start, end, summary
+
+
+@app.route("/auth0/microposts", methods=["GET"])
+def get_micropost_for_auth0():
+&nbsp; &nbsp; if "Authorization" not in app.current_request.headers:
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body=None, status_code=401)
+
+&nbsp; &nbsp; access_token = app.current_request.headers["Authorization"].removeprefix("Bearer ")
+
+&nbsp; &nbsp; jwks_client = jwt.PyJWKClient("https://dev-XXXXXXXXXXXXXXXXXXXXX.us.auth0.com/.well-known/jwks.json")
+&nbsp; &nbsp; try:
+&nbsp; &nbsp; &nbsp; &nbsp; signing_key = jwks_client.get_signing_key_from_jwt(access_token)
+&nbsp; &nbsp; &nbsp; &nbsp; payload = jwt.decode(
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; access_token,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; signing_key.key,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; algorithms=["RS256"],
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; audience=AUTH0_CLIENT_ID,
+&nbsp; &nbsp; &nbsp; &nbsp; )
+&nbsp; &nbsp; except Exception as e:
+&nbsp; &nbsp; &nbsp; &nbsp; app.log.error(e)
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body=None, status_code=401)
+
+&nbsp; &nbsp; # scopeの検証
+&nbsp; &nbsp; if "read:microposts" not in payload["scope"].split():
+&nbsp; &nbsp; &nbsp; &nbsp; app.log.error("insufficient scope")
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body=None, status_code=401)
+
+&nbsp; &nbsp; posts = Microposts.query(payload.get("sub"))
+&nbsp; &nbsp; res = [post.to_simple_dict() for post in posts]
+&nbsp; &nbsp; return Response(body=res, status_code=200)</code></pre>

バックエンド

API連携の実装

Auth0においてはIDトークンだけでなくアクセストークンも実態は署名付きJWTです。実装していてそれぞれのpayloadを参照したいことが結構あると思ったので以下に記載しておきます。 IDトークンのpayload<pre><code>{
&nbsp; "nickname": "XXXXXXX",
&nbsp; "name": "XXXXXXXXXXXXXXX",
&nbsp; "picture": "https://s.gravatar.com/avatar/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.png",
&nbsp; "updated_at": "2024-04-18T14:31:52.952Z",
&nbsp; "iss": "https://dev-XXXXXXXXXXXXXXXXXXXXXXXXXXX.us.auth0.com/",
&nbsp; "aud": "XXXXXXXXXXXXXXXXXXXXXXXX",
&nbsp; "iat": 1713450713,
&nbsp; "exp": 1713486713,
&nbsp; "sub": "auth0|XXXXXXXXXXXXXXXXXXXXXXXXXX",
&nbsp; "sid": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
&nbsp; "nonce": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}</code></pre> アクセストークンのpayload<pre><code>{
&nbsp; "iss": "https://dev-XXXXXXXXXXXXXXXXXXXXXXXX.us.auth0.com/",
&nbsp; "sub": "auth0|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXx",
&nbsp; "aud": [
&nbsp; &nbsp; "my-custom-api",
&nbsp; &nbsp; "https://dev-XXXXXXXXXXXXXXXXXXXXXX.us.auth0.com/userinfo"
&nbsp; ],
&nbsp; "iat": 1713452513,
&nbsp; "exp": 1713538913,
&nbsp; "scope": "openid profile read:shows read:microposts",
&nbsp; "azp": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}</code></pre>

Auth0のアクセストークンとIDトークン

今回はAuth0環境の構築から自作のAPIを投げてみるまで試してみました。 迷ったのはAPIでユーザを検証するときにIDトークンを使うかアクセストークンを使うかです。APIのクライアントが確実に限定される場合はIDトークンのほうがユーザが認証されていることが保証されるのでセキュリティ的なことを考えてもいいと思いますが、アクセストークンを使うのでも使い方としては正しいと思います。（むしろ投稿アプリの使用をユーザが認可したという意味になるのでアクセストークンの方が本来の目的にあってそうな気がします）ただその考え方を推し進めると全てのバックエンドとのやり取りはアクセストークンを使えばいいとなって逆にIDトークンいらなくない？とちょっと思いましたが、見ての通りIDトークンにはユーザ名やアバターなどアプリの見た目をユーザのためにカスタマイズするのに必要ですし（userinfoエンドポイントにアクセスすればいいじゃんという話もありますが・・・）、アクセストークンでは認証の証明にはならないためアプリ側でIDトークンの検証は行うべきだと思います。

Auth0環境を構築して自作のAPIと連携してみた

最もセキュリティレベルが高いのは、都度認証でしょう。また、バックエンドから認証エラーが返ってきたときにログイン画面にリダイレクトすればいいだけなので、実装的にも最も簡単だと思われます。ただ、当然のことながらIDトークンの有効期限が切れるたびに認証を突破しなければいけないため、UX的には最も劣る方法でもあります。 次にトークンをリフレッシュする方法を考えます。これなら有効期限が切れてもユーザの手を煩わせることもありません。フロント側でリフレッシュトークンを持っておいて、バックエンドから認証エラーが返ってきたときにトークンエンドポイントに対してリフレッシュトークンを送信し、新しいIDトークンを受け取ります。ただこの場合、リフレッシュトークンが万が一漏れた場合に他人になりすまされてしまいます。フロント側ではリフレッシュトークンを安全に保管することはできません。 バックエンド側でトークンを保管することを考えます。そうするとフロントとバックエンドでセッションを共有するための別の要素が必要になってきます。ログインに成功したら、バックエンドでセッションIDを発行し、トークン3セットと紐付けておきます。レスポンスとしてはトークン3セットの代わりにセッションIDを返すようにしましょう。そうすると、フロントはIDトークンの有効期限など考えずに、単純にセッションIDをCookieに保存しておき、毎回のリクエストに含めるだけで良くなります。IDトークンの有効期限が来た場合は、よしなにバックエンドでトークンをリフレッシュし、新しいトークンに交換しておきます。ただこの場合も、セッションIDが漏れた場合になりすまされてしまいます。結局、リフレッシュトークンがセッションIDに置き換わっただけで、本質的には何も変わっていません。

基本的な方針の比較

リフレッシュトークンもセッションIDの違いについて考えてみます。まず、リフレッシュトークンには有効期限がありますがセッションIDにはありません。しかし、セッションIDをCookieで保存するなら有効期限は設定できます。次に、セッションIDはリクエストのたびに送るものですが、リフレッシュトークンはトークンの有効期限が切れた場合のみ送るものです。なので、ネットワークを経由する頻度としてはリフレッシュトークンのほうが圧倒的に少ないと言えます。最後に、漏洩した場合のリスクですが、セッションIDについては明示的にログアウトしない限り有効です。リフレッシュトークンについて言えば、基本的に1回使ったら古いものは使えないはずです。※リフレッシュトークンの再利用はできないようにすべきですが、OAuth2.0の仕様として<a href="unsafe:決められているわけではない">決められているわけではない</a>ようです。<blockquote>例えば, 認可サーバーはアクセストークンリフレッシュレスポンスの都度新しいリフレッシュトークンを発行するリフレッシュトークンローテーションを採用することができる.&nbsp;</blockquote> 総合的に見て、単なるセッションIDよりもリフレッシュトークンのほうがセキュリティレベルが高いような気がしてきました。

リフレッシュトークンとセッションIDの比較

考察

Googleの場合には、インプリシットフローではリフレッシュトークンを取得することができませんでした。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/11a4132c62f14a59ac1e6a3f79d451ad/Screenshot%20from%202024-04-12%2022-59-34.png" alt="">やはりURLフラグメントで丸見えになってしまうからでしょうか。リフレッシュトークンは有効期限が長く漏洩した場合のダメージが大きいため、インプリシットフローではそもそも禁止されているものと思われます。なので、その場合は都度認証しか手段がないですね。

インプリシットフローとリフレッシュトークン

上の比較検討のところで、<blockquote>リフレッシュトークンについて言えば、基本的に1回使ったら古いものは使えないはずです。</blockquote>と書きましたが、本当にそうでしょうか？試しにGoogleの認可サーバが対応しているかどうか試してみましょう。 1回目の使用<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/246b3998ed614b8eacba838023775956/Screenshot%20from%202024-04-12%2023-13-28.png" alt=""> 2回目の使用<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/81b0cac66f4d4207855cedff3dffd7af/Screenshot%20from%202024-04-12%2023-15-44.png" alt=""> 普通に使えちゃってますね・・・意外でした。 ユーザがもう一度認可した場合は、古いリフレッシュトークンは利用できるんでしょうか？（再度認可しました） <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5796533aa26f414896e1d475e8de755b/Screenshot%20from%202024-04-12%2023-19-44.png" alt="">普通に使えちゃってますね・・・これだと、セッションIDを使うのとあまり変わらないかもしれないです。 後になって気づいたのですが、トークンリフレッシュレスポンスにリフレッシュトークンは含まれていませんでした。つまり、元々最初に発行されたリフレッシュトークンを使いまわすことをあえて意図しているようです。リフレッシュトークンの有効期限について調べてみましたが、明確な記述は見つかりませんでした。<a href="https://groups.google.com/g/google-apps-api-japan/c/kvKDfaQfvvI" target="_blank" rel="noopener noreferrer">かなり長く設定されているようだ、みたいな話</a>もあるみたいです。

リフレッシュトークンのローテーション検証

演習

以下、あくまでも自分の意見ですがまとめました。<ul><li>ユーザがいないときにアクセストークンを利用するユースケース(毎日特定の時間にGoogleドライブにアクセスするなど)がないのであれば、都度認証が最も望ましい<ul><li>1時間毎だと煩わしいのであれば、3時間毎にするとか。セキュリティ面とのバランスでチューニングする</li></ul></li><li>都度認証が許容できないのであれば、リフレッシュトークンをフロント側にもたせるのもアリ</li></ul>

「Googleでログイン」を実装してみた〜トークンリフレッシュ編〜

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/78e8262c26564c02ab305e7d3d4000d1/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/082a3f9c7dca45838fe7014a999e7dd6/Screenshot%20from%202024-04-09%2023-05-30.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/44906d0330a94ceb8beefb33a698ac34/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/428d42b6fd7848ca8fe7eabe1600744d/Screenshot%20from%202024-04-09%2023-08-06.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/da3a5b5b5dbe4870bbafef611dd64bcd/Screenshot%20from%202024-04-09%2023-10-12.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/67678995983d475c817647e078d1b046/Screenshot%20from%202024-04-09%2023-11-42.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/94214a245aef40648d0dfc89fc36f725/Screenshot%20from%202024-04-09%2023-13-18.png" alt="">"yyyy/mm/dd hh:MM:ss ~ yyyy/mm/dd hh:MM:ss hogehoge"というパターンの投稿がされた場合に、予定に関する投稿とみなしてGoogleカレンダーに登録する仕様です。

実装のポイントとしては、<ul><li>Googleカレンダーへのアクセス権限が欲しいので、OAuthのスコープにGoogleカレンダーの読み書き権限を追加する</li><li>上記の権限が付与されたアクセストークンを使ってGoogleカレンダーAPIにアクセスしたいので、投稿APIのリクエストボディにアクセストークンを追加する</li></ul>というところです。ベースの実装ができているのでほんの少しの修正だけで実現できます。

ポイント

<pre><code>diff --git a/src/routes/+page.svelte b/src/routes/+page.svelte
index 910dc9d..ad79e35 100644
--- a/src/routes/+page.svelte
+++ b/src/routes/+page.svelte
@@ -10,7 +10,7 @@
&nbsp;		const params = {
&nbsp;			response_type: 'code',
&nbsp;			client_id: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
-			scope: 'openid profile email',
+			scope: 'openid profile email https://www.googleapis.com/auth/calendar',
&nbsp;			redirect_uri: 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/callback',
&nbsp;			state: Math.random().toString(32).substring(2),
&nbsp;			nonce: Math.random().toString(32).substring(2)
@@ -33,7 +33,7 @@
&nbsp;		const params = {
&nbsp;			response_type: 'token id_token',
&nbsp;			client_id: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
-			scope: 'openid profile email',
+			scope: 'openid profile email https://www.googleapis.com/auth/calendar',
&nbsp;			redirect_uri: 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/implicit/callback',
&nbsp;			state: Math.random().toString(32).substring(2),
&nbsp;			nonce: Math.random().toString(32).substring(2)
diff --git a/src/routes/microposts/+page.svelte b/src/routes/microposts/+page.svelte
index 7dbfe73..8bad0ee 100644
--- a/src/routes/microposts/+page.svelte
+++ b/src/routes/microposts/+page.svelte
@@ -27,7 +27,7 @@
&nbsp;
&nbsp; &nbsp; &nbsp;async function post() {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// 投稿
-&nbsp; &nbsp; &nbsp; &nbsp; await axios.post('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/api/microposts', {content: content}, {headers: {Authorization: `Bearer ${id_token}`}});
+&nbsp; &nbsp; &nbsp; &nbsp; await axios.post('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/api/microposts', {content: content, access_token: access_token}, {headers: {Authorization: `Bearer ${id_token}`}});
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// リロード
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;micropostRes = await axios.get('https://nfk13r40e6.execute-api.ap-northeast-1.amazonaws.com/api/microposts', {headers: {Authorization: `Bearer ${id_token}`}});
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;console.log(micropostRes);</code></pre>

<pre><code>diff --git a/app.py b/app.py
index bd01a93..df4073e 100644
--- a/app.py
+++ b/app.py
@@ -3,6 +3,7 @@ import logging
&nbsp;import requests
&nbsp;import boto3
&nbsp;import urllib
+from datetime import datetime, timedelta, timezone
&nbsp;from chalicelib.models import Microposts
&nbsp;from chalicelib.utils import login
&nbsp;
@@ -57,6 +58,27 @@ def post():
&nbsp; &nbsp; &nbsp;micropost = user.post(req["content"])
&nbsp; &nbsp; &nbsp;micropost.save()
&nbsp;
+&nbsp; &nbsp; if "access_token" in req:
+&nbsp; &nbsp; &nbsp; &nbsp; start, end, summary = _parse_schedule(req["content"])
+&nbsp; &nbsp; &nbsp; &nbsp; if start and end and summary:
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; app.log.info(f"googleカレンダーに予定({summary})を作成します")
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; token = req["access_token"]
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; res = requests.post(
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "https://www.googleapis.com/calendar/v3/calendars/primary/events",
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; headers={"Authorization": f"Bearer {token}"},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; json={
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "summary": summary,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "description": "これはサンプルアプリで作成した予定です",
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "start": {"dateTime": start.isoformat()},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "end": {"dateTime": end.isoformat()},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if res.status_code &gt;= 300:
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; app.log.error(res.json())
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return Response(body={"message": "server error"}, status_code=500)
+
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; app.log.info(f"googleカレンダーに予定({summary})を作成しました")
+
&nbsp; &nbsp; &nbsp;return Response(body={"posted_at": micropost.postedAt.isoformat()}, status_code=201)
&nbsp;
&nbsp;
@@ -70,3 +92,23 @@ def get_list():
&nbsp; &nbsp; &nbsp;posts = Microposts.query(user.id)
&nbsp; &nbsp; &nbsp;res = [post.to_simple_dict() for post in posts]
&nbsp; &nbsp; &nbsp;return Response(body=res, status_code=200)
+
+
+def _parse_schedule(schedule_str):
+&nbsp; &nbsp; # 文字列をスペースで分割して情報を取得
+&nbsp; &nbsp; parts = schedule_str.split()
+
+&nbsp; &nbsp; if len(parts) &lt; 5 or parts[2] != "~":
+&nbsp; &nbsp; &nbsp; &nbsp; return None, None, None
+
+&nbsp; &nbsp; # 日付と時間をパースしてdatetimeオブジェクトに変換
+&nbsp; &nbsp; start_str = f"{parts[0]} {parts[1]}"
+&nbsp; &nbsp; end_str = f"{parts[3]} {parts[4]}"
+
+&nbsp; &nbsp; start = datetime.strptime(start_str, "%Y/%m/%d %H:%M").replace(tzinfo=timezone(timedelta(hours=9)))
+&nbsp; &nbsp; end = datetime.strptime(end_str, "%Y/%m/%d %H:%M").replace(tzinfo=timezone(timedelta(hours=9)))
+
+&nbsp; &nbsp; # サマリを取得
+&nbsp; &nbsp; summary = " ".join(parts[5:])
+
+&nbsp; &nbsp; return start, end, summary</code></pre>

今回はGoogleカレンダー権限をスコープに追加してアクセスする実装を試してみました。今回はAPIの中で直接GoogleカレンダーAPIを叩いてしまっていますが、Googleカレンダーに登録するまでユーザを待たせてしまうのも微妙なので、非同期で登録するようにしたほうがいいと思いました。その場合は非同期キューにアクセストークンを含ませたリクエストを登録する形になりそうです。今回、IDトークンはAuthorizationヘッダに含ませていますが、アクセストークンはリクエストボディに含ませました。なんか不格好な気がしますが、一般的なOIDCを利用したAPIの設計はどうするのが普通なんでしょうか・・・ 今後やってみたいこととしては、<ul><li>トークンのリフレッシュに対応する</li><li>ログアウトに対応する</li><li>他のIDPを利用する</li></ul>などがあります。際限なく出てきますね・・・また実装でき次第記事にしようと思います。

<a href="https://developers.google.com/calendar/api/v3/reference?hl=ja" target="_blank" rel="noopener noreferrer">GoogleカレンダーAPIリファレンス</a>

BuildersIO produced by YOKU