さあ、SUSEでCloud Foundry on Kubernetesをはじめよう！（後半）

前半では実際にCloud Foundryを触ることをご紹介しましたが、後半では商用では実際にどう使うのかというお話、SUSEの持つ優位性についてご紹介したいと思います。PaaSを利用するにはベンダーが提供するサービスもございますが一社のみが提供するサービスには将来性や柔軟性において大きなリスクがあります。オープンなCloud Foundryであれば他社との連携や移行のハードルがなくなります。

Cloud Foundryを利用するにはベンダーマネージドのサービス（オンプレ、クラウド）を使う方法もありますがDEV/TEST/PROD環境を揃えるとそれなりの金額になるかと存じます。また2020年現在、SUSE以外のCloud FoundryはVMwareの上で動いておりポータビリティーやスケール、耐障害性などのコンテナのメリットをフルに享受出来ないという難点やBOSHという（何でも出来るけど）学習コストの高い言語を扱う必要があります。結局、ライセンス費用やコンサル費用を考えると規模感が…。そこで今回はパブリッククラウドサービスプロバイダーが提供するKubernetes(EKS, AKS, GKE)上にCloud Foundry環境を簡単にご利用いただけるSUSE Cloud Application Platformについてご紹介します。

Amazon EKSの場合

いくつか方法をご紹介しますが、まずは一番簡単なAWSのクイックスタートを使う方法をご紹介します。こちらのURLにアクセスして必要な情報を入力するだけで１時間ほどでCloud Foundryの環境を構築可能です。

デプロイガイドを開いてクリックして開始します。Step 3. Launch the Quick Startまでスクロールダウン。必要な条件等もこのドキュメントにまとまっております。前提条件としてはAWSのI AMアカウントがあること。全リージョン対応ではないのでご了承ください（個人的にはNorth Virginia使ってますが東京も対応してます）。

既存のVPC使うのでなければ左側の青い方をクリックしてCloud Formationを起動。

新規作成でよければそのままデフォルトのテンプレートを選択してで次へ。

あとはテンプレートに必要事項を入力するのみです。事前に設定が必要なのはRoute53（ドメイン取得とHosted zone ID）とSSH keyのみです。それ以外は各環境のポリシーに合わせて入力をします。その他のパラメータで変更を考慮する必要があるのはクラスター数やGUIの利用可否くらいかと思います。

開始すると裏でスタックが自動で作成されていきます。概ね40-60分ほどで構築が完了します（たまにエラーで止まりますが多いのはI AM権限関係のエラーです）。エラーの場合はスタックが削除されて自動でロールバックされますが親スタック以外が残る場合があります。その際には手動で対応して正しいパラメータで再実行します。

完了したら親スタックのOutputsに必要なEndpointの情報やGUI(Stratos)の情報が出力されます。その後は前半でご紹介したのと同様にすぐにアプリケーションをCloud Foundry上で動かすことが可能です。なお、パスワードはSecret managerを探してください。

Azure AKSの場合

次にAzureのマーケットプレイスからデプロイする方法をご紹介します。こちらもテンプレート化されており必要な情報を入力していくだけでCloud Foundryの世界を始めることが出来ます。

“GET IT NOW”をクリックしてスタートします

新規で作成するかプリセットされたコンフィグを使うか選択して開始します。

インスタンス、ディスク、ネットワーク、管理など項目ごとに情報を入力して作成します（以下、冗長となるので省略させて頂きます）。

EKS/AKS/GKEにデプロイ

導入の容易性を考慮して二つのパターンをご紹介しましたが最新バージョンや大規模導入、GKEの場合にはTerraformを活用して導入が可能です。こちらのGitHubにテンプレートがありますので興味があればご活用ください。手順に関してもマニュアルをリンクしておきます。
https://github.com/SUSE/cap-terraform
https://documentation.suse.com/suse-cap

