Contents
Go製動的リンクライブラリ(.so)のビルド手順
Go製の動的リンクライブラリを開発するには、特定の環境設定とビルド構成が不可欠です。このセクションでは、必要な準備から実際の操作までを丁寧に解説します。
開発環境準備
以下の要素を確認し、適切な環境構築を行ってください。
- Go 1.20以上：最新バージョンで開発し、
cgoのサポートを確保 - build制約設定：
CGO_ENABLED=1を環境変数に設定（Linux向け） - コンパイルツールチェーン：gccやclangなど
注意点として、
cgoを使用する場合は、クロスコンパイルを行うと実行時にエラーになる可能性があるため、ターゲットOSでビルドすることを推奨します。cgoはC言語コードとのインターフェースを作成するためのGoの機能です。
ビルドターゲット設定
プロジェクトディレクトリにMakefileを作成し、以下の内容を記述します。
|
1 2 3 4 5 |
BINARY_NAME=myplugin.so build: GOOS=linux GOARCH=amd64 CGO_ENABLED=1 go build -o $(BINARY_NAME) -buildmode=c-shared . |
この設定で、make buildコマンドを実行すると.soファイルが生成されます。
共有ライブラリの出力確認
ビルドが成功したら、以下のように確認します。
lsコマンドで.soファイルが生成されているかチェックnm -D myplugin.soでエクスポートされたシンボルを確認（_initや_finiが含まれているか）
| 項目 | 値 | 補足 |
|---|---|---|
| ビルドコマンド | make build |
Makefileに記載されている |
| ターゲットOS | Linux (amd64) | プラグイン実行環境のアーキテクチャに合わせる必要あり |
| シンボル確認 | _init, _fini |
エラー発生時のヒントになる |
krakend.jsonでのプラグイン設定方法
KrakenDでは、.soファイルをロードするための詳細な設定が必要です。ここでは基本構成から応用例までを解説します。
基本構成例
krakend.jsonに以下のように記述します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "version": 3, "extra_config": { "github.com/devopsfaith/krakend-metrics": { "prefix": "/metrics" }, "github.com/yourname/myplugin": { "option1": "value1", "option2": true } } } |
extra_configセクションにプラグインのマッピングを定義します。github.com/yourname/mypluginは実際のリポジトリURLと一致させる必要があります。
ロードバランシング対応設定
複数バックエンドに分散処理が必要な場合は、以下のように設定できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "version": 3, "endpoints": [ { "endpoint": "/api", "backend": [ { "url_pattern": "http://backend1:8080/api", "weight": 2 }, { "url_pattern": "http://backend2:8080/api", "weight": 1 } ] } ] } |
この設定により、backend1とbackend2に2:1の割合でリクエストを分散します。
エラーハンドリング指定
エラー発生時の処理は、以下のように定義可能です。
|
1 2 3 4 5 6 7 8 9 10 |
{ "version": 3, "extra_config": { "github.com/yourname/myplugin": { "error_retry": 3, "fallback_response": "{'status':503,'message':'Service Unavailable'}" } } } |
| 項目 | 値 | 補足 |
|---|---|---|
| エラーリトライ | error_retry: 3 |
最大リトライ回数を指定 |
| 代替応答 | fallback_response |
エラー発生時に返すJSON形式のレスポンス |
Docker多段階ビルドによるイメージ作成
KrakenDプラグインは、開発環境と本番環境で一貫したコンテナを作成する必要があります。ここでは多段階ビルドの手順を解説します。
開発環境構築レイヤー
開発用イメージでは、Goツールチェーンをインストールし、リポジトリのコードをコピーします。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# Build stage FROM golang:1.20 as builder WORKDIR /app COPY . . RUN make build # Development stage FROM golang:1.20 WORKDIR /app COPY --from=builder /app/myplugin.so /app/ CMD ["krakend", "run", "--config=/app/krakend.json"] |
--from=builderは、ビルドステージからファイルをコピーします。この方法で、実行イメージにはGoツールが不要になります。
ビルドステージ分離
多段階ビルドでは、以下のような構造を持たせます。
- Build Stage：開発環境用のGoツールチェーンとコードを含む
- Runtime Stage：実行に必要なみのバイナリと設定ファイルのみを保持する
| ステージ | 内容 | メリット |
|---|---|---|
| Build | Goツールで.soビルド |
開発環境用として使い捨て可能 |
| Runtime | 最小限のイメージにバイナリと設定をコピー | ローカル環境との一貫性が保たれる |
最終イメージの最適化
実行時に必要なファイルのみを残すことで、イメージサイズを抑えることができます。
|
1 2 3 4 5 6 7 |
# Final stage FROM alpine:3.18 WORKDIR /app COPY --from=builder /app/myplugin.so . COPY krakend.json . CMD ["krakend", "run", "--config=/app/krakend.json"] |
Alpine Linuxは軽量で、セキュリティにも優れた選択です。
公式イメージタギング方針とバージョン管理
KrakenDプロジェクト公式リポジトリでは、Semantic Versioning（語義的バージョン）という方式を採用しています。これは、メジャーバージョン、マイナーバージョン、パッチバージョンの3階層でタギングが行われる仕組みです。
Semantic Versioningの適用
- メジャーバージョン（例: 2.0）：非互換な変更がある場合に更新
- マイナーバージョン（例: 2.1）：互換性のある新機能追加
- パッチバージョン（例: 2.1.3）：バグ修正やセキュリティアップデート
プラグイン開発では、メジャーバージョンの変更を検知する仕組みが必要です。
krakend.jsonでバージョン指定することで互換性を確保できます。
Git tagとの連携
GitタグとDockerイメージタグを連携させる手順は以下の通りです。
- Gitリポジトリにバージョンタグ（例:
v2.1.3）を作成する - CI/CDパイプラインで、
docker build -t yourname/myplugin:v2.1.3 .を実行 - プラグイン利用側は、
krakend.jsonでタグ指定を行う
| タグ種類 | 内容 | 用途 |
|---|---|---|
latest |
最新リリースバージョン | 開発環境向けに一時的に使用可能 |
| バージョンタグ（例: v2.1.3） | セマンティックバージョン | 本番環境向けに安定したバージョンを指定 |
ローカル開発環境構築ワークフロー
ローカルでの開発では、コンテナ化とホットリロードの組み合わせが効率的です。ここでは具体的な設定方法を解説します。
コンテナ化による隔離環境
Docker Composeを使用して、KrakenD本体・バックエンドAPI・データベースを統合的に管理できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
version: '3' services: krakend: image: yourname/myplugin:latest ports: - "8080:8080" volumes: - ./krakend.json:/etc/krakend/krakend.json backend: image: yourname/backend-api ports: - "8081:8081" |
volumesで設定ファイルをマウントすることで、変更後の再起動が不要になります。
ホットリロード対応設定
KrakenDはホットリロードに対応しており、以下のように設定します。
|
1 2 3 4 5 6 7 8 9 |
{ "version": 3, "extra_config": { "github.com/yourname/myplugin": { "hot_reload": true } } } |
| 設定 | 内容 | 効果 |
|---|---|---|
hot_reload: true |
プラグインコードの変更を自動で反映 | 開発中の再起動不要 |
テストスイートの実行方法
Docker Composeでテスト環境を構築後、以下のように実行します。
docker-compose upでコンテナ起動- Postmanやcurlで
http://localhost:8080/apiにアクセス - ロギング確認：
docker logs krakendで出力内容を確認
統合テストは、Docker ComposeでバックエンドとKrakenDの両方を起動して実施します。
まとめ
本ガイドでは、KrakenDプラグイン開発における以下のポイントを解説しました：
- Go製
.soファイルのビルド方法 - krakend.jsonでのプラグイン設定手順
- Docker多段階ビルドによるイメージ作成
- Semantic VersioningとGitタグの連携方法
- ローカル開発環境構築ワークフローの設計
これらの知識を活用することで、KrakenDプラグインの開発・導入が円滑に進むでしょう。実際の導入時には、Web検索結果にある最新情報（例：2026年5月のDockerイメージタギングガイド）を参考にしながら、プロジェクトに最適な設定を行ってください。