서버리스 논리


Red Hat OpenShift Serverless 1.33

OpenShift Serverless Logic 소개

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Serverless Logic 기능에 대한 개요를 제공합니다.

1장. 시작하기

1.1. Knative Workflow 플러그인을 사용하여 워크플로우 생성 및 실행

OpenShift Serverless Logic 워크플로를 로컬에서 생성하고 실행할 수 있습니다.

1.1.1. 워크플로우 생성

kn 워크플로 와 함께 create 명령을 사용하여 현재 디렉터리에 새 OpenShift Serverless Logic 프로젝트를 설정할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic kn-workflow CLI 플러그인을 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 새 OpenShift Serverless Logic 워크플로 프로젝트를 생성합니다.

    $ kn workflow create
    Copy to Clipboard Toggle word wrap

    기본적으로 생성된 프로젝트 이름은 new-project 입니다. 다음과 같이 [-n|--name] 플래그를 사용하여 프로젝트 이름을 변경할 수 있습니다.

    명령 예

    $ kn workflow create --name my-project
    Copy to Clipboard Toggle word wrap

1.1.2. 로컬로 워크플로우 실행

kn 워크플로 와 함께 run 명령을 사용하여 현재 디렉터리에서 OpenShift Serverless Logic 워크플로 프로젝트를 빌드하고 실행할 수 있습니다.

사전 요구 사항

  • 로컬 시스템에 Podman을 설치했습니다.
  • OpenShift Serverless Logic kn-workflow CLI 플러그인을 설치했습니다.
  • OpenShift Serverless Logic 워크플로 프로젝트를 생성했습니다.

프로세스

  1. 다음 명령을 실행하여 OpenShift Serverless Logic 워크플로우 프로젝트를 빌드하고 실행합니다.

    $ kn workflow run
    Copy to Clipboard Toggle word wrap

    프로젝트가 준비되면 localhost:8080/q/dev-ui 의 브라우저에서 Development UI가 자동으로 열리고 사용 가능한 Serverless Workflow Tools 타일이 있습니다. 또는 http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows 을 사용하여 툴에 직접 액세스할 수 있습니다.

참고

머신에서 실행되는 컨테이너를 사용하여 워크플로우를 로컬에서 실행할 수 있습니다. Ctrl+C를 사용하여 컨테이너를 중지합니다.

1.2. 워크플로우 배포

Dev 모드 및 프리뷰 모드의 두 가지 모드로 Serverless Logic 워크플로를 클러스터에 배포할 수 있습니다.

1.2.1. Dev 모드에서 워크플로 배포

Dev 모드에서 OpenShift Container Platform에 로컬 워크플로를 배포할 수 있습니다. 이 배포를 사용하여 클러스터에서 직접 워크플로우를 실험 및 수정하고 변경 사항이 거의 즉시 표시됩니다. dev 모드는 개발 및 테스트 목적으로 설계되었습니다. 초기 개발 단계와 새로운 변경 사항을 테스트하는 데 이상적입니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 워크플로우 구성 YAML 파일을 생성합니다.

    workflow-dev.yaml 파일 예

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      name: greeting 
    1
    
      annotations:
        sonataflow.org/description: Greeting example on k8s!
        sonataflow.org/version: 0.0.1
        sonataflow.org/profile: dev 
    2
    
    spec:
      flow:
        start: ChooseOnLanguage
        functions:
          - name: greetFunction
            type: custom
            operation: sysout
        states:
          - name: ChooseOnLanguage
            type: switch
            dataConditions:
              - condition: "${ .language == \"English\" }"
                transition: GreetInEnglish
              - condition: "${ .language == \"Spanish\" }"
                transition: GreetInSpanish
            defaultCondition: GreetInEnglish
          - name: GreetInEnglish
            type: inject
            data:
              greeting: "Hello from JSON Workflow, "
            transition: GreetPerson
          - name: GreetInSpanish
            type: inject
            data:
              greeting: "Saludos desde JSON Workflow, "
            transition: GreetPerson
          - name: GreetPerson
            type: operation
            actions:
              - name: greetAction
                functionRef:
                  refName: greetFunction
                  arguments:
                    message:  ".greeting + .name"
            end: true
    Copy to Clipboard Toggle word wrap

    1
    workflow_name
    2
    Dev 모드에서 워크플로를 배포해야 함을 나타냅니다.
  2. 애플리케이션을 배포하려면 다음 명령을 입력하여 YAML 파일을 적용합니다.

    $ oc apply -f <filename> -n <your_namespace>
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 입력하여 배포를 확인하고 배포된 워크플로우의 상태를 확인합니다.

    $ oc get workflow -n <your_namespace> -w
    Copy to Clipboard Toggle word wrap

    워크플로우가 나열되고 상태가 Running 또는 Completed 인지 확인합니다.

  4. 다음 명령을 입력하여 클러스터에서 직접 워크플로를 편집합니다.

    $ oc edit sonataflow <workflow_name> -n <your_namespace>
    Copy to Clipboard Toggle word wrap
  5. 편집 후 변경 사항을 저장합니다. OpenShift Serverless Logic Operator는 변경 사항을 감지하고 그에 따라 워크플로우를 업데이트합니다.

검증

  1. 변경 사항이 올바르게 적용되도록 하려면 다음 명령을 입력하여 워크플로우의 상태 및 로그를 확인합니다.

    1. 다음 명령을 실행하여 워크플로우의 상태를 확인합니다.

      $ oc get sonataflows -n <your_namespace>
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 워크플로우 로그를 확인합니다.

      $ oc logs <workflow_pod_name> -n <your_namespace>
      Copy to Clipboard Toggle word wrap

다음 단계

  1. 테스트를 완료한 후 다음 명령을 실행하여 불필요한 사용을 방지하기 위해 리소스를 삭제합니다.

    $ oc delete sonataflow <workflow_name> -n <your_namespace>
    Copy to Clipboard Toggle word wrap

