DevOpsツールとWAS Liberty /...

～DevOpsツールとWAS Liberty / PureApplicationの連携～

© 2015 IBM Corporation

セッション番号. セッションタイトル

２．WAS LibertyとJenkins、Maven、Arquillianの連携


アジェンダ

はじめに連携ツールの紹介

• git

• Maven

• Jenkins

• Arquillian

処理全体の流れ

各フェーズにおけるツール連携イメージ開発～ソース管理

ビルド

デプロイ

テスト

2


はじめに

はじめに、今回のWAS Libertyとの連携の対象となるツールの概要をお話します。

次に、今回のシステムの全体像、処理の流れについてご説明し、この流れに沿った具体的な連携例をご紹介します。

各処理の説明にあたって、処理の手順や構成に複数の選択肢が考えられる部分においては、要検討事項として考えられる選択肢、今回の想定を併記する形で記述します。

もちろん、それ以外にも構成や使用するツール、前提とする考え方によってより多くの検討パターンが派生すると考えられますが、参考情報として参照ください。

3


はじめに

4

1. 連携ツールの紹介1. git

2. Maven

3. Jenkins

4. Arquillian

2. 処理全体の流れ


git

5


1. Git – 何ができるのか？

分散型バージョン管理システム Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発

され、それ以降ほかの多くのプロジェクトで採用

gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。

（wikipedia より）

こちらもどうぞ！ Git のコマンドだけでなく、その仕組みを学ぶ

• https://www.ibm.com/developerworks/jp/devops/library/d-learn-workings-git/

6

https://www.ibm.com/developerworks/jp/devops/library/d-learn-workings-git/


2. git – どこで使うか？

7

各環境サーバー

開発環境

本番環境

検証環境

ビルドサーバー

Liberty Profileサーバー構成

アプリ

開発端末ソース管理/

パッケージ管理サーバー

管理サーバー管理端末

ライフサイクル全体管理

デプロイ

デプロイ

デプロイ

開発ソース / パッケージ管理

ビルド / テストデプロイ後のテスト


3. git – Liberty との連携は？

git と Liberty を直接連携するgitのプラグインのようなものは無さそう。

git で Liberty の設定ファイル群を管理する、という関係になります。

また・・・Liberty関連のコードやサンプルなどの殆どはGitHubに置かれています。

https://github.com/wasdev

8

https://github.com/wasdev


4. git - 仕組み/アーキテクチャー

9

作業ディレクトリ（クライアント）

ローカルリポジトリ

ステージングエリア

（Indexと呼ばれる）

1

2

1

2 2

checkout

add commit

はじめに・・・・

git configで初期セットアップします。（ユーザー情報登録など・・・・）

git init でリポジトリ初期化します。

Checkoutして編集します。

addすることでステージングエリアに登録され、コミット可能な状態になります。

Commitで変更が確定されます！

（サーバー側）

共用リポジトリ

Push/Pull（or fetch&merge）で同期します。


Maven

10


1. Maven - 何ができるのか？

プロジェクトのライフサイクル全体を管理するソフトウェア・プロジェクト管理ツール

プロジェクト（アプリケーション）情報の一元管理

依存ライブラリの管理

ビルドプロセスの単純化、自動化

• プロジェクトのコンパイル、ユニットテスト

11


2. Maven - どこで使うか？

12


開発環境

本番環境

検証環境



アプリ





デプロイ

デプロイ

デプロイ



ここで実行ここで設定


3. Maven - Libertyとの連携は？

Liberty Mavenプラグインが提供されている

Libertyサーバーの作成・開始・停止・アプリデプロイ・パッケージングを行うことが可能

Mavenゴールとして以下が提供されている

13

Mavenゴール説明

liberty:install-server Libertyプロファイルのランタイムを導入する

liberty:create-server Libertyサーバーを作成する

liberty:start-server Libertyサーバーを起動する

liberty:stop-server Libertyサーバーを停止する

liberty:package-server Libertyサーバーをパッケージングする

liberty:dump-server サーバーの診断情報をアーカイブに出力する

liberty:java-dump-server サーバーJVMの診断情報を出力する

liberty:deploy アプリケーションをLibertyサーバーのdropinsディレクトリーにデプロイする

liberty:undeploy アプリケーションをLibertyサーバーのdropinsディレクトリーから削除する

