最近、ChatGPTやGeminiなどのLLMを使ったAIエージェントの開発が活発になってきていますよね。PythonのLangChainが有名ですが、「Haskellでも同じようなことができないかな？」と思って開発を始めたのが「lgchain-hs」です。※LangChainを名乗るのは流石におこがましいので、"lgchain"としています このブログは特に以下の方に読んでいただきたいです：- 壊れないAIエージェントの開発に興味がある方- HaskellでLLMを扱いたい方

はじめに

いきなりですが、まずは本ライブラリの具体的な使用例を見ていきましょう。 ### 1. シンプルな文字列出力 一番基本的な使い方です。OpenAIのモデルに質問を投げて、回答を文字列で受け取ります。 ```haskell{-# LANGUAGE OverloadedStrings #-} import Lgchain.Core.Clients (Chain(StrChain), invoke, runOrFail, strOutput)import Lgchain.Core.Requests (ReqMessage(ReqMessage), Role(System, User))import Control.Monad.Trans.Except (ExceptT(ExceptT))import Lgchain.OpenAI.Clients (ChatOpenAI(ChatOpenAI), OpenAIModelName(GPT4O)) main :: IO ()main = runOrFail $ do let prompt = [ ReqMessage System "You are a helpful assistant.", ReqMessage User "Haskellについて教えてください。" ] let model = ChatOpenAI GPT4O let chain = StrChain model prompt result &lt;- invoke chain Nothing response &lt;- ExceptT $ return $ strOutput result liftIO $ putStrLn response``` ### 2. 構造化データの取得 これが「lgchain-hs」の真骨頂です。例えば、レシピを構造化データとして取得してみましょう。 ```haskell{-# LANGUAGE OverloadedStrings #-}{-# LANGUAGE TemplateHaskell #-} import Lgchain.Core.Clients (Chain(Chain), invoke, runOrFail, structedOutput)import Lgchain.Core.Requests (ReqMessage(ReqMessage), Role(System, User), ViewableText, deriveJsonSchema)import Data.Map qualified as Mimport GHC.Generics (Generic)import Lgchain.Gemini.Clients (ChatGemini(ChatGemini), GeminiModelName(GEMINI_1_5_FLASH)) data Recipe = Recipe { ingredients :: [ViewableText], steps :: [ViewableText] } deriving (Eq, Show, Generic) deriveJsonSchema ''Recipe -- ここがポイント！ main :: IO ()main = runOrFail $ do let prompt = [ ReqMessage System "ユーザが入力した料理のレシピを考えてください。", ReqMessage User "{dish}" ] let model = ChatGemini GEMINI_1_5_FLASH let chain = Chain model prompt (undefined :: Recipe) let formatMap = M.fromList [("{dish}", "カレー")] result &lt;- invoke chain (Just formatMap) recipe &lt;- ExceptT $ return $ structedOutput result liftIO $ print recipe``` `deriveJsonSchema`を使うことで、Haskellのデータ型定義から自動的にJSONスキーマを生成できます。これにより、型安全な構造化データの取得が可能になります。 ### 3. チャット履歴の管理 チャットボットを作る場合、会話の履歴管理は必須ですよね。SQLiteを使った履歴管理の例を見てみましょう。 ```haskell{-# LANGUAGE OverloadedStrings #-} import Lgchain.Core.Histories.ChatMessageHistories (ChatMessageHistory(addMessage, deleteMessages), getMessages)import Lgchain.Core.Histories.ChatMessageHistories.RDB (SqliteChatMessageHistory(SqliteChatMessageHistory), migrate)import Lgchain.Core.Requests (ReqMessage(ReqMessage), Role(Assistant, System, User)) main :: IO ()main = runOrFail $ do let history = SqliteChatMessageHistory "database.db" "session1" liftIO $ migrate history -- 履歴の追加と取得が簡単！ liftIO $ addMessage history (ReqMessage User "こんにちは") messages &lt;- liftIO $ getMessages history``` ### 4. エージェントワークフロー 複数のステップを持つAIエージェントも実装できます。例えば、「質問を分析して適切なロールを選択→回答を生成」というワークフローを考えてみましょう。 ```haskelldata ExampleState = ExampleState { query :: ViewableText, currentRole :: Maybe ViewableText, messages :: [ViewableText] } deriving (Eq, Show, Generic) -- ロール選択ノードdata SelectionNode = SelectionNode instance AgentNode SelectionNode ExampleState where run _ state = do -- ロール選択ロジック return $ state { currentRole = Just "選択されたロール" } -- 回答ノードdata AnsweringNode = AnsweringNode instance AgentNode AnsweringNode ExampleState where run _ state = do -- 回答生成ロジック return $ state { messages = messages state ++ ["生成された回答"] }```

使用例と応用

さて、なぜHaskellでLLMライブラリを作ろうと思ったのか。 PythonのLangChainは本当に素晴らしいライブラリです。特に外部ツールとの連携や拡張性は群を抜いています。 ただ、最近のLLM開発では**Model-Completion-Prompt (MCP)** パターンが主流になってきています。つまり、複雑なツール連携よりも、プロンプト設計と構造化出力の取り扱いが重要になってきているんです。 「だったらHaskellでも十分戦えるんじゃない？」 そう考えて、型安全なLLMインターフェースの構築を始めました。

動機と背景

最大の課題は「構造化出力の型安全な取得」でした。 AIエージェントを開発していると、よく遭遇する問題があります：- LLMから返ってくるJSONが期待した構造と違う- スキーマの定義が面倒で、しかも手動だとミスが起きやすい- モデルプロバイダごとに構造化出力の定義フォーマットが異なる これらの問題を解決しないと、実用的なAIエージェントの実装は困難です。 ## 構造化出力の設計と解決法 最初は、HaskellのGenericを使ってスキーマを動的に生成しようとしました。でも、Haskellの型システムと`LLMModel`型クラスの関係で、これは断念することに... そこで考えた解決策が： 1. ChatGPTの構造化出力定義形式を中間表現として採用2. `JsonSchemaConvertable`型クラスを`TemplateHaskell`で実装3. ユーザ定義型からChatGPT定義形式への自動変換を実現4. Geminiなどの他のプロバイダはChatGPT形式からの変換を定義して吸収 この方法で、型安全性を保ちながら、異なるモデル間での構造化出力の取り扱いを統一できました。

解決したかった課題

プロジェクトは現在以下の3つのライブラリを提供しています： 1. `lgchain-hs-core`: 基本的な抽象化とユーティリティ2. `lgchain-hs-openai`: OpenAIモデルとの統合3. `lgchain-hs-gemini`: Geminiモデルとの統合 中心的な概念は： - `Chain`, `StrChain`: LLM操作の組み合わせを表現- `ChatMessageHistory`: 履歴管理（RDB対応）- `AgentNode`: AIエージェントのワークフローを型安全に記述 特に「統一インターフェースと型レベルの安全性」にこだわって設計しています。 ### クリーンなモジュール設計 設計上のこだわりポイントとして、クライアント実装時の依存が極力coreに集中するようにしています。具体的には： ```haskell-- coreモジュールから必要な型や関数をimportimport Lgchain.Core.Clients (Chain(Chain), invoke, runOrFail)import Lgchain.Core.Requests (ReqMessage(ReqMessage), Role(System, User)) -- プロバイダモジュールからはLLMModel型インスタンスのみをimportimport Lgchain.OpenAI.Clients (ChatOpenAI(ChatOpenAI))-- またはimport Lgchain.Gemini.Clients (ChatGemini(ChatGemini))``` これを実現しているのが`LLMModel`型クラスです： ```haskellclass LLMModel a where invokeWithSchema :: (JsonSchemaConvertable b) =&gt; a -&gt; Prompt -&gt; b -&gt; Maybe FormatMap -&gt; ExceptIO (Output b) invokeStr :: a -&gt; Prompt -&gt; Maybe FormatMap -&gt; ExceptIO (Output b)``` 各プロバイダ固有の呼び出し方法は、そのプロバイダの`LLMModel`インスタンスが知っているため、クライアント側は統一されたインターフェースだけを使えば良いのです。 これにより：- クリーンなコード（余計なimportが不要）- 高い保守性（プロバイダ固有の実装を隠蔽）- 容易な切り替え（異なるプロバイダ間でのスイッチが簡単） を実現しています。

構造と特徴

一番苦労したのは、モデルごとの構造化出力定義の違いを吸収する部分です。現在はChatGPT形式をベースにしていますが、これには潜在的な問題があります： **もしChatGPT形式で表現できない構造化出力を求めるプロバイダが出てきたら？** より柔軟なスキーマ変換の仕組みについては、実現可能性が見えてきたら対応したいです。 その他、今後の改善点として考えているのは： - MCPクライアントの実装- DSLベースのワークフロー定義- LangGraph風のステートマシン連携機能 他にもやるべきことはたくさんありますが、一歩一歩進めていきたいと思います。また進展があれば記事にしようと思うので、ご期待ください！

苦労した点と今後の課題

