第5章 開発

手順

1. オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \
       --target ./ \
       --namespace test

   出力例

   Service 'event-display' created in namespace 'test'.

   • --target ./ フラグはオフラインモードを有効にし、./ を新しいディレクトリーツリーを保存するディレクトリーとして指定します。

     既存のディレクトリーを指定せずに、--target my-service.yaml などのファイル名を使用すると、ディレクトリーツリーは作成されません。代わりに、サービス記述子ファイル my-service.yaml のみが現在のディレクトリーに作成されます。

     ファイル名には、.yaml、.yml または .json 拡張子を使用できます。.json を選択すると、JSON 形式でサービス記述子ファイルが作成されます。

   • --namespace test オプションは、新規サービスを テスト namespace に配置します。

     --namespace を使用せずに、OpenShift クラスターにログインしている場合には、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルが default の namespace に作成されます。

2. 作成したディレクトリー構造を確認します。

   $ tree ./

   出力例

   ./
   └── test
       └── ksvc
           └── event-display.yaml
   
   2 directories, 1 file

   • --target で指定する現在の ./ ディレクトリーには新しい test/ ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。
   • test/ ディレクトリーには、リソースタイプの名前が付けられた ksvc ディレクトリーが含まれます。
   • ksvc ディレクトリーには、指定のサービス名に従って命名される記述子ファイル event-display.yaml が含まれます。

3. 生成されたサービス記述子ファイルを確認します。

   $ cat test/ksvc/event-display.yaml

   出力例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     creationTimestamp: null
     name: event-display
     namespace: test
   spec:
     template:
       metadata:
         annotations:
           client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
         creationTimestamp: null
       spec:
         containers:
         - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
           name: ""
           resources: {}
   status: {}

4. 新しいサービスに関する情報を一覧表示します。

   $ kn service describe event-display --target ./ --namespace test

   出力例

   Name:       event-display
   Namespace:  test
   Age:
   URL:
   
   Revisions:
   
   Conditions:
     OK TYPE    AGE REASON

   • --target ./ オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。

     または、--target オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml、.yml、および .json です。

   • --namespace オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーの kn と通信します。

     --namespace を使用せず、OpenShift クラスターにログインしている場合には、kn は現在の namespace をもとに名前が付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kn は default/ サブディレクトリーで検索します。

5. サービス記述子ファイルを使用してクラスターでサービスを作成します。

   $ kn service create -f test/ksvc/event-display.yaml

   出力例

   Creating service 'event-display' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "event-display" is waiting for a Revision to become ready.
    23.377s ...
    23.419s Ingress has not yet been reconciled.
    23.534s Waiting for load balancer to be ready
    23.723s Ready to serve.
   
   Service 'event-display' created to latest revision 'event-display-00001' is available at URL:
   http://event-display-test.apps.example.com

手順

1. 以下のサンプルコードを含む YAML ファイルを作成します。

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-delivery
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. YAML ファイルが含まれるディレクトリーに移動し、YAML ファイルを適用してアプリケーションをデプロイします。

   $ oc apply -f <filename>

手順

1. アプリケーション URL を検索します。

   $ oc get ksvc <service_name>

   コマンドの例

   $ oc get ksvc event-delivery

   出力例

   NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
   event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

2. クラスターに対して要求を実行し、出力を確認します。

   HTTP 要求の例

   $ curl http://event-delivery-default.example.com

   HTTPS 要求の例

   $ curl https://event-delivery-default.example.com

   出力例

   Hello Serverless!

3. オプション。証明書チェーンで自己署名証明書に関連するエラーが発生した場合は、curl コマンドに --insecure フラグを追加して、エラーを無視できます。

   $ curl https://event-delivery-default.example.com --insecure

   出力例

   Hello Serverless!

   重要

   自己署名証明書は、実稼働デプロイメントでは使用しないでください。この方法は、テスト目的にのみ使用されます。

4. オプション。OpenShift Container Platform クラスターが認証局 (CA) で署名されているが、システムにグローバルに設定されていない証明書で設定されている場合、curl コマンドでこれを指定できます。証明書へのパスは、--cacert フラグを使用して curl コマンドに渡すことができます。

   $ curl https://event-delivery-default.example.com --cacert <file>

   出力例

   Hello Serverless!

手順

1. アプリケーションホストを検索します。サーバーレスアプリケーションのデプロイメントの確認の説明を参照してください。

2. Ingress ゲートウェイのパブリックアドレスを見つけます。

   $ oc -n knative-serving-ingress get svc kourier

   出力例

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
   kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

   パブリックアドレスは EXTERNAL-IP フィールドで表示され、この場合は a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com になります。

3. HTTP 要求のホストヘッダーを手動でアプリケーションのホストに手動で設定しますが、Ingress ゲートウェイのパブリックアドレスに対して要求自体をダイレクトします。

   $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

   出力例

   Hello Serverless!

   Ingress ゲートウェイに対して要求を直接ダイレクトする間に、権限をアプリケーションのホストに設定して gRPC 要求を行うこともできます。

   grpc.Dial(
       "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
       grpc.WithAuthority("hello-default.example.com:80"),
       grpc.WithInsecure(),
   )

   注記

   直前の例のように、それぞれのポート (デフォルトでは 80) を両方のホストに追加します。

手順

1. アプリケーションへのアクセスを必要とする各 Knative システム namespace に knative.openshift.io/system-namespace=true ラベルを追加します。

   1. knative-serving namespace にラベルを付けます。

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true

   2. knative-serving-ingress namespace にラベルを付けます。

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true

   3. knative-eventing namespace にラベルを付けます。

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true

   4. knative-kafka namespace にラベルを付けます。

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true

2. アプリケーション namespace で NetworkPolicy オブジェクトを作成し、knative.openshift.io/system-namespace ラベルのある namespace からのアクセスを許可します。

   サンプル NetworkPolicy オブジェクト

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: <network_policy_name> 

   1

   
     namespace: <namespace> 

   2

   
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             knative.openshift.io/system-namespace: "true"
     podSelector: {}
     policyTypes:
     - Ingress

   1

   ネットワークポリシーの名前を指定します。

   2

   アプリケーションが存在する namespace。