liberty:install-feature Esa（Subsystem Archive）形式でパッケージされたfeatureを導入する

liberty:uninstall-feature Libertyプロファイルのランタイムからfeatureを削除する

liberty:install-apps Mavenのdependenciesとして指定された１つ以上のアプリケーションをLibertyサーバーのdropinsディレクトリーにコピーする

https://github.com/WASdev/ci.maven?cm_mc_uid=54428987039714449566809&cm_mc_sid_50200000=1445860688#build

https://github.com/WASdev/ci.maven?cm_mc_uid=54428987039714449566809&cm_mc_sid_50200000=1445860688#build


【参考】 Libertyプロファイル管理用のマルチモジュール・プロジェクト

また、Libertyプロファイル用のマルチモジュールプロジェクト生成のarchetypeとして、liberty-plugin-archetype が提供されています。

このプロジェクトでは、シンプルなwebアプリケーションのビルド

Libertyプロファイルサーバーへのデプロイ

Libertyプロファイルサーバー上でのテスト

を行います。また、そのアプリケーションを含むLibertyプロファイルのサーバーパッケージの作成も

行います。

14


Jenkins

15


1. Jenkins - 何ができるのか？

Jenkinsとは Javaで書かれたオープンソースの継続的インテグレーションツール

• ※ 継続的インテグレーションツール

• アプリケーション作成時の品質改善や納期短縮を目的としてビルドやテストなどを継続的な実行を支援するツール

反復型ジョブを実行する自動化フレームワーク

Hudsonプロジェクトが開発していたもののフォーク

要は、予め定義しておいた作業（ビルドやシェルの実行など）を、分散環境で、ブラウザからの簡単操作で自動実行してくれる、というツールです。

16


2 . Jenkins - どこで使うか？

17


開発環境

本番環境

検証環境



アプリ





デプロイ

デプロイ

デプロイ




3. Jenkins - Libertyの連携は？

以下の通り、アプリケーションのデプロイ用プラグインが提供されています。

18

Plugin Features

•Deployment to a running remote or local instance of WebSphere 6.0.x - 8.5.x

•Deployment to a running remote or local instance of WebSphere Liberty Edition 8.x.x

•Support for deployments when SSL is activated on WebSphere (Global Security)

•Support for most versions of WebSphere (Liberty,ND,Extreme Scale, Express, Standard, etc...)

•Support for deploying to different WebSphere instances/types per build

•Support for node, cell, and server level deployments

•Support for pre-compiling JSPs on WebSphere during deployment (When stress testing as part of build process)

•Support for disabling JSP reloading (When stress testing as part of build process)

•Support for not starting application after deployment

•Supports fully stopping, uninstalling, installing and starting application during deployment process

•Smart detection of existing deployed application state (to prevent failures when a system admin stops your application without you knowing)

https://wiki.jenkins-ci.org/display/JENKINS/WebSphere+Deployer+Plugin


Prod

ST

UT

4. Jenkins -仕組み/アーキテクチャー

19

M

S

S

S

SM

S

S

バージョン管理（SCM）

ビルド（Build）：Master

：Slave

Jenkins.war が動いてます。

ブラウザで管理画面にアクセス。ここで設定等を行います。

ノードは管理画面から簡単に登録できます。

登録すると、SSHでslave.jarが配布されます。


Arquillian

20


1. Arquillian - 何ができるのか？（1/2）

Arquillianとは Javaミドルウェア統合テストを簡素化することを目的にJBossコミュニティーで開発

されているオープンソースのテストツール

2012年4月にJBossコミュニティーが「Arquillian 1.0」をリリース

主にJavaEEで利用することを目的としており様々なコンテナ環境上でのテストをサポート

21


1. Arquillian - 何ができるのか？（2/2）

Arquillianの機能 Arquillianを使用することでJavaEEアプリケーションサーバーのランタイムで動くテ

ストを作成可能

Arquillianがテストに関連したコンテナライフサイクル管理や依存性クラスバンドルなどの機能を提供（開発者はテスト作成そのものにフォーカス）

アプリケーションサーバとの連携方法として下記3つをサポート

• Remote

• 既に起動しているアプリケーションサーバに対してデプロイとテスト実行を実施

• Managed

