검색

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

download PDF

이 섹션에서는 Operator를 사용하여 OpenShift에서 Red Hat 3scale API Management의 배포 구성 옵션에 대해 설명합니다.

사전 요구 사항

2.5.1. 내장된 APIcast에 대한 프록시 매개변수 구성

3scale 관리자는 내장된 APIcast 준비 및 프로덕션에 대한 프록시 매개변수를 구성할 수 있습니다. 이 섹션에서는 APIManager CR(사용자 정의 리소스)에서 프록시 매개변수를 지정하는 데 필요한 참조 정보를 제공합니다. 즉, APIManager CR인 3scale Operator를 사용하여 OpenShift에 3scale을 배포합니다.

APIManager CR을 처음 배포할 때 이러한 매개변수를 지정하거나 배포된 APIManager CR을 업데이트할 수 있으며 Operator에서 업데이트를 조정할 수 있습니다. APIManager 사용자 정의 리소스 배포를 참조하십시오.

내장된 APIcast의 프록시 관련 구성 매개변수는 다음 네 가지입니다.

  • allProxy
  • httpProxy
  • httpsProxy
  • noProxy

allProxy

allProxy 매개변수는 요청이 프로토콜별 프록시를 지정하지 않는 경우 서비스 연결에 사용할 HTTP 또는 HTTPS 프록시를 지정합니다.

프록시를 설정한 후 allProxy 매개변수를 프록시 주소로 설정하여 APIcast를 구성합니다. 프록시에서 인증이 지원되지 않습니다. 즉, APIcast는 인증된 요청을 프록시에 보내지 않습니다.

allProxy 매개변수의 값은 문자열이며, 기본값이 없으며 매개 변수는 필요하지 않습니다. spec.apicast.productionSpec.allProxy 매개변수 또는 spec.apicast.stagingSpec.allProxy 매개변수를 설정하려면 이 형식을 사용합니다.

<scheme>://<host>:<port>

예를 들어 다음과 같습니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
   name: example-apimanager
spec:
   apicast:
      productionSpec:
         allProxy: http://forward-proxy:80
      stagingSpec:
         allProxy: http://forward-proxy:81

httpProxy

httpProxy 매개변수는 HTTP 서비스 연결에 사용할 HTTP 프록시를 지정합니다.

프록시를 설정한 후 httpProxy 매개변수를 프록시 주소로 설정하여 APIcast를 구성합니다. 프록시에서 인증이 지원되지 않습니다. 즉, APIcast는 인증된 요청을 프록시에 보내지 않습니다.

httpProxy 매개변수의 값은 문자열이며, 기본값이 없으며 매개 변수는 필요하지 않습니다. spec.apicast.productionSpec.httpProxy 매개변수 또는 spec.apicast.stagingSpec.httpProxy 매개변수를 설정하려면 이 형식을 사용합니다.

http://<host>:<port>

예를 들어 다음과 같습니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
   name: example-apimanager
spec:
   apicast:
      productionSpec:
         httpProxy: http://forward-proxy:80
      stagingSpec:
         httpProxy: http://forward-proxy:81

httpsProxy

httpsProxy 매개변수는 서비스 연결에 사용할 HTTPS 프록시를 지정합니다.

프록시를 설정한 후 httpsProxy 매개변수를 프록시 주소로 설정하여 APIcast를 구성합니다. 프록시에서 인증이 지원되지 않습니다. 즉, APIcast는 인증된 요청을 프록시에 보내지 않습니다.

httpsProxy 매개변수의 값은 문자열이며, 기본값이 없으며 매개 변수는 필요하지 않습니다. spec.apicast.productionSpec.httpsProxy 매개변수 또는 spec.apicast.stagingSpec.httpsProxy 매개변수를 설정하려면 이 형식을 사용합니다.

https://<host>:<port>

예를 들어 다음과 같습니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
   name: example-apimanager
spec:
   apicast:
      productionSpec:
         httpsProxy: https://forward-proxy:80
      stagingSpec:
         httpsProxy: https://forward-proxy:81

noProxy

noProxy 매개변수는 쉼표로 구분된 호스트 이름과 도메인 이름을 지정합니다. 요청에 이러한 이름 중 하나가 포함되어 있으면 APIcast에서 요청을 프록시하지 않습니다.

프록시에 대한 액세스를 중지해야 하는 경우(예: 유지 관리 작업 중) noProxy 매개변수를 별표(*)로 설정합니다. 이는 모든 요청에 지정된 모든 호스트와 일치하며 프록시를 효과적으로 비활성화합니다.

noProxy 매개변수의 값은 문자열이며, 기본값이 없으며 매개 변수는 필요하지 않습니다. spec.apicast.productionSpec.noProxy 매개변수 또는 spec.apicast.stagingSpec.noProxy 매개변수를 설정하려면 쉼표로 구분된 문자열을 지정합니다. 예를 들어 다음과 같습니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
   name: example-apimanager
spec:
   apicast:
      productionSpec:
         noProxy: theStore,company.com,big.red.com
      stagingSpec:
         noProxy: foo,bar.com,.extra.dot.com

2.5.2. 3scale Operator를 사용하여 사용자 지정 환경 삽입

포함된 APIcast를 사용하는 3scale 설치에서는 3scale 연산자를 사용하여 사용자 정의 환경을 삽입할 수 있습니다. 임베디드 APIcast는 관리 또는 호스팅 APIcast라고도 합니다. 사용자 지정 환경은 게이트웨이가 제공하는 모든 업스트림 API에 APIcast가 적용되는 동작을 정의합니다. 사용자 지정 환경을 만들려면 Lua 코드에서 글로벌 구성을 정의합니다.

