2.5. Operator를 사용하여 OpenShift에서 3scale에 대한 배포 구성 옵션

절차

1. 삽입할 사용자 지정 환경을 정의하는 Lua 코드를 작성합니다. 예를 들어 다음 env1.lua 파일은 3scale 운영자가 모든 서비스에 대해 로드하는 사용자 지정 로깅 정책을 보여줍니다.

   local cjson = require('cjson')
   local PolicyChain = require('apicast.policy_chain')
   local policy_chain = context.policy_chain
   
   local logging_policy_config = cjson.decode([[
   {
     "enable_access_logs": false,
     "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.name}}"
   }
   ]])
   
   policy_chain:insert( PolicyChain.load_policy('logging', 'builtin', logging_policy_config), 1)
   
   return {
     policy_chain = policy_chain,
     port = { metrics = 9421 },
   }

2. 사용자 지정 환경을 정의하는 Lua 파일에서 시크릿을 생성합니다. 예를 들어 다음과 같습니다.

   $ oc create secret generic custom-env-1 --from-file=./env1.lua

   시크릿에는 여러 사용자 지정 환경이 포함될 수 있습니다. 사용자 지정 환경을 정의하는 각 파일에 대해 '-from-file 옵션을 지정합니다. Operator는 각 사용자 지정 환경을 로드합니다.

3. 방금 생성한 시크릿을 참조하는 APIManager CR(사용자 정의 리소스)을 정의합니다. 다음 예제에서는 사용자 지정 환경을 정의하는 시크릿을 참조하는 상대적 콘텐츠만 보여줍니다.

   apiVersion: apps.3scale.net/v1alpha1
   kind: APIManager
   metadata:
     name: apimanager-apicast-custom-environment
   spec:
     wildcardDomain: <desired-domain>
     apicast:
       productionSpec:
         customEnvironments:
           - secretRef:
               name: custom-env-1
       stagingSpec:
         customEnvironments:
           - secretRef:
               name: custom-env-1

   APIManager CR은 사용자 정의 환경을 정의하는 여러 시크릿을 참조할 수 있습니다. Operator는 각 사용자 지정 환경을 로드합니다.

4. 사용자 지정 환경을 추가하는 APIManager CR을 생성합니다. 예를 들어 다음과 같습니다.

   $ oc apply -f apimanager.yaml

절차

1. 하나의 사용자 지정 정책을 정의하는 파일에서 시크릿을 생성합니다. 예를 들어 다음과 같습니다.

   $ oc create secret generic my-first-custom-policy-secret \
    --from-file=./apicast-policy.json \
    --from-file=./init.lua \
    --from-file=./my-first-custom-policy.lua

   사용자 지정 정책이 두 개 이상 있는 경우 각 사용자 지정 정책에 대한 보안을 생성합니다. 보안에는 하나의 사용자 지정 정책만 포함될 수 있습니다.

2. 사용자 정의 정책이 포함된 각 보안을 참조하는 APIManager CR을 정의합니다. APIcast 스테이징 및 APIcast 프로덕션에 대해 동일한 시크릿을 지정할 수 있습니다. 다음 예제에서는 사용자 정의 정책이 포함된 보안을 참조하는 것과 관련된 콘텐츠만 보여줍니다.

   apiVersion: apps.3scale.net/v1alpha1
   kind: APIManager
   metadata:
     name: apimanager-apicast-custom-policy
   spec:
     apicast:
       stagingSpec:
         customPolicies:
           - name: my-first-custom-policy
             version: "0.1"
             secretRef:
               name: my-first-custom-policy-secret
           - name: my-second-custom-policy
             version: "0.1"
             secretRef:
               name: my-second-custom-policy-secret
       productionSpec:
         customPolicies:
           - name: my-first-custom-policy
             version: "0.1"
             secretRef:
               name: my-first-custom-policy-secret
           - name: my-second-custom-policy
             version: "0.1"
             secretRef:
               name: my-second-custom-policy-secret

   APIManager CR은 다른 사용자 정의 정책을 정의하는 여러 시크릿을 참조할 수 있습니다. Operator는 각 사용자 지정 정책을 로드합니다.

3. 사용자 정의 정책이 포함된 보안을 참조하는 APIManager CR을 생성합니다. 예를 들어 다음과 같습니다.

   $ oc apply -f apimanager.yaml

절차

1. stringData.config 에 OpenTracing 구성 세부 정보가 포함된 시크릿을 정의합니다. 이는 OpenTracing 구성 세부 정보가 포함된 속성에 대해 유일하게 유효한 값입니다. 다른 사양에서는 APIcast가 OpenTracing 구성 세부 정보를 수신하지 못하도록 합니다. 다음 예제에서는 유효한 보안 정의를 보여줍니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: myjaeger
   stringData:
     config: |-
         {
         "service_name": "apicast",
         "disabled": false,
         "sampler": {
           "type": "const",
           "param": 1
         },
         "reporter": {
           "queueSize": 100,
           "bufferFlushInterval": 10,
           "logSpans": false,
           "localAgentHostPort": "jaeger-all-in-one-inmemory-agent:6831"
         },
         "headers": {
           "jaegerDebugHeader": "debug-id",
           "jaegerBaggageHeader": "baggage",
           "TraceContextHeaderName": "uber-trace-id",
           "traceBaggageHeaderPrefix": "testctx-"
         },
         "baggage_restrictions": {
             "denyBaggageOnInitializationFailure": false,
             "hostPort": "127.0.0.1:5778",
             "refreshInterval": 60
         }
         }
   type: Opaque

2. 시크릿을 생성합니다. 예를 들어 이전 시크릿 정의를 myjaeger.yaml 파일에 저장한 경우 다음 명령을 실행합니다.

   $ oc create -f myjaeger.yaml

