Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第7章 チュートリアル

7.1. 概要

以下のトピックでは、OpenShift Container Platform でアプリケーションを稼働させる方法や、さまざまな言語とフレームワークについて説明します。

7.2. クイックスタートのテンプレート

7.2.1. 概要

クイックスタートは、OpenShift Container Platform で実行するアプリケーションの基本例です。クイックスタートはさまざまな言語やフレームワークが含まれており、サービスのセット、ビルド設定およびデプロイメント設定などで構成される「テンプレート」で定義されています。このテンプレートは、必要なイメージやソースリポジトリーを参照して、アプリケーションをビルドし、デプロイします。

クイックスタートを試してみるには、テンプレートからアプリケーションを作成します。管理者がすでにこれらのテンプレートを OpenShift Container Platform クラスターにインストールしている可能性がありますが、その場合には、Web コンソールからこれを簡単に選択できます。テンプレートのアップロード、作成、変更に関する情報は、「テンプレート」のドキュメントを参照してください。

クイックスタートは、アプリケーションのソースコードを含むソースリポジトリーを参照します。クイックスタートをカスタマイズするには、リポジトリーをフォークし、テンプレートからアプリケーションを作成する時に、デフォルトのソースリポジトリー名をフォークしたリポジトリーに置き換えます。これにより、提供されたサンプルのソースではなく、独自のソースコードを使用してビルドが実行されます。ソースリポジトリーでコードを更新し、新しいビルドを起動して、デプロイされたアプリケーションで変更が反映されていることを確認できます。

7.2.2. Web フレームワーククイックスタートのテンプレート

以下のクイックスタートでは、指定のフレームワークおよび言語の基本アプリケーションを提供します。

7.3. Ruby on Rails

7.3.1. 概要

Ruby on Rails は Ruby で記述された一般的な Web フレームワークです。本ガイドでは、OpenShift Container Platform での Rails 4 の使用について説明します。

警告

チュートリアル全体をチェックして、OpenShift Container Platform でアプリケーションを実行するために必要なすべての手順を概観することを強く推奨します。問題に直面した場合には、チュートリアル全体を振り返り、もう一度問題に対応してください。またチュートリアルは、実行済みの手順を確認し、すべての手順が適切に実行されていることを確認するのに役立ちます。

本ガイドでは、以下があることを前提としています。

  • Ruby/Rails の基本知識
  • Ruby 2.0.0+、Rubygems、Bundler のローカルにインストールされたバージョン
  • Git の基本知識
  • OpenShift Container Platform v3 の実行インスタンス

7.3.2. ローカルのワークステーション設定

まず、OpenShift Container Platform のインスタンスが実行されており、利用できることを確認します。OpenShift Container Platform を稼働させる方法については、「インストール方法」を確認してください。また、oc CLI クライアントのインストール」が実行されており、コマンドがお使いのコマンドシェルから利用できることを確認し、CLI クライアントからメールとパスワードを使用して、「ログイン」できるようにします。

7.3.2.1. データベースの設定

Rails アプリケーションはほぼ常にデータベースと併用されます。ローカル開発の場合は、PostgreSQL データベースを選択してください。PostgreSQL データベースをインストール方法するには、以下を入力します。

$ sudo yum install -y postgresql postgresql-server postgresql-devel

次に、以下のコマンドでデータベースを初期化する必要があります。

$ sudo postgresql-setup initdb

このコマンドで /var/lib/pgsql/data ディレクトリーが作成され、このディレクトリーにデータが保存されます。

以下を入力してデータベースを起動します。

$ sudo systemctl start postgresql.service

データベースが実行されたら、rails ユーザーを作成します。

$ sudo -u postgres createuser -s rails

作成をしたユーザーのパスワードは作成されていない点に留意してください。

7.3.3. アプリケーションの作成

Rails アプリケーションをゼロからビルドするには、Rails gem を先にインストールする必要があります。

$ gem install rails
Successfully installed rails-4.2.0
1 gem installed

Rails gem のインストール後に、PostgreSQL をデータベースとして 指定して新規アプリケーションを作成します。

$ rails new rails-app --database=postgresql

次に、新規ディレクトリーに移動します。

$ cd rails-app

アプリケーションがすでにある場合には pg (postgresql) gem が Gemfile に配置されているはずです。配置されていない場合には、Gemfile を編集して gem を追加します。

gem 'pg'

すべての依存関係を含む Gemfile.lock を新たに生成するには、以下を実行します。

$ bundle install

pg gem で postgresql データベースを使用することのほかに、config/database.ymlpostgresql アダプターを使用していることを確認する必要があります。

config/database.yml ファイルの default セクションを以下のように更新するようにしてください。

