こんにちは。どらおです。

 

今回の記事はとある案件で、Linux上に構成されたJenkinsからWindows Server環境にデプロイを自動で行うのに悩んだ(でる)話です。

はじめに

巷では、CodeStarなどのクラウド系CIや、Jenkins以外のCIツールの発展などCIツールが目まぐるしく発達しています。

エンジニアとしては、最新のツールをプロジェクトで使ってみたいと思うのですが、SIerの仕事では最新のCIツールを導入することが正解とは限らない場合(導入できない場合)があります。

既存システム構成、既存プロセス、既存リポジトリ、既存CI環境などが構築されており、そういった制約の中でいかに継続的インテグレーションを効率よく回していくのかを考えなくてはいけません。

私は、すでに走り出している案件にアサインされ、ある程度環境が構築されている状態でリリースの自動化タスクを与えられました。こちらの記事はその際に悩んだ話になります。

Linux:JenkinsからのWindows Serverへのデプロイ

既存で以下のシステムが構成されていました。

  1. JenkinsはAmazon Linux上で既に動作している(ビルドジョブは登録されていない)
  2. デプロイ先はWindows Server。ApacheとTomcatが既に構築されており、Javaアプリケーションをデプロイしたい(現状は手動で転送している)
  3. JavaのビルドはMaven
  4. リポジトリはGit(GitBucket)を利用
  5. 厳格にビルドバージョン、リリースタイミングを管理したい

 
サーバは複数台あり、手動でビルド&デプロイが大変なため、自動化したいということでした。
私はJenkins自体あまり触ったことがなかったので、試行錯誤しながら環境構成を検討しました。

まず一つ目に考えた案

Windows ServerをJenkins Slaveとして扱う方法です。
デプロイ先のWindows ServerにJenkins Slaveを導入して、Windows Server上でビルドし、バッチコマンドを使って、デプロイできれば良いと考えました。
Windowsのバッチコマンドが使えるので柔軟な対応ができ、よい方法だと思いましたが以下の要求が発生したため、却下となりました。

・Windows Serverには追加のソフトを導入したくない

二つ目に考えた案

ビルドしたファイルを共有フォルダに格納する方法です。
Linuxサーバ(Jenkins)にSambaをインストールします。
Linuxサーバ(Jenkins)でビルドのみ実施し、Sambaで構築したLinux – Windows Serverの共有ドライブにビルドファイルを保存します。
Windows Serverにアクセスして、デプロイを行います(リリースシェルを準備)

この方法だと、ビルドファイル作成後にWindows Serverにログインしてリリースシェルを叩く作業が必要になりシームレスにデプロイ&リリースが行えないことが難点です。
しばらく、使ってみたのですがプロジェクトの局面によっては日に何度もビルドが発生する&デプロイサーバが複数あるのでやや手間になってきました。
今はこちらの案で運用しています、が、近々三つ目の案を試してみたいと思います。

そして、三つ目に考えた案

mavenのtomcat-pluginを利用する方法です。
tomcat-pluginはtomcat7-maven-plugin、tomcat8-maven-pluginとtomcatバージョンごとにプラグインが分かれています。
が、tomcat7-maven-pluginでもtomcat8にデプロイ可能なようです。
tomcat7-maven-pluginは知っていたのですが、tomcat7にしか対応していないのかと思い、検討から除外していました。
まだ未導入ですので、躓いたらまたブログにアップしたいと思います。
※リリースの際、apacheを再起動したいところですが、こちらの方法では解決できないのが新たな悩みです。。
※Jenkins Deploy Pluginも検討中。

最後に

まだまだ、Jenkins が使いこなせておらず、苦悩の日々が続いております。
Gitブランチの運用なども含めやることはたくさんあるのですがこの辺もクリアして自動化を進めていきたいと思います。

この記事の内容がベストな対応ではないと思いますが、同じようなことで悩んでいる人の一助になればと思います。