第6章 アプリケーションの移行
6.1. 概要
以下のトピックでは、OpenShift version 2 (v2) アプリケーションから OpenShift version 3 (v3) に移行する手順を説明します。
以下のトピックでは、OpenShift v2 に固有の用語を使用します。「「OpenShift Enterprise 2 と OpenShift Enterprise 3 の比較」では、これら 2 つのバージョンや、使用する用語の違いについて詳しく説明しています。
OpenShift v2 アプリケーションから OpenShift Container Platform v3 に移行するには、各 v2 カートリッジは OpenShift Container Platform v3 の対応のイメージまたはテンプレートと同等であり、個別に移行する必要があるので、v2 アプリケーションのすべてのカートリッジを記録する必要があります。またそれぞれのカートリッジについて、すべての依存関係または必要なパッケージは v3 イメージに含める必要があるため、それらを記録する必要もあります。
一般的な移行手順は以下のとおりです。
v2 アプリケーションをバックアップします。
- Web カートリッジ: ソースコードは、GitHub のリポジトリーにプッシュするなど、Git リポジトリーにバックアップすることができます。
-
データベースカートリッジ: データベースは、dump コマンドを使用してバックアップすることができます (
mongodump
、mysqldump
、pg_dump
)。 Web およびデータベースカートリッジ:
rhc
クライアントツールには、複数のカートリッジをバックアップするスナップショットの機能があります。$ rhc snapshot save <app_name>
スナップショットは展開可能な tar ファイルであり、このファイルには、アプリケーションのソースコードとデータベースのダンプが含まれます。
- アプリケーションにデータベースカートリッジが含まれる場合には、v3 データベースアプリケーションを作成し、データベースダンプを新しい v3 データベースアプリケーションの Pod に同期してから、データベースの復元コマンドを使用して v3 データベースアプリケーションに v2 データベースを復元します。
- Web フレームワークアプリケーションの場合には、v3 と互換性を持たせるようにアプリケーションのソースコードを編集してから、Git リポジトリーの適切なファイルに、必要な依存関係やパッケージを追加します。v2 環境変数を適切な v3 環境変数に変換します。
- ソース (Git リポジトリー) または Git URL のクイックスタートから v3 アプリケーションを作成します。また、データベースのサービスパラメーターを新規アプリケーションに追加して、データベースアプリケーションと Web アプリケーションをリンクします。
- v2 には統合 git 環境があり、アプリケーションは v2 git リポジトリーに変更がプッシュされるたびに自動的に再ビルドされ、再起動されます。v3 では、ビルドがパブリックの git リポジトリーにプッシュされるソースコードの変更で自動的にトリガーされるようにするために、v3 の初期ビルドの完了後に webhook を設定する必要があります。
6.2. データベースアプリケーションの移行
6.2.1. 概要
以下のトピックでは、MySQL、PostgreSQL および MongoDB データベースアプリケーションを OpenShift バージョン 2 (v2) から OpenShift version 3 (v3) に移行する方法を確認します。
6.2.2. サポートされているデータベース
v2 | v3 |
---|---|
MongoDB: 2.4 |
MongoDB: 2.4、2.6 |
MySQL: 5.5 |
MySQL: 5.5、5.6 |
PostgreSQL: 9.2 |
PostgreSQL: 9.2、9.4 |
6.2.3. MySQL
すべてのデータベースをダンプファイルにエクスポートして、これをローカルマシン (現在のディレクトリー) にコピーします
$ rhc ssh <v2_application_name> $ mysqldump --skip-lock-tables -h $OPENSHIFT_MYSQL_DB_HOST -P ${OPENSHIFT_MYSQL_DB_PORT:-3306} -u ${OPENSHIFT_MYSQL_DB_USERNAME:-'admin'} \ --password="$OPENSHIFT_MYSQL_DB_PASSWORD" --all-databases > ~/app-root/data/all.sql $ exit
dbdump をローカルマシンにダウンロードします。
$ mkdir mysqldumpdir $ rhc scp -a <v2_application_name> download mysqldumpdir app-root/data/all.sql
テンプレートから v3 mysql-persistent Pod を作成します。
$ oc new-app mysql-persistent -p \ MYSQL_USER=<your_V2_mysql_username> -p \ MYSQL_PASSWORD=<your_v2_mysql_password> -p MYSQL_DATABASE=<your_v2_database_name>
Pod の使用準備ができているかどうかを確認します。
$ oc get pods
Pod の実行中に、データベースのアーカイブファイルを v3 MySQL Pod にコピーします。
$ oc rsync /local/mysqldumpdir <mysql_pod_name>:/var/lib/mysql/data
v3 の実行中の Pod に、データベースを復元します。
$ oc rsh <mysql_pod> $ cd /var/lib/mysql/data/mysqldumpdir
v3 では、データベースを復元するには、root ユーザーとして MySQL にアクセスする必要があります。
v2 では、
$OPENSHIFT_MYSQL_DB_USERNAME
には全データベースに対する完全な権限がありました。v3 では、権限をデータベースごとに$MYSQL_USER
に割り当てる必要があります。$ mysql -u root $ source all.sql
<dbname> のすべての権限を
<your_v2_username>@localhost
に割り当ててから、権限をフラッシュします。Pod からダンプディレクトリーを削除します。
$ cd ../; rm -rf /var/lib/mysql/data/mysqldumpdir
サポート対象の MySQL 環境変数
v2 | v3 |
---|---|
|
|
|
|
|
|
|
|
| |
| |
| |
| |
| |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| |
| |
| |
| |
|
6.2.4. PostgreSQL
ギアから v2 PostgreSQL データベースをバックアップします。
$ rhc ssh -a <v2-application_name> $ mkdir ~/app-root/data/tmp $ pg_dump <database_name> | gzip > ~/app-root/data/tmp/<database_name>.gz
ローカルマシンに、バックアップファイルを展開します。
$ rhc scp -a <v2_application_name> download <local_dest> app-root/data/tmp/<db-name>.gz $ gzip -d <database-name>.gz
注記手順 4 とは別のフォルダーにバックアップファイルを保存します。
新規サービスを作成するための v2 アプリケーションのデータベース名、ユーザー名、パスワードを使用して PostgreSQL サービスを作成します。
$ oc new-app postgresql-persistent -p POSTGRESQL_DATABASE=dbname -p POSTGRESQL_PASSWORD=password -p POSTGRESQL_USER=username
Pod の使用準備ができているかどうかを確認します。
$ oc get pods
Pod を実行中に、バックアップディレクトリーを Pod に同期します。
$ oc rsync /local/path/to/dir <postgresql_pod_name>:/var/lib/pgsql/data
Pod にリモートからアクセスします。
$ oc rsh <pod_name>
データベースを復元します。
psql dbname < /var/lib/pgsql/data/<database_backup_file>
必要のなくなったバックアップファイルをすべて削除します。
$ rm /var/lib/pgsql/data/<database-backup-file>
サポート対象の PostgreSQL 環境変数
v2 | v3 |
---|---|
|
|
|
|
|
|
|
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
6.2.5. MongoDB
- OpenShift v3 の場合: MongoDB シェルバージョン 3.2.6
- OpenShift v2 の場合: MongoDB シェルバージョン 2.4.9
ssh
コマンドを使用して、v2 アプリケーションにリモートからアクセスします。$ rhc ssh <v2_application_name>
-d <database_name> -c <collections>
で単一のデータベースを指定して、mongodump を実行します。このオプションがないと、データベースはすべてダンプされます。各データベースは、独自のディレクトリーにダンプされます。$ mongodump -h $OPENSHIFT_MONGODB_DB_HOST -o app-root/repo/mydbdump -u 'admin' -p $OPENSHIFT_MONGODB_DB_PASSWORD $ cd app-root/repo/mydbdump/<database_name>; tar -cvzf dbname.tar.gz $ exit
dbdump を mongodump ディレクトリーのローカルマシンにダウンロードします。
$ mkdir mongodump $ rhc scp -a <v2 appname> download mongodump \ app-root/repo/mydbdump/<dbname>/dbname.tar.gz
v3 で MongoDB Pod を実行します。最新のイメージ (3.2.6) には mongo-tools が含まれないので、
mongorestore
またはmongoimport
コマンドを使用するには、デフォルトのmongodb-persistent テンプレートを編集して、mongo-tools, “mongodb:2.4”
を含むイメージタグを指定します。このため、以下のoc export
コマンドを使用して、編集することが必要です。$ oc export template mongodb-persistent -n openshift -o json > mongodb-24persistent.json
mongodb-24persistent.json の L80 を編集します。
mongodb:latest
はmongodb:2.4
に置き換えてください。$ oc new-app --template=mongodb-persistent -n <project-name-that-template-was-created-in> \ MONGODB_USER=user_from_v2_app -p \ MONGODB_PASSWORD=password_from_v2_db -p \ MONGODB_DATABASE=v2_dbname -p \ MONGODB_ADMIN_PASSWORD=password_from_v2_db $ oc get pods
mongodb Pod の実行中に、データベースのアーカイブファイルを v3 MongoDB Pod にコピーします。
$ oc rsync local/path/to/mongodump <mongodb_pod_name>:/var/lib/mongodb/data $ oc rsh <mongodb_pod>
MongoDB Pod で、復元する各データベースについて以下を実行します。
$ cd /var/lib/mongodb/data/mongodump $ tar -xzvf dbname.tar.gz $ mongorestore -u $MONGODB_USER -p $MONGODB_PASSWORD -d dbname -v /var/lib/mongodb/data/mongodump
データベースが復元されたかどうかを確認します。
$ mongo admin -u $MONGODB_USER -p $MONGODB_ADMIN_PASSWORD $ use dbname $ show collections $ exit
Pod から mongodump ディレクトリーを削除します。
$ rm -rf /var/lib/mongodb/data/mongodump
サポート対象の MongoDB 環境変数
v2 | v3 |
---|---|
|
|
|
|
|
|
|
|
| |
| |
| |
| |
| |
| |
| |
| |
|
6.3. Web フレームワークアプリケーションの移行
6.3.1. 概要
以下のトピックでは、Python、Ruby、PHP、Perl、Node.js、WordPress、Ghost、JBoss EAP、JBoss WS (Tomcat) および Wildfly 10 (JBoss AS) の Web フレームワークアプリケーションを OpenShift version 2 (v2) から OpenShift version 3 (v3) に移行する方法を確認します。
6.3.2. Python
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
setup.py、wsgi.py、requirements.txt および etc などの重要なファイルがすべて新規リポジトリーにプッシュされていることを確認します。
- アプリケーションに必要なパッケージがすべて requirements.txt に含まれていることを確認します。
oc
コマンドを使用して、ビルダーイメージとソースコードから新規の Python アプリケーションを起動します。$ oc new-app --strategy=source python:3.3~https://github.com/<github-id>/<repo-name> --name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
サポート対象の Python バージョン
v2 | v3 |
---|---|
Python: 2.6、2.7、3.3 | |
Django |
Django-psql-example (quickstart) |
6.3.3. Ruby
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
Gemfile がなく、単純な rack アプリケーションを実行している場合には、この Gemfile ファイルをソースの root にコピーします。
https://github.com/sclorg/ruby-ex/blob/master/Gemfile
注記Ruby 2.0 がサポートする rack gem の最新バージョンは 1.6.4 であるため、Gemfile は
gem 'rack', “1.6.4”
に変更する必要があります。Ruby 2.2 以降の場合は、rack gem 2.0 以降を使用してください。
oc
コマンドを使用して、ビルダーイメージとソースコードから新規の Ruby アプリケーションを起動します。$ oc new-app --strategy=source ruby:2.0~https://github.com/<github-id>/<repo-name>.git
サポート対象の Ruby バージョン
v2 | v3 |
---|---|
Ruby: 1.8、1.9、2.0 | |
Ruby on Rails: 3、4 |
Rails-postgresql-example (quickstart) |
Sinatra |
6.3.4. PHP
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
oc
コマンドを使用して、ビルダーイメージとソースコードから新規の PHP アプリケーションを起動します。$ oc new-app https://github.com/<github-id>/<repo-name>.git --name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
サポート対象の PHP バージョン
v2 | v3 |
---|---|
PHP: 5.3、5.4 | |
PHP 5.4 with Zend Server 6.1 | |
CodeIgniter 2 | |
HHVM | |
Laravel 5.0 | |
cakephp-mysql-example (quickstart) |
6.3.5. Perl
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
ローカルの Git リポジトリーを編集して、変更をアップストリームにプッシュして、v3 との互換性を確保します。
v2 では、CPAN モジュールは .openshift/cpan.txt にあり、v3 では s2i ビルダーは、ソースの root ディレクトリーで cpanfile という名前のファイルを検索します。
$ cd <local-git-repository> $ mv .openshift/cpan.txt cpanfile
cpanfile の形式が若干異なるので、これを編集します。
cpanfile の形式 cpan.txt の形式 requires ‘cpan::mod’;
cpan::mod
requires ‘Dancer’;
Dancer
requires ‘YAML’;
YAML
.openshift ディレクトリーを削除します。
注記v3 では、action_hooks および cron タスクは同じようにサポートされません。詳細情報は、「アクションフック」を参照してください。
-
oc
コマンドを使用して、ビルダーイメージとソースコードから新規の Perl アプリケーションを起動します。
$ oc new-app https://github.com/<github-id>/<repo-name>.git
サポート対象の Perl バージョン
v2 | v3 |
---|---|
Perl: 5.10 | |
Dancer-mysql-example (quickstart) |
6.3.6. Node.js
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
ローカルの Git リポジトリーを編集して、変更をアップストリームにプッシュして、v3 との互換性を確保します。
.openshift ディレクトリーを削除します。
注記v3 では、action_hooks および cron タスクは同じようにサポートされません。詳細情報は、「アクションフック」を参照してください。
server.js を編集します。
- L116 server.js: 'self.app = express();'
- L25 server.js: self.ipaddress = '0.0.0.0';
L26 server.js: self.port = 8080;
注記Lines(L) は V2 カートリッジの server.js から取得されます。
oc
コマンドを使用して、ビルダーイメージとソースコードから新規の Node.js アプリケーションを起動します。$ oc new-app https://github.com/<github-id>/<repo-name>.git --name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
サポート対象の Node.js バージョン
v2 | v3 |
---|---|
Node.js 0.10 | |
Nodejs-mongodb-example。このクイックスタートテンプレートは Node.js バージョン 6 のみをサポートします。 |
6.3.7. WordPress
現時点で WordPress アプリケーションの移行はコミュニティーによるサポートのみで、Red hat のサポートはありません。
WordPress アプリケーションの OpenShift Container Platform v3 への移行に関する情報は、「OpenShift ブログ」を参照してください。
6.3.8. Ghost
現時点で Ghost アプリケーションの移行はコミュニティーによるサポートのみで、Red hat のサポートはありません。
Ghost アプリケーションの OpenShift Container Platform v3 への移行に関する情報は、「OpenShift ブログ」を参照してください。
6.3.9. JBoss EAP
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
- リポジトリーに事前にビルドされた .war ファイルが含まれている場合には、それらをリポジトリーの root ディレクトリー内の deployments ディレクトリーに置く必要があります。
JBoss EAP 7 ビルダーイメージ (jboss-eap70-openshift) と GitHub からのソースコードリポジトリーを使用して新規アプリケーションを作成します。
$ oc new-app --strategy=source jboss-eap70-openshift:1.6~https://github.com/<github-id>/<repo-name>.git
6.3.10. JBoss WS (Tomcat)
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
- リポジトリーに事前にビルドされた .war ファイルが含まれている場合には、それらをリポジトリーの root ディレクトリー内の deployments ディレクトリーに置く必要があります。
JBoss Web Server 3 (Tomcat 7) ビルダーイメージ (jboss-webserver30-tomcat7) と GitHub からのソースコードリポジトリーを使用して新規アプリケーションを作成します。
$ oc new-app --strategy=source jboss-webserver30-tomcat7-openshift~https://github.com/<github-id>/<repo-name>.git --name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
6.3.11. JBoss AS (Wildfly 10)
新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
ローカルの v2 ソースコードを新規リポジトリーにプッシュします。
$ git push -u <remote-name> master
ローカルの Git リポジトリーを編集して、変更をアップストリームにプッシュして v3 との互換性を確保します。
.openshift ディレクトリーを削除します。
注記v3 では、action_hooks および cron タスクは同じようにサポートされません。詳細情報は、「アクションフック」を参照してください。
- deployments ディレクトリーをソースリポジトリーの root に追加します。.war ファイルをこの「deployments」ディレクトリーに移動します。
oc
コマンドを使用して、ビルダーイメージとソースコードから新規の Wildfly アプリケーションを起動します。$ oc new-app https://github.com/<github-id>/<repo-name>.git --image-stream=”openshift/wildfly:10.0" --name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
注記引数
--name
はアプリケーション名を指定するためのオプションの引数です。また、-e
はOPENSHIFT_PYTHON_DIR
などのビルドやデプロイメントプロセスに必要な環境変数を追加するためのオプションの引数です。
6.3.12. サポート対象の JBoss バージョン
v2 | v3 |
---|---|
JBoss App Server 7 | |
Tomcat 6 (JBoss EWS 1.0) | |
Tomcat 7 (JBoss EWS 2.0) | |
Vert.x 2.1 | |
WildFly App Server 10 | |
WildFly App Server 8.2.1.Final | |
WildFly App Server 9 | |
CapeDwarf | |
JBoss Data Virtualization 6 | |
JBoss Enterprise App Platform (EAP) 6 | |
JBoss Unified Push Server 1.0.0.Beta1、Beta2 | |
JBoss BPM Suite | |
JBoss BRMS | |
jboss-eap70-openshift: 1.3-Beta | |
eap64-https-s2i | |
eap64-mongodb-persistent-s2i | |
eap64-mysql-persistent-s2i | |
eap64-psql-persistent-s2i |
6.4. クイックスタートの例
6.4.1. 概要
v2 クイックスタートから v3 クイックスタートへの明確な移行パスはありませんが、v3 では以下のクイックスタートを利用できます。データベースを含むアプリケーションがある場合には、oc new-app
でアプリケーションを作成してから、もう一度 oc new-app
を実行して別のデータベースサービスを起動し、これら 2 つを共通の環境変数を使用してリンクするのではなく、以下のいずれかを使用し、ソースコードを含む GitHub リポジトリーからリンクしたアプリケーションとデータベースを一度にインスタンス化できます。oc get templates -n openshift
で利用可能なテンプレートをすべて表示することができます。
CakePHP MySQL https://github.com/sclorg/cakephp-ex
- テンプレート: cakephp-mysql-example
Node.js MongoDB https://github.com/sclorg/nodejs-ex
- テンプレート: nodejs-mongodb-example
Django PosgreSQL https://github.com/sclorg/django-ex
- テンプレート: django-psql-example
Dancer MySQL https://github.com/sclorg/dancer-ex
- テンプレート: dancer-mysql-example
Rails PostgreSQL https://github.com/sclorg/rails-ex
- テンプレート: rails-postgresql-example
6.4.2. ワークフロー
上記のテンプレート URL のいずれかに対して git clone
をローカルで実行します。アプリケーションのソースコードを追加し、コミットし、GitHub リポジトリーにプッシュしてから、上記のテンプレートのいずれかで v3 クイックスタート アプリケーションを起動します。
- アプリケーション用の GitHub リポジトリーを作成します。
クイックスタートテンプレートのクローンを作成して、GitHub リポジトリーをリモートとして追加します。
$ git clone <one-of-the-template-URLs-listed-above> $ cd <your local git repository> $ git remote add upstream <https://github.com/<git-id>/<quickstart-repo>.git> $ git push -u upstream master
ソースコードを GitHub にコミットし、プッシュします。
$ cd <your local repository> $ git commit -am “added code for my app” $ git push origin master
v3 で新規アプリケーションを作成します。
$ oc new-app --template=<template> \ -p SOURCE_REPOSITORY_URL=<https://github.com/<git-id>/<quickstart_repo>.git> \ -p DATABASE_USER=<your_db_user> \ -p DATABASE_NAME=<your_db_name> \ -p DATABASE_PASSWORD=<your_db_password> \ -p DATABASE_ADMIN_PASSWORD=<your_db_admin_password> 1
- 1
- MongoDB にのみ該当します。
web フレームワーク Pod とデータベース Pod の 2 つの Pod が実行され、web フレームワーク Pod 環境は、データベース Pod 環境と一致しているはずです。
oc set env pod/<pod_name> --list
を使用して、環境変数を表示できます。-
DATABASE_NAME
は<DB_SERVICE>_DATABASE
になります。 -
DATABASE_USER
は<DB_SERVICE>_USER
になります。 -
DATABASE_PASSWORD
は<DB_SERVICE>_PASSWORD
になります。 DATABASE_ADMIN_PASSWORD
はMONGODB_ADMIN_PASSWORD
になります (MongoDB のみに該当します)。SOURCE_REPOSITORY_URL
が指定されていない場合、テンプレートはソースリポジトリーとして上記のテンプレート URL (https://github.com/openshift/<quickstart>-ex) を使用して、hello-welcome アプリケーションが起動します。
-
データベースを移行する場合は、データベースをダンプファイルにエクスポートして、新しい v3 データベース Pod にデータベースを復元します。「データベースアプリケーション」に記載の手順を参照してください。ただし、データベース Pod はすでに実行中であるため、
oc new-app
の手順は省略してください。
6.5. 継続的インテグレーションまたは継続的デプロイ (CI/CD)
6.5.1. 概要
以下のトピックでは、OpenShift バージョン 2 (v2) と OpenShift バージョン 3 (v3) 間の継続的インテグレーションおよびデプロイメント (CI/CD) アプリケーションの相違点と、これらのアプリケーションを v3 環境に移行する方法を確認します。
6.5.2. Jenkins
Jenkins アプリケーションは、アーキテクチャーの根本的な違いにより OpenShift バージョン 2 (v2) と OpenShift バージョン 3 (v3) では異なる方法で設定されます。たとえば、v2 ではアプリケーションはギアでホストされる統合型の Git リポジトリーを使用してソースコードを保存します。v3 では、ソースコードは Pod の外部でホストされるパブリックまたはプライベート Git リポジトリーに置かれます。
さらに OpenShift v3 では、Jenkins ジョブは、ソースコードの変更だけでなく、ソースコードと共にアプリケーションをビルドするために使用されるイメージの変更である ImageStream の変更によってもトリガーされます。そのため、v3 で新しい Jenkins アプリケーションを作成してから、OpenShift v3 環境に適した設定でジョブを作成し直して Jenkins アプリケーションを手動で移行することを推奨します。
Jenkins アプリケーションの作成、ジョブの設定、Jenkins プラグインの正しい使用の方法に関する詳細は、以下のリソースを参照してください。
6.6. Webhook およびアクションフック
6.6.1. 概要
以下のトピックでは、OpenShift バージョン 2 (v2) と OpenShift バージョン 3 (v3) 間の webhook とアクションフックの相違点と、これらのアプリケーションの v3 環境への移行方法について説明します。
6.6.2. Webhook
GitHub リポジトリーから
BuildConfig
を作成した後に、以下を実行します。$ oc describe bc/<name-of-your-BuildConfig>
以下のように、上記のコマンドは webhook GitHub URL を出力します。
<https://api.starter-us-east-1.openshift.com:443/oapi/v1/namespaces/nsname/buildconfigs/bcname/webhooks/secret/github>.
- GitHub の Web コンソールから、この URL を GitHub にカットアンドペーストします。
-
GitHub リポジトリーで、Settings
Webhooks & Services から Add Webhook を選択します。 - Payload URL フィールドに、(上記と同様の) URL の出力を貼り付けます。
-
Content Type を
application/json
に設定します。 - Add webhook をクリックします。
webhook の設定が正常に完了したことを示す GitHub のメッセージが表示されます。
これで変更を GitHub リポジトリーにプッシュするたびに新しいビルドが自動的に起動し、ビルドに成功すると新しいデプロイメントが起動します。
アプリケーションを削除または再作成する場合には、GitHub の Payload URL フィールドを BuildConfig
webhook url で更新する必要があります。
6.6.3. アクションフック
OpenShift バージョン 2 (v2) では、.openshift/action_hooks ディレクトリーに build、deploy、post_deploy および pre_build スクリプトまたは action_hooks が置かれます。v3 にはこれらのスクリプトに対応する 1 対 1 の機能マッピングはありませんが、v3 の 「S2I ツール」には「カスタム可能なスクリプト」を指定の URL またはソースリポジトリーの .s2i/bin ディレクトリーに追加するオプションがあります。
OpenShift バージョン 3 (v3) には、イメージをビルドしてからレジストリーにプッシュするまでのイメージの基本的なテストを実行する「post-build hook」があります。「デプロイメントフック」はデプロイメント構成で設定されます。
v2 では、通常 action_hooks は環境変数を設定するために使用されます。v2 では、環境変数は以下のように渡される必要があります。
$ oc new-app <source-url> -e ENV_VAR=env_var
または以下を実行します。
$ oc new-app <template-name> -p ENV_VAR=env_var
または、以下を使用して環境変数を追加し、変更することができます。
$ oc set env dc/<name-of-dc> ENV_VAR1=env_var1 ENV_VAR2=env_var2’
6.7. S2I ツール
6.7.1. 概要
「Source-to-Image (S2I) ツール」は、アプリケーションのソースコードをコンテナーイメージに挿入します。最終成果物として、ビルダーイメージとビルド済みのソースコードが組み込まれた実行準備のできたコンテナーイメージが新たに作成されます。S2I ツールは、OpenShift Container Platform がなくても、「リポジトリー」から、ローカルマシンにインストールできます。
S2I ツールは、OpenShift Container Platform で使用する前にアプリケーションとイメージをローカルでテストし、検証するための非常に強力なツールです。
6.7.2. コンテナーイメージの作成
- アプリケーションに必要なビルダーイメージを特定します。Red Hat は、「Python、Ruby、Perl、PHP および Node.js」など各種の言語のビルダーイメージを複数提供しています。他のイメージは コミュニティースペース から取得できます。
S2I は、Git リポジトリーまたはローカルのファイルシステムのソースコードからイメージをビルドできます。ビルダーイメージおよびソースコードから新しいコンテナーイメージをビルドするには、以下を実行します。
$ s2i build <source-location> <builder-image-name> <output-image-name>
注記<source-location>
には Git リポジトリーの URL、 またはローカルファイルシステムのソースコードのディレクトリーのいずれかを指定できます。Docker デーモンでビルドしたイメージをテストします。
$ docker run -d --name <new-name> -p <port-number>:<port-number> <output-image-name> $ curl localhost:<port-number>
- 新しいイメージを「OpenShift レジストリー」にプッシュします。
oc
コマンドを使用して、OpenShift レジストリーのイメージから新規アプリケーションを作成します。$ oc new-app <image-name>
6.8. サポートガイド
6.8.1. 概要
以下のトピックでは、OpenShift バージョン 2 (v2) および OpenShift バージョン 3 (v3) でサポート対象の言語、フレームワーク、データベース、マーカーについて説明します。
OpenShift Container Platform のお客様が使用する一般的な組み合わせに関する情報は、「OpenShift Container Platform tested integrations」を参照してください。
6.8.2. サポートされているデータベース
データベースアプリケーションのトピックの「サポート対象のデータベース」セクションを参照してください。
6.8.3. サポート言語
6.8.4. サポート対象のフレームワーク
v2 | v3 |
---|---|
Jenkins サーバー |
jenkins-persistent |
Drupal 7 | |
Ghost 0.7.5 | |
WordPress 4 | |
Ceylon | |
Go | |
MEAN |
6.8.5. サポート対象のマーカー
v2 | v3 |
---|---|
pip_install |
リポジトリーに requirements.txt が含まれる場合には、デフォルトで pip が呼び出されます。含まれていない場合に pip は使用されません。 |
v2 | v3 |
---|---|
disable_asset_compilation |
これは、buildconfig ストラテジー定義で |
v2 | v3 |
---|---|
enable_cpan_tests |
これは、「ビルド設定」で |
v2 | v3 |
---|---|
use_composer |
ソースリポジトリーの root ディレクトリーに composer.json が含まれる場合に、コンポーザーが常に使用されます。 |
v2 | v3 |
---|---|
NODEJS_VERSION |
該当なし |
use_npm |
アプリケーションの起動には、 |
v2 | v3 |
---|---|
enable_debugging |
このオプションは、デプロイメント設定で設定される |
skip_maven_build |
pom.xml がある場合には、maven が実行されます。 |
java7 |
該当なし |
java8 |
JavaEE は JDK8 を使用します。 |
v2 | v3 |
---|---|
enable_debugging |
該当なし |
v2 | v3 |
---|---|
force_clean_build |
v3 には同様の概念が使われています。buildconfig の noCache フィールドにより、コンテナービルドによる各層の再実行が強制的に実行されます。S2I ビルドでは、clean build を示す incremental フラグはデフォルトで false になっています。 |
hot_deploy | |
enable_public_server_status |
該当なし |
disable_auto_scaling |
自動スケーリングはデフォルトではオフになっていますが、「Pod auto-scaling」でオンにすることができます。 |