保守作業によるオペレーションを統一化
アプリケーションにはさまざまな特徴があります。
- バッチのような1回限りのもの
- Cronで定期的に実行するもの
- ジョブキューを常に実行するもの（sidekiq、delayed_job）
- Webアプリケーション
- 起動時にデータをすべてオンメモリーに乗せてから実行するもの
Webアプリケーションに対しては、以下のようなオペレーションが必ずあると思います。
- デプロイ
- スケール
- 定期バッチ処理
- 不定期バッチ処理
- スキーマ変更
- コンソール
- ログ確認
このように、さまざまな特徴があるオペレーションを統一化するためKubernetesを使用します。
マニフェストファイルとkubectlを用いたオペレーション
Kubernetes上でアプリケーションを実行する場合、KubernetesのAPIサーバーに指示を出すことで実行されます。
指示を出すには、kubectlというコマンドラインツールを使います。kubectlのオプションとしてYAML（またはJSON）で記載したファイルを送ることができます。このファイルを、マニフェストファイルといいます。ここでは、手続き的な書き方ではなく、宣言的な書き方をします。
マニフェストを書き終えたらコマンド、kubectl create -f ./your_manifest.yamlを実行します。すると、KubernetesのAPIサーバーに内容が送られ、クラスタに反映されます。Kubernetesにはいくつかのリソースがありますが、同様にマニフェストファイルを書いてkubectlコマンドを実行するだけで反映されます。マニフェストファイルの設定をうまく利用することで、ブルーグリーンデプロイメントやローリングデプロイメイントを行うことが可能です。
また、kubectlには他にもサブコマンドが用意されており、例えばログをストリーミングで確認できるkubectl logs -f pod_idや、アプリケーションに入りたい場合に使用するkubectl exec -it pod_name bashがあります。
この仕組みにより、アプリケーションの外側のオペレーションについては、すべて同じコマンドを利用するため、差異を吸収することができます。
統一化したオペレーションになった際のアプリケーションエンジニアのメリット
Kubernetesはいくつかのサーバーを組み合わせて、1つのクラスタを構築します。そのため、アプリケーションを実行する際にサーバーを意識する必要はありません。Railsのデプロイツールとして、よく使われるCapistranoと比較して考えてみます。（Fabricなども同様です）
Capistranoで新しくサービスを追加する場合、config/deploy/の下で定義されているステージを追加し、サーバー先を設定する必要があります。
しかしKubernetesの場合、そもそもその作業は必要ありません。kubectlを実行するとKubernetesのAPIサーバーに指示が飛び、クラスタ内部で実行してくれるからです。
新しくサービスを作りたい場合でも、インフラチームに頼んでサーバーを用意してもらったり、Capistranoにstageを追加したり、リリース方法を細かく指定するために既存のCapistranoのソースに手を入れたりする必要はありません。
アプリケーションエンジニアは、主に以下の作業を行います。
- Dockerfileを書く。
- kubernetes/とscript/直下にファイルを書く。
-
コマンド
kubectl create -f ./your_manifest.yamlでアプリケーションをリリースする。
主にこの3つだけを行うことで、作ったものを簡単にリリースすることができます。
［補足］Herokuでいいじゃん
「Herokuでいいじゃん」と思った方に少し補足します。Herokuとの違いとして以下の利点があります。
- 欲しいスペックを定義できる。
- リリースしてからトラフィックを受け付けるタイミングを決められる。
- postStartで事前準備ができる。
- preStopで事後処理ができる。
- Podはあくまでもデプロイする最小単位であり、「静的な部分をnginxコンテナで返し、動的な部分をアプリケーションコンテナで返す」という2つのコンテナをセットとして扱うことができる。（Kubernetesのコア開発者の方が書かれているこちらの資料がわかりやすいです）
- Jobなどもマニフェストファイルに書くだけで、アドオンを追加することなく利用できる。
- （社内でKubernetesを構築した場合は）社内の内部APIといったリソースが利用できる。
- （クラスタの使い方次第で）モニタリングやロギングの設定を気にせず、同じDashboardに反映され、そのまま利用できる。
ただ意外にも、社内でKubernetesを使ってみて最も反響が大きかったのはインフラチームにいちいち依頼せずに利用できることでした。