MCP時代のAIエージェント開発において、構造化出力と型の扱いは非常に重要です。Haskellの型システムを活かすことで、より安全で保守性の高いAIエージェントが作れると考えています。 コードやライブラリはすべて[GitHub](https://github.com/jtamu/lgchain-hs)で公開しています。フィードバックやコントリビューションをお待ちしています！

まとめ

HaskellでLangchain風のAIエージェントライブラリを実装してみたら楽しすぎた件〜基盤実装編〜

本記事では、以下の前提で解説します。<ul><li>プライベートサブネット内にEC2インスタンスが配置されている</li><li>AWS Identity and Access Management (IAM) の適切な設定がされている</li></ul>

前提

EC2 Instance Connectを使用すれば、踏み台サーバーや有料のVPCエンドポイントを作成する必要がありません。よってコストを削減することができます（個人的にこれが一番嬉しい） プライベートサブネットにあるEC2にEICを利用するには、EC2 Instance Connect Endpoint を作成する必要がありますが、インターフェース型のVPCエンドポイントとは異なり、料金は発生しません。

1. コストを抑えられる

従来のSSH接続では、秘密鍵の管理が必要ですが、EICでは一時的なSSHキーを使用するため、鍵の管理や漏洩リスクを減らすことができます。

2. SSH鍵の管理が不要

IAMポリシーを利用して、どのユーザーがどのEC2にアクセスできるかを制御できます。これにより、必要な権限を持つユーザーだけがEC2に接続できるようになります。

3. 簡単なIAM権限管理

踏み台サーバーによるSSH接続、SSM Session Manager、EC2 Instance Connectの比較をするとこんな感じです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/40af26630c574f1d8b2f46376efbffe4/image.png" alt="">

比較表

EC2 Instance Connectを利用するメリット

先に言っておくと、使いづらいところもあります。<ul><li>一つのVPCに対して1つのEICエンドポイントしか設定できない<ul><li>複数サブネットにEC2がある場合は不便です。。</li></ul></li><li>DBeaverなどのデータベース管理ツールでSSHトンネルでのDBインスタンスへの接続はできない<ul><li>上記を実現するには踏み台サーバー一択かも？</li></ul></li></ul>

EC2 Instance Connectの痒いところ

プライベートサブネットにあるEC2にEICを利用するには、EC2 Instance Connect Endpoint （以下、EICエンドポイント） を作成する必要があります。ただその前に、EICエンドポイントにアタッチするセキュリティグループを作成します。<ul><li>インバウンドルール<ul><li>特に設定する必要なし。</li></ul></li><li>アウトバウンドルール<ul><li>EC2インスタンスのセキュリティグループを許可します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d669783403354aae839c61f44ec51a4c/image.png" alt=""></li></ul></li></ul>上記ルールを設定すればOK。

1. EC2 Instance Connect エンドポイント用のセキュリティグループを作成

次に、先ほど作成したセキュリティグループを使ってEICエンドポイントを作成します。<ul><li>VPCマネジメントコンソールで「エンドポイント」を選択し、「エンドポイントを作成」をクリック</li><li>タイプ：「EC2 インスタンス接続エンドポイント」を選択<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a9770ac435804063afbff87a4ae21783/image.png" alt=""></li><li>ネットワーク設定<ul><li>EC2インスタンスが配置されているVPCを選択します。</li></ul></li><li>セキュリティグループ<ul><li>1で作成したセキュリティグループをアタッチします。</li></ul></li><li>サブネット<ul><li>EC2インスタンスが配置されているサブネットを選択します。</li></ul></li><li>※見落としがち！クライアントIPの保持<ul><li>SSH接続先のEC2にIP制限を設けたい場合は「クライアントIPの保持」にチェックを入れてください！有効化するとEICエンドポイントは、クライアントIPのアドレスを保持する様になるため、インバウンドルールにて、特定のクライアントIPを許可する設定が可能になります。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fc3ce98b8c984a5e99710d62f1ccba67/image.png" alt=""></li></ul></li></ul>上記設定で「エンドポイントを作成」を押せばEICエンドポイントの作成が完了します。

2. EICエンドポイントを作成

EC2側のセキュリティグループ（インバウンドルール）を設定します。特定のIPアドレスのみSSH（ポート22）を許可するように設定します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/881712727d084c2191a3b814429a8651/image.png" alt="">

3. セキュリティグループの設定

設定手順

<ul><li>該当のインスタンスを選択</li><li>「接続」をクリック</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c9c0ef7255904e958898ba1fc1eca7a7/image.png" alt=""></li><li>EC2 Instance Connectのタブから「EC2 Instance Connect エンドポイントを使用して接続する」を選択して接続。</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/13ea4512818f47b091fa26ce08b67c4a/image.png" alt=""></li><li>じゃーん</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e71ebaa55786477b985f668037713cc4/image.png" alt=""></li></ul>

マネコンから

インスタンスIDがわかっていればローカル端末から接続することも可能です。<pre><code>$ aws ec2-instance-connect ssh --instance-id i-0e5e0f3e85568e95e --connection-type eice</code></pre> じゃーん<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/216afa2a8d4e46608aaaf3f4c715f1ed/image.png" alt="">

ローカルからCLIで接続

接続してみた

AWSの運用コストに関してシビアなプロジェクトであれば、少しでも運用コストは下げたいところ。今回のEC2 Instance Connectが一つの選択肢になれば幸いです。

終わりに

EC2 Instance Connectでコスト削減！プライベートサブネットのEC2に接続してみたよ

Waydroidのインストール手順は<a href="https://docs.waydro.id/usage/install-on-desktops#ubuntu-debian-and-derivatives" target="_blank" rel="noopener noreferrer">こちら</a>の公式ドキュメントに従うのがいいと思います。注意点としては、そこにも書いてあるとおり、Waylandが有効になっている必要があるため、まずは<a href="https://linuxconfig.org/how-to-enable-disable-wayland-on-ubuntu-22-04-desktop" target="_blank" rel="noopener noreferrer">How to enable/disable wayland on Ubuntu Desktop</a>の手順に従ってWaylandを有効化してください。Waydroidを起動するには1回PCを再起動してログインの際にUbuntu on Waylandを選択する必要があります。 ※ウインドウサーバを切り替えることでなんらかの不具合が発生するかもしれませんが、自分の環境では今の所特に目立った問題はなく使えています。

Waydroidのインストール

インストールが完了したらAppsの中にWaydroidが入っているので起動します。そうすると、Androidのインストール画面が出てきますが、ここでGAPPSを選択してください。VANILLAの方だとGoogle Play Storeが使えないみたいです。 Google Play Storeを使えるようにするためにはGoogleにデバイスを登録する必要がありますが、すぐに終わります。<a href="https://docs.waydro.id/faq/google-play-certification" target="_blank" rel="noopener noreferrer">こちら</a>の手順に従ってデバイスを登録してください。 デバイスの登録ができたら、Waydroidを起動してください。Androidの画面が起動するはずです。デバイス登録が反映されるまで少し時間がかかるようなので、アラートが出るようでしたら数分待ってから再度起動してください。

Waydroidの初期化

Androidの画面は適当に弄っていれば操作方法はわかってくると思います。自分の場合はキーバインディングに若干の問題がありましたが（特に、Googleアカウント入力の際に@を押すと[が入力されてしまいました）、タブレットのように下からAndroid画面上にキーボードが出てくるので、押せないキーはそれを使いました。本当は直し方があるんだと思いますが、とりあえずKindleを読みたいだけなので一旦いいかなということで。 Kindleのインストール方法自体は普通のタブレットとかと同じなので割愛します。 Ryzen CPUを使用している場合は、Kindleがサポートされていないと表示されると思いますが、その場合はlibndkをインストールしてください。インストール方法は<a href="https://github.com/casualsnek/waydroid_script?tab=readme-ov-file#interactive-terminal-interface" target="_blank" rel="noopener noreferrer">こちら</a>の対話型のインターフェースを使うのがわかりやすいと思います。 参考までにlibndkについては以下perplexityの引用です：<pre><code>libndk（Native Development Kit Translation）は、x86系プロセッサを搭載したAndroidデバイスでARM向けのアプリケーションを実行するための変換レイヤーです[1][4]。この技術により、x86プラットフォーム上でARMバイナリを実行することが可能になります[3]。


libndk の主な特徴は以下の通りです：


1. ARM命令をx86命令に変換する機能を提供[1]
2. Android NDK（Native Development Kit）と連携して動作[3]
3. AMD CPUを搭載したデバイスでの使用が推奨される[4][5]


ただし、libndk はすべてのアプリケーションで完璧に動作するわけではありません。一部のアプリケーションでは、ログイン画面で停止するなどの問題が報告されています[4]。そのような場合、代替として libhoudini という別の変換レイヤーを使用することもあります[4][5]。

開発者やユーザーは、アプリケーションの互換性やパフォーマンスに応じて、libndk と libhoudini を使い分けることがあります[5]。


Citations:
[1] https://qiita.com/y_q/items/b22898d903820fc1f6f8
[2] http://xlog.insnhgd.com/2?locale=ja
[3] https://github.com/sickcodes/Droid-NDK-Extractor
[4] https://sumadoratyper.net/notes/7f721210cfdb91577e29e1aba980bb4a2baccecf/
[5] https://wiki.archlinux.jp/index.php/Waydroid
[6] https://zenn.dev/nyarla/scraps/2463d15a5f02c8</code></pre>

Kindleのインストール

UbuntuでKindleが読めるようになるまで

今回は、UbuntuでKindleを読む方法をご紹介しました。恐らく自分の知る限りでは最も王道な方法にもかかわらず実はあまり知られていない方法かと思います。ぜひ試してみてください。

さいごに

UbuntuでもKindleを読みたい（Wineじゃないよ）

リポジトリは<a href="https://github.com/jtamu/ojtalk" target="_blank" rel="noopener noreferrer">こちら</a>です。使い方はREADMEに書いてあるとおりです。 仕組みとしてはDocker環境のなかでOpenJTalkを実行しています。（<a href="https://zenn.dev/kotaproj/books/raspberrypi-tips/viewer/038_kiso_openj" target="_blank" rel="noopener noreferrer">こちら</a>の記事を参考にさせていただきました。） えっと、短いですが以上ですw

本文

そもそもなんでsayコマンドに興味を持ったかというと、<a href="https://zenn.dev/magicmoment/articles/play-sound-command-20241205" target="_blank" rel="noopener noreferrer">こちら</a>の記事を読んだからです。今までそんなに意識してませんでしたが確かに、実行時間が長いコマンドが終わったら「終わったよ」って声かけてくれたら嬉しいなと思ったからです。コマンドなのでシェルに組み込めば他にも色々な用途に使えそうだなと思いました。

sayコマンドに興味を持ったきっかけ

<ul><li><a href="https://zenn.dev/magicmoment/articles/play-sound-command-20241205" target="_blank" rel="noopener noreferrer">長い処理には通知音コマンドを仕込んでおくと捗るぞ</a></li><li><a href="https://zenn.dev/kotaproj/books/raspberrypi-tips/viewer/038_kiso_openj" target="_blank" rel="noopener noreferrer">🗣OpenJTalkでおしゃべりする - ⭐｜ラズベリーパイのレシピ</a></li></ul>

参考資料

あとがき

Ubuntuにもsayコマンドを導入したい

基本設計とは、システム開発における工程の一つで、要件定義で定義した要件を機能別に分け、それぞれの機能が「何を実現するのか」を具体的に決定することです。基本設計の工程ではシステムの全体像を大まかに捉えることを目指します。基本設計の結果や成果をまとめた資料を基本設計書といいます。

基本設計とは？

システム開発は「要件定義」「基本設計」「詳細設計」「開発」「導入」という流れで行われます。基本設計は要件定義で開発するシステムの目的を明らかにした後に、それをどのように実現するのかという概要をまとめる役割を持っています。

システム開発での役割

インフラとはインフラストラクチャーの略で、システムやアプリケーションを動かすために必要な基盤部分を指します。そのため、インフラでの開発はコードを書くプログラミングを行いません。インフラ開発をする場合には、通常のシステム開発とは基本設計に必要な項目が異なり、サーバ数やサーバのスペック、OSを何にするかの指定などを基本設計に盛り込む必要があります。

インフラの場合は、基本設計に必要な項目が異なる

システム開発において外部に開発を委託する場合が多くあります。その場合に発注時点の要望と実際の開発の方向性が合っているかをすり合わせる必要があり、そこで重要な役割を果たすのが基本設計です。基本設計の工程は発注者側にシステムの完成の全体像を提示する役割と、開発者側にシステム開発の方法を提示する役割の二つを担っており、両者の方向性を合わせることができます。

方向性を合わせるため

作業工程の途中で問題が見つかった場合、それ以前の作業段階に戻ってやり直さなければなりません。システム開発は前の工程を全て完成させてから次の工程に移る手法をとるため、手戻りをすることになった場合は費用と時間の大幅なロスにつながります。しかし、基本設計で要件定義の内容を実現する方法をしっかりとまとめておけば、手戻りを防ぐことができます。無駄なコストをかけないために、基本設計をしっかりと行うことは重要です。

手戻りをなくすことができる

基本設計、詳細設計を行う重要性についてまとめましたが、システムエンジニアであればどちらの設計も行う機会があると思います。それぞれがどのような目的、役割を持っている工程なのかを理解した上で作業を行わなければ、以降の工程がスムーズに進まなくなる可能性があります。費用や時間などコストを見据えて、費用な工程をしっかりとこなしていくことがとても大事になります。自分自身もそうですが、今一度各工程に必要な目的などをしっかりと確認した上で作業を行っていきたいですね。

最後に

基本設計が重要な理由

基本設計の作成

詳細設計とはシステムやソフトウエアを開発する工程の一つになります。要件定義や基本設計で定めた要素や実践方法の詳細を具体的に定義する工程となります。詳細設計では開発を行う上での、システムの仕様の詳細をまとめる役割を持ちます。また、開発者向けの詳細設計や成果物をまとめた資料を詳細設計書といい、詳細設計書はシステム設計とシステム開発の橋渡しとなる重要な資料です。

詳細設計とは？

詳細設計は、システム開発の工程において基本設計の次に行います。基本設計で大まかに定められた内容に基づき、システムの実現方法を詳細に決定していきます。基本設計と詳細設計では、目的が大きく異なります。基本設計ではシステムのユーザーが直接目に見える部分の機能を構築するために設計します。詳細設計では基本設計で構築した機能を実現するためのシステムの中身の部分を構築するために設計します。

基本設計との違いとは？

詳細設計を行うことで、開発の品質水準を安定させることができます。細かく開発方法を設定することで、開発者の経験値に依存することなく、安定したパフォーマンスで開発ができるようになります。

一定水準の品質を保つため

開発者が一から開発の方法を考えることになった場合、多くの時間と労力が必要になります。しかし、事前に開発の具体的なルールや方向性を決定しておくことで、効率的に開発が行えるようになります。また、開発を効率的に行うことにより、開発後の検証や確認作業に時間を多く費やすことができるようになります。「生産性の向上」および「システムの品質の向上」を実現することができることから、詳細設計は重要な役割を果たす工程と言えます。

効率的な開発のため

開発した後に詳細設計書をもとにシステムを検証することができます。検証をせずにリリースしてしまった場合、システムエラーが生じてしまう可能性がありますが、詳細設計書があれば事前に回避することができます。詳細設計書に基づいて検証を行えば、検証作業も効率的に行えます。

開発後の検証を行うため

冒頭にも記載しましたが、システムエンジニアとは他人が見てもある程度理解のできる成果物が必要になります。どのようなデータが必要になるか、どんな機能が実装されているのか、どのような場合にエラーが発生するのか、etc...挙げるとキリがありませんが、様々な状況・場面を想定してルールを定義することはとても重要になります。ルールのない状態から開発するのは経験が浅いと本当に難しく、また経験がある程度あってもユーザーやクライアントにシステムの説明を行う際の資料がソースコードしかないと相手が理解するのに時間を要します。その指標となるものとして、詳細設計が存在するので作業工程の意味と必要性を理解した上、作業を進めていくことが大事だと思います。

なぜ詳細設計が必要なのか

詳細設計の作成

タイトルに書いた通り、ノーコード開発サービスとなります。『CELF』とは、「Excel（Excelライクな業務アプリを）」＋「SELF（自分の手でカイゼン）」を掛け合わせた名前です。Excelファイルから自動的に業務アプリを生成することができます。見た目や使用感や関数計算はExcelと同じなので、持っているExcel の知識で作業ができます。また、クラウド上にデータベースを持つので、大量データの保存・検索などが使えます。ITエンジニアではない人でも、プログラム言語を覚える必要なく業務アプリを作成することが可能です。今や小学校で学べる、「ビジュアル・プログラミング」を用いて、部品をドラック＆ドロップで処理を組み立てて開発ができます。

CELFはどんなものなのか

CELFを使うことでExcelファイルを業務アプリにすることが可能。<ol><li>今使用しているExcelファイルをアップロード</li><li>管理するデータ項目を指定</li><li>指定したデータ項目を読み込むことでオリジナルの業務アプリが完成</li></ol>CELFにはテンプレートも存在します。また、指定したいデータにはラベルやデータ形式などを設定することも可能です。

CELFでどんなことが可能なのか

業務では、予算実績管理や管理帳票、見積管理、請求管理、案件管理、販売管理、在庫管理、勤怠管理、生産管理、仕訳データ変換、顧客管理、原価管理、受注管理、人事考課と目標管理、契約管理、マスタ管理、etc...様々な業務で使用されています。大手企業での導入事例も多くあり、専門的なプログラミング技術がなくても導入できるため、コスト削減や働き方改善につながっている企業もあります。

CELFの利用実績

CELFについて、簡単な説明となりましたが本当に作業が簡単で初心者でも取り掛かりやすいのが特徴だと思います。データベースからデータを取得する際SQLの知識があれば、より高度な処理ができるアプリにすることも可能です。初めての方から、プログラミング経験者まで幅広く使えるサービスになっています。30日間無料トライアルもできるので興味があればぜひチャレンジしてみてください。

「CELF」はノーコード開発サービス

CELFとは？

これまでの話の流れが追えていればcan-i-deployの仕組みはなんとなく想像がつくと思います。基本的な仕組みとしては想像通りで、コンシューマが契約を更新後に、更新された契約を引き続きプロバイダ側が満たしているかをブローカー経由でチェックしに行きます。 注意すべき点は、コンシューマがデプロイ可能かどうかを判断するためには、現在のプロバイダのデプロイバージョンに対して確認する必要があるということです。かつ、本番環境・開発環境など、一般的に複数のデプロイ環境があります。デプロイしようとしている環境が開発環境であれば、開発環境にデプロイされているプロバイダのバージョンに確認する必要があります。 そうなってくると、Pactブローカーに現在どのバージョンがどの環境にデプロイされているかという情報を予め教えてあげる必要があります。これを、record-deploymentといいます。 というわけで、can-i-deployの前準備として、一旦現在デプロイされているコンシューマ・プロバイダに対して手動でrecord-deploymentを実行してみました。 <pre><code>~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version 445fec738b5a4761bda6379ca37286062d079401 --environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

No environment found with name 'dev'. Available options: production, test

~/work/auth0-next-custom$&nbsp;</code></pre> dev環境がないと言われました。production, testはそのまま使えるようですが、それ以外はまず環境自体を定義してあげる必要があるようです。対応するアクションは、 create_environment です。 <pre><code>~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker create-environment --name dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Created dev environment in the Pact Broker with UUID xxxxxxxxxxxx

~/work/auth0-next-custom$&nbsp;</code></pre> 無事作成できました。それでは再度record-deploymentを実行してみましょう。 <pre><code># コンシューマ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version 445fec738b5a4761bda6379ca37286062d079401 --environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Recorded deployment of auth0-next-custom version 445fec738b5a4761bda6379ca37286062d079401 to dev environment in the Pact Broker.

~/work/auth0-next-custom$&nbsp;


# プロバイダ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant google-login-back --version f042bc78690b272fed7ab6735bcacd4a39bccf15 --environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Recorded deployment of google-login-back version f042bc78690b272fed7ab6735bcacd4a39bccf15 to dev environment in the Pact Broker.

~/work/auth0-next-custom$&nbsp;</code></pre> 今度は成功し、コンシューマとプロバイダの両方のデプロイバージョンをブローカーに記録できました。record-deploymentした後の"Pact Matrix" (コンシューマ x プロバイダのバージョン一覧表) は以下のようになりました。緑タグでデプロイ環境が示されていますね。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/946b7d6e38b94d2aaef7267c5e5d3b9f/Pasted%20image%2020241002223539.png" alt="">

record-deployment

それでは試しに、ローカル環境でcan-i-deployを実行してみましょう。 <pre><code># コンシューマ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version 445fec738b5a4761bda6379ca37286062d079401 --to-environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Computer says yes \o/&nbsp;

CONSUMER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| C.VERSION&nbsp;| PROVIDER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| P.VERSION&nbsp;| SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | 445fec7... | google-login-back | f042bc7... | true&nbsp;&nbsp;&nbsp;| 1&nbsp;&nbsp;&nbsp;&nbsp;

VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/611750a58c1c1b4697e602671bf23021bbe60df7/metadata/Y3ZuPTQ0NWZlYzczOGI1YTQ3NjFiZGE2Mzc5Y2EzNzI4NjA2MmQwNzk0MDE/verification-results/319 (success)

All required verification results are published and successful
~/work/auth0-next-custom$&nbsp;

# プロバイダ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version f042bc78690b272fed7ab6735bcacd4a39bccf15 --to-environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Computer says yes \o/&nbsp;

CONSUMER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| C.VERSION&nbsp;| PROVIDER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| P.VERSION&nbsp;| SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | 445fec7... | google-login-back | f042bc7... | true&nbsp;&nbsp;&nbsp;| 1&nbsp;&nbsp;&nbsp;&nbsp;

VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/611750a58c1c1b4697e602671bf23021bbe60df7/metadata/Y3ZuPTQ0NWZlYzczOGI1YTQ3NjFiZGE2Mzc5Y2EzNzI4NjA2MmQwNzk0MDE/verification-results/319 (success)

All required verification results are published and successful
~/work/auth0-next-custom$&nbsp;</code></pre> コンシューマ・プロバイダのどちらもデプロイバージョンに対して検証が成功していることが確認できました。 それではいよいよ、can-i-deployをCI/CDに組み込みましょうと言いたいところですが、ここで少しThinking Timeを挟みました。というのも、プロバイダのパイプラインにcan-i-deployを組み込む意味があるのか？という疑問が生じたためです。結論としては、プロバイダのパイプラインにも組み込む必要があるとの思いに至りました。理由としては、以下の2点が挙げられます。 理由の1つ目：現状プロバイダのパイプラインで契約の検証を行っていますが、それは常に最新の契約に対して行っており、現在のコンシューマのデプロイバージョンに対してではありません。ということは、コンシューマのデプロイバージョンの契約をプロバイダが満たしていなかったが、契約が更新され、最新の契約をプロバイダが満たすようになった場合、現状のテストは成功するため、契約をサポートしていないプロバイダがデプロイされてしまいます。 理由の2つ目：そもそも、マイクロサービスにおいて特定のサービスがプロバイダとしてしか振る舞わないという保証はない気がします。例えば、投稿バックエンドサービスは投稿フロントエンドのプロバイダですが、投稿バックエンドサービスからメール通知サービスを呼び出す場合、同サービスはコンシューマとしても振る舞います。現状役割がプロバイダだけだったとしても、将来的にコンシューマになる可能性を残しておいたほうがいいと考えます。そうなってくると、プロバイダもコンシューマと同じフローにしておいたほうが良さそうです。

ローカル環境でcan-i-deployしてみる

それではいよいよ、can-i-deployをCI/CDに組み込みましょう。デプロイ前にcan-i-deployするだけでなく、デプロイ後にrecord-deploymentするのもお忘れなく。デプロイ環境はCodeBuildで指定した環境変数で動的に切り替わるようにしておきます。 コンシューマ<pre><code>diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
index 6bf857f..e94b165 100644
--- a/app/api/microposts/service.ts
+++ b/app/api/microposts/service.ts
@@ -1,5 +1,4 @@
&nbsp;import axios from "axios";
-import { NextRequest } from "next/server";
&nbsp;
&nbsp;export default function MicropostService(baseUrl: string) {
&nbsp; &nbsp;const ping = async (): Promise&lt;{message: string}&gt; =&gt; {
diff --git a/buildspec.yml b/buildspec.yml
index 7d35759..71b2f6b 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -9,8 +9,10 @@ phases:
&nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp;commands:
&nbsp; &nbsp; - npm run test
-&nbsp; &nbsp;- npm run publish
+&nbsp; &nbsp;- npm run pact:publish
+&nbsp; &nbsp;- npm run pact:can-i-deploy
&nbsp; build:
&nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp;commands:
-&nbsp; &nbsp;- aws amplify start-job --app-id xxxxxxxxxxxx --branch-name main --job-type RELEASE
+&nbsp; &nbsp;- ./deploy.sh
+&nbsp; &nbsp;- npm run pact:record-deployment
diff --git a/deploy.sh b/deploy.sh
new file mode 100755
index 0000000..89ee0a5
--- /dev/null
+++ b/deploy.sh
@@ -0,0 +1,28 @@
+#!/bin/bash -e
+
+# Amplifyアプリのパラメータを設定
+APP_ID="xxxxxxxxxxxx"
+BRANCH_NAME="main"
+JOB_TYPE="RELEASE"
+
+# デプロイジョブを開始
+JOB_ID=$(aws amplify start-job --app-id $APP_ID --branch-name $BRANCH_NAME --job-type $JOB_TYPE --query 'jobSummary.jobId' --output text)
+
+echo "Started job with ID: $JOB_ID"
+
+# ジョブの状態を監視
+while true; do
+ JOB_STATUS=$(aws amplify get-job --app-id $APP_ID --branch-name $BRANCH_NAME --job-id $JOB_ID --query 'job.summary.status' --output text)
+
+ echo "Current job status: $JOB_STATUS"
+
+ if [ "$JOB_STATUS" == "SUCCEED" ]; then
+&nbsp; echo "Job completed successfully"
+&nbsp; break
+ elif [ "$JOB_STATUS" == "FAILED" ]; then
+&nbsp; echo "Job failed"
+&nbsp; exit 1
+ fi
+
+ sleep 10
+done
diff --git a/package.json b/package.json
index e3b09ed..677ada9 100644
--- a/package.json
+++ b/package.json
@@ -8,7 +8,9 @@
&nbsp; &nbsp;"start": "next start",
&nbsp; &nbsp;"lint": "next lint",
&nbsp; &nbsp;"test": "jest",
-&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; "pact: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; "pact:can-i-deploy": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
+&nbsp; "pact:record-deployment": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
&nbsp; },
&nbsp; "dependencies": {
&nbsp; &nbsp;"@auth0/nextjs-auth0": "^3.5.0",</code></pre> package.jsonとか汚くてすいません。この辺綺麗にするのは今後の課題とさせてください。 注意すべき点は、record-deploymentを行うタイミングです。このパイプラインではamplifyのstart-jobを行うことでデプロイを開始していますが、start-job実行後にそのままrecord-deploymentを行ってしまうと、amplifyのjobが失敗した場合に本来デプロイされていないはずのものがrecord-deploymentされてしまい不整合が生じてしまいます。そのためstart-jobするだけでなく定期的にget-jobにより状態を監視することで、デプロイが成功した場合のみrecord-deploymentを行うことを実現しています。 プロバイダ<pre><code>diff --git a/buildspec.yml b/buildspec.yml
index 68e505c..6f1d138 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -18,12 +18,14 @@ phases:
&nbsp; &nbsp; - sleep 5 # 起動待ち
&nbsp; &nbsp; - docker compose run python ./test.sh
&nbsp; &nbsp; - docker compose stop
+&nbsp; &nbsp;- docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
&nbsp; &nbsp; - aws s3 cp s3://xxxxxxxxxxxx/google_login_back/dev.json .chalice/deployed/dev.json || true
&nbsp;
&nbsp; build:
&nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp;commands:
&nbsp; &nbsp; - chalice deploy
+&nbsp; &nbsp;- docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant google-login-back --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
&nbsp;
&nbsp; post_build:
&nbsp; &nbsp;on-failure: ABORT</code></pre> こちらも汚くてすみません。こちらはコンシューマとは違い同期的にデプロイされるため、そのままrecord-deploymentを行って大丈夫です。

can-i-deployをCI/CDに組み込む

それではパイプラインが実装できたので、実際にいくつかのケースにおいて期待通りの挙動をするか確認してみましょう。まずは、契約の互換性を保った状態でプロバイダを更新してみます。 具体的には、投稿一覧取得APIにおいて各投稿につけられたlike(いいね)の数も取得する、という想定とします。実際にはそもそも投稿保存APIでいいねの数も保存しなければいけないところですが、CI/CDの挙動を確認したいだけなので一旦ランダムな自然数を返します。 現在の投稿一覧取得APIに関する契約は以下です。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a4bda8a8685b46e18ab17c91cc72ab2b/Pasted%20image%2020241003223938.png" alt="">まだいいねの数に関して契約が更新されていないので、今のところ各投稿はcontentとpostedAtしか含まれないようになっています。現状コンシューマ側でcontentとpostedAtしか使っていなかったとして、プロバイダ側でlikeも返すようになったとしても、コンシューマにしてみれば必要なものはちゃんと返しているので挙動的には問題ないと考えられます。なので、契約の互換性は保たれていると考えました。 それでは、プロバイダ側の修正を行います。<pre><code>diff --git a/app.py b/app.py
index cfc1d9a..a05a689 100644
--- a/app.py
+++ b/app.py
@@ -7,6 +7,7 @@ from datetime import datetime, timedelta, timezone
&nbsp;from chalicelib.models import Microposts
&nbsp;from chalicelib.utils import login
&nbsp;import jwt
+import random
&nbsp;
&nbsp;
&nbsp;app = Chalice(app_name="google_login_back")
@@ -177,7 +178,7 @@ def get_micropost_for_auth0():
&nbsp; &nbsp; &nbsp;return Response(body=None, status_code=401)
&nbsp;
&nbsp; &nbsp;posts = Microposts.query(payload.get("sub"))
-&nbsp; res = [post.to_simple_dict() for post in posts]
+&nbsp; res = [{**post.to_simple_dict(), "like": random.randrange(1000)} for post in posts]
&nbsp; &nbsp;return Response(body=res, status_code=200)</code></pre> ローカルでAPIを実行し動作確認を行います。各投稿にランダムなlikeが振られていることが確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/307c8275ae954ac68243432ea5b38675/Pasted%20image%2020241005172459.png" alt=""> プッシュ前のPact Matrixは以下です。これがプッシュ後はどのように変わるでしょうか。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e8741356a1424a859a29741a1d30d9a3/Pasted%20image%2020241003224105.png" alt=""> プッシュ後<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/65df48d337d34c879c43e4e2d058216a/Pasted%20image%2020241003224649.png" alt=""> 無事デプロイが成功し、プロバイダのdev環境タグが最新のコミットのバージョンに移動しました。プロバイダのCI/CDが通ったことで、契約はちゃんと守られているとPactが判断したことがわかります。

契約の互換性を保った状態でプロバイダを更新する

ひとつ上のセクションでは、契約の互換性を保った状態でプロバイダを更新しました。それの続きで、今度は更新したプロバイダに合った形で契約を更新してみます。 具体的には、投稿一覧取得APIで各投稿にいいねの数を含めるようにしたので、契約もそれに合う形で各投稿にいいねの数を含む形に修正しましょう。結果はどうなると思いますか？もちろん、テストが成功し正常にデプロイされると思いますよね？それでは、実際にやってみます。<pre><code>diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
index e94b165..a1bac9f 100644
--- a/app/api/microposts/service.ts
+++ b/app/api/microposts/service.ts
@@ -10,7 +10,7 @@ export default function MicropostService(baseUrl: string) {
&nbsp; &nbsp; &nbsp;return res.json();
&nbsp; &nbsp;}
&nbsp;
-&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string}&gt;&gt; =&gt; {
+&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string, like: number}&gt;&gt; =&gt; {
&nbsp; &nbsp; &nbsp;const response = await axios.get(`${baseUrl}/auth0/microposts`, {
&nbsp; &nbsp; &nbsp; &nbsp;headers: {
&nbsp; &nbsp; &nbsp; &nbsp; "Authorization": `Bearer ${accessToken}`,
diff --git a/app/microposts/page.tsx b/app/microposts/page.tsx
index eef1672..f2d9a7e 100644
--- a/app/microposts/page.tsx
+++ b/app/microposts/page.tsx
@@ -10,7 +10,7 @@ import { useUser } from '@auth0/nextjs-auth0/client';
&nbsp;export default withPageAuthRequired(() =&gt; {
&nbsp; const router = useRouter();
&nbsp; const { user, error, isLoading } = useUser();
- const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string}&gt;);
+ const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string, like: number}&gt;);
&nbsp; const [content, setContent] = useState("");
&nbsp;
&nbsp; useEffect(() =&gt; {
@@ -46,6 +46,7 @@ export default withPageAuthRequired(() =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;Image className="w-12 h-12 rounded-full mr-2" src={user.picture ?? ''} alt="facePicture" width={600} height={600} /&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;div className="flex-grow"&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;h3 className="m-0 text-lg"&gt;{micropost.content}&lt;/h3&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p className="my-1 text-sm text-gray-700"&gt;{micropost.like} いいね&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{user.name}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{dayjs(micropost.postedAt).format('YYYY-MM-DD HH:mm:ss')}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/div&gt;
diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index 44d123d..0c2d5b9 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -2,7 +2,7 @@ import MicropostService from "@/app/api/microposts/service";
&nbsp;import { MatchersV3, PactV3 } from "@pact-foundation/pact";
&nbsp;import path from "path";
&nbsp;
-const {eachLike, string, regex, timestamp} = MatchersV3;
+const {eachLike, string, integer, timestamp} = MatchersV3;
&nbsp;
&nbsp;const provider = new PactV3({
&nbsp; &nbsp;dir: path.resolve(process.cwd(), 'pacts'),
@@ -50,6 +50,7 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;body: eachLike({
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like: integer(123)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -57,9 +58,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; expect(JSON.stringify(response)).toStrictEqual(
-&nbsp; &nbsp; &nbsp; &nbsp; JSON.stringify([{content: 'Hello, World.', postedAt: '2024-08-21 23:01:01'}])
-&nbsp; &nbsp; &nbsp; );
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> ローカルで実際に画面を開いてみます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/dcb3efb332024901b8daf5ec35097fd8/Pasted%20image%2020241003225411.png" alt="">無事にいいねの数が表示されました。 それではデプロイします。 プッシュ前<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d8011d117a944e9f8fc91ad1a24b4e37/Pasted%20image%2020241003224649.png" alt=""> プッシュしたところ、パイプラインでエラーが発生しました。<pre><code>&gt; auth0-next-custom@0.1.0 pact:can-i-deploy
&gt; docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}


Computer says no ¯\_(ツ)_/¯


CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|-----------|----------|--------
auth0-next-custom | 87ad0f7... | google-login-back | ???&nbsp; &nbsp; | ???&nbsp; &nbsp;|&nbsp; &nbsp; &nbsp;


There is no verified pact between version 87ad0f757d72fca441573927194c097da1850b9c of auth0-next-custom and the version of google-login-back currently deployed or released to dev (9a796efc330c87c243e62bc44ecbc53d02e21081)


[Container] 2024/10/03 14:08:27.936109 Command did not exit successfully npm run pact:can-i-deploy exit status 1
[Container] 2024/10/03 14:08:27.941294 Phase complete: PRE_BUILD State: FAILED_WITH_ABORT
[Container] 2024/10/03 14:08:27.941316 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: npm run pact:can-i-deploy. Reason: exit status 1</code></pre> プッシュ後のPact Matrixは以下です。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/47f1bd3fad7d4cf8a4daa3a5dec3369e/Pasted%20image%2020241003231110.png" alt=""> 最初は意外でしたが、考えてみたらそりゃそうだわなって話です。我々からしたら、更新後の契約をプロバイダが満たしていることは明らかですが、Pactブローカーからしたら、まだ検証していないので満たしているかどうかはわかりません。なのでやるべきことははっきりしていて、コンシューマ側のCI/CDで契約が更新されたら、更新された契約に対してプロバイダ側の検証を行う必要があります。 Pactのドキュメントを漁っていたら、<a href="https://docs.pact.io/pact_broker/webhooks#example-cicd-and-webhook-configuration" target="_blank" rel="noopener noreferrer">こんな</a>シーケンス図がありました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/6256ea5e83fa45fbb7837394188e79a5/Pasted%20image%2020241003232519.png" alt="">次のタスクとしては上の図のようなフローを実現したいです。

コンシューマ側で互換性を保った形での契約の更新

今やプロバイダ側での契約検証はプロバイダのCI/CDに組み込まれているので、コンシューマ側での契約発行をトリガーにプロバイダのCI/CDを動かせば良いです。 Pactには契約が更新されたことを通知するwebhookがあるみたいですが、APIを呼び出す形なので実現するためにはそのためのリソース(API Gateway, Lambda, IAM Role等々)も作成しなければならず作業量が増えてしまいます。 なので今回は単純にコンシューマ側のパイプラインの中でプロバイダのパイプラインを呼び出す形でできないか検討しました。つまりCodePipelineを外部からトリガーできればよいです。それには以下のAWSコマンドの実行で実現可能です。<pre><code>aws codepipeline start-pipeline-execution --name PIPELINE_NAME</code></pre> めっちゃ簡単ですね。あとはpublishしてからcan-i-deployするまでの間に上記コマンドをcodebuild内で実行するだけです。ちなみに、上記を実行するために必要なポリシーのactionは<code>codepipeline:StartPipelineExecution</code> です。 さて、勘のいい人は気づいたと思いますが、上記はパイプラインを開始するだけなので、単純に上記をコンシューマのパイプラインに組み込むだけでは、can-i-deployは相変わらず失敗します。 ここで朗報です。can-i-deployの<code>--retry-while-unknown</code>オプションで待つことが可能みたいです。<pre><code>[--retry-while-unknown=TIMES]&nbsp;&nbsp;
# The number of times to retry while there is an unknown&nbsp;&nbsp;
verification result (ie. the provider verification is likely&nbsp;&nbsp;
still running)&nbsp;&nbsp;
# Default: 0</code></pre> 検証結果がない場合にリトライしてくれるとのことです。リトライ回数ということなのでプロバイダ側のCI/CDが正しくトリガーされなかったとか、プロバイダ側のCI/CDが異常終了して検証結果が反映されないなどの不具合の場合も無限にリトライし続けるということはないので安心です。リトライ間隔も<code>--retry-interval</code>オプションで指定できるようです。<pre><code>[--retry-interval=SECONDS]&nbsp;&nbsp;
# The time between retries in seconds. Use in conjuction with&nbsp;&nbsp;
--retry-while-unknown&nbsp;&nbsp;
# Default: 10</code></pre> うまく設計されていますね。感心しました。 それでは今回のユースケースにおいて、妥当なパラメータを検討します。今回はプロバイダは1つのみですが、依存するプロバイダが複数の場合もプロバイダのCI/CDは並列で動かすはずなので、遅くても10分には終わるという想定で設定します。また、リトライ間隔は10秒のままとします。そうすると最大リトライ回数は60回という計算になります。（60回リトライしても結果が不明な場合はcan-i-deployの結果を失敗側に倒すということ）

コンシューマのCI/CDからプロバイダのCI/CDを発火する（準備編）

では、実際にコンシューマのパイプラインに適用してみましょう。 まずはポリシーを追加します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e9428553947942c3a6e8048cea191699/Pasted%20image%2020241005152922.png" alt=""> プロバイダのパイプライン名は環境変数 PROVIDER_PIPELINES で管理します。（複数を入れる想定）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/79a9f00a144f4878838e20b314eff770/Pasted%20image%2020241005153927.png" alt=""> buildspecを修正します。<pre><code>diff --git a/buildspec.yml b/buildspec.yml
index 71b2f6b..41e8996 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -10,6 +10,7 @@ phases:
&nbsp; &nbsp;commands:
&nbsp; &nbsp; - npm run test
&nbsp; &nbsp; - npm run pact:publish
+&nbsp; &nbsp;- ./trigger_pipelines.sh
&nbsp; &nbsp; - npm run pact:can-i-deploy
&nbsp; build:
&nbsp; &nbsp;on-failure: ABORT
diff --git a/package.json b/package.json
index 677ada9..4c7e9ed 100644
--- a/package.json
+++ b/package.json
@@ -9,7 +9,7 @@
&nbsp; &nbsp;"lint": "next lint",
&nbsp; &nbsp;"test": "jest",
&nbsp; &nbsp;"pact: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; "pact:can-i-deploy": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
+&nbsp; "pact:can-i-deploy": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --retry-while-unknown 60 --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
&nbsp; &nbsp;"pact:record-deployment": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
&nbsp; },
&nbsp; "dependencies": {
diff --git a/trigger_pipelines.sh b/trigger_pipelines.sh
new file mode 100755
index 0000000..85c2d54
--- /dev/null
+++ b/trigger_pipelines.sh
@@ -0,0 +1,5 @@
+#!/bin/bash -xe
+
+for pipeline in $PROVIDER_PIPELINES; do
+ aws codepipeline start-pipeline-execution --name $pipeline
+done</code></pre> それでは、pushしてみましょう。CI/CDのログは以下のようになりました。<pre><code>&gt; auth0-next-custom@0.1.0 pact:can-i-deploy
&gt; docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --retry-while-unknown 60 --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
Computer says yes \o/&nbsp;
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | b160b72... | google-login-back | 9a796ef... | true&nbsp; &nbsp;| 1&nbsp; &nbsp;&nbsp;
VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/cf071c371a83627a39f9642722633bb0330d74a9/metadata/Y3ZuPWIxNjBiNzJiZGVjOWI1NzhhNTFhMTNmYTVmNWVjNjI0N2UzYjRlYmQ/verification-results/330 (success)
All required verification results are published and successful</code></pre> push後のPact Matrixです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ffe84cbaf90044179770c589e5da9d0a/Pasted%20image%2020241005160309.png" alt=""> 更新後の契約に対して無事にプロバイダ側の検証も成功していることが確認できました。

コンシューマのCI/CDからプロバイダのCI/CDを発火する（実践編）

次に、コンシューマ側で互換性を保たない形での契約の更新を行ってみます。 先程は投稿一覧で各投稿にいいねの数を追加しましたが、今回は同じノリでお気に入り数を追加してみます。ですが前回とは違い、先にコンシューマ側で契約を更新し実装を修正してしまいます。 コンシューマの修正差分は以下です。<pre><code>diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
index a1bac9f..9db8c68 100644
--- a/app/api/microposts/service.ts
+++ b/app/api/microposts/service.ts
@@ -10,7 +10,7 @@ export default function MicropostService(baseUrl: string) {
&nbsp; &nbsp; &nbsp;return res.json();
&nbsp; &nbsp;}
&nbsp;
-&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string, like: number}&gt;&gt; =&gt; {
+&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string, like: number, favorite: number}&gt;&gt; =&gt; {
&nbsp; &nbsp; &nbsp;const response = await axios.get(`${baseUrl}/auth0/microposts`, {
&nbsp; &nbsp; &nbsp; &nbsp;headers: {
&nbsp; &nbsp; &nbsp; &nbsp; "Authorization": `Bearer ${accessToken}`,
diff --git a/app/microposts/page.tsx b/app/microposts/page.tsx
index f2d9a7e..b16a5b5 100644
--- a/app/microposts/page.tsx
+++ b/app/microposts/page.tsx
@@ -10,7 +10,7 @@ import { useUser } from '@auth0/nextjs-auth0/client';
&nbsp;export default withPageAuthRequired(() =&gt; {
&nbsp; const router = useRouter();
&nbsp; const { user, error, isLoading } = useUser();
- const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string, like: number}&gt;);
+ const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string, like: number, favorite: number}&gt;);
&nbsp; const [content, setContent] = useState("");
&nbsp;
&nbsp; useEffect(() =&gt; {
@@ -47,6 +47,7 @@ export default withPageAuthRequired(() =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;div className="flex-grow"&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;h3 className="m-0 text-lg"&gt;{micropost.content}&lt;/h3&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{micropost.like} いいね&lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p className="my-1 text-sm text-gray-700"&gt;{micropost.favorite} お気に入り&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{user.name}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{dayjs(micropost.postedAt).format('YYYY-MM-DD HH:mm:ss')}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/div&gt;
diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index 0c2d5b9..ea14748 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -50,7 +50,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;body: eachLike({
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like: integer(123)
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like: integer(123),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; favorite: integer(456),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -58,8 +59,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
-&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like, favorite} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123 &amp;&amp; favorite == 456);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> ローカルで動作確認します。まだプロバイダ側が対応していないのでお気に入り数は表示されません。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/00d68dafe32e41b89da9c6b05cbe4f33/Pasted%20image%2020241005162202.png" alt=""> さて、pushしたのですがCI/CDで<a href="https://fu3ak1.hatenablog.com/entry/2020/11/22/122241" target="_blank" rel="noopener noreferrer">docker pullのLate Limit問題</a>で落ちまくるので急遽対応しました。（今までも実は落ちていたのですが、数回再実行すれば通っていたのでそのままにしていたのです）<code>docker login</code>するようbuildspecを更新し、<code>DOCKER_USER</code>, <code>DOCKER_TOKEN</code>環境変数を追加しました。 気を取り直して再度pushし、コンシューマ側のパイプラインが動き出しました。上で述べているように、コンシューマ側のパイプラインが動くとそれに伴ってプロバイダ側のパイプラインも動き出します。 プロバイダ側のパイプラインでエラーになりました。プロバイダ側でエラーになるとコンシューマ側も契約の検証ができないためパイプラインが失敗しデプロイは行われません。エラー内容は以下です。<pre><code>=================================== FAILURES ===================================
_ test_pacts[auth0-next-custom with request '\u30e6\u30fc\u30b6\u306e\u5168\u3066\u306e\u6295\u7a3f\u3092\u30ea\u30af\u30a8\u30b9\u30c8\u3059\u308b'1] _
Pact failure details:
Response element 'favorite' is missing at body[0]</code></pre> 各投稿にfavoriteがないので契約は満たされないという結果です。完全に予想通りです。その時のPact Matrixは以下です。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/81eb5a43eaa94235a1957473fde4d51b/Pasted%20image%2020241005170324.png" alt=""> では、今度は検証を成功させるべく、プロバイダ側を修正しましょう。差分は以下です。<pre><code>diff --git a/app.py b/app.py
index a05a689..c2987e5 100644
--- a/app.py
+++ b/app.py
@@ -178,7 +178,9 @@ def get_micropost_for_auth0():
&nbsp; &nbsp; &nbsp;return Response(body=None, status_code=401)
&nbsp;
&nbsp; &nbsp;posts = Microposts.query(payload.get("sub"))
-&nbsp; res = [{**post.to_simple_dict(), "like": random.randrange(1000)} for post in posts]
+&nbsp; res = [
+&nbsp; &nbsp; {**post.to_simple_dict(), "like": random.randrange(1000), "favorite": random.randrange(1000)} for post in posts
+&nbsp; ]
&nbsp; &nbsp;return Response(body=res, status_code=200)</code></pre> ローカルで動作確認します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/8d83101ca1ea4149a8974c2fb1d88d66/Pasted%20image%2020241005172948.png" alt=""> 問題なさそうなので、pushします。<pre><code>Computer says no ¯\_(&lt;span class='ace_cjk'&gt;ツ&lt;/span&gt;)_/¯
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|-----------|----------|--------
auth0-next-custom | b160b72... | google-login-back | ???&nbsp; &nbsp; | ???&nbsp; &nbsp;|&nbsp; &nbsp; &nbsp;
There is no verified pact between the version of auth0-next-custom currently deployed or released to dev (b160b72bdec9b578a51a13fa5f5ec6247e3b4ebd) and version 3b301dd771efeba855e6983d8723033e9f047ef0 of google-login-back
[Container] 2024/10/05 08:31:43.951369 Command did not exit successfully docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD} exit status 1</code></pre> あれ、おかしいですね。can-i-deployで失敗しました。その時のPact Matrixです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/2465a62efe7c40d88dfdefe54d3ffcf9/Pasted%20image%2020241005173744.png" alt=""> 以下の表だとわかりやすいでしょうか。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3ea9593a8c4040c2be69486db66df5af/image.png" alt="">新しい契約を満たすようになったプロバイダバージョンにおけるcan-i-deployでは、上記の真ん中の組み合わせの検証結果がほしいです。ポイントとしては、あくまで最新の契約ではなく、コンシューマのデプロイバージョンにおける契約に対して満たしているかを確認する必要があるということです。しかし、プロバイダのパイプラインで検証しているのは最新の契約のみなので、上記の表の通り旧契約に対しては未検証という結果になり、プロバイダのパイプラインが失敗します。 では、どうしたらいいのでしょうか？ ボツ案：コンシューマの新契約バージョン＝devデプロイバージョンになれば成功するので、コンシューマ側のパイプラインをもう一度手動で回せばいいのでは？と思いましたが、そうするとcan-i-deployでコンシューマの新契約バージョン×プロバイダのdevデプロイバージョンの組み合わせで検証結果を確認しようとしますがその組み合わせの検証結果は存在しないため成功しませんでした。コンシューマ側のパイプラインから発火するプロバイダ側のパイプラインでは、コンシューマの新契約バージョン×プロバイダの最新バージョンに対して検証が行われるため、求めている検証結果が得られません。 解決策：一旦契約をロールバックします。そうすることで今度は先にプロバイダが契約の互換性を保った状態で機能追加した状態になるので、成功するはずです。

コンシューマ側で互換性を保たない形での契約の更新

流れとしてはまず、コンシューマ側でfavoriteが追加されていない旧契約状態のものに直します。この時点でプロバイダ側はfavorite対応を行っていますが互換性があるためテストは成功します。またプロバイダ側のcan-i-deployもコンシューマ：旧契約バージョン(devデプロイバージョン)×プロバイダ：最新バージョンの検証が通っているため成功し、最新バージョンでデプロイされます。コンシューマ側のcan-i-deployも以下の理屈により成功します。コンシューマ：最新バージョン×プロバイダ：devデプロイバージョンで検証されますが、コンシューマ側のバージョンについて最新バージョン＝旧契約バージョン＝devデプロイバージョンが成り立つため、結果としてコンシューマ：devデプロイバージョン×プロバイダ：devデプロイバージョンの検証となり、これは（デプロイされている時点で当然ですが）既に検証済みです。 では、順を追って見ていきましょう。 まずはコンシューマ側の修正差分です。<pre><code>diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index ea14748..720bb43 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -51,7 +51,6 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;like: integer(123),
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; favorite: integer(456),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -59,8 +58,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; const {content, postedAt, like, favorite} = response[0];
-&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123 &amp;&amp; favorite == 456);
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> 修正できたのでpushします。コンシューマ側のパイプラインです。<pre><code>&gt; docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --retry-while-unknown 60 --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
Computer says yes \o/&nbsp;
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | 5b9b833... | google-login-back | 9a796ef... | true&nbsp; &nbsp;| 1&nbsp; &nbsp;&nbsp;
VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/cf071c371a83627a39f9642722633bb0330d74a9/metadata/Y3ZuPTViOWI4MzM4N2FiODdjZjFmMzQ2MGZhNjk3ZTVhZDBlMWIwOTE4MjA/verification-results/331 (success)
All required verification results are published and successful</code></pre> 続いて、プロバイダ側のパイプラインです。<pre><code>Computer says yes \o/&nbsp;
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | b160b72... | google-login-back | 3b301dd... | true&nbsp; &nbsp;| 1&nbsp; &nbsp;&nbsp;
VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/cf071c371a83627a39f9642722633bb0330d74a9/metadata/Y3ZuPWIxNjBiNzJiZGVjOWI1NzhhNTFhMTNmYTVmNWVjNjI0N2UzYjRlYmQ/verification-results/335 (success)
All required verification results are published and successful</code></pre> パイプライン実行後のPact Matrixです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e357f25b10dd4bbe94ef0d9ddc666139/Pasted%20image%2020241005182712.png" alt=""> どちらも無事に最新バージョンがデプロイされました。ここまでくれば、あとはロールバックしていた契約を元に戻すだけです。 コンシューマ側の修正(ロールバックコミットのrevert)：<pre><code>diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index 720bb43..ea14748 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -51,6 +51,7 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;like: integer(123),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; favorite: integer(456),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -58,8 +59,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
-&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like, favorite} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123 &amp;&amp; favorite == 456);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> pushします。 Pact Matrix：<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/cffc7271cd2c49deab4170283b207477/Pasted%20image%2020241005184248.png" alt=""> 無事に契約バージョンが最新に更新されました。

契約をロールバックする

今回は、Pactのcan-i-deployを試してみました。契約を更新するフローとしては、<ul><li>古い契約の互換性を保ったまま先にプロバイダを更新し、後から契約を更新する</li><li>先に契約を更新し、後からプロバイダを更新する</li></ul>の2パターンを試してみました。後者の場合、今のパイプラインの実装だと、<ol><li>コンシューマ側の新契約バージョンをpush<ol><li>コンシューマ側のPactテストが成功</li><li>コンシューマ側のパイプライン上のcan-i-deployのためプロバイダ側のパイプラインが発火</li><li>プロバイダ側のPactテストが失敗（新契約に未対応のため）</li><li>コンシューマ側のパイプラインも失敗</li></ol></li><li>プロバイダ側の新契約対応バージョンをpush<ol><li>プロバイダ側のPactテスト【コンシューマ：最新バージョン（新契約バージョン）×プロバイダ：最新バージョン】が成功</li><li>プロバイダ側のパイプライン上のcan-i-deployが失敗（【コンシューマ：デプロイバージョン（旧契約バージョン）×プロバイダ：最新バージョン】の組み合わせの検証結果が存在しないため）</li><li>プロバイダ側のパイプラインが失敗</li></ol></li></ol>となり積んだ状態になってしまいます。今回は契約をロールバックする形で対応しましたが、手動で【コンシューマ：デプロイバージョン（旧契約バージョン）×プロバイダ：最新バージョン】の組み合わせの検証を行う方法もありそうです。もしくは、最初からプロバイダ側のcan-i-deployをする前に上記の検証も行うようパイプラインを組むという手もあるかもしれません。

実用的には、「コンシューマの契約を更新する際にうっかり互換性のない修正を行ってしまった」というケースがありそうです。特に、依存するプロバイダが1個だけならまだ大丈夫かもしれませんが、数が多くなってくると段々それぞれのプロバイダの状態がどうなっているか管理するのが困難になってくると思われます。そういうときこそ、can-i-deployが威力を発揮するのではないでしょうか。そうなってくると、まとめの最後に述べた、「プロバイダ側のcan-i-deployをする前に【コンシューマ：デプロイバージョン×プロバイダ：最新バージョン】の組み合わせの検証を行うようパイプラインを組む」というのは対応したほうがいいと思います。今回はそこまでは対応しませんでしたが、それでもcan-i-deployの便利さはかなり感じました。ここまでやって初めて、Pactを導入する旨味が出てくる気がします。マイクロサービスにおいて、複数サービスを同時にデプロイしなくても、パイプラインを回すだけで検証ができ、安全でないものはデプロイされない仕組みができるというのは素晴らしいと思いました。

感想

参考までに今回の対応で修正したbuildspecの最終的なファイルの中身を添付します。 コンシューマ：<pre><code>version: 0.2

phases:
 install:
 on-failure: ABORT
 commands:
 - npm ci
 pre_build:
 on-failure: ABORT
 commands:
 - echo $DOCKER_TOKEN | docker login -u $DOCKER_USER --password-stdin
 - npm run test
 - npm run pact:publish
 - ./trigger_pipelines.sh
 - npm run pact:can-i-deploy
 build:
 on-failure: ABORT
 commands:
 - ./deploy.sh
 - npm run pact:record-deployment</code></pre> プロバイダ：<pre><code>version: 0.2

phases:
 install:
 on-failure: ABORT
 commands:
 - pip install -r requirements.txt

 pre_build:
 on-failure: ABORT
 commands:
 - TEMP_ROLE=$(aws sts assume-role --role-arn $ASSUME_ROLE_ARN --role-session-name xxxx)
 - export AWS_ACCESS_KEY_ID=$(echo "${TEMP_ROLE}" | jq -r '.Credentials.AccessKeyId')
 - export AWS_SECRET_ACCESS_KEY=$(echo "${TEMP_ROLE}" | jq -r '.Credentials.SecretAccessKey')
 - export AWS_SESSION_TOKEN=$(echo "${TEMP_ROLE}" | jq -r '.Credentials.SessionToken')
 - echo $DOCKER_TOKEN | docker login -u $DOCKER_USER --password-stdin
 - docker compose up dynamo-test -d
 - chmod 777 dynamodb-test/
 - sleep 5 # 起動待ち
 - docker compose run python ./test.sh
 - docker compose stop
 - docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
 - aws s3 cp s3://xxxxx/google_login_back/dev.json .chalice/deployed/dev.json || true

 build:
 on-failure: ABORT
 commands:
 - chalice deploy
 - docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant google-login-back --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}

 post_build:
 on-failure: ABORT
 commands:
 - aws s3 cp .chalice/deployed/dev.json s3://xxxxx/google_login_back/dev.json
 - python create_table.py</code></pre>

付録：buildspecの最終形態

コンシューマ駆動契約テストに入門してみた〜can-i-deploy編〜

JWT (JSON Web Token) 認証とは、Webアプリケーションでユーザーの認証と承認を行うためのオープンスタンダードのこと。以下がポイント。 ①トークンベースの認証JWTは、ユーザーがログインするときに生成されるトークンを使用する。このトークンは、ユーザーの認証情報を含むJSON形式のデータ。 ②セッション管理の代替セッションベースの認証では、サーバーがユーザーのセッション情報を保持するが、JWTではクライアント側がトークンを保持する。これにより、サーバーの負荷が軽減され、スケーラビリティが向上する。 ③セキュリティJWTは署名されており、改ざんされていないことを保証する。署名には秘密鍵が使用され、サーバーだけがその秘密鍵を知っている。

JWT認証とは

任意のプロジェクトディレクトリに移動し、下記コマンドでJWT認証のパッケージをインストールする。 <code>composer require tymon/jwt-auth</code>

パッケージのインストール

<code>php artisan vendor:publish --provider="Tymon\JWTAuth\Providers\LaravelServiceProvider"</code>

設定ファイル(config/jwt.php)を生成

<code>php artisan jwt:secret</code>

.envにJWTの秘密鍵を生成

config/auth.phpを下記のように書き換える。 <pre><code>'guards' =&gt; [
&nbsp; &nbsp; 'api' =&gt; [
&nbsp; &nbsp; &nbsp; &nbsp; 'driver' =&gt; 'jwt',
&nbsp; &nbsp; &nbsp; &nbsp; 'provider' =&gt; 'users',
&nbsp; &nbsp; ],
],</code></pre>

Guardの変更

下記のようにUserモデルに追記する。 <pre><code>use Tymon\JWTAuth\Contracts\JWTSubject;


class User extends Authenticatable implements JWTSubject
{
&nbsp; &nbsp; public function getJWTIdentifier()
&nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; return $this-&gt;getKey();
&nbsp; &nbsp; }


&nbsp; &nbsp; public function getJWTCustomClaims()
&nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; return [];
&nbsp; &nbsp; }
}</code></pre>

Userモデルの設定

<code>php artisan make:controller AuthController</code> <pre><code>&lt;?php


namespace App\Http\Controllers;


use Illuminate\Http\Request;
use Tymon\JWTAuth\Facades\JWTAuth;
use App\Models\User;


class AuthController extends Controller
{
&nbsp; &nbsp; public function login(Request $request)
&nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; $credentials = $request-&gt;only('email', 'password');


&nbsp; &nbsp; &nbsp; &nbsp; if (! $token = JWTAuth::attempt($credentials)) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return response()-&gt;json(['error' =&gt; 'Unauthorized'], 401);
&nbsp; &nbsp; &nbsp; &nbsp; }


&nbsp; &nbsp; &nbsp; &nbsp; return response()-&gt;json([
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'message' =&gt; 'Login successful',
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'token' =&gt; $token
&nbsp; &nbsp; &nbsp; &nbsp; ]);
&nbsp; &nbsp; }


&nbsp; &nbsp; public function register(Request $request)
&nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; $user = User::create([
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'name' =&gt; $request-&gt;name,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'email' =&gt; $request-&gt;email,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'password' =&gt; bcrypt($request-&gt;password),
&nbsp; &nbsp; &nbsp; &nbsp; ]);


&nbsp; &nbsp; &nbsp; &nbsp; $token = JWTAuth::fromUser($user);


&nbsp; &nbsp; &nbsp; &nbsp; return response()-&gt;json([
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'message' =&gt; 'Registration successful',
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'token' =&gt; $token
&nbsp; &nbsp; &nbsp; &nbsp; ]);
&nbsp; &nbsp; }
}</code></pre>

コントローラー作成

routes/api.php を編集。 <pre><code>Route::post('login', [AuthController::class, 'login']);
Route::post('register', [AuthController::class, 'register']);</code></pre>

ルートの作成

実装手順

postmanを使用して確認する。 <blockquote>名前 : test1 メールアドレス : test1@example.com パスワード : password</blockquote> 上記のユーザーを登録。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/f1fc7e271feb4e5eba46460c2944f3c4/image.png" alt="">

登録

登録したユーザーでログインを確認する。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/48e68fe7f33e463196462b1bbbd8927f/image.png" alt="">

動作確認

【Laravel】JWT認証機能の実装

下記リンクからインストール可能（MacとWindowsでインストーラが変わるため注意）<a href="https://www.docker.com/get-started/" target="_blank" rel="noopener noreferrer">https://www.docker.com/get-started/</a>

（前提）Docker のインストール

任意の場所にプロジェクトディレクトリを作成する。 <code>mkdir laravel11-docker</code><code>cd laravel11-docker</code> ★ディレクトリ構造<pre><code>laravel11-docker/
├── docker/
│&nbsp; &nbsp;├── mysql/
│&nbsp; &nbsp;│&nbsp; &nbsp;└── (MySQL関連ファイル)
│&nbsp; &nbsp;├── nginx/
│&nbsp; &nbsp;│&nbsp; &nbsp;├── logs/
│&nbsp; &nbsp;│&nbsp; &nbsp;├── default.conf
│&nbsp; &nbsp;│&nbsp; &nbsp;└── Dockerfile
│&nbsp; &nbsp;└── php/
│&nbsp; &nbsp; &nbsp; &nbsp;├── Dockerfile
│&nbsp; &nbsp; &nbsp; &nbsp;└── php.ini
├── src/
│&nbsp; &nbsp;└── (Laravelプロジェクトファイル)
└── docker-compose.yml</code></pre>

プロジェクトディレクトリの作成

docker-compose.ymlファイルを作成し、以下の内容を記述する。 <pre><code>services:
&nbsp; nginx:
&nbsp; &nbsp; container_name: "laravel11-nginx"
&nbsp; &nbsp; build:
&nbsp; &nbsp; &nbsp; context: ./docker/nginx
&nbsp; &nbsp; ports:
&nbsp; &nbsp; &nbsp; - "80:80"
&nbsp; &nbsp; volumes:
&nbsp; &nbsp; &nbsp; - ./src:/var/www/html
&nbsp; php:
&nbsp; &nbsp; container_name: "laravel11-php"
&nbsp; &nbsp; build:
&nbsp; &nbsp; &nbsp; context: ./docker/php
&nbsp; &nbsp; volumes:
&nbsp; &nbsp; &nbsp; - ./src:/var/www/html
&nbsp; &nbsp; &nbsp; - ./docker/php/php.ini:/usr/local/etc/php/php.ini
&nbsp; mysql:
&nbsp; &nbsp; image: mysql:8.0
&nbsp; &nbsp; container_name: "laravel11-mysql"
&nbsp; &nbsp; environment:
&nbsp; &nbsp; &nbsp; MYSQL_ROOT_PASSWORD: root
&nbsp; &nbsp; &nbsp; MYSQL_DATABASE: laravel
&nbsp; &nbsp; volumes:
&nbsp; &nbsp; &nbsp; - ./docker/mysql:/var/lib/mysql
&nbsp; &nbsp; ports:
&nbsp; &nbsp; &nbsp; - "3306:3306"</code></pre>

docker-compose.ymlの作成

docker/nginxフォルダ内にDockerfileとdefault.confを作成し、以下の内容を記述する。 ・Dockerfile<pre><code>FROM nginx:1.21
COPY default.conf /etc/nginx/conf.d/</code></pre> ・default.conf<pre><code>server {
&nbsp; &nbsp; listen 80;
&nbsp; &nbsp; server_name localhost;
&nbsp; &nbsp; root /var/www/html/public;
&nbsp; &nbsp; index index.php index.html;


&nbsp; &nbsp; location / {
&nbsp; &nbsp; &nbsp; &nbsp; try_files $uri $uri/ /index.php?$query_string;
&nbsp; &nbsp; }


&nbsp; &nbsp; location ~ \.php$ {
&nbsp; &nbsp; &nbsp; &nbsp; fastcgi_pass laravel11-php:9000;
&nbsp; &nbsp; &nbsp; &nbsp; fastcgi_index index.php;
&nbsp; &nbsp; &nbsp; &nbsp; include fastcgi_params;
&nbsp; &nbsp; &nbsp; &nbsp; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
&nbsp; &nbsp; }
}</code></pre>

Nginxの設定

docker/phpフォルダ内にDockerfileとphp.iniを作成し、以下の内容を記述する。 ・Dockerfile <pre><code>FROM php:8.2-fpm

# 必要なパッケージのインストール
RUN apt-get update &amp;&amp; apt-get install -y \
&nbsp;&nbsp;zip \
&nbsp;&nbsp;unzip \
&nbsp;&nbsp;git \
&nbsp;&nbsp;&amp;&amp; docker-php-ext-install pdo_mysql

# Composerのインストール
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

COPY php.ini /usr/local/etc/php/</code></pre> ・php.ini<pre><code>[PHP]
display_errors = On</code></pre>

PHPの設定

プロジェクトフォルダ内で以下のコマンドを実行してLaravelプロジェクトを作成する。 <code>docker compose run --rm php composer create-project --prefer-dist laravel/laravel src</code>

Laravelプロジェクトの作成

<code>docker-compose up -d</code>

Dockerコンテナの起動

DockerによるLaravel環境の構築

ブラウザでアクセスしウェルカムページが表示されるかを確認する。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/93e2745c8ecd40a780f071c3d932c7bd/image.png" alt="">

【Docker】Laravel 11 環境の構築

Docker社が開発している、コンテナ型の仮想環境を作成、配布、実行するためのプラットフォーム。

Dockerとは

Dockerコンテナはコード化されたファイルを共有することで、ローカル環境と本番環境の違いをなくし、一貫した動作の環境のもと開発を行うことができる。Dockerはミドルウェアのインストールや各種環境設定をコード化して管理できる。

メリット

Docker

下記リンクからインストール可能（MacとWindowsでインストーラが変わるため注意）<a href="https://www.docker.com/get-started/" target="_blank" rel="noopener noreferrer">https://www.docker.com/get-started/</a>

任意の場所にディレクトリを作成する。 <code>mkdir php-docker</code><code>cd php-docker</code> (ディレクトリ構造)<pre><code>php-docker/
├── Dockerfile
├── docker-compose.yml
├── index.php
└── その他のPHPファイルやディレクトリ</code></pre>

ディレクトリの作成

Dockerfile とは、PHPのベースイメージに対して追加のPHP拡張モジュールをインストールするためのもの。プロジェクトディレクトリ内に Dockerfile を作成し、以下の内容を記述する。 <pre><code># ベースイメージとしてPHPを使用
FROM php:7.4-apache


# 作業ディレクトリを設定
WORKDIR /var/www/html


# プロジェクトファイルをコンテナにコピー
COPY . /var/www/html


# 必要なPHP拡張モジュールをインストール
RUN docker-php-ext-install mysqli</code></pre>

Dockerfileの作成

docker-compose.yml は、複数のDockerコンテナを一括で定義・管理するための設定ファイル。1つのファイルで複数のコンテナを定義可能で、例えばPHPとMySQLを同時に設定でき、ローカル環境、テスト環境で同じ設定ファイルを用いることで、一貫性のある環境を提供できる。プロジェクトディレクトリ内に docker-compose.yml を作成し、以下の内容を記述する。 <pre><code>version: '3.8'


services:
&nbsp; web:
&nbsp; &nbsp; build: .
&nbsp; &nbsp; ports:
&nbsp; &nbsp; &nbsp; - "8080:80"
&nbsp; &nbsp; volumes:
&nbsp; &nbsp; &nbsp; - .:/var/www/html
&nbsp; &nbsp; depends_on:
&nbsp; &nbsp; &nbsp; - db


&nbsp; db:
&nbsp; &nbsp; image: mysql:5.7
&nbsp; &nbsp; environment:
&nbsp; &nbsp; &nbsp; MYSQL_ROOT_PASSWORD: example
&nbsp; &nbsp; &nbsp; MYSQL_DATABASE: mydatabase
&nbsp; &nbsp; &nbsp; MYSQL_USER: user
&nbsp; &nbsp; &nbsp; MYSQL_PASSWORD: password
&nbsp; &nbsp; volumes:
&nbsp; &nbsp; &nbsp; - db_data:/var/lib/mysql


volumes:
&nbsp; db_data:</code></pre>

例えば index.php ファイルを作成し、MySQLデータベースに接続できているかを確認するソースを記述する。 <pre><code>&lt;?php
$servername = "db";
$username = "user";
$password = "password";
$dbname = "mydatabase";


// MySQLデータベースに接続
$conn = new mysqli($servername, $username, $password, $dbname);


// 接続をチェック
if ($conn-&gt;connect_error) {
&nbsp; &nbsp; die("Connection failed: " . $conn-&gt;connect_error);
}
echo "Connected successfully";
?&gt;</code></pre>

PHPファイルの作成

以下のコマンドを実行して、Dockerコンテナをビルドし起動する。 <code>docker-compose up -d</code>

Dockerコンテナのビルドと起動

ブラウザで http://localhost:8080 にアクセスして、PHPとMySQLが正しく連携しているか確認する。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/dc14ce9af8d54347b3a8de2ce3e502eb/image.png" alt="">

ブラウザで確認

DockerによるPHP環境の構築

今回はDockerでPHPの環境の構築を行いました。

【Docker】PHP環境の構築

まずは認可の問題です。このシステムではユーザが投稿リクエストを送る権限があるかどうかとユーザの特定をアクセストークンを使って行っています。認証・認可にはAuth0を使っており、ユーザがログインしたタイミングで取得したアクセストークンをバックエンドに送信しています。 Pactの契約を作る際、リクエスト内容と対応するレスポンスを定義しますが、リクエスト内容のAuthorizationヘッダにAuth0から取得したアクセストークンを書き込んだとしても、アクセストークンには有効期限があります。有効期限が切れた途端に失敗しかしなくなるテストコードになってしまいます。対処法として以下の2パターンを考えました。投稿APIのプロバイダ側の契約テストで必要になるアクセストークンの問題の対処法：<ol><li>リクエストヘッダをバックエンド側で上書きする<ol><li><a href="https://github.com/reecetech/pactman/tree/master?tab=readme-ov-file#verifying-pacts-using-pytest" target="_blank" rel="noopener noreferrer">pactman</a>の場合は<code>pact_verifier.verify</code>の第3引数に辞書形式で追加のリクエストヘッダを指定できるようです。</li><li>ただしこのやり方だと逆に常に認証が成功してしまい、認証失敗するケースをテストできなくなってしまいます。</li></ol></li><li>認証コンポーネントをモック化する<ol><li>モック化する場合、認証のロジックを別で担保するのかどうかを検討する必要があります。</li><li>実行中のAPIの内部状態を変更する必要があります。</li></ol></li></ol>どちらのパターンにおいてもデメリットがありました。（1のリクエストヘッダ上書きの方は、ケースごとに上書きするヘッダを指定できたらいいのにな・・・と思います） 次に対処法2のデメリットである、実行中のAPIの内部状態を変更する方法について検討しました。 django（公式ドキュメントの例）の場合<a href="https://github.com/reecetech/pactman/tree/master?tab=readme-ov-file#verifying-pacts-using-pytest" target="_blank" rel="noopener noreferrer">pactmanのドキュメント</a>では、djangoの場合の<code>live_server</code> pytest fixtureを使った例が書いてあります。自分はdjangoは全くの未経験ですが、軽く調べたところによるとlive_serverはテストとは異なるスレッドで実行されるようです。今回のように内部状態を変えたい場合はどうやって対応するんだろうと思ってもう少し調べてみたら、<code>transactional_db</code> fixtureに依存することで、DBの内容を操作できるようになっているようです。（その内部実装がどうなっているかまでは追えていません・・・） Chalice（今回のプロジェクト）の場合<a href="https://aws.github.io/chalice/topics/testing.html#rest-apis" target="_blank" rel="noopener noreferrer">テスト用のClient</a>があるようです。こちらは先程のlive_serverとは異なり、実際にサーバを起動するのではなく、あくまでクライアントのモックとしてリクエストに対するレスポンスを返してくれるみたいです。なので同じプロセスになるので、モンキーパッチなどで外部からデータを書き換えるのは簡単そうです。しかし、pactmanの公式がlive_serverを例として出していることからも想像できるように、pactmanは別プロセスとして実際に動くAPIを前提とした実装になっています。 pact_verifierの実装を少し深堀したところ、単純に<a href="https://github.com/reecetech/pactman/blob/master/pactman/verifier/verify.py#L75" target="_blank" rel="noopener noreferrer">内部でrequestsの関数を呼び出しているだけ</a>でした。したがって、もしChalice提供のテスト用Clientを使うのであれば、requestsのget関数を呼び出した際にテスト用Clientのgetが呼ばれる、みたいにうまく噛み合うようなパッチを手探りで作っていかなければなりません。 自分は少しだけ試してみましたが無理そうだったのでテスト用Clientは使わないことにしました。そうなると、テスト用Clientではなく実際に<code>chalice local</code>でサーバを起動するやり方になります。そうすると、別プロセスで動いているChaliceプログラムの内部状態を変えなければいけないという難しい問題に直面しなければならず、こちらもかなり厄介な実装になりそうだったので、アクセストークン問題の対処法2は断念し、1で対応する方針に切り替えました。 対処法1のデメリットとしては認証失敗ケースのテストができないというのがありますが、今回は別で（手動テストなどで）担保するので問題ないとしました。（というより、それしか現実的な方法がないのですが）

トークンの有効期限問題

さて、少し話が本題とそれてしまいますが、リクエストヘッダを上書きするとして、そのアクセストークンはどうやって取得すればいいでしょうか？何を言っているんだと思われるかもしれませんが、今回プロデューサ側のテストを考えています。つまり、アクセストークンは送られてくるわけではなく、プロデューサ自身の側で生成しなければいけません。今回は投稿権限を持ったテスト用のユーザをAuth0側に実際に作成し、（画面はないので）OAuth2.0のリソースオーナーパスワードフローを使って直接トークンを取得する形にしました。パスワードフローを使うにあたって色々と設定などが必要だったのですが、そのあたりの話は完全に脱線してしまうのでここでは省略します。

アクセストークンの取得方法

アクセストークンが無事に取得できたとき、また別の壁が立ちはだかりました。<code>pact_verifier.verify</code>の第3引数に設定する<code>extra_provider_headers</code>は、（なんと）<a href="https://github.com/reecetech/pactman/blob/master/pactman/verifier/verify.py#L198" target="_blank" rel="noopener noreferrer">pactに記載の内容で上書きされてしまいます</a>。つまりどういうことかというと、コンシューマ側で契約を定義しますが、その際にAuthorizationヘッダに<code>"Bearer hoge"</code>と設定していたとすると、<code>extra_provider_headers</code>を指定していたとしても<code>"Bearer hoge"</code>の方が勝ってしまうということです。更に悪いことに、<code>extra_provider_headers</code>は<code>@property</code>で「保護されている」ため、パッチするのも困難になってしまっています。自分の場合は仕方なく、契約にはAuthorizationヘッダを含めないようにしました。実際と異なる契約になってしまうため、できればやりたくなかったのですが。自分の理解が及んでいないだけかもしれませんが、契約側よりプロバイダ側の注入の方が勝つようにしてほしいです・・・pactmanの今後の改修に期待したいです。 ようやくアクセストークンを正しく設定できるようになったところで、別のエラーになりました。ユーザが自身の投稿の一覧を取得するAPIの検証結果です：<pre><code>Failed: body size 0 is smaller than minimum size 1 at body</code></pre> ただここまでくれば勝ったも同然ですね。今はユーザの投稿を1件も保存していない状態なので、想定通りのエラーです。

pactmanのextra_provider_headersが上書きされる問題

認可の問題

さてようやくDBについてどうするかを考えるタイミングが来ました。APIは別プロセスで<code>chalice local</code>で動いているので、現状DBもモックではなく本物（といってもDynamoDB localですが）に繋がっています。まずDBにモックを使わないのは妥当かどうかですが、このDBは内部システムとみなせるため、実物を使用すべしという結論になります。このあたりは<a href="https://build.yoku.co.jp/articles/rfycv5cu04_p#section_4_subsection_1" target="_blank" rel="noopener noreferrer">以前の投稿</a>をご参照ください。次に、DBのコンテナについて考えます。現状はローカル開発環境用のDBにchaliceが接続してしまっていますが、ローカル開発環境用とは切り離したいです。そこで単純にテスト用のdockerコンテナを別途作成し、chaliceのstageに紐づく環境変数を（<code>.chalice/config.json</code>で）切り分けることで、ローカル開発環境chaliceとテスト用chaliceで別々のDBコンテナを見に行くようにしました。

接続先DBの検討

上に述べたような試行錯誤の末ようやくローカルで投稿APIのプロバイダ側のテストが通るようになりました。CodeBuild環境でもテストを通したいのですが、今のままだと通りません。それは、ローカルではpythonコンテナ上でテストを実行していますが、CodeBuild環境では現状localhostで直接テストを実行しているためです。もし現状のままlocalhostで実行するのであれば、DBコンテナに接続するためにはDBコンテナをポートフォワーディングし、対象ポートに接続する必要があります。接続先は環境変数で切り替えればいいのでそこまで難易度は高くありませんが、今後も開発を進めていく中でローカル環境とCodeBuild環境の環境差異が原因でテストが通らなくなることがありそうです。手元の環境でないと中々デバッグもし辛いですし、できればこの際ローカルと同じようにCodeBuild環境でもDocker上でテストを実行するようにしたいです。

CI/CD環境をどうするか

CodeBuild環境でもDocker上でテストを実行するようにしたところ、conftest.pyのboto3をインスタンス化している箇所でNoRegionErrorが発生しました。これはCodeBuildのAWSプロファイルがコンテナに引き継がれないためです。CodeBuildの場合、認証情報が環境変数に設定されているわけでも~/.aws/配下に保存されているわけでもないようです。したがってCodeBuild環境の認証情報をDockerに引き継ぐ方法はありません。コンテナからawsコマンドを実行するには、コンテナ用のIAMロールを作る必要があります。<a href="https://repost.aws/ja/knowledge-center/codebuild-temporary-credentials-docker" target="_blank" rel="noopener noreferrer">AWS公式</a>にやり方が書いてあります。

CodeBuildでNoRegionError

curlならIP、ホスト名指定共にpythonコンテナからDBコンテナへの接続が成功するのですが、なぜかpynamodb(botocore)経由だとタイムアウトしてしまう現象に相当悩まされました。様々な試行錯誤の末、最終的に最小限の構成で新規プロジェクトをローカルに立ち上げたところ、単純に<a href="https://qiita.com/yuta-katayama-23/items/a8c497fe4a61f29deb34#%E3%81%9D%E3%81%AE2%E3%81%82%E3%82%89%E3%81%8B%E3%81%98%E3%82%81%E6%89%8B%E5%8B%95%E3%81%A7volumes%E3%81%A7%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%83%9B%E3%82%B9%E3%83%88%E5%81%B4%E3%81%AE%E3%83%9E%E3%82%A6%E3%83%B3%E3%83%88%E5%85%88%E3%81%AB%E3%81%AA%E3%82%8B%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97chmod-777%E3%81%AB%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B" target="_blank" rel="noopener noreferrer">dataディレクトリのパーミッションを変更</a>していなかったことが原因と気づきました。

ローカルだと通るがcodebuildだとDynamoDB-localへの接続がタイムアウトする

投稿APIに対してリクエストを投げた際に、以下のようなエラーが発生しテストが頻繁に失敗するようになりました。<pre><code>E&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8008): Max retries exceeded with url: /auth0/microposts (Caused by NewConnectionError('&lt;urllib3.connection.HTTPConnection object at 0x727b9434f610&gt;: Failed to establish a new connection: [Errno 111] Connection refused'))</code></pre> DB更新などを行った際にchaliceの監視対象が更新したと判定され、ホットリロードによりchaliceが再起動するようです。そして再起動している間にリクエストが来ると、応答できずにエラーになってしまうものと思われます。そのためchaliceの実行オプションに<a style="color:#ff357f;background-color:#ffffff" href="https://github.com/aws/chalice/issues/1064#issuecomment-461259975" target="_blank" rel="noopener noreferrer"><code>--no-autoreload</code></a>を追加し、リロードされないようにしたところ失敗しなくなりました。

プロバイダ側のテストが不安定に失敗することがある

DBの問題

ユーザの投稿一覧を取得するAPIの契約で、ユーザの投稿が存在する場合としない場合の両方のケースについてプロバイダ側で契約を満たしているか確認する必要があります。このように前提としているプロバイダ側の状態がある場合、どのようにコントロールしたらいいでしょうか？ Pactではもちろんこのようなケースに対応できます。pactmanの場合は<code>pact_verifier.verify</code>の第二引数に<code>provider_state</code>関数を渡してあげることで対応できます。<code>provider_state</code>関数の第一引数のnameに、契約に規定された<code>providerStates[].name</code>が渡ってくるので、そのラベルで分岐することで必要な状態を作成することが可能です。 例えば、今回の例だとユーザの投稿が存在する場合には<code>"ユーザの投稿が存在する場合"</code>という文字列が渡ってくるので、provider_state関数の中で<code>providerStates[].name</code>が<code>"ユーザの投稿が存在する場合"</code>だった場合には事前に投稿APIをPOSTすることで投稿が存在する状態を作っています。<pre><code>def provider_state(token):
 def _provider_state(name, **params):
 if name == "ユーザの投稿が存在する場合":
 requests.post(f"{CHALICE_URL}/auth0/microposts", json={"content": "hello, world"}, headers={'Authorization': f"Bearer {token}"})
 return _provider_state</code></pre> なお、今回はprovider_state関数がtokenを受け取って関数を返す関数になっていますが、これは投稿APIをPOSTする際に<code>token</code> fixtureで生成したトークンを渡す必要があるためです。

BuildersIO produced by YOKU