• Arquillianがアプリケーションサーバを起動してからテストを実行して最後にサーバをシャットダウン

• Embedded

• 組込みコンテナを使用して全てを同じJVMで実行

22


2. Arquillian - Arquillianのアーキテクチャー

Arquillianは下記コンポーネントと連携してテスト環境を提供

単体テストフレームワーク

• ArquillianがテストコントローラーとなってJunit/TestNG等の単体テストフレームワークを利用

ShrinkWrap

• テストの対象となるjar/war/ear等のアーカイブを作成するJavaのAPI

ターゲット・コンテナー

• JavaEEアプリケーションサーバー/Servletコンテナー等のテスト実行環境

• ArquillianのコンテナーとしてLibertyプロファイルをサポート

23

ターゲット・コンテナー

Arquillian

単体テスト・フレームワーク

テストケース

ShrinkWrap


3. Arquillian - Arquillian使用手順 – 前提

運用時には以下のような流れでArquillianを使用

Jenkinsから実行環境(例：開発環境のLibertyサーバー)を指定してテストを行うジョブを実行

↓

実行環境(例：開発環境のLibertyサーバー)上でArquillianを使用してテスト実行

セットアップ作業も含めた全ライフサイクルは以下の様なイメージ1つのマシン上に全てのコンポーネントを導入して

MavenでビルドしたアプリケーションのテストスイートにArquillianを組み込んでテスト実行

①MavenでJavaプロジェクトを作成

②JavaプロジェクトをEclipseにインポート

③ArquillianのAPIを追加

④コンテナとしてLibertyサーバーを追加

⑤アプリケーションを開発

⑥Arquillianテストアプリケーションを開発

⑦テスト実行

⑧テスト実行結果を確認

24

Liberty Profile

サーバー構成Maven

Arquillian

Eclipse

アプリケーション

テストアプリケーション

本番運用でサイクル実行

初回セットアップ

Jenkinsからのジョブ実行


はじめに

25

1. 連携ツールの紹介1. git

2. Maven

3. Jenkins

4. Arquillian

2. 処理全体の流れ


本日お話するシステムの全体像

26

テスト環境



アプリ

ソース管理

管理サーバー

管理 / 開発端末

下記ジョブ実行

A

サーバー構成ファイルのバージョンを指定してビルド

成功したら

B

テスト環境にデプロイ

成功したら

C

ビルドサーバーでテスト実行

バージョン指定してビルド起動

サーバー構成ファイルを取得

Git

Maven

Jenkins Agent

Jenkins Agent

パッケージ指定してテスト環境にデプロイ

ビルドしたパッケージを登録

データの流れ

処理の流れ

ジョブ実行

テスト起動

A-1

A-2 A-4

C

B

Jenkins

Server

Arquillian

テスト

C

B

前

サーバー構成ファイルを登録

A-3ビルド/パッケージ

Jenkins Agent


処理全体の流れ

事前作業

サーバー構成ファイルを登録します。

作成したパッケージをターゲットの環境にコピーし、展開します。

Jenkins gitMaven

/Arquillian実行環境端末

サーバー構成ファイルの登録

前サーバー構成ファイルの登録

デプロイジョブの実行デプロイB

ファイルのコピーファイルのコピー

テストジョブの実行テストジョブの実行

テストテスト

テストC

パッケージの展開

自動化されたテストを実行します。

ビルド対象となるファイル群をビルドサーバーにコピーして、ビルド（Libertyパッケージ作成）を行います。

作成したパッケージも、ソース管理の対象としてリポジトリに登録します。

ビルドAビルドジョブの起動

git pull で同期

ビルド/パッケージ

git pull で同期

git pushで同期git pushで同期

ビルドジョブの実行


各フェーズにおけるツール連携イメージ

28

1. 開発～ソース管理2. ビルド3. デプロイ4. テスト


要検討事項！ー git（SCM）でのLibertyの管理

リポジトリの持ち方リポジトリの範囲

• wlp全体？

• usrの下？

• サーバー単位？

29

リポジトリの範囲はすなわち版管理、共有の範囲となりますので、冪等性、不変を標榜するImmutable Infrastructureの思想からすると・・・・今回はwlp全体をリポジトリ管理の対象とする事としました。

但し、ランタイムであるJDKなどは1ノード内の複数インスタンスの稼動を考えると、リソース・管理効率の観点から、共用対象から除外した方が良いかも知れません。