3scale 설치 전이나 후에 사용자 지정 환경을 삽입할 수 있습니다. 사용자 지정 환경을 삽입한 후 3scale 설치 후 사용자 지정 환경을 제거할 수 있습니다. 3scale Operator는 변경 사항을 조정합니다.

사전 요구 사항

  • 3scale Operator가 설치되어 있습니다.

절차

  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

다음 단계

사용자 지정 환경을 정의하는 보안의 콘텐츠를 업데이트할 수 없습니다. 사용자 지정 환경을 업데이트해야 하는 경우 다음 중 하나를 수행할 수 있습니다.

  • 권장 옵션은 다른 이름으로 시크릿을 생성하고 APIManager (CR) 필드인 customEnvironments[].secretRef.name 을 업데이트하는 것입니다. Operator는 롤링 업데이트를 트리거하고 업데이트된 사용자 지정 환경을 로드합니다.
  • 또는 spec.apicast.productionSpec.replicas 또는 spec.apicast.stagingSpec.replicas 를 0으로 설정한 다음 spec.apicast.productionSpec.replicas 또는 spec.apicast.stagingSpec.replicas 를 이전 값으로 설정하여 APIcast를 다시 배포하여 기존 보안을 업데이트할 수 있습니다.

2.5.3. 3scale Operator를 사용하여 사용자 정의 정책 삽입

내장 APIcast를 사용하는 3scale 설치에서는 3scale Operator를 사용하여 사용자 지정 정책을 삽입할 수 있습니다. 임베디드 APIcast는 관리 또는 호스팅 APIcast라고도 합니다. 사용자 지정 정책을 삽입하면 정책 코드가 APIcast에 추가됩니다. 그런 다음 다음 중 하나를 사용하여 API 제품의 정책 체인에 사용자 지정 정책을 추가할 수 있습니다.

  • 3scale API
  • Product CR(사용자 정의 리소스)

3scale 관리 포털을 사용하여 제품의 정책 체인에 사용자 정의 정책을 추가하려면 사용자 정의 정책의 스키마를 CustomPolicyDefinition CR에 등록해야 합니다. 사용자 지정 정책 등록은 관리 포털을 사용하여 제품의 정책 체인을 구성하려는 경우에만 필요합니다.

3scale 설치 후 또는 의 일부로 사용자 지정 정책을 삽입할 수 있습니다. 사용자 지정 정책을 삽입한 후 3scale 설치 후 APIManager CR에서 사양을 제거하여 사용자 지정 정책을 제거할 수 있습니다. 3scale Operator는 변경 사항을 조정합니다.

사전 요구 사항

  • 3scale Operator를 설치하거나 이전에 설치했습니다.
  • 자체 정책 쓰기에 설명된 대로 사용자 지정 정책을 정의했습니다. 즉, 사용자 지정 정책을 정의하는 my-policy.lua, apicast-policy.json, init.lua 파일이 이미 생성되었습니다.

절차

  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

다음 단계

사용자 정의 정책을 정의하는 시크릿 콘텐츠를 업데이트할 수 없습니다. 사용자 지정 정책을 업데이트해야 하는 경우 다음 중 하나를 수행할 수 있습니다.

  • 권장 옵션은 다른 이름으로 시크릿을 생성하고 새 보안을 참조하도록 APIManager CR customPolicies 섹션을 업데이트하는 것입니다. Operator는 롤링 업데이트를 트리거하고 업데이트된 사용자 지정 정책을 로드합니다.
  • 또는 spec.apicast.productionSpec.replicas 또는 spec.apicast.stagingSpec.replicas 를 0으로 설정한 다음 spec.apicast.productionSpec.replicas 또는 spec.apicast.stagingSpec.replicas 를 이전 값으로 설정하여 APIcast를 다시 배포하여 기존 보안을 업데이트할 수 있습니다.

2.5.4. 3scale Operator로 OpenTracing 구성

내장 APIcast를 사용하는 3scale 설치에서는 3scale Operator를 사용하여 OpenTracing을 구성할 수 있습니다. 스테이징 또는 프로덕션 환경에서 또는 두 환경 모두에서 OpenTracing을 구성할 수 있습니다. OpenTracing을 활성화하면 APIcast 인스턴스에 대한 더 많은 통찰력과 가시성을 얻을 수 있습니다.

절차

  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

다음 단계

OpenTracing이 설치된 방법에 따라 Jaeger 서비스 사용자 인터페이스에 추적이 표시되어야 합니다.

2.5.5. 3scale Operator를 사용하여 Pod 수준에서 TLS 활성화

3scale은 두 개의 APIcast 인스턴스를 배포합니다. 하나는 프로덕션용이고 다른 하나는 스테이징용입니다. 프로덕션 또는 스테이징만 또는 두 인스턴스에만 TLS를 활성화할 수 있습니다.

사전 요구 사항

  • TLS를 활성화하는 데 유효한 인증서입니다.

절차

  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. 생성을 클릭합니다.

2.5.6. 평가 배포에 대한 개념 증명

다음 섹션에서는 3scale 평가 배포에 대한 개념 증명에 적용되는 구성 옵션에 대해 설명합니다. 이 배포에서는 내부 데이터베이스를 기본값으로 사용합니다.

중요

외부 데이터베이스의 구성은 프로덕션 환경의 표준 배포 옵션입니다.

