nikkie-ftnextの日記

イベントレポートや読書メモを発信

WireMockをローカルのKubernetesで動かす 〜ちさたき移植を目指して、まずはDeploymentとService〜

はじめに

もしもしもしもし〜、nikkieです。

docker runで素振りした題材をKubernetesに移植する素振りです。

目次

WireMockをJSONファイルで設定してDockerで動かす

過去記事より

WireMockはAPIをモックできるツールです。
システムが依存するAPIを、テスト時にスタブ・モックにするシーンで使っています。
この素振りとして、過去にリコリス・リコイル1なWireMockを設定しました。

$ curl http://localhost:8080/chinanago
さかなー🐟
$ curl -s http://localhost:8080/takina -H 'Content-Type: application/json' -d '{"lines": "chinanago"}' | jq .
{
  "lines": "さかなー🐟"
}

たきなをGET、千束をPOSTで設定しました

WireMockのDockerイメージをrunしていたわけなのですが、ふと「Kubernetes(ローカルに用意)で動かせるのでは!?」と電波を受信しました。
設定するのを後回しにして、最初はKubernetesで動かすだけやってみます。

ServiceとDeployment

ローカル環境のKubernetesは、Rancher Desktopを使っています2(Version: 1.17.1)。
https://docs.rancherdesktop.io/#kubernetes

WireMockのイメージをKubernetesで動かすにあたり、このたび認識したのは、ServiceとDeploymentを定義する必要があるということ

Deployment

Deployment はPodとReplicaSetの宣言的なアップデート機能を提供します。

WireMockのイメージはPodとして動くわけですが、どんなPodを常に何個動かすか(ReplicaSet)をDeploymentとして定義するという理解です。
ドキュメントに沿って以下を用意

  • Deploymentの名前は.metadata.nameの「chisa-taki-deploy
  • .spec.templateでPodを定義していると理解
    • .metadataapp: chisa-taki-appとラベル付け
    • (さらなる).specでWireMockのイメージを指定し、8080ポートを設定しています

kubectl apply -fで適用します。

% kubectl --context rancher-desktop -n default apply -f deployment.yaml
deployment.apps/chisa-taki-deploy created

Service

KubernetesにおけるServiceとは、 クラスター内で1つ以上のPodとして実行されているネットワークアプリケーションを公開する方法です。

用意したWireMockのPodにリクエストを送りたいので、Serviceも作ります。

Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します

  • Serviceの名前は.metadata.nameの「chisa-taki-svc
  • .spec.selectorにあるapp: chisa-taki-appというラベルのPodの8080番ポートをターゲットにする(targetPort
    • 気づき:ラベルでPodの論理的なセットを用意してるってことか!(複数Podがあってもこれならリクエストを送れそう)

今回nameを揃えずバラバラにしたのは、Deploymentで定義したPodに、Serviceをどのようにしてリクエストを送れるようにするのかを理解したかったという理由があります。

kubectl apply -fで適用

% kubectl --context rancher-desktop -n default apply -f deployment.yaml -f service.yaml 
service/chisa-taki-svc created

動作確認

Serviceをポートフォワードして確認します

% kubectl port-forward svc/chisa-taki-svc 8080:8080

WireMockは未設定ですが、スタブの設定を確認できるエンドポイントがあります3
https://wiremock.org/docs/standalone/admin-api-reference/#tag/Stub-Mappings/operation/getAllStubMappings
GET /__admin/mappings

ここにリクエストを送って疎通確認とします

% curl 127.0.0.1:8080/__admin/mappings
{
  "mappings" : [ ],
  "meta" : {
    "total" : 0
  }
}

なお、GET /__admin/healthもありました。
https://wiremock.org/docs/standalone/admin-api-reference/#tag/System/operation/getHealth

% curl 127.0.0.1:8080/__admin/health 
{
  "status" : "healthy",
  "message" : "Wiremock is ok",
  "version" : "3.10.0",
  "uptimeInSeconds" : 144,
  "timestamp" : "2025-01-30T12:32:58.299082Z"
}

終わりに

WireMockをローカルのKubernetesで(設定は何もせずに)動かしました。

  • KubernetesのDeploymentとServiceを定義
  • DeploymentでPodにラベルを付け、そのラベルをServiceでも使いターゲットにした

ラベルの理解が少し深まったのが収穫です。
まだKubernetesではちさたきできていないので、今後は設定を探っていきます!

今回のソースコード


  1. おおお!
  2. 他の方法でKubernetesを用意しても変わらないと考えています
  3. https://wiremock.org/docs/standalone/administration/#fetching-all-of-your-stub-mappings-and-checking-wiremock-is-working