default: &default
  adapter: postgresql
  encoding: unicode
  pool: 5
  host: localhost
  username: rails
  password:

アプリケーションの開発およびテストデータベースを作成するには、以下の rake コマンドを使用します。

$ rake db:create

これで PostgreSQL サーバーに development および test データベースが作成されます。

7.3.3.1. Welcome ページの作成

Rails 4 では、静的な public/index.html ページが実稼働環境で提供されなくなったので、新たに root ページを作成する必要があります。

welcome ページをカスタマイズするには、以下の手順を実行する必要があります。

  • index アクションで コントローラー を作成します。
  • welcome コントローラー index アクションの ビュー ページを作成します。
  • 作成した コントローラービュー と共にアプリケーションの root ページを提供する ルート を作成します。

Rails には、これらの必要な手順をすべて実行するジェネレーターがあります。

$ rails generate controller welcome index

必要なファイルはすべて作成されたので、config/routes.rb ファイルの 2 行目を以下のように編集することのみが必要になります。

root 'welcome#index'

rails server を実行して、ページが利用できることを確認します。

$ rails server

ブラウザーで http://localhost:3000 に移動してページを表示してください。このページが表示されない場合は、サーバーに出力されるログを確認してデバッグを行ってください。

7.3.3.2. OpenShift Container Platform のアプリケーションの設定

アプリケーションと OpenShift Container Platform で実行されている PostgreSQL データベースサービスとを通信させるには、「環境変数」を使用するように config/database.ymldefault セクションを編集する必要があります。環境変数は、後でデータベースサービスを作成する時に定義します。

編集した config/database.ymldefault セクションに事前定義済みの変数を入力すると、以下のようになります。

<% user = ENV.key?("POSTGRESQL_ADMIN_PASSWORD") ? "root" : ENV["POSTGRESQL_USER"] %>
<% password = ENV.key?("POSTGRESQL_ADMIN_PASSWORD") ? ENV["POSTGRESQL_ADMIN_PASSWORD"] : ENV["POSTGRESQL_PASSWORD"] %>
<% db_service = ENV.fetch("DATABASE_SERVICE_NAME","").upcase %>

default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV["POSTGRESQL_MAX_CONNECTIONS"] || 5 %>
  username: <%= user %>
  password: <%= password %>
  host: <%= ENV["#{db_service}_SERVICE_HOST"] %>
  port: <%= ENV["#{db_service}_SERVICE_PORT"] %>
  database: <%= ENV["POSTGRESQL_DATABASE"] %>

最終的なファイルの内容のサンプルについては、「Ruby on Rails アプリケーションの例 config/database.yml」を参照してください。

7.3.3.3. git へのアプリケーションの保存

OpenShift Container Platform には git が必要なので、まだインストールされていない場合はインストールする必要があります。

OpenShift Container Platform でアプリケーションをビルドするには通常、ソースコードを git リポジトリーに保存する必要があるため、git がない場合にはインストールしてください。

ls -1 コマンドを実行して、Rails アプリケーションのディレクトリーで操作を行っていることを確認します。コマンドの出力は以下のようになります。

$ ls -1
app
bin
config
config.ru
db
Gemfile
Gemfile.lock
lib
log
public
Rakefile
README.rdoc
test
tmp
vendor

Rails app ディレクトリーでこれらのコマンドを実行して、コードを初期化して、git にコミットします。

$ git init
$ git add .
$ git commit -m "initial commit"

アプリケーションをコミットしたら、リモートのリポジトリーにプッシュする必要があります。これには、GitHub アカウント が必要です。このアカウントで 新しいリポジトリーを作成します

お使いの git リポジトリーを参照するリモートを設定します。

$ git remote add origin git@github.com:<namespace/repository-name>.git

次に、アプリケーションをリモートの git リポジトリーにプッシュします。

$ git push

7.3.4. OpenShift Container Platform へのアプリケーションのデプロイ

Ruby on Rails アプリケーションをデプロイするには、アプリケーション用に新規の プロジェクト を作成します。

$ oc new-project rails-app --description="My Rails application" --display-name="Rails Application"

rails-app プロジェクト」を作成すると、自動的に新しいプロジェクトの namespace に切り替えられます。

OpenShift Container Platform へのアプリケーションのデプロイでは 3 つの手順を実行します。

7.3.4.1. データベースサービスの作成

Rails アプリケーションには、稼働中のデータベース「サービス」が必要です。このサービスには PostgeSQL データベース 「イメージ」を使用してください。

データベース「サービス」を作成するには、oc new-app コマンドを使用します。このコマンドでは必要な「環境変数」を指定する必要があります。この環境変数は、データベースコンテナー内で使用します。このような「環境変数」では、ユーザー名、パスワード、データベース名を設定する必要があります。これらの 「環境変数」は任意の値に変更することが可能です。今回設定する変数は以下のとおりです。

  • POSTGRESQL_DATABASE
  • POSTGRESQL_USER
  • POSTGRESQL_PASSWORD