1.2.2. 프리뷰 모드에서 워크플로우 배포

프리뷰 모드에서 OpenShift Container Platform에 로컬 워크플로를 배포할 수 있습니다. 이를 통해 클러스터에서 직접 워크플로우를 실험 및 수정하여 거의 즉시 변경 사항이 표시됩니다. 프리뷰 모드는 프로덕션에 배포하기 전에 최종 테스트 및 검증에 사용됩니다. 또한 프로덕션과 같은 설정에서 워크플로우가 원활하게 실행되도록 합니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프리뷰 모드에서 워크플로를 배포하기 위해 OpenShift Serverless Logic Operator는 OpenShift Container Platform에서 빌드 시스템을 사용하여 워크플로우 배포 이미지를 자동으로 생성합니다.

다음 섹션에서는 SonataFlow 사용자 정의 리소스가 있는 OpenShift Serverless Logic Operator를 사용하여 클러스터에 워크플로를 빌드하고 배포하는 방법을 설명합니다.

1.2.2.1. 프리뷰 모드에서 워크플로우 구성
1.2.2.1.1. 워크플로우 기본 빌더 이미지 구성

시나리오에 보안 또는 강화 제약 조건과 같은 이미지 사용에 대한 엄격한 정책이 필요한 경우 OpenShift Serverless Logic Operator에서 최종 워크플로우 컨테이너 이미지를 빌드하는 데 사용하는 기본 이미지를 교체합니다.

기본적으로 OpenShift Serverless Logic Operator는 공식 Red Hat Registry에 배포된 이미지를 사용하여 워크플로우를 빌드합니다. 시나리오에 보안 또는 강화 제약 조건 등 이미지 사용을 위한 엄격한 정책이 필요한 경우 기본 이미지를 교체할 수 있습니다.

이 이미지를 변경하려면 워크플로우를 배포한 네임스페이스에서 SonataFlowPlatform CR(사용자 정의 리소스)을 편집합니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 네임스페이스의 SonataFlowPlatform 리소스를 나열합니다.

    $ oc get sonataflowplatform -n <your_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;your_namespace >를 네임스페이스 이름으로 바꿉니다.
  2. 다음 명령을 실행하여 새 빌더 이미지로 SonataFlowPlatform 리소스를 패치합니다.

    $ oc patch sonataflowplatform <name> --patch 'spec:\n  build:\n    config:\n      baseImage: <your_new_image_full_name_with_tag>' -n <your_namespace>
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 SonataFlowPlatform CR이 올바르게 패치되었는지 확인합니다.

    $ oc describe sonataflowplatform <name> -n <your_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;name >을 SonataFlowPlatform 리소스의 이름으로 바꾸고 < your_namespace >를 네임스페이스 이름으로 바꿉니다.

    spec.build.configbaseImage 필드가 새 이미지를 반영하는지 확인합니다.

1.2.2.1.2. 기본 빌더 Dockerfile 사용자 정의

OpenShift Serverless Logic Operator는 openshift-serverless-logicOpenShift Serverless Logic Operator 설치 네임스페이스에서 logic-operator-rhel8-builder-config 구성 맵 CR(사용자 정의 리소스)을 사용하여 워크플로우 빌드 프로세스를 구성하고 실행합니다. 이 구성 맵에서 Dockerfile 항목을 변경하여 필요에 따라 Dockerfile을 조정할 수 있습니다.

중요

Dockerfile을 수정하면 빌드 프로세스가 중단될 수 있습니다.

참고

이 예제는 참조용으로만 사용됩니다. 실제 버전은 약간 다를 수 있습니다. 설치에 이 예제를 사용하지 마십시오.

logic-operator-rhel8-builder-config 구성 맵 CR의 예