2.5.6.1. 기본 배포 구성

  • 컨테이너에 Kubernetes 리소스 제한 및 요청이 있습니다.

    • 이는 최소 성능 수준을 보장합니다.
    • 리소스를 제한하여 외부 서비스 및 솔루션 할당을 허용합니다.
  • 내부 데이터베이스를 배포합니다.
  • 파일 스토리지는 지속성 볼륨(PV)을 기반으로 합니다.

    • 하나는 읽기, 쓰기, 실행(RWX) 액세스 모드가 필요합니다.
    • OpenShift는 요청 시 이를 제공하도록 구성되어 있습니다.
  • MySQL을 내부 관계형 데이터베이스로 배포합니다.

기본 구성 옵션은 PoC(Proof of concept) 또는 고객의 평가에 적합합니다.

APIManager CR의 특정 필드 값으로 기본 구성 옵션 중 하나 또는 모든 기본 구성 옵션을 덮어쓸 수 있습니다. 3scale Operator는 사용 가능한 모든 조합을 허용합니다.

2.5.6.2. 평가 설치

평가 설치의 경우 컨테이너에 kubernetes 리소스 제한 및 요청이 지정되지 않습니다. 예를 들어 다음과 같습니다.

  • 작은 메모리 공간
  • 빠른 시작
  • 랩탑에서 실행 가능
  • 사전 판매 / 판매 데모에 적합
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  wildcardDomain: lvh.me
  resourceRequirementsEnabled: false

추가 리소스

  • 자세한 내용은 APIManager CR을 참조하십시오.

2.5.7. 외부 데이터베이스 설치

중요

Red Hat 3scale API Management 배포에서 데이터베이스를 외부화하는 경우 애플리케이션에서 격리하고 데이터베이스 수준에서 서비스 중단에 대한 탄력성을 제공합니다. 서비스 중단에 대한 탄력성은 데이터베이스를 호스팅하는 인프라 또는 플랫폼 공급자가 제공하는 SLA(서비스 수준 계약)에 따라 다릅니다. 이는 3scale에서 제공되지 않습니다. 선택한 배포에서 제공하는 데이터베이스를 외부화하는 방법에 대한 자세한 내용은 관련 문서를 참조하십시오.

외부 데이터베이스 설치는 중단없는 가동 시간을 제공하거나 자체 데이터베이스를 재사용하려는 프로덕션에 적합합니다.

중요

3scale 외부 데이터베이스 설치 모드를 활성화할 때 다음 데이터베이스 중 하나 이상을 3scale 외부로 구성할 수 있습니다.

  • backend-redis
  • system-redis
  • system-database (mysql,postgresql 또는 Oracle)
  • zync-database

3scale을 배포하기 위해 APIManager CR을 생성하기 전에 OpenShift 시크릿을 사용하여 외부 데이터베이스에 대해 다음 연결 설정을 제공해야 합니다.

2.5.7.1. 백엔드 Redis 시크릿

다음 예와 같이 두 개의 외부 Redis 인스턴스를 배포하고 연결 설정을 작성합니다.

apiVersion: v1
kind: Secret
metadata:
  name: backend-redis
stringData:
  REDIS_STORAGE_URL: "redis://backend-redis-storage"
  REDIS_STORAGE_SENTINEL_HOSTS: "redis://sentinel-0.example.com:26379,redis://sentinel-1.example.com:26379, redis://sentinel-2.example.com:26379"
  REDIS_STORAGE_SENTINEL_ROLE: "master"
  REDIS_QUEUES_URL: "redis://backend-redis-queues"
  REDIS_QUEUES_SENTINEL_HOSTS: "redis://sentinel-0.example.com:26379,redis://sentinel-1.example.com:26379, redis://sentinel-2.example.com:26379"
  REDIS_QUEUES_SENTINEL_ROLE: "master"
type: Opaque

시크릿 이름은 backend-redis 여야 합니다.

2.5.7.2. 시스템 Redis 시크릿

다음 예와 같이 두 개의 외부 Redis 인스턴스를 배포하고 연결 설정을 작성합니다.

apiVersion: v1
kind: Secret
metadata:
  name: system-redis
stringData:
  URL: "redis://system-redis"
  SENTINEL_HOSTS: "redis://sentinel-0.example.com:26379,redis://sentinel-1.example.com:26379, redis://sentinel-2.example.com:26379"
  SENTINEL_ROLE: "master"
  NAMESPACE: ""
type: Opaque

시크릿이름은 system-redis 여야 합니다.

2.5.7.3. 시스템 데이터베이스 시크릿

참고
  • 시크릿이름은 system-database 여야 합니다.

3scale을 배포할 때 시스템 데이터베이스에 대한 세 가지 대안이 있습니다. 각 대체의 관련 보안에 대해 서로 다른 속성 및 값을 구성합니다.

  • MySQL
  • PostgreSQL
  • Oracle Database

MySQL, PostgreSQL 또는 Oracle Database 시스템 데이터베이스 시크릿을 배포하려면 다음 예와 같이 연결 설정을 작성합니다.

MySQL 시스템 데이터베이스 시크릿

apiVersion: v1
kind: Secret
metadata:
  name: system-database
stringData:
  URL: "mysql2://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
type: Opaque

중요

3scale 2.12와 함께 MySQL 8.0을 사용하는 경우 인증 플러그인을 mysql_native_password로 설정해야 합니다. MySQL 구성 파일에 다음을 추가합니다.

[mysqld]
default_authentication_plugin=mysql_native_password

PostgreSQL 시스템 데이터베이스 시크릿

apiVersion: v1
kind: Secret
metadata:
  name: system-database
stringData:
  URL: "postgresql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
type: Opaque

Oracle 시스템 데이터베이스 시크릿

apiVersion: v1
kind: Secret
metadata:
  name: system-database
stringData:
  URL: "oracle-enhanced://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
  ORACLE_SYSTEM_PASSWORD: "{SYSTEM_PASSWORD}"
type: Opaque

참고

