fbpx

コンテナへ踏み出すための第一歩: JavaアプリをVMware Tanzu Build Serviceでコンテナ化！#vmware #mirantis #kubernetes #k8s

d-higuchiDockerKubernetesMirantis

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

現在オンプレミスや仮想マシン上で動作しているJavaアプリを、お手軽にコンテナとしてKubernetes上で動作させ、セキュアに運用し続けたい----そんな要望は少なくないと思います。

本稿では、そんな要望を叶えるシステムである VMware Tanzu Build Service (TBS)を、Mirantis Kubernetes Engine (MKE)と Mirantis Secure Registry (MSR)上に構築し、その魔法のような仕組みを紹介します。

「アプリのコンテナ化」とは？ その難しさ

「アプリをコンテナ化する」と聞いて何を思い浮かべるでしょうか？ Javaフレームワークの1つであるSpringを利用した自社開発アプリを例に考えてみましょう。

最近のソフトウェアであれば Docker Hub にコンテナの元となるイメージが共有されていることや、ソースコード内にイメージを生成するための「Dockerfile」が含まれていることも見かけるようになってきました。しかし、自社で独自開発したアプリはDocker Hubにはもちろん公開されていません。そして一般的にアプリをコンテナ化するためにはDockerfileを自作する必要があります。しかしDockerfileの学習コストは決して低くありませんし、イメージで使用するJavaやSpringの更新などのメンテナンスコストも大きくなります。

簡単にまとめると「アプリのコンテナ化」とは、

  • Dockerfileを記述する必要がある
    • 文法を学ぶ必要がある
    • 適切な記述方法や規則・知見・経験則などが必要
  • Dockerfileは継続的に更新する必要がある
    • アプリが新しくなれば、追従する
    • アプリが利用するフレームワークなど他ソフトウェアが新しくなれば、追従する

ということを満たしたイメージを作成することであり、コンテナ導入に二の足を踏む原因の一つとなっているでしょう。

VMware Tanzu Build Serviceとは

VMware Tanzu Build Service (TBS)とは、アプリを解析してコンテナ用イメージを自動作成し、Kubernetes環境で実行できるようにするVMware社の製品です。

  • Dockerfileを記述する必要がない
    • 昨今注目されているCloud Native Buildpacksを利用
    • アプリの内容を走査し、イメージを適切な形で自動生成
  • イメージを継続的かつ自動的に更新
    • アプリのソースが更新されたら、イメージも更新
    • アプリが利用するライブラリやフレームワークが更新されたら、イメージも更新

といった機能を持つソフトウェアです。もともとはオープンソースであるkpackの商用製品であり、

などを加えたものです。kpackだけでもさまざまなアプリのコンテナ化が実現できますが、JavaやSpringの長期サポートを含む点がVMware TBSの大きな特徴です。長期にわたって安定稼働を求められるアプリをコンテナ化する必要があるならば、VMware TBSがそのニーズにマッチしていると言えるでしょう。

ここからは、VMware TBSを使ってアプリをコンテナ化して実行する例を見ていきましょう。

前提条件

本稿ではTBSの動作例をいち早くご覧いただくため、環境のセットアップやシステムのインストールに関しては省略させて頂きます。既に次の項目が完了しているものとします。

1台のMKEクライアントに加えて、1台のMKEマネージャと2台のMKEワーカーの計3台で構成されたKubernetesクラスタにMSRとTBSをデプロイしてあるものとします。

  • node1, 192.168.56.201 (MKEクライアント, TBSクライアント)
  • node2, 192.168.56.202 (MKEマネージャ)
  • node3, 192.168.56.203 (MKEワーカー, TBS)
  • node4, 192.168.56.204 (MKEワーカー, MSR)

PetClinic サンプルアプリのコンテナ化

Javaフレームワークの1つであるSpringを利用したサンプルアプリ PetClinic を、TBSでコンテナ化してみましょう。クライアントであるnode1 (192.168.56.201)で次のコマンドを実行します。

$ kp image create petclinic \
--tag 192.168.56.204/admin/petclinic \
--git https://github.com/spring-projects/spring-petclinic \
--git-revision main \
--env BP_GRADLE_BUILD_FILE=no-such-file.xml \
--wait

たったこれだけでPetClinicのイメージが作成できました。Dockerfileを書く必要はありません！

オプションを1つ1つ解説していきましょう。

  • kp image create petclinic
    • 「petclinic」という名前のイメージを作成するという意味です。
  • --tag 192.168.56.204/admin/petclinic
    • 作成したイメージの格納先です。ここでは 192.168.56.204 (MSR)の admin ユーザの petclinic レポジトリを指しています。
  • --git https://github.com/spring-projects/spring-petclinic
    • アプリのソースコードを指しています。ご覧の通り、GitHubのレポジトリです。
  • --git-revision main
    • checkoutするソースコードのリビジョンです。ここではmainブランチを指しています。
  • --env BP_GRADLE_BUILD_FILE=no-such-file.xml
    • PetClinicはサンプルアプリなので、ビルドツールとしてMavenとGradleの両方を定義しています。これはGradleを無効化し、結果的にMavenを使うという指定になります。なお、執筆時点の既知の問題に対するワークアラウンドであり、修正されれば不要になるオプションです。
  • --wait
    • イメージ作成が開始されるまで待ち、作成ログを標準出力に書き出します。

