JavaアプリケーションのDevOps ～OpenShiftならこんなに簡単～

目次 Table of Contents

1. はじめに
2. Javaアプリケーションの現状とDevOpsに対する課題
3. JavaアプリケーションとOpenShiftによるSource2Image(S2I)の組み合わせ
4. まとめ

1.はじめに

みなさま、クラウドネイティブしていますか！？ NADPの兼田です。エンタープライズで用いられるサーバサイドのアプリケーションとして、Javaを用いている企業様は多いですよね。Java自体、JVMというレイヤがあるために実行環境を選ばないといった特性がありますが、DXを進めるにはデプロイだけではなくソース改修も頻繁に進めていく必要があります。耳にタコですが、DevOpsとCI/CDですね。今回はそんなお話をさせていただきます。

2.Javaアプリケーションの現状とDevOpsに対する課題

“はじめに”で述べた通り、Javaは多くの企業で、特に金融機関においても利用されている技術(※1)です。Mavenを代表とするプロジェクト管理ツールを用いて実行環境をパッキングし、Apache Tomcat/JBossといったアプリケーションサーバ上で実行し、アプリケーション層を担当する、といったアーキテクチャはよく見られるものです。旧来の開発スタイルでは、ビジネスロジックの改修が必要となった際に、Mavenと連携したIDEからビルドを実行し、パッキングした実行環境(多くの場合、.jarファイル)をアプリケーションサーバへ配置し、テストを実行してデプロイといった手順が必要であり、人力、もしくはスクリプトを用いた簡易自動化で実行する、という場面を見ます。でもこれ、ビジネスのアジャイル化にはいくつか問題があると思いませんか？

• 開発環境はどのように統一化しますか？開発者にインストール手順書を渡したとして、手順書のメンテナンスは不要ですか？
• IDEで見ているソースコードは何で管理していますか？バージョン管理はどうしていますか？
• Javaのバージョン管理はどうしますか？クリティカルな脆弱性が発見された場合、即座に対応できますか？
• デプロイ時＆テスト時、失敗したビルドはどのように扱いますか？簡易自動化では失敗したビルドが勝手にデプロイされてしまいませんか？

業務システムの開発経験の薄い兼田ですら、パッと上記くらいの課題は思い浮かんでしまいます。さらに、システム全体に視点を上げてみると、可用性はどうするか、応答速度のチューニングは何に影響を受けるか、などなど、非機能要件の点においても、多くの現場ではKKD(勘/経験/度胸、ですね)に頼ったアーキテクチャが実装され、プロジェクトの属人化というさらなる課題に行き当たってしまいます。

結局のところ、Javaが実行環境をパッキングする仕組みを持つとはいえ、DevOpsやCI/CDといった文脈では、より低レイヤから開発の仕組みを見直す必要があるということです。モダンなアプリケーション基盤として、デジタルの力を頼ってElasticな繋ぎこみに変容させていく必要がありそうですね。

3.JavaアプリケーションとOpenShiftによるSource2Image(S2I)の組み合わせ

そこで、Red Hat OpenShiftの出番です。OpenShiftはどのようなアプリケーションにも柔軟性を持たせることのできる、非常に強力なプラットフォームです。Javaですら上記の課題を抱えているため、その他開発環境においてもコンテナ化という要素がどれだけDevOpsの中での比重を持っているか、ご理解いただけると思います。

OpenShiftによるソースコードのコンテナ化は非常に簡単です。S2I(Source2Image)と呼ばれる機能がすでに備わっています。Docker/LXCベースのコンテナビルドとどのように異なるのか、イメージを見てみましょう。

内部の流れとしては両者に違いはありませんが、S2Iの場合はターゲットのアプリケーションに対して非常に柔軟なビルドを行うことが可能です。今回はS2Iを対象とした記事になりますが、S2Iではイメージストリームと呼ばれる仕組みを用いて、アプリケーションのバージョンごとにタグをつけることで、本番デプロイ時のCanaryやBlue/Greenデプロイメントといったことも簡単にできるようになっています。(※2)