これらの変数を設定すると、以下を確認できます。

  • 指定の名前でデータベースが存在する
  • 指定の名前でユーザーが存在する
  • ユーザーは指定のパスワードで指定のデータベースにアクセスできる

以下に例を示します。

$ oc new-app postgresql -e POSTGRESQL_DATABASE=db_name -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password

データベースの管理者のパスワードも設定するには、直前のコマンドに以下を追加します。

-e POSTGRESQL_ADMIN_PASSWORD=admin_pw

このコマンドの進捗を確認するには、以下を実行します。

$ oc get pods --watch

7.3.4.2. フロントエンドサービスの作成

アプリケーションを OpenShift Container Platform にデプロイするには、「oc new-app」コマンドをもう一度使用して、アプリケーションを配置するリポジトリーを指定する必要があります。このコマンドでは、「データベースサービスの作成」で設定したデータベース関連の「環境変数」を指定してください。

$ oc new-app path/to/source/code --name=rails-app -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password -e POSTGRESQL_DATABASE=db_name -e DATABASE_SERVICE_NAME=postgresql

このコマンドでは、OpenShift Container Platform は、ソースコードの取得、ビルダーイメージの設定、アプリケーションイメージの「ビルド」、新規作成したイメージと指定の「環境変数」のデプロイを行います。このアプリケーションは rails-app という名前に指定します。

rails-app「DeploymentConfig」の JSON ドキュメントを参照して、環境変数が追加されたかどうかを確認できます。

$ oc get dc rails-app -o json

以下のセクションが表示されるはずです。

env": [
    {
        "name": "POSTGRESQL_USER",
        "value": "username"
    },
    {
        "name": "POSTGRESQL_PASSWORD",
        "value": "password"
    },
    {
        "name": "POSTGRESQL_DATABASE",
        "value": "db_name"
    },
    {
        "name": "DATABASE_SERVICE_NAME",
        "value": "postgresql"
    }

],

ビルドプロセスを確認するには、以下を実行します。

$ oc logs -f build rails-app-1

ビルドが完了すると、OpenShift Container Platform で Pod が実行されていることを確認できます。

$ oc get pods

myapp-<number>-<hash> で始まる行が表示されますが、これは OpenShift Container Platform で実行中のアプリケーションです。

データベースの移行スクリプトを実行してデータベースを初期化してからでないと、アプリケーションは機能しません。これを実行する 2 種類の方法があります。

  • 実行中のフロントエンドコンテナーから手動で行う

最初に「rsh」コマンドでフロントエンドコンテナーに対して実行します。

$ oc rsh <FRONTEND_POD_ID>

コンテナー内から移行を実行します。

$ RAILS_ENV=production bundle exec rake db:migrate

development または test 環境で Rails アプリケーションを実行する場合には、RAILS_ENV の環境変数を指定する必要はありません。

7.3.4.3. アプリケーションのルートの作成

www.example.com などの外部からアクセスできるホスト名を指定してサービスを公開するには、OpenShift Container Platform のルートを使用します。この場合は、以下を入力してフロントエンドサービスを公開する必要があります。

$ oc expose service rails-app --hostname=www.example.com
警告

ユーザーは指定したホスト名がルーターの IP アドレスに解決することを確認する必要があります。詳しい情報は、以下に関する OpenShift Container Platform ドキュメントを参照してください。

7.4. Maven 用の Nexus ミラーリングの設定

7.4.1. はじめに

Java および Maven でアプリケーションを開発すると、ビルドを複数回実行する可能性が非常に高くなります。Pod のビルド時間を短縮するために、Maven の依存関係をローカルの Nexus リポジトリーにキャッシュすることができます。このチュートリアルでは、クラスター上に Nexus リポジトリーを作成する方法を説明します。

このチュートリアルでは、ご利用のプロジェクトが Maven で使用できるように設定されていることを前提としています。Java プロジェクトで Maven を使用する場合は、Maven のガイド を参照することを強く推奨します。

また、アプリケーションのイメージに Maven ミラーリング機能があるか確認するようにしてください。Maven を使用するイメージの多くに MAVEN_MIRROR_URL 環境変数が含まれており、このプロセスを単純化するために使用できます。この機能が含まれていない場合には、Nexus ドキュメント を参照して、ビルドが正しく設定されていることを確認してください。

さらに、各 Pod が機能するように十分なリソースを割り当てるようにしてください。追加のリソースを要求するには、Nexus デプロイメント設定で「Pod テンプレートを編集」する必要がある場合があります。

