第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 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 仕様ファイルについての詳細は、参照のトピックを参照してください。ここでは、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
プロセス中に、プロビジョニングタスクの 2 つの部分が消去されました。Playbook playbooks/provision.yml および roles/provision-my-test-apb の関連ロール。
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
コマンドラインでサービスの情報を表示するには、以下を実行できます。
$ oc project getting-started $ oc get services $ oc describe services/my-test
describe
は、サービスにアクセスするために使用する IP アドレスを表示します。ただし、ユーザーがアプリケーションにアクセスするために IP アドレスを使用する方法は通常は理想的な方法ではありません。その代わりに、次のセクションで説明されるように route を作成する必要があります。
次に進む前にクリーンアップし、再度プロビジョニングを実行するために、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
, andDB_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 をプロビジョニングし、シークレットを作成する オプションを選択します。
- 次に、プロジェクトに移動します (まだの場合)。hello-world アプリケーションと PostgreSQL データベースの両方を確認できます。プロビジョニング時にバインディングを作成することを選択しなかった場合は、ここで バインディングの作成 リンクを使用してこれを実行できます。
バインディングが作成されたら、バインディングで作成されたシークレットをアプリケーションに追加する必要があります。まず、Resources
Secretsページでシークレットに移動します。 シークレットを環境変数として追加します。
これを追加したら、Overview ページに戻ることができます。my-test アプリケーションは依然として設定変更による再デプロイの実行中である可能性があります。その場合には、ルートをクリックしてアプリケーションを表示できるまで待機します。
ルートのクリック後に、hello-world アプリケーションが my-pg データベースを検出し、これに接続されていることを確認できます。
3.1.4.2.2. Test
テストアクションは、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 がエラー状態の場合は障害が生じたことを示し、コマンドはテストが不成功であったことを報告します。