また、Gitリポジトリ―からの直接ビルドが対象となっていることも大きな特徴です。Docker / LXC ベースのビルドでは、ソースコードの生ファイルをビルド時にコンテナ内部へコピーする必要がありますが、S2Iを用いた場合は、パッケージ管理ソフトの設定ファイル(Mavenの場合はpom.xml)を自動認識し、OpenShiftクラスタへcloneしてソースコードのコンテナ化を実行します。素のJavaアプリケーションをデプロイする際に浮かび上がっていた課題が、見事に解消されているのがご理解いただけると思います。

実際のビルド手順をご紹介します。題材としては、当社サービスの住所コードAPIを一部OpenShiftへ載せ替える、といったシナリオを想定しています。

S2Iの手順をお見せするうえでもっとも簡単で分かりやすいのは、OpenShift WebコンソールのDeveloperパースペクティブから、対象のGitリポジトリ―を指定する方法です。

プライベートなGitリポジトリーを対象とする場合、公開鍵方式でアクセスすることが可能です。アクセスするための秘密鍵はセキュアなものなので、OpenShiftのProjectへsecretリソースとして暗号化して保存しておくことが出来ます。

S2Iによるビルドで特徴的なのが、インポートストラテジーです。今回はBuilder Imageを利用することで、ソースコードの実行環境をBuilderとしてコンテナへ入れ込むことが出来ます。(実際は、入れ込むというよりはBuilderが指定するベースイメージをもとにコンテナを作成する感覚です。) Builder Imageを指定する他にも、DockerfileやDevfile(※3)を指定することも可能です。

早速ビルドを開始してみましょう！GUIで入力した情報から、buildconfigリソースが作成され、それに伴ってbuildも自動で生成されます。buildのpodがcompletedになれば、アプリケーションがpodとしてデプロイされたことになります。ビルド中はbuildのpodからログを確認することもできます。眺めていて楽しい他に、ビルド失敗時の切り分けにも役立ちます。

今回はサービスのフロントも持たせているコンテナとなりますが、OpenAPIで設計された、RestAPIが返ってくるアプリケーションですので、curlやpostmanでrouteのFQDNへHTTPリクエストを送ることで動作確認ができます。(当サービスは有償のものですので、返ってくるレスポンスは記事上では内緒にさせてください。)

このように、S2Iを利用することで簡単にソースコードをコンテナにすることが可能です。S2Iは非常に応用が利く仕組みなので、この仕組みをベースにCDを実装することが出来たり、Gitリポジトリ―へのcommitをトリガーとしてビルドを実行することでCIが実現出来たりします。実際に当サービスでも、ArgoCDを用いたCDを実装し、利用しています。

また、執筆の都合上OpenShiftのWebコンソールからS2Iを実行しましたが、オープン・ハイブリッドクラウドを標榜するRed Hat社のソリューションですので、当然.yamlによるS2Iも可能です。(※4)すなわち、.yamlファイルをバージョン管理することで、CI/CDパイプラインすらも自在に管理することが可能となります。

4.まとめ

いきなり兼田のパーソナルなことを書かせていただきますが、私はエンジニアとして「人間は間違いを犯すから、機械様が得意なことは機械様に任せるべき」という仕事観を持っています。Infrastructure as Codeといった概念もとても好きです。今回はJavaアプリケーションの手動デプロイにおける問題と解決手段を解説する記事ですが、アプリケーションモダナイズであれば環境を問わず同席してしまう問題を、OpenShiftであれば機械様が解決できるよ、ということを記事にしてみました。DXに踏み出す勇気がなくとも、当社ではモダナイゼーションサービス(※5)によってアプリケーションを少しずつマイクロサービス化していくお手伝いをさせていただきますので、ご興味を持たれた方はぜひお話だけでもお伺いできればと思います。

————————————————————————————————

参照一覧：
(※1) 数字で見る 2020年における Java の現状 | The IntelliJ IDEA Blog (jetbrains.com)
(※2) When to use canary vs. blue/green vs. rolling deployment (techtarget.com)
(※3) OpenShiftによるお手軽統合開発環境 ～CodeReady Workspacesを添えて～
(※4) Build lean Java containers with the new Red Hat Universal Base Images OpenJDK runtime images | Red Hat Developer
(※5) Nissho Application Digital Platform – Natic

————————————————————————————————

記事担当者：:アプリケーション事業推進部　兼田 涼
投稿日：2022/10/28