第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 イメージに含める必要があるため、それらを記録する必要もあります。

一般的な移行手順は以下のとおりです。

  1. v2 アプリケーションをバックアップします。

    • Web カートリッジ: ソースコードは、GitHub のリポジトリーにプッシュするなど、Git リポジトリーにバックアップすることができます。
    • データベースカートリッジ: データベースは、dump コマンドを使用してバックアップすることができます (mongodumpmysqldumppg_dump)。
    • Web およびデータベースカートリッジ: rhc クライアントツールには、複数のカートリッジをバックアップするスナップショットの機能があります。

      $ rhc snapshot save <app_name>

      スナップショットは展開可能な tar ファイルであり、このファイルには、アプリケーションのソースコードとデータベースのダンプが含まれます。

  2. アプリケーションにデータベースカートリッジが含まれる場合には、v3 データベースアプリケーションを作成し、データベースダンプを新しい v3 データベースアプリケーションの Pod に同期してから、データベースの復元コマンドを使用して v3 データベースアプリケーションに v2 データベースを復元します。
  3. Web フレームワークアプリケーションの場合には、v3 と互換性を持たせるようにアプリケーションのソースコードを編集してから、Git リポジトリーの適切なファイルに、必要な依存関係やパッケージを追加します。v2 環境変数を適切な v3 環境変数に変換します。
  4. ソース (Git リポジトリー) または Git URL のクイックスタートから v3 アプリケーションを作成します。また、データベースのサービスパラメーターを新規アプリケーションに追加して、データベースアプリケーションと Web アプリケーションをリンクします。
  5. 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. サポートされているデータベース

v2v3

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

  1. すべてのデータベースをダンプファイルにエクスポートして、これをローカルマシン (現在のディレクトリー) にコピーします

    $ 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
  2. dbdump をローカルマシンにダウンロードします。

    $ mkdir mysqldumpdir
    $ rhc scp -a <v2_application_name> download mysqldumpdir app-root/data/all.sql
  3. テンプレートから 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>
  4. Pod の使用準備ができているかどうかを確認します。

    $ oc get pods
  5. Pod の実行中に、データベースのアーカイブファイルを v3 MySQL Pod にコピーします。

    $ oc rsync /local/mysqldumpdir <mysql_pod_name>:/var/lib/mysql/data
  6. 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 に割り当ててから、権限をフラッシュします。

  7. Pod からダンプディレクトリーを削除します。

    $ cd ../; rm -rf /var/lib/mysql/data/mysqldumpdir

サポート対象の MySQL 環境変数

v2v3

OPENSHIFT_MYSQL_DB_HOST

[service_name]_SERVICE_HOST

OPENSHIFT_MYSQL_DB_PORT

[service_name]_SERVICE_PORT

OPENSHIFT_MYSQL_DB_USERNAME

MYSQL_USER

OPENSHIFT_MYSQL_DB_PASSWORD

MYSQL_PASSWORD

OPENSHIFT_MYSQL_DB_URL

 

OPENSHIFT_MYSQL_DB_LOG_DIR

 

OPENSHIFT_MYSQL_VERSION

 

OPENSHIFT_MYSQL_DIR

 

OPENSHIFT_MYSQL_DB_SOCKET

 

OPENSHIFT_MYSQL_IDENT

 

OPENSHIFT_MYSQL_AIO

MYSQL_AIO

OPENSHIFT_MYSQL_MAX_ALLOWED_PACKET

MYSQL_MAX_ALLOWED_PACKET

OPENSHIFT_MYSQL_TABLE_OPEN_CACHE

MYSQL_TABLE_OPEN_CACHE

OPENSHIFT_MYSQL_SORT_BUFFER_SIZE

MYSQL_SORT_BUFFER_SIZE

OPENSHIFT_MYSQL_LOWER_CASE_TABLE_NAMES

MYSQL_LOWER_CASE_TABLE_NAMES

OPENSHIFT_MYSQL_MAX_CONNECTIONS

MYSQL_MAX_CONNECTIONS

OPENSHIFT_MYSQL_FT_MIN_WORD_LEN

MYSQL_FT_MIN_WORD_LEN

OPENSHIFT_MYSQL_FT_MAX_WORD_LEN

MYSQL_FT_MAX_WORD_LEN

OPENSHIFT_MYSQL_DEFAULT_STORAGE_ENGINE

 

OPENSHIFT_MYSQL_TIMEZONE

 
 

MYSQL_DATABASE

 

