さくらのサービスを支えるコンテナ活用術を公開！「さくらの夕べ Docker/Kubernetesナイト #2」レポート

11月5日(火)の夜に「さくらの夕べ Docker/Kubernetesナイト #2」を開催しました。前回の「さくらの夕べ Docker/Kubernetesナイト」に続き、今回も100人以上の方にご参加いただき、会場は超満員！たくさんのご来場ありがとうございます！　今回もさくらのエンジニアたちがDockerやKubernetesなどをどのように使いこなしているかを発表しました。その模様をお伝えします！

簡単に使える！Docker Swarmオーケストレーション入門

最初の発表はデベロッパーアドボケイトの前佛雅人による「Docker Swarmオーケストレーション入門」です。

コンテナを使ったオーケストレーションツールとしてはKubernetesの知名度が高いですが、Dockerにもはじめから内蔵されているSwarmモードというものがあり、これを使うことで簡単にオーケストレーションを行うことができます。

オーケストレーションツールの役割は、複数のホスト・システム上を横断するアプリケーションを状況に応じて適切にスケール(拡大・縮小)することです。Docker Swarmにおいては、クラスタの起動やホストの参加・除外などのクラスタ管理はdocker swarmコマンド、サービスのデプロイや稼働状況の確認といったサービス管理はdocker stackコマンドを使用します。それぞれ実行例を掲げます。

• クラスタの起動

  % docker swarm init

• ホストをクラスタに参加させる

  % docker swarm join -token <トークン> <IPアドレス>:2377

• サービスのデプロイ

  % docker stack deploy -c docker-compose.yml <サービス名>

この発表では、これらの説明に加えて実演も行われました。ホスト名を表示する簡単なアプリを実装したnginxのコンテナを3台デプロイし、アクセスすると3台のいずれかが応答します。Docker Swarmではクラスタを作るとIngressネットワークと呼ばれる内部ネットワークが自動的に構築され、ルーティングや負荷分散をしてくれます。さらにサービスのバージョンアップ(新しいバージョンのコンテナをデプロイすると自動的にアップデートが走り稼働するコンテナが置き換えられる)や障害発生(3台のうち1台が停止すると自動的にルーティング先から除外される)などの実演もありました。実演の模様は配信のアーカイブで見ることができます。

最後に前佛から「Docker Swarmは簡単なのでぜひ試してみてほしい」というコメントがありました。Kubernetesを使うほど大規模や複雑なシステムでなければ、Docker Swarmは十分に使う価値があると感じました。

さくらのクラウドでKubernetesを動かすコツ

2番目の発表は、技術本部ストレージチームの金澤直輝による「Deploy & Manage Kubernetes on SakuraCloud」です。金澤は当社で新サービスの開発に従事しており、その中でコントロールパネルやAPIなどの基盤にKubernetesを利用しています。その経験をもとに、さくらのクラウドにKubernetesを載せる際のコツを中心に話をしました。

新サービスの基盤構成を図に示します。さくらのクラウドと物理サーバを併用しているのが特徴で、両者の接続には当社の各種サービスをつなぐ「ハイブリッド接続」を用いています。当初はクラウドと物理サーバにまたがってKubernetesクラスタを展開していましたが、現在はクラウドだけで展開しています。基盤のCNI(Container Network Interface)にはCalico、ユーザ管理にはクライアント証明書認証など複数の方法を併用しています。(参考記事：「Kubernetesのユーザー管理と認証・権限確認機構を理解しよう」)

さくらのクラウドにKubernetesをデプロイする工程は、サーバの展開→サーバの初期設定→Kubernetesクラスタのデプロイ、です。サーバの展開にはTerraform、初期設定にはAnsibleを利用しています。初期設定における注意点として、systemdが勝手にswapを有効化してしまうので強制的に無効化する設定を追加することや、さくらのクラウドのロードバランサはDSR方式を採用しているので、それ用の設定が必要なことなどがあります。Kubernetesクラスタのデプロイにはkubesprayを利用します。ここでも、Ansibleのバージョンをそろえておかないとコケるとか、kubesprayのバグらしき動作が散見されるなどのTipsが紹介されました。

金澤の発表資料は公開されているので、詳しくはそちらをご覧ください。また、発表で紹介したツールについてはGitHubにサンプルを用意しているので、興味を持たれた方は使ってみてください。

GitOpsでKubernetesのCI/CDを美しく

3人目として登場したのは技術本部アプリケーショングループの川井俊輝で、「k8sにおけるCI/CD事例の紹介」という演題で発表しました。

Kubernetesに限らず、システムの継続的な更新をサポートする仕組みとして、CI(継続的インテグレーション)やCD(継続的デリバリ)といったものがあります。CI/CDツールとしてはJenkinsが有名ですが、Jenkinsは世代管理が困難だったり、CIもCDもできるため権限の分離ができず、例えばテスト用の更新を誤って本番環境にデプロイしてしまうといったトラブルを招くことがあります。