2.5.7.4. Zync 데이터베이스 시크릿

zync 데이터베이스 설정에서 spec.externalmanifests.zync.database 필드가 true로 설정된 경우 3scale을 배포하기 전에 zync라는 시크릿을 생성해야 합니다. 이 시크릿에서 DATABASE_URLDATABASE_PASSWORD 필드를 외부 zync 데이터베이스를 가리키는 값으로 설정합니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Secret
metadata:
  name: zync
stringData:
  DATABASE_URL: postgresql://<zync-db-user>:<zync-db-password>@<zync-db-host>:<zync-db-port>/zync_production
  ZYNC_DATABASE_PASSWORD: <zync-db-password>
type: Opaque

zync 데이터베이스는 고가용성 모드여야 합니다.

2.5.7.5. 3scale을 배포하기 위한 APIManager 사용자 정의 리소스

참고
  • 외부 구성 요소를 활성화하는 경우 3scale을 배포하기 전에 각 외부 구성 요소 (backend-redis system-redis,system-database,zync)에 대한 시크릿을 생성해야 합니다.
  • 외부 system-database의 경우 외부화할 하나의 데이터베이스 유형만 선택합니다.

APIManager CR(사용자 정의 리소스)의 구성은 선택한 데이터베이스가 3scale 배포 외부에 있는지 여부에 따라 달라집니다.

backend-redis,system-redis 또는 system-database 가 3scale 외부에 있는 경우 다음 예와 같이 APIManager CR externalComponents 오브젝트를 채웁니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  wildcardDomain: lvh.me
  externalComponents:
    system:
      database: true

2.5.8. 3scale Operator에서 Pod 유사성 활성화

모든 구성 요소에 대해 3scale Operator에서 Pod 기능을 활성화할 수 있습니다. 이렇게 하면 클러스터의 서로 다른 노드에 있는 각 deploymentConfig 에서 Pod 복제본이 배포되므로 AZ(가용성 영역) 간에 균등하게 분산됩니다.

2.5.8.1. 구성 요소 수준에서 노드 유사성 및 허용 오차 사용자 정의

APIManager CR 속성을 통해 3scale 솔루션의 kubernetes 선호도허용 오차 를 사용자 지정합니다. 그런 다음 kubernetes 노드에 다른 3scale 구성 요소를 예약하도록 사용자 지정할 수 있습니다.

예를 들어 backend-listenersystem-memcached 에 대한 사용자 정의 허용 오차에 대한 사용자 정의 노드 유사성을 설정하려면 다음을 수행합니다.

사용자 정의 유사성 및 허용 오차

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  backend:
    listenerSpec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "kubernetes.io/hostname"
                operator: In
                values:
                - ip-10-96-1-105
              - key: "beta.kubernetes.io/arch"
                operator: In
                values:
                - amd64
  system:
    memcachedTolerations:
    - key: key1
      value: value1
      operator: Equal
      effect: NoSchedule
    - key: key2
      value: value2
      operator: Equal
      effect: NoSchedule

다음 affinity 블록을 apicastProductionSpec 또는 비 데이터베이스 deploymentConfig 에 추가합니다. 그러면 preferredDuringSchedulingIgnoredDuringExecution 를 사용하여 소프트 podAntiAffinity 구성이 추가됩니다. 스케줄러는 다른 AZ의 다른 호스트에서 이 apicast-production Pod 세트를 실행하려고 합니다. 불가능한 경우 다른 위치에서 실행할 수 있도록 허용하십시오.

소프트 podAntiAffinity

affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    deploymentConfig: apicast-production
                topologyKey: kubernetes.io/hostname
            - weight: 99
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    deploymentConfig: apicast-production
                topologyKey: topology.kubernetes.io/zone

다음 예에서는 requiredDuringSchedulingIgnoredDuringExecution 를 사용하여 하드 podAntiAffinity 구성이 설정됩니다. 노드에 Pod를 예약하려면 조건을 충족해야 합니다. 예를 들어 사용 가능한 리소스가 낮은 클러스터에서 새 Pod를 예약할 수 없는 위험이 있습니다.

하드 podAntiAffinity

affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    deploymentConfig: apicast-production
                topologyKey: kubernetes.io/hostname
            - weight: 99
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    deploymentConfig: apicast-production
                topologyKey: topology.kubernetes.io/zone

추가 리소스

선호도 및 허용 오차와 관련된 전체 속성 목록은 APIManager CDR 참조에서 확인하십시오.

2.5.9. 여러 가용성 영역에 있는 여러 클러스터

참고

오류가 발생하는 경우 수동 클러스터를 활성 모드로 전환하면 절차가 완료될 때까지 서비스 프로비저닝이 중단됩니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.

이 문서에서는 AWS(Amazon Web Services)를 사용한 배포에 중점을 둡니다. 동일한 구성 옵션은 공급자의 관리 데이터베이스 서비스 제공(예: 여러 가용성 영역 및 여러 지역에 대한 지원 등)을 제공하는 다른 퍼블릭 클라우드 공급업체에 적용됩니다.

여러 OpenShift 클러스터 및 HA(고가용성) 영역에 3scale을 설치하려는 경우 여기에서 참조할 수 있는 옵션을 사용할 수 있습니다.

여러 클러스터 설치 옵션에서 클러스터는 몇 가지 수동 단계와 관련된 장애 조치 절차에 따라 활성/수동 구성으로 작동합니다.

2.5.9.1. 여러 클러스터 설치의 사전 요구 사항