MYSQL_ROOT_PASSWORD

 

MYSQL_MASTER_USER

 

MYSQL_MASTER_PASSWORD

6.2.4. PostgreSQL

  1. ギアから 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
  2. ローカルマシンに、バックアップファイルを展開します。

    $ rhc scp -a <v2_application_name> download <local_dest> app-root/data/tmp/<db-name>.gz
    $ gzip -d <database-name>.gz
    注記

    手順 4 とは別のフォルダーにバックアップファイルを保存します。

  3. 新規サービスを作成するための v2 アプリケーションのデータベース名、ユーザー名、パスワードを使用して PostgreSQL サービスを作成します。

    $ oc new-app postgresql-persistent -p POSTGRESQL_DATABASE=dbname -p
    POSTGRESQL_PASSWORD=password -p POSTGRESQL_USER=username
  4. Pod の使用準備ができているかどうかを確認します。

    $ oc get pods
  5. Pod を実行中に、バックアップディレクトリーを Pod に同期します。

    $ oc rsync /local/path/to/dir <postgresql_pod_name>:/var/lib/pgsql/data
  6. Pod にリモートからアクセスします。

    $ oc rsh <pod_name>
  7. データベースを復元します。

    psql dbname < /var/lib/pgsql/data/<database_backup_file>
  8. 必要のなくなったバックアップファイルをすべて削除します。

    $ rm /var/lib/pgsql/data/<database-backup-file>

サポート対象の PostgreSQL 環境変数

v2v3

OPENSHIFT_POSTGRESQL_DB_HOST

[service_name]_SERVICE_HOST

OPENSHIFT_POSTGRESQL_DB_PORT

[service_name]_SERVICE_PORT

OPENSHIFT_POSTGRESQL_DB_USERNAME

POSTGRESQL_USER

OPENSHIFT_POSTGRESQL_DB_PASSWORD

POSTGRESQL_PASSWORD

OPENSHIFT_POSTGRESQL_DB_LOG_DIR

 

OPENSHIFT_POSTGRESQL_DB_PID

 

OPENSHIFT_POSTGRESQL_DB_SOCKET_DIR

 

OPENSHIFT_POSTGRESQL_DB_URL

 

OPENSHIFT_POSTGRESQL_VERSION

 

OPENSHIFT_POSTGRESQL_SHARED_BUFFERS

 

OPENSHIFT_POSTGRESQL_MAX_CONNECTIONS

 

OPENSHIFT_POSTGRESQL_MAX_PREPARED_TRANSACTIONS

 

OPENSHIFT_POSTGRESQL_DATESTYLE

 

OPENSHIFT_POSTGRESQL_LOCALE

 

OPENSHIFT_POSTGRESQL_CONFIG

 

OPENSHIFT_POSTGRESQL_SSL_ENABLED

 
 

POSTGRESQL_DATABASE

 

POSTGRESQL_ADMIN_PASSWORD

6.2.5. MongoDB

注記
  • OpenShift v3 の場合: MongoDB シェルバージョン 3.2.6
  • OpenShift v2 の場合: MongoDB シェルバージョン 2.4.9
  1. ssh コマンドを使用して、v2 アプリケーションにリモートからアクセスします。

    $ rhc ssh <v2_application_name>
  2. -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
  3. dbdumpmongodump ディレクトリーのローカルマシンにダウンロードします。

    $ mkdir mongodump
    $ rhc scp -a <v2 appname> download mongodump \
      app-root/repo/mydbdump/<dbname>/dbname.tar.gz
  4. 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:latestmongodb: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
  5. mongodb Pod の実行中に、データベースのアーカイブファイルを v3 MongoDB Pod にコピーします。

    $ oc rsync local/path/to/mongodump <mongodb_pod_name>:/var/lib/mongodb/data
    $ oc rsh <mongodb_pod>
  6. 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
  7. データベースが復元されたかどうかを確認します。

    $ mongo admin -u $MONGODB_USER -p $MONGODB_ADMIN_PASSWORD
    $ use dbname
    $ show collections
    $ exit
  8. Pod から mongodump ディレクトリーを削除します。

    $ rm -rf /var/lib/mongodb/data/mongodump

サポート対象の MongoDB 環境変数

v2v3

OPENSHIFT_MONGODB_DB_HOST

[service_name]_SERVICE_HOST

OPENSHIFT_MONGODB_DB_PORT

[service_name]_SERVICE_PORT

OPENSHIFT_MONGODB_DB_USERNAME