apiVersion: v1
data:
  DEFAULT_WORKFLOW_EXTENSION: .sw.json
  Dockerfile: |
    FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0 AS builder

    # Variables that can be overridden by the builder
    # To add a Quarkus extension to your application
    ARG QUARKUS_EXTENSIONS
    # Args to pass to the Quarkus CLI add extension command
    ARG QUARKUS_ADD_EXTENSION_ARGS
    # Additional java/mvn arguments to pass to the builder
    ARG MAVEN_ARGS_APPEND

    # Copy from build context to skeleton resources project
    COPY --chown=1001 . ./resources

    RUN /home/kogito/launch/build-app.sh ./resources

    #=============================
    # Runtime Run
    #=============================
    FROM registry.access.redhat.com/ubi9/openjdk-17:latest

    ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'

    # We make four distinct layers so if there are application changes, the library layers can be re-used
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/lib/ /deployments/lib/
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/*.jar /deployments/
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/app/ /deployments/app/
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/quarkus/ /deployments/quarkus/

    EXPOSE 8080
    USER 185
    ENV AB_JOLOKIA_OFF=""
    ENV JAVA_OPTS="-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
    ENV JAVA_APP_JAR="/deployments/quarkus-run.jar"
kind: ConfigMap
metadata:
  name: sonataflow-operator-builder-config
  namespace: sonataflow-operator-system
Copy to Clipboard Toggle word wrap

1.2.2.1.3. 리소스 요구 사항 변경

워크플로우 네임스페이스에서 SonataFlowPlatform 리소스를 생성하거나 편집하여 내부 빌더 Pod에 대한 리소스 요구 사항을 지정할 수 있습니다.

SonataFlowPlatform 리소스의 예

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform
spec:
  build:
    template:
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"
Copy to Clipboard Toggle word wrap

참고

네임스페이스당 하나의 SonataFlowPlatform 리소스만 허용됩니다. 다른 리소스를 생성하는 대신 OpenShift Serverless Logic Operator가 생성한 리소스를 가져와서 편집합니다.

특정 워크플로우에 대한 리소스 요구 사항을 미세 조정할 수 있습니다. 각 워크플로우 인스턴스에는 워크플로우와 동일한 이름으로 생성된 SonataFlowBuild 인스턴스가 있습니다. SonataFlowBuild CR(사용자 정의 리소스)을 편집하고 매개변수를 다음과 같이 지정할 수 있습니다.

SonataFlowBuild CR의 예

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowBuild
metadata:
  name: my-workflow
spec:
  resources:
    requests:
      memory: "64Mi"
      cpu: "250m"
    limits:
      memory: "128Mi"
      cpu: "500m"
Copy to Clipboard Toggle word wrap

이러한 매개변수는 새 빌드 인스턴스에만 적용됩니다.

1.2.2.1.4. 내부 빌더에 인수 전달

빌드 인수를 SonataFlowBuild 인스턴스에 전달하거나 SonataFlowPlatform 리소스에서 기본 빌드 인수를 설정하여 빌드 프로세스를 사용자 지정할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 기존 SonataFlowBuild 인스턴스를 확인합니다.

    $ oc get sonataflowbuild <name> -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt ;name >을 SonataFlowBuild 인스턴스의 이름으로 바꾸고 < namespace >를 네임스페이스로 바꿉니다.
  2. 다음 명령을 실행하여 SonataFlowBuild 인스턴스에 빌드 인수를 추가합니다.

    $ oc edit sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  3. SonataFlowBuild 인스턴스의 .spec.buildArgs 필드에 원하는 빌드 인수를 추가합니다.

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>  
    1
    
    spec:
      buildArgs:
        - name: <argument_1>
          value: <value_1>
        - name: <argument_2>
          value: <value_2>
    Copy to Clipboard Toggle word wrap
    1
    기존 SonataFlowBuild 인스턴스의 이름입니다.
  4. 파일을 저장하고 종료합니다.

    업데이트된 구성이 포함된 새 빌드가 시작됩니다.

  5. 다음 명령을 실행하여 SonataFlowPlatform 리소스에서 기본 빌드 인수를 설정합니다.

    $ oc edit sonataflowplatform <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  6. SonataFlowPlatform 리소스의 .spec.buildArgs 필드에 원하는 빌드 인수를 추가합니다.

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: <name> 
    1
    
    spec:
      build:
        template:
          buildArgs:
            - name: <argument_1>
              value: <value_1>
            - name: <argument_2>
              value: <value_2>
    Copy to Clipboard Toggle word wrap
    1
    기존 SonataFlowPlatform 리소스의 이름입니다.
  7. 파일을 저장하고 종료합니다.
1.2.2.1.5. 내부 빌더에서 환경 변수 설정

환경 변수를 SonataFlowBuild 내부 빌더 Pod로 설정할 수 있습니다. 이러한 변수는 빌드 컨텍스트에만 유효하며 최종 빌드된 워크플로우 이미지에 설정되지 않습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 기존 SonataFlowBuild 인스턴스를 확인합니다.

    $ oc get sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    &lt ;name >을 SonataFlowBuild 인스턴스의 이름으로 바꾸고 < namespace >를 네임스페이스로 바꿉니다.

  2. 다음 명령을 실행하여 SonataFlowBuild 인스턴스를 편집합니다.

    $ oc edit sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    SonataFlowBuild 인스턴스 예

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>
    spec:
      envs:
        - name: <env_variable_1>
          value: <value_1>
        - name: <env_variable_2>
          value: <value_2>
    Copy to Clipboard Toggle word wrap

  3. 파일을 저장하고 종료합니다.

    업데이트된 구성이 새로 시작됩니다.

    또는 SonataFlowPlatform 에서 enviroments를 설정하여 모든 새 빌드 인스턴스에서 템플릿으로 사용할 수 있습니다.

    SonataFlowPlatform 인스턴스 예

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: <name>
    spec:
      build:
        template:
          envs:
            - name: <env_variable_1>
              value: <value_1>
            - name: <env_variable_2>
              value: <value_2>
    Copy to Clipboard Toggle word wrap

1.2.2.1.6. 기본 빌더 이미지 변경

logic-operator-rhel8-builder-config 구성 맵을 편집하여 OpenShift Serverless Logic Operator에서 사용하는 기본 빌더 이미지를 수정할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 logic-operator-rhel8-builder-config 구성 맵을 편집합니다.

    $ oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logic
    Copy to Clipboard Toggle word wrap
  2. dockerfile 항목을 수정합니다.

    편집기에서 Dockerfile 항목을 찾아 첫 번째 행을 원하는 이미지로 변경합니다.

    data:
      Dockerfile: |
        FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0
        # Change the image to the desired one
    Copy to Clipboard Toggle word wrap

  3. 변경 사항을 저장합니다.
1.2.2.2. 워크플로우 빌드 및 배포

OpenShift Container Platform 및 OpenShift Serverless Logic Operator에서 SonataFlow CR(사용자 정의 리소스)을 생성하여 워크플로우를 빌드하고 배포할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음과 유사한 워크플로우 YAML 파일을 생성합니다.

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      name: greeting
      annotations:
        sonataflow.org/description: Greeting example on k8s!
        sonataflow.org/version: 0.0.1
    spec:
      flow:
        start: ChooseOnLanguage
        functions:
          - name: greetFunction
            type: custom
            operation: sysout
        states:
          - name: ChooseOnLanguage
            type: switch
            dataConditions:
              - condition: "${ .language == \"English\" }"
                transition: GreetInEnglish
              - condition: "${ .language == \"Spanish\" }"
                transition: GreetInSpanish
            defaultCondition: GreetInEnglish
          - name: GreetInEnglish
            type: inject
            data:
              greeting: "Hello from JSON Workflow, "
            transition: GreetPerson
          - name: GreetInSpanish
            type: inject
            data:
              greeting: "Saludos desde JSON Workflow, "
            transition: GreetPerson
          - name: GreetPerson
            type: operation
            actions:
              - name: greetAction
                functionRef:
                  refName: greetFunction
                  arguments:
                    message:  ".greeting+.name"
            end: true
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 SonataFlow 워크플로우 정의를 OpenShift Container Platform 네임스페이스에 적용합니다.

    $ oc apply -f <workflow-name>.yaml -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    welcomes -workflow.yaml 파일에 대한 명령의 예:

    $ oc apply -f greetings-workflow.yaml -n workflows
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 모든 빌드 구성을 나열합니다.

    $ oc get buildconfigs -n workflows
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 빌드 프로세스의 로그를 가져옵니다.

    $ oc logs buildconfig/<workflow-name> -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    welcomes -workflow.yaml 파일에 대한 명령의 예:

    $ oc logs buildconfig/greeting -n workflows
    Copy to Clipboard Toggle word wrap

검증

  1. 배포를 확인하려면 다음 명령을 실행하여 모든 Pod를 나열합니다.

    $ oc get pods -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    워크플로우에 해당하는 Pod가 실행 중인지 확인합니다.

  2. 다음 명령을 실행하여 실행 중인 Pod 및 해당 로그를 확인합니다.

    $ oc logs pod/<pod-name> -n workflows
    Copy to Clipboard Toggle word wrap
1.2.2.3. 워크플로우 배포 확인

워크플로우 Pod에서 테스트 HTTP 호출을 수행하여 OpenShift Serverless Logic 워크플로가 실행 중인지 확인할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음과 유사한 워크플로우 YAML 파일을 생성합니다.

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      name: greeting
      annotations:
        sonataflow.org/description: Greeting example on k8s!
        sonataflow.org/version: 0.0.1
    spec:
      flow:
        start: ChooseOnLanguage
        functions:
          - name: greetFunction
            type: custom
            operation: sysout
        states:
          - name: ChooseOnLanguage
            type: switch
            dataConditions:
              - condition: "${ .language == \"English\" }"
                transition: GreetInEnglish
              - condition: "${ .language == \"Spanish\" }"
                transition: GreetInSpanish
            defaultCondition: GreetInEnglish
          - name: GreetInEnglish
            type: inject
            data:
              greeting: "Hello from JSON Workflow, "
            transition: GreetPerson
          - name: GreetInSpanish
            type: inject
            data:
              greeting: "Saludos desde JSON Workflow, "
            transition: GreetPerson
          - name: GreetPerson
            type: operation
            actions:
              - name: greetAction
                functionRef:
                  refName: greetFunction
                  arguments:
                    message:  ".greeting+.name"
            end: true
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 워크플로우 서비스의 경로를 생성합니다.

    $ oc expose svc/<workflow-service-name> -n workflows
    Copy to Clipboard Toggle word wrap

    이 명령은 워크플로우 서비스에 액세스할 공용 URL을 생성합니다.

  3. 다음 명령을 실행하여 공용 URL의 환경 변수를 설정합니다.

    $ WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 서비스에 POST 요청을 보내 워크플로우에 HTTP를 호출합니다.

    $ curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{<"your": "json_payload">}' http://$WORKFLOW_SVC/<endpoint>
    Copy to Clipboard Toggle word wrap

    출력 예

    {
      "id": "b5fbfaa3-b125-4e6c-9311-fe5a3577efdd",
      "workflowdata": {
        "name": "John",
        "language": "English",
        "greeting": "Hello from JSON Workflow, "
      }
    }
    Copy to Clipboard Toggle word wrap

    이 출력은 워크플로우가 실행 중인 경우 예상되는 응답의 예를 보여줍니다.

1.2.2.4. 빌드 재시작

빌드를 다시 시작하려면 SonataFlowBuild 인스턴스에서 sonataflow.org/restartBuild: true 주석을 추가하거나 편집할 수 있습니다. 워크플로우 또는 초기 빌드 버전에 문제가 있는 경우 빌드를 다시 시작해야 합니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 SonataFlowBuild 인스턴스가 있는지 확인합니다.

    $ oc get sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 SonataFlowBuild 인스턴스를 편집합니다.

    $ oc edit sonataflowbuild/<name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    & lt;name >을 SonataFlowBuild 인스턴스의 이름으로 바꾸고 < namespace >를 워크플로우가 배포된 네임스페이스로 바꿉니다.

  3. sonataflow.org/restartBuild: true 주석을 추가하여 빌드를 다시 시작합니다.

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>
      annotations:
        sonataflow.org/restartBuild: true
    Copy to Clipboard Toggle word wrap

    이 작업을 수행하면 OpenShift Serverless Logic Operator가 워크플로우의 새 빌드를 시작합니다.

  4. 빌드 프로세스를 모니터링하려면 다음 명령을 실행하여 빌드 로그를 확인합니다.

    $ oc logs buildconfig/<name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    & lt;name >을 SonataFlowBuild 인스턴스의 이름으로 바꾸고 < namespace >를 워크플로우가 배포된 네임스페이스로 바꿉니다.

1.2.3. 워크플로우 편집

OpenShift Serverless Logic Operator는 워크플로우 서비스를 배포할 때 런타임 속성을 저장하기 위해 두 개의 구성 맵을 생성합니다.

  • 사용자 속성: 접미사 -props 를 사용하여 SonataFlow 오브젝트 뒤에 이름이 지정된 ConfigMap 에 정의됩니다. 예를 들어 워크플로우 이름이 인사말 인 경우 ConfigMap 이름은 greeting-props 입니다.
  • 관리 속성: 접미사 -managed-props 를 사용하여 SonataFlow 오브젝트 뒤에 이름이 지정된 ConfigMap 에 정의됩니다. 예를 들어 워크플로우 이름이 인사말 인 경우 ConfigMap 이름은 인사말-관리형입니다.
참고

관리 되는 속성은 항상 동일한 키 이름으로 사용자 속성을 재정의 하며 사용자가 편집할 수 없습니다.Managed properties always override any user property with the same key name and cannot be edited by the user. 다음 조정 사이클에서 Operator가 변경 사항을 덮어씁니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 ConfigMap 을 열고 편집합니다.

    $ oc edit cm <workflow_name>-props -n <namespace>
    Copy to Clipboard Toggle word wrap

    & lt;workflow_name >을 워크플로우 이름으로 바꾸고 < namespace >를 워크플로우가 배포된 네임스페이스로 바꿉니다.

  2. application.properties 섹션에 속성을 추가합니다.

    ConfigMap 내에 저장된 워크플로우 속성의 예:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      labels:
        app: greeting
      name: greeting-props
      namespace: default
    data:
      application.properties: |
        my.properties.key = any-value
    Copy to Clipboard Toggle word wrap

    Operator가 구성을 기본 설정으로 교체하지 못하도록 속성이 올바르게 포맷되었는지 확인합니다.

  3. 필요한 변경을 수행한 후 파일을 저장하고 편집기를 종료합니다.

1.2.4. 워크플로우 테스트

OpenShift Serverless Logic 워크플로가 올바르게 실행 중인지 확인하려면 관련 Pod에서 테스트 HTTP 호출을 수행할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 네임스페이스에 지정된 서비스의 경로를 생성하려면 다음을 수행합니다.

    $ oc expose svc <service_name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 새로 노출된 서비스의 URL을 가져오려면 다음을 수행합니다.

    $ WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')
    Copy to Clipboard Toggle word wrap
  3. 테스트 HTTP 호출을 수행하고 다음 명령을 실행하여 POST 요청을 보냅니다.

    $ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>
    Copy to Clipboard Toggle word wrap
  4. 응답을 확인하여 워크플로우가 예상대로 작동하는지 확인합니다.

1.2.5. 워크플로우 문제 해결

OpenShift Serverless Logic Operator는 상태 점검 프로브와 함께 Pod를 배포하여 워크플로우가 정상 상태로 실행되도록 합니다. 변경으로 인해 이러한 상태 점검이 실패하면 Pod가 응답하지 않습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 워크플로우 상태를 확인합니다.

    $ oc get workflow <name> -o jsonpath={.status.conditions} | jq .
    Copy to Clipboard Toggle word wrap
  2. 워크플로우 배포에서 로그를 가져와서 분석하려면 다음 명령을 실행합니다.

    $ oc logs deployment/<workflow_name> -f
    Copy to Clipboard Toggle word wrap

1.2.6. 워크플로우 삭제

oc delete 명령을 사용하여 현재 디렉터리에서 OpenShift Serverless Logic 워크플로를 삭제할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI (oc) 를 설치했습니다.

프로세스

  1. 삭제할 워크플로우를 정의하는 올바른 파일이 있는지 확인합니다. 예: workflow.yaml.
  2. oc delete 명령을 실행하여 지정된 네임스페이스에서 워크플로우를 제거합니다.

    $ oc delete -f <your_file> -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    &lt ;your_file >을 워크플로우 파일의 이름으로 바꾸고 < your_namespace >를 네임스페이스로 바꿉니다.

2장. 서비스 관리

2.1. OpenAPI 서비스 구성

OAS( OpenAPI Specification )는 HTTP API에 대한 표준 프로그래밍 언어와 무관한 인터페이스를 정의합니다. 소스 코드, 추가 문서 또는 네트워크 트래픽 검사에 액세스하지 않고도 서비스의 기능을 이해할 수 있습니다. OpenAPI를 사용하여 서비스를 정의할 때 최소한의 구현 논리를 사용하여 이해하고 상호 작용할 수 있습니다. 인터페이스 설명이 하위 수준 프로그래밍을 단순화하는 것과 마찬가지로 OpenAPI 사양 에서는 서비스 호출에 대한 추측을 제거합니다.

2.1.1. OpenAPI 함수 정의

OpenShift Serverless Logic을 사용하면 함수의 OpenAPI specfication 참조를 사용하여 워크플로우가 원격 서비스와 상호 작용할 수 있습니다.

OpenAPI 함수 정의의 예

{
   "functions": [
      {
         "name": "myFunction1",
         "operation": "classpath:/myopenapi-file.yaml#myFunction1"
      }
   ]
}
Copy to Clipboard Toggle word wrap

operation 속성은 다음 매개변수로 구성된 문자열입니다.

  • URI: 엔진은 이를 사용하여 classpath 와 같은 사양 파일을 찾습니다.
  • 운영 식별자: 이 ID는 OpenAPI 사양 파일에서 찾을 수 있습니다.

OpenShift Serverless Logic은 다음 URI 체계를 지원합니다.

  • classpath: 애플리케이션 프로젝트의 src/main/resources 폴더에 있는 파일에 이 값을 사용합니다. classpath 는 기본 URI 스키마입니다. URI 스키마를 정의하지 않으면 파일 위치는 src/main/resources/myopenapifile.yaml 입니다.
  • 파일: 파일 시스템에 있는 파일에 이 값을 사용합니다.
  • HTTP 또는 https: 원격 위치에 있는 파일에 이 값을 사용합니다.

빌드 시 OpenAPI 사양 파일을 사용할 수 있는지 확인합니다. OpenShift Serverless Logic은 내부 코드 생성 기능을 사용하여 런타임 시 요청을 보냅니다. 애플리케이션 이미지를 빌드하면 OpenShift Serverless Logic에 이러한 파일에 액세스할 수 없습니다.

워크플로우에 추가하려는 OpenAPI 서비스에 사양 파일이 없는 경우 파일을 생성하고 노출하도록 서비스를 하나 생성하거나 업데이트할 수 있습니다.

2.1.2. OpenAPI 사양을 기반으로 REST 요청 전송

OpenAPI 사양 파일을 기반으로 하는 REST 요청을 보내려면 다음 절차를 수행해야 합니다.

  • 함수 참조 정의
  • 워크플로우 상태의 정의된 함수에 액세스

사전 요구 사항

  • OpenShift Serverless Logic Operator가 클러스터에 설치되어 있어야 합니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenAPI 사양 파일에 액세스할 수 있습니다.

프로세스

  1. OpenAPI 기능을 정의하려면 다음을 수행합니다.

    1. 호출하려는 서비스의 OpenAPI 사양 파일을 식별하고 액세스합니다.
    2. OpenAPI 사양 파일을 src/main/resources/specs 와 같은 워크플로우 서비스 디렉터리에 복사합니다.

      다음 예제에서는 곱셈 REST 서비스에 대한 OpenAPI 사양을 보여줍니다.

      곱셈 REST 서비스 OpenAPI 사양의 예

      openapi: 3.0.3
      info:
        title: Generated API
        version: "1.0"
      paths:
        /:
          post:
            operationId: doOperation
            parameters:
              - in: header
                name: notUsed
                schema:
                  type: string
                required: false
            requestBody:
              content:
                application/json:
                  schema:
                    $ref: '#/components/schemas/MultiplicationOperation'
            responses:
              "200":
                description: OK
                content:
                  application/json:
                    schema:
                      type: object
                      properties:
                        product:
                          format: float
                          type: number
      components:
        schemas:
          MultiplicationOperation:
            type: object
            properties:
              leftElement:
                format: float
                type: number
              rightElement:
                format: float
                type: number
      Copy to Clipboard Toggle word wrap

    3. 워크플로우에서 함수를 정의하려면 OpenAPI 사양의 operationId 를 사용하여 함수 정의에서 원하는 작업을 참조합니다.

      온도 변환 애플리케이션의 함수 정의 예

      {
         "functions": [
           {
             "name": "multiplication",
             "operation": "specs/multiplication.yaml#doOperation"
           },
           {
             "name": "subtraction",
             "operation": "specs/subtraction.yaml#doOperation"
           }
         ]
      }
      Copy to Clipboard Toggle word wrap

    4. 함수 정의가 src/main/resources/specs 디렉터리에 저장된 OpenAPI 파일의 올바른 경로를 참조하는지 확인합니다.
  2. 워크플로우 상태에서 정의된 함수에 액세스하려면 다음을 수행합니다.

    1. 추가한 함수 정의를 호출하는 워크플로우 작업을 정의합니다. 각 작업이 이전에 정의한 함수를 참조하는지 확인합니다.
    2. functionRef 속성을 사용하여 이름으로 특정 함수를 참조합니다. OpenAPI 사양에 정의된 매개 변수를 사용하여 functionRef 의 인수를 매핑합니다.

      다음 예제에서는 요청 본문 대신 요청 경로의 매핑 매개변수에 대해 보여줍니다. 다음 PetStore API 예제를 참조할 수 있습니다.

      워크플로우에서 함수 인수 매핑 예

      {
         "states": [
          {
            "name": "SetConstants",
            "type": "inject",
            "data": {
              "subtractValue": 32.0,
              "multiplyValue": 0.5556
            },
            "transition": "Computation"
          },
          {
            "name": "Computation",
            "actionMode": "sequential",
            "type": "operation",
            "actions": [
              {
                "name": "subtract",
                "functionRef": {
                  "refName": "subtraction",
                  "arguments": {
                    "leftElement": ".fahrenheit",
                    "rightElement": ".subtractValue"
                  }
                }
              },
              {
                "name": "multiply",
                "functionRef": {
                  "refName": "multiplication",
                  "arguments": {
                     "leftElement": ".difference",
                     "rightElement": ".multiplyValue"
                  }
                }
              }
            ],
            "end": {
              "terminate": true
            }
          }
        ]
      }
      Copy to Clipboard Toggle word wrap

    3. OpenAPI 사양의 Operation Object 섹션을 확인하여 요청의 매개변수를 구조화하는 방법을 알아봅니다.
    4. jq 표현식을 사용하여 페이로드에서 데이터를 추출하여 필요한 매개변수에 매핑합니다. OpenAPI 사양에 따라 엔진에서 매개변수 이름을 매핑하는지 확인합니다.
    5. 본문 대신 요청 경로에 매개 변수가 필요한 작업의 경우 OpenAPI 사양의 매개변수 정의를 참조하십시오.

      요청 본문 대신 요청 경로의 매핑 매개변수에 대한 자세한 내용은 다음 PetStore API 예제를 참조하십시오.

      매핑 경로 매개변수 예

      {
        "/pet/{petId}": {
          "get": {
            "tags": ["pet"],
            "summary": "Find pet by ID",
            "description": "Returns a single pet",
            "operationId": "getPetById",
            "parameters": [
              {
                "name": "petId",
                "in": "path",
                "description": "ID of pet to return",
                "required": true,
                "schema": {
                  "type": "integer",
                  "format": "int64"
                }
              }
            ]
          }
        }
      }
      Copy to Clipboard Toggle word wrap

      다음은 함수 호출의 예로, 요청 경로에 petId 라는 하나의 매개변수만 추가됩니다.

      PetStore 함수 호출 예

      {
        "name": "CallPetStore", 
      1
      
        "actionMode": "sequential",
        "type": "operation",
        "actions": [
          {
            "name": "getPet",
            "functionRef": {
              "refName": "getPetById", 
      2
      
              "arguments": { 
      3
      
                "petId": ".petId"
              }
            }
          }
        ]
      }
      Copy to Clipboard Toggle word wrap

      1
      CallPetStore 와 같은 상태 정의
      2
      함수 정의 참조. 이전 예에서 함수 정의 getPetById 는 PetStore OpenAPI 사양입니다.
      3
      인수 정의. OpenShift Serverless Logic은 요청을 보내기 전에 인수 petId 를 요청 경로에 추가합니다.

2.1.3. OpenAPI 서비스의 끝점 URL 구성

워크플로우 상태의 함수 정의에 액세스한 후 OpenAPI 서비스의 엔드포인트 URL을 구성할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenShift Serverless Logic 프로젝트를 생성했습니다.
  • OpenAPI 사양 파일에 액세스할 수 있습니다.
  • 워크플로우에서 함수 정의를 정의했습니다.
  • 워크플로우 상태에서 정의된 함수에 액세스할 수 있습니다.

프로세스

  1. 구성할 OpenAPI 사양 파일을 찾습니다. 예를 들면 substraction.yaml 입니다.
  2. 문자(예: . )를 밑줄로 바꾸고 문자를 소문자로 변환하여 파일 이름을 유효한 구성 키로 변환합니다. 예를 들어 substraction.yamlsubstraction_yaml 로 변경합니다.
  3. 구성 키를 정의하려면 변환된 파일 이름을 REST 클라이언트 구성 키로 사용합니다. 다음 예와 같이 이 키를 환경 변수로 설정합니다.

    quarkus.rest-client.subtraction_yaml.url=http://myserver.com
    Copy to Clipboard Toggle word wrap
  4. application.properties 파일에서 하드 코딩 URL을 방지하려면 다음 예와 같이 환경 변수 대체를 사용합니다.

    quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}
    Copy to Clipboard Toggle word wrap

    이 예제에서는 다음을 수행합니다.

    • 구성 키: quarkus.rest-client.subtraction_yaml.url
    • 환경 변수: SUBTRACTION_URL
    • 대체 URL: http://myserver.com
  5. (SUBTRACTION_URL) 환경 변수가 시스템 또는 배포 환경에 설정되어 있는지 확인합니다. 변수를 찾을 수 없는 경우 애플리케이션은 대체 URL (http://myserver.com) 을 사용합니다.
  6. application.properties 파일에 구성 키와 URL 대체를 추가합니다.

    quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}
    Copy to Clipboard Toggle word wrap
  7. 애플리케이션을 배포하거나 다시 시작하여 새 구성 설정을 적용합니다.

2.2. OpenAPI 서비스 끝점 구성

OpenShift Serverless Logic은 kogito.sw.operationIdStrategy 속성을 사용하여 OpenAPI 문서에 정의된 서비스를 호출하는 REST 클라이언트를 생성합니다. 이 속성은 REST 클라이언트 구성에 대해 구성 키를 파생하는 방법을 결정합니다.

kogito.sw.operationIdStrategy 속성은 FILE_NAME,FULL_URI,FUNCTION_NAME, SPEC_TITLE 값을 지원합니다.

FILE_NAME

OpenShift Serverless Logic은 OpenAPI 문서 파일 이름을 사용하여 구성 키를 생성합니다. 키는 파일 이름을 기반으로 하며, 여기서 특수 문자가 밑줄로 교체됩니다.

설정 예:

quarkus.rest-client.stock_portfolio_svc_yaml.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
OpenAPI 파일 경로는 src/main/resources/openapi/stock-portfolio-svc.yaml 입니다. REST 클라이언트의 URL을 구성하는 생성된 키는 score _portfolio_svc_yaml입니다.
FULL_URI

OpenShift Serverless Logic은 OpenAPI 문서의 전체 URI 경로를 구성 키로 사용합니다. 전체 URI는 키를 형성하도록 조정됩니다.

Serverless Workflow의 예

{
    "id": "myworkflow",
    "functions": [
        {
          "name": "myfunction",
          "operation": "https://my.remote.host/apicatalog/apis/123/document"
        }
    ]
    ...
}
Copy to Clipboard Toggle word wrap

설정 예:

quarkus.rest-client.apicatalog_apis_123_document.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
URI 경로는 https://my.remote.host/apicatalog/apis/123/document 입니다. REST 클라이언트의 URL을 구성하는 생성된 키는 apicatalog_apis_123_document 입니다.
FUNCTION_NAME

OpenShift Serverless Logic은 OpenAPI 문서를 참조하는 워크플로우 ID와 함수 이름을 결합하여 구성 키를 생성합니다.

Serverless Workflow의 예

{
    "id": "myworkflow",
    "functions": [
        {
          "name": "myfunction",
          "operation": "https://my.remote.host/apicatalog/apis/123/document"
        }
    ]
    ...
}
Copy to Clipboard Toggle word wrap

설정 예:

quarkus.rest-client.myworkflow_myfunction.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
워크플로우 ID는 myworkflow 입니다. 함수 이름은 myfunction 입니다. REST 클라이언트의 URL을 구성하는 생성된 키는 myworkflow_myfunction 입니다.
SPEC_TITLE

OpenShift Serverless Logic은 OpenAPI 문서의 info.title 값을 사용하여 구성 키를 생성합니다. 제목이 키를 형성하도록 조정됩니다.

OpenAPI 문서의 예

openapi: 3.0.3
info:
  title: stock-service API
  version: 2.0.0-SNAPSHOT
paths:
  /stock-price/{symbol}:
...
Copy to Clipboard Toggle word wrap

설정 예:

quarkus.rest-client.stock-service_API.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
OpenAPI 문서 제목은 주식 서비스 API 입니다. REST 클라이언트의 URL을 구성하는 생성된 키는 price -service_API 입니다.

2.2.1. URI 별칭 사용

kogito.sw.operationIdStrategy 속성 대신 workflow-uri-definitions 사용자 지정 확장을 사용하여 URI에 별칭을 할당할 수 있습니다. 이 별칭은 구성 프로세스를 단순화하고 REST 클라이언트 설정 및 함수 정의에서 구성 키로 사용할 수 있습니다.

workflow-uri-definitions 확장을 사용하면 URI를 워크플로우 전체에서 및 구성 파일에서 참조할 수 있는 별칭에 매핑할 수 있습니다. 이 접근 방식은 중앙 집중식으로 URI 및 해당 구성을 관리하는 방법을 제공합니다.

사전 요구 사항

  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenAPI 사양 파일에 액세스할 수 있습니다.

프로세스

  1. workflow-uri-definitions 확장을 워크플로에 추가합니다. 이 확장 내에서 URI에 대한 별칭을 생성합니다.

    워크플로우 예

    {
      "extensions": [
        {
          "extensionid": "workflow-uri-definitions", 
    1
    
          "definitions": {
            "remoteCatalog": "https://my.remote.host/apicatalog/apis/123/document" 
    2
    
          }
        }
      ],
      "functions": [ 
    3
    
        {
          "name": "operation1",
          "operation": "remoteCatalog#operation1"
        },
        {
          "name": "operation2",
          "operation": "remoteCatalog#operation2"
        }
      ]
    }
    Copy to Clipboard Toggle word wrap

1
확장 ID를 workflow-uri-definitions 로 설정합니다.
2
remoteCatalog 별칭을 URI에 매핑하여 별칭 정의를 설정합니다(예: https://my.remote.host/apicatalog/apis/123/document URI).
3
작업 식별자와 함께 remoteCatalog 별칭을 사용하여 함수 작업을 설정합니다(예: operation1operation2 작업 식별자).
  1. application.properties 파일에서 워크플로에 정의된 별칭을 사용하여 REST 클라이언트를 구성합니다.

    속성 예

    quarkus.rest-client.remoteCatalog.url=http://localhost:8282/
    Copy to Clipboard Toggle word wrap

    이전 예에서 구성 키는 quarkus.rest-client.remoteCatalog.url 로 설정되고 URL은 remoteCatalog 별칭을 참조하여 REST 클라이언트가 사용하는 http://localhost:8282/ 로 설정됩니다.

  2. 워크플로우에서는 URI에서 작동하는 함수를 정의할 때 별칭을 사용합니다.

    예제 워크플로우(종료됨):

    {
      "functions": [
        {
          "name": "operation1",
          "operation": "remoteCatalog#operation1"
        },
        {
          "name": "operation2",
          "operation": "remoteCatalog#operation2"
        }
      ]
    }
    Copy to Clipboard Toggle word wrap

2.3. 서비스 문제 해결

OpenAPI 기능을 사용하는 HTTP 기반 함수 호출의 효율적인 문제 해결은 워크플로우 오케스트레이션을 유지 관리하는 데 매우 중요합니다.

문제를 진단하기 위해 HTTP 요청 및 응답을 추적할 수 있습니다.

2.3.1. HTTP 요청 및 응답 추적

OpenShift Serverless Logic은 Apache HTTP 클라이언트를 사용하여 HTTP 요청 및 응답을 추적합니다.

사전 요구 사항

  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한으로 OpenShift Serverless Logic 프로젝트에 액세스할 수 있습니다.
  • OpenAPI 사양 파일에 액세스할 수 있습니다.
  • HTTP 요청 및 응답을 상관하기 위해 워크플로우 정의 및 인스턴스 ID에 액세스할 수 있습니다.
  • HTTP 서비스 호출이 발생하는 애플리케이션의 로그 구성에 액세스할 수 있습니다.

프로세스

  1. OpenShift Serverless Logic은 HTTP 요청 및 응답을 추적하기 위해 다음 속성을 설정하여 Apache HTTP 클라이언트를 사용합니다.

    # Turning HTTP tracing on
    quarkus.log.category."org.apache.http".level=DEBUG
    Copy to Clipboard Toggle word wrap
  2. 애플리케이션의 application.properties 파일에 다음 구성을 추가하여 Apache HTTP Client에 대한 디버깅을 켭니다.

    quarkus.log.category."org.apache.http".level=DEBUG
    Copy to Clipboard Toggle word wrap
  3. 애플리케이션을 다시 시작하여 로그 구성 변경 사항을 전파합니다.
  4. 다시 시작한 후 로그에 HTTP 요청 추적을 확인합니다.

    추적된 HTTP 요청의 로그 예

    2023-09-25 19:00:55,242 DEBUG Executing request POST /v2/models/yolo-model/infer HTTP/1.1
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> POST /v2/models/yolo-model/infer HTTP/1.1
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> Accept: application/json
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> Content-Type: application/json
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocid: inferencepipeline
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocinstanceid: 85114b2d-9f64-496a-bf1d-d3a0760cde8e
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocist: Active
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoproctype: SW
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocversion: 1.0
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> Content-Length: 23177723
    2023-09-25 19:00:55,244 DEBUG http-outgoing-0 >> Host: yolo-model-opendatahub-model.apps.trustyai.dzzt.p1.openshiftapps.com
    Copy to Clipboard Toggle word wrap

  5. 요청 로그 다음에 HTTP 응답 추적의 로그를 확인합니다.

    추적된 HTTP 응답의 로그 예

    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "HTTP/1.1 500 Internal Server Error[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "content-type: application/json[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "date: Mon, 25 Sep 2023 19:01:00 GMT[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "content-length: 186[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "set-cookie: 276e4597d7fcb3b2cba7b5f037eeacf5=5427fafade21f8e7a4ee1fa6c221cf40; path=/; HttpOnly; Secure; SameSite=None[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "{"code":13, "message":"Failed to load Model due to adapter error: Error calling stat on model file: stat /models/yolo-model__isvc-1295fd6ba9/yolov5s-seg.onnx: no such file or directory"}"
    Copy to Clipboard Toggle word wrap

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat