検索

第3章 APB の作成

download PDF

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 を作成する前に、開発環境をセットアップする必要があります。

  1. OpenShift Container Platform クラスターにアクセスできることを確認します。クラスターはサービスカタログと、デフォルトでインストールされている OpenShift Ansible broker (OAB) の両方を実行している必要があります。
  2. APB ツールをCLI ツールのトピックで説明されているようにインストールします。検証するには、apb help コマンドを実行して、有効な応答の有無を確認します。
  3. リモートホストに存在する OpenShift Container Platform クラスターに対して開発を行っている場合や、docker デーモンにアクセスがない場合は、本書で説明されている apb push および apb run コマンドを使用する際の代替的な手順について、リモートクラスターの使用を参照してください。

3.1.3. APB の初回作成

このチュートリアルでは、コンテナー化された hello world アプリケーションの APB を作成します。ここでは、APB hello-world-apb をミラーリングする基本的な APB を扱います。

  1. 最初のタスクとして、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

  2. Dockerfile では、2 つの更新を実行します。

    1. FROM 命令を変更して、イメージを Red Hat Container Catalog から使用できるようにします。最初の行が表示されるはずです。

      FROM openshift3/apb-base
    2. 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

  3. この時点で、ビルド可能な完全に形成された APB が使用できるようになります。apb prepare の使用を省略した場合でも、apb build コマンドがイメージのビルド前に APB を作成します。

    $ apb build
  4. 新規の APB イメージをローカルの OpenShift Container レジストリーにプッシュできるようになります。

    $ apb push
  5. 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

以下のセクションで上記のアクションのそれぞれを追加していきます。開始前に、以下を確認してください。

  1. oc CLI 経由で OpenShift Container Platform クラスターにログインしている。この場合は、apb ツールが OpenShift Container Platform および OAB と対話できます。

    # oc login <cluster_host>:<port> -u <user_name> -p <password>
  2. OpenShift Container Platform Web コンソールにログインし、APB がカタログに一覧表示されていることを確認します。

    図3.1 OpenShift Container Platform Web コンソール

    browse catalog my test
  3. 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
1
この Playbook を検査します。
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 のプロビジョニング

provision my test

プロビジョニングの実行中、新規の namespace が dh-my-test-apb-prov-<random> という名前で作成されます。開発モードでは、これは永続しますが、通常この namespace は正常な完了後に削除されます。APB がプロビジョニングに失敗すると、デフォルトでは namespace は永続します。

Pod リソースを参照すると、ログで APB の実行を確認することができます。Pod のログを表示するには、以下を実行します。

  1. 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
  2. プロジェクトに切り替えます。

    $ oc project dh-my-test-apb-prov-<random>
    Now using project "dh-my-test-apb-prov-<random>" on server "<cluster_host>:<port>".
  3. Pod 名を取得します。

    $ oc get pods
    NAME             READY     STATUS      RESTARTS   AGE
    <apb_pod_name>   0/1       Completed   0          3m
  4. ログを表示します。

    $ 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 をデプロイできる必要があります。これは デプロイメント設定を指定して実行できます。

  1. 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
    1
    デプロイメント設定が置かれる必要のある namespace を指定します。
    2
    オブジェクトの編成、分類および選択に使用されます。
    3
    1 つの Pod のみを必要とするように指定します。
    4
    selector セクションは Pod に対する ラベルのクエリーです。
    5
    この containers セクションは、コンテナーを TCP のポート 8080 で実行される hello-world アプリケーションで指定します。イメージdocker.io/ansibleplaybookbundle/hello-world に保存されます。

    詳細については、APB の作成: 参照を参照してください。 また、すべてのフィールドの詳細については、ansible-kubernetes-modules ドキュメントを参照してください。

  2. APB をビルドし、プッシュします。

    $ apb build
    $ apb push
  3. Web コンソールを使用して APB をプロビジョニングします。
  4. プロビジョニングの後に、新規に実行される 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 を使用して負荷分散を行い、ユーザーがそれらに単一ホストとしてアクセスできるようにサービスを作成する必要になる場合があります。 以下を実行します。

  1. 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 モジュールを参照してください。

  2. APB をビルドし、プッシュします。

    $ apb build
    $ apb push
  3. 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 アドレスを使用する方法は通常は理想的な方法ではありません。その代わりに、次のセクションで説明されるように route を作成する必要があります。

ヒント

次に進む前にクリーンアップし、再度プロビジョニングを実行するために、getting-started プロジェクトを削除してから再作成するか、または新規のプロジェクトを作成することができます。

3.1.4.1.3. ルートの作成

アプリケーションへの外部アクセスは、信頼できる名前付きルートで公開できます。

  1. 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 モジュール を参照してください。

  2. APB をビルドし、プッシュします。

    $ apb build
    $ apb push
  3. 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
1
このファイルを検査します。
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 を参照してください。

  1. --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
    1
    bindable フラグは true に設定されます。
    2
    新規ファイル
    3
    新規ファイル
    4
    新規の空ファイル
    5
    エンコードされたバインド認証情報
    6
    新規の空ファイル

    通常ファイルのほかに、新規 Playbook bind.ymlunbind.yml、およびそれらの関連付けられたロールが表示されます。bind.yml および unbind.yml ファイルはどちらも空であり、デフォルトのバインド動作を使用しているために空のままになります。

  2. 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
  3. 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, and DB_NAME) として利用可能にします。これは、bind.yml ファイルが空のままの場合のデフォルトの動作です。すべてのアプリケーション (hello-world など) がこれらの環境変数を使用でき、バインド操作後に設定済みのデータベースに接続できます。

  4. 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
  5. 最後に APB をビルドし、プッシュします。

    $ apb build
    $ apb push

この時点で、APB は完全に機能する PostgreSQL データベースをクラスターに作成できます。これについては、次のセクションでテストできます。

3.1.4.2.1.2. UI からの実行

アプリケーションをテストするには、hello-world アプリケーションをプロビジョニングされた PostgreSQL データベースにバインドできます。このチュートリアルのプロビジョニング セクションで事前に作成されたアプリケーションを使用するか、または hello-world-apb を使用できます。

  1. まず、my-test-apb をプロビジョニングします。
  2. 次に、my-pg-apb をプロビジョニングし、シークレットを作成する オプションを選択します。

    provision my pg
    provision my pg params
    provision my pg binding
    provision my pg results
  3. 次に、プロジェクトに移動します (まだの場合)。hello-world アプリケーションと PostgreSQL データベースの両方を確認できます。プロビジョニング時にバインディングを作成することを選択しなかった場合は、ここで バインディングの作成 リンクを使用してこれを実行できます。
  4. バインディングが作成されたら、バインディングで作成されたシークレットをアプリケーションに追加する必要があります。まず、Resources Secretsページでシークレットに移動します。

    my pg nav secrets
    my pg secrets
  5. シークレットを環境変数として追加します。

    my pg add secret
    my pg add secret app
  6. これを追加したら、Overview ページに戻ることができます。my-test アプリケーションは依然として設定変更による再デプロイの実行中である可能性があります。その場合には、ルートをクリックしてアプリケーションを表示できるまで待機します。

    my pg overview

    ルートのクリック後に、hello-world アプリケーションが my-pg データベースを検出し、これに接続されていることを確認できます。

    my pg hello world
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

1
Ansible Kubernetes モジュールを読み込みます。
2
テストロールからプロビジョニングするために必要なデフォルト値を組み込みます。
3
実行するプロビジョニングロールを組み込みます。
4
実行する verify ロールを含めます。検証ロールの作成 を参照してください。
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 がエラー状態の場合は障害が生じたことを示し、コマンドはテストが不成功であったことを報告します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.