7.4.2. Nexus の設定

  1. 正式な Nexus コンテナーイメージをダウンロードし、デプロイします。

    oc new-app sonatype/nexus
  2. 新規作成した Nexus サービスを公開して、ルートを作成します。

    oc expose svc/nexus
  3. oc get routes を使用して、Pod の新規外部アドレスを検索します。

    oc get routes

    出力は以下のようになります。

    NAME      HOST/PORT                              PATH      SERVICES   PORT       TERMINATION
    nexus     nexus-myproject.192.168.1.173.xip.io             nexus      8081-tcp
  4. ブラウザーで HOST/PORT の対象の URL に移動して、Nexus が実行されていることを確認します。Nexus にサインインするには、デフォルトの管理者ユーザー名 admin、パスワード admin123 を使用します。
注記

Nexus は中央リポジトリー用に事前に設定されていますが、アプリケーション用に他のリポジトリーが必要な場合があります。Red Hat イメージの多くは、Maven リポジトリーjboss-ga リポジトリーを追加 することを推奨します。

7.4.2.1. プローブを使用した正常な実行の確認

ここで readiness プローブと liveness プローブ を設定することができます。これらのプローブは、Nexus が正しく実行されていることを定期的に確認します。

$ oc set probe dc/nexus \
	--liveness \
	--failure-threshold 3 \
	--initial-delay-seconds 30 \
	-- echo ok
$ oc set probe dc/nexus \
	--readiness \
	--failure-threshold 3 \
	--initial-delay-seconds 30 \
	--get-url=http://:8081/nexus/content/groups/public

7.4.2.2. Nexus への永続性の追加

注記

永続ストレージを必要としない場合には、Nexus への接続 に進みます。ただし、Pod が何らかの理由で再起動された場合には、キャッシュされた依存関係および設定のカスタマイズはなくなります。

Nexus の Persistent Volume Claim (永続ボリューム要求、PVC) を作成し、サーバーを実行中の pod を中断すると、キャッシュされた依存関係が失われないようにします。PVC にはクラスター内で利用可能な永続ボリューム (PV) が必要です。利用可能な PV がない場合や、クラスターに管理者としてのアクセス権限がない場合には、システム管理者に、読み取り/書き込み可能な永続ボリュームを作成するように依頼してください。

永続ボリュームの作成手順については、「OpenShift Container Platform での永続ストレージ」を参照してください。

Nexus デプロイメント設定に PVC を追加します。

$ oc volumes dc/nexus --add \
	--name 'nexus-volume-1' \
	--type 'pvc' \
	--mount-path '/sonatype-work/' \
	--claim-name 'nexus-pv' \
	--claim-size '1G' \
	--overwrite

これで、デプロイメント設定の以前の emptyDir ボリュームが削除され、1 GB 永続ストレージを /sonatype-work (依存関係の保存先) にマウントする要求を追加します。この設定の変更により、Nexus Pod は自動的に再デプロイされます。

Nexus が実行していることを確認するには、ブラウザーで Nexus ページを更新します。以下を使用して、デプロイメントの進捗をモニタリングすることができます。

$ oc get pods -w

7.4.3. Nexus への接続

次の手順では、新しい Nexus リポジトリーを使用するビルドを定義する方法を説明します。残りのチュートリアルでは、このリポジトリーサンプル と、ビルダーとして wildfly-100-centos7を使用しますが、これらの変更はどのプロジェクトでも機能します。

ビルダーイメージサンプル では、環境の一部として MAVEN_MIRROR_URL をサポートするため、これを使用して、ビルダーイメージを Nexus リポジトリーにポイントすることができます。イメージが環境変数を使用した Mavin のミラーリングをサポートしていない場合には、Nexus ミラーリングを参照する正しい Maven 設定を指定するようにビルダーイメージを変更する必要がある場合があります。

$ oc new-build openshift/wildfly-100-centos7:latest~https://github.com/openshift/jee-ex.git \
	-e MAVEN_MIRROR_URL='http://nexus.<Nexus_Project>:8081/nexus/content/groups/public'
$ oc logs build/jee-ex-1 --follow

<Nexus_Project> は Nexus リポジトリーのプロジェクト名に置き換えます。これが使用するアプリケーションと同じプロジェクトに含まれる場合には、<Nexus_Project>. を削除できます。「OpenShift Container Platform の DNS 解決について参照してください」

7.4.4. 正常な実行の確認

web ブラウザーで、http://<NexusIP>:8081/nexus/content/groups/public に移動して、アプリケーションの依存関係を保存したことを確認します。また、ビルドログを確認して Maven が Nexus ミラーリングを使用しているかどうかをチェックできます。正常にミラーリングされている場合には、URL http://nexus:8081 を参照する出力が表示されるはずです。