今回は・・・


要検討事項！ー git（SCM）でのLibertyの管理

リポジトリの持ち方リポジトリの分け方

• 単一のリポジトリでブランチを環境毎にわけるのか？

• リポジトリ自体を環境ごとに分けるのか？

30

今回の構成例ではデプロイ対象がテスト環境1つのみなので実質選択の必要はないのですが、開発・テスト・本番など複数環境管理を行う場合は判断が必要です。

基本的には同一の構成を持ちながら、変更差分の管理を行うことを考えると、１リポジトリ複数ブランチ構成が妥当でしょうか。

もしくは、1ブランチに環境固有ファイルを複数配置して、パッケージ作成時に必要なものを選択するという方式でももちろんOKです。（環境固有部分を別ファイルに書き出して、server.xml でincludeする）

今回は・・・


【参考】本当にLibertyプロファイルを丸ごとソース管理するのか？

上記の例では丸ごとaddする流れで記述していますが、ランタイムごとに動的に生成されるものや、テンポラリで使用するもの、キャッシュファイルなどは、あまりソース管理を行う意味がありません。

そこで・・・

gitには特定ファイルをソース管理から除外する機能があります。

• .gitignore ファイルへの除外ルールの記述

• $GIT_DIR/info/excludeファイルへの除外ルールの記述

• https://git-scm.com/docs/gitignore

この機能を利用して、必要ではないファイルやディレクトリをソース管理対象外とする事を検討してください。

例えば、以下のようなファイルは除外対象になると考えられます。

31

/servers/.classCache//servers/.logs//servers/.pid//servers/<SERVER_NAME>/workarea//servers/<SERVER_NAME>/logs/

注！

https://git-scm.com/docs/gitignore


要検討事項！ー git でのネーミングルール、運用

ブランチ名などのネーミングルール端末、SCMサーバー、Jenkinsからのブランチ指定、などサーバーを跨って同じも

のを扱う必要がありますので、特にgit内で使用するブランチなどのネーミングルールは予め決定し周知しておく必要があります。

例えば・・・

• ブランチ切り替え

• git checkout production

インフラ構成はそれほど頻繁に行うわけではないと思われますが、複数人で同じタイミングで修正を行った場合はmergeなどの対応が必要になります。このあたりの運用ルールも検討しておく必要がありそうです。

32


事前・前提作業

事前作業



Jenkins gitMaven

/Arquillianテスト環境端末






テストテスト

テストC






git pull で同期


git pull で同期


ビルドジョブの実行 1

2

3

4

いまココ！


server.xmlの編集

ここでは、初期セットアップが完了しているものとして、server.xmlの編集後からの操作の流れを紹介します。

34

Server.xmlの編集と、アプリケーションのデプロイを行っています。


server.xml をコミット

Eclipseでの操作は・・・egit（eclipseのgitプラグイン）で！

35

ここをクリックしてcommitと共用リモートリポジトリへのPUSHを行います。

コミットが完了し、履歴に残っています。

コミットの確認

他のクライアントから、commitの内容を確認してみます。

ここでは、ビルドサーバー上のローカルリポジトリで変更が反映されているか確認してみます。

36

[wasadmin@oms94 build]$ git [email protected]'s password:remote: Counting objects: 10, done.remote: Compressing objects: 100% (8/8), done.remote: Total 10 (delta 3), reused 0 (delta 0)Unpacking objects: 100% (10/10), done.From ssh://scm.ise.com/opt/IBM/Liberty/liberty-shared* branch master -> FETCH_HEAD

Updating 77ff68b..d08f488Fast-forwardwlp/usr/servers/templateServer/server.xml | 3 +++wlp/usr/shared/apps/SampleServlet_EAR_v1.0.ear | Bin 0 -> 12288 bytes2 files changed, 3 insertions(+)create mode 100644 wlp/usr/shared/apps/SampleServlet_EAR_v1.0.ear

[wasadmin@oms94 build]$ cat /opt/IBM/Liberty/build/wlp/usr/servers/templateServer/server.xml<?xml version="1.0" encoding="UTF-8"?><server description="new server">

<featureManager>

<feature>webProfile-7.0</feature></featureManager>

