2017.09.22

OpenShiftで実現するリリースの自動化

大溝桂
レッドハット株式会社
シニアソリューションアーキテクト
このエントリーをはてなブックマークに追加

アプリケーションのリリース作業は、時間と手間がかかり、人為的なミスが発生することも多々あります。リリース作業の自動化や効率化によって、新しいサービスの企画からリリースまでの期間短縮、また、リリース後の機能追加も迅速に行えるようになります。
継続的インテグレーション(CI)/継続的デリバリー(CD)に利用できるツールとしての一つにJenkinsがあります。今回は、OpenShiftで簡単に利用できるJenkinsのコンテナを利用したCI/CDの実現方法をご紹介します。

まず、本題に入る前にOpenShiftでアプリケーションをビルド・デプロイする仕組みついて簡単にご紹介します。
OpenShiftでは、コンテナイメージの生成とコンテナイメージを指定したデプロイが可能です。コンテナイメージの生成は、以下の3つのビルド方式が提供されています。

  • Source to Image (S2I) Build - アプリケーションのソースコードを指定し、OpenShift上でアプリケーションをビルド、実行環境のコンテナとアプリケーションを併せたコンテナイメージを生成
  • Docker Build - Docker ファイルの定義にしたがって、コンテナイメージを生成
  • Pipeline Build - Jenkins Pipelineの定義にしたがって、ビルド、テスト、コンテナイメージの生成、デプロイなどを実施 

今回ご紹介するPipeline Buildで使われるJenkins Pipelineは、Groovy スクリプトでワークフローを定義します。スクリプトで定義(Pipeline as Code)することで、ワークフローの可視化とバージョン管理が可能となります。
Jenkins Pipelineは、継続的インゲグレーションや継続的デリバリーに活用することができます。

OpenShiftでJenkins Pipelineを使ってCI/CDを実現する場合はOpenShiftのタスクを簡単に定義できるプラグインが組み込まれた、Jenkins Container (Jenkins V2)を利用します。 Jenkins Pipelineを利用すると、ビルド、テストの自動化だけでなく、テスト環境やプロダクション環境へのデプロイまで一定のフローにしたがった実行を定義することができます。また、OpenShiftでJenkinsを実行するメリットは、Jenkinsのパイプラインが起動されるとJenkinsのSlaveサーバが立ち上がりタスクを実行するので、Jenkinsを利用したビルドが同時に実行されてもパフォーマンスの劣化がありません。

Pipeline Build では、OpenShift からパイプラインを実行するJenkinsコンテナを起動し、起動されたJenkinsコンテナは、Jenkinsfileで定義されたパイプラインにしがたってタスクを実行します。例えば [図1 PipelineBuild] の流れは以下のようになります。

  1. OpenShiftがJenkinsfileにしたがってパイプラインを実行するJenkinsコンテナを起動
  2. Jenkinsがソースコードリポジトリからソースコードを取得し、アプリケーションのアーカイブを作成
  3. JenkinsからOpenShiftの機能を利用してコンテナイメージを生成し、内部のレジストリへ登録、デプロイ
  4. 生成されたイメージを利用してアプリケーションをデプロイ

パイプラインに単体テストの実行を定義しておけば、コンテナイメージの生成前に、単体テストを実行することも可能です。


170925_redhat_01.JPG
図1 PipelineBuildの流れ

例えば、[図2 CI/CDフロー]は、テストの実行やアーティファクトリポジトリへのビルド済みのアプリケーションアーカイブの登録、さらには、ステージング環境へのデプロイ承認とデプロイを行うパイプラインの例を表しています。
OpenShiftでは、プロジェクトという単位でアプリケーションとそれに関連するコンポーネントやリソースを管理しています。この例では、DEVプロジェクト用にビルドしたアプリケーションに対して、単体テスト、静的解析を実行し、それらの検証が正常終了したらアーティファクトリポジトリへ成果物を登録します。次に、ビルドの成果物を実行環境と併せた新たなコンテナイメージを生成し、DEVプロジェクトにデプロイし、インテグレーションテストを実行します。最後に、STAGE プロジェクトへインテグレーションテストが完了したコンテナイメージをデプロイするか否かを判断し、OKならばSTAGE環境へデプロイします。
このような常に一定のパイプラインにしたがったプロセスを経てステージング環境持っていくことができるので、ソースコード間の不整合も早い段階で発見することができ、いつでもリリース可能な状態を保つことができるようになります。


170925_redhat_02.JPG

図2 CI/CDフロー

パイプラインの定義にしたがって、常に同じプロセスを経てリリースまで進めること、さらにそのプロセスを可能な限り自動化することで、時間と手間のかかるリリース作業が効率的に行えるようになります。OpenShiftではこれらを簡単に実現できる仕組みを提供していますので、ぜひ、試してみてください。
OpenShiftの CI/CDのサンプルテンプレートは、
https://github.com/akubicharm/openshift-cd-demoで公開しています。

この記事の著者:大溝桂

レッドハット株式会社
シニアソリューションアーキテクト

外資系ベンダーにてC言語/Java言語を利用した基幹業務システムの開発や運用支援などを経験後、2012年にレッドハット株式会社に入社。
パートナを担当するプリセールスエンジニアとして、JBoss Middlewareの拡販とパートナ企業の技術者育成に従事していたが、
OpenShiftに魅了され、現在は OpenShift / PaaS / DevOpsを促進している。


DevOps Hubのアカウントをフォローして
更新情報を受け取る

  • Like on Feedly
    follow us in feedly

関連記事

このエントリーをはてなブックマークに追加

お問い合わせ

DevOpsに関することなら
お気軽にご相談ください。

Facebook、TwitterでDevOpsに関する
情報配信を行っています。