여러 OpenShift 클러스터를 사용하는 3scale 설치에서 다음을 사용합니다.

  • APIManager CR(사용자 정의 리소스)에서 kubernetes.io/hostnametopology.kubernetes.io/zone 규칙과 함께 Pod 기능을 사용합니다.
  • APIManager CR에서 Pod 중단 예산을 사용합니다.
  • 여러 클러스터에 대한 3scale 설치는 APIManager CR에서 동일한 공유 wildcardDomain 특성 사양을 사용해야 합니다. 데이터베이스에 저장된 정보가 충돌하므로 각 클러스터에 대해 다른 도메인을 사용할 수 없습니다.
  • 동일한 값이 있는 모든 클러스터에 토큰 및 암호와 같은 인증 정보가 포함된 보안을 수동으로 배포해야 합니다. 3scale Operator는 모든 클러스터에서 보안 임의 값으로 생성합니다. 이 경우 두 클러스터에 동일한 인증 정보가 있어야 합니다. 보안 목록과 3scale Operator 설명서에서 구성하는 방법을 확인할 수 있습니다. 다음은 두 클러스터에서 미러링해야 하는 시크릿 목록입니다.

    • backend-internal-api
    • system-app
    • system-events-hook
    • system-master-apicast
    • system-seed

      backend-redis,system-redis,system-databasezync 의 데이터베이스 연결 문자열을 사용하여 시크릿을 수동으로 배포해야 합니다. 외부 데이터베이스 설치를 참조하십시오.

    • 클러스터에서 공유되는 데이터베이스는 모든 클러스터에서 동일한 값을 사용해야 합니다.
    • 각 클러스터에 자체 데이터베이스가 있는 경우 각 클러스터에서 다른 값을 사용해야 합니다.

2.5.9.2. 공유 데이터베이스가 있는 동일한 리전의 활성-패시브 클러스터

이 설정은 동일한 지역에 두 개 이상의 클러스터를 보유하고 활성-패시브 모드로 3scale을 배포하는 것으로 구성됩니다. 한 클러스터가 활성 상태이고 트래픽을 수신하며 다른 클러스터는 트래픽을 수신하지 않고 대기 모드이므로 active 클러스터에 오류가 있는 경우 활성 역할을 가정할 수 있습니다.

이 설치 옵션에서는 단일 리전만 사용 중이며 모든 클러스터에서 데이터베이스가 공유됩니다.

공유 데이터베이스가 있는 동일한 리전에서 3scale High Availability active-passive

2.5.9.3. 공유 데이터베이스 구성 및 설치

절차

  1. 다른 가용성 영역(AZ)을 사용하여 동일한 리전에 두 개 이상의 OpenShift 클러스터를 생성합니다. 최소 3개의 영역이 권장됩니다.
  2. Amazon RDS(Dataal Database Service) Multi-AZ가 활성화된 모든 필수 AWS ElastiCache(EC) 인스턴스를 생성합니다.

    1. Backend Redis 데이터베이스용 AWS EC 1개
    2. System Redis 데이터베이스용 AWS EC 1개
  3. Amazon RDS Multi-AZ가 활성화된 모든 AWS RDS 인스턴스를 생성합니다.

    1. 시스템 데이터베이스용 AWS RDS 1개
    2. Zync 데이터베이스용 AWS RDS 1개
  4. 시스템 자산에 대한 AWS S3 버킷을 구성합니다.
  5. AWS Route53 또는 DNS 공급자에 사용자 지정 도메인을 생성하고 활성 클러스터의 OpenShift 라우터를 가리킵니다. APIManager CR(사용자 정의 리소스)의 wildcardDomain 속성과 일치해야 합니다.
  6. 수동 클러스터에 3scale을 설치합니다. APIManager CR은 이전 단계에서 사용한 것과 동일해야 합니다. 모든 Pod가 실행 중인 경우 APIManager 를 변경하여 모든 백엔드,시스템,zyncAPIcast Pod에 0개의 복제본을 배포합니다.

    1. 활성 데이터베이스의 작업 사용을 방지하려면 복제본을 0으로 설정합니다. 각 복제본이 처음에 0으로 설정된 경우 Pod 종속성으로 인해 배포가 실패합니다. 예를 들어 Pod는 다른 사용자가 실행 중인지 확인합니다. 먼저 normal으로 배포한 다음 APIManager 사양 예에 표시된 대로 복제본을 0으로 설정합니다.

      spec:
        apicast:
          stagingSpec:
            replicas: 0
          productionSpec:
            replicas: 0
        backend:
          listenerSpec:
            replicas: 0
          workerSpec:
            replicas: 0
          cronSpec:
            replicas: 0
        zync:
          appSpec:
            replicas: 0
          queSpec:
            replicas: 0
        system:
          appSpec:
            replicas: 0
          sidekiqSpec:
            replicas: 0

2.5.9.4. 수동 장애 조치 공유 데이터베이스

절차

  1. 활성 클러스터에서 백엔드,시스템,zyncAPIcast Pod의 복제본을 0으로 축소합니다.

    1. 이는 새로운 수동 클러스터가 되어 새로운 수동 클러스터가 활성 데이터베이스의 작업을 사용하지 않도록 합니다. 다운타임은 여기에서 시작됩니다.
  2. 수동 클러스터에서 APIManager 를 편집하여 백엔드,시스템,zync, APIcast Pod의 복제본을 0으로 설정하여 활성 클러스터가 되도록 합니다.
  3. 새 활성 클러스터에서 zync 에서 생성한 OpenShift 경로를 다시 생성합니다.

    1. system-app Pod의 system-master 컨테이너에서 zync:resync:domains 명령을 실행합니다.

      bundle exec rake zync:resync:domains
  4. AWS Route53에서 생성된 사용자 정의 도메인을 새 활성 클러스터의 OpenShift 라우터를 지정합니다.

    1. 이전 패시브 클러스터는 트래픽을 수신하기 시작하고 새 활성 클러스터가 됩니다.