また現在はAzureのみがマーケットプレイスに対応しておりますが近日中にAWS/Googleにおいてもマーケットプレイスからのご利用が可能となる予定です。その際、ライセンスはBYOS(Bring Your Own Subscription)となっておりますが、これも本年後半にはPay-as-you-goでご利用可能になる予定でございます。短期間のみ、もしくは反復の多いシステムの場合に１時間で環境を用意して１週間のみ使うようなオンデマンド・サブスクリプション利用が可能になります。これもSUSEの大きなアドバンテージですので今後にご期待ください。

Cloud Foundry on Kubernetesがなぜ素晴らしいのか？

最後に、なぜKubernetes上でCloud Foundryを構築することが良いのか。なぜSUSEがそんなことをしているのかを少しお伝えしたいと思います。以前書きましたとおり、SUSE以外のディストリビューションはCloud FoundryをVMware上で提供していますが、コンテナ化することで様々なメリットを享受出来るようになります。

そのメリットとは：

• VMwareのライセンスが不要
• 学習コストの高いBOSHが不要
• 1/3～1/4のメモリで動作
• コンテナとKubernetesのメリットを享受可能

その結果、構成や期間によっては最大90%ほどコストを抑えて全く同じ環境をご利用頂くことが出来る様になります。これはCloud Foundryのメリットをさらに高めるものでコストが見合わない、規模の小さいプロジェクトやSMBのお客様にも提案が可能になります。経営者にとっては魅力的でしょう。もう一つはアジャイル、ポータビリティー、スケール、冗長性、自己修復などKubernetesのアドバンテージを最大限に有効活用出来る様になります。これはアプリ開発者、インフラ担当者にとって大きなメリットとなります。そんなコンテナ化されたCloud Foundryですが現在パッケージ化して企業向けにサポートを提供しているのはSUSEのみでございます。

ここでなぜSUSEかという話を少し書きたいと思います。SAPやHPCの世界では有名ですが、それ以外の方にはカメレオンの縫いぐるみの印象が強いという方が多いと思います。しかし、実はKubernetesとCloud Foundryにも力を入れております。話はSUSEがHPEのHelion Stackatoを買収したところに遡る訳でございますが（詳しくはWebで）、その後IBM、SAP、Pivotalとも連携しながら主に以下のプロジェクトに携わっておりました。

CF コンテナ化は仮想マシンの代わりにCFAR(Cloud Foundry Application Runtime)をコンテナとしてパッケージ化し、CFARをKubernetesにデプロイ出来るようにする取り組み

CFARのプラガブルスケジューリングを有効にする取り組み（運用者はCFARがDiegoかKubernetesのどちらかを利用するか選択可能です）

前半の記事でもご紹介しましたCloud Foundryを管理するためのWebベースのUIに関する取り組み

ユーザーと管理者の両方がCloud Foundryクラスターで実行されているアプリケーションを管理し、クラスター管理タスクを実行することができます

Kubernetes向けのアプリケーションランタイムディストリビューション
Cloud Foundry Application Runtimeのオープンソース実装

そう、最後のKube CFはSUSE Cloud Foundryとして開発されていたscfが2020年3月20日にインキュベーションプロジェクトとしてCNCFに寄贈されました（関連記事参照）。今後はCF on K8sが主流となっていく訳ですが、その様な流れもあり実はSUSEもLinuxだけではなくパフォーマンスとセキュリティに優れたカーネルを活かしてKubernetesとCloud Foundryにガッツリ取り組みパッケージ化をしているという次第でございます。KubeCFについて興味のある方はこちらのブログもお読み頂くと良いかと思います。

Cloud Foundryが頭に浮かんだ際には数あるディストリビューションの中にSUSEという選択肢を入れて頂ければこれ幸いでございます。またアップデートがあれば共有させて頂きたいと思います。

お問い合わせに関して

• この記事に関するお問い合わせは、担当までお寄せください。
• 当該ブログの記述内容は、製品マニュアル、各種サービスに関する説明、プレスリリースなど弊社が配布する文書、Webサイト上の情報を基にできる限り正確な記述に努めておりますが、もし内容が異なる表現や複数の解釈が可能な表現があった場合には、製品マニュアル、各種サービスに関する説明、プレスリリースなどの情報を正しい情報としてご理解の上、担当まで御一報ください。