そこで現在川井が担当しているシステムでは、GitOpsの考え方を採用しています。KubernetesのあらゆるソースをGitで管理し、Gitを中心としてCIやCDのパイプラインを構成する手法です。管理ツールとしては、CIにはDrone CI、CDにはArgo CDを採用しています。このようにCIとCDを分離することで、CIはビルドとテストに集中し、CDはデプロイに集中することができます。また、分離ができていると、システム更新のワークフローにおいて、更新されたものをデプロイする前に運用者がチェックし承認するフローを入れられるので、デプロイのミスを防げます。

こう書くとGitOps万々歳のように見えますが、それでも運用してみるとわかる問題もあります。例えば、今回のシステムではコンテナをデプロイするのですが、アップロードされるのがコンテナイメージなので差分がコンテナイメージのハッシュ値にしか表れず、どこが変更されるのかわかりません。そこで対策として、デプロイに使用するManifestを生成するときに、Drone CIにて対象となるプルリクエストやissueを紐付けることで更新内容がわかるようにしています。また、今回の環境ではTelepresenceというツールを用いてローカル環境のアプリを開発環境に接続してテストを行っていますが、Telepresenceの仕様で同時に複数人が接続することができません。これに対しては、Namespaceを開発者ごとに分けることで複数人の接続を可能にすることを検討中です。

当社でも開発者の増加に伴ってチームで開発する例が増えています。複数人での開発をサポートする手法はこれからも大事になっていくだろうと感じました。

ISUCONの環境構築をDockerとKubernetesでいい感じにスピードアップ

最後の発表は、執行役員の江草陽太による「Dockerで動かすISUCONポータルと問題」です。

ISUCONは「いい感じにスピードアップコンテスト」の略で、与えられたウェブアプリケーションを制限時間内に高速化させ、その性能を競うものです。さくらインターネットは先日行われたISUCON9において、本戦の問題環境を提供しました。(参考記事：「ISUCON9本選問題の解説と講評」)

ISUCONに必要なシステムは、コンテストのポータルサイトと、参加者への問題提供システムです。ポータルサイトの主な機能は、GitHub認証(参加登録に使用)、チーム参加登録、コンテスト用OSイメージの共有、ベンチマーク実行、ランキング表示などで、実装にはNginx、Django、PostgreSQL、Redisなどを使用しました。ソースコードはGitHubで公開しています。

これの開発にDocker Composeを使ったのですが、江草はこれに限らずさまざまなサービスの開発を並行して手掛けており、その作業を自身のMacで行っています。サービスごとに使用するソフトウェアやバージョンが異なるのですが、DockerComposeを使うと個々の環境を独立したものとして作れるので、1台のマシンで複数のサービス開発を共存させることができます。また、本番環境で動かすときも、サーバにDockerとDocker Composeをインストールし、開発したものをGitHubからダウンロードし、サービスをSystemdに登録して起動するだけで動作するので、とても簡単です。もっとも、この方法ではコンテナを更新するときにダウンタイムが発生するので、無停止でコンテナを差し替えるにはKubernetesやDockerSwarmを使います。今回のように1台のマシン上にKubernetes環境を作るときは、minikubeを使うと簡単です。(参考記事：「簡単にローカルKubernetes環境を構築できるツール『Minikube』」)

それから、参加者への問題提供にもDocker Composeを使っています。問題として提示するウェブアプリケーションは、1つのプログラミング言語だけで作成するとその言語が得意なチームが有利になってしまうので、複数の言語で提供します(今回はGo、Python、Perl、PHPに対応)。参加者が簡単に言語を切り替えられるように、言語ごとにDockerfile、docker-composeファイル、Systemdのserviceファイルを用意し、参加者が使いたい言語のserviceファイルを設定して起動すればよいようにしました。

最後に江草から「コンテナを普段から使わない手はない」という言葉があり、すでにコンテナが日常的な開発ツールになっていることを感じさせました。こちらの発表資料も公開されていますので、詳しく知りたい方はご覧ください。

おわりに

江草からのコメントにもあったように、DockerやKubernetesは当社のサービス開発を支える重要なツールというポジションを得つつあります。社内でもエンジニアたちによる情報交換が行われており、今後もこのようなイベントやさくナレの記事という形で成果を報告できるかもしれません。

しかしその一方で、今回のイベントの参加者にコンテナの利用状況をうかがったところ、実稼働しているサービスにコンテナを使っている人は全体の2割ぐらいで、まだ様子見や情報収集の段階にある人が多いように見受けられます。このギャップを埋めるにはどうすればよいかが当面の課題になりそうです。当社でも先日からDockerの初心者向けハンズオンを定期開催しており、毎回キャンセル待ちが出るほどの人気を博しています(例：12月開催分)。ハンズオンセッションなので一度に大量の人に教えることはできませんが、地道に少しずつでもコンテナに慣れ親しむ人を増やしていくことが、このような便利なソフトウェアを使わせてもらっていることへのお礼になると思い、これからも取り組んでいきたいと考えています。

それではまた、次回のイベントでお会いしましょう！