2.5.9.5. 동기화된 데이터베이스가 있는 다른 리전의 활성-패시브 클러스터

이 설정은 다른 지역에 두 개 이상의 클러스터가 있고 활성 모드에서 3scale을 배포하는 것으로 구성됩니다. 한 클러스터가 활성 상태이고 트래픽을 수신하며 다른 클러스터는 트래픽을 수신하지 않고 대기 모드이므로 active 클러스터에 오류가 있는 경우 활성 역할을 가정할 수 있습니다.

좋은 데이터베이스 액세스 대기 시간을 보장하기 위해 각 클러스터에는 자체 데이터베이스 인스턴스가 있습니다. 활성 3scale 설치의 데이터베이스는 3scale 수동 설치의 read-replica 데이터베이스에 복제되므로 가능한 장애 조치(failover)를 위해 데이터를 사용할 수 있고 모든 리전에서 최신 상태로 유지됩니다.

동기화된 데이터베이스가 있는 다른 리전의 3scale High Availability Active-passive 클러스터

2.5.9.6. 동기화된 데이터베이스 구성 및 설치

절차

  1. 다른 가용성 영역을 사용하여 다른 지역에 두 개 이상의 OpenShift 클러스터를 생성합니다. 최소 3개의 영역이 권장됩니다.
  2. 모든 리전에서 Amazon RDS Multi-AZ가 활성화된 모든 AWS ElastiCache 인스턴스를 생성합니다.

    1. 백엔드 Redis 데이터베이스를 위한 AWS EC 2개(지역당 하나씩)
    2. System Redis 데이터베이스용 AWS EC 두 개: 리전당 1개
    3. 글로벌 데이터 저장소 기능이 활성화된 상태에서 지역 간 복제를 사용하므로 수동 지역의 데이터베이스는 활성 리전의 마스터 데이터베이스에서 읽기-복제본입니다.
  3. 모든 리전에서 Amazon RDS Multi-AZ가 활성화된 상태에서 필요한 모든 AWS RDS 인스턴스를 생성합니다.

    1. 시스템 데이터베이스용 AWS RDS 2개
    2. Zync 데이터베이스용 AWS RDS 2개
    3. 지역 간 복제를 사용하므로 수동 리전의 데이터베이스는 활성 리전의 마스터 데이터베이스에서 읽기-복제본입니다.
  4. 리전 간 복제를 사용하여 모든 리전에서 시스템 자산에 대한 AWS S3 버킷을 구성합니다.
  5. AWS Route53 또는 DNS 공급자에 사용자 지정 도메인을 생성하고 활성 클러스터의 OpenShift 라우터를 가리킵니다. APIManager CR의 wildcardDomain 속성과 일치해야 합니다.
  6. 수동 클러스터에 3scale을 설치합니다. APIManager CR은 이전 단계에서 사용한 것과 동일해야 합니다. 모든 Pod가 실행 중인 경우 APIManager 를 변경하여 모든 백엔드,시스템,zyncAPIcast Pod에 0개의 복제본을 배포합니다.

    1. 활성 데이터베이스의 작업 사용을 방지하려면 복제본을 0으로 설정합니다. 각 복제본이 처음에 0으로 설정된 경우 Pod 종속성으로 인해 배포가 실패합니다. 예를 들어 Pod는 다른 사용자가 실행 중인지 확인합니다. 먼저 normal으로 배포한 다음 replicas를 0으로 설정합니다.

2.5.9.7. 수동 장애 조치 동기화 데이터베이스

절차

  1. 수동 Cryostat 공유 데이터베이스에서 1, 2 및 3단계를 수행합니다.

    1. 각 클러스터에는 고유한 독립 데이터베이스, 즉 활성 리전의 마스터의 읽기-복제본이 있습니다.
    2. 모든 데이터베이스에서 장애 조치(failover)를 수동으로 실행하여 패시브 리전에서 새 마스터를 선택해야 합니다. 그러면 활성 리전이 됩니다.
  2. 실행할 데이터베이스의 수동 페일오버는 다음과 같습니다.

    1. AWS RDS: 시스템Zync.
    2. AWS ElastiCaches: 백엔드시스템.
  3. 수동 Cryostat 공유 데이터베이스에서 4단계를 수행합니다.

2.5.10. Amazon Simple Storage Service 3scale fileStorage 설치

3scale을 배포하기 위해 APIManager CR(사용자 정의 리소스)을 생성하기 전에 OpenShift 시크릿을 사용하여 Amazon Simple Storage Service(Amazon S3) 서비스에 대한 연결 설정을 제공합니다.

중요
  • 로컬 파일 시스템 스토리지를 사용하여 3scale을 배포하는 경우 이 섹션을 건너뜁니다.
  • 시크릿에 대해 선택한 이름은 기존 보안 이름이 아니며 APIManager CR에서 참조되는 모든 이름이 될 수 있습니다.
  • S3 호환 스토리지에 AWS_REGION 이 제공되지 않으면 default 를 사용하거나 배포에 실패합니다.
  • 면책 조항: 여기에 포함된 외부 웹 사이트와의 링크는 편의를 위해서만 제공됩니다. Red Hat은 링크를 검토하지 않았으며 컨텐츠 또는 이용 가능 여부에 대해 책임을 지지 않습니다. 외부 웹 사이트에 대한 링크가 포함되어 있다고 해서 Red Hat이 해당 웹 사이트 또는 해당 엔티티, 제품, 서비스를 보증한다는 의미는 아닙니다. 사용자는 본인이 그러한 외부 사이트나 콘텐츠를 사용(또는 신뢰)하여 초래되는 어떠한 손실이나 비용에 대해 Red Hat이 어떠한 책임도 지지 않는 데 동의합니다.

