連載：第九回「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（2/2）

はじめに
「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。

前回はOpenShiftの特徴を説明できるか！？(1/2）では生K8sについておさらいしましたが、今回は「Red Hat OpenShiftの特徴を説明できる？」(2/2)と題して、ざっくりとした違いと特徴を記述します。恐らく、急に聞かれたら言えない営業も多いと思いますので、最後の【まとめ】だけでも覚えておくとよいと思います。

第一回記事：「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事：「DXを売る」”DXに関心を持たせる”　営業トーク 」
第三回記事：「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事：「DXを売る」”IT自動化とDX推進を繋げる５つのポイント”
第五回記事：「DXを売る」営業の素朴な疑問　”コンテナってどこでも動くの？”
第六回記事：「DXを売る」営業の素朴な疑問　”サイドカーって何モノ？”
第七回記事：「DXを売る」営業の素朴な疑問　”コンテナ向けOSって何？”
第八回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（1/2）
第九回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（2/2）
第10回記事：「DXを売る」DX営業　”サービスメッシュ”　を説明できる?
第11回記事：「DXを売る」DX営業　”API連携とは何？”を理解する
第12回記事：「DXを売る」DX営業　”APIマネージメントとは？”　を理解する！
第13回記事：「DXを売る」DX営業　”K8sの機能を理解する”！
第14回記事：「DXを売る」DX営業　”Podmanを知っている？”
第15回記事：「DXを売る」DX営業　”Pod”についての理解

【特徴１】”ばら買い”or”セット買い”どっち？　セットでしょ‼

図をみていただくとわかるように、生K8sをばらで組み立てて使うか？　利用しやすいセットを利用するかだと思います。

前回のBlogでも説明したとおり、生K8sだけではうまく運用できないので、様々なOSSなどを組合せて利用するケースが多いです。Operating System(OS)も別途入手、ワークロード抽象化の項目のようなソリューションを組合せます。

セット買いの方が一般的な企業で利用するならば便利に決まってます！
経験の少ないエンジニアが、各々を入手して導入して動作確認しているうちに日が暮れてしまいますし、本来そんな作業をするお仕事ではないはずです。例えば生K8sを導入しようとした場合、

• 利用するK8sに適合するOSを用意
• K8sを導入
• サービスメッシュなどのK8s管理関連のツールをいくつも入れる
• 開発環境から運用までの環境を揃える
• その他の必要なコンポーネントを選んで導入する
• テストして使えるようにする
• K8sがバージョンアップしたら関連するものを全て見直してupdateするものはupdateする
• セキュリティのことも考慮
• 「OpenShiftを使えば、OSを含めてある程度利用できるセットが揃っているので導入も運用も楽になる」

【特徴２】自動化してくれる”Operator”が含まれている

IT業界の人ともお話をする機会があるのですが、Operatorを知らない人がまだ多いように思います。
恐らく、私が認識するOpenShiftの特徴で一番重要なのは、この”Operator”だと思います。
何故か？

• コンテナやクラスタシステムを管理するには、管理者の負担がハンパないから！
  例えば
  • 異常を継続的にチェック
  • 人による障害復旧作業
  • 手動のコンテナ変更作業
  • アプリケーションごとの設定管理
  • ビジネス変化に応じたリソースの調整

ということで、コンテナの数が数千、数万、それ以上を考えるとエンジニアのモチベーションが下がります。

K8s自体もいろいろ便利なのですが、アプリケーションをコンテナ化してエンタープライズで利用しようとすれば大変なことになり、エンジニアリソースが足りなくなります。

• そこでOperatorについて簡単に説明します。
  • 一言でいうとK8sのAnsibleみたいなものです
    • 運用の知見をコード化して、アプリケーションの運用を自動化します
  • 以下のような作業を自動化します
    • インストール
    • リソーススケーリング
    • バックアップ
    • アップデート
  • どのようなプロセスで動くのでしょう？
    • アプリケーションの現在の状態を判断する（Observation）
    • アプリケーションの現在の状態とアプリケーションの予想される状態を比較する（Analysis）
    • アプリケーションの実行状態を期待状態に一致させるための処理をおこなう（Action）

【特徴３】Operatorの種類が増えて便利が加速！

• 便利そうなOperatorですが、アプリケーション毎に作る必要があります。
  すでにRed Hatが認定しているOperatorも数多くありますが、各アプリケーションベンダーからも提供されていますので、利用可能なOperatorは日々増えています。

以上のように、Operatorにはいくつかカテゴリーがあることが想像できると思います。

• 以下にカテゴリーと説明を記述します。（Red HatのWebサイトより転記）
  • Red Hat Operator
    Red Hat によってパッケージ化され、出荷される Red Hat 製品。Red Hat によってサポートされます。
  • 認定Operator
    大手独立系ソフトウェアベンダー (ISV) の製品。Red Hat は ISV とのパートナーシップにより、パッケージ化および出荷を行います。ISV によってサポートされます。
  • コミュニティOperator
    operator-framework/community-operators GitHub リポジトリーで関連するエンティティーによってメンテナンスされる、オプションで表示可能になるソフトウェア。正式なサポートはありません。
  • カスタムOperator
    各自でクラスターに追加する Operator。カスタム Operator を追加しない場合、カスタムカテゴリーは Web コンソールの OperatorHub 上に表示されません。

以上のように様々なOperatorが提供されてきており、安心して利用可能なOperatorを探して利用できる環境が整いつつあるのです。
余談ですが、以前にRed Hatの方が、OpenShift自体もOperatorにより自動化されていると言っていました。
さらに余談ですが、Operatorの開発にお困りでしたらサイオステクノロジーまでお問合せください。

【まとめ】

1. OpenShiftは、必要なコンポーネントが含まれていて導入が楽
2. CoreOS（コンテナ用のLinux）が同梱され、OSレベルまでの心配をしなくてもよい
3. OperatorがOpenShiftに適合され、自動化が進んでいる
   今後もOpenShiftの自動化が進化していく
4. サポートはRed Hatなので安心

以上、
今回のBlogの内容はお役に立ちましたでしょうか？
今後のBlog記事に関するご要望や実際のビジネスでのご相談事などございましたらお問合せいただきますようお願いいたします。最後まで読んでいただきありがとうございました。