7.4.5. その他のリソース

7.5. OpenShift Pipeline ビルド

7.5.1. はじめに

シンプルな web サイトを作成する場合も、複雑なマイクロサービス web を作成する場合も、OpenShift Pipeline を使用して、OpenShift でアプリケーションをビルド、テスト、デプロイ、プロモートを実行します。

標準の Jenkins Pipeline 構文のほかにも、OpenShift Jenkins イメージは (OpenShift Jenkins Client プラグインを使用して) OpenShift の Domain Specific Language (DSL) を提供します。これは、OpenShift API サーバーと高度な対話を行う、読み取り可能でコンパクトで総合的な、かつ Fluent (流れるような) 構文を提供することを目的とし、OpenShift クラスターのアプリケーションのビルド、デプロイメント、プロモートのより詳細な制御が可能になります。

以下の例では、nodejs-mongodb.json テンプレートを使用して Node.js/MongoDB アプリケーションをビルドし、デプロイし、検証する OpenShift Pipeline を作成する方法を紹介します。

7.5.2. Jenkins Master の作成

Jenkins master を作成するには以下を実行します。

  $ oc project <project_name> 1
  $ oc new-app jenkins-ephemeral 2
1
oc new-project <project_name> で新規プロジェクトを使用するか、または作成するプロジェクトを選択します。
2
永続ストレージを使用する場合は、jenkins-persistent を代わりに使用します。
注記

Jenkins の自動プロビジョニングがクラスターで有効化されており、Jenkins master をカスタマイズする必要がない場合には、以前の手順を省略できます。

Jenkins の自動プロビジョニングに関する情報は、「Pipeline の実行設定」を参照してください。

7.5.3. Pipeline のビルド設定

Jenkins master が機能するようになったので、Jenkins Pipeline ストラテジーを使用して Node.js/MongoDB のサンプルアプリケーションをビルドし、デプロイし、スケーリングする BuildConfig を作成します。

以下の内容で nodejs-sample-pipeline.yaml という名前のファイルを作成します。

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "nodejs-sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: <pipeline content from below>
    type: JenkinsPipeline

Pipeline ビルドストラテジーに関する情報は、「Pipeline ストラテジーオプション」を参照してください。

7.5.4. Jenkinsfile

jenkinsPipelineStrategy で BuildConfig を作成したら、インラインの jenkinsfile を使用して、パイプラインに指示を出します。以下の例では、アプリケーションの git リポジトリーは設定していません。

以下の jenkinsfile の内容は、OpenShift DSL を使用して Groovy で記述されています。ソースリポジトリーに jenkinsfile を追加することが推奨される方法ですが、この例では YAML Literal Style を使用して BuildConfig にインラインコンテンツを追加しています。

完了した BuildConfig は、OpenShift Origin リポジトリーの examples ディレクトリーの nodejs-sample-pipeline.yaml で確認できます。

def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1
def templateName = 'nodejs-mongodb-example' 2
pipeline {
  agent {
    node {
      label 'nodejs' 3
    }
  }
  options {
    timeout(time: 20, unit: 'MINUTES') 4
  }
  stages {
    stage('preamble') {
        steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                        echo "Using project: ${openshift.project()}"
                    }
                }
            }
        }
    }
    stage('cleanup') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.selector("all", [ template : templateName ]).delete() 5
                  if (openshift.selector("secrets", templateName).exists()) { 6
                    openshift.selector("secrets", templateName).delete()
                  }
                }
            }
        }
      }
    }
    stage('create') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.newApp(templatePath) 7
                }
            }
        }
      }
    }
    stage('build') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def builds = openshift.selector("bc", templateName).related('builds')
                  timeout(5) { 8
                    builds.untilEach(1) {
                      return (it.object().status.phase == "Complete")
                    }
                  }
                }
            }
        }
      }
    }
    stage('deploy') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def rm = openshift.selector("dc", templateName).rollout()
                  timeout(5) { 9
                    openshift.selector("dc", templateName).related('pods').untilEach(1) {
                      return (it.object().status.phase == "Running")
                    }
                  }
                }
            }
        }
      }
    }
    stage('tag') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10
                }
            }
        }
      }
    }
  }
}
1
使用するテンプレートへのパス
2
作成するテンプレート名
3
このビルドを実行する node.js のスレーブ Pod をスピンアップします。
4
このパイプラインに 20 分間のタイムアウトを設定します。
5
このテンプレートラベルが指定されたものすべてを削除します。
6
このテンプレートラベルが付いたシークレットをすべて削除します。
7
templatePath から新規アプリケーションを作成します。
8
ビルドが完了するまで最大 5 分待機します。
9
デプロイメントが完了するまで最大 5 分待機します。
10
すべてが正常に完了した場合は、$ {templateName}:latest イメージに $ {templateName}-staging:latest のタグを付けます。ステージング環境向けのパイプラインの BuildConfig は、変更する $ {templateName}-staging:latest イメージがないかを確認し、このイメージをステージング環境にデプロイします。
注記