<httpEndpoint id="defaultHttpEndpoint"

httpPort="9080"httpsPort="9443" />

<enterpriseApplication location="${shared.app.dir}/SampleServlet_EAR_v1.0.ear" id="Sample"></enterpriseApplication>

git pullコマンドでSCMサーバー上に登録された情報を取得しています。

先ほど編集したserver.xmlとアプリケーションを取得しています！

編集内容が反映されている事を確認できました！


まとめ

ここまででできた事ソース管理サーバー上のgit共用リポジトリの設定、開発端末上のgitローカルリポジトリの設定が完了しました。

開発端末上で設定を行ったLibertyプロファイルサーバー構成（server.xml）をcommitしました。

ビルドサーバー上のgitローカルリポジトリでも、開発端末上で行ったLibertyプロファイルサーバー構成を参照することができました。

次は・・・・次は、Jenkinsからビルドのタスクを呼び出して、Libertyプロファイルサーバーパッ

ケージを作成します。

37


各フェーズにおけるツール連携イメージ

38

1. 開発～ソース管理2. ビルド3. デプロイ4. テスト


前提：liberty-plugin-archetype を使用する

ビルドというとアプリケーションをビルドしてEARファイルやWARファイルの生成をする事をイメージされるかと思いますが、ここではビルド済みのアプリケーションを含むLibertyプロファイルパッケージを生成することをビルドと呼ぶことにします。

ここで使用するMavenでは、Libertyプロファイル用のマルチモジュールプロジェクト生成のarchetypeとして、liberty-plugin-archetype が提供されています。これには、以下の処理が含まれています。

シンプルなwebアプリケーションのビルド

Libertyプロファイルサーバーへのデプロイ

Libertyプロファイルサーバー上でのテスト

ここでは、この liberty-plugin-archetype を使用する前提で説明します。

39


前提：Mavenのリポジトリをgitに格納してシェアする

今回のシステムではgit も使用していますので、Maven のリポジトリもgit リポジトリとして登録を行う事とします。

開発端末のEclipseでMavenの設定などを行い、git共用リポジトリ@SCMサーバーに登録し、buildサーバーでのそのプロジェクトを読み込んでビルドを行う、という分散管理の利点を生かす環境を構築します。

40

ビルドサーバー開発端末ソース管理/


入れる

GUI（Eclipse）で効率的に設定を入れ込みます。

ためる

Git共有リポジトリにmavenの情報も保管します。

使う

Gitの共用リポジトリをcloneすることで、分散環境でも同じイメージを使って作業できます。


要検討事項！ージョブの設定単位

ジョブはどの粒度で設定する？コマンド=ジョブ単位で実行し、処理順序設定で対応する？

機能処理=ジョブ単位で実行し、ジョブステップを細かく区切る？

41

ジョブの実行時に、どの程度の粒度でジョブを分割するか、というのも重要な検討項目です。

あまりに細かい粒度でジョブを分割してしまうと、管理が煩雑になってしまいます。かといってあまりに大きい粒度で設定すると、障害発生時などの対応が不便になります。

おおよその機能処理の塊でジョブを定義し、リトライ等が、し易い単位でジョブを設定しておくのが良さそうです。

今回は・・・


ビルド処理の流れ

事前作業





Jenkins gitMaven





git pull で同期


git pull で同期





テストテスト

テストC



いまココ！


2

3

4


実行すること

ここからは、以下の流れの操作を行うことを想定しています。前ページの作業の流れと合わせてご確認ください。

Jenkinsコンソールから、ビルド作業一式を行うジョブを定義します。

ジョブは、ビルドサーバー上で実行されます。まずは、ビルドサーバー上でgit pullコマンドを実行して、gitの共用リポジトリと同期します。

次に、mavenのLibertyプロファイルプラグインを呼び出し、gitのワークディレクトリ上のLibertyプロファイルディレクトリをパッケージングします。（"ビルド"です。）

生成されたパッケージを、git上にadd、commit、pushして共用リポジトリに反映させます。

前述の処理の流れの各ステップと、Jenkinsのプロジェクトの対応は、以下のようになります。

43

1

2

3

4

ビルドジョブの起動


git pull で同期

git pushで同期

1

2

3

4


使用方法 - まずは、ジョブ（プロジェクト）を定義(1/3)

44

git pull で同期 2