作成されたイメージは自動的にMSRにプッシュされます。Kubernetes (MKE)には次のコマンドでデプロイできます。

$ kubectl create deployment petclinic --image=192.168.56.204/admin/petclinic:b1.20220401.061856 --port=8080
deployment.apps/petclinic created
$ kubectl expose deployment petclinic --type=NodePort --name=petclinic --target-port=8080
service/petclinic exposed
$ kubectl get svc petclinic
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
petclinic NodePort 10.96.165.55 8080:33383/TCP 15s

ブラウザでアクセスすると次のようになります。

このようにPetClinicのWebUIが表示されました。

また、PetClinicのソースコードの更新や、OSおよびミドルウェアにあたるJava、Tomcatやベースイメージにパッチが公開されると、自動的に新しいイメージがビルドされてMSRにプッシュされます。コマンドを実行する必要は何もありません。

kp build listコマンドを実行し、REASONがSTACK、BUILDPACKとなっているものが自動的にビルドされたイメージです。

$ kp build list petclinic
BUILD STATUS BUILT IMAGE REASON IMAGE RESOURCE
1 SUCCESS 192.168.56.204/admin/petclinic@sha256:c4b95792ccad54448a174286bd54bfda64572e66a2050bb23921825c3cd879f1 CONFIG petclinic
(中略)
9 SUCCESS 192.168.56.204/admin/petclinic@sha256:e4811df8e776b47655e3b84061dd9c713b616735b0a5e4ae1627a5c66737c3a0 TRIGGER petclinic
10 SUCCESS 192.168.56.204/admin/petclinic@sha256:ad796d6c2a49c52f6e6a9b4589fd3bd0eda59e91f482c7237c9b6e4a050451c4 STACK petclinic
11 SUCCESS 192.168.56.204/admin/petclinic@sha256:42aec5d2066c676e8b98ee8da86cc27439487891a71dfd9bf6d12088ea80c040 COMMIT+ petclinic
12 SUCCESS 192.168.56.204/admin/petclinic@sha256:de5b0c332659d9c38fff234ed448490ffe7168a3cd02b5de65ab64cecded6192 BUILDPACK petclinic

MSRのウェブUIからも、プッシュされていることが確認できます。

Apache Struts 1.2.7 サンプルアプリのコンテナ化

次はApache Struts 1.2.7のサンプルアプリを対象としてみましょう。Apache Struts 1.2.7は、2013年に発表されたDockerよりもさらに古い、2005年にリリースされたソフトウェアです。こんな大変古いソフトウェアをコンテナ化できるのでしょうか？ 試してみましょう。

$ kp image create struts-examples \
--tag 192.168.56.204/admin/struts-examples \
--local-path struts-1.2.7/webapps/struts-examples.war \
--wait

今もアクティブに開発されているPetClinicと同様に、レガシーなStrutsサンプルアプリのイメージがたったこれだけで作成できました。先のPetClinicの例ではソースコードをビルドしてイメージを作成していましたが、 --local-path struts-1.2.7/webapps/struts-examples.war オプションを指定することでコンパイル済みのwarファイルからイメージを作成することもできます。ソースコードをビルドしてイメージを作成するか、コンパイル済みのwarファイルからイメージを作成するかは、ユースケースに応じて使い分けるとよいと思います。

MSRにプッシュされたイメージをKubernetes (MKE)のサービスとして起動してみましょう。

$ kubectl create deployment struts-examples --image=192.168.56.204/admin/struts-examples:b1.20220401.033512 --port=8080
deployment.apps/struts-examples created
$ kubectl expose deployment struts-examples --type=NodePort --name=struts-examples --target-port=8080
service/struts-examples exposed
$ kubectl get svc struts-examples
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
struts-examples NodePort 10.96.255.83 8080:33626/TCP 47s

ブラウザでアクセスすると次のようになります。

Strutsのサンプルアプリが表示されました。

まとめ

本稿では VMware Tanzu Build Service (TBS)を、Mirantis Kubernetes Engine (MKE)と Mirantis Secure Registry (MSR)上に構築し、Springを利用したサンプルアプリPetClinicとApache Struts 1.2.7のサンプルアプリをコンテナ化してみました。Dockerfileを一切書くことなく、ワンコマンドでセキュアなイメージが継続的に自動ビルドされるよう設定できるという大きなメリットをご覧いただけたかと思います。

今回はJavaアプリを対象としましたが、TBSは.NET、Node、Ruby、Go、PHP、Pythonなど、多種多様なアプリに対応しています。レガシーなアプリでもモダンなアプリでも、Dockerfileによるコンテナ化の困難さを感じている方にとって、TBSはその要望を満たすことのできるシステムでしょう。またTBSはMKEとMSRと統合できるため、Mirantisエコシステムの恩恵を受けることもできます。

クリエーションラインでは今後もコンテナ化の第一歩を後押しする技術や手法をご紹介させていただきます。

本ブログについてのお問い合わせ先はこちらまでお願いいたします。

Author

Daisuke Higuchi

    Chef・Docker・Mirantis製品などの技術要素に加えて、会議の進め方・文章の書き方などの業務改善にも取り組んでいます。「Chef活用ガイド」共著のほか、Debian Official Developerもやっています。

    Daisuke Higuchiの記事一覧

    新規CTA