MONGODB_USER

OPENSHIFT_MONGODB_DB_PASSWORD

MONGODB_PASSWORD

OPENSHIFT_MONGODB_DB_URL

 

OPENSHIFT_MONGODB_DB_LOG_DIR

 
 

MONGODB_DATABASE

 

MONGODB_ADMIN_PASSWORD

 

MONGODB_NOPREALLOC

 

MONGODB_SMALLFILES

 

MONGODB_QUIET

 

MONGODB_REPLICA_NAME

 

MONGODB_KEYFILE_VALUE

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

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. setup.pywsgi.pyrequirements.txt および etc などの重要なファイルがすべて新規リポジトリーにプッシュされていることを確認します。

    • アプリケーションに必要なパッケージがすべて requirements.txt に含まれていることを確認します。
  4. 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 バージョン

v2v3

Python: 2.6、2.7、3.3

サポート対象のコンテナーイメージ

Django

Django-psql-example (quickstart)

6.3.3. Ruby

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. 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 以降を使用してください。

  4. oc コマンドを使用して、ビルダーイメージとソースコードから新規の Ruby アプリケーションを起動します。

    $ oc new-app --strategy=source
    ruby:2.0~https://github.com/<github-id>/<repo-name>.git

サポート対象の Ruby バージョン

v2v3

Ruby: 1.8、1.9、2.0

サポート対象のコンテナーイメージ

Ruby on Rails: 3、4

Rails-postgresql-example (quickstart)

Sinatra

 

6.3.4. PHP

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. oc コマンドを使用して、ビルダーイメージとソースコードから新規の PHP アプリケーションを起動します。

    $ oc new-app https://github.com/<github-id>/<repo-name>.git
    --name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>

サポート対象の PHP バージョン

v2v3

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

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル v2 Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. ローカルの Git リポジトリーを編集して、変更をアップストリームにプッシュして、v3 との互換性を確保します。

    1. 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

    2. .openshift ディレクトリーを削除します。

      注記

      v3 では、action_hooks および cron タスクは同じようにサポートされません。詳細情報は、「アクションフック」を参照してください。

  4. oc コマンドを使用して、ビルダーイメージとソースコードから新規の Perl アプリケーションを起動します。
$ oc new-app https://github.com/<github-id>/<repo-name>.git

サポート対象の Perl バージョン

v2v3

Perl: 5.10

サポート対象のコンテナーイメージ

 

Dancer-mysql-example (quickstart)

6.3.6. Node.js

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. ローカルの Git リポジトリーを編集して、変更をアップストリームにプッシュして、v3 との互換性を確保します。

    1. .openshift ディレクトリーを削除します。

      注記

      v3 では、action_hooks および cron タスクは同じようにサポートされません。詳細情報は、「アクションフック」を参照してください。

    2. 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 から取得されます。

  4. 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 バージョン

v2v3

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

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. リポジトリーに事前にビルドされた .war ファイルが含まれている場合には、それらをリポジトリーの root ディレクトリー内の deployments ディレクトリーに置く必要があります。
  4. 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)

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. リポジトリーに事前にビルドされた .war ファイルが含まれている場合には、それらをリポジトリーの root ディレクトリー内の deployments ディレクトリーに置く必要があります。
  4. 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)

  1. 新しい GitHub リポジトリーを設定して、そのリポジトリーをリモートのブランチとして現在のローカル Git リポジトリーに追加します。

    $ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
  2. ローカルの v2 ソースコードを新規リポジトリーにプッシュします。

    $ git push -u <remote-name> master
  3. ローカルの Git リポジトリーを編集して、変更をアップストリームにプッシュして v3 との互換性を確保します。

    1. .openshift ディレクトリーを削除します。

      注記

      v3 では、action_hooks および cron タスクは同じようにサポートされません。詳細情報は、「アクションフック」を参照してください。

    2. deployments ディレクトリーをソースリポジトリーの root に追加します。.war ファイルをこの「deployments」ディレクトリーに移動します。
  4. 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 はアプリケーション名を指定するためのオプションの引数です。また、-eOPENSHIFT_PYTHON_DIR などのビルドやデプロイメントプロセスに必要な環境変数を追加するためのオプションの引数です。

6.3.12. サポート対象の JBoss バージョン

v2v3

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 で利用可能なテンプレートをすべて表示することができます。

6.4.2. ワークフロー