実行ノードの指定をしないと、利用可能な何れかのノードで実行されてしまいます。このジョブはビルドサーバー上で実行したいので、"Build"のラベルがつけられたビルドサーバーを指定しています。

（本来はエラーハンドリング処理なども記述すべきですが・・・）実行するコマンドを記述しています。Libertyプロファイルローカルリポジトリにcdして、git pullして最新化しています。

このプロジェクトの正常終了後に実行するプロジェクトを指定しています。

以下は、ジョブ定義変更箇所の抜粋です。



45

同じく、このジョブはビルドサーバー上で実行させるため、"Build"のラベルがつけられたビルドサーバーを指定しています。

（本来はエラーハンドリング処理なども記述すべきですが・・・）実行するコマンドを記述しています。今回、複数のブランチを利用する想定にはなっていませんが、ここでブランチの選択なども行うとよいでしょう。

ビルドサーバー上のMavenで、Libertyプロファイルサーバーのパッケージを行うゴール、およびpom、引数として渡すプロパティを指定しています。以下のように実行されます。/opt/Maven/apache-maven-3.3.3/bin/mvn -f /opt/IBM/Liberty/maven/pom.xml -DpackageFile=templateServer.jar -DserverHome=/opt/IBM/Liberty/build/wlp/ -DserverName=templateServerliberty:package-server

ビルド/パッケージ 3 以下は、ジョブ定義変更箇所の抜粋です。


アプリケーションのデプロイは？

ここでは、サンプルアプリケーションが組み込まれているMavenのarchetypeを使用していますのでアプリケーションのデプロイ手順が省略されていますが、本来はここで併せて

アプリケーションのビルド

Libertyパッケージへの組み込み

が必要になります。

46

注！



47


またまた同じく、実行ノードの指定をしないと、利用可能な何れかのノードで実行されてしまいます。このジョブはビルドサーバー上で実行したいので、"Build"のラベルがつけられたビルドサーバーを指定しています。

git pushで同期 4

ここで指定したプロジェクトの正常終了後に、このプロジェクトを実行する、という指定をしています。

（本来はエラーハンドリング処理なども記述すべきですが・・・）実行するコマンドを記述しています。生成されたパッケージ（本環境ではmaven側ディレクトリに生成されます）をaddして、commit（コメントにはJenkinsが生成ビルドのタグを埋め込む様に変数の指定）、pushしています。


ジョブを実行します。

実行結果！

48


実行結果！

49

git pull で同期 2

Git pullの実行結果です。

Git pullではなく、git fetch + merge を使うべきという議論もあるようですが、それはまたの機会に・・・

次のジョブ（プロジェクト）を起動しています。


実行結果

50

前のジョブから起動された事がわかります。

Mavenのプロジェクトが実行されています。

次のジョブを起動しています。

ビルド/パッケージ 3

中略


実行結果

51

git pushで同期 4


コミットされました。


アーカイブの形式はzip？jar？

Unixにおいてはserver packageコマンドでアーカイブする際に、jarを指定した場合とzipを指定した場合では、（unzipコマンドの実装に依存して）解凍時のファイルパーミッションに違いが生じます。

zipの場合はパーミッションが保管されませんので注意が必要です！

52

[wasadmin@oms94 jar]$ java -jar templateServer.jar /work/jar/

Extracting files to /work/jar/wlp

Successfully extracted all product files.

[wasadmin@oms94 jar]$ ls -la /work/jar/wlp/bin/server

-rwxrwxr-x. 1 wasadmin wasadmin 30806 Nov 16 14:55 /work/jar/wlp/bin/server

[wasadmin@oms94 zip]$ unzip templateServer.zip

Archive: templateServer.zip

creating: wlp/

：

[wasadmin@oms94 jar]$ ls -la /work/zip/wlp/bin/server

-rw-rw-r--. 1 wasadmin wasadmin 30806 Nov 16 14:46 /work/zip/wlp/bin/server

-rw-rw-r--

-rwxrwxr-x

jar

zip

注！


まとめ

ここまででできた事 Jenkinsにてビルドを行うためのジョブ（プロジェクト）の登録を行いました。

実際にビルドジョブの起動によって、以下を実行しています。

• gitリポジトリ内のLibertyプロファイルサーバー構成を参照し、