3. OpenTracing 특성을 지정하는 APIManager CR(사용자 정의 리소스)을 정의합니다. CR 정의에서 openTracing.tracingConfigSecretRef.name 속성을 OpenTracing 구성 세부 정보가 포함된 시크릿 이름으로 설정합니다. 다음 예제에서는 OpenTracing 구성을 기준으로 한 콘텐츠만 보여줍니다.

   apiVersion: apps.3scale.net/v1alpha1
   kind: APIManager
   metadata:
     name: apimanager1
   spec:
     apicast:
       stagingSpec:
         ...
         openTracing:
           enabled: true
           tracingLibrary: jaeger
           tracingConfigSecretRef:
             name: myjaeger
       productionSpec:
         ...
           openTracing:
             enabled: true
             tracingLibrary: jaeger
             tracingConfigSecretRef:
               name: myjaeger

4. OpenTracing을 구성하는 APIManager CR을 생성합니다. 예를 들어 APIManager CR을 apimanager1.yaml 파일에 저장한 경우 다음 명령을 실행합니다.

   $ oc apply -f apimanager1.yaml

절차

1. 유효한 인증서에서 보안을 생성합니다. 예를 들면 다음과 같습니다.

   $ oc create secret tls mycertsecret --cert=server.crt --key=server.key

   구성은 APIManager CR(사용자 정의 리소스)에 시크릿 참조를 노출합니다. 보안을 생성한 다음 다음과 같이 APIManager CR에서 시크릿 이름을 참조합니다.

   • production: APIManager CR은 .spec.apicast.productionSpec.httpsCertificateSecretRef 필드에 인증서를 노출합니다.

   • staging: APIManager CR은 .spec.apicast.stagingSpec.httpsCertificateSecretRef 필드에 인증서를 노출합니다.

     선택적으로 다음을 구성할 수 있습니다.

   • httpsPort 는 HTTPS 연결에서 수신 대기해야 하는 포트 APIcast를 나타냅니다. HTTP 포트 APIcast가 충돌하면 이 포트는 HTTPS용으로만 사용됩니다.

   • httpsVerifyDepth 는 클라이언트 인증서 체인의 최대 길이를 정의합니다.

     참고

     APIManager CR에서 유효한 인증서 및 참조를 제공합니다. 구성에서 httpsPort 에 액세스할 수 있지만 httpsCertificateSecretRef 는 액세스할 수 없는 경우 APIcast는 포함된 자체 서명된 인증서를 사용합니다. 이는 권장되지 않습니다.

2. Operators > 설치된 Operators를 클릭합니다.
3. 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
4. API Manager 탭을 클릭합니다.
5. APIManager 생성을 클릭합니다.

6. 편집기에 다음 YAML 정의를 추가합니다.

   1. 프로덕션에 대해 활성화하는 경우 다음 YAML 결함을 구성합니다.

      spec:
        apicast:
          productionSpec:
            httpsPort: 8443
            httpsVerifyDepth: 1
            httpsCertificateSecretRef:
              name: mycertsecret

   2. 스테이징 을 위해 활성화하는 경우 다음 YAML 결함을 구성합니다.

      spec:
        apicast:
          stagingSpec:
            httpsPort: 8443
            httpsVerifyDepth: 1
            httpsCertificateSecretRef:
              name: mycertsecret

7. 생성을 클릭합니다.

절차

1. 아직 로그인하지 않은 경우 OpenShift에 로그인합니다.

   $ oc login

2. oc patch 명령을 사용하여 secret 유형을 지정합니다. 여기서 system-smtp 는 보안의 이름 뒤에 -p 옵션 뒤에 다음 변수에 대해 JSON에 새 값을 작성합니다.

   표 2.2. system-smtp

   필드	설명	기본값
   address	이는 사용할 원격 메일 서버의 주소(hostname 또는 IP)입니다. 이 값이 "" 과 다른 값으로 설정된 경우 시스템은 메일 서버를 사용하여 API 관리 솔루션에서 발생하는 이벤트와 관련된 이메일을 보냅니다.	""
   port	이 포트는 사용할 원격 메일 서버의 포트입니다.	""
   domain	메일 서버에 HELO 도메인이 필요한 경우 domain을 사용합니다.	""
   인증	메일 서버에 인증이 필요한 경우 를 사용합니다. 암호 Base64 인코딩 또는 cram_md5 알고리즘을 기반으로 챌린지/응답 메커니즘을 결합하도록 authentication types: plain 에서 암호를 전송하도록 설정합니다.	""
   사용자 이름	메일 서버에 인증이 필요하고 인증 유형에 필요한 경우 사용자 이름을 사용합니다.	""
   암호	메일 서버에 인증이 필요하며 인증 유형에 필요한 경우 password 를 사용합니다.	""
   openssl.verify.mode	TLS를 사용할 때 OpenSSL이 인증서를 확인하는 방법을 설정할 수 있습니다. 이 기능은 자체 서명된 인증서 및/또는 와일드카드 인증서를 검증해야 하는 경우에 유용합니다. OpenSSL 확인 상수: none 또는 peer 이름을 사용할 수 있습니다.	""
   from_address	no-reply mail의 address 값 에서	""

   예

   $ oc patch secret system-smtp -p '{"stringData":{"address":"<your_address>"}}'
   $ oc patch secret system-smtp -p '{"stringData":{"username":"<your_username>"}}'
   $ oc patch secret system-smtp -p '{"stringData":{"password":"<your_password>"}}'

3. 보안 변수를 설정한 후 system-app 및 system-sidekiq Pod를 재배포합니다.

   $ oc rollout latest dc/system-app
   $ oc rollout latest dc/system-sidekiq

4. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

   $ oc rollout status dc/system-app
   $ oc rollout status dc/system-sidekiq