2.5.10.1. Amazon S3 버킷 생성

사전 요구 사항

절차

  1. 시스템 자산을 저장하기 위한 버킷을 생성합니다.
  2. 개발자 포털의 Logo 기능을 사용할 때 S3의 공용 액세스 차단기를 비활성화합니다.
  3. 다음과 같은 최소한의 권한으로 IAM(Identity and Access Management) 정책을 생성합니다.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:ListAllMyBuckets",
                "Resource": "arn:aws:s3:::*"
            },
            {
                "Effect": "Allow",
                "Action": "s3:*",
                "Resource": [
                    "arn:aws:s3:::<target_bucket_name>", 1
                    "arn:aws:s3:::<target_bucket_name>/*" 2
                ]
            }
        ]
    }
    1
    & lt;target_bucket_name&gt;을 고유한 값으로 바꿉니다.
    2
    & lt;target_bucket_name&gt;을 고유한 값으로 바꿉니다.
  4. 다음 규칙을 사용하여 CORS 구성을 생성합니다.

    <?xml version="1.0" encoding="UTF-8"?>
    <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>https://*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
    </CORSRule>
    </CORSConfiguration>

2.5.10.2. OpenShift 시크릿 생성

다음 예제에서는 PVC(영구 볼륨 클레임) 대신 Amazon S3를 사용하는 3scale fileStorage 를 보여줍니다.

참고

AWS S3 호환 공급자는 AWS_HOSTNAME,AWS_PATH_STYLE, AWS_PROTOCOL 선택 키를 사용하여 S3 시크릿에 구성할 수 있습니다. 자세한 내용은 fileStorage S3 인증 정보 시크릿 필드 표를 참조하십시오.

다음 예에서 Secret 이름은 APIManager CR에서 참조되므로 무엇이든 될 수 있습니다.

apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: null
  name: aws-auth
stringData:
  AWS_ACCESS_KEY_ID: <ID_123456>
  AWS_SECRET_ACCESS_KEY: <ID_98765544>
  AWS_BUCKET: <mybucket.example.com>
  AWS_REGION: eu-west-1
type: Opaque

마지막으로 APIManager CR을 생성하여 3scale을 배포합니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: <example_apimanager>
  namespace: <3scale_test>
spec:
  wildcardDomain: lvh.me
  system:
    fileStorage:
      simpleStorageService:
        configurationSecretRef:
          name: aws-auth

APIManager SystemS3Spec 을 확인합니다.

다음 표에서는 IAM(Identity and Access Management) 및 STS(Security Token Service) 설정에 대한 fileStorage Amazon S3 인증 정보 시크릿 필드 요구 사항을 보여줍니다.

  • STS(Secure Token Service)를 사용하는 S3 인증 방법은 단기적이고 제한된 권한 보안 인증 정보를 위한 것입니다.
  • S3 IAM(Identity and Access Management)은 장기적인 권한 보안 자격 증명을 위한 것입니다.
표 2.1. filestorage S3 인증 정보 시크릿 필드
필드설명IAM에 필요STS에 필수

AWS_ACCESS_KEY_ID

시스템의 fileStorage에 대해 S3 Storage에서 사용할 AWS Access Key ID

있음

없음

AWS_SECRET_ACCESS_KEY

시스템의 fileStorage에 S3 Storage에서 사용할 AWS Access Key Secret

있음

없음

AWS_BUCKET

자산의 시스템 fileStorage 로 사용할 S3 버킷

있음

있음

AWS_REGION

자산에 대한 시스템의 fileStorage 로 사용할 S3 버킷의 리전

있음

있음

AWS_HOSTNAME

기본값: Amazon endpoints - AWS S3 호환 공급자 끝점 호스트 이름

없음

없음

AWS_PROTOCOL

기본값 : AWS S3 호환 공급자 끝점 프로토콜

없음

없음

AWS_PATH_STYLE

default: false true 로 설정하면 버킷 이름은 항상 요청 URI에 남아 있고 호스트로 하위 도메인으로 이동하지 않습니다.

없음

없음

AWS_ROLE_ARN

AWS STS를 사용하여 인증하는 정책이 연결된 역할의 ARN

없음

있음

AWS_WEB_IDENTITY_TOKEN_FILE

마운트된 토큰 파일 위치 경로입니다. 예: /var/run/secrets/openshift/serviceaccount/token

없음

있음

2.5.11. PostgreSQL 설치

MySQL 내부 관계형 데이터베이스는 기본 배포입니다. 대신 PostgreSQL을 사용하도록 이 배포 구성을 재정의할 수 있습니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  wildcardDomain: lvh.me
  system:
    database:
      postgresql: {}

추가 리소스

2.5.12. SMTP 변수 구성 (선택 사항)

3scale은 이메일을 사용하여 알림을 보내고 새 사용자를 초대합니다. 이러한 기능을 사용하려면 자체 SMTP 서버를 제공하고 system-smtp 시크릿에서 SMTP 변수를 구성해야 합니다.

다음 단계를 수행하여 system-smtp 시크릿에서 SMTP 변수를 구성합니다.

절차

  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-appsystem-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

2.5.13. 구성 요소 수준에서 컴퓨팅 리소스 요구 사항 사용자 정의

APIManager CR(사용자 정의 리소스) 속성을 통해 3scale 솔루션의 Kubernetes 컴퓨팅 리소스 요구 사항을 사용자 정의합니다. 이 작업을 수행하여 특정 APIManager 구성 요소에 할당된 CPU 및 메모리인 컴퓨팅 리소스 요구 사항을 사용자 정의합니다.