• MavenのLibertyプロファイルサーバーパッケージゴールを実行して

• 生成されたパッケージファイルを再びgitリポジトリへ登録！

次は・・・・次は、Jenkinsからデプロイタスクを呼びだして、テスト環境へのLibertyプロファイ

ルサーバーパッケージの配置と展開を行います。

53


3. Libertyプロファイルとツールの連携

54

1. はじめに2. 開発～ソース管理3. ビルド4. デプロイ5. テスト


要検討事項！ーどのようにしてパッケージを配置する？

どのようにしてパッケージを配置する？生成したパッケージをどのようにしてテスト環境へ配置するか決定する必要がありま

す。

例えば以下のような方法が考えられます。

• ソース管理サーバーからファイル転送プロトコル（scp/sftpなど）で配置する

• テスト環境にもgitクライアントを導入してpullする

• さらには、gitリモート/ローカル間の通信に使用するプロトコルも選択可能です。• https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-

%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

これは、主に各社のセキュリティ標準システムの位置づけなどのセキュリティ要件に基づいて決定する事になります。

今回は、作成したパッケージをgitリポジトリから取り出して、テスト環境へscpにてコピーする、という方法をとることにします。

55

https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB


デプロイ作業の流れ

事前作業





Jenkins gitMaven





git pull で同期


git pull で同期





テストテスト

テストC



いまココ！


2

3

4

1

2

3


実行すること


Jenkinsコンソールから、デプロイ作業一式を行うジョブを定義します。

ジョブは、ソース/パッケージ管理サーバー上で実行されます。まずは、ソース/パッケージ管理サーバー上のローカルリポジトリでgit pullコマンドを実行して、gitの共用リポジトリと同期した上で、Libertyプロファイルサーバーパッケージをテスト環境へコピーします。

テスト環境上で、コピーしたLibertyプロファイルサーバーパッケージを展開します。


57

1

2

3

デプロイジョブの実行

ファイルのコピー


1

2

3



58


実行ノードの指定をしないと、利用可能な何れかのノードで実行されてしまいます。このジョブはソース管理サーバー上での処理になるので、"SCM"のラベルがつけられたソース管理サーバーを指定しています。

パッケージLibertyプロファイルサーバーパッケージはMavenのリポジトリ下に生成されますので、そこからテスト環境へパッケージの識別ができるようにビルド番号付でコピーしています。

ここで指定したプロジェクトの正常終了後にこのプロジェクトを実行します。

ファイルのコピー 2



59


お馴染みの実行ノードの指定です。このジョブは稼働サーバー上で実行したいので、"Production"のラベルがつけられた稼動サーバーを指定しています。

ビルド番号付のディレクトリを作成して旧ディレクトリのバックアップを取り、パッケージを回答しています。

パッケージの展開 3

ここで指定したプロジェクトの正常終了後にこのプロジェクトを実行します。


実働環境へのデプロイ後のライセンス管理は大丈夫ですか？

このような場合、開発環境用のライセンスを、実働環境のライセンスに置き換える必要があります。

置き換えるためのライセンスファイル（jar）が提供されています。

導入方法は、以下のとおり、実働環境に移行した後、ライセンスファイルを展開します。

この手順をデプロイの手順に組み込んでください！

現在どのライセンスで稼動しているかは、以下のコマンドで確認できます。

もしくは、起動時のcosole.logに以下のような出力がされます。

60

http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_ins_upgrade_archive.html

C:¥Users¥IBM_ADMIN>java -jar C:¥Work¥wlp-nd-license-8.5.5.jarIBM WebSphere Application Server Network Deployment V8.5.5.6を使用、抽出、またはインストールする前に、プログラムのご使用条件の条項と追加のライセンス情報に同意する必要があります。以下の使用条件をよくお読みください。：以下で「同意する」を選択すると、使用許諾契約の契約条件 (該当する場合は、IBM 以外の契約条件を含む) を受諾することになります。同意しない場合は、「同意しない」を選択してください。

[1] 同意する、または [2] 同意しないを選択: 1

ライセンス・ファイルのディレクトリーを入力するか、ブランクのままにしてデフォルト値を受け入れます。デフォルトのターゲット・ディレクトリー: C:¥Users¥IBM_ADMIN