以前の例は、declarative pipeline スタイルを使用して記述されていますが、以前の scripted pipeline スタイルもサポートされます。

7.5.5. パイプラインの作成

OpenShift の BuildConfig を作成するには、以下を実行します。

$ oc create -f nodejs-sample-pipeline.yaml

独自のファイルを作成しない場合には、以下を実行して Origin リポジトリーからサンプルを使用できます。

$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

使用する OpenShift DSL 構文の情報は、「OpenShift Jenkins クライアントプラグイン」を参照してください。

7.5.6. パイプラインの起動

以下のコマンドでパイプラインを起動します。

$ oc start-build nodejs-sample-pipeline
注記

または、OpenShift Web コンソールで Builds → Pipeline セクションに移動して、Start Pipeline をクリックするか、Jenkins コンソールから作成したパイプラインに移動して、Build Now をクリックしてパイプラインを起動できます。

パイプラインが起動したら、以下のアクションがプロジェクト内で実行されるはずです。

  • ジョブインスタンスが Jenkins サーバー上で作成される
  • パイプラインで必要な場合には、スレーブ Pod が起動される
  • パイプラインがスレーブ Pod で実行されるか、またはスレーブが必要でない場合には master で実行される

    • template=nodejs-mongodb-example ラベルの付いた以前に作成されたリソースは削除されます。
    • 新規アプリケーションおよびそれに関連するすべてのリソースは、nodejs-mongodb-example テンプレートで作成されます。
    • ビルドは nodejs-mongodb-example BuildConfig を使用して起動されます。

      • パイプラインは、ビルドが完了して次のステージをトリガーするまで待機します。
    • デプロイメントは、nodejs-mongodb-example のデプロイメント設定を使用して開始されます。

      • パイプラインは、デプロイメントが完了して次のステージをトリガーするまで待機します。
    • ビルドとデプロイに成功すると、nodejs-mongodb-example:latest イメージが nodejs-mongodb-example:stage としてトリガーされます。
  • パイプラインで以前に要求されていた場合には、スレーブ Pod が削除される
注記

OpenShift Web コンソールで確認すると、最適な方法でパイプラインの実行を視覚的に把握することができます。Web コンソールにログインして、Builds → Pipelines に移動して、パイプラインを確認します。

7.5.7. OpenShift Pipeline の詳細オプション

OpenShift Pipeline では、Jenkins を 1 つのプロジェクトで起動してから、OpenShift 同期プラグインに開発者が作業をするプロジェクトグループをモニタリングさせることができます。以下のセクションでは、このプロセスを完了する手順を説明します。

  • Jenkins の自動プロビジョニングを無効化するには、「Pipeline の実行設定」を参照してください。
  • Jenkins サービスアカウントを有効化して、OpenShift Pipeline を実行する各プロジェクトにアクセスする方法は、「プロジェクト間のアクセス」を参照してください。
  • モニタリングするプロジェクトを追加するには、以下のいずれかを行います。

    • Jenkins コンソールにログインします。

      • Manage Jenkins から、Configure System に移動します。
      • OpenShift Jenkins SyncNamespace フィールドを更新します。
    • または、S2I 拡張オプションを使用して OpenShift Jenkins イメージを拡張して Jenkins 設定ファイルを更新します。
注記

OpenShift 同期プラグインを実行する複数の Jenkins デプロイメントから、同じプロジェクトのモニタリングがされないようにします。これらのインスタンス間の連携はなく、予期せぬ結果が発生する可能性があります。

7.6. バイナリービルド

7.6.1. はじめに

OpenShift のバイナリービルドの機能では、開発者はビルドで Git リポジトリーの URL からソースをプルするのではなく、ソースまたはアーティファクトをビルドに直接アップロードします。ソース、Docker またはカスタムのストラテジーが指定された BuildConfig はバイナリービルドとして起動できます。ローカルのアーティファクトからビルドを起動する場合は、既存のソース参照をローカルユーザーのマシンのソースに置き換えます。

