クラウドへのアプリ移行が進むなか、多くの企業は「リフト＆シフト」で移すか、それとも「クラウドネイティブ」（その定義はさまざまです）に作り直すかという選択を迫られています。本記事では後者、なかでもアプリをコンテナ（Dockerなど）に載せ替え、Kubernetesでオーケストレーションする際に役立つテクニックを取り上げます。
出典: iStockPhoto
ブートストラップの課題
DevOpsやクラウド移行がもたらす価値のひとつは、手作業を自動化して従来型運用の負担を減らせることです。アプリのあるべき状態を自動で保ち続けるKubernetesの宣言的な仕組みは、非常に強力です。とはいえアプリによっては、正常に起動する前に「ブートストラップ」処理が必要だったり、キューやデータベースなど他システムとの依存関係を解消するために特定の順序で起動しなければならなかったりします。
アプリを正常に動かすために、条件が整うまでリトライするカスタムロジックを組み込む手もありますが、それでは移行が後ろ倒しになりかねません。コードを書き換えずに済む代替策が、小さなアプリやスクリプト、コマンドを用意してInitContainersとして追加する方法です。
Init Containerの活用シーン
- ピア同士で自身を登録する必要があるブロックチェーンアプリ
- IDプロバイダーからアクセストークンを取得する必要があるアプリ
- データベースから動的にデータを取得し、起動後にアプリが使えるようキャッシュする
- Vaultから暗号化されたシークレットを取り出し、ファイルシステムに書き込む
- 他システム（キューやデータベースサーバーなど）が利用可能になるまでアプリの起動を待機させる
2つのBusyboxイメージを使ったシンプルな例
ここでは、先ほど挙げたシナリオのように、アプリが起動前に動的なデータを取り込む必要があるケースを想定します。同じことはConfigMapでも実現できますが、このテクニックの応用範囲を示すための例なので、他にどんな使い方ができるかを思い描きながら読んでみてください。
- PersistentVolumeClaimを作成する
まずはアクセス可能なストレージボリュームを用意します。
Persistent Volume Claim
$ kubectl apply -f test-pvc.yamlpersistentvolumeclaim/test-pvc created
2. Deployment設定のYAMLファイルを生成する
$ kubectl create deployment test-app --image=busybox:1.28.0 -o yaml --dry-run > test-app.yaml
3. Deploymentを編集し、ボリュームとInit Containerを次のように追加する
Init Containerを含むDeployment
このファイルではボリュームを追加したうえで、initContainerにもう一つのBusyboxイメージを指定しています。実際にはどんなイメージでも構いませんが、この例ではマウントしたファイルシステム上のファイルに内容を書き込み、もう一方のBusyboxイメージでアプリが起動したときにそのファイルを読み取る、という流れにしています。
4. Deploymentを実行し、ログを確認する
# deploy app
$ kubectl apply -f test-app.yamldeployment.apps/test-app configured# monitor logs
$ kubectl logs -f deployment/test-appFile content: Hello, World!
「File content: Hello, World!」と表示されれば成功です。この基本形をもとに、メインのコンテナイメージを差し替えたり、必要に応じてinit containerを追加したりすれば、アプリが必要な前提条件をすべて満たした状態で起動するように構成できます。このテクニックの強みは、かつて手動で対処していた依存関係に対して複雑なリトライ処理やエラーハンドリングを書かずとも、アプリのデプロイを自動化できる点にあります。
Init Containerについて詳しくは、Kubernetes公式ドキュメントをご覧ください。