製品ファイルのターゲット・ディレクトリー? C:¥IBM¥WebSphere¥LibertyArchive8556ライセンス・ファイルが正常に適用されました。

C:¥IBM¥WebSphere¥LibertyArchive8556¥wlp¥bin>C:¥IBM¥WebSphere¥LibertyArchive8556¥wlp¥bin¥productInfo.bat version製品名: WebSphere Application Server製品バージョン: 8.5.5.6製品エディション: BASE_ILAN

ILAN（International License Agreement for Non-Warranted Programs）が付与されていると、保証対象外、すなわち開発用ライセンスと考えられます！

パッケージ展開での実働環境へのデプロイ時には、ライセンス管理に注意！重要

[15/06/25 20:40:01:446 JST] 00000001 com.ibm.ws.kernel.launch.internal.FrameworkManager A CWWKE0100I: この製品は、開発使用向け、および限定的な実動使用向けにライセンスが交付されています。全ライセンス条項は以下で表示可能です: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/8.5.5.5/lafiles/ja.html

http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_ins_upgrade_archive.html



61

以下は、ジョブ定義変更箇所の抜粋です。パッケージの展開 3

前ページの注意点に従って、ライセンスファイルのインストールを行います。

[wasadmin@prod wlp]$ ./bin/productInfo version

Product name: WebSphere Application Server

Product version: 8.5.5.7

Product edition: BASE_ILAN

Before・・・

[wasadmin@prod wlp]$ ./bin/productInfo version

Product name: WebSphere Application Server

Product version: 8.5.5.7

Product edition: ND

After・・・


ジョブを実行します。

実行結果！

62


実行結果！

63

次のジョブ（プロジェクト）を起動しています。

ファイルのコピー 2

ファイルがコピーされました。


実行結果

64


既存のLiberty環境があればバックアップを取得します。

無事展開されました。

パッケージの展開 3


まとめ

ここまででできた事 Jenkinsでデプロイを行うためのジョブ（プロジェクト）の登録を行いました。

実際にデプロイジョブの起動によって、以下を実行しています。

• gitリポジトリ内のLibertyプロファイルサーバーパッケージを稼動サーバーにscpして

• 稼動サーバー上でパッケージを展開しています。

次は・・・・次は、Jenkinsからテストタスクを呼びだして、Libertyプロファイルサーバーの起動

と稼動確認を行います。

65


3. Libertyプロファイルとツールの連携

66

1. はじめに2. 開発～ソース管理3. ビルド4. デプロイ5. テスト


テスト作業の流れ

事前作業





Jenkins gitMaven





git pull で同期


git pull で同期





テストテスト

テストC


自動化されたテストを実行します。いまココ！


2

3

4

1

2

3

1

2


実行すること


Jenkinsコンソールから、Arquillianのテストを起動するジョブを定義します。

ジョブは、Mavenが導入されているビルドサーバーで起動されて、実行環境上のLibertyプロファイルサーバーに対してテストを行います。


68

1

2

テストジョブの実行

テスト

1

2



69


Buildサーバー上で実行しています。

Arquillianはmavenの実体はarchetypeです。Mavenのゴールとしてtestを指定しています。

テスト 2


実行結果イメージ

70

Mavenのテストを起動しています。

テスト 2

正常に終了しました。


まとめ

ここまででできた事 Jenkinsでテストを行うためのジョブ（プロジェクト）の登録を行いました。

あらかじめ定められた、コードとして記述されたテストを Mavenから呼び出すことで、デプロイ後のテストも自動化できました！

ここまでの定義で、基本的には最初のジョブの1クリックでビルド、デプロイ、テストまでが自動で実行できたことになります。

71


全体まとめ

Libertyプロファイル＋OSS DevOpsツール群でインフラ構築の自動化を実践してみました。

72

server.xmlをベースとしたシンプルな構成

パッケージ＆デプロイ機能による簡単デプロイ

ツール提供の豊富なプラグイン、連携機能

で構成を管理し、

でビルド（パッケージング）を行い

で全体の制御、およびデプロイを実施して

で自動テスト

Libertyプロファイルの特性を生かして、

各種 DevOpsツールと連携することで、

「新しいスタイルのシステム構築・運用」が可能です！

DevOpsツールとWAS Liberty /...

Documents

Transcript of DevOpsツールとWAS Liberty /...