Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第3章 APB の作成
3.1. APB の作成: 作業の開始
3.1.1. 概要
このチュートリアルでは、いくつかのサンプル Ansible Playbook Bundle (APB) の作成を行います。APB でプロビジョニング、プロビジョニング解除、バインドおよびバインド解除を可能にするアクションを作成します。APB の設計についての詳細は、「設計」のトピックを参照してください。APB の作成についてのさらに詳細な情報は、「参照」のトピックを参照してください。
このチュートリアルの残りの部分では、括弧のマークされた項目を独自の情報で置き換えます。たとえば、<host>:<port>
を 172.17.0.1.nip.io:8443
などに置き換えます。
3.1.2. 作業開始前の準備
独自の APB を作成する前に、開発環境をセットアップする必要があります。
- OpenShift Container Platform クラスターにアクセスできることを確認します。クラスターはサービスカタログと、OpenShift Container Platform 3.7 以降でサポートされている OpenShift Ansible broker (OAB) の両方を実行している必要があります。
-
APB ツールを「CLI ツール」のトピックで説明されているようにインストールします。検証するには、
apb help
コマンドを実行して、有効な応答の有無を確認します。 -
リモートホストに存在する OpenShift Container Platform クラスターに対して開発を行っている場合や、docker デーモンにアクセスがない場合は、本書で説明されている
apb push
およびapb run
コマンドを使用する際の代替的な手順について、「リモートクラスターの使用」を参照してください。
3.1.3. APB の初回作成
このチュートリアルでは、コンテナー化された hello world アプリケーションの APB を作成します。ここでは、APB hello-world-apb をミラーリングする基本的な APB を扱います。
最初のタスクとして、
apb
CLI ツールを使用して APB を初期化します。これにより、APB のスケルトンが作成されます。ここで使用するコマンドは単純なコマンドです。$ apb init my-test-apb
初期化の後に、以下の構造を確認できます。
my-test-apb/ ├── apb.yml ├── Dockerfile ├── playbooks │ ├── deprovision.yml │ └── provision.yml └── roles ├── deprovision-my-test-apb │ └── tasks │ └── main.yml └── provision-my-test-apb └── tasks └── main.yml
apb.yml (APB 仕様ファイル) および Dockerfile の 2 つのファイルがルートディレクトリーに作成されています。これらは APB に必要な最低限のファイルです。 これらは APB に必要な最低限のファイルです。APB 仕様ファイルについての詳細は、「参照」のトピックを参照してください。ここでは、Dockerfile で実行できることについても説明されています。
apb.yml
version: 1.0 name: my-test-apb description: This is a sample application generated by apb init bindable: False async: optional metadata: displayName: my-test plans: - name: default description: This default plan deploys my-test-apb free: True metadata: {} parameters: []
Dockerfile
FROM ansibleplaybookbundle/apb-base LABEL "com.redhat.apb.spec"=\ COPY playbooks /opt/apb/actions COPY roles /opt/ansible/roles RUN chmod -R g=u /opt/{ansible,apb} USER apb
Dockerfile では、2 つの更新を実行します。
FROM
命令を変更して、イメージを Red Hat Container Catalog から使用できるようにします。最初の行が表示されるはずです。FROM openshift3/apb-base
LABEL
命令のcom.redhat.apb.spec
を base64 でエンコードされたバージョンの apb.yml で更新します。これを実行するには、apb prepare
を実行します。$ cd my-test-apb $ apb prepare
これにより、以下のように Dockerfile が更新されます。
Dockerfile
FROM openshift3/apb-base LABEL "com.redhat.apb.spec"=\ "dmVyc2lvbjogMS4wCm5hbWU6IG15LXRlc3QtYXBiCmRlc2NyaXB0aW9uOiBUaGlzIGlzIGEgc2Ft\ cGxlIGFwcGxpY2F0aW9uIGdlbmVyYXRlZCBieSBhcGIgaW5pdApiaW5kYWJsZTogRmFsc2UKYXN5\ bmM6IG9wdGlvbmFsCm1ldGFkYXRhOgogIGRpc3BsYXlOYW1lOiBteS10ZXN0CnBsYW5zOgogIC0g\ bmFtZTogZGVmYXVsdAogICAgZGVzY3JpcHRpb246IFRoaXMgZGVmYXVsdCBwbGFuIGRlcGxveXMg\ bXktdGVzdC1hcGIKICAgIGZyZWU6IFRydWUKICAgIG1ldGFkYXRhOiB7fQogICAgcGFyYW1ldGVy\ czogW10=" COPY playbooks /opt/apb/actions COPY roles /opt/ansible/roles RUN chmod -R g=u /opt/{ansible,apb} USER apb
この時点で、ビルド可能な完全に形成された APB が使用できるようになります。
apb prepare
の使用を省略した場合でも、apb build
コマンドがイメージのビルド前に APB を作成します。$ apb build
新規の APB イメージをローカルの OpenShift Container レジストリーにプッシュできるようになります。
$ apb push
OAB のクエリーによって、新規の APB が一覧表示されているのを確認できます。
$ apb list ID NAME DESCRIPTION < ------------ ID -------------> dh-my-test-apb This is a sample application generated by apb init
同様に、OpenShift Container Platform Web コンソールにアクセスすると、サービスカタログの All および Other タブの下に my-test-apb という名前の新規 APB が表示されます。
3.1.4. アクションの追加
直前のセクションで作成された完全に新規の APB は、そのままの状態では多くのことを実行できないため、いくつかのアクションを追加する必要があります。サポートされているアクションには以下が含まれます。
- provision (プロビジョニング)
- deprovision (プロビジョニング解除)
- bind (バインド)
- unbind (バインド解除)
- test (テスト)
以下のセクションで上記のアクションのそれぞれを追加していきます。開始前に、以下を確認してください。
oc
CLI 経由で OpenShift Container Platform クラスターにログインしている。この場合は、apb
ツールが OpenShift Container Platform および OAB と対話できます。# oc login <cluster_host>:<port> -u <user_name> -p <password>
OpenShift Container Platform Web コンソールにログインし、APB がカタログに一覧表示されていることを確認します。
図3.1 OpenShift Container Platform Web コンソール
getting-started という名前のプロジェクトを作成します。このプロジェクトで OpenShift Container Platform リソースをデプロイします。Web コンソールまたは CLI を使用してこれを作成できます。
$ oc new-project getting-started
3.1.4.1. プロビジョニング
apb init
プロセスで、Playbook の playbooks/provision.yml と roles/provision-my-test-apb の関連ロールの、プロビジョニングタスクの 2 つの部分が表示されます。
my-test-apb ├── apb.yml ├── Dockerfile ├── playbooks │ └── provision.yml 1 └── roles └── provision-my-test-apb └── tasks └── main.yml 2
playbooks/provision.yml ファイルは、プロビジョニングアクションが OAB から呼び出される際に実行される Ansible Playbook です。Playbook は変更可能ですが、ここではコードをそのままにしておきます。
playbooks/provision.yml
- name: my-test-apb playbook to provision the application hosts: localhost gather_facts: false connection: local roles: - role: ansible.kubernetes-modules install_python_requirements: no - role: ansibleplaybookbundle.asb-modules - role: provision-my-test-apb playbook_debug: false
Playbook は localhost
で実行され、ロール provision-my-test-apb を実行します。この Playbook はサービスブローカーで作成されるローカルコンテナーで機能します。ansible.kubernetes-modules ロールによって kubernetes-modules を使用して OpenShift Container Platform リソースを作成できます。asb-modules は OAB で使用できる追加の機能を提供します。
現時点で、このロールに設定されたタスクはありません。roles/provision-my-test-apb/tasks/main.yml のコンテンツには、共通のリソース作成タスクを示すコメントのみが含まれます。現時点でプロビジョニングタスクを実行できますが、実行するタスクがないために APB コンテナーが単純に起動されるのみで、何もデプロイせずに終了されることになります。
これは Web コンソールを使用し、my-test APB をクリックして、これを getting-started プロジェクトにデプロイして試してみることができます。
図3.2 my-test のプロビジョニング
プロビジョニングの実行中、新規の namespace が dh-my-test-apb-prov-<random> という名前で作成されます。開発モードでは、これは永続しますが、通常この namespace は正常な完了後に削除されます。APB がプロビジョニングに失敗すると、デフォルトでは namespace は永続します。
Pod リソースを参照すると、ログで APB の実行を確認することができます。Pod のログを表示するには、以下を実行します。
Web コンソールを使用してすべての namespace を表示し、作成日で並べ替えるか、または以下のコマンドを使用するかのいずれかを実行して namespace を検索します。
$ oc get ns NAME STATUS AGE ansible-service-broker Active 1h default Active 1h dh-my-test-apb-prov-<random> Active 4m
プロジェクトに切り替えます。
$ oc project dh-my-test-apb-prov-<random> Now using project "dh-my-test-apb-prov-<random>" on server "<cluster_host>:<port>".
Pod 名を取得します。
$ oc get pods NAME READY STATUS RESTARTS AGE <apb_pod_name> 0/1 Completed 0 3m
ログを表示します。
$ oc logs -f <apb_pod_name> ... + ansible-playbook /opt/apb/actions/provision.yml --extra-vars '{"_apb_plan_id":"default","namespace":"getting-started"}' PLAY [my-test-apb playbook to provision the application] *********************** TASK [ansible.kubernetes-modules : Install latest openshift client] ************* skipping: [localhost] TASK [ansibleplaybookbundle.asb-modules : debug] ******************************* skipping: [localhost] PLAY RECAP ********************************************************************* localhost : ok=0 changed=0 unreachable=0 failed=0
3.1.4.1.1. デプロイメント設定の作成
APB は少なくともアプリケーション Pod をデプロイできる必要があります。これはデプロイメント設定を指定して実行できます。
provision-my-test-apb/tasks/main.yml ファイルでコメントアウトされている最初のタスクの 1 つに、デプロイメント設定の作成があります。このコメントを解除することも、または以下を貼り付けることもできます。
注記通常、
image:
値を独自のアプリケーションイメージに置き換えることができます。- name: create deployment config openshift_v1_deployment_config: name: my-test namespace: '{{ namespace }}' 1 labels: 2 app: my-test service: my-test replicas: 1 3 selector: 4 app: my-test service: my-test spec_template_metadata_labels: app: my-test service: my-test containers: 5 - env: image: docker.io/ansibleplaybookbundle/hello-world:latest name: my-test ports: - container_port: 8080 protocol: TCP
詳細については、『APB の作成: 参照』を参照してください。また、すべてのフィールドの詳細については、ansible-kubernetes-modules ドキュメントを参照してください。
APB をビルドし、プッシュします。
$ apb build $ apb push
- Web コンソールを使用して APB をプロビジョニングします。
プロビジョニングの後に、新規に実行される Pod および新規のデプロイメント設定が利用可能になります。OpenShift Container Platform リソースをチェックして検証します。
$ oc project getting-started $ oc get all NAME REVISION DESIRED CURRENT TRIGGERED BY dc/my-test 1 1 1 config NAME DESIRED CURRENT READY AGE rc/my-test-1 1 1 1 35s NAME READY STATUS RESTARTS AGE po/my-test-1-2pw4t 1/1 Running 0 33s
また、Web コンソールのプロジェクトの Overview ページでデプロイされたアプリケーションを表示できます。
この Pod を現行の状態で使用する唯一の方法として、以下を実行します。
$ oc describe pods/<pod_name>
これにより、その IP アドレスを検索し、それに直接アクセスします。複数の Pod がある場合、それらは別個にアクセスされます。それらを単一ホストのように処理するには、次のセクションで説明されているように サービス を作成する必要があります。
次に進む前にクリーンアップし、再度プロビジョニングを実行するために、getting-started プロジェクトを削除してから再作成するか、または新規のプロジェクトを作成することができます。
3.1.4.1.2. サービスの作成
複数の Pod を使用して負荷分散を行い、ユーザーがそれらに単一ホストとしてアクセスできるように サービスを作成する必要になる場合があります。以下を実行します。
provision-my-test-apb/tasks/main.yml ファイルを変更し、以下を追加します。
- name: create my-test service k8s_v1_service: name: my-test namespace: '{{ namespace }}' labels: app: my-test service: my-test selector: app: my-test service: my-test ports: - name: web port: 80 target_port: 8080
selector
セクションでは、my-test サービスに適切な Pod を組み込むことができます。ports
はターゲットポートを Pod から取得し (8080)、それらをサービスの単一ポート (80) として公開します。アプリケーションは 8080 で実行されていますが、これがデフォルトの HTTP ポート 80 で利用可能になることに注意してください。ポートの
name
フィールドでは、このポートを今後に他のリソースで使用できるように指定できます。詳細については、 k8s_v1_service モジュールを参照してください。APB をビルドし、プッシュします。
$ apb build $ apb push
- Web コンソールを使用して APB をプロビジョニングします。
プロビジョニング後に、新規サービスが Web コンソールまたは CLI に表示されます。Web コンソールでは、アプリケーションの Overview ページの Networking の下か、または Applications → Services の下で新規サービスをクリックできます。負荷が分散されたアプリケーションに使用するために使用できるサービスの IP アドレスが表示されます。
コマンドラインでサービスの情報を表示するには、以下を実行できます。
$ oc project getting-started $ oc get services $ oc describe services/my-test
describe
コマンドは、サービスにアクセスするために使用する IP アドレスを表示します。ただし、ユーザーがアプリケーションにアクセスするために IP アドレスを使用する方法は通常は理想的な方法ではありません。その代わりに、次のセクションで説明されるように ルート を作成する必要があります。
次に進む前にクリーンアップし、再度プロビジョニングを実行するために、getting-started プロジェクトを削除してから再作成するか、または新規のプロジェクトを作成することができます。
3.1.4.1.3. ルートの作成
アプリケーションへの外部アクセスは、信頼できる名前付きルートで公開できます。
provision-my-test-apb/tasks/main.yml ファイルを変更して以下を追加します。
- name: create my-test route openshift_v1_route: name: my-test namespace: '{{ namespace }}' labels: app: my-test service: my-test to_name: my-test spec_port_target_port: web
to_name
はターゲットサービスの名前です。spec_port_target_port
はターゲットサービスのポートの名前を参照します。詳細は、「openshift_v1_routeモジュールを参照してください。APB をビルドし、プッシュします。
$ apb build $ apb push
- Web コンソールを使用して APB をプロビジョニングします。
プロビジョニング後に、作成される新規ルートが表示されます。Web コンソールの getting-started プロジェクトの Overview ページでは、アクティブでクリック可能なルートリンクがアプリケーションに一覧表示されます。ルートをクリックするか、または URL にアクセスすると、hello-world アプリケーションが起動します。
CLI からルート情報を表示することもできます。
$ oc project getting-started $ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD my-test my-test-getting-started.172.17.0.1.nip.io my-test web None $ oc describe routes/my-test Name: my-test Namespace: getting-started ...
この時点で、my-test アプリケーションは完全に機能し、負荷分散が行われており、拡張可能かつアクセス可能です。完成した APB を hello-world-apb サンプルリポジトリーの hello-world APB と比較できます。
3.1.4.2. プロビジョニング解除
プロビジョニング解除タスクについては、すべてのプロビジョニングされたリソースを、通常は作成時と反対の順序で破棄する必要があります。
プロビジョニング解除アクションを追加するには、deprovision.yml ファイルが playbooks/ ディレクトリーの下にあり、関連タスクが roles/deprovision-my-test-apb/tasks/main.yml になければなりません。これらのファイルはどちらもすでに作成されている必要があります。
my-test-apb/ ├── apb.yml ├── Dockerfile ├── playbooks │ └── deprovision.yml 1 └── roles └── deprovision-my-test-apb └── tasks └── main.yml 2
deprovision.yml ファイルの内容は、異なるロールを呼び出すことを除くとプロビジョニングタスクと同様です。
playbooks/deprovision.yml
- name: my-test-apb playbook to deprovision the application hosts: localhost gather_facts: false connection: local roles: - role: ansible.kubernetes-modules install_python_requirements: no - role: ansibleplaybookbundle.asb-modules - role: deprovision-my-test-apb playbook_debug: false
このロールをファイル roles/deprovision-my-test-apb/tasks/main.yml で編集します。タスクのコメントを解除することにより、コメントなしの生成されるファイルは以下のようになります。
- openshift_v1_route: name: my-test namespace: '{{ namespace }}' state: absent - k8s_v1_service: name: my-test namespace: '{{ namespace }}' state: absent - openshift_v1_deployment_config: name: my-test namespace: '{{ namespace }}' state: absent
先に作成された provision.yml ファイルでは、デプロイメント設定、サービス、次にルートを作成しました。プロビジョンニング解除アクションの場合、リソースを逆の順序で削除する必要があります。これは、リソースを namespace
および name
で識別し、これを state: absent
としてマークして実行できます。
プロビジョニング解除テンプレートを実行するには、Deployed Services 一覧のメニューをクリックし、Delete を選択します。
3.1.4.2.1. バインド
先のセクションでは、スタンドアロンアプリケーションをデプロイする方法を説明しました。しかし、ほとんどの場合、アプリケーションは他のアプリケーションと通信し、とくにデータソースと通信する必要があります。以下のセクションでは、my-test-apb からデプロイされた hello-world アプリケーションが使用できる PostSQL データベースを作成します。
3.1.4.2.1.1. 準備
正常に開始できるように、PostgreSQL をプロビジョニングおよびプロビジョニング解除するために必要なファイルを作成します。
詳細な例については、PostgreSQL example APB を参照してください。
--bindable
オプションを使用して APB を初期化します。$ apb init my-pg-apb --bindable
これは、いくつかの違いはあるものの、通常の APB ファイル構造を作成します。
my-pg-apb/ ├── apb.yml 1 ├── Dockerfile ├── playbooks │ ├── bind.yml 2 │ ├── deprovision.yml │ ├── provision.yml │ └── unbind.yml 3 └── roles ├── bind-my-pg-apb │ └── tasks │ └── main.yml 4 ├── deprovision-my-pg-apb │ └── tasks │ └── main.yml ├── provision-my-pg-apb │ └── tasks │ └── main.yml 5 └── unbind-my-pg-apb └── tasks └── main.yml 6
通常ファイルのほかに、新規 Playbook bind.yml、 unbind.yml、およびそれらの関連付けられたロールが表示されます。bind.yml および unbind.yml ファイルはどちらも空であり、デフォルトのバインド動作を使用しているために空のままになります。
apb.yml ファイルを編集します。
bindable: true
の設定に注意してください。それらの変更のほかにも、PostgreSQL を設定するためにいくつかのパラメーターを apb.yml に追加する必要があります。それらは、新規 APB のプロビジョニング時の Web コンソールでの選択可能なフィールドになります。version: 1.0 name: my-pg-apb description: This is a sample application generated by apb init bindable: True async: optional metadata: displayName: my-pg plans: - name: default description: This default plan deploys my-pg-apb free: True metadata: {} # edit the parameters and add the ones below. parameters: - name: postgresql_database title: PostgreSQL Database Name type: string default: admin - name: postgresql_user title: PostgreSQL User type: string default: admin - name: postgresql_password title: PostgreSQL Password type: string default: admin
playbooks/provision.yml は以下のようになります。
- name: my-pg-apb playbook to provision the application hosts: localhost gather_facts: false connection: local roles: - role: ansible.kubernetes-modules install_python_requirements: no - role: ansibleplaybookbundle.asb-modules - role: provision-my-pg-apb playbook_debug: false
playbooks/deprovision.yml は以下のようになります。
- name: my-pg-apb playbook to deprovision the application hosts: localhost gather_facts: false connection: local roles: - role: ansible.kubernetes-modules install_python_requirements: no - role: deprovision-my-pg-apb playbook_debug: false
roles/provision-my-pg-apb/tasks/main.yml ファイルを編集します。このファイルは、多くの点で hello-world アプリケーションをミラーリングしますが、再起動間のデータを保存し、デプロイメント設定の各種設定オプションを保存するために 永続ボリューム (PV) を追加します。
さらに、新規タスクがプロビジョニングタスク後に下部に追加されます。プロビジョニングプロセスで作成された認証情報を保存するには、OAB で取得できるようにそれらをエンコードする必要があります。モジュール
asb_encode_binding
を使用する新規タスクでこれを実行します。このファイルのすべての内容を安全に削除し、これを以下に置き換えることができます。
# New persistent volume claim - name: create volumes k8s_v1_persistent_volume_claim: name: my-pg namespace: '{{ namespace }}' state: present access_modes: - ReadWriteOnce resources_requests: storage: 1Gi - name: create deployment config openshift_v1_deployment_config: name: my-pg namespace: '{{ namespace }}' labels: app: my-pg service: my-pg replicas: 1 selector: app: my-pg service: my-pg spec_template_metadata_labels: app: my-pg service: my-pg containers: - env: - name: POSTGRESQL_PASSWORD value: '{{ postgresql_password }}' - name: POSTGRESQL_USER value: '{{ postgresql_user }}' - name: POSTGRESQL_DATABASE value: '{{ postgresql_database }}' image: docker.io/centos/postgresql-94-centos7 name: my-pg ports: - container_port: 5432 protocol: TCP termination_message_path: /dev/termination-log volume_mounts: - mount_path: /var/lib/pgsql/data name: my-pg working_dir: / volumes: - name: my-pg persistent_volume_claim: claim_name: my-pg test: false triggers: - type: ConfigChange - name: create service k8s_v1_service: name: my-pg namespace: '{{ namespace }}' state: present labels: app: my-pg service: my-pg selector: app: my-pg service: my-pg ports: - name: port-5432 port: 5432 protocol: TCP target_port: 5432 # New encoding task makes credentials available to future bind operations - name: encode bind credentials asb_encode_binding: fields: DB_TYPE: postgres DB_HOST: my-pg DB_PORT: "5432" DB_USER: "{{ postgresql_user }}" DB_PASSWORD: "{{ postgresql_password }}" DB_NAME: "{{ postgresql_database }}"
encode bind credentials
タスクは利用可能なフィールドを環境変数として利用可能にします。これには、DB_TYPE
、DB_HOST
、DB_PORT
、DB_USER
、DB_PASSWORD
およびDB_NAME
が含まれます。これは、bind.yml ファイルが空のままの場合のデフォルト動作になります。すべてのアプリケーション (hello-world など) がこれらの環境変数を使用でき、バインド操作後に設定済みのデータベースに接続できます。roles/deprovision-my-pg-apb/tasks/main.yml を編集し、以下の行のコメントを解除して、作成されたリソースがプロビジョニング解除時に削除されるようにします。
- k8s_v1_service: name: my-pg namespace: '{{ namespace }}' state: absent - openshift_v1_deployment_config: name: my-pg namespace: '{{ namespace }}' state: absent - k8s_v1_persistent_volume_claim: name: my-pg namespace: '{{ namespace }}' state: absent
最後に APB をビルドし、プッシュします。
$ apb build $ apb push
この時点で、APB は完全に機能する PostgreSQL データベースをクラスターに作成できます。これについては、次のセクションでテストできます。
3.1.4.2.1.2. UI からの実行
アプリケーションをテストするには、hello-world アプリケーションをプロビジョニングされた PostgreSQL データベースにバインドできます。このチュートリアルの「プロビジョニング」セクションで事前に作成されたアプリケーションを使用するか、または hello-world-apb を使用できます。
- まず、my-test-apb をプロビジョニングします。
次に、my-pg-apb をプロビジョニングし、Create a secretオプションを選択します。
- 次に、プロジェクトに移動します (まだの場合)。hello-world アプリケーションと PostgreSQL データベースの両方を確認できます。プロビジョニング時にバインディングを作成することを選択しなかった場合は、ここで Create binding リンクを使用してこれを実行できます。
バインディングが作成されたら、バインディングで作成されたシークレットをアプリケーションに追加する必要があります。 まず、「Resources → Secrets」ページでシークレットに移動します。
シークレットを環境変数として追加します。
これを追加したら、Overview ページに戻ることができます。 my-test アプリケーションは依然として設定変更による再デプロイの実行中である可能性があります。その場合には、ルートをクリックしてアプリケーションを表示できるまで待機します。
ルートのクリック後に、hello-world アプリケーションが my-pg データベースを検出し、これに接続されていることを確認できます。
3.1.4.2.2. テスト
テストアクションは、APB がサービスカタログに公開される前に基本的なサニティーチェックをパスするものであることを確認することを目的としています。これらはライブサービスをテストするように意図されていません。OpenShift Container Platform には、プロビジョニング時に追加できる liveness および readiness プローブを使用してライブサービスをテストする機能があります。
テストの実際の実装については、APB の作成者が決定することができます。以下のセクションでは、これについてのガイダンスおよびベストプラクティスを説明します。
3.1.4.2.2.1. テストアクションの作成
APB のテストアクションを作成するには、以下を実行します。
- playbooks/test.yml ファイルを組み込みます。
- テストのデフォルトを playbooks/vars/ ディレクトリーに組み込みます。
my-apb/ ├── ... ├── playbooks/ ├── test.yml └── vars/ └── test_defaults.yml
APB のテストのオーケストレーションを実行するには、test.yml ファイルの include_vars および include_role モジュールを使用する必要があります。
test.yml
- name: test media wiki abp hosts: localhost gather_facts: false connection: local roles: - role: ansible.kubernetes-modules 1 install_python_requirements: no post_tasks: - name: Load default variables for testing 2 include_vars: test_defaults.yaml - name: create project for namespace openshift_v1_project: name: '{{ namespace }}' - name: Run the provision role. 3 include_role: name: provision-mediawiki-apb - name: Run the verify role. 4 include_role: name: verify-mediawiki-apb
3.1.4.2.2.2. 検証ロールの作成
検証ロール では、プロビジョニングが失敗したか、または成功したかを判別できます。verify_<name> ロールは roles/ ディレクトリーに配置されます。これは通常の Ansible ロールです。
my-apb/ ├── ... └── roles/ ├── ... └── verify_<name> ├── defaults └── defaults.yml └── tasks └── main.yml
main.yml ファイルのタスクサンプルは以下のようになります。
- name: url check for media wiki uri: url: "http://{{ route.route.spec.host }}" return_content: yes register: webpage failed_when: webpage.status != 200
3.1.4.2.2.3. テスト結果の保存
また、asb_save_test_result モジュールを検証ロールで使用することもできます。これにより、APB はテスト結果を保存し、apb test
コマンドはそれらを返すことができるようになります。APB Pod はツールがテスト結果を取得するまで有効な状態のままになります。
たとえば、asb_save_test_result の使用を先の main.yml のサンプルに追加します。
- name: url check for media wiki uri: url: "http://{{ route.route.spec.host }}" return_content: yes register: webpage - name: Save failure for the web page asb_save_test_result: fail: true msg: "Could not reach route and retrieve a 200 status code. Recieved status - {{ webpage.status }}" when: webpage.status != 200 - fail: msg: "Could not reach route and retrieve a 200 status code. Recieved status - {{ webpage.status }}" when: webpage.status != 200 - name: Save test pass asb_save_test_result: fail: false when: webpage.status == 200
3.1.4.2.2.4. テストアクションの実行
テストアクションを定義した後に、CLI ツールを使用してテストを実行できます。
$ apb test
テストアクションは以下を実行します。
- イメージのビルド
- サービスブローカーで実行を開始される場合と同様の Pod の起動
- 保存されている場合、テスト結果の取得
実行が終了した後の Pod のステータスはテストのステータスを判別するものになります。Pod がエラー状態の場合は障害が生じたことを示し、コマンドはテストが不成功であったことを報告します。
3.2. APB の作成: 参照
3.2.1. 概要
「使用開始」のトピックでは初回の Ansible Playbook Bundle (APB) の作成を手順ごとに説明していますが、このトピックでは、詳細な参考情報を提供します。ここでは APB を構成する基本的なコンポーネントについて詳細に説明し、経験豊かな APB 開発者が APB 内の個々のコンポーネントをよく理解するのに役立つ情報を提供します。
完成した APB サンプルについては、GitHub のansibleplaybookbundle 組織で APB を参照できます。
3.2.2. ディレクトリー構造
以下は、APB のディレクトリー構造のサンプルを示しています。
example-apb/ ├── Dockerfile ├── apb.yml └── roles/ │ └── example-apb-openshift │ ├── defaults │ │ └── main.yml │ └── tasks │ └── main.yml └── playbooks/ └── provision.yml └── deprovision.yml └── bind.yml └── unbind.yml
3.2.3. APB 仕様ファイル
APB 仕様ファイルは apb.yml に置かれ、ここではアプリケーションの概要情報が宣言されます。以下は APB 仕様の例です。
version: 1.0
name: example-apb
description: A short description of what this APB does
bindable: True
async: optional 1
metadata:
documentationUrl: <link_to_documentation>
imageUrl: <link_to_url_of_image>
dependencies: ['<registry>/<organization>/<dependency_name_1>', '<registry>/<organization>/<dependency_name_2>']
displayName: Example App (APB)
longDescription: A longer description of what this APB does
providerDisplayName: "Red Hat, Inc."
plans:
- name: default
description: A short description of what this plan does
free: true
metadata:
displayName: Default
longDescription: A longer description of what this plan deploys
cost: $0.00
parameters:
- name: parameter_one
required: true
default: foo_string
type: string
title: Parameter One
maxlength: 63
- name: parameter_two
required: true
default: true
title: Parameter Two
type: boolean
- 1
- 非同期バインドおよびバインド解除は実験的な機能であり、デフォルトではサポートされておらず、有効にされていません。
3.2.3.1. 上部の構造
フィールド | 説明 |
---|---|
|
APB 仕様のバージョンです。詳細は、「APB 仕様のバージョン管理」を参照してください。 |
|
APB の名前です。名前は有効な ASCII でなければならず、小文字、数字、アンダースコア、ピリオド、およびダッシュを含めることができます。有効なタグ名については、Docker のガイドラインを参照してください。 |
|
この APB の簡単な説明です。 |
|
この APB をバインド可能にするかについてのブール値オプションです。許可されるフィールドは |
|
関連するメタデータ情報を宣言するディクショナリーフィールドです。 |
|
デプロイできるプランの一覧です。詳細は、「プラン」を参照してください。. |
3.2.3.2. メタデータ
フィールド | 説明 |
---|---|
|
アプリケーションのドキュメントへの URL です。 |
|
サービスカタログについての Web コンソールに表示されるイメージの URL です。 |
|
APB 内で使用できるイメージの一覧です。 |
|
Web コンソールに表示されるこの APB の名前です。 |
|
APB が Web コンソールでクリックされる際に表示される詳細の説明です。 |
|
この APB を使用できるように提供しているプロバイダーの名前です。 |
3.2.3.3. プラン
プランは一覧として宣言されます。このセクションでは、プランの各フィールドの説明内容について説明します。
フィールド | 説明 |
---|---|
|
デプロイするプランの任意の名前です。これは APB がサービスカタログからクリックされる際に表示されます。 |
|
このプランからデプロイされる内容の簡単な説明です。 |
|
この計画にコストが発生しないかどうかを判別するためのブール値フィールドです。許可されるフィールドは |
|
関連するプランメタデータ情報を宣言するディクショナリーフィールドです。詳細は、「プランメタデータ」を参照してください。 |
|
APB への入力として使用されるパラメーターディクショナリーの一覧です。詳細は、「パラメーター 」を参照してください。 |
3.2.3.4. プランメタデータ
フィールド | 説明 |
---|---|
|
Web コンソールに表示されるプランの名前です。 |
|
このプランがデプロイする内容の詳細な説明です。 |
|
プランのデプロイにかかるコストです。許可されるフィールドは |
3.2.3.5. パラメーター
parameters
セクションの各項目には複数のフィールドがある場合があります。name
フィールドは必須です。パラメーターの順序は、OpenShift Container Platform Web コンソールのフォームの順序で表示されます。
parameters: - name: my_param title: My Parameter type: enum enum: ['X', 'Y', 'Z'] required: True default: X display_type: select display_group: Group 1
フィールド | 説明 |
---|---|
|
APB に渡されるパラメーターの固有の名前です。 |
|
Web コンソールに表示されるラベルです。 |
|
リンク json-schema で指定されるパラメーターのデータタイプです ( |
|
パラメーターが APB の実行に必須かどうかを示します。Web コンソールの必須フィールドです。 |
|
パラメーターに割り当てられるデフォルト値です。 |
|
Web コンソールの表示タイプです。たとえば、 |
|
パラメーターが一致する |
パラメーターの詳細の一覧を使用する場合、共有パラメーター一覧を使用すると便利です。この例として、rhscl-postgresql-apb を参照してください。
3.2.3.6. APB 仕様のバージョン管理
APB 仕様は x.y
形式のセマンティックバージョニングを使用します。ここで、x
はメジャーリリースで、 y
はマイナーリリースです。e.
現行の仕様バージョンは 1.0
です。
3.2.3.6.1. メジャーバージョン
APB 仕様は、API の互換性を失う変更が仕様に導入されるたびにメジャーバージョンを増分します。その例には以下が含まれます。
- 必須フィールドの導入または削除。
- YAML 形式の変更。
- 新機能。
3.2.3.6.2. マイナーバージョン
APB 仕様は、API の互換性に影響がない変更が仕様に導入されるたびにマイナーバージョンを増分します。その例には以下が含まれます。
- オプションフィールドの導入または削除。
- スペルの修正。
- 新規オプションの既存フィールドへの導入。
3.2.4. Dockerfile
Dockerfile は APB イメージを実際にビルドする際に使用されます。そのため、これを独自のニーズに合わせてカスタマイズする必要があります。たとえば、PostgreSQL との対話が必要な Playbook を実行する場合、yum install
コマンドを追加して必要なパッケージをインストールすることが必要になる可能性があります。
FROM ansibleplaybookbundle/apb-base MAINTAINER Ansible Playbook Bundle Community LABEL "com.redhat.apb.spec"=\ "<------------base64-encoded-spec------------>" COPY roles /opt/ansible/roles COPY playbooks /opt/apb/actions RUN chmod -R g=u /opt/{ansible,apb} ### INSTALL THE REQUIRED PACKAGES RUN yum -y install python-boto postgresql && yum clean all USER apb
3.2.5. APB アクション (Playbook)
APB のアクションは APB の実行で使用されるコマンドです。サポートされている標準的なアクションは以下になります。
- provision (プロビジョニング)
- deprovision (プロビジョニング解除)
- bind (バインド)
- unbind (バインド解除)
- test (テスト)
アクションを有効にするには、playbooks/ ディレクトリーに <action>.yml という名前の有効なファイルがなければなりません。これらの Playbook はすべてのことを実行できる、つまり、希望するすべてのアクションを作成できます。たとえば、mediawiki-apb には update
アクションを作成する Playbook があります。
ほとんどの APB にはリソースを作成するためのプロビジョニングアクションと、サービスを削除する際にリソースを破棄するためのプロビジョニング解除アクションがあります。
バインドおよびバインド解除アクションは、1 つのサービスの位置情報 (coordinate) を別のサービスで利用可能にする必要がある場合に使用されます。通常、これはデータサービスを作成し、これをアプリケーションで利用可能にする場合に該当します。現時点では、この位置情報 (coordinate) はプロビジョニング時に利用可能になります。
位置情報 (coordinate) を別のサービスで適切に利用可能にするには、 asb_encode_binding モジュールを使用します。このモジュールは APB のプロビジョニングロールの最後に呼び出され、これは OpenShift Ansible Broker (OAB) にバインド認証情報を返します。
- name: encode bind credentials asb_encode_binding: fields: EXAMPLE_FIELD: foo EXAMPLE_FIELD2: foo2
3.2.6. 共通リソースの使用
このセクションでは、APB の開発時に作成される共通の OpenShift Container Platform リソースの一覧について説明します。利用可能なリソースモジュールの詳細の一覧については、「Ansible Kubernetes Module」を参照してください。
3.2.6.1. サービス
以下は、hello-world という名前のサービスを作成するためのサンプルの Ansible タスクです。APB の namespace
変数は Web コンソールから起動される場合に OAB によって提供されます。
プロビジョニング
- name: create hello-world service k8s_v1_service: name: hello-world namespace: '{{ namespace }}' labels: app: hello-world service: hello-world selector: app: hello-world service: hello-world ports: - name: web port: 8080 target_port: 8080
プロビジョニング解除
- k8s_v1_service: name: hello-world namespace: '{{ namespace }}' state: absent
3.2.6.2. デプロイメント設定
以下は、サービス hello-world にマップするイメージ docker.io/ansibleplaybookbundle/hello-world のデプロイメント設定を作成するサンプルの Ansible タスクです。
プロビジョニング
- name: create deployment config openshift_v1_deployment_config: name: hello-world namespace: '{{ namespace }}' labels: app: hello-world service: hello-world replicas: 1 selector: app: hello-world service: hello-world spec_template_metadata_labels: app: hello-world service: hello-world containers: - env: image: docker.io/ansibleplaybookbundle/hello-world:latest name: hello-world ports: - container_port: 8080 protocol: TCP
プロビジョニング解除
- openshift_v1_deployment_config: name: hello-world namespace: '{{ namespace }}' state: absent
3.2.6.3. ルート
以下は、サービス hello-world にマップする hello-world という名前のルートを作成する例です。
プロビジョニング
- name: create hello-world route openshift_v1_route: name: hello-world namespace: '{{ namespace }}' spec_port_target_port: web labels: app: hello-world service: hello-world to_name: hello-world
プロビジョニング解除
- openshift_v1_route: name: hello-world namespace: '{{ namespace }}' state: absent
3.2.6.4. 永続ボリューム
以下は、Persistent Volume Claim (PVC, 永続ボリューム要求) リソースとこれを使用するデプロイメント設定を作成する例です。
プロビジョニング
# Persistent volume resource - name: create volume claim k8s_v1_persistent_volume_claim: name: hello-world-db namespace: '{{ namespace }}' state: present access_modes: - ReadWriteOnce resources_requests: storage: 1Gi
リソースに加えて、ボリュームをデプロイメント設定の宣言に追加します。
- name: create hello-world-db deployment config openshift_v1_deployment_config: name: hello-world-db --- volumes: - name: hello-world-db persistent_volume_claim: claim_name: hello-world-db test: false triggers: - type: ConfigChange
プロビジョニング解除
- openshift_v1_deployment_config: name: hello-world-db namespace: '{{ namespace }}' state: absent - k8s_v1_persistent_volume_claim: name: hello-world-db namespace: '{{ namespace }}' state: absent
3.2.7. オプション変数
オプションの変数は、環境変数を使用して APB に追加できます。変数を APB に渡すには、.yml ファイルで変数置換をエスケープする必要があります。
たとえば、etherpad-apb の以下の roles/provision-etherpad-apb/tasks/main.yml ファイルについて見てみましょう。
- name: create mariadb deployment config openshift_v1_deployment_config: name: mariadb namespace: '{{ namespace }}' ... - env: - name: MYSQL_ROOT_PASSWORD value: '{{ mariadb_root_password }}' - name: MYSQL_DATABASE value: '{{ mariadb_name }}' - name: MYSQL_USER value: '{{ mariadb_user }}' - name: MYSQL_PASSWORD value: '{{ mariadb_password }}'
APB の変数は roles/provision-etherpad-apb/defaults/main.yml ファイルに定義されます。
playbook_debug: no mariadb_root_password: "{{ lookup('env','MYSQL_ROOT_PASSWORD') | default('admin', true) }}" mariadb_name: "{{ lookup('env','MYSQL_DATABASE') | default('etherpad', true) }}" mariadb_user: "{{ lookup('env','MYSQL_USER') | default('etherpad', true) }}" mariadb_password: "{{ lookup('env','MYSQL_PASSWORD') | default('admin', true) }}" etherpad_admin_password: "{{ lookup('env','ETHERPAD_ADMIN_PASSWORD') | default('admin', true) }}" etherpad_admin_user: "{{ lookup('env','ETHERPAD_ADMIN_USER') | default('etherpad', true) }}" etherpad_db_host: "{{ lookup('env','ETHERPAD_DB_HOST') | default('mariadb', true) }}" state: present
3.2.8. リモートクラスターの使用
APB の開発において、開発者が apb
ツールが提供する完全な開発ライフサイクルを使用できない状態になるいくつかの要因があります。これらの主な要因には、以下が含まれます。
- リモートホストにある OpenShift Container Platform クラスターに対して開発を行っている。
- docker デーモンへのアクセスがないマシンで APB を開発している。
開発者が上記のいずれかの条件を満たす場合は、以下のワークフローを使用してイメージを内部 OpenShift Container Platform レジストリーに公開し、ブローカーがイメージのブートストラップ (APB 仕様をブローカーに読み込むプロセス) を実行できるようにします。以下のセクションでは、apb
ツールを使用する場合と使用しない場合にこれらの手順を実行する方法について説明しています。
3.2.8.1. APB のプッシュ
リモートの OpenShift Container Platform クラスターを使って apb push
コマンドを使用するには、以下を実行します。
base64 エンコードされた APB 仕様が Dockerfile のラベルであることを確認します。これは、通常は
apb prepare
コマンドを使用して実行できます。apb
ツールがインストールされていない場合は、以下を実行できます。$ cat apb.yml | base64
base64 エンコードされた apb.yml を返します。これは、以下のように Dockerfile の
LABEL "com.redhat.apb.spec"
の下にコピーアンドペーストできます。LABEL "com.redhat.apb.spec"=\ "dmVyc2lvbjogMS4wCm5hbWU6IG1lZGlhd2lraS1hcGIKZGVzY3JpcHRpb246IE1lZGlhd2lraSBh\ cGIgaW1wbGVtZW50YXRpb24KYmluZGFibGU6IEZhbHNlCmFzeW5jOiBvcHRpb25hbAptZXRhZGF0\ YToKICBkb2N1bWVudGF0aW9uVXJsOiBodHRwczovL3d3dy5tZWRpYXdpa2kub3JnL3dpa2kvRG9j\ dW1lbnRhdGlvbgogIGxvbmdEZXNjcmlwdGlvbjogQW4gYXBiIHRoYXQgZGVwbG95cyBNZWRpYXdp\ a2kgMS4yMwogIGRlcGVuZGVuY2llczogWydkb2NrZXIuaW8vYW5zaWJsZXBsYXlib29rYnVuZGxl\ L21lZGlhd2lraTEyMzpsYXRlc3QnXQogIGRpc3BsYXlOYW1lOiBNZWRpYXdpa2kgKEFQQilmZGZk\ CiAgY29uc29sZS5vcGVuc2hpZnQuaW8vaWNvbkNsYXNzOiBpY29uLW1lZGlhd2lraQogIHByb3Zp\ ZGVyRGlzcGxheU5hbWU6ICJSZWQgSGF0LCBJbmMuIgpwbGFuczoKICAtIG5hbWU6IGRlZmF1bHQK\ ICAgIGRlc2NyaXB0aW9uOiBBbiBBUEIgdGhhdCBkZXBsb3lzIE1lZGlhV2lraQogICAgZnJlZTog\ VHJ1ZQogICAgbWV0YWRhdGE6CiAgICAgIGRpc3BsYXlOYW1lOiBEZWZhdWx0CiAgICAgIGxvbmdE\ ZXNjcmlwdGlvbjogVGhpcyBwbGFuIGRlcGxveXMgYSBzaW5nbGUgbWVkaWF3aWtpIGluc3RhbmNl\ IHdpdGhvdXQgYSBEQgogICAgICBjb3N0OiAkMC4wMAogICAgcGFyYW1ldGVyczoKICAgICAgLSBu\ YW1lOiBtZWRpYXdpa2lfZGJfc2NoZW1hCiAgICAgICAgZGVmYXVsdDogbWVkaWF3aWtpCiAgICAg\ ICAgdHlwZTogc3RyaW5nCiAgICAgICAgdGl0bGU6IE1lZGlhd2lraSBEQiBTY2hlbWEKICAgICAg\ ICBwYXR0ZXJuOiAiXlthLXpBLVpfXVthLXpBLVowLTlfXSokIgogICAgICAgIHJlcXVpcmVkOiBU\ cnVlCiAgICAgIC0gbmFtZTogbWVkaWF3aWtpX3NpdGVfbmFtZQogICAgICAgIGRlZmF1bHQ6IE1l\ ZGlhV2lraQogICAgICAgIHR5cGU6IHN0cmluZwogICAgICAgIHRpdGxlOiBNZWRpYXdpa2kgU2l0\ ZSBOYW1lCiAgICAgICAgcGF0dGVybjogIl5bYS16QS1aXSskIgogICAgICAgIHJlcXVpcmVkOiBU\ cnVlCiAgICAgICAgdXBkYXRhYmxlOiBUcnVlCiAgICAgIC0gbmFtZTogbWVkaWF3aWtpX3NpdGVf\ bGFuZwogICAgICAgIGRlZmF1bHQ6IGVuCiAgICAgICAgdHlwZTogc3RyaW5nCiAgICAgICAgdGl0\ bGU6IE1lZGlhd2lraSBTaXRlIExhbmd1YWdlCiAgICAgICAgcGF0dGVybjogIl5bYS16XXsyLDN9\ JCIKICAgICAgICByZXF1aXJlZDogVHJ1ZQogICAgICAtIG5hbWU6IG1lZGlhd2lraV9hZG1pbl91\ c2VyCiAgICAgICAgZGVmYXVsdDogYWRtaW4KICAgICAgICB0eXBlOiBzdHJpbmcKICAgICAgICB0\ aXRsZTogTWVkaWF3aWtpIEFkbWluIFVzZXIgKENhbm5vdCBiZSB0aGUgc2FtZSB2YWx1ZSBhcyBB\ ZG1pbiBVc2VyIFBhc3N3b3JkKQogICAgICAgIHJlcXVpcmVkOiBUcnVlCiAgICAgIC0gbmFtZTog\ bWVkaWF3aWtpX2FkbWluX3Bhc3MKICAgICAgICB0eXBlOiBzdHJpbmcKICAgICAgICB0aXRsZTog\ TWVkaWF3aWtpIEFkbWluIFVzZXIgUGFzc3dvcmQKICAgICAgICByZXF1aXJlZDogVHJ1ZQogICAg\ ICAgIGRpc3BsYXlfdHlwZTogcGFzc3dvcmQK"
内部 OpenShift Container Platform レジストリーにビルドされた APB イメージを設定します。
通常、これは
apb push
コマンドで処理されます。docker
CLI を使用せずにイメージをビルドするには、OpenShift Container Platform の S2I 機能を利用することができます。デフォルトで、OAB は openshift プロジェクトで公開済みの APB を検索するように設定されます。このプロジェクトは、クラスターのすべての認証ユーザーが利用できるようにイメージとイメージストリームを公開するグローバル namespace です。イメージをビルドするために、openshift プロジェクトで
oc new-app
コマンドを使用して、この利点を活用できます。$ oc new-app <path_to_bundle_source> \ --name <bundle_name> \ -n openshift
2 分ほど経過したら、イメージが内部レジストリーに表示されるはずです。
$ oc get images | grep <bundle_name> sha256:b2dcb4b95e178e9b7ac73e5ee0211080c10b24260f76cfec30b89e74e8ee6742 172.30.1.1:5000/openshift/<bundle_name>@sha256:b2dcb4b95e178e9b7ac73e5ee0211080c10b24260f76cfec30b89e74e8ee6742
OAB をブートストラップします。通常、これも
apb push
またはapb bootstrap
コマンドで処理されます。apb bootstrap
コマンドは 5 分から 10 分の待機時間なしにサービスカタログを再度一覧表示するため、このコマンドをこの手順で使用するのが適しています。apb
ツールがインストールされていない場合は、代わりに以下を実行できます。ブローカーのルート名を取得します。
$ oc get route -n openshift-ansible-service-broker NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD asb-1338 asb-1338-openshift-ansible-service-broker.172.17.0.1.nip.io asb port-1338 reencrypt None
ブローカーでサポートされているパスの一覧を取得します。
$ curl -H "Authorization: Bearer $(oc whoami -t)" -k \ https://asb-1338-openshift-ansible-service-broker.172.17.0.1.nip.io/ { "paths": [ "/apis", "/ansible-service-broker/", 1 "/healthz", "/healthz/ping", "/healthz/poststarthook/generic-apiserver-start-informers", "/metrics" ] }
- 1
- このパスは
v2/bootstrap
およびv2/catalog
パスを指定します。
直前の手順で検出される値を使用し、
v2/bootstrap
パスに対して curl 実行します。$ curl -H "Authorization: Bearer $(oc whoami -t)" -k -X POST \ https://asb-1338-openshift-ansible-service-broker.172.17.0.1.nip.io/ansible-service-broker/v2/bootstrap 1 { "spec_count": 38, "image_count": 109 }
- 1
- 直前の手順で検出される値と異なる場合には、
ansible-service-broker
を置き換えます。
注記oc whoami -t
コマンドはトークンを返し、認証ユーザーには「アクセスパーミッション」で説明されているパーミッションがなければなりません。
新規 APB が OAB に存在することを確認します。通常、これは
apb list
コマンドの機能になります。apb
ツールがインストールされていない場合、代わりに以下を実行できます。直前の
v2/bootstrap
の手順で収集されるルートおよびサポートされているパスと名前を使用して、v2/catalog
パスに対して curl を実行します。$ curl -H "Authorization: Bearer $(oc whoami -t)" -k \ https://asb-1338-openshift-ansible-service-broker.172.17.0.1.nip.io/ansible-service-broker/v2/catalog
ブートストラップされたすべての APB 仕様の一覧および
localregistry-<bundle_name>
のラベルが付けられたものが表示されるはずです。出力の形式が JSON であるため、|grep <bundle_name>
を使用して検索することができます。
3.2.8.2. APB の実行
リモートクラスターを使用する際に制限があるため、apb push
コマンドが正常に実行されるかどうかに依存せずに apb run
コマンドと同じ機能を使用する必要がある場合があります。apb run
の場合はアプリケーションのプロビジョニングを試行する前に apb push
を暗黙的に実行します。
この問題の回避策として、以下を実行します。
「APB のプッシュ」に説明される手順に従い、イメージを内部 OpenShift Container Platform レジストリーにプッシュします。イメージが存在している場合は、以下のように表示されるはずです。
$ oc get images | grep <bundle_name> sha256:bfaa73a5e15bf90faec343c7d5f8cc4f952987afdbc3f11a24c54c037528d2ed 172.30.1.1:5000/openshift/<bundle_name>@sha256:bfaa73a5e15bf90faec343c7d5f8cc4f952987afdbc3f11a24c54c037528d2ed
プロビジョニングを実行するには、
oc run
コマンドを使用して APB を起動します。$ oc new-project <target_namespace> $ oc create serviceaccount apb $ oc create rolebinding apb --clusterrole=admin --serviceaccount=<target_namespace>:apb $ oc run <pod_name> \ --env="POD_NAME=<pod_name>" \ --env="POD_NAMESPACE=<target_namespace>" \ --image=<pull_spec> \ 1 --restart=Never \ --attach=true \ --serviceaccount=apb \ -- <action> -e namespace=<target_namespace> -e cluster=openshift
- 1
- レジストリーは完全修飾ドメイン名 (FQDN) を決定するため、直前の手順で
oc get images
を実行する際に表示されるイメージのプル仕様を使用します。
3.2.9. 制限付き SCC の使用
OpenShift Container Platform イメージのビルド時に、アプリケーションを root ユーザーとして実行していないことは重要になります (可能な場合)。 制限付き SCC で実行される場合、アプリケーションのイメージはランダム UID で起動します。これは、アプリケーションフォルダーが root ユーザーで所有されている場合には問題を生じさせます。
この問題の適切な回避策として、ユーザーを root グループに追加し、アプリケーションフォルダーを root グループによって所有されるようにすることができます。任意のユーザー ID をサポートする方法についての詳細は、「OpenShift Container Platform-Specific Guidelines」を参照してください。
以下は、/usr/src で実行されるノードアプリケーションの Dockerfile の例です。このコマンドは、アプリケーションが /usr/src にインストールされ、関連付けられた環境変数が設定された後に実行されます。
ENV USER_NAME=haste \ USER_UID=1001 \ HOME=/usr/src RUN useradd -u ${USER_UID} -r -g 0 -M -d /usr/src -b /usr/src -s /sbin/nologin -c "<username> user" ${USER_NAME} \ && chown -R ${USER_NAME}:0 /usr/src \ && chmod -R g=u /usr/src /etc/passwd USER 1001
3.2.10. ConfigMap の APB 内での使用
Ansible モジュールのバグ対策として、Ansible から ConfigMaps を作成するために一時的な回避策を使用できます。
ConfigMaps の 1 つの一般的なユースケースとして、APB のパラメーターがアプリケーションまたはサービスの設定ファイル内で使用される場合があります。ConfigMap モジュールにより、ConfigMap を Pod にボリュームとしてマウントできます。これは設定ファイルを保存するために使用できます。この方法では、ConfigMap を APB パラメーターから作成するために Ansible の テンプレート モジュール機能を活用することもできます。
以下は、ボリュームとして Pod にマウントされた Jinja テンプレートから ConfigMap を作成する例です。
- name: Create hastebin config from template template: src: config.js.j2 dest: /tmp/config.js - name: Create hastebin configmap shell: oc create configmap haste-config --from-file=haste-config=/tmp/config.js <snip> - name: create deployment config openshift_v1_deployment_config: name: hastebin namespace: '{{ namespace }}' labels: app: hastebin service: hastebin replicas: 1 selector: app: hastebin service: hastebin spec_template_metadata_labels: app: hastebin service: hastebin containers: - env: image: docker.io/dymurray/hastebin:latest name: hastebin ports: - container_port: 7777 protocol: TCP volumeMounts: - mountPath: /usr/src/haste-server/config name: config - env: image: docker.io/modularitycontainers/memcached:latest name: memcached ports: - container_port: 11211 protocol: TCP volumes: - name: config configMap: name: haste-config items: - key: haste-config path: config.js
3.2.11. エラーメッセージのカスタマイズ
プロビジョニング呼び出しが失敗すると、デフォルトのエラーメッセージが Web コンソールに返されます。以下のようになります。
Error occurred during provision. Please contact administrator if the issue persists.
失敗した場合にトラブルシューティングに使用する詳細情報を提供するために、Web コンソールがチェックできる APB についてのカスタムエラーメッセージを作成し、これをユーザーに返せるようにすることができます。
Kubernetes は Pod が終了ログに対して致命的なイベントのログを記録できるようにします。ログファイルの場所は、Pod の仕様の terminationMessagePath
フィールドで設定され、デフォルトでは /dev/termination-log に設定されます。
OpenShift Container Platform 3.10 より、ブローカーはこの終了ログでファイルに書き込まれたメッセージの有無を確認し、その内容をサービスカタログに渡すようになりました。Web コンソールは失敗が発生するとこのメッセージを表示します。
Pod の終了メッセージについての詳細は、Kubernetes ドキュメントを参照してください。
以下は、CloudFormation テンプレートを使用して、これを APB で実行する方法の例について示しています。
- name: Writing Termination Message shell: echo "[CloudFormation Error] - {{ ansible_failed_result.msg }}" > /dev/termination-log - fail: msg="[APB Failed Plain - '{{ _apb_plan_id }}'] "
エラーが発生すると、このカスタムメッセージのサンプルは Pod が失敗する前にデフォルトの終了ログパスに書き込まれます。