クラウドネイティブスクエア

1. クラウドネイティブとは

クラウドネイティブとは、クラウド環境を最大限に活用するために、「最初からクラウド上で動作することを前提に」設計・開発されたシステムやアプリケーションを指すものです。クラウドネイティブの定義については以下の記事にもまとめられておりますので、ご参照ください。

クラウドネイティブ化の具体的手法を解説！企業のアフタークラウドを支援するNebulaShift【イベントレポート前編】｜SCSK IT Platform Navigator

クラウドネイティブには以下のような様々なメリットがあり、アプリケーションの迅速な更新、高い可用性、コストの最適化などが期待できます。

• アプリケーションをマイクロサービスとして分割し、コンテナ技術を使って実行することで従来のシステムよりも迅速に開発や運用が可能（アジャイルの適用が容易）
• サービス間の通信を管理し、負荷分散や高いセキュリティ性を実現することによる信頼性向上
• 自動化によるコスト削減

2. モダナイズとは

クラウドネイティブの考え方が活躍するシーンとして、前項でご紹介した記事ではDX推進の課題解決と述べております。

DX推進にあたり以下のような課題を抱える現場で、ITのモダナイズに取り組むことが課題解決に向けた一歩となると考えております。

• 既存のIT資産のお守りをするだけで手いっぱい（レガシーシステムの問題）
• 既存システムを今後クラウド移行していかなければならないのに、さらにそこからDX向けの環境を増やしていかなければならないのは負担
• 今後、人が減ることが明らかな中、時間をどうやって捻出していけばいいかわからない

ITのモダナイズとは、現在および将来のビジネス目標をより適切にサポートするために、組織の古い IT インフラストラクチャの一部または全部を更新するプロセスのことです。

一言にモダナイズといっても、モダナイズの目的により取りうる手段には様々なものがあります。

例

インフラの調達スピードアップ

オンプレミスからクラウドへのリフト

商用ライセンスからの脱却

OSSへの変更

運用のコスト削減・手動運用削減

Ansibleなどを使用した運用作業の自動化

アプリケーションリリースのスピードアップ

CI/CDの導入、マイクロサービスアーキテクチャ・コンテナアプリケーションへのシフト

NebulaShift®ではモダナイズの支援も行っておりますので、こちらの記事もご参照ください。
レガシーシステムをモダナイズしたい￨NebulaShift®

絶賛コンテナ技術勉強中の私は
アプリケーションのモダナイズを進めるにあたり、コンテナアプリケーションへのシフトを行おうと考えたときに、コンテナ技術がLinux系OSをベースとした技術であることから、

• Windows OSをベースとしたアプリケーションは対象外となるの？
• アプリケーションの基盤が別になるなら運用の手間が増えるだけでは？

という疑問を持ちました。

NebulaShift®ではコンテナ基盤として、Red Hat OpenShift Container Platform（以下、OpenShift）を取り扱っておりますため、今回の記事ではOpenShiftでのWindowsアプリケーションをどう動かしていくのか、をテーマに触ってみた結果をお伝えしていきます。

3. OpenShiftでWindowsノードを立ててみた

OpenShiftではWindows OSのCompute Node上にWindows OSをベースとしたコンテナアプリケーションを立ち上げることができるようになっていたので、Windows OS のCompute Node（Windowsノード）をOpenShiftに追加した際の手順をご紹介します。

1．やったこと

AWS上にOpenShiftをIPIインストールし、Control Plane Node×3、ComputeNode×2 OS:RHEL Core OSを構築したのちに、Compute Node×1 OS:Windowsを追加で構築しました。

2．システム構成図

OpenShiftはversion4.13を使用しました。（バージョンが古い点はご容赦ください。）

3．手順

①AWS上でOpenShiftのインストール

今回はIPIインストールにて構築しました。
Windowsノードを使う場合はnetworkTypeをOVNKubernetesとする必要があります。IPIインストール時にはRHEL CoreOSをベースとしたNodeのみ指定しています。

ハイブリッドネットワーク設定用マニュフェストファイルを作成してインストールを開始します。クイックインストールの手順だけを見ていたらインストール前作業として対応が漏れており再度インストールが必要になったので、注意が必要だと感じました。

②各種設定とログイン確認

以下の設定を行い、構築したOpenShiftクラスターへのログイン確認を行います。

• oc cliダウンロード
• KUBECONFIG設定
• （必要に応じて）ユーザ追加

③Windows Machine Config Operator (WMCO)インストール

WEBコンソール、またはCLIにてWMCOをインストールした後、Windows Machine Config Operator のシークレットを設定します。

④Windows MachineSet作成

Windows MachineSetオブジェクトのyamlを作成し、yamlファイルの適用（oc apply -f yamlファイル名）によりWindows MachineSetを作成します。

Windows MachineSetオブジェクトのyamlに以下の要素を入れます。（minimumスタートで細かい設定を行わない場合）

• nfrastructure_id
• windows_container_ami
• AWSゾーン
• AWSリージョン

以下、yamlファイルの例。

Windows MachineSetが作成されたことを確認します。
以下のようにAVAILABLEになっていない場合は、証明書の承認が必要になるため、
保留中の証明書要求をすべて承認してから確認します。

保留中の証明書要求の承認は以下のコマンドを実行します。

⑤WindowsNodeできあがり！

今回はNodeの作成までとして、Windowsコンテナアプリケーションの立ち上げまでは検証していません。

【参考URL】
4.1. Windows Machine Config Operator のインストール
4.2. Windows Machine Config Operator のシークレットの設定
5.1. AWS 上での Windows マシンセットの作成
6.2.1. Route 53 の設定
6.4. クラスターの AWS へのクイックインストール
6.6.10. OVN-Kubernetes を使用したハイブリッドネットワークの設定
9.9. マシンの証明書署名要求の承認

4. OpenShift上でのWindowsアプリケーションを動かすには

前項の手順でWindowsノードを構築することができましたが、自身の知識不足もあり、エラー発生時に原因特定に足る情報がRed Hatドキュメントからは見つけられず、自分で必要箇所をピックアップして順番に実行していくのに手こずりました。

この次のステップとしてWindowsOSをベースとしたコンテナアプリケーションを立ち上げようとした場合には、エラー発生時のトラブルシュートなど、Linux系OSベースのコンテナアプリケーションに比べてナレッジが少ないことでうまく進まないのではないかと懸念しています。

基本思想としては、コンテナ化することによるメリット（OSパッチの影響を受けづらいなど）もあるので、アプリケーションのモダナイズを行いコンテナ化していけるとベストなのですが、モダナイズに大量のコストがかかるケースや、どうしてもコンテナ化の難しい（OSと切り離せないなど）アプリケーションもあると思います。その場合に、OpenShiftなどのコンテナ基盤に加えて、VMなどのWindowsアプリケーション用の基盤を分けることになると基盤が統一されておらず運用の手間が増えてしまう可能性もあります。

そのケースでは、OpenShift上で仮想マシンとしてWindowsアプリケーションを立ち上げることができる、Red Hat OpenShift Virtualizationという製品も取り扱いがございますので、是非ご検討いただければと思います。
構成イメージは以下です。

今後、Red Hat OpenShift Virtualizationに関するブログも載せていく予定です。乞うご期待！