ソースは複数の方法で提供できます。これは、start-build コマンドの使用時に利用可能な引数に相当します。

  • ファイルから (--from-file): これは、ビルドのソース全体が単一ファイルで構成されている場合です。たとえば、Docker ビルドは Dockerfile、Wildfly ビルドは pom.xml、Ruby ビルドは Gemfile です。
  • ディレクトリーから (--from-directory): ソースがローカルのディレクトリーにあり、Git リポジトリーにコミットされていない場合に使用します。start-build コマンドは指定のディレクトリーのアーカイブを作成して、ビルダーにソースとしてアップロードします。
  • アーカイブから (--from-archive): ソースが含まれるアーカイブがすでに存在する場合に使用します。アーカイブはtartar.gz または zip 形式のいずれかを使用できます。
  • Git リポジトリーから (--from-repo): これはソースがユーザーのローカルマシンで Git リポジトリーの一部となっている場合に使用します。現在のリポジトリーの HEAD コミットがアーカイブされ、ビルド用に OpenShift に送信されます。

7.6.1.1. 使用例

バイナリービルドの場合は、ビルドでソースを既存の git リポジトリーからプルする必要がありません。バイナリービルドを使用する理由は以下のとおりです。

  • ローカルコードの変更をビルドし、テストする。パブリックリポジトリーからのソースはクローンでき、ローカルの変更を OpenShift にアップロードしてビルドできます。ローカルの変更はコミットまたはプッシュする必要はありません。
  • プロイベートコードをビルドする。新規ビルドをゼロからバイナリービルドとして起動することができます。ソースは、SCM にチェックインする必要なく、ローカルのワークステションから OpenShift に直接アップロードできます。
  • 別のソースからアーティファクトを含むイメージをビルドする。Jenkins Pipeline では、Maven または C コンパイラー、これらのビルドを活用するランタイムイメージなどのツールでビルドしたアーティファクトを組み合わせる場合に、バイナリービルドが役立ちます。

7.6.1.2. 制限

  • バイナリービルドは反復できません。バイナリービルドは、ビルドの開始時にアーティファクトをアップロードするユーザーに依存するため、そのユーザーが毎回同じアップロードを繰り返さない限り、OpenShift は同じビルドを反復できません。
  • バイナリービルドは自動的にトリガーできません。バイナリービルドは、ユーザーが必要なバイナリーアーティファクトをアップロードする時にのみ手動で起動できます。
注記

バイナリービルドとして起動したビルドには設定済みのソース URL が含まれる場合があります。その場合、トリガーでビルドが正常に起動しますが、ソースはビルドの最終実行時にユーザーが指定した URL ではなく、設定済みのソース URL から取得されます。

7.6.2. チュートリアルの概要

以下のチュートリアルは、OpenShift クラスターが利用可能であり、アーティファクトを作成できるプロジェクトが用意されていることを前提としています。このチュートリアルでは、gitoc がローカルで使用できる必要があります。

7.6.2.1. チュートリアル: ローカルコードの変更のビルド

  1. 既存のソースリポジトリーをベースにして新規アプリケーションを作成し、そのルートを作成します。

    $ oc new-app https://github.com/openshift/ruby-hello-world.git
    $ oc expose svc/ruby-hello-world
  2. 初期ビルドが完了するまで待機し、ルートのホストに移動してアプリケーションのページを表示すると、Welcome ページが表示されるはずです。

    $ oc get route ruby-hello-world
  3. リポジトリーをローカルにクローンします。

    $ git clone https://github.com/openshift/ruby-hello-world.git
    $ cd ruby-hello-world
  4. アプリケーションのビューに変更を加えます。任意のエディターで views/main.rb を編集します。<body> タグを <body style="background-color:blue"> に変更します。
  5. ローカルで変更したソースで新規ビルドを起動します。リポジトリーのローカルディレクトリーから、以下を実行します。

    ----
    $ oc start-build ruby-hello-world --from-dir="." --follow
    ----

ビルドが完了し、アプリケーションが再デプロイされたら、アプリケーションのルートホストに移動すると、青のバックグラウンドのページが表示されるはずです。

ローカルでさらに変更を加えて、oc start-build --from-dir でコードをビルドします。

また、コードのブランチを作成し、変更をローカルでコミットし、リポジトリーの HEAD をビルドのソースとして使用します。

$ git checkout -b my_branch
$ git add .
$ git commit -m "My changes"
$ oc start-build ruby-hello-world --from-repo="." --follow

7.6.2.2. チュートリアル: プライベートコードのビルド

  1. コードを保存するローカルディレクトリーを作成します。

    $ mkdir myapp
    $ cd myapp
  2. このディレクトリーで、以下の内容を含む Dockerfile という名前のファイルを作成します。

    FROM centos:centos7
    
    EXPOSE 8080
    
    COPY index.html /var/run/web/index.html
    
    CMD cd /var/run/web && python -m SimpleHTTPServer 8080
  3. 以下の内容を含む index.html という名前のファイルを作成します。

    <html>
      <head>
        <title>My local app</title>
      </head>
      <body>
        <h1>Hello World</h1>
        <p>This is my local application</p>
      </body>
    </html>
  4. アプリケーションの新規ビルドを作成します。

    $ oc new-build --strategy docker --binary --docker-image centos:centos7 --name myapp
  5. ローカルディレクトリーの内容を使用して、バイナリービルドを起動します。

    $ oc start-build myapp --from-dir . --follow
  6. new-app を使用してアプリケーションをデプロイしてから、そのルートを作成します。

    $ oc new-app myapp
    $ oc expose svc/myapp
  7. ルートのホスト名を取得して、そこに移動します。

    $ oc get route myapp