다음 예제에서는 backend-listenerzync-database 에 대해 system-master의 system-provider 컨테이너에 대한 컴퓨팅 리소스 요구 사항을 사용자 지정하는 방법을 간략하게 설명합니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  backend:
    listenerSpec:
      resources:
        requests:
          memory: "150Mi"
          cpu: "300m"
        limits:
          memory: "500Mi"
          cpu: "1000m"
  system:
    appSpec:
      providerContainerResources:
        requests:
          memory: "111Mi"
          cpu: "222m"
        limits:
          memory: "333Mi"
          cpu: "444m"
  zync:
    databaseResources:
      requests:
        memory: "111Mi"
        cpu: "222m"
      limits:
        memory: "333Mi"
        cpu: "444m"

추가 리소스

구성 요소 수준 CR 요구 사항을 지정하는 방법에 대한 자세한 내용은 APIManager CRD 참조를 참조하십시오.

2.5.13.1. 기본 APIManager 구성 요소 컴퓨팅 리소스

APIManager spec.resourceRequirementsEnabled 속성을 true 로 구성하면 기본 컴퓨팅 리소스가 APIManager 구성 요소에 대해 설정됩니다.

APIManager 구성 요소에 설정된 특정 컴퓨팅 리소스 기본값이 다음 표에 표시되어 있습니다.

2.5.13.1.1. CPU 및 메모리 단위

다음 목록에서는 컴퓨팅 리소스 기본값 표에 언급된 단위를 설명합니다. CPU 및 메모리 유닛에 대한 자세한 내용은 Managing Resources for Containers 를 참조하십시오.

리소스 단위 설명

  • m - milliCPU 또는 millicore
  • Mi - 메비 바이트
  • GI - 기비바이트
  • G - 기가바이트
표 2.3. 컴퓨팅 리소스 기본값
구성 요소CPU 요청CPU 제한메모리 요청메모리 제한

system-app의 system-master

50m

1000m

600Mi

800Mi

system-app의 system-provider

50m

1000m

600Mi

800Mi

system-app의 system- developer

50m

1000m

600Mi

800Mi

system-sidekiq

100m

1000m

500Mi

2Gi

system-sphinx

80m

1000m

250Mi

512Mi

system-redis

150m

500m

256Mi

32Gi

system-mysql

250m

제한 없음

512Mi

2Gi

system-postgresql

250m

제한 없음

512Mi

2Gi

backend-listener

500m

1000m

550Mi

700Mi

backend-worker

150m

1000m

50Mi

300Mi

backend-cron

50m

150m

40Mi

80Mi

backend-redis

1000m

2000m

1024Mi

32Gi

APIcast-production

500m

1000m

64Mi

128Mi

apicast-staging

50m

100m

64Mi

128Mi

zync

150m

1

250M

512Mi

zync-que

250m

1

250M

512Mi

zync-database

50m

250m

250M

2G

2.5.14. 구성 요소 수준에서 노드 유사성 및 허용 오차 사용자 정의

APIManager CR 속성을 통해 Red Hat 3scale API Management 솔루션의 Kubernetes 유사성허용 오차 를 사용자 지정하여 설치의 다양한 3scale 구성 요소가 Kubernetes 노드에 예약되는 위치와 방법을 사용자 지정합니다.

다음 예제에서는 백엔드에 대한 사용자 정의 노드 유사성을 설정합니다. 또한 system-memcached에 대한 리스너 및 사용자 정의 허용 오차를 설정합니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  backend:
    listenerSpec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "kubernetes.io/hostname"
                operator: In
                values:
                - ip-10-96-1-105
              - key: "beta.kubernetes.io/arch"
                operator: In
                values:
                - amd64
  system:
    memcachedTolerations:
    - key: key1
      value: value1
      operator: Equal
      effect: NoSchedule
    - key: key2
      value: value2
      operator: Equal
      effect: NoSchedule

추가 리소스

유사성 및 허용 오차와 관련된 전체 속성 목록은 APIManager CRD 참조 를 참조하십시오.

2.5.15. 조정

3scale이 설치되면 3scale Operator를 사용하면 CR(사용자 정의 리소스)에서 지정된 매개변수 세트를 업데이트하여 시스템 구성 옵션을 수정할 수 있습니다. 시스템을 중지하거나 종료하지 않고 핫 스와핑을 통해 수정이 수행됩니다.

APIManager CRD(사용자 정의 리소스 정의)의 매개 변수가 모두 조정 가능한 것은 아닙니다.

다음은 조정 가능한 매개변수 목록입니다.

2.5.15.1. 리소스

모든 3scale 구성 요소에 대한 리소스 제한 및 요청

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  resourceRequirementsEnabled: true/false

2.5.15.2. 백엔드 복제본

백엔드 구성 요소 pod 수입니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  backend:
    listenerSpec:
      replicas: X
    workerSpec:
      replicas: Y
    cronSpec:
      replicas: Z

2.5.15.3. APIcast 복제본

APIcast 스테이징 및 프로덕션 구성 요소 Pod 수입니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  apicast:
    productionSpec:
      replicas: X
    stagingSpec:
      replicas: Z

2.5.15.4. 시스템 복제본

시스템 앱 및 시스템 sidekiq 구성 요소 Pod 수

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  system:
    appSpec:
      replicas: X
    sidekiqSpec:
      replicas: Z

2.5.15.5. Zync 복제본

Zync 앱 및 que 구성 요소 Pod 수

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  zync:
    appSpec:
      replicas: X
    queSpec:
      replicas: Z
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.