上記のテンプレート URL のいずれかに対して git clone をローカルで実行します。アプリケーションのソースコードを追加し、コミットし、GitHub リポジトリーにプッシュしてから、上記のテンプレートのいずれかで v3 クイックスタート アプリケーションを起動します。

  1. アプリケーション用の GitHub リポジトリーを作成します。
  2. クイックスタートテンプレートのクローンを作成して、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
  3. ソースコードを GitHub にコミットし、プッシュします。

    $ cd <your local repository>
    $ git commit -am “added code for my app”
    $ git push origin master
  4. 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_PASSWORDMONGODB_ADMIN_PASSWORD になります (MongoDB のみに該当します)。

      SOURCE_REPOSITORY_URL が指定されていない場合、テンプレートはソースリポジトリーとして上記のテンプレート URL (https://github.com/openshift/<quickstart>-ex) を使用して、hello-welcome アプリケーションが起動します。

  5. データベースを移行する場合は、データベースをダンプファイルにエクスポートして、新しい 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

  1. 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>.
  2. GitHub の Web コンソールから、この URL を GitHub にカットアンドペーストします。
  3. GitHub リポジトリーで、Settings Webhooks & Services から Add Webhook を選択します。
  4. Payload URL フィールドに、(上記と同様の) URL の出力を貼り付けます。
  5. Content Typeapplication/json に設定します。
  6. 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. コンテナーイメージの作成

  1. アプリケーションに必要なビルダーイメージを特定します。Red Hat は、「Python、Ruby、Perl、PHP および Node.js」など各種の言語のビルダーイメージを複数提供しています。他のイメージは コミュニティースペース から取得できます。
  2. S2I は、Git リポジトリーまたはローカルのファイルシステムのソースコードからイメージをビルドできます。ビルダーイメージおよびソースコードから新しいコンテナーイメージをビルドするには、以下を実行します。

    $ s2i build <source-location> <builder-image-name> <output-image-name>
    注記

    <source-location> には Git リポジトリーの URL、 またはローカルファイルシステムのソースコードのディレクトリーのいずれかを指定できます。

  3. Docker デーモンでビルドしたイメージをテストします。

    $ docker run -d --name <new-name> -p <port-number>:<port-number> <output-image-name>
    $ curl localhost:<port-number>
  4. 新しいイメージを「OpenShift レジストリー」にプッシュします。
  5. 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. サポート対象のフレームワーク

表6.1 サポート対象のフレームワーク
v2v3

Jenkins サーバー

jenkins-persistent

Drupal 7

 

Ghost 0.7.5

 

WordPress 4

 

Ceylon

 

Go

 

MEAN

 

6.8.5. サポート対象のマーカー

表6.2 Python
v2v3

pip_install

リポジトリーに requirements.txt が含まれる場合には、デフォルトで pip が呼び出されます。含まれていない場合に pip は使用されません。

表6.3 Ruby
v2v3

disable_asset_compilation

これは、buildconfig ストラテジー定義で DISABLE_ASSET_COMPILATION 環境変数を true に設定すると使用できます。

表6.4 Perl
v2v3

enable_cpan_tests

これは、「ビルド設定」ENABLE_CPAN_TEST 環境変数を true に設定すると使用できます。

表6.5 PHP
v2v3

use_composer

ソースリポジトリーの root ディレクトリーに composer.json が含まれる場合に、コンポーザーが常に使用されます。

表6.6 Node.js
v2v3

NODEJS_VERSION

該当なし

use_npm

アプリケーションの起動には、DEV_MODEtrue に設定されていない限り npm が常に使用されます。true に設定されていない場合には nodemon が使用されます。

表6.7 JBoss EAP、JBoss WS、WildFly
v2v3

enable_debugging

このオプションは、デプロイメント設定で設定される ENABLE_JPDA 環境変数に値を設定することで制御します。

skip_maven_build

pom.xml がある場合には、maven が実行されます。

java7

該当なし

java8

JavaEE は JDK8 を使用します。

表6.8 Jenkins
v2v3

enable_debugging

該当なし

表6.9 all
v2v3

force_clean_build

v3 には同様の概念が使われています。buildconfignoCache フィールドにより、コンテナービルドによる各層の再実行が強制的に実行されます。S2I ビルドでは、clean build を示す incremental フラグはデフォルトで false になっています。

hot_deploy

RubyPythonPerlPHPNode.js

enable_public_server_status

該当なし

disable_auto_scaling

自動スケーリングはデフォルトではオフになっていますが、「Pod auto-scaling」でオンにすることができます。

6.8.6. サポート対象の環境変数

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.