コードをビルドし、デプロイした後に、ローカルファイルに変更を加えて、oc start-build myapp --from-dir を呼び出して新規ビルドを起動します。ビルドされると、コードが自動的にデプロイされ、ページを更新すると、変更がブラウザーに反映されます。

7.6.2.3. チュートリアル: パイプラインからのバイナリーアーティファクト

Jenkins on OpenShift では、適切なツールでスレーブイメージを使用して、コードをビルドすることができます。たとえば、maven スレーブを使用して、コードリポジトリーから WAR をビルドできます。ただし、このアーティファクトがビルドされたら、コードを実行するための適切なランタイムアーティファクトが含まれるイメージにコミットする必要があります。これらのアーティファクトをランタイムイメージに追加するために、バイナリービルドが使用される場合があります。以下のチュートリアルでは、maven スレーブで WAR をビルドし、Dockerfile でバイナリービルドを使用してこの WAR を WIldfly のランタイムイメージに追加するように Jenkins パイプラインを作成します。

  1. アプリケーションの新規ディレクトリーを作成します。

    $ mkdir mavenapp
    $ cd mavenapp
  2. WAR を wildfly イメージ内の適切な場所にコピーする Dockerfile を作成します。以下を Dockerfile という名前のローカルファイルにコピーします。

    FROM wildfly:latest
    COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
    CMD  $STI_SCRIPTS_PATH/run
  3. Dockerfile の新規 BuildConfig を作成します。

    注記

    これにより、ビルドが自動的に起動しますが、ROOT.war アーティファクトがまだ利用できないので初回は失敗します。以下のパイプラインでは、バイナリービルドを使用してその WAR をビルドに渡します。

    $ cat Dockerfile | oc new-build -D - --name mavenapp
  4. Jenkins Pipeline で BuildConfig を作成します。この BuildConfig では WAR をビルドし、以前に作成した Dockerfile を使用してこの WAR でイメージをビルドします。ツールのセットでバイナリーアーティファクトをビルドしてから、最終的なパッケージ用に別のランタイムイメージと組み合わせる場合など、同じパターンを別のプラットフォームでも使用できます。以下のコードを mavenapp-pipeline.yml に保存します。

    apiVersion: v1
    kind: BuildConfig
    metadata:
      name: mavenapp-pipeline
    spec:
      strategy:
        jenkinsPipelineStrategy:
          jenkinsfile: |-
            pipeline {
              agent { label "maven" }
              stages {
                stage("Clone Source") {
                  steps {
                    checkout([$class: 'GitSCM',
                                branches: [[name: '*/master']],
                                extensions: [
                                  [$class: 'RelativeTargetDirectory', relativeTargetDir: 'mavenapp']
                                ],
                                userRemoteConfigs: [[url: 'https://github.com/openshift/openshift-jee-sample.git']]
                            ])
                  }
                }
                stage("Build WAR") {
                  steps {
                    dir('mavenapp') {
                      sh 'mvn clean package -Popenshift'
                    }
                  }
                }
                stage("Build Image") {
                  steps {
                    dir('mavenapp/target') {
                      sh 'oc start-build mavenapp --from-dir . --follow'
                    }
                  }
                }
              }
            }
        type: JenkinsPipeline
      triggers: []
  5. Pipeline ビルドを作成します。Jenkins がプロジェクトにデプロイされていない場合は、パイプラインが含まれる BuildConfig を作成すると、Jenkins がデプロイされます。Jenkins がパイプラインをビルドする準備ができるまで、2 分ほどかかる場合があります。Jenkins のロールアウトの状況を確認するには、oc rollout status dc/jenkins を起動します。

    $ oc create -f ./mavenapp-pipeline.yml
  6. Jenkins の準備ができたら、以前に定義したパイプラインを起動します。

    $ oc start-build mavenapp-pipeline
  7. パイプラインがビルドを完了した時点で、new-app で新規アプリケーションをデプロイし、ルートを公開します。

    $ oc new-app mavenapp
    $ oc expose svc/mavenapp
  8. ブラウザーで、アプリケーションのルートに移動します。

    $ oc get route mavenapp