オープンでロックインなし業務でKubernetesを使うための“最高の仕事道具”とは

「オープンテクノロジーでベンダーロックインなし」が大前提

斎藤氏は、Kubernetesを活用するまでの課題として「学習コスト」「Kubernetesの周りで必要になるもの」「エンタープライズでどう適用するか」の3つを挙げた。

学習コストについては「勉強するしかないが、最近では多数のベンダーがKubernetesをサービスとして提供していることから、構築などを一から勉強する必要はなくなっている」と斎藤氏は語った。

学習コストはあるがKubernetesサービスが提供されている

次の、Kubernetesの周りで必要になるものが、本セッションの中心テーマとなった。斎藤氏はKubernetesを使おうとする際に思いつく疑問点として、「コンテナを使って早く開発したい」「モニタリングは？」「セキュリティやアクセス制御は？」「CI/CDはどうやるの？」「バージョン管理の単位は？」などを挙げた。

これらのために必要になるものは、IDEやソースコード管理、KubernetesのYAML、CI/CDパイプラインなどの開発ツールや、Kubernetes自身やアプリの運用ツールなどだ。さらに、コンテナ上で動くWebサーバーやデータサービスなどのミドルウェアも必要になる。「実際に使うには、単にコンテナやKubernetesだけでなく、いろいろと考えなくてはならない」（斎藤氏）。

Kubernetesのほかに必要になるもの

これらのツールの選択基準として、斎藤氏はまず「オープンテクノロジーでベンダーロックインなし」であることが「絶対重要」とした。さらに、企業として導入するには「『継続的に投資され、更新され、サポートつき』であること。Kubernetesが流行った理由の1つは、ベンダーがみんな手掛けているから」と指摘。

これらを大前提として、その上で重要なのが「組み換え自由であること」で、適材適所で好きなものを使えることが重要だと斎藤氏は述べた。「CI/CDを実践している人には当然のことかもしれないが、多くのお客様はそうではない。1回作って数年後にアップデートできない、ということがままある」（斎藤氏）。

オープンテクノロジーでベンダーロックインなし」であること

HelmでKubernetesに開発環境を作る

こうしたツールを使ってKubernetesで環境を構築する例を、斎藤氏は2つのシナリオで解説した。シナリオ1は、「Kubernetesで開発環境を作る」というものだ。

例えば、WordPressをKubernetesにkubectlでデプロイするだけでも、Kubernetes用の各種定義を用意したうえで永続ボリュームを作り、MySQLサーバーをデプロイし、MySQLを起動し、PHPサーバーをデプロイし、WordPressとロードバランサーをデプロイするという手順が必要になる。

簡単な構成でも定義と5つのコマンドが必要

そこで斎藤氏が推奨するのが「Helm」だ。HelmはKubernetesのパッケージングの技術で、利用するイメージや割り当てるリソース、可用性、外部公開などの構成を記述してパッケージングできる。これを元に実行すると、複数台構成がマネージされた状態でできあがる。

Helmの概要

シナリオ1の拡張版として、アプリ開発者のテスト目的で本番と同等の環境を用意する場合も解説された。これもKubernetesとHelmを使うとやりやすくなるという。

想定されたのは、認証・認可やカタログ、顧客情報管理などがマイクロサービス的に分かれたECサイトのアプリケーションだ。サービス数が約10個あり、起動するにはkubectlだと30回以上コマンドを実行することになるが、Helmを使うと簡単にできる。

さらにKubernetesのNamespaceで分離してやることで、同じクラスター内で本番環境に影響せずにテスト環境を構築できる。「Helmなら、1つのHelmチャートを作れば少し変えるだけでバリエーションが作れる」と斎藤氏は利点を説明した。

想定アプリケーションの構成

Helmでデプロイ

Namespaceで環境を分離

そのほかにも、Helmについて一部のアップデートやロールバックも簡単にできるところをデモで示した。

CI/CDを考慮したイマドキのアプリ開発プラットフォーム

シナリオ2は「イマドキのアプリ開発」だ。アプリ開発者がDockerfileを含めてコードを開発し、GitHubにpushすると、JenkinsからMavenによるビルドやDockerのイメージビルド、Helmチャートの作成などを起動し、Kubernetesクラスターにデプロイするという、CI/CDを考慮した流れとなる。

このときに必要なのが、細かいところは対象ごとにカスタマイズでき、ほかの構成要素でも使えるようになっていることだ。斎藤氏は「さきほど『組み換え自由であること』を基準に挙げたのは、こういうことだ」と説明した。

CI/CDを考慮したイマドキのアプリ開発の流れ

斎藤氏はコンテナ上のWeb IDEで説明。新しいプロジェクトを作って言語やフレームワークを選ぶと、コードの雛形のほか、DockerfileやJenkinsfileなどの雛形などができるところを示した。「こういうものがあるからCI/CDが使える」と斎藤氏。コードを変更するとビルドが走り、動作確認やログ、パフォーマンステストなどを開発する段階で見られる。「『Kubernetesやります』だけでなく、こうした仕組みを最初から考える、または考えなくても勝手にそうなる状態を作って提供しておくのが重要だ」（斎藤氏）。

Web IDEでDockerfileやJenkinsfileなどの雛形もできる

JenkinsによるCI/CDパイプライン

既存アプリケーションのモダナイズ

最初に掲げられた課題の3つめは、エンタープライズでどう適用するか、既存アプリケーションをどうクラウドネイティブにモダナイズするかの「Modernization Journey」だ。

Modernization Journey

第1段階は「Assess and Plan」で、アプリケーションを分析する。データをアプリケーションのコンテナの中に置くと問題がある、といったところから抽出し、どうやって新しいものにしていくかをツールや人力で分析する。

第2段階は「Move, Modernize, Deploy」で、あらゆるものをコンテナ化してKubernetes基盤に乗せていく。同時にCI/CDの仕組みに最初から嵌めこんでいく。

そして第3段階が「Common Hybrid Cloud Patform」だ。どのようなクラウドでも動かせるように、DockerやKubernetes、Helm、Terraformなどの技術を使ってマネージしていく。

Modernization Journyの流れ

斎藤氏はここで、セッション冒頭からここまでのまとめとして「使えるものは使う。このときオープンテクノロジーを意識する」と「HELMやCI/CDを使うのがおすすめ」とポイントを挙げた。

IBM Cloudの特徴

セッションの最後に、斎藤氏は「IBM Cloud」を紹介。IBM Cloudの特徴として、パブリッククラウド、Dedicatedなクラウド、インストールして使うPrivateの3種類に対応していることを挙げた。

IBM Cloudの特徴

その中でも、斎藤氏は「IBM Cloud Private」について重点的に説明した。単なるコンテナやKubernetesの基盤だけでなく、その上で必要な機能が揃っているのが特徴だという。「DevOpsツールチェーンやインストールした瞬間から運用監視が動くこと、コンテナの脆弱性検査、暗号化、ロールベースのアクセス制御など、これらをビルトインで提供している。『試してみたい』のレベルだけではなく、フルサポートを提供する製品だ」（斎藤氏）。