CLI 툴

OpenShift Container Platform 4.8

OpenShift Container Platform 명령줄 툴 사용 방법 알아보기

Red Hat OpenShift Documentation Team

초록

이 문서는 OpenShift Container Platform 명령줄 툴 설치, 구성 및 사용에 대해 자세히 설명합니다. CLI 명령에 대한 참조와 사용 방법에 대한 예도 포함되어 있습니다.

1장. OpenShift CLI(oc)

1.1. OpenShift CLI 시작하기

1.1.1. OpenShift CLI 정보

OpenShift CLI(명령줄 인터페이스) 즉, oc 명령을 사용하면 터미널에서 애플리케이션을 생성하고 OpenShift Container Platform 프로젝트를 관리할 수 있습니다. OpenShift CLI를 사용하기에 적합한 경우는 다음과 같습니다.

  • 직접 프로젝트 소스 코드로 작업하는 경우
  • OpenShift Container Platform 작업 스크립트를 작성하는 경우
  • 대역폭 리소스가 제한되고 웹 콘솔을 사용할 수 없는 상태에서 프로젝트를 관리하는 경우

1.1.2. OpenShift CLI 설치

OpenShift CLI(oc)는 바이너리를 다운로드하거나 RPM을 사용하여 설치할 수 있습니다.

1.1.2.1. 바이너리를 다운로드하여 OpenShift CLI 설치

명령줄 인터페이스를 사용하여 OpenShift Container Platform과 상호 작용하기 위해 OpenShift CLI(oc)를 설치할 수 있습니다. Linux, Windows 또는 macOS에 oc를 설치할 수 있습니다.

중요

이전 버전의 oc를 설치한 경우, OpenShift Container Platform 4.8의 모든 명령을 완료하는 데 해당 버전을 사용할 수 없습니다. 새 버전의 oc를 다운로드하여 설치합니다.

Linux에서 OpenShift CLI 설치

다음 절차를 사용하여 Linux에서 OpenShift CLI(oc) 바이너리를 설치할 수 있습니다.

프로세스

  1. Red Hat OpenShift Cluster Manager 사이트의 Infrastructure Provider 페이지를 찾습니다.
  2. 인프라 공급자(해당되는 경우)를 선택하고 설치 유형을 선택합니다.
  3. 명령행 인터페이스 섹션의 드롭다운 메뉴에서 Linux를 선택하고 명령행 툴 다운로드를 클릭합니다.
  4. 아카이브의 압축을 풉니다.

    $ tar xvzf <file>
  5. oc 바이너리를 PATH에 있는 디렉터리에 배치합니다.

    PATH를 확인하려면 다음 명령을 실행합니다.

    $ echo $PATH

CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

$ oc <command>
Windows에서 OpenSfhit CLI 설치

다음 절차에 따라 Windows에 OpenShift CLI(oc) 바이너리를 설치할 수 있습니다.

프로세스

  1. Red Hat OpenShift Cluster Manager 사이트의 Infrastructure Provider 페이지를 찾습니다.
  2. 인프라 공급자(해당되는 경우)를 선택하고 설치 유형을 선택합니다.
  3. 명령행 인터페이스 섹션의 드롭다운 메뉴에서 Windows를 선택하고 명령행 툴 다운로드를 클릭합니다.
  4. ZIP 프로그램으로 아카이브의 압축을 풉니다.
  5. oc 바이너리를 PATH에 있는 디렉터리로 이동합니다.

    PATH를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.

    C:\> path

CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

C:\> oc <command>
macOS에 OpenShift CLI 설치

다음 절차에 따라 macOS에서 OpenShift CLI(oc) 바이너리를 설치할 수 있습니다.

프로세스

  1. Red Hat OpenShift Cluster Manager 사이트의 Infrastructure Provider 페이지를 찾습니다.
  2. 인프라 공급자(해당되는 경우)를 선택하고 설치 유형을 선택합니다.
  3. 명령행 인터페이스 섹션의 드롭다운 메뉴에서 MacOS를 선택하고 명령행 툴 다운로드를 클릭합니다.
  4. 아카이브의 압축을 해제하고 압축을 풉니다.
  5. oc 바이너리 PATH의 디렉터리로 이동합니다.

    PATH를 확인하려면 터미널을 열고 다음 명령을 실행합니다.

    $ echo $PATH

CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

$ oc <command>

1.1.2.2. RPM을 사용하여 OpenShift CLI 설치

RHEL(Red Hat Enterprise Linux)의 경우 Red Hat 계정에 활성 OpenShift Container Platform 서브스크립션이 있으면 OpenShift CLI(oc)를 RPM으로 설치할 수 있습니다.

사전 요구 사항

  • root 또는 sudo 권한이 있어야 합니다.

절차

  1. Red Hat Subscription Manager에 등록합니다.

    # subscription-manager register
  2. 최신 서브스크립션 데이터를 가져옵니다.

    # subscription-manager refresh
  3. 사용 가능한 서브스크립션을 나열하십시오.

    # subscription-manager list --available --matches '*OpenShift*'
  4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이 서브스크립션을 등록된 시스템에 연결합니다.

    # subscription-manager attach --pool=<pool_id>
  5. OpenShift Container Platform 4.8에 필요한 리포지토리를 활성화합니다.

    • Red Hat Enterprise Linux 8의 경우:

      # subscription-manager repos --enable="rhocp-4.7-for-rhel-8-x86_64-rpms"
    • Red Hat Enterprise Linux 7의 경우:

      # subscription-manager repos --enable="rhel-7-server-ose-4.7-rpms"
  6. openshift-clients 패키지를 설치합니다.

    # yum install openshift-clients

CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

$ oc <command>

1.1.3. OpenShift CLI에 로그인

OpenShift CLI (oc) 에 로그인하면 클러스터에 액세스하여 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 대한 액세스 권한이 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.
참고

HTTP 프록시 서버를 통해서만 액세스할 수 있는 클러스터에 액세스하려면 HTTP_PROXY, HTTPS_PROXYNO_PROXY 변수를 설정할 수 있습니다. oc CLI에서는 이러한 환경 변수를 준수하므로 클러스터와의 모든 통신이 HTTP 프록시를 통해 이루어집니다.

프로세스

  1. oc login 명령을 입력하고 사용자 이름을 전달합니다.

    $ oc login -u user1
  2. 프롬프트가 표시되면 필요한 정보를 입력합니다.

    출력 예

    Server [https://localhost:8443]: https://openshift.example.com:6443 1
    The server uses a certificate signed by an unknown authority.
    You can bypass the certificate check, but any data you send to the server could be intercepted by others.
    Use insecure connections? (y/n): y 2
    
    Authentication required for https://openshift.example.com:6443 (openshift)
    Username: user1
    Password: 3
    Login successful.
    
    You don't have any projects. You can try to create a new project, by running
    
        oc new-project <projectname>
    
    Welcome! See 'oc help' to get started.

    1
    OpenShift Container Platform 서버 URL을 입력합니다.
    2
    비보안 연결 사용 여부를 입력합니다.
    3
    사용자 암호를 입력합니다.

이제 클러스터를 관리하기 위한 프로젝트를 생성하거나 다른 명령을 실행할 수 있습니다.

1.1.4. OpenShift CLI 사용

다음 섹션을 검토하여 CLI로 일반적인 작업을 완료하는 방법을 알아봅니다.

1.1.4.1. 프로젝트 생성

oc new-project 명령을 사용하여 새 프로젝트를 생성합니다.

$ oc new-project my-project

출력 예

Now using project "my-project" on server "https://openshift.example.com:6443".

1.1.4.2. 새 애플리케이션 생성

oc new-app 명령을 사용하여 새 애플리케이션을 생성합니다.

$ oc new-app https://github.com/sclorg/cakephp-ex

출력 예

--> Found image 40de956 (9 days old) in imagestream "openshift/php" under tag "7.2" for "php"

...

    Run 'oc status' to view your app.

1.1.4.3. Pod 보기

oc get pods 명령을 사용하여 현재 프로젝트의 Pod를 봅니다.

$ oc get pods -o wide

출력 예

NAME                  READY   STATUS      RESTARTS   AGE     IP            NODE                           NOMINATED NODE
cakephp-ex-1-build    0/1     Completed   0          5m45s   10.131.0.10   ip-10-0-141-74.ec2.internal    <none>
cakephp-ex-1-deploy   0/1     Completed   0          3m44s   10.129.2.9    ip-10-0-147-65.ec2.internal    <none>
cakephp-ex-1-ktz97    1/1     Running     0          3m33s   10.128.2.11   ip-10-0-168-105.ec2.internal   <none>

1.1.4.4. Pod 로그 보기

oc logs 명령을 사용하여 특정 Pod의 로그를 봅니다.

$ oc logs cakephp-ex-1-deploy

출력 예

--> Scaling cakephp-ex-1 to 1
--> Success

1.1.4.5. 현재 프로젝트 보기

oc project 명령을 사용하여 현재 프로젝트를 봅니다.

$ oc project

출력 예

Using project "my-project" on server "https://openshift.example.com:6443".

1.1.4.6. 현재 프로젝트의 상태 보기

oc status 명령을 사용하여 서비스, 배포, 빌드 구성 등 현재 프로젝트에 대한 정보를 봅니다.

$ oc status

출력 예

In project my-project on server https://openshift.example.com:6443

svc/cakephp-ex - 172.30.236.80 ports 8080, 8443
  dc/cakephp-ex deploys istag/cakephp-ex:latest <-
    bc/cakephp-ex source builds https://github.com/sclorg/cakephp-ex on openshift/php:7.2
    deployment #1 deployed 2 minutes ago - 1 pod

3 infos identified, use 'oc status --suggest' to see details.

1.1.4.7. 지원되는 API 리소스 나열

oc api-resources 명령을 사용하여 서버에서 지원되는 API 리소스 목록을 봅니다.

$ oc api-resources

출력 예

NAME                                  SHORTNAMES       APIGROUP                              NAMESPACED   KIND
bindings                                                                                     true         Binding
componentstatuses                     cs                                                     false        ComponentStatus
configmaps                            cm                                                     true         ConfigMap
...

1.1.5. 도움말 가져오기

CLI 명령 및 OpenShift Container Platform 리소스에 대한 도움말을 가져올 수 있는 방법은 다음과 같습니다.

  • oc help를 사용하여 모든 사용 가능한 CLI 명령 목록 및 설명을 가져옵니다.

    예: CLI에 대한 일반적인 도움말 가져오기

    $ oc help

    출력 예

    OpenShift Client
    
    This client helps you develop, build, deploy, and run your applications on any OpenShift or Kubernetes compatible
    platform. It also includes the administrative commands for managing a cluster under the 'adm' subcommand.
    
    Usage:
      oc [flags]
    
    Basic Commands:
      login           Log in to a server
      new-project     Request a new project
      new-app         Create a new application
    
    ...

  • --help 플래그를 사용하여 특정 CLI 명령에 대한 도움말을 가져옵니다.

    예: oc create 명령에 대한 도움말 가져오기

    $ oc create --help

    출력 예

    Create a resource by filename or stdin
    
    JSON and YAML formats are accepted.
    
    Usage:
      oc create -f FILENAME [flags]
    
    ...

  • oc explain 명령을 사용하여 특정 리소스에 대한 설명 및 필드를 봅니다.

    예: Pod 리소스에 대한 문서 보기

    $ oc explain pods

    출력 예

    KIND:     Pod
    VERSION:  v1
    
    DESCRIPTION:
         Pod is a collection of containers that can run on a host. This resource is
         created by clients and scheduled onto hosts.
    
    FIELDS:
       apiVersion	<string>
         APIVersion defines the versioned schema of this representation of an
         object. Servers should convert recognized schemas to the latest internal
         value, and may reject unrecognized values. More info:
         https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
    
    ...

1.1.6. OpenShift CLI에서 로그아웃

OpenShift CLI에서 로그아웃하여 현재 세션을 종료할 수 있습니다.

  • oc logout 명령을 사용합니다.

    $ oc logout

    출력 예

    Logged "user1" out on "https://openshift.example.com"

이렇게 하면 저장된 인증 토큰이 서버에서 삭제되고 구성 파일에서 제거됩니다.

1.2. OpenShift CLI 구성

1.2.1. 탭 완료 활성화

oc CLI 툴을 설치한 후에는 탭 완료를 활성화하여 자동으로 oc 명령을 완료하거나 탭을 누를 때 옵션을 제안하도록 할 수 있습니다.

사전 요구 사항

  • oc CLI 툴이 설치되어 있어야 합니다.
  • bash-completion 패키지가 설치되어 있어야 합니다.

프로세스

Bash 탭 완료를 활성화하는 절차는 다음과 같습니다.

  1. Bash 완료 코드를 파일에 저장합니다.

    $ oc completion bash > oc_bash_completion
  2. 이 파일을 /etc/bash_completion.d/에 복사합니다.

    $ sudo cp oc_bash_completion /etc/bash_completion.d/

    파일을 로컬 디렉터리에 저장하고 .bashrc 파일에서 소싱할 수도 있습니다.

새 터미널을 열면 탭 완료가 활성화됩니다.

1.3. 플러그인을 사용하여 OpenShift CLI 확장

기본 oc 명령에 빌드할 플러그인을 작성하고 설치하여 OpenShift Container Platform CLI에서 새롭고 더 복잡한 작업을 수행할 수 있습니다.

1.3.1. CLI 플러그인 작성

명령줄 명령을 작성할 수 있는 모든 프로그래밍 언어 또는 스크립트로 OpenShift Container Platform CLI용 플러그인을 작성할 수 있습니다. 기존 oc 명령은 플러그인으로 덮어쓸 수 없습니다.

중요

OpenShift CLI 플러그인은 현재 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 고객은 출시 예정된 제품 기능을 프리뷰를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.

자세한 내용은 Red Hat 기술 프리뷰 기능 지원 범위를 참조하십시오.

절차

이 절차에서는 oc foo 명령을 실행할 때 메시지를 터미널에 출력하는 간단한 Bash 플러그인을 생성합니다.

  1. oc-foo라는 파일을 생성합니다.

    플러그인 파일 이름을 지정할 때 다음 사항에 유의합니다.

    • 파일이 플러그인으로 인식되려면 oc- 또는 kubectl-로 시작되어야 합니다.
    • 파일 이름에 따라 플러그인을 호출하는 명령이 결정됩니다. 예를 들어 파일 이름이 oc-foo-bar인 플러그인은 oc foo bar 명령으로 호출할 수 있습니다. 명령에 대시를 포함하기 위해 밑줄을 사용할 수도 있습니다. 예를 들어 파일 이름이 oc-foo_bar인 플러그인은 oc foo-bar 명령으로 호출할 수 있습니다.
  2. 파일에 다음 콘텐츠를 추가합니다.

    #!/bin/bash
    
    # optional argument handling
    if [[ "$1" == "version" ]]
    then
        echo "1.0.0"
        exit 0
    fi
    
    # optional argument handling
    if [[ "$1" == "config" ]]
    then
        echo $KUBECONFIG
        exit 0
    fi
    
    echo "I am a plugin named kubectl-foo"

OpenShift Container Platform CLI용으로 이 플러그인을 설치한 후에는 oc foo 명령을 사용하여 호출할 수 있습니다.

추가 리소스

1.3.2. CLI 플러그인 설치 및 사용

OpenShift Container Platform CLI용 사용자 정의 플러그인을 작성한 후에는 플러그인을 설치해야 플러그인에서 제공하는 기능을 사용할 수 있습니다.

중요

OpenShift CLI 플러그인은 현재 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 고객은 출시 예정된 제품 기능을 프리뷰를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.

자세한 내용은 Red Hat 기술 프리뷰 기능 지원 범위를 참조하십시오.

사전 요구 사항

  • oc CLI 툴이 설치되어 있어야 합니다.
  • oc- 또는 kubectl-로 시작하는 CLI 플러그인 파일이 있어야 합니다.

절차

  1. 필요한 경우 플러그인 파일을 실행 가능하게 업데이트합니다.

    $ chmod +x <plugin_file>
  2. 파일을 PATH에 있는 임의의 위치(예: /usr/local/bin/)에 배치합니다.

    $ sudo mv <plugin_file> /usr/local/bin/.
  3. oc plugin list를 실행하여 플러그인이 나열되는지 확인합니다.

    $ oc plugin list

    출력 예

    The following compatible plugins are available:
    
    /usr/local/bin/<plugin_file>

    여기에 플러그인이 나열되지 않으면 파일이 oc- 또는 kubectl-로 시작하고, 실행 가능하며, PATH에 있는지 확인합니다.

  4. 플러그인에서 도입한 새 명령 또는 옵션을 호출합니다.

    예를 들어 샘플 플러그인 리포지터리에서 kubectl-ns 플러그인을 빌드하고 설치한 경우 다음 명령을 사용하여 현재 네임스페이스를 볼 수 있습니다.

    $ oc ns

    플러그인을 호출하는 명령은 플러그인 파일 이름에 따라 달라집니다. 예를 들어 파일 이름이 oc-foo-bar인 플러그인은 oc foo bar 명령으로 호출합니다.

1.4. OpenShift CLI developer 명령 참조

이 참조는 OpenShift CLI (oc) developer 명령에 대한 설명 및 예제 명령을 제공합니다. 관리자 명령의 경우 OpenShift CLI 관리자 명령 참조를 참조하십시오.

oc help를 실행하여 모든 명령을 나열하거나 oc <command> --help를 실행하여 특정 명령에 대한 추가 세부 정보를 가져옵니다.

1.4.1. OpenShift CLI (oc) 개발자 명령

1.4.1.1. oc annotate

리소스에서 주석 업데이트

사용 예

  # Update pod 'foo' with the annotation 'description' and the value 'my frontend'.
  # If the same annotation is set multiple times, only the last value will be applied
  oc annotate pods foo description='my frontend'

  # Update a pod identified by type and name in "pod.json"
  oc annotate -f pod.json description='my frontend'

  # Update pod 'foo' with the annotation 'description' and the value 'my frontend running nginx', overwriting any existing value.
  oc annotate --overwrite pods foo description='my frontend running nginx'

  # Update all pods in the namespace
  oc annotate pods --all description='my frontend running nginx'

  # Update pod 'foo' only if the resource is unchanged from version 1.
  oc annotate pods foo description='my frontend running nginx' --resource-version=1

  # Update pod 'foo' by removing an annotation named 'description' if it exists.
  # Does not require the --overwrite flag.
  oc annotate pods foo description-

1.4.1.2. oc api-resources

서버에서 지원되는 API 리소스 출력

사용 예

  # Print the supported API Resources
  oc api-resources

  # Print the supported API Resources with more information
  oc api-resources -o wide

  # Print the supported API Resources sorted by a column
  oc api-resources --sort-by=name

  # Print the supported namespaced resources
  oc api-resources --namespaced=true

  # Print the supported non-namespaced resources
  oc api-resources --namespaced=false

  # Print the supported API Resources with specific APIGroup
  oc api-resources --api-group=extensions

1.4.1.3. oc api-versions

"group/version" 형식으로 서버에서 지원되는 API 버전을 인쇄합니다.

사용 예

  # Print the supported API versions
  oc api-versions

1.4.1.4. oc apply

파일 이름 또는 stdin을 사용하여 리소스에 설정 적용

사용 예

  # Apply the configuration in pod.json to a pod.
  oc apply -f ./pod.json

  # Apply resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml.
  oc apply -k dir/

  # Apply the JSON passed into stdin to a pod.
  cat pod.json | oc apply -f -

  # Note: --prune is still in Alpha
  # Apply the configuration in manifest.yaml that matches label app=nginx and delete all the other resources that are not in the file and match label app=nginx.
  oc apply --prune -f manifest.yaml -l app=nginx

  # Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file.
  oc apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap

1.4.1.5. oc apply edit-last-applied

리소스/개체의 최신 last-applied-configuration 주석 편집

사용 예

  # Edit the last-applied-configuration annotations by type/name in YAML.
  oc apply edit-last-applied deployment/nginx

  # Edit the last-applied-configuration annotations by file in JSON.
  oc apply edit-last-applied -f deploy.yaml -o json

1.4.1.6. oc apply set-last-applied

파일의 내용과 일치하도록 라이브 오브젝트에 last-applied-configuration 주석을 설정합니다.

사용 예

  # Set the last-applied-configuration of a resource to match the contents of a file.
  oc apply set-last-applied -f deploy.yaml

  # Execute set-last-applied against each configuration file in a directory.
  oc apply set-last-applied -f path/

  # Set the last-applied-configuration of a resource to match the contents of a file, will create the annotation if it does not already exist.
  oc apply set-last-applied -f deploy.yaml --create-annotation=true

1.4.1.7. oc apply view-last-applied

리소스/개체의 최신 last-applied-configuration 주석 보기

사용 예

  # View the last-applied-configuration annotations by type/name in YAML.
  oc apply view-last-applied deployment/nginx

  # View the last-applied-configuration annotations by file in JSON
  oc apply view-last-applied -f deploy.yaml -o json

1.4.1.8. oc attach

실행 중인 컨테이너에 연결

사용 예

  # Get output from running pod mypod, use the oc.kubernetes.io/default-container annotation
  # for selecting the container to be attached or the first container in the pod will be chosen
  oc attach mypod

  # Get output from ruby-container from pod mypod
  oc attach mypod -c ruby-container

  # Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod mypod
  # and sends stdout/stderr from 'bash' back to the client
  oc attach mypod -c ruby-container -i -t

  # Get output from the first pod of a ReplicaSet named nginx
  oc attach rs/nginx

1.4.1.9. oc auth can-i

작업이 허용되는지 확인

사용 예

  # Check to see if I can create pods in any namespace
  oc auth can-i create pods --all-namespaces

  # Check to see if I can list deployments in my current namespace
  oc auth can-i list deployments.apps

  # Check to see if I can do everything in my current namespace ("*" means all)
  oc auth can-i '*' '*'

  # Check to see if I can get the job named "bar" in namespace "foo"
  oc auth can-i list jobs.batch/bar -n foo

  # Check to see if I can read pod logs
  oc auth can-i get pods --subresource=log

  # Check to see if I can access the URL /logs/
  oc auth can-i get /logs/

  # List all allowed actions in namespace "foo"
  oc auth can-i --list --namespace=foo

1.4.1.10. oc auth 조정

RBAC 역할, RoleBinding, ClusterRole 및 ClusterRoleBinding 오브젝트에 대한 규칙 조정

사용 예

  # Reconcile rbac resources from a file
  oc auth reconcile -f my-rbac-rules.yaml

1.4.1.11. oc autoscale

배포 구성, 배포, 복제본 세트, 상태 저장 세트 또는 복제 컨트롤러 자동 스케일링

사용 예

  # Auto scale a deployment "foo", with the number of pods between 2 and 10, no target CPU utilization specified so a default autoscaling policy will be used:
  oc autoscale deployment foo --min=2 --max=10

  # Auto scale a replication controller "foo", with the number of pods between 1 and 5, target CPU utilization at 80%:
  oc autoscale rc foo --max=5 --cpu-percent=80

1.4.1.12. oc cancel-build

실행 중, 보류 중 또는 새 빌드 취소

사용 예

  # Cancel the build with the given name
  oc cancel-build ruby-build-2

  # Cancel the named build and print the build logs
  oc cancel-build ruby-build-2 --dump-logs

  # Cancel the named build and create a new one with the same parameters
  oc cancel-build ruby-build-2 --restart

  # Cancel multiple builds
  oc cancel-build ruby-build-1 ruby-build-2 ruby-build-3

  # Cancel all builds created from the 'ruby-build' build config that are in the 'new' state
  oc cancel-build bc/ruby-build --state=new

1.4.1.13. oc cluster-info

클러스터 정보 표시

사용 예

  # Print the address of the control plane and cluster services
  oc cluster-info

1.4.1.14. oc cluster-info dump

디버깅 및 진단을 위해 관련 정보를 많이 덤프합니다.

사용 예

  # Dump current cluster state to stdout
  oc cluster-info dump

  # Dump current cluster state to /path/to/cluster-state
  oc cluster-info dump --output-directory=/path/to/cluster-state

  # Dump all namespaces to stdout
  oc cluster-info dump --all-namespaces

  # Dump a set of namespaces to /path/to/cluster-state
  oc cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state

1.4.1.15. oc completion

지정된 쉘에 대한 쉘 완료 코드 출력(bash 또는 zsh)

사용 예

  # Installing bash completion on macOS using homebrew
  ## If running Bash 3.2 included with macOS
  brew install bash-completion
  ## or, if running Bash 4.1+
  brew install bash-completion@2
  ## If oc is installed via homebrew, this should start working immediately.
  ## If you've installed via other means, you may need add the completion to your completion directory
  oc completion bash > $(brew --prefix)/etc/bash_completion.d/oc


  # Installing bash completion on Linux
  ## If bash-completion is not installed on Linux, please install the 'bash-completion' package
  ## via your distribution's package manager.
  ## Load the oc completion code for bash into the current shell
  source <(oc completion bash)
  ## Write bash completion code to a file and source it from .bash_profile
  oc completion bash > ~/.kube/completion.bash.inc
  printf "
  # Kubectl shell completion
  source '$HOME/.kube/completion.bash.inc'
  " >> $HOME/.bash_profile
  source $HOME/.bash_profile

  # Load the oc completion code for zsh[1] into the current shell
  source <(oc completion zsh)
  # Set the oc completion code for zsh[1] to autoload on startup
  oc completion zsh > "${fpath[1]}/_oc"

1.4.1.16. oc config current-context

현재 문맥 표시

사용 예

  # Display the current-context
  oc config current-context

1.4.1.17. oc config delete-cluster

kubeconfig에서 지정된 클러스터 삭제

사용 예

  # Delete the minikube cluster
  oc config delete-cluster minikube

1.4.1.18. oc config delete-context

kubeconfig에서 지정된 컨텍스트 삭제

사용 예

  # Delete the context for the minikube cluster
  oc config delete-context minikube

1.4.1.19. oc config delete-user

kubeconfig에서 지정된 사용자 삭제

사용 예

  # Delete the minikube user
  oc config delete-user minikube

1.4.1.20. oc config get-clusters

kubeconfig에 정의된 클러스터 표시

사용 예

  # List the clusters oc knows about
  oc config get-clusters

1.4.1.21. oc config get-contexts

하나 또는 여러 컨텍스트 설명

사용 예

  # List all the contexts in your kubeconfig file
  oc config get-contexts

  # Describe one context in your kubeconfig file.
  oc config get-contexts my-context

1.4.1.22. oc config get-users

kubeconfig에 정의된 사용자 표시

사용 예

  # List the users oc knows about
  oc config get-users

1.4.1.23. oc config rename-context

kubeconfig 파일에서 컨텍스트의 이름을 변경합니다.

사용 예

  # Rename the context 'old-name' to 'new-name' in your kubeconfig file
  oc config rename-context old-name new-name

1.4.1.24. oc config set

kubeconfig 파일에서 개별 값 설정

사용 예

  # Set server field on the my-cluster cluster to https://1.2.3.4
  oc config set clusters.my-cluster.server https://1.2.3.4

  # Set certificate-authority-data field on the my-cluster cluster.
  oc config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

  # Set cluster field in the my-context context to my-cluster.
  oc config set contexts.my-context.cluster my-cluster

  # Set client-key-data field in the cluster-admin user using --set-raw-bytes option.
  oc config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

1.4.1.25. oc config set-cluster

kubeconfig에서 클러스터 항목 설정

사용 예

  # Set only the server field on the e2e cluster entry without touching other values.
  oc config set-cluster e2e --server=https://1.2.3.4

  # Embed certificate authority data for the e2e cluster entry
  oc config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

  # Disable cert checking for the dev cluster entry
  oc config set-cluster e2e --insecure-skip-tls-verify=true

  # Set custom TLS server name to use for validation for the e2e cluster entry
  oc config set-cluster e2e --tls-server-name=my-cluster-name

1.4.1.26. oc config set-context

kubeconfig에서 컨텍스트 항목 설정

사용 예

  # Set the user field on the gce context entry without touching other values
  oc config set-context gce --user=cluster-admin

1.4.1.27. oc config set-credentials

kubeconfig에서 사용자 항목 설정

사용 예

  # Set only the "client-key" field on the "cluster-admin"
  # entry, without touching other values:
  oc config set-credentials cluster-admin --client-key=~/.kube/admin.key

  # Set basic auth for the "cluster-admin" entry
  oc config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

  # Embed client certificate data in the "cluster-admin" entry
  oc config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

  # Enable the Google Compute Platform auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=gcp

  # Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

  # Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

  # Enable new exec auth plugin for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

  # Define new exec auth plugin args for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

  # Create or update exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

  # Remove exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=var-to-remove-

1.4.1.28. oc config 설정 해제

kubeconfig 파일에서 개별 값 설정 해제

사용 예

  # Unset the current-context.
  oc config unset current-context

  # Unset namespace in foo context.
  oc config unset contexts.foo.namespace

1.4.1.29. oc config use-context

kubeconfig 파일에서 current-context 설정

사용 예

  # Use the context for the minikube cluster
  oc config use-context minikube

1.4.1.30. oc config view

병합된 kubeconfig 설정 또는 지정된 kubeconfig 파일 표시

사용 예

  # Show merged kubeconfig settings.
  oc config view

  # Show merged kubeconfig settings and raw certificate data.
  oc config view --raw

  # Get the password for the e2e user
  oc config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

1.4.1.31. oc cp

컨테이너 간에 파일 및 디렉터리를 복사합니다.

사용 예

  # !!!Important Note!!!
  # Requires that the 'tar' binary is present in your container
  # image.  If 'tar' is not present, 'oc cp' will fail.
  #
  # For advanced use cases, such as symlinks, wildcard expansion or
  # file mode preservation consider using 'oc exec'.

  # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace>
  tar cf - /tmp/foo | oc exec -i -n <some-namespace> <some-pod> -- tar xf - -C /tmp/bar

  # Copy /tmp/foo from a remote pod to /tmp/bar locally
  oc exec -n <some-namespace> <some-pod> -- tar cf - /tmp/foo | tar xf - -C /tmp/bar

  # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the default namespace
  oc cp /tmp/foo_dir <some-pod>:/tmp/bar_dir

  # Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container
  oc cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

  # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace>
  oc cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar

  # Copy /tmp/foo from a remote pod to /tmp/bar locally
  oc cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar

1.4.1.32. oc create

파일 또는 stdin에서 리소스를 만듭니다.

사용 예

  # Create a pod using the data in pod.json.
  oc create -f ./pod.json

  # Create a pod based on the JSON passed into stdin.
  cat pod.json | oc create -f -

  # Edit the data in docker-registry.yaml in JSON then create the resource using the edited data.
  oc create -f docker-registry.yaml --edit -o json

1.4.1.33. oc create build

새 빌드 만들기

사용 예

  # Create a new build
  oc create build myapp

1.4.1.34. oc create clusterresourcequota

클러스터 리소스 할당량 생성

사용 예

  # Create a cluster resource quota limited to 10 pods
  oc create clusterresourcequota limit-bob --project-annotation-selector=openshift.io/requester=user-bob --hard=pods=10

1.4.1.35. oc create clusterrole

ClusterRole 생성.

사용 예

  # Create a ClusterRole named "pod-reader" that allows user to perform "get", "watch" and "list" on pods
  oc create clusterrole pod-reader --verb=get,list,watch --resource=pods

  # Create a ClusterRole named "pod-reader" with ResourceName specified
  oc create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

  # Create a ClusterRole named "foo" with API Group specified
  oc create clusterrole foo --verb=get,list,watch --resource=rs.extensions

  # Create a ClusterRole named "foo" with SubResource specified
  oc create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

  # Create a ClusterRole name "foo" with NonResourceURL specified
  oc create clusterrole "foo" --verb=get --non-resource-url=/logs/*

  # Create a ClusterRole name "monitoring" with AggregationRule specified
  oc create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

1.4.1.36. oc create clusterrolebinding

특정 ClusterRole에 대한 ClusterRoleBinding 생성

사용 예

  # Create a ClusterRoleBinding for user1, user2, and group1 using the cluster-admin ClusterRole
  oc create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

1.4.1.37. oc create configmap

로컬 파일, 디렉토리 또는 리터럴 값에서 configmap 만들기

사용 예

  # Create a new configmap named my-config based on folder bar
  oc create configmap my-config --from-file=path/to/bar

  # Create a new configmap named my-config with specified keys instead of file basenames on disk
  oc create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt

  # Create a new configmap named my-config with key1=config1 and key2=config2
  oc create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

  # Create a new configmap named my-config from the key=value pairs in the file
  oc create configmap my-config --from-file=path/to/bar

  # Create a new configmap named my-config from an env file
  oc create configmap my-config --from-env-file=path/to/bar.env

1.4.1.38. oc create cronjob

지정된 이름으로 cronjob을 생성합니다.

사용 예

  # Create a cronjob
  oc create cronjob my-job --image=busybox --schedule="*/1 * * * *"

  # Create a cronjob with command
  oc create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

1.4.1.39. oc create deployment

지정된 이름으로 배포를 만듭니다.

사용 예

  # Create a deployment named my-dep that runs the busybox image.
  oc create deployment my-dep --image=busybox

  # Create a deployment with command
  oc create deployment my-dep --image=busybox -- date

  # Create a deployment named my-dep that runs the nginx image with 3 replicas.
  oc create deployment my-dep --image=nginx --replicas=3

  # Create a deployment named my-dep that runs the busybox image and expose port 5701.
  oc create deployment my-dep --image=busybox --port=5701

1.4.1.40. oc create deploymentconfig

지정된 이미지를 사용하는 기본 옵션으로 배포 구성 생성

사용 예

  # Create an nginx deployment config named my-nginx
  oc create deploymentconfig my-nginx --image=nginx

1.4.1.41. oc create identity

수동으로 ID 생성 (자동 생성이 비활성화된 경우에만 필요)

사용 예

  # Create an identity with identity provider "acme_ldap" and the identity provider username "adamjones"
  oc create identity acme_ldap:adamjones

1.4.1.42. oc create imagestream

비어 있는 새 이미지 스트림 생성

사용 예

  # Create a new image stream
  oc create imagestream mysql

1.4.1.43. oc create imagestreamtag

새 이미지 스트림 태그 만들기

사용 예

  # Create a new image stream tag based on an image in a remote registry
  oc create imagestreamtag mysql:latest --from-image=myregistry.local/mysql/mysql:5.0

1.4.1.44. oc create ingress

지정된 이름으로 인그레스를 만듭니다.

사용 예

  # Create a single ingress called 'simple' that directs requests to foo.com/bar to svc
  # svc1:8080 with a tls secret "my-cert"
  oc create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

  # Create a catch all ingress of "/path" pointing to service svc:port and Ingress Class as "otheringress"
  oc create ingress catch-all --class=otheringress --rule="/path=svc:port"

  # Create an ingress with two annotations: ingress.annotation1 and ingress.annotations2
  oc create ingress annotated --class=default --rule="foo.com/bar=svc:port" \
  --annotation ingress.annotation1=foo \
  --annotation ingress.annotation2=bla

  # Create an ingress with the same host and multiple paths
  oc create ingress multipath --class=default \
  --rule="foo.com/=svc:port" \
  --rule="foo.com/admin/=svcadmin:portadmin"

  # Create an ingress with multiple hosts and the pathType as Prefix
  oc create ingress ingress1 --class=default \
  --rule="foo.com/path*=svc:8080" \
  --rule="bar.com/admin*=svc2:http"

  # Create an ingress with TLS enabled using the default ingress certificate and different path types
  oc create ingress ingtls --class=default \
  --rule="foo.com/=svc:https,tls" \
  --rule="foo.com/path/subpath*=othersvc:8080"

  # Create an ingress with TLS enabled using a specific secret and pathType as Prefix
  oc create ingress ingsecret --class=default \
  --rule="foo.com/*=svc:8080,tls=secret1"

  # Create an ingress with a default backend
  oc create ingress ingdefault --class=default \
  --default-backend=defaultsvc:http \
  --rule="foo.com/*=svc:8080,tls=secret1"

1.4.1.45. oc create 작업

지정된 이름으로 작업을 만듭니다.

사용 예

  # Create a job
  oc create job my-job --image=busybox

  # Create a job with command
  oc create job my-job --image=busybox -- date

  # Create a job from a CronJob named "a-cronjob"
  oc create job test-job --from=cronjob/a-cronjob

1.4.1.46. oc create namespace

지정된 이름으로 네임 스페이스 만들기

사용 예

  # Create a new namespace named my-namespace
  oc create namespace my-namespace

1.4.1.47. oc create poddisruptionbudget

지정된 이름으로 Pod 중단 예산을 생성합니다.

사용 예

  # Create a pod disruption budget named my-pdb that will select all pods with the app=rails label
  # and require at least one of them being available at any point in time.
  oc create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

  # Create a pod disruption budget named my-pdb that will select all pods with the app=nginx label
  # and require at least half of the pods selected to be available at any point in time.
  oc create pdb my-pdb --selector=app=nginx --min-available=50%

1.4.1.48. oc create priorityclass

지정된 이름으로 priorityclass를 생성합니다.

사용 예

  # Create a priorityclass named high-priority
  oc create priorityclass high-priority --value=1000 --description="high priority"

  # Create a priorityclass named default-priority that considered as the global default priority
  oc create priorityclass default-priority --value=1000 --global-default=true --description="default priority"

  # Create a priorityclass named high-priority that can not preempt pods with lower priority
  oc create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

1.4.1.49. oc create quota

지정된 이름으로 할당량을 만듭니다.

사용 예

  # Create a new resourcequota named my-quota
  oc create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10

  # Create a new resourcequota named best-effort
  oc create quota best-effort --hard=pods=100 --scopes=BestEffort

1.4.1.50. oc create role

단일 규칙을 사용하여 역할을 만듭니다.

사용 예

  # Create a Role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods
  oc create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

  # Create a Role named "pod-reader" with ResourceName specified
  oc create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

  # Create a Role named "foo" with API Group specified
  oc create role foo --verb=get,list,watch --resource=rs.extensions

  # Create a Role named "foo" with SubResource specified
  oc create role foo --verb=get,list,watch --resource=pods,pods/status

1.4.1.51. oc create rolebinding

특정 역할 또는 ClusterRole에 대한 RoleBinding 만들기

사용 예

  # Create a RoleBinding for user1, user2, and group1 using the admin ClusterRole
  oc create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1

1.4.1.52. oc create route edge

엣지 TLS 종료를 사용하는 경로 만들기

사용 예

  # Create an edge route named "my-route" that exposes the frontend service
  oc create route edge my-route --service=frontend

  # Create an edge route that exposes the frontend service and specify a path
  # If the route name is omitted, the service name will be used
  oc create route edge --service=frontend --path /assets

1.4.1.53. oc create route passthrough

패스스루 TLS 종료를 사용하는 경로 만들기

사용 예

  # Create a passthrough route named "my-route" that exposes the frontend service
  oc create route passthrough my-route --service=frontend

  # Create a passthrough route that exposes the frontend service and specify
  # a host name. If the route name is omitted, the service name will be used
  oc create route passthrough --service=frontend --hostname=www.example.com

1.4.1.54. oc create route reencrypt

재암호화 TLS 종료를 사용하는 경로 만들기

사용 예

  # Create a route named "my-route" that exposes the frontend service
  oc create route reencrypt my-route --service=frontend --dest-ca-cert cert.cert

  # Create a reencrypt route that exposes the frontend service, letting the
  # route name default to the service name and the destination CA certificate
  # default to the service CA
  oc create route reencrypt --service=frontend

1.4.1.55. oc create secret docker-registry

Docker 레지스트리와 함께 사용할 시크릿 생성

사용 예

  # If you don't already have a .dockercfg file, you can create a dockercfg secret directly by using:
  oc create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

  # Create a new secret named my-secret from ~/.docker/config.json
  oc create secret docker-registry my-secret --from-file=.dockerconfigjson=path/to/.docker/config.json

1.4.1.56. oc create secret 일반

로컬 파일, 디렉터리 또는 리터럴 값에서 시크릿 생성

사용 예

  # Create a new secret named my-secret with keys for each file in folder bar
  oc create secret generic my-secret --from-file=path/to/bar

  # Create a new secret named my-secret with specified keys instead of names on disk
  oc create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-file=ssh-publickey=path/to/id_rsa.pub

  # Create a new secret named my-secret with key1=supersecret and key2=topsecret
  oc create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

  # Create a new secret named my-secret using a combination of a file and a literal
  oc create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

  # Create a new secret named my-secret from an env file
  oc create secret generic my-secret --from-env-file=path/to/bar.env

1.4.1.57. oc create secret tls

TLS 시크릿 만들기

사용 예

  # Create a new TLS secret named tls-secret with the given key pair:
  oc create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key

1.4.1.58. oc create service clusterip

ClusterIP 서비스를 생성합니다.

사용 예

  # Create a new ClusterIP service named my-cs
  oc create service clusterip my-cs --tcp=5678:8080

  # Create a new ClusterIP service named my-cs (in headless mode)
  oc create service clusterip my-cs --clusterip="None"

1.4.1.59. oc create service externalname

ExternalName 서비스를 생성합니다.

사용 예

  # Create a new ExternalName service named my-ns
  oc create service externalname my-ns --external-name bar.com

1.4.1.60. oc create service loadbalancer

LoadBalancer 서비스를 만듭니다.

사용 예

  # Create a new LoadBalancer service named my-lbs
  oc create service loadbalancer my-lbs --tcp=5678:8080

1.4.1.61. oc create service nodeport

NodePort 서비스를 생성합니다.

사용 예

  # Create a new NodePort service named my-ns
  oc create service nodeport my-ns --tcp=5678:8080

1.4.1.62. oc create serviceaccount

지정된 이름으로 서비스 계정 만들기

사용 예

  # Create a new service account named my-service-account
  oc create serviceaccount my-service-account

1.4.1.63. oc create user

사용자를 수동으로 만듭니다 (자동 생성이 비활성화된 경우에만 필요)

사용 예

  # Create a user with the username "ajones" and the display name "Adam Jones"
  oc create user ajones --full-name="Adam Jones"

1.4.1.64. oc create useridentitymapping

ID를 사용자에게 수동으로 매핑

사용 예

  # Map the identity "acme_ldap:adamjones" to the user "ajones"
  oc create useridentitymapping acme_ldap:adamjones ajones

1.4.1.65. oc debug

디버깅을 위해 Pod의 새 인스턴스를 시작합니다.

사용 예

  # Start a shell session into a pod using the OpenShift tools image
  oc debug

  # Debug a currently running deployment by creating a new pod
  oc debug deploy/test

  # Debug a node as an administrator
  oc debug node/master-1

  # Launch a shell in a pod using the provided image stream tag
  oc debug istag/mysql:latest -n openshift

  # Test running a job as a non-root user
  oc debug job/test --as-user=1000000

  # Debug a specific failing container by running the env command in the 'second' container
  oc debug daemonset/test -c second -- /bin/env

  # See the pod that would be created to debug
  oc debug mypod-9xbc -o yaml

  # Debug a resource but launch the debug pod in another namespace
  # Note: Not all resources can be debugged using --to-namespace without modification. For example,
  # volumes and service accounts are namespace-dependent. Add '-o yaml' to output the debug pod definition
  # to disk.  If necessary, edit the definition then run 'oc debug -f -' or run without --to-namespace
  oc debug mypod-9xbc --to-namespace testns

1.4.1.66. oc delete

파일 이름, stdin, 리소스 및 이름별 또는 리소스 및 레이블 선택기별 리소스 삭제

사용 예

  # Delete a pod using the type and name specified in pod.json.
  oc delete -f ./pod.json

  # Delete resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml.
  oc delete -k dir

  # Delete a pod based on the type and name in the JSON passed into stdin.
  cat pod.json | oc delete -f -

  # Delete pods and services with same names "baz" and "foo"
  oc delete pod,service baz foo

  # Delete pods and services with label name=myLabel.
  oc delete pods,services -l name=myLabel

  # Delete a pod with minimal delay
  oc delete pod foo --now

  # Force delete a pod on a dead node
  oc delete pod foo --force

  # Delete all pods
  oc delete pods --all

1.4.1.67. oc describe

특정 리소스 또는 리소스 그룹의 세부 정보 표시

사용 예

  # Describe a node
  oc describe nodes kubernetes-node-emt8.c.myproject.internal

  # Describe a pod
  oc describe pods/nginx

  # Describe a pod identified by type and name in "pod.json"
  oc describe -f pod.json

  # Describe all pods
  oc describe pods

  # Describe pods by label name=myLabel
  oc describe po -l name=myLabel

  # Describe all pods managed by the 'frontend' replication controller (rc-created pods
  # get the name of the rc as a prefix in the pod the name).
  oc describe pods frontend

1.4.1.68. oc diff

would에 대한 라이브 버전이 적용된 버전

사용 예

  # Diff resources included in pod.json.
  oc diff -f pod.json

  # Diff file read from stdin
  cat service.yaml | oc diff -f -

1.4.1.69. oc edit

서버의 리소스 편집

사용 예

  # Edit the service named 'docker-registry':
  oc edit svc/docker-registry

  # Use an alternative editor
  KUBE_EDITOR="nano" oc edit svc/docker-registry

  # Edit the job 'myjob' in JSON using the v1 API format:
  oc edit job.v1.batch/myjob -o json

  # Edit the deployment 'mydeployment' in YAML and save the modified config in its annotation:
  oc edit deployment/mydeployment -o yaml --save-config

1.4.1.70. oc ex dockergc

Docker 스토리지에서 공간을 확보하기 위해 가비지 컬렉션을 수행합니다.

사용 예

  # Perform garbage collection with the default settings
  oc ex dockergc

1.4.1.71. oc exec

컨테이너에서 명령 실행

사용 예

  # Get output from running 'date' command from pod mypod, using the first container by default
  oc exec mypod -- date

  # Get output from running 'date' command in ruby-container from pod mypod
  oc exec mypod -c ruby-container -- date

  # Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod mypod
  # and sends stdout/stderr from 'bash' back to the client
  oc exec mypod -c ruby-container -i -t -- bash -il

  # List contents of /usr from the first container of pod mypod and sort by modification time.
  # If the command you want to execute in the pod has any flags in common (e.g. -i),
  # you must use two dashes (--) to separate your command's flags/arguments.
  # Also note, do not surround your command and its flags/arguments with quotes
  # unless that is how you would execute it normally (i.e., do ls -t /usr, not "ls -t /usr").
  oc exec mypod -i -t -- ls -t /usr

  # Get output from running 'date' command from the first pod of the deployment mydeployment, using the first container by default
  oc exec deploy/mydeployment -- date

  # Get output from running 'date' command from the first pod of the service myservice, using the first container by default
  oc exec svc/myservice -- date

1.4.1.72. oc explain

리소스 문서

사용 예

  # Get the documentation of the resource and its fields
  oc explain pods

  # Get the documentation of a specific field of a resource
  oc explain pods.spec.containers

1.4.1.73. oc expose

복제된 애플리케이션을 서비스 또는 경로로 노출

사용 예

  # Create a route based on service nginx. The new route will reuse nginx's labels
  oc expose service nginx

  # Create a route and specify your own label and route name
  oc expose service nginx -l name=myroute --name=fromdowntown

  # Create a route and specify a host name
  oc expose service nginx --hostname=www.example.com

  # Create a route with a wildcard
  oc expose service nginx --hostname=x.example.com --wildcard-policy=Subdomain
  # This would be equivalent to *.example.com. NOTE: only hosts are matched by the wildcard; subdomains would not be included

  # Expose a deployment configuration as a service and use the specified port
  oc expose dc ruby-hello-world --port=8080

  # Expose a service as a route in the specified path
  oc expose service nginx --path=/nginx

  # Expose a service using different generators
  oc expose service nginx --name=exposed-svc --port=12201 --protocol="TCP" --generator="service/v2"
  oc expose service nginx --name=my-route --port=12201 --generator="route/v1"

  # Exposing a service using the "route/v1" generator (default) will create a new exposed route with the "--name" provided
  # (or the name of the service otherwise). You may not specify a "--protocol" or "--target-port" option when using this generator

1.4.1.74. oc extract

시크릿 또는 구성 맵을 디스크에 추출

사용 예

  # Extract the secret "test" to the current directory
  oc extract secret/test

  # Extract the config map "nginx" to the /tmp directory
  oc extract configmap/nginx --to=/tmp

  # Extract the config map "nginx" to STDOUT
  oc extract configmap/nginx --to=-

  # Extract only the key "nginx.conf" from config map "nginx" to the /tmp directory
  oc extract configmap/nginx --to=/tmp --keys=nginx.conf

1.4.1.75. oc get

하나 이상의 리소스 표시

사용 예

  # List all pods in ps output format.
  oc get pods

  # List all pods in ps output format with more information (such as node name).
  oc get pods -o wide

  # List a single replication controller with specified NAME in ps output format.
  oc get replicationcontroller web

  # List deployments in JSON output format, in the "v1" version of the "apps" API group:
  oc get deployments.v1.apps -o json

  # List a single pod in JSON output format.
  oc get -o json pod web-pod-13je7

  # List a pod identified by type and name specified in "pod.yaml" in JSON output format.
  oc get -f pod.yaml -o json

  # List resources from a directory with kustomization.yaml - e.g. dir/kustomization.yaml.
  oc get -k dir/

  # Return only the phase value of the specified pod.
  oc get -o template pod/web-pod-13je7 --template={{.status.phase}}

  # List resource information in custom columns.
  oc get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

  # List all replication controllers and services together in ps output format.
  oc get rc,services

  # List one or more resources by their type and names.
  oc get rc/web service/frontend pods/web-pod-13je7

1.4.1.76. oc idle

확장 가능한 리소스를 유휴 상태로 설정

사용 예

  # Idle the scalable controllers associated with the services listed in to-idle.txt
  $ oc idle --resource-names-file to-idle.txt

1.4.1.77. oc image append

이미지에 레이어를 추가하고 레지스트리에 푸시합니다.

사용 예

  # Remove the entrypoint on the mysql:latest image
  oc image append --from mysql:latest --to myregistry.com/myimage:latest --image '{"Entrypoint":null}'

  # Add a new layer to the image
  oc image append --from mysql:latest --to myregistry.com/myimage:latest layer.tar.gz

  # Add a new layer to the image and store the result on disk
  # This results in $(pwd)/v2/mysql/blobs,manifests
  oc image append --from mysql:latest --to file://mysql:local layer.tar.gz

  # Add a new layer to the image and store the result on disk in a designated directory
  # This will result in $(pwd)/mysql-local/v2/mysql/blobs,manifests
  oc image append --from mysql:latest --to file://mysql:local --dir mysql-local layer.tar.gz

  # Add a new layer to an image that is stored on disk (~/mysql-local/v2/image exists)
  oc image append --from-dir ~/mysql-local --to myregistry.com/myimage:latest layer.tar.gz

  # Add a new layer to an image that was mirrored to the current directory on disk ($(pwd)/v2/image exists)
  oc image append --from-dir v2 --to myregistry.com/myimage:latest layer.tar.gz

  # Add a new layer to a multi-architecture image for an os/arch that is different from the system's os/arch
  # Note: Wildcard filter is not supported with append. Pass a single os/arch to append
  oc image append --from docker.io/library/busybox:latest --filter-by-os=linux/s390x --to myregistry.com/myimage:latest layer.tar.gz

1.4.1.78. oc 이미지 추출

이미지의 파일 복사를 파일 시스템으로

사용 예

  # Extract the busybox image into the current directory
  oc image extract docker.io/library/busybox:latest

  # Extract the busybox image into a designated directory (must exist)
  oc image extract docker.io/library/busybox:latest --path /:/tmp/busybox

  # Extract the busybox image into the current directory for linux/s390x platform
  # Note: Wildcard filter is not supported with extract. Pass a single os/arch to extract
  oc image extract docker.io/library/busybox:latest --filter-by-os=linux/s390x

  # Extract a single file from the image into the current directory
  oc image extract docker.io/library/centos:7 --path /bin/bash:.

  # Extract all .repo files from the image's /etc/yum.repos.d/ folder into the current directory
  oc image extract docker.io/library/centos:7 --path /etc/yum.repos.d/*.repo:.

  # Extract all .repo files from the image's /etc/yum.repos.d/ folder into a designated directory (must exist)
  # This results in /tmp/yum.repos.d/*.repo on local system
  oc image extract docker.io/library/centos:7 --path /etc/yum.repos.d/*.repo:/tmp/yum.repos.d

  # Extract an image stored on disk into the current directory ($(pwd)/v2/busybox/blobs,manifests exists)
  # --confirm is required because the current directory is not empty
  oc image extract file://busybox:local --confirm

  # Extract an image stored on disk in a directory other than $(pwd)/v2 into the current directory
  # --confirm is required because the current directory is not empty ($(pwd)/busybox-mirror-dir/v2/busybox exists)
  oc image extract file://busybox:local --dir busybox-mirror-dir --confirm

  # Extract an image stored on disk in a directory other than $(pwd)/v2 into a designated directory (must exist)
  oc image extract file://busybox:local --dir busybox-mirror-dir --path /:/tmp/busybox

  # Extract the last layer in the image
  oc image extract docker.io/library/centos:7[-1]

  # Extract the first three layers of the image
  oc image extract docker.io/library/centos:7[:3]

  # Extract the last three layers of the image
  oc image extract docker.io/library/centos:7[-3:]

1.4.1.79. oc 이미지 정보

이미지에 대한 정보 표시

사용 예

  # Show information about an image
  oc image info quay.io/openshift/cli:latest

  # Show information about images matching a wildcard
  oc image info quay.io/openshift/cli:4.*

  # Show information about a file mirrored to disk under DIR
  oc image info --dir=DIR file://library/busybox:latest

  # Select which image from a multi-OS image to show
  oc image info library/busybox:latest --filter-by-os=linux/arm64

1.4.1.80. oc 이미지 미러

한 저장소에서 다른 저장소로 이미지를 미러링

사용 예

  # Copy image to another tag
  oc image mirror myregistry.com/myimage:latest myregistry.com/myimage:stable

  # Copy image to another registry
  oc image mirror myregistry.com/myimage:latest docker.io/myrepository/myimage:stable

  # Copy all tags starting with mysql to the destination repository
  oc image mirror myregistry.com/myimage:mysql* docker.io/myrepository/myimage

  # Copy image to disk, creating a directory structure that can be served as a registry
  oc image mirror myregistry.com/myimage:latest file://myrepository/myimage:latest

  # Copy image to S3 (pull from <bucket>.s3.amazonaws.com/image:latest)
  oc image mirror myregistry.com/myimage:latest s3://s3.amazonaws.com/<region>/<bucket>/image:latest

  # Copy image to S3 without setting a tag (pull via @<digest>)
  oc image mirror myregistry.com/myimage:latest s3://s3.amazonaws.com/<region>/<bucket>/image

  # Copy image to multiple locations
  oc image mirror myregistry.com/myimage:latest docker.io/myrepository/myimage:stable \
  docker.io/myrepository/myimage:dev

  # Copy multiple images
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  myregistry.com/myimage:new=myregistry.com/other:target

  # Copy manifest list of a multi-architecture image, even if only a single image is found
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --keep-manifest-list=true

  # Copy specific os/arch manifest of a multi-architecture image
  # Run 'oc image info myregistry.com/myimage:latest' to see available os/arch for multi-arch images
  # Note that with multi-arch images, this results in a new manifest list digest that includes only
  # the filtered manifests
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --filter-by-os=os/arch

  # Copy all os/arch manifests of a multi-architecture image
  # Run 'oc image info myregistry.com/myimage:latest' to see list of os/arch manifests that will be mirrored
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --keep-manifest-list=true

  # Note the above command is equivalent to
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --filter-by-os=.*

1.4.1.81. oc import-image

컨테이너 이미지 레지스트리에서 이미지 가져오기

사용 예

  # Import tag latest into a new image stream
  oc import-image mystream --from=registry.io/repo/image:latest --confirm

  # Update imported data for tag latest in an already existing image stream
  oc import-image mystream

  # Update imported data for tag stable in an already existing image stream
  oc import-image mystream:stable

  # Update imported data for all tags in an existing image stream
  oc import-image mystream --all

  # Import all tags into a new image stream
  oc import-image mystream --from=registry.io/repo/image --all --confirm

  # Import all tags into a new image stream using a custom timeout
  oc --request-timeout=5m import-image mystream --from=registry.io/repo/image --all --confirm

1.4.1.82. oc kustomize

디렉터리 또는 URL에서 kustomization 대상을 빌드합니다.

사용 예

  # Build the current working directory
  oc kustomize

  # Build some shared configuration directory
  oc kustomize /home/config/production

  # Build from github
  oc kustomize https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?ref=v1.0.6

1.4.1.83. oc label

리소스에서 라벨 업데이트

사용 예

  # Update pod 'foo' with the label 'unhealthy' and the value 'true'.
  oc label pods foo unhealthy=true

  # Update pod 'foo' with the label 'status' and the value 'unhealthy', overwriting any existing value.
  oc label --overwrite pods foo status=unhealthy

  # Update all pods in the namespace
  oc label pods --all status=unhealthy

  # Update a pod identified by the type and name in "pod.json"
  oc label -f pod.json status=unhealthy

  # Update pod 'foo' only if the resource is unchanged from version 1.
  oc label pods foo status=unhealthy --resource-version=1

  # Update pod 'foo' by removing a label named 'bar' if it exists.
  # Does not require the --overwrite flag.
  oc label pods foo bar-

1.4.1.84. oc login

서버에 로그인

사용 예

  # Log in interactively
  oc login --username=myuser

  # Log in to the given server with the given certificate authority file
  oc login localhost:8443 --certificate-authority=/path/to/cert.crt

  # Log in to the given server with the given credentials (will not prompt interactively)
  oc login localhost:8443 --username=myuser --password=mypass

1.4.1.85. oc logout

현재 서버 세션 종료

사용 예

  # Log out
  oc logout

1.4.1.86. oc logs

Pod에서 컨테이너의 로그 출력

사용 예

  # Start streaming the logs of the most recent build of the openldap build config
  oc logs -f bc/openldap

  # Start streaming the logs of the latest deployment of the mysql deployment config
  oc logs -f dc/mysql

  # Get the logs of the first deployment for the mysql deployment config. Note that logs
  # from older deployments may not exist either because the deployment was successful
  # or due to deployment pruning or manual deletion of the deployment
  oc logs --version=1 dc/mysql

  # Return a snapshot of ruby-container logs from pod backend
  oc logs backend -c ruby-container

  # Start streaming of ruby-container logs from pod backend
  oc logs -f pod/backend -c ruby-container

1.4.1.87. oc new-app

새 애플리케이션 만들기

사용 예

  # List all local templates and image streams that can be used to create an app
  oc new-app --list

  # Create an application based on the source code in the current git repository (with a public remote) and a Docker image
  oc new-app . --docker-image=registry/repo/langimage

  # Create an application myapp with Docker based build strategy expecting binary input
  oc new-app  --strategy=docker --binary --name myapp

  # Create a Ruby application based on the provided [image]~[source code] combination
  oc new-app centos/ruby-25-centos7~https://github.com/sclorg/ruby-ex.git

  # Use the public Docker Hub MySQL image to create an app. Generated artifacts will be labeled with db=mysql
  oc new-app mysql MYSQL_USER=user MYSQL_PASSWORD=pass MYSQL_DATABASE=testdb -l db=mysql

  # Use a MySQL image in a private registry to create an app and override application artifacts' names
  oc new-app --docker-image=myregistry.com/mycompany/mysql --name=private

  # Create an application from a remote repository using its beta4 branch
  oc new-app https://github.com/openshift/ruby-hello-world#beta4

  # Create an application based on a stored template, explicitly setting a parameter value
  oc new-app --template=ruby-helloworld-sample --param=MYSQL_USER=admin

  # Create an application from a remote repository and specify a context directory
  oc new-app https://github.com/youruser/yourgitrepo --context-dir=src/build

  # Create an application from a remote private repository and specify which existing secret to use
  oc new-app https://github.com/youruser/yourgitrepo --source-secret=yoursecret

  # Create an application based on a template file, explicitly setting a parameter value
  oc new-app --file=./example/myapp/template.json --param=MYSQL_USER=admin

  # Search all templates, image streams, and Docker images for the ones that match "ruby"
  oc new-app --search ruby

  # Search for "ruby", but only in stored templates (--template, --image-stream and --docker-image
  # can be used to filter search results)
  oc new-app --search --template=ruby

  # Search for "ruby" in stored templates and print the output as YAML
  oc new-app --search --template=ruby --output=yaml

1.4.1.88. oc new-build

새 빌드 구성 만들기

사용 예

  # Create a build config based on the source code in the current git repository (with a public
  # remote) and a Docker image
  oc new-build . --docker-image=repo/langimage

  # Create a NodeJS build config based on the provided [image]~[source code] combination
  oc new-build centos/nodejs-8-centos7~https://github.com/sclorg/nodejs-ex.git

  # Create a build config from a remote repository using its beta2 branch
  oc new-build https://github.com/openshift/ruby-hello-world#beta2

  # Create a build config using a Dockerfile specified as an argument
  oc new-build -D $'FROM centos:7\nRUN yum install -y httpd'

  # Create a build config from a remote repository and add custom environment variables
  oc new-build https://github.com/openshift/ruby-hello-world -e RACK_ENV=development

  # Create a build config from a remote private repository and specify which existing secret to use
  oc new-build https://github.com/youruser/yourgitrepo --source-secret=yoursecret

  # Create a build config from a remote repository and inject the npmrc into a build
  oc new-build https://github.com/openshift/ruby-hello-world --build-secret npmrc:.npmrc

  # Create a build config from a remote repository and inject environment data into a build
  oc new-build https://github.com/openshift/ruby-hello-world --build-config-map env:config

  # Create a build config that gets its input from a remote repository and another Docker image
  oc new-build https://github.com/openshift/ruby-hello-world --source-image=openshift/jenkins-1-centos7 --source-image-path=/var/lib/jenkins:tmp

1.4.1.89. oc new-project

새 프로젝트 요청

사용 예

  # Create a new project with minimal information
  oc new-project web-team-dev

  # Create a new project with a display name and description
  oc new-project web-team-dev --display-name="Web Team Development" --description="Development project for the web team."

1.4.1.90. oc observe

리소스에 대한 변경 사항을 관찰하고 이에 대응합니다(시험)

사용 예

  # Observe changes to services
  oc observe services

  # Observe changes to services, including the clusterIP and invoke a script for each
  oc observe services --template '{ .spec.clusterIP }' -- register_dns.sh

  # Observe changes to services filtered by a label selector
  oc observe namespaces -l regist-dns=true --template '{ .spec.clusterIP }' -- register_dns.sh

1.4.1.91. oc patch

리소스 필드 업데이트

사용 예

  # Partially update a node using a strategic merge patch. Specify the patch as JSON.
  oc patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

  # Partially update a node using a strategic merge patch. Specify the patch as YAML.
  oc patch node k8s-node-1 -p $'spec:\n unschedulable: true'

  # Partially update a node identified by the type and name specified in "node.json" using strategic merge patch.
  oc patch -f node.json -p '{"spec":{"unschedulable":true}}'

  # Update a container's image; spec.containers[*].name is required because it's a merge key.
  oc patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

  # Update a container's image using a json patch with positional arrays.
  oc patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

1.4.1.92. oc policy add-role-to-user

현재 프로젝트의 사용자 또는 서비스 계정에 역할 추가

사용 예

  # Add the 'view' role to user1 for the current project
  oc policy add-role-to-user view user1

  # Add the 'edit' role to serviceaccount1 for the current project
  oc policy add-role-to-user edit -z serviceaccount1

1.4.1.93. oc policy scc-review

Pod를 생성할 수 있는 서비스 계정 확인

사용 예

  # Check whether service accounts sa1 and sa2 can admit a pod with a template pod spec specified in my_resource.yaml
  # Service Account specified in myresource.yaml file is ignored
  oc policy scc-review -z sa1,sa2 -f my_resource.yaml

  # Check whether service accounts system:serviceaccount:bob:default can admit a pod with a template pod spec specified in my_resource.yaml
  oc policy scc-review -z system:serviceaccount:bob:default -f my_resource.yaml

  # Check whether the service account specified in my_resource_with_sa.yaml can admit the pod
  oc policy scc-review -f my_resource_with_sa.yaml

  # Check whether the default service account can admit the pod; default is taken since no service account is defined in myresource_with_no_sa.yaml
  oc policy scc-review -f myresource_with_no_sa.yaml

1.4.1.94. oc policy scc-subject-review

사용자 또는 서비스 계정이 Pod를 생성할 수 있는지 확인

사용 예

  # Check whether user bob can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -f myresource.yaml

  # Check whether user bob who belongs to projectAdmin group can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -g projectAdmin -f myresource.yaml

  # Check whether a service account specified in the pod template spec in myresourcewithsa.yaml can create the pod
  oc policy scc-subject-review -f myresourcewithsa.yaml

1.4.1.95. oc port-forward

Pod에 하나 이상의 로컬 포트를 전달합니다

사용 예

  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
  oc port-forward pod/mypod 5000 6000

  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the deployment
  oc port-forward deployment/mydeployment 5000 6000

  # Listen on port 8443 locally, forwarding to the targetPort of the service's port named "https" in a pod selected by the service
  oc port-forward service/myservice 8443:https

  # Listen on port 8888 locally, forwarding to 5000 in the pod
  oc port-forward pod/mypod 8888:5000

  # Listen on port 8888 on all addresses, forwarding to 5000 in the pod
  oc port-forward --address 0.0.0.0 pod/mypod 8888:5000

  # Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod
  oc port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000

  # Listen on a random port locally, forwarding to 5000 in the pod
  oc port-forward pod/mypod :5000

1.4.1.96. oc process

템플릿을 리소스 목록으로 처리

사용 예

  # Convert the template.json file into a resource list and pass to create
  oc process -f template.json | oc create -f -

  # Process a file locally instead of contacting the server
  oc process -f template.json --local -o yaml

  # Process template while passing a user-defined label
  oc process -f template.json -l name=mytemplate

  # Convert a stored template into a resource list
  oc process foo

  # Convert a stored template into a resource list by setting/overriding parameter values
  oc process foo PARM1=VALUE1 PARM2=VALUE2

  # Convert a template stored in different namespace into a resource list
  oc process openshift//foo

  # Convert template.json into a resource list
  cat template.json | oc process -f -

1.4.1.97. oc project

다른 프로젝트로 전환

사용 예

  # Switch to the 'myapp' project
  oc project myapp

  # Display the project currently in use
  oc project

1.4.1.98. oc projects

기존 프로젝트 표시

사용 예

  # List all projects
  oc projects

1.4.1.99. oc proxy

Kubernetes API 서버에 대한 프록시 실행

사용 예

  # To proxy all of the kubernetes api and nothing else.
  oc proxy --api-prefix=/

  # To proxy only part of the kubernetes api and also some static files.
  # You can get pods info with 'curl localhost:8001/api/v1/pods'
  oc proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/

  # To proxy the entire kubernetes api at a different root.
  # You can get pods info with 'curl localhost:8001/custom/api/v1/pods'
  oc proxy --api-prefix=/custom/

  # Run a proxy to kubernetes apiserver on port 8011, serving static content from ./local/www/
  oc proxy --port=8011 --www=./local/www/

  # Run a proxy to kubernetes apiserver on an arbitrary local port.
  # The chosen port for the server will be output to stdout.
  oc proxy --port=0

  # Run a proxy to kubernetes apiserver, changing the api prefix to k8s-api
  # This makes e.g. the pods api available at localhost:8001/k8s-api/v1/pods/
  oc proxy --api-prefix=/k8s-api

1.4.1.100. oc 레지스트리 정보

통합 레지스트리에 대한 정보 인쇄

사용 예

  # Display information about the integrated registry
  oc registry info

1.4.1.101. oc 레지스트리 로그인

통합 레지스트리에 로그인

사용 예

  # Log in to the integrated registry
  oc registry login

  # Log in as the default service account in the current namespace
  oc registry login -z default

  # Log in to different registry using BASIC auth credentials
  oc registry login --registry quay.io/myregistry --auth-basic=USER:PASS

1.4.1.102. oc replace

리소스를 파일 이름 또는 stdin으로 교체

사용 예

  # Replace a pod using the data in pod.json.
  oc replace -f ./pod.json

  # Replace a pod based on the JSON passed into stdin.
  cat pod.json | oc replace -f -

  # Update a single-container pod's image version (tag) to v4
  oc get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | oc replace -f -

  # Force replace, delete and then re-create the resource
  oc replace --force -f ./pod.json

1.4.1.103. oc 롤백

애플리케이션의 일부를 이전 배포로 되돌리기

사용 예

  # Perform a rollback to the last successfully completed deployment for a deployment config
  oc rollback frontend

  # See what a rollback to version 3 will look like, but do not perform the rollback
  oc rollback frontend --to-version=3 --dry-run

  # Perform a rollback to a specific deployment
  oc rollback frontend-2

  # Perform the rollback manually by piping the JSON of the new config back to oc
  oc rollback frontend -o json | oc replace dc/frontend -f -

  # Print the updated deployment configuration in JSON format instead of performing the rollback
  oc rollback frontend -o json

1.4.1.104. oc rollout cancel

진행 중인 배포를 취소합니다

사용 예

  # Cancel the in-progress deployment based on 'nginx'
  oc rollout cancel dc/nginx

1.4.1.105. oc 롤아웃 내역

롤아웃 내역 보기

사용 예

  # View the rollout history of a deployment
  oc rollout history dc/nginx

  # View the details of deployment revision 3
  oc rollout history dc/nginx --revision=3

1.4.1.106. oc rollout latest

트리거의 최신 상태로 배포 구성에 대한 새 롤아웃 시작

사용 예

  # Start a new rollout based on the latest images defined in the image change triggers
  oc rollout latest dc/nginx

  # Print the rolled out deployment config
  oc rollout latest dc/nginx -o json

1.4.1.107. oc 롤아웃 일시 중지

제공된 리소스를 일시 중지됨으로 표시

사용 예

  # Mark the nginx deployment as paused. Any current state of
  # the deployment will continue its function, new updates to the deployment will not
  # have an effect as long as the deployment is paused
  oc rollout pause dc/nginx

1.4.1.108. oc rollout restart

리소스 재시작

사용 예

  # Restart a deployment
  oc rollout restart deployment/nginx

  # Restart a daemonset
  oc rollout restart daemonset/abc

1.4.1.109. oc rollout restart

일시 중지된 리소스 재개

사용 예

  # Resume an already paused deployment
  oc rollout resume dc/nginx

1.4.1.110. oc rollout 재시도

가장 최근에 실패한 롤아웃 재시도

사용 예

  # Retry the latest failed deployment based on 'frontend'
  # The deployer pod and any hook pods are deleted for the latest failed deployment
  oc rollout retry dc/frontend

1.4.1.111. oc rollout 상태

롤아웃 상태 표시

사용 예

  # Watch the status of the latest rollout
  oc rollout status dc/nginx

1.4.1.112. oc rollout undo

이전 롤아웃 실행 취소

사용 예

  # Roll back to the previous deployment
  oc rollout undo dc/nginx

  # Roll back to deployment revision 3. The replication controller for that version must exist
  oc rollout undo dc/nginx --to-revision=3

1.4.1.113. oc rsh

컨테이너에서 쉘 세션 시작

사용 예

  # Open a shell session on the first container in pod 'foo'
  oc rsh foo

  # Open a shell session on the first container in pod 'foo' and namespace 'bar'
  # (Note that oc client specific arguments must come before the resource name and its arguments)
  oc rsh -n bar foo

  # Run the command 'cat /etc/resolv.conf' inside pod 'foo'
  oc rsh foo cat /etc/resolv.conf

  # See the configuration of your internal registry
  oc rsh dc/docker-registry cat config.yml

  # Open a shell session on the container named 'index' inside a pod of your job
  oc rsh -c index job/sheduled

1.4.1.114. oc rsync

로컬 파일 시스템과 Pod 간 파일 복사

사용 예

  # Synchronize a local directory with a pod directory
  oc rsync ./local/dir/ POD:/remote/dir

  # Synchronize a pod directory with a local directory
  oc rsync POD:/remote/dir/ ./local/dir

1.4.1.115. oc run

클러스터에서 특정 이미지 실행

사용 예

  # Start a nginx pod.
  oc run nginx --image=nginx

  # Start a hazelcast pod and let the container expose port 5701.
  oc run hazelcast --image=hazelcast/hazelcast --port=5701

  # Start a hazelcast pod and set environment variables "DNS_DOMAIN=cluster" and "POD_NAMESPACE=default" in the container.
  oc run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"

  # Start a hazelcast pod and set labels "app=hazelcast" and "env=prod" in the container.
  oc run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"

  # Dry run. Print the corresponding API objects without creating them.
  oc run nginx --image=nginx --dry-run=client

  # Start a nginx pod, but overload the spec with a partial set of values parsed from JSON.
  oc run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'

  # Start a busybox pod and keep it in the foreground, don't restart it if it exits.
  oc run -i -t busybox --image=busybox --restart=Never

  # Start the nginx pod using the default command, but use custom arguments (arg1 .. argN) for that command.
  oc run nginx --image=nginx -- <arg1> <arg2> ... <argN>

  # Start the nginx pod using a different command and custom arguments.
  oc run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>

1.4.1.116. oc scale

Deployment, ReplicaSet 또는 복제 컨트롤러의 새 크기 설정

사용 예

  # Scale a replicaset named 'foo' to 3.
  oc scale --replicas=3 rs/foo

  # Scale a resource identified by type and name specified in "foo.yaml" to 3.
  oc scale --replicas=3 -f foo.yaml

  # If the deployment named mysql's current size is 2, scale mysql to 3.
  oc scale --current-replicas=2 --replicas=3 deployment/mysql

  # Scale multiple replication controllers.
  oc scale --replicas=5 rc/foo rc/bar rc/baz

  # Scale statefulset named 'web' to 3.
  oc scale --replicas=3 statefulset/web

1.4.1.119. oc serviceaccounts create-kubeconfig

서비스 계정에 대한 kubeconfig 파일 생성

사용 예

  # Create a kubeconfig file for service account 'default'
  oc serviceaccounts create-kubeconfig 'default' > default.kubeconfig

1.4.1.120. oc serviceaccounts get-token

서비스 계정에 토큰 할당

사용 예

  # Get the service account token from service account 'default'
  oc serviceaccounts get-token 'default'

1.4.1.121. oc serviceaccounts new-token

서비스 계정에 대한 새 토큰 생성

사용 예

  # Generate a new token for service account 'default'
  oc serviceaccounts new-token 'default'

  # Generate a new token for service account 'default' and apply
  # labels 'foo' and 'bar' to the new token for identification
  oc serviceaccounts new-token 'default' --labels foo=foo-value,bar=bar-value

1.4.1.122. oc set build-hook

빌드 구성에서 빌드 후크 업데이트

사용 예

  # Clear post-commit hook on a build config
  oc set build-hook bc/mybuild --post-commit --remove

  # Set the post-commit hook to execute a test suite using a new entrypoint
  oc set build-hook bc/mybuild --post-commit --command -- /bin/bash -c /var/lib/test-image.sh

  # Set the post-commit hook to execute a shell script
  oc set build-hook bc/mybuild --post-commit --script="/var/lib/test-image.sh param1 param2 && /var/lib/done.sh"

1.4.1.123. oc set build-secret

빌드 구성에서 빌드 보안 업데이트

사용 예

  # Clear the push secret on a build config
  oc set build-secret --push --remove bc/mybuild

  # Set the pull secret on a build config
  oc set build-secret --pull bc/mybuild mysecret

  # Set the push and pull secret on a build config
  oc set build-secret --push --pull bc/mybuild mysecret

  # Set the source secret on a set of build configs matching a selector
  oc set build-secret --source -l app=myapp gitsecret

1.4.1.124. oc set data

구성 맵 또는 시크릿 내의 데이터 업데이트

사용 예

  # Set the 'password' key of a secret
  oc set data secret/foo password=this_is_secret

  # Remove the 'password' key from a secret
  oc set data secret/foo password-

  # Update the 'haproxy.conf' key of a config map from a file on disk
  oc set data configmap/bar --from-file=../haproxy.conf

  # Update a secret with the contents of a directory, one key per file
  oc set data secret/foo --from-file=secret-dir

1.4.1.125. oc set deployment-hook

배포 구성에서 배포 후크 업데이트

사용 예

  # Clear pre and post hooks on a deployment config
  oc set deployment-hook dc/myapp --remove --pre --post

  # Set the pre deployment hook to execute a db migration command for an application
  # using the data volume from the application
  oc set deployment-hook dc/myapp --pre --volumes=data -- /var/lib/migrate-db.sh

  # Set a mid deployment hook along with additional environment variables
  oc set deployment-hook dc/myapp --mid --volumes=data -e VAR1=value1 -e VAR2=value2 -- /var/lib/prepare-deploy.sh

1.4.1.126. oc set env

Pod 템플릿에서 환경 변수 업데이트

사용 예

  # Update deployment config 'myapp' with a new environment variable
  oc set env dc/myapp STORAGE_DIR=/local

  # List the environment variables defined on a build config 'sample-build'
  oc set env bc/sample-build --list

  # List the environment variables defined on all pods
  oc set env pods --all --list

  # Output modified build config in YAML
  oc set env bc/sample-build STORAGE_DIR=/data -o yaml

  # Update all containers in all replication controllers in the project to have ENV=prod
  oc set env rc --all ENV=prod

  # Import environment from a secret
  oc set env --from=secret/mysecret dc/myapp

  # Import environment from a config map with a prefix
  oc set env --from=configmap/myconfigmap --prefix=MYSQL_ dc/myapp

  # Remove the environment variable ENV from container 'c1' in all deployment configs
  oc set env dc --all --containers="c1" ENV-

  # Remove the environment variable ENV from a deployment config definition on disk and
  # update the deployment config on the server
  oc set env -f dc.json ENV-

  # Set some of the local shell environment into a deployment config on the server
  oc set env | grep RAILS_ | oc env -e - dc/myapp

1.4.1.127. oc set image

Pod 템플릿 이미지 업데이트

사용 예

  # Set a deployment configs's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'.
  oc set image dc/nginx busybox=busybox nginx=nginx:1.9.1

  # Set a deployment configs's app container image to the image referenced by the imagestream tag 'openshift/ruby:2.3'.
  oc set image dc/myapp app=openshift/ruby:2.3 --source=imagestreamtag

  # Update all deployments' and rc's nginx container's image to 'nginx:1.9.1'
  oc set image deployments,rc nginx=nginx:1.9.1 --all

  # Update image of all containers of daemonset abc to 'nginx:1.9.1'
  oc set image daemonset abc *=nginx:1.9.1

  # Print result (in yaml format) of updating nginx container image from local file, without hitting the server
  oc set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

1.4.1.128. oc set image-lookup

애플리케이션을 배포할 때 이미지가 해결되는 방법 변경

사용 예

  # Print all of the image streams and whether they resolve local names
  oc set image-lookup

  # Use local name lookup on image stream mysql
  oc set image-lookup mysql

  # Force a deployment to use local name lookup
  oc set image-lookup deploy/mysql

  # Show the current status of the deployment lookup
  oc set image-lookup deploy/mysql --list

  # Disable local name lookup on image stream mysql
  oc set image-lookup mysql --enabled=false

  # Set local name lookup on all image streams
  oc set image-lookup --all

1.4.1.129. oc set probe

Pod 템플릿에서 프로브 업데이트

사용 예

  # Clear both readiness and liveness probes off all containers
  oc set probe dc/myapp --remove --readiness --liveness

  # Set an exec action as a liveness probe to run 'echo ok'
  oc set probe dc/myapp --liveness -- echo ok

  # Set a readiness probe to try to open a TCP socket on 3306
  oc set probe rc/mysql --readiness --open-tcp=3306

  # Set an HTTP startup probe for port 8080 and path /healthz over HTTP on the pod IP
  oc probe dc/webapp --startup --get-url=http://:8080/healthz

  # Set an HTTP readiness probe for port 8080 and path /healthz over HTTP on the pod IP
  oc probe dc/webapp --readiness --get-url=http://:8080/healthz

  # Set an HTTP readiness probe over HTTPS on 127.0.0.1 for a hostNetwork pod
  oc set probe dc/router --readiness --get-url=https://127.0.0.1:1936/stats

  # Set only the initial-delay-seconds field on all deployments
  oc set probe dc --all --readiness --initial-delay-seconds=30

1.4.1.130. oc set 리소스

Pod 템플릿을 사용하여 오브젝트에서 리소스 요청/제한 업데이트

사용 예

  # Set a deployments nginx container CPU limits to "200m and memory to 512Mi"
  oc set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi

  # Set the resource request and limits for all containers in nginx
  oc set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

  # Remove the resource requests for resources on containers in nginx
  oc set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

  # Print the result (in YAML format) of updating nginx container limits locally, without hitting the server
  oc set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml

1.4.1.131. oc set route-backends

경로의 백엔드 업데이트

사용 예

  # Print the backends on the route 'web'
  oc set route-backends web

  # Set two backend services on route 'web' with 2/3rds of traffic going to 'a'
  oc set route-backends web a=2 b=1

  # Increase the traffic percentage going to b by 10%% relative to a
  oc set route-backends web --adjust b=+10%%

  # Set traffic percentage going to b to 10%% of the traffic going to a
  oc set route-backends web --adjust b=10%%

  # Set weight of b to 10
  oc set route-backends web --adjust b=10

  # Set the weight to all backends to zero
  oc set route-backends web --zero

1.4.1.132. oc set selector

리소스에 선택기 설정

사용 예

  # Set the labels and selector before creating a deployment/service pair.
  oc create service clusterip my-svc --clusterip="None" -o yaml --dry-run | oc set selector --local -f - 'environment=qa' -o yaml | oc create -f -
  oc create deployment my-dep -o yaml --dry-run | oc label --local -f - environment=qa -o yaml | oc create -f -

1.4.1.133. oc set serviceaccount

리소스의 ServiceAccount 업데이트

사용 예

  # Set deployment nginx-deployment's service account to serviceaccount1
  oc set serviceaccount deployment nginx-deployment serviceaccount1

  # Print the result (in YAML format) of updated nginx deployment with service account from a local file, without hitting the API server
  oc set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run -o yaml

1.4.1.134. oc set subject

RoleBinding/ClusterRoleBinding에서 사용자, 그룹 또는 서비스 계정 업데이트

사용 예

  # Update a cluster role binding for serviceaccount1
  oc set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1

  # Update a role binding for user1, user2, and group1
  oc set subject rolebinding admin --user=user1 --user=user2 --group=group1

  # Print the result (in YAML format) of updating role binding subjects locally, without hitting the server
  oc create rolebinding admin --role=admin --user=admin -o yaml --dry-run | oc set subject --local -f - --user=foo -o yaml

1.4.1.135. oc set triggers

하나 이상의 오브젝트에서 트리거 업데이트

사용 예

  # Print the triggers on the deployment config 'myapp'
  oc set triggers dc/myapp

  # Set all triggers to manual
  oc set triggers dc/myapp --manual

  # Enable all automatic triggers
  oc set triggers dc/myapp --auto

  # Reset the GitHub webhook on a build to a new, generated secret
  oc set triggers bc/webapp --from-github
  oc set triggers bc/webapp --from-webhook

  # Remove all triggers
  oc set triggers bc/webapp --remove-all

  # Stop triggering on config change
  oc set triggers dc/myapp --from-config --remove

  # Add an image trigger to a build config
  oc set triggers bc/webapp --from-image=namespace1/image:latest

  # Add an image trigger to a stateful set on the main container
  oc set triggers statefulset/db --from-image=namespace1/image:latest -c main

1.4.1.136. oc set volumes

Pod 템플릿에서 볼륨 업데이트

사용 예

  # List volumes defined on all deployment configs in the current project
  oc set volume dc --all

  # Add a new empty dir volume to deployment config (dc) 'myapp' mounted under
  # /var/lib/myapp
  oc set volume dc/myapp --add --mount-path=/var/lib/myapp

  # Use an existing persistent volume claim (pvc) to overwrite an existing volume 'v1'
  oc set volume dc/myapp --add --name=v1 -t pvc --claim-name=pvc1 --overwrite

  # Remove volume 'v1' from deployment config 'myapp'
  oc set volume dc/myapp --remove --name=v1

  # Create a new persistent volume claim that overwrites an existing volume 'v1'
  oc set volume dc/myapp --add --name=v1 -t pvc --claim-size=1G --overwrite

  # Change the mount point for volume 'v1' to /data
  oc set volume dc/myapp --add --name=v1 -m /data --overwrite

  # Modify the deployment config by removing volume mount "v1" from container "c1"
  # (and by removing the volume "v1" if no other containers have volume mounts that reference it)
  oc set volume dc/myapp --remove --name=v1 --containers=c1

  # Add new volume based on a more complex volume source (AWS EBS, GCE PD,
  # Ceph, Gluster, NFS, ISCSI, ...)
  oc set volume dc/myapp --add -m /data --source=<json-string>

1.4.1.137. oc start-build

새 빌드 시작

사용 예

  # Starts build from build config "hello-world"
  oc start-build hello-world

  # Starts build from a previous build "hello-world-1"
  oc start-build --from-build=hello-world-1

  # Use the contents of a directory as build input
  oc start-build hello-world --from-dir=src/

  # Send the contents of a Git repository to the server from tag 'v2'
  oc start-build hello-world --from-repo=../hello-world --commit=v2

  # Start a new build for build config "hello-world" and watch the logs until the build
  # completes or fails
  oc start-build hello-world --follow

  # Start a new build for build config "hello-world" and wait until the build completes. It
  # exits with a non-zero return code if the build fails
  oc start-build hello-world --wait

1.4.1.138. oc status

현재 프로젝트의 개요 표시

사용 예

  # See an overview of the current project
  oc status

  # Export the overview of the current project in an svg file
  oc status -o dot | dot -T svg -o project.svg

  # See an overview of the current project including details for any identified issues
  oc status --suggest

1.4.1.139. oc tag

기존 이미지에 이미지 스트림 태그

사용 예

  # Tag the current image for the image stream 'openshift/ruby' and tag '2.0' into the image stream 'yourproject/ruby with tag 'tip'
  oc tag openshift/ruby:2.0 yourproject/ruby:tip

  # Tag a specific image
  oc tag openshift/ruby@sha256:6b646fa6bf5e5e4c7fa41056c27910e679c03ebe7f93e361e6515a9da7e258cc yourproject/ruby:tip

  # Tag an external container image
  oc tag --source=docker openshift/origin-control-plane:latest yourproject/ruby:tip

  # Tag an external container image and request pullthrough for it
  oc tag --source=docker openshift/origin-control-plane:latest yourproject/ruby:tip --reference-policy=local

  # Remove the specified spec tag from an image stream
  oc tag openshift/origin-control-plane:latest -d

1.4.1.140. oc 버전

클라이언트 및 서버 버전 정보 출력

사용 예

  # Print the OpenShift client, kube-apiserver, and openshift-apiserver version information for the current context
  oc version

  # Print the OpenShift client, kube-apiserver, and openshift-apiserver version numbers for the current context
  oc version --short

  # Print the OpenShift client version information for the current context
  oc version --client

1.4.1.141. oc wait

실험적: 하나 이상의 리소스에서 특정 조건을 기다립니다.

사용 예

  # Wait for the pod "busybox1" to contain the status condition of type "Ready".
  oc wait --for=condition=Ready pod/busybox1

  # The default value of status condition is true, you can set false.
  oc wait --for=condition=Ready=false pod/busybox1

  # Wait for the pod "busybox1" to be deleted, with a timeout of 60s, after having issued the "delete" command.
  oc delete pod/busybox1
  oc wait --for=delete pod/busybox1 --timeout=60s

1.4.1.142. oc whoami

현재 세션에 대한 정보 반환

사용 예

  # Display the currently authenticated user
  oc whoami

1.4.2. 추가 리소스

1.5. OpenShift CLI 관리자 명령 참조

이 참조는 OpenShiftCLI(oc)관리자 명령에 대한 설명 및 예제 명령을 제공합니다. 개발자 명령의 경우 OpenShift CLI developer 명령 참조를 참조하십시오.

oc adm help를 실행하여 모든 관리자 명령을 나열하거나 oc <command> --help를 실행하여 특정 명령에 대한 추가 세부 정보를 가져옵니다.

1.5.1. OpenShift CLI (oc) 관리자 명령

1.5.1.1. oc adm build-chain

빌드의 입력 및 종속 항목 출력

사용 예

  # Build the dependency tree for the 'latest' tag in <image-stream>
  oc adm build-chain <image-stream>

  # Build the dependency tree for the 'v2' tag in dot format and visualize it via the dot utility
  oc adm build-chain <image-stream>:v2 -o dot | dot -T svg -o deps.svg

  # Build the dependency tree across all namespaces for the specified image stream tag found in the 'test' namespace
  oc adm build-chain <image-stream> -n test --all

1.5.1.2. oc adm catalog mirror

operator-registry 카탈로그 미러링

사용 예

  # Mirror an operator-registry image and its contents to a registry
  oc adm catalog mirror quay.io/my/image:latest myregistry.com

  # Mirror an operator-registry image and its contents to a particular namespace in a registry
  oc adm catalog mirror quay.io/my/image:latest myregistry.com/my-namespace

  # Mirror to an airgapped registry by first mirroring to files
  oc adm catalog mirror quay.io/my/image:latest file:///local/index
  oc adm catalog mirror file:///local/index/my/image:latest my-airgapped-registry.com

  # Configure a cluster to use a mirrored registry
  oc apply -f manifests/imageContentSourcePolicy.yaml

  # Edit the mirroring mappings and mirror with "oc image mirror" manually
  oc adm catalog mirror --manifests-only quay.io/my/image:latest myregistry.com
  oc image mirror -f manifests/mapping.txt

  # Delete all ImageContentSourcePolicies generated by oc adm catalog mirror
  oc delete imagecontentsourcepolicy -l operators.openshift.org/catalog=true

1.5.1.3. oc adm completion

지정된 쉘에 대한 쉘 완료 코드 출력(bash 또는 zsh)

사용 예

  # Installing bash completion on macOS using homebrew
  ## If running Bash 3.2 included with macOS
  brew install bash-completion
  ## or, if running Bash 4.1+
  brew install bash-completion@2
  ## If oc is installed via homebrew, this should start working immediately.
  ## If you've installed via other means, you may need add the completion to your completion directory
  oc completion bash > $(brew --prefix)/etc/bash_completion.d/oc


  # Installing bash completion on Linux
  ## If bash-completion is not installed on Linux, please install the 'bash-completion' package
  ## via your distribution's package manager.
  ## Load the oc completion code for bash into the current shell
  source <(oc completion bash)
  ## Write bash completion code to a file and source it from .bash_profile
  oc completion bash > ~/.kube/completion.bash.inc
  printf "
  # Kubectl shell completion
  source '$HOME/.kube/completion.bash.inc'
  " >> $HOME/.bash_profile
  source $HOME/.bash_profile

  # Load the oc completion code for zsh[1] into the current shell
  source <(oc completion zsh)
  # Set the oc completion code for zsh[1] to autoload on startup
  oc completion zsh > "${fpath[1]}/_oc"

1.5.1.4. oc adm config current-context

현재 문맥 표시

사용 예

  # Display the current-context
  oc config current-context

1.5.1.5. oc adm config delete-cluster

kubeconfig에서 지정된 클러스터 삭제

사용 예

  # Delete the minikube cluster
  oc config delete-cluster minikube

1.5.1.6. oc adm config delete-context

kubeconfig에서 지정된 컨텍스트 삭제

사용 예

  # Delete the context for the minikube cluster
  oc config delete-context minikube

1.5.1.7. oc adm config delete-user

kubeconfig에서 지정된 사용자 삭제

사용 예

  # Delete the minikube user
  oc config delete-user minikube

1.5.1.8. oc adm config get-clusters

kubeconfig에 정의된 클러스터 표시

사용 예

  # List the clusters oc knows about
  oc config get-clusters

1.5.1.9. oc adm config get-contexts

하나 또는 여러 컨텍스트 설명

사용 예

  # List all the contexts in your kubeconfig file
  oc config get-contexts

  # Describe one context in your kubeconfig file.
  oc config get-contexts my-context

1.5.1.10. oc adm config get-users

kubeconfig에 정의된 사용자 표시

사용 예

  # List the users oc knows about
  oc config get-users

1.5.1.11. oc adm config rename-context

kubeconfig 파일에서 컨텍스트의 이름을 변경합니다.

사용 예

  # Rename the context 'old-name' to 'new-name' in your kubeconfig file
  oc config rename-context old-name new-name

1.5.1.12. oc adm config set

kubeconfig 파일에서 개별 값 설정

사용 예

  # Set server field on the my-cluster cluster to https://1.2.3.4
  oc config set clusters.my-cluster.server https://1.2.3.4

  # Set certificate-authority-data field on the my-cluster cluster.
  oc config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

  # Set cluster field in the my-context context to my-cluster.
  oc config set contexts.my-context.cluster my-cluster

  # Set client-key-data field in the cluster-admin user using --set-raw-bytes option.
  oc config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

1.5.1.13. oc adm config set-cluster

kubeconfig에서 클러스터 항목 설정

사용 예

  # Set only the server field on the e2e cluster entry without touching other values.
  oc config set-cluster e2e --server=https://1.2.3.4

  # Embed certificate authority data for the e2e cluster entry
  oc config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

  # Disable cert checking for the dev cluster entry
  oc config set-cluster e2e --insecure-skip-tls-verify=true

  # Set custom TLS server name to use for validation for the e2e cluster entry
  oc config set-cluster e2e --tls-server-name=my-cluster-name

1.5.1.14. oc adm config set-context

kubeconfig에서 컨텍스트 항목 설정

사용 예

  # Set the user field on the gce context entry without touching other values
  oc config set-context gce --user=cluster-admin

1.5.1.15. oc adm config set-credentials

kubeconfig에서 사용자 항목 설정

사용 예

  # Set only the "client-key" field on the "cluster-admin"
  # entry, without touching other values:
  oc config set-credentials cluster-admin --client-key=~/.kube/admin.key

  # Set basic auth for the "cluster-admin" entry
  oc config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

  # Embed client certificate data in the "cluster-admin" entry
  oc config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

  # Enable the Google Compute Platform auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=gcp

  # Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

  # Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

  # Enable new exec auth plugin for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

  # Define new exec auth plugin args for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

  # Create or update exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

  # Remove exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=var-to-remove-

1.5.1.16. oc adm config unset

kubeconfig 파일에서 개별 값 설정 해제

사용 예

  # Unset the current-context.
  oc config unset current-context

  # Unset namespace in foo context.
  oc config unset contexts.foo.namespace

1.5.1.17. oc adm config use-context

kubeconfig 파일에서 current-context 설정

사용 예

  # Use the context for the minikube cluster
  oc config use-context minikube

1.5.1.18. oc adm config view

병합된 kubeconfig 설정 또는 지정된 kubeconfig 파일 표시

사용 예

  # Show merged kubeconfig settings.
  oc config view

  # Show merged kubeconfig settings and raw certificate data.
  oc config view --raw

  # Get the password for the e2e user
  oc config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

1.5.1.19. oc adm cordon

노드를 예약 불가로 표시

사용 예

  # Mark node "foo" as unschedulable.
  oc adm cordon foo

1.5.1.20. oc adm create-bootstrap-project-template

부트스트랩 프로젝트 템플릿 생성

사용 예

  # Output a bootstrap project template in YAML format to stdout
  oc adm create-bootstrap-project-template -o yaml

1.5.1.21. oc adm create-error-template

오류 페이지 템플릿 생성

사용 예

  # Output a template for the error page to stdout
  oc adm create-error-template

1.5.1.22. oc adm create-login-template

로그인 템플릿 만들기

사용 예

  # Output a template for the login page to stdout
  oc adm create-login-template

1.5.1.23. oc adm create-provider-selection-template

공급자 선택 템플릿 생성

사용 예

  # Output a template for the provider selection page to stdout
  oc adm create-provider-selection-template

1.5.1.24. oc adm drain

유지보수를 위해 노드 드레이닝

사용 예

  # Drain node "foo", even if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet on it.
  $ oc adm drain foo --force

  # As above, but abort if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet, and use a grace period of 15 minutes.
  $ oc adm drain foo --grace-period=900

1.5.1.25. oc adm groups add-users

그룹에 사용자 추가

사용 예

  # Add user1 and user2 to my-group
  oc adm groups add-users my-group user1 user2

1.5.1.26. oc adm groups new

새 그룹 만들기

사용 예

  # Add a group with no users
  oc adm groups new my-group

  # Add a group with two users
  oc adm groups new my-group user1 user2

  # Add a group with one user and shorter output
  oc adm groups new my-group user1 -o name

1.5.1.27. oc adm groups prune

외부 공급자에서 누락된 레코드를 참조하는 이전 OpenShift 그룹 제거

사용 예

  # Prune all orphaned groups
  oc adm groups prune --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups except the ones from the blacklist file
  oc adm groups prune --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist file
  oc adm groups prune --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist
  oc adm groups prune groups/group_name groups/other_name --sync-config=/path/to/ldap-sync-config.yaml --confirm

1.5.1.28. oc adm groups remove-users

그룹에서 사용자 제거

사용 예

  # Remove user1 and user2 from my-group
  oc adm groups remove-users my-group user1 user2

1.5.1.29. oc adm groups sync

외부 프로바이더의 레코드와 OpenShift 그룹 동기화

사용 예

  # Sync all groups with an LDAP server
  oc adm groups sync --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Sync all groups except the ones from the blacklist file with an LDAP server
  oc adm groups sync --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Sync specific groups specified in a whitelist file with an LDAP server
  oc adm groups sync --whitelist=/path/to/whitelist.txt --sync-config=/path/to/sync-config.yaml --confirm

  # Sync all OpenShift groups that have been synced previously with an LDAP server
  oc adm groups sync --type=openshift --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Sync specific OpenShift groups if they have been synced previously with an LDAP server
  oc adm groups sync groups/group1 groups/group2 groups/group3 --sync-config=/path/to/sync-config.yaml --confirm

1.5.1.30. oc adm inspect

지정된 리소스에 대한 디버깅 데이터 수집

사용 예

  # Collect debugging data for the "openshift-apiserver" clusteroperator
  oc adm inspect clusteroperator/openshift-apiserver

  # Collect debugging data for the "openshift-apiserver" and "kube-apiserver" clusteroperators
  oc adm inspect clusteroperator/openshift-apiserver clusteroperator/kube-apiserver

  # Collect debugging data for all clusteroperators
  oc adm inspect clusteroperator

  # Collect debugging data for all clusteroperators and clusterversions
  oc adm inspect clusteroperators,clusterversions

1.5.1.31. oc adm migrate template-instances

최신 group-version-kinds를 가리키도록 템플릿 인스턴스를 업데이트합니다.

사용 예

  # Perform a dry-run of updating all objects
  oc adm migrate template-instances

  # To actually perform the update, the confirm flag must be appended
  oc adm migrate template-instances --confirm

1.5.1.32. oc adm must-gather

디버그 정보 수집을 위해 Pod의 새 인스턴스를 시작합니다.

사용 예

  # Gather information using the default plug-in image and command, writing into ./must-gather.local.<rand>
  oc adm must-gather

  # Gather information with a specific local folder to copy to
  oc adm must-gather --dest-dir=/local/directory

  # Gather audit information
  oc adm must-gather -- /usr/bin/gather_audit_logs

  # Gather information using multiple plug-in images
  oc adm must-gather --image=quay.io/kubevirt/must-gather --image=quay.io/openshift/origin-must-gather

  # Gather information using a specific image stream plug-in
  oc adm must-gather --image-stream=openshift/must-gather:latest

  # Gather information using a specific image, command, and pod-dir
  oc adm must-gather --image=my/image:tag --source-dir=/pod/directory -- myspecial-command.sh

1.5.1.33. oc adm new-project

새 프로젝트 만들기

사용 예

  # Create a new project using a node selector
  oc adm new-project myproject --node-selector='type=user-node,region=east'

1.5.1.34. oc adm node-logs

노드 로그 표시 및 필터링

사용 예

  # Show kubelet logs from all masters
  oc adm node-logs --role master -u kubelet

  # See what logs are available in masters in /var/logs
  oc adm node-logs --role master --path=/

  # Display cron log file from all masters
  oc adm node-logs --role master --path=cron

1.5.1.35. oc adm pod-network isolate-projects

프로젝트 네트워크 격리

사용 예

  # Provide isolation for project p1
  oc adm pod-network isolate-projects <p1>

  # Allow all projects with label name=top-secret to have their own isolated project network
  oc adm pod-network isolate-projects --selector='name=top-secret'

1.5.1.36. oc adm pod-network join-projects

프로젝트 네트워크 참여

사용 예

  # Allow project p2 to use project p1 network
  oc adm pod-network join-projects --to=<p1> <p2>

  # Allow all projects with label name=top-secret to use project p1 network
  oc adm pod-network join-projects --to=<p1> --selector='name=top-secret'

1.5.1.37. oc adm pod-network make-projects-global

프로젝트 네트워크 글로벌 만들기

사용 예

  # Allow project p1 to access all pods in the cluster and vice versa
  oc adm pod-network make-projects-global <p1>

  # Allow all projects with label name=share to access all pods in the cluster and vice versa
  oc adm pod-network make-projects-global --selector='name=share'

1.5.1.38. oc adm policy add-role-to-user

현재 프로젝트의 사용자 또는 서비스 계정에 역할 추가

사용 예

  # Add the 'view' role to user1 for the current project
  oc policy add-role-to-user view user1

  # Add the 'edit' role to serviceaccount1 for the current project
  oc policy add-role-to-user edit -z serviceaccount1

1.5.1.39. oc adm policy add-scc-to-group

그룹에 보안 컨텍스트 제약 조건 추가

사용 예

  # Add the 'restricted' security context constraint to group1 and group2
  oc adm policy add-scc-to-group restricted group1 group2

1.5.1.40. oc adm policy add-scc-to-user

사용자 또는 서비스 계정에 보안 컨텍스트 제약 조건 추가

사용 예

  # Add the 'restricted' security context constraint to user1 and user2
  oc adm policy add-scc-to-user restricted user1 user2

  # Add the 'privileged' security context constraint to serviceaccount1 in the current namespace
  oc adm policy add-scc-to-user privileged -z serviceaccount1

1.5.1.41. oc adm policy scc-review

Pod를 생성할 수 있는 서비스 계정 확인

사용 예

  # Check whether service accounts sa1 and sa2 can admit a pod with a template pod spec specified in my_resource.yaml
  # Service Account specified in myresource.yaml file is ignored
  oc policy scc-review -z sa1,sa2 -f my_resource.yaml

  # Check whether service accounts system:serviceaccount:bob:default can admit a pod with a template pod spec specified in my_resource.yaml
  oc policy scc-review -z system:serviceaccount:bob:default -f my_resource.yaml

  # Check whether the service account specified in my_resource_with_sa.yaml can admit the pod
  oc policy scc-review -f my_resource_with_sa.yaml

  # Check whether the default service account can admit the pod; default is taken since no service account is defined in myresource_with_no_sa.yaml
  oc policy scc-review -f myresource_with_no_sa.yaml

1.5.1.42. oc adm policy scc-subject-review

사용자 또는 서비스 계정이 Pod를 생성할 수 있는지 확인

사용 예

  # Check whether user bob can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -f myresource.yaml

  # Check whether user bob who belongs to projectAdmin group can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -g projectAdmin -f myresource.yaml

  # Check whether a service account specified in the pod template spec in myresourcewithsa.yaml can create the pod
  oc policy scc-subject-review -f myresourcewithsa.yaml

1.5.1.43. oc adm prune 빌드

이전 빌드 및 실패한 빌드 삭제

사용 예

  # Dry run deleting older completed and failed builds and also including
  # all builds whose associated build config no longer exists
  oc adm prune builds --orphans

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune builds --orphans --confirm

1.5.1.44. oc adm prune deployment

이전 완료 및 실패한 배포 구성 제거

사용 예

  # Dry run deleting all but the last complete deployment for every deployment config
  oc adm prune deployments --keep-complete=1

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune deployments --keep-complete=1 --confirm

1.5.1.45. oc adm prune groups

외부 공급자에서 누락된 레코드를 참조하는 이전 OpenShift 그룹 제거

사용 예

  # Prune all orphaned groups
  oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups except the ones from the blacklist file
  oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist file
  oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist
  oc adm prune groups groups/group_name groups/other_name --sync-config=/path/to/ldap-sync-config.yaml --confirm

1.5.1.46. oc adm prune images

권장되지 않은 이미지 제거

사용 예

  # See what the prune command would delete if only images and their referrers were more than an hour old
  # and obsoleted by 3 newer revisions under the same tag were considered
  oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

  # See what the prune command would delete if we are interested in removing images
  # exceeding currently set limit ranges ('openshift.io/Image')
  oc adm prune images --prune-over-size-limit

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune images --prune-over-size-limit --confirm

  # Force the insecure http protocol with the particular registry host name
  oc adm prune images --registry-url=http://registry.example.org --confirm

  # Force a secure connection with a custom certificate authority to the particular registry host name
  oc adm prune images --registry-url=registry.example.org --certificate-authority=/path/to/custom/ca.crt --confirm

1.5.1.47. oc adm release extract

업데이트 페이로드 내용을 디스크에 추출

사용 예

  # Use git to check out the source code for the current cluster release to DIR
  oc adm release extract --git=DIR

  # Extract cloud credential requests for AWS
  oc adm release extract --credentials-requests --cloud=aws

1.5.1.48. oc adm release info

릴리스에 대한 정보 표시

사용 예

  # Show information about the cluster's current release
  oc adm release info

  # Show the source code that comprises a release
  oc adm release info 4.2.2 --commit-urls

  # Show the source code difference between two releases
  oc adm release info 4.2.0 4.2.2 --commits

  # Show where the images referenced by the release are located
  oc adm release info quay.io/openshift-release-dev/ocp-release:4.2.2 --pullspecs

1.5.1.49. oc adm release mirror

다른 이미지 레지스트리 위치에 릴리스 미러링

사용 예

  # Perform a dry run showing what would be mirrored, including the mirror objects
  oc adm release mirror 4.3.0 --to myregistry.local/openshift/release \
  --release-image-signature-to-dir /tmp/releases --dry-run

  # Mirror a release into the current directory
  oc adm release mirror 4.3.0 --to file://openshift/release \
  --release-image-signature-to-dir /tmp/releases

  # Mirror a release to another directory in the default location
  oc adm release mirror 4.3.0 --to-dir /tmp/releases

  # Upload a release from the current directory to another server
  oc adm release mirror --from file://openshift/release --to myregistry.com/openshift/release \
  --release-image-signature-to-dir /tmp/releases

  # Mirror the 4.3.0 release to repository registry.example.com and apply signatures to connected cluster
  oc adm release mirror --from=quay.io/openshift-release-dev/ocp-release:4.3.0-x86_64 \
  --to=registry.example.com/your/repository --apply-release-image-signature

1.5.1.50. oc adm release new

새 OpenShift 릴리스 만들기

사용 예

  # Create a release from the latest origin images and push to a DockerHub repo
  oc adm release new --from-image-stream=4.1 -n origin --to-image docker.io/mycompany/myrepo:latest

  # Create a new release with updated metadata from a previous release
  oc adm release new --from-release registry.svc.ci.openshift.org/origin/release:v4.1 --name 4.1.1 \
  --previous 4.1.0 --metadata ... --to-image docker.io/mycompany/myrepo:latest

  # Create a new release and override a single image
  oc adm release new --from-release registry.svc.ci.openshift.org/origin/release:v4.1 \
  cli=docker.io/mycompany/cli:latest --to-image docker.io/mycompany/myrepo:latest

  # Run a verification pass to ensure the release can be reproduced
  oc adm release new --from-release registry.svc.ci.openshift.org/origin/release:v4.1

1.5.1.51. oc adm taint

하나 이상의 노드에서 테인트 업데이트

사용 예

  # Update node 'foo' with a taint with key 'dedicated' and value 'special-user' and effect 'NoSchedule'.
  # If a taint with that key and effect already exists, its value is replaced as specified.
  oc adm taint nodes foo dedicated=special-user:NoSchedule

  # Remove from node 'foo' the taint with key 'dedicated' and effect 'NoSchedule' if one exists.
  oc adm taint nodes foo dedicated:NoSchedule-

  # Remove from node 'foo' all the taints with key 'dedicated'
  oc adm taint nodes foo dedicated-

  # Add a taint with key 'dedicated' on nodes having label mylabel=X
  oc adm taint node -l myLabel=X  dedicated=foo:PreferNoSchedule

  # Add to node 'foo' a taint with key 'bar' and no value
  oc adm taint nodes foo bar:NoSchedule

1.5.1.52. oc adm top images

이미지의 사용량 통계 표시

사용 예

  # Show usage statistics for images
  oc adm top images

1.5.1.53. oc adm top 이미지 스트림

이미지 스트림의 사용량 통계 표시

사용 예

  # Show usage statistics for image streams
  oc adm top imagestreams

1.5.1.54. oc adm top node

노드의 리소스 (CPU/Memory) 사용 표시

사용 예

  # Show metrics for all nodes
  oc adm top node

  # Show metrics for a given node
  oc adm top node NODE_NAME

1.5.1.55. oc adm top pod

Pod의 리소스 (CPU/Memory) 사용 표시

사용 예

  # Show metrics for all pods in the default namespace
  oc adm top pod

  # Show metrics for all pods in the given namespace
  oc adm top pod --namespace=NAMESPACE

  # Show metrics for a given pod and its containers
  oc adm top pod POD_NAME --containers

  # Show metrics for the pods defined by label name=myLabel
  oc adm top pod -l name=myLabel

1.5.1.56. oc adm uncordon

노드를 예약 가능으로 표시

사용 예

  # Mark node "foo" as schedulable.
  $ oc adm uncordon foo

1.5.1.57. oc adm verify-image-signature

이미지 서명에 포함된 이미지 ID 확인

사용 예

  # Verify the image signature and identity using the local GPG keychain
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 \
  --expected-identity=registry.local:5000/foo/bar:v1

  # Verify the image signature and identity using the local GPG keychain and save the status
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 \
  --expected-identity=registry.local:5000/foo/bar:v1 --save

  # Verify the image signature and identity via exposed registry route
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 \
  --expected-identity=registry.local:5000/foo/bar:v1 \
  --registry-url=docker-registry.foo.com

  # Remove all signature verifications from the image
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 --remove-all

1.5.2. 추가 리소스

1.6. oc 및 kubectl 명령 사용

Kubernetes CLI(명령줄 인터페이스), kubectl은 Kubernetes 클러스터에 대해 명령을 실행하는 데 사용할 수 있습니다. OpenShift Container Platform은 인증된 Kubernetes 배포판이므로 OpenShift Container Platform과 함께 제공된 지원되는 kubectl 바이너리를 사용할 수도 있고 oc 바이너리를 사용하여 확장 기능을 받을 수도 있습니다.

1.6.1. oc 바이너리

oc 바이너리는 kubectl 바이너리와 동일한 기능을 제공하지만 다음을 비롯하여 추가 OpenShift Container Platform 기능을 지원하도록 기본적으로 확장됩니다.

  • OpenShift Container Platform 리소스 전체 지원

    DeploymentConfig, BuildConfig, Route, ImageStreamImageStreamTag 오브젝트와 같은 리소스는 OpenShift Container Platform 배포판에 고유하며 표준 Kubernetes 프리미티브에 빌드됩니다.

  • 인증

    oc 바이너리에서 제공하는 기본 login 명령은 인증을 허용하며 Kubernetes 네임스페이스를 인증된 사용자에 매핑하는 OpenShift Container Platform 프로젝트 작업을 지원합니다. 자세한 내용은 인증 이해를 참조하십시오.

  • 추가 명령

    예를 들어 추가 명령 oc new-app을 사용하면 기존 소스 코드 또는 미리 빌드된 이미지를 사용하여 새 애플리케이션을 보다 쉽게 시작할 수 있습니다. 마찬가지로, 추가 명령 oc new-project를 사용하면 기본값으로 전환할 수 있는 프로젝트를 보다 쉽게 시작할 수 있습니다.

1.6.2. kubectl 바이너리

kubectl 바이너리는 표준 Kubernetes 환경의 새로운 OpenShift Container Platform 사용자 또는 kubectl CLI 사용을 선호하는 사용자를 위해 기존 워크플로우 및 스크립트를 지원하는 수단으로 제공됩니다. kubectl의 기존 사용자는 OpenShift Container Platform 클러스터를 변경할 필요 없이 이 바이너리를 사용하여 Kubernetes 프리미티브와 계속 상호 작용할 수 있습니다.

지원되는 kubectl 바이너리는 OpenShift CLI 설치 단계에 따라 설치할 수 있습니다. kubectl 바이너리는 바이너리를 다운로드한 경우 아카이브에 포함되어 있습니다. RPM을 사용하여 CLI를 설치할 때 이 바이너리가 설치됩니다.

자세한 내용은 kubectl 문서를 참조하십시오.

2장. 개발자 CLI(odo)

2.1. {odo-title} 릴리스 노트

2.1.1. odo의 주요 변경 사항 및 개선 사항

  • odo에서 이제 Devfile v2를 지원합니다.
  • odo create -s2i는 S2I 구성 요소를 devfile 구성 요소로 변환합니다. odo create --s2i <component-type> odo 를 실행하는 경우 이제 지정된 구성 요소 유형의 S2I 이미지를 기반으로 변환된 Devfile 구성 요소를 생성합니다.

    이 기능에는 다양한 변경 사항이 도입되었습니다. 자세한 내용은 알려진 문제를 참조하십시오.

  • odo push를 실행하는 경우에만 Operator 기반 서비스가 클러스터에 생성되고 odo service create 후에는 생성되지 않습니다.
  • 이제 --container 플래그를 사용하여 odo storage create 명령을 실행할 때 스토리지를 연결할 컨테이너를 지정할 수 있습니다. 자세한 내용은 특정 컨테이너에 스토리지 추가를 참조하십시오.
  • odo catalog component describe는 여러 레지스트리의 구성 요소에 동일한 이름이 사용되는 경우 올바른 JSON을 반환합니다.
  • 클러스터에서 직접 변경 사항을 구현하는 명령은 사용자에게 odo push가 필요하지 않음을 알리는 메시지를 표시합니다.
  • devfile에서 구성 요소를 생성할 때 odo create는 이제 이름이 지정되지 않은 경우 기본 구성 요소 이름을 사용합니다.
  • odo에는 Telemetry가 있습니다. Telemetry 동의 설정을 수정하는 방법에 대한 자세한 내용은 Telemetry 섹션을 참조하십시오.
  • odo service를 사용하면 devfile에서 사용자 정의 리소스 정의 및 ServiceInstance 정보를 추가하거나 삭제할 수 있습니다.

2.1.2. 지원 요청

문서의 경우

오류를 발견하거나 문서 개선을 위한 제안 사항이 있는 경우 Bugzilla에 문제를 제출합니다. OpenShift Container Platform 제품 유형 및 문서 구성 요소 유형을 선택합니다.

제품의 경우

오류를 발견하거나, 버그가 발생하거나, odo의 기능 개선을 위한 제안 사항이 있는 경우 Bugzilla에 문제를 제출합니다. 제품 유형으로 OpenShift Developer Tools 및 Service를 구성 요소로 odo를 선택합니다.

문제 설명에 가능한 한 많은 세부 정보를 제공합니다.

2.1.3. 알려진 문제

  • 버그 1760574 odo project get 명령에 삭제된 네임스페이스가 나열됩니다.
  • 버그 1760586 odo delete 명령을 실행하면 프로젝트가 삭제되고 구성 요소 이름이 설정된 후 무한 루프가 시작됩니다.
  • 버그 1760588 Cygwin에서 실행되는 경우 odo service create 명령이 충돌합니다.
  • 버그 1760590 Windows용 Git BASH에서 odo login -u developer 명령을 실행하면 요청이 있어도 입력된 암호를 숨기지 않습니다.
  • 버그 1783188 연결이 끊어진 클러스터에서 odo component create 명령을 실행하면 카탈로그 목록에 구성 요소가 나열되어 있어도 …​tag not found…​ 오류가 발생합니다.
  • 버그 1761440 한 프로젝트에서 동일한 유형의 서비스를 두 개 생성할 수 없습니다.
  • 버그 1821643 odo push는 .NET 구성 요소 태그 2.1 이상에서 작동하지 않습니다.

    해결방법: 다음을 실행하여 .NET 프로젝트 파일을 지정합니다.

    $ odo config set --env DOTNET_STARTUP_PROJECT=<path_to_your_project>
  • odo create --s2i 이후에 odo url create를 실행하면 명령이 실패합니다. odo는 이제 요청하지 않고 직접 URL을 생성합니다.
  • WildFly 및 dotnet S2I 구성 요소는 odo create를 사용하여 생성할 수 없습니다.
  • odo env set DebugPort가 변환된 devfile 구성 요소에서 작동하지 않습니다. 해결방법: odo config set --env DEBUG_PORT를 사용합니다.
  • odo delete --wait에서 devfile 구성 요소에 대해 리소스가 종료될 때까지 기다리지 않습니다.

2.2. odo 이해

odo는 OpenShift Container Platform 및 Kubernetes에서 애플리케이션을 생성하는 데 사용되는 CLI 툴입니다. odo를 사용하면 클러스터 자체를 관리할 필요 없이 클러스터에서 애플리케이션을 작성하고, 빌드하고, 디버깅할 수 있습니다. odo를 통해 배포 구성, 빌드 구성, 서비스 경로 및 기타 OpenShift Container Platform 요소 또는 Kubernetes 요소 생성이 모두 자동화됩니다.

oc 같은 기존 툴은 운영에 초점을 맞추고 있으며 Kubernetes 및 OpenShift Container Platform 개념을 심층적으로 이해해야 합니다. odo에는 복잡한 Kubernetes 및 OpenShift Container Platform의 개념이 요약되어 있으므로 개발자가 가장 중요한 요소인 코드에 집중할 수 있습니다.

2.2.1. 주요 기능

단순하고 간결하게 설계된 odo는 다음과 같은 주요 기능을 갖추고 있습니다.

  • 간단한 구문 및 설계는 프로젝트, 애플리케이션, 구성 요소 등 개발자에게 친숙한 개념에 중점을 두고 있습니다.
  • 완전하게 클라이언트를 기반으로 합니다. OpenShift Container Platform 이외의 다른 서버가 배포에 필요하지 않습니다.
  • Node.js 및 Java 구성 요소를 공식적으로 지원합니다.
  • Ruby, Perl, PHP, Python 등의 언어 및 프레임워크와 부분적으로 호환됩니다.
  • 로컬 코드 변경 사항을 감지하고 자동으로 클러스터에 배포하므로 즉각적인 피드백을 제공하여 실시간으로 변경 사항을 검증할 수 있습니다.
  • 클러스터의 사용 가능한 구성 요소와 서비스가 모두 나열됩니다.

2.2.2. 핵심 개념

프로젝트
프로젝트는 별도의 단일 단위로 구성된 소스 코드, 테스트, 라이브러리입니다.
애플리케이션
애플리케이션은 일반 사용자용으로 설계된 프로그램입니다. 애플리케이션은 개별적으로 작동하여 전체 애플리케이션을 빌드하는 여러 마이크로 서비스 또는 구성 요소로 이루어져 있습니다. 애플리케이션의 예로는 비디오 게임, 미디어 플레이어, 웹 브라우저가 있습니다.
구성 요소
구성 요소는 코드 또는 데이터를 호스팅하는 Kubernetes 리소스 집합입니다. 구성 요소마다 별도로 실행하고 배포할 수 있습니다. 구성 요소의 예로는 Node.js, Perl, PHP, Python, Ruby가 있습니다.
Service
서비스는 구성 요소가 링크되어 있거나 기반을 두고 있는 소프트웨어입니다. 서비스의 예로는 MariaDB, Jenkins, MySQL이 있습니다. odo에서는 서비스가 OpenShift 서비스 카탈로그에서 프로비저닝되며, 클러스터 내에서 활성화되어야 합니다.

2.2.2.1. 공식적으로 지원되는 언어 및 해당 컨테이너 이미지

표 2.1. 지원되는 언어, 컨테이너 이미지, 패키지 관리자 및 플랫폼

언어컨테이너 이미지패키지 관리자플랫폼

Node.js

rhscl/nodejs-10-rhel7

NPM

amd64, s390x, ppc64le

 

rhscl/nodejs-12-rhel7

NPM

amd64, s390x, ppc64le

Java

redhat-openjdk-18/openjdk18-openshift

Maven, Gradle

amd64, s390x, ppc64le

 

openjdk/openjdk-11-rhel8

Maven, Gradle

amd64, s390x, ppc64le

 

openjdk/openjdk-11-rhel7

Maven, Gradle

amd64, s390x, ppc64le

2.2.2.1.1. 사용 가능한 컨테이너 이미지 나열
참고

사용 가능한 컨테이너 이미지 목록은 클러스터의 내부 컨테이너 레지스트리 및 클러스터와 관련된 외부 레지스트리에서 가져옵니다.

클러스터의 사용 가능한 구성 요소 및 관련 컨테이너 이미지를 나열하려면 다음을 수행합니다.

  1. odo를 사용하여 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 사용 가능한 odo 지원 구성 요소와 지원되지 않는 구성 요소, 해당 컨테이너 이미지를 나열합니다.

    $ odo catalog list components

    출력 예

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

    TAGS 열은 사용 가능한 이미지 버전을 나타냅니다. 예를 들어 10rhoar-nodejs/nodejs-10 컨테이너 이미지를 나타냅니다. CLI 명령에 대한 자세한 내용을 보려면 odo CLI 참조로 이동하십시오.

2.2.2.2. odo에서 Telemetry

odo는 운영 체제, RAM, CPU 크기, 코어 수, odo 버전, 오류, 성공/실패, 명령을 완료하는 데 걸리는 시간 등 odo 사용 방법에 대한 정보를 수집합니다.

odo preference를 사용하여 Telemetry 동의를 수정할 수 있습니다.

  • odo preference set ConsentTelemetry true로 Telemetry에 동의합니다.
  • odo preference unset ConsentTelemetry로 Telemetry를 비활성화합니다.
  • odo preference view로 현재 설정을 확인합니다.

2.3. odo 설치

다음 섹션에서는 CLI를 사용하거나 VS Code(Visual Studio Code) IDE를 사용하여 다양한 플랫폼에 odo를 설치하는 방법을 설명합니다.

참고

현재 제한된 네트워크 환경에서는 odo가 설치를 지원하지 않습니다.

오른쪽 상단에 있는 ? 아이콘을 클릭하고 명령줄 툴을 선택하여 OpenShift Container Platform 웹 콘솔의 최신 바이너리 URL을 찾을 수도 있습니다.

2.3.1. Linux에 odo 설치

2.3.1.1. 바이너리 설치

절차

  1. 바이너리를 가져옵니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-amd64 -o /usr/local/bin/odo
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.1.2. Tarball 설치

절차

  1. Tarball을 가져옵니다.

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-amd64.tar.gz | gzip -d > /usr/local/bin/odo'
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.1.3. RHEL(Red Hat Enterprise Linux)에 yum으로 설치

프로세스

  1. Red Hat Subscription Manager에 등록합니다.

    # subscription-manager register
  2. 최신 서브스크립션 데이터를 가져옵니다.

    # subscription-manager refresh
  3. 사용 가능한 서브스크립션을 나열하십시오.

    # subscription-manager list --available --matches '*OpenShift Developer Tools and Services*'
  4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 Pool ID를 찾아서 이 서브스크립션을 등록된 시스템에 연결합니다.

    # subscription-manager attach --pool=<pool_id>
  5. odo에 필요한 리포지토리를 활성화합니다.

    # subscription-manager repos --enable="ocp-tools-4.8-for-rhel-8-x86_64-rpms"
  6. odo 패키지를 설치합니다.

    # yum install odo
  7. 시스템에서 odo를 사용할 수 있는지 확인합니다.

    $ odo version

2.3.2. Linux on IBM Power에 odo 설치

2.3.2.1. 바이너리 설치

절차

  1. 바이너리를 가져옵니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-ppc64le -o /usr/local/bin/odo
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.2.2. Tarball 설치

절차

  1. Tarball을 가져옵니다.

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-ppc64le.tar.gz | gzip -d > /usr/local/bin/odo'
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.3. Linux on IBM Z 및 LinuxONE에 odo 설치

2.3.3.1. 바이너리 설치

절차

  1. 바이너리를 가져옵니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-s390x -o /usr/local/bin/odo
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.3.2. Tarball 설치

절차

  1. Tarball을 가져옵니다.

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-s390x.tar.gz | gzip -d > /usr/local/bin/odo'
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.4. Windows에 odo 설치

2.3.4.1. 바이너리 설치

  1. 최신 odo.exe 파일을 다운로드합니다.
  2. odo.exe의 위치를 GOPATH/bin 디렉터리에 추가합니다.
Windows 7/8의 PATH 변수 설정

다음 예에서는 경로 변수를 설정하는 방법을 보여줍니다. 바이너리는 어떤 위치에든 있을 수 있지만 이 예에서는 C:\go-bin을 위치로 사용합니다.

  1. C:\go-bin에 폴더를 생성합니다.
  2. 시작을 마우스 오른쪽 버튼으로 클릭하고 제어판을 클릭합니다.
  3. 시스템 및 보안을 선택하고 시스템을 클릭합니다.
  4. 왼쪽 메뉴에서 고급 시스템 설정을 선택하고 아래에 있는 환경 변수 버튼을 클릭합니다.
  5. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
  6. 새로 생성을 클릭하고 필드에 C:\go-bin을 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.
Windows 10의 PATH 변수 설정

검색을 사용하여 Environment Variables를 편집합니다.

  1. 검색을 클릭하고 env 또는 environment를 입력합니다.
  2. 계정의 환경 변수 편집을 선택합니다.
  3. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
  4. 새로 생성을 클릭하고 필드에 C:\go-bin을 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

2.3.5. macOS에 odo 설치

2.3.5.1. 바이너리 설치

절차

  1. 바이너리를 가져옵니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64 -o /usr/local/bin/odo
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.5.2. Tarball 설치

절차

  1. Tarball을 가져옵니다.

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64.tar.gz | gzip -d > /usr/local/bin/odo'
  2. 파일의 권한을 변경합니다.

    # chmod +x /usr/local/bin/odo

2.3.6. VS Code에 odo 설치

OpenShift VS Code 확장에서는 OpenShift Container Platform 클러스터와 상호 작용하는 데 odooc 바이너리를 둘 다 사용합니다. 이러한 기능으로 작업하려면 VS Code에 OpenShift VS Code 확장을 설치하십시오.

사전 요구 사항

  • VS Code가 설치되어 있어야 합니다.

절차

  1. VS Code를 엽니다.
  2. Ctrl+P로 VS Code Quick Open을 시작합니다.
  3. 다음 명령을 실행합니다.

    $ ext install redhat.vscode-openshift-connector

2.4. odo를 사용하여 애플리케이션 생성 및 배포

2.4.1. 프로젝트 작업

프로젝트에는 별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있습니다.

2.4.1.1. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.4.2. odo를 사용하여 단일 구성 요소 애플리케이션 생성

odo를 사용하여 클러스터에 애플리케이션을 생성하고 배포할 수 있습니다.

사전 요구 사항

  • odo가 설치되어 있어야 합니다.
  • 실행 중인 클러스터가 있어야 합니다. CRC(CodeReady Containers)를 사용하여 로컬 클러스터를 빠르게 배포할 수 있습니다.

2.4.2.1. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.4.2.2. odo를 사용하여 Node.js 애플리케이션 생성

Node.js 구성 요소를 생성하려면 odo를 사용하여 Node.js 애플리케이션을 다운로드하고 소스 코드를 클러스터로 푸시합니다.

절차

  1. 구성 요소 디렉터리를 생성합니다.

    $ mkdir my_components && cd my_components
  2. Node.js 애플리케이션 예를 다운로드합니다.

    $ git clone https://github.com/openshift/nodejs-ex
  3. 현재 디렉터리를 애플리케이션이 있는 디렉터리로 변경합니다.

    $ cd <directory_name>
  4. Node.js 유형의 구성 요소를 애플리케이션에 추가합니다.

    $ odo create nodejs
    참고

    기본적으로 최신 이미지가 사용됩니다. odo create openshift/nodejs:8을 사용하여 명시적으로 이미지 버전을 지정할 수도 있습니다.

  5. 초기 소스 코드를 구성 요소로 푸시합니다.

    $ odo push

    이제 OpenShift Container Platform에 구성 요소가 배포되었습니다.

  6. URL을 생성하고 다음과 같이 로컬 구성 파일에 항목을 추가합니다.

    $ odo url create --port 8080
  7. 변경 사항을 푸시합니다. 이렇게 하면 클러스터에 URL이 생성됩니다.

    $ odo push
  8. URL이 나열되도록 하여 구성 요소에 원하는 URL이 지정되었는지 확인합니다.

    $ odo url list
  9. 생성된 URL을 사용하여 배포된 애플리케이션을 확인합니다.

    $ curl <url>

2.4.2.3. 애플리케이션 코드 수정

애플리케이션 코드를 수정하고 OpenShift Container Platform의 애플리케이션에 변경 사항이 적용되도록 할 수 있습니다.

  1. 원하는 텍스트 편집기를 사용하여 Node.js 디렉터리의 레이아웃 파일 중 하나를 편집합니다.
  2. 구성 요소를 업데이트합니다.

    $ odo push
  3. 브라우저에서 애플리케이션을 새로 고쳐 변경 사항을 확인합니다.

2.4.2.4. 애플리케이션 구성 요소에 스토리지 추가

애플리케이션에 영구 데이터를 추가하려면 odo storage 명령을 사용합니다. 유지되어야 하는 데이터의 예로는 데이터베이스 파일, 종속 항목, 빌드 아티팩트(예: .m2 Maven 디렉터리) 등이 있습니다.

절차

  1. 구성 요소에 스토리지를 추가합니다.

    $ odo storage create <storage_name> --path=<path_to_the_directory> --size=<size>
  2. 스토리지를 클러스터로 푸시합니다.

    $ odo push
  3. 구성 요소의 모든 스토리지를 나열하여 스토리지가 구성 요소에 연결되어 있는지 확인합니다.

    $ odo storage list
    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Pushed
  4. 구성 요소에서 스토리지를 삭제합니다.

    $ odo storage delete <storage_name>
  5. 모든 스토리지를 나열하여 스토리지 상태가 Locally Deleted인지 확인합니다.

    $ odo storage list
    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Locally Deleted
  6. 클러스터로 변경 사항을 푸시합니다.

    $ odo push

2.4.2.5. 사용자 정의 빌더를 추가하여 빌드 이미지 지정

OpenShift Container Platform을 사용하면 사용자 정의 이미지를 추가하여 사용자 정의 이미지 생성 간 격차를 해소할 수 있습니다.

다음 예에서는 redhat-openjdk-18 이미지를 성공적으로 가져오고 사용하는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

절차

  1. OpenShift Container Platform으로 이미지를 가져옵니다.

    $ oc import-image openjdk18 \
    --from=registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift \
    --confirm
  2. odo에 대해 액세스할 수 있도록 이미지를 태깅합니다.

    $ oc annotate istag/openjdk18:latest tags=builder
  3. odo를 사용하여 이미지를 배포합니다.

    $ odo create openjdk18 --git \
    https://github.com/openshift-evangelists/Wild-West-Backend

2.4.2.6. OpenShift 서비스 카탈로그를 사용하여 여러 서비스에 애플리케이션 연결

OpenShift 서비스 카탈로그는 OSB API(Open Service Broker API)를 Kubernetes용으로 구현한 것입니다. OpenShift Container Platform에 배포된 애플리케이션을 다양한 서비스와 연결하는 데 사용할 수 있습니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
  • 클러스터에 서비스 카탈로그가 설치 및 활성화되어 있어야 합니다.

절차

  • 서비스를 나열하려면 다음을 실행합니다.

    $ odo catalog list services
  • 서비스 카탈로그 관련 작업을 사용하려면 다음을 실행합니다.

    $ odo service <verb> <service_name>

2.4.2.7. 애플리케이션 삭제

애플리케이션을 삭제하려면 odo app delete 명령을 사용합니다.

절차

  1. 현재 프로젝트의 애플리케이션을 나열합니다.

    $ odo app list

    출력 예

        The project '<project_name>' has the following applications:
        NAME
        app

  2. 애플리케이션과 관련된 구성 요소를 나열합니다. 이러한 구성 요소는 애플리케이션과 함께 삭제됩니다.

    $ odo component list

    출력 예

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. 애플리케이션을 삭제합니다.

    $ odo app delete <application_name>

    출력 예

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Y를 사용하여 삭제를 확인합니다. -f 플래그를 사용하여 확인 프롬프트를 억제할 수 있습니다.

2.4.3. odo를 사용하여 다중 구성 요소 애플리케이션 생성

odo를 사용하면 쉽고 자동화된 방식으로 다중 구성 요소 애플리케이션을 생성하고, 수정하고, 해당 구성 요소를 연결할 수 있습니다.

이 예에서는 다중 구성 요소 애플리케이션(슈팅 게임)을 배포하는 방법을 설명합니다. 애플리케이션은 프론트 엔드 Node.js 구성 요소와 백엔드 Java 구성 요소로 이루어져 있습니다.

사전 요구 사항

  • odo가 설치되어 있어야 합니다.
  • 실행 중인 클러스터가 있어야 합니다. 개발자는 CRC(CodeReady Containers)를 사용하여 빠르게 로컬 클러스터를 배포할 수 있습니다.
  • Maven이 설치되어 있어야 합니다.

2.4.3.1. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.4.3.2. 백엔드 구성 요소 배포

Java 구성 요소를 생성하려면 Java 빌더 이미지를 가져온 후 odo를 사용하여 Java 애플리케이션을 다운로드하고 소스 코드를 클러스터로 푸시합니다.

절차

  1. openjdk18을 클러스터로 가져옵니다.

    $ oc import-image openjdk18 \
    --from=registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift --confirm
  2. 이미지를 builder로 태깅하여 odo에 대해 액세스할 수 있도록 합니다.

    $ oc annotate istag/openjdk18:latest tags=builder
  3. 생성된 이미지를 보려면 odo catalog list components를 실행합니다.

    $ odo catalog list components

    출력 예

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

  4. 구성 요소 디렉터리를 생성합니다.

    $ mkdir my_components && cd my_components
  5. 백엔드 애플리케이션 예를 다운로드합니다.

    $ git clone https://github.com/openshift-evangelists/Wild-West-Backend backend
  6. 백엔드 소스 디렉터리로 변경합니다.

    $ cd backend
  7. 디렉터리에 올바른 파일이 있는지 확인합니다.

    $ ls

    출력 예

    debug.sh  pom.xml  src

  8. Maven으로 백엔드 소스 파일을 빌드하여 JAR 파일을 생성합니다.

    $ mvn package

    출력 예

    ...
    [INFO] --------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] --------------------------------------
    [INFO] Total time: 2.635 s
    [INFO] Finished at: 2019-09-30T16:11:11-04:00
    [INFO] Final Memory: 30M/91M
    [INFO] --------------------------------------

  9. backend라는 Java 구성 요소 유형을 생성합니다.

    $ odo create --s2i openjdk18 backend --binary target/wildwest-1.0.jar

    출력 예

     ✓  Validating component [1ms]
     Please use `odo push` command to create the component with source deployed

    이제 배포할 구성 요소에 대한 정보가 포함된 구성 파일 config.yaml이 백엔드 구성 요소의 로컬 디렉터리에 있습니다.

  10. 다음을 사용하여 config.yaml 파일의 백엔드 구성 요소에 대한 구성 설정을 확인합니다.

    $ odo config view

    출력 예

    COMPONENT SETTINGS
    ------------------------------------------------
    PARAMETER         CURRENT_VALUE
    Type              openjdk18
    Application       app
    Project           myproject
    SourceType        binary
    Ref
    SourceLocation    target/wildwest-1.0.jar
    Ports             8080/TCP,8443/TCP,8778/TCP
    Name              backend
    MinMemory
    MaxMemory
    DebugPort
    Ignore
    MinCPU
    MaxCPU

  11. 구성 요소를 OpenShift Container Platform 클러스터로 푸시합니다.

    $ odo push

    출력 예

    Validation
     ✓  Checking component [6ms]
    
    Configuration changes
     ✓  Initializing component
     ✓  Creating component [124ms]
    
    Pushing to component backend of type binary
     ✓  Checking files for pushing [1ms]
     ✓  Waiting for component to start [48s]
     ✓  Syncing files to the component [811ms]
     ✓  Building component [3s]

    OpenShift Container Platform은 odo push를 사용하여 백엔드 구성 요소를 호스팅하는 컨테이너를 생성하고, OpenShift Container Platform 클러스터에서 실행 중인 Pod에 컨테이너를 배포하고, backend 구성 요소를 시작합니다.

  12. 다음을 검증합니다.

    • odo의 동작 상태:

      $ odo log -f

      출력 예

      2019-09-30 20:14:19.738  INFO 444 --- [           main] c.o.wildwest.WildWestApplication         : Starting WildWestApplication v1.0 onbackend-app-1-9tnhc with PID 444 (/deployments/wildwest-1.0.jar started by jboss in /deployments)

    • 백엔드 구성 요소의 상태:

      $ odo list

      출력 예

      APP     NAME        TYPE          SOURCE                             STATE
      app     backend     openjdk18     file://target/wildwest-1.0.jar     Pushed

2.4.3.3. 프론트 엔드 구성 요소 배포

프론트 엔드 구성 요소를 생성하고 배포하려면 Node.js 애플리케이션을 다운로드하고 odo를 사용하여 소스 코드를 클러스터로 푸시합니다.

절차

  1. 프론트 엔드 애플리케이션 예를 다운로드합니다.

    $ git clone https://github.com/openshift/nodejs-ex frontend
  2. 현재 디렉터리를 프론트 엔드 디렉터리로 변경합니다.

    $ cd frontend
  3. 디렉터리의 콘텐츠를 나열하여 프론트 엔드가 Node.js 애플리케이션인지 확인합니다.

    $ ls

    출력 예

    README.md       openshift       server.js       views
    helm            package.json    tests

    참고

    프론트 엔드 구성 요소는 해석되는 언어(Node.js)로 작성됩니다. 빌드할 필요가 없습니다.

  4. frontend라는 Node.js 구성 요소 유형을 생성합니다.

    $ odo create --s2i nodejs frontend

    출력 예

     ✓  Validating component [5ms]
    Please use `odo push` command to create the component with source deployed

  5. 구성 요소를 실행 중인 컨테이너로 푸시합니다.

    $ odo push

    출력 예

    Validation
     ✓  Checking component [8ms]
    
    Configuration changes
     ✓  Initializing component
     ✓  Creating component [83ms]
    
    Pushing to component frontend of type local
     ✓  Checking files for pushing [2ms]
     ✓  Waiting for component to start [45s]
     ✓  Syncing files to the component [3s]
     ✓  Building component [18s]
     ✓  Changes successfully pushed to component

2.4.3.4. 두 구성 요소 연결

클러스터에서 실행되는 구성 요소가 상호 작용하려면 서로 연결되어야 합니다. OpenShift Container Platform에서는 프로그램의 통신 바인딩을 해당 클라이언트에 게시하는 연결 메커니즘을 제공합니다.

절차

  1. 클러스터에서 실행 중인 모든 구성 요소를 나열합니다.

    $ odo list

    출력 예

    OpenShift Components:
    APP     NAME         PROJECT     TYPE          SOURCETYPE     STATE
    app     backend      testpro     openjdk18     binary         Pushed
    app     frontend     testpro     nodejs        local          Pushed

  2. 현재 프론트 엔드 구성 요소를 백엔드에 연결합니다.

    $ odo link backend --port 8080

    출력 예

     ✓  Component backend has been successfully linked from the component frontend
    
    Following environment variables were added to frontend component:
    - COMPONENT_BACKEND_HOST
    - COMPONENT_BACKEND_PORT

    백엔드 구성 요소의 구성 정보가 프론트 엔드 구성 요소에 추가되고 프론트 엔드 구성 요소가 재시작됩니다.

2.4.3.5. 구성 요소 공개

절차

  1. frontend 디렉터리로 이동합니다.

    $ cd frontend
  2. 애플리케이션의 외부 URL을 생성합니다.

    $ odo url create frontend --port 8080

    출력 예

     ✓  URL frontend created for component: frontend
    
    To create URL on the OpenShift  cluster, use `odo push`

  3. 변경 사항을 적용합니다.

    $ odo push

    출력 예

    Validation
     ✓  Checking component [21ms]
    
    Configuration changes
     ✓  Retrieving component data [35ms]
     ✓  Applying configuration [29ms]
    
    Applying URL changes
     ✓  URL frontend: http://frontend-app-myproject.192.168.42.79.nip.io created
    
    Pushing to component frontend of type local
     ✓  Checking file changes for pushing [1ms]
     ✓  No file changes detected, skipping build. Use the '-f' flag to force the build.

  4. 브라우저에서 URL을 열어 애플리케이션을 봅니다.
참고

애플리케이션이 OpenShift Container Platform 네임스페이스에 액세스하여 활성 Pod를 삭제하려면 활성 서비스 계정에 대한 권한이 있어야 하는 경우 백엔드 구성 요소에서 odo log를 볼 때 다음 오류가 발생할 수 있습니다.

Message: Forbidden!Configured service account doesn’t have access. Service account may have been revoked

이 오류를 해결하려면 서비스 계정 역할에 대한 권한을 추가합니다.

$ oc policy add-role-to-group view system:serviceaccounts -n <project>
$ oc policy add-role-to-group edit system:serviceaccounts -n <project>

프로덕션 클러스터에서는 이 작업을 수행하지 마십시오.

2.4.3.6. 실행 중인 애플리케이션 수정

절차

  1. 로컬 디렉터리를 프론트 엔드 디렉터리로 변경합니다.

    $ cd frontend
  2. 다음을 사용하여 파일 시스템의 변경 사항을 모니터링합니다.

    $ odo watch
  3. index.html 파일을 편집하여 슈팅 게임의 표시 이름을 변경합니다.

    참고

    odo에서 변경 사항을 인식할 때까지 약간의 지연이 발생할 수 있습니다.

    odo는 프론트 엔드 구성 요소로 변경 사항을 푸시하고 해당 상태를 터미널에 출력합니다.

    File /root/frontend/index.html changed
    File  changed
    Pushing files...
     ✓  Waiting for component to start
     ✓  Copying files to component
     ✓  Building component
  4. 웹 브라우저에서 애플리케이션 페이지를 새로 고칩니다. 이제 새 이름이 표시됩니다.

2.4.3.7. 애플리케이션 삭제

애플리케이션을 삭제하려면 odo app delete 명령을 사용합니다.

절차

  1. 현재 프로젝트의 애플리케이션을 나열합니다.

    $ odo app list

    출력 예

        The project '<project_name>' has the following applications:
        NAME
        app

  2. 애플리케이션과 관련된 구성 요소를 나열합니다. 이러한 구성 요소는 애플리케이션과 함께 삭제됩니다.

    $ odo component list

    출력 예

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. 애플리케이션을 삭제합니다.

    $ odo app delete <application_name>

    출력 예

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Y를 사용하여 삭제를 확인합니다. -f 플래그를 사용하여 확인 프롬프트를 억제할 수 있습니다.

2.4.4. 데이터베이스를 사용하여 애플리케이션 생성

이 예에서는 데이터베이스를 프론트 엔드 애플리케이션에 배포하고 연결하는 방법을 설명합니다.

사전 요구 사항

  • odo가 설치되어 있어야 합니다.
  • oc 클라이언트가 설치되어 있어야 합니다.
  • 실행 중인 클러스터가 있어야 합니다. 개발자는 CRC(CodeReady Containers)를 사용하여 빠르게 로컬 클러스터를 배포할 수 있습니다.
  • 클러스터에 서비스 카탈로그가 설치 및 활성화되어 있어야 합니다.

    참고

    기본적으로 OpenShift Container Platform 4 이상에서는 서비스 카탈로그가 더 이상 사용되지 않습니다.

2.4.4.1. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.4.4.2. 프론트 엔드 구성 요소 배포

프론트 엔드 구성 요소를 생성하고 배포하려면 Node.js 애플리케이션을 다운로드하고 odo를 사용하여 소스 코드를 클러스터로 푸시합니다.

절차

  1. 프론트 엔드 애플리케이션 예를 다운로드합니다.

    $ git clone https://github.com/openshift/nodejs-ex frontend
  2. 현재 디렉터리를 프론트 엔드 디렉터리로 변경합니다.

    $ cd frontend
  3. 디렉터리의 콘텐츠를 나열하여 프론트 엔드가 Node.js 애플리케이션인지 확인합니다.

    $ ls

    출력 예

    README.md       openshift       server.js       views
    helm            package.json    tests

    참고

    프론트 엔드 구성 요소는 해석되는 언어(Node.js)로 작성됩니다. 빌드할 필요가 없습니다.

  4. frontend라는 Node.js 구성 요소 유형을 생성합니다.

    $ odo create --s2i nodejs frontend

    출력 예

     ✓  Validating component [5ms]
    Please use `odo push` command to create the component with source deployed

  5. 프론트 엔드 인터페이스에 액세스할 URL을 생성합니다.

    $ odo url create myurl

    출력 예

     ✓  URL myurl created for component: nodejs-nodejs-ex-pmdp

  6. 구성 요소를 OpenShift Container Platform 클러스터로 푸시합니다.

    $ odo push

    출력 예

    Validation
     ✓  Checking component [7ms]
    
     Configuration changes
     ✓  Initializing component
     ✓  Creating component [134ms]
    
     Applying URL changes
     ✓  URL myurl: http://myurl-app-myproject.192.168.42.79.nip.io created
    
     Pushing to component nodejs-nodejs-ex-mhbb of type local
     ✓  Checking files for pushing [657850ns]
     ✓  Waiting for component to start [6s]
     ✓  Syncing files to the component [408ms]
     ✓  Building component [7s]
     ✓  Changes successfully pushed to component

2.4.4.3. 대화형 모드로 데이터베이스 배포

odo에서 제공하는 대화형 모드의 명령줄을 사용하면 배포를 간소화할 수 있습니다.

절차

  • 대화형 모드를 실행하고 프롬프트에 응답합니다.

    $ odo service create

    출력 예

    ? Which kind of service do you wish to create database
    ? Which database service class should we use mongodb-persistent
    ? Enter a value for string property DATABASE_SERVICE_NAME (Database Service Name): mongodb
    ? Enter a value for string property MEMORY_LIMIT (Memory Limit): 512Mi
    ? Enter a value for string property MONGODB_DATABASE (MongoDB Database Name): sampledb
    ? Enter a value for string property MONGODB_VERSION (Version of MongoDB Image): 3.2
    ? Enter a value for string property VOLUME_CAPACITY (Volume Capacity): 1Gi
    ? Provide values for non-required properties No
    ? How should we name your service  mongodb-persistent
    ? Output the non-interactive version of the selected options No
    ? Wait for the service to be ready No
     ✓  Creating service [32ms]
     ✓  Service 'mongodb-persistent' was created
    Progress of the provisioning will not be reported and might take a long time.
    You can see the current status by executing 'odo service list'

참고

암호 또는 사용자 이름은 환경 변수로 프론트 엔드 애플리케이션에 전달됩니다.

2.4.4.4. 수동으로 데이터베이스 배포

  1. 사용 가능한 서비스를 나열합니다.

    $ odo catalog list services

    출력 예

    NAME                         PLANS
    django-psql-persistent       default
    jenkins-ephemeral            default
    jenkins-pipeline-example     default
    mariadb-persistent           default
    mongodb-persistent           default
    mysql-persistent             default
    nodejs-mongo-persistent      default
    postgresql-persistent        default
    rails-pgsql-persistent       default

  2. mongodb-persistent 유형의 서비스를 선택하고 필요한 매개변수를 확인합니다.

    $ odo catalog describe service mongodb-persistent

    출력 예

      ***********************        | *****************************************************
      Name                           | default
      -----------------              | -----------------
      Display Name                   |
      -----------------              | -----------------
      Short Description              | Default plan
      -----------------              | -----------------
      Required Params without a      |
      default value                  |
      -----------------              | -----------------
      Required Params with a default | DATABASE_SERVICE_NAME
      value                          | (default: 'mongodb'),
                                     | MEMORY_LIMIT (default:
                                     | '512Mi'), MONGODB_VERSION
                                     | (default: '3.2'),
                                     | MONGODB_DATABASE (default:
                                     | 'sampledb'), VOLUME_CAPACITY
                                     | (default: '1Gi')
      -----------------              | -----------------
      Optional Params                | MONGODB_ADMIN_PASSWORD,
                                     | NAMESPACE, MONGODB_PASSWORD,
                                     | MONGODB_USER

  3. 필요한 매개변수를 플래그로 전달하고 데이터베이스가 배포될 때까지 기다립니다.

    $ odo service create mongodb-persistent --plan default --wait -p DATABASE_SERVICE_NAME=mongodb -p MEMORY_LIMIT=512Mi -p MONGODB_DATABASE=sampledb -p VOLUME_CAPACITY=1Gi

2.4.4.5. 프론트 엔드 애플리케이션에 데이터베이스 연결

  1. 프론트 엔드 서비스에 데이터베이스를 연결합니다.

    $ odo link mongodb-persistent

    출력 예

     ✓  Service mongodb-persistent has been successfully linked from the component nodejs-nodejs-ex-mhbb
    
    Following environment variables were added to nodejs-nodejs-ex-mhbb component:
    - database_name
    - password
    - uri
    - username
    - admin_password

  2. Pod의 애플리케이션 및 데이터베이스 환경 변수를 확인합니다.

    1. Pod 이름을 가져옵니다.

      $ oc get pods

      출력 예

      NAME                                READY     STATUS    RESTARTS   AGE
      mongodb-1-gsznc                     1/1       Running   0          28m
      nodejs-nodejs-ex-mhbb-app-4-vkn9l   1/1       Running   0          1m

    2. Pod에 연결합니다.

      $ oc rsh nodejs-nodejs-ex-mhbb-app-4-vkn9l
    3. 환경 변수를 확인합니다.

      sh-4.2$ env

      출력 예

      uri=mongodb://172.30.126.3:27017
      password=dHIOpYneSkX3rTLn
      database_name=sampledb
      username=user43U
      admin_password=NCn41tqmx7RIqmfv

  3. 브라우저에서 URL을 열고 오른쪽 아래에 있는 데이터베이스 구성을 확인합니다.

    $ odo url list

    출력 예

    Request information
    Page view count: 24
    
    DB Connection Info:
    Type:	MongoDB
    URL:	mongodb://172.30.126.3:27017/sampledb

2.4.5. 데이터베이스를 사용하여 Java 애플리케이션 생성

이 예에서는 devfile을 사용하여 Java 애플리케이션을 배포하고 데이터베이스 서비스에 연결하는 방법을 설명합니다.

사전 요구 사항

  • 실행 중인 클러스터가 있어야 합니다.
  • odo가 설치되어 있어야 합니다.
  • Service Binding Operator가 클러스터에 설치되어 있어야 합니다. Operator 설치 방법을 알아보려면 클러스터 관리자에게 문의하거나 OperatorHub에서 Operator 설치를 참조하십시오.
  • Dev4Devs PostgreSQL Operator가 클러스터에 설치되어 있어야 합니다. Operator 설치 방법을 알아보려면 클러스터 관리자에게 문의하거나 OperatorHub에서 Operator 설치를 참조하십시오.

2.4.5.1. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.4.5.2. Java MicroServices JPA 애플리케이션 생성

odo를 사용하여 샘플 Java MicroServices JPA 애플리케이션을 생성하고 관리할 수 있습니다.

절차

  1. 샘플 애플리케이션을 복제합니다.

    $ git clone -b jpa-sample https://github.com/redhat-developer/application-stack-samples.git
  2. 애플리케이션 디렉터리로 이동합니다.

    $ cd ./application-stack-samples/jpa
  3. 프로젝트를 초기화합니다.

    $ odo create java-openliberty java-application
  4. 애플리케이션을 클러스터로 푸시합니다.

    $ odo push

    이제 애플리케이션이 클러스터에 배포되었습니다.

  5. OpenShift 로그를 터미널로 스트리밍하여 클러스터 상태를 봅니다.

    $ odo log

    테스트 실패 및 UnknownDatabaseHostException 오류를 확인할 수 있습니다. 이렇게 된 것은 애플리케이션에 아직 데이터베이스가 없기 때문입니다.

    [INFO] [err] java.net.UnknownHostException: ${DATABASE_CLUSTERIP}
    [INFO] [err]    at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:220)
    [INFO] [err]    at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:403)
    [INFO] [err]    at java.base/java.net.Socket.connect(Socket.java:609)
    [INFO] [err]    at org.postgresql.core.PGStream.<init>(PGStream.java:68)
    [INFO] [err]    at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:144)
    [INFO] [err]    ... 86 more
    [ERROR] Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.706 s <<< FAILURE! - in org.example.app.it.DatabaseIT
    [ERROR] testGetAllPeople  Time elapsed: 0.33 s  <<< FAILURE!
    org.opentest4j.AssertionFailedError: Expected at least 2 people to be registered, but there were only: [] ==> expected: <true> but was: <false>
            at org.example.app.it.DatabaseIT.testGetAllPeople(DatabaseIT.java:57)
    
    [ERROR] testGetPerson  Time elapsed: 0.047 s  <<< ERROR!
    java.lang.NullPointerException
            at org.example.app.it.DatabaseIT.testGetPerson(DatabaseIT.java:41)
    
    [INFO]
    [INFO] Results:
    [INFO]
    [ERROR] Failures:
    [ERROR]   DatabaseIT.testGetAllPeople:57 Expected at least 2 people to be registered, but there were only: [] ==> expected: <true> but was: <false>
    [ERROR] Errors:
    [ERROR]   DatabaseIT.testGetPerson:41 NullPointer
    [INFO]
    [ERROR] Tests run: 2, Failures: 1, Errors: 1, Skipped: 0
    [INFO]
    [ERROR] Integration tests failed: There are test failures.
  6. 애플리케이션에 액세스할 Ingress URL을 생성합니다.

    $ odo url create --port 8080
  7. 변경 사항을 클러스터로 푸시합니다.

    $ odo push
  8. 생성된 URL을 표시합니다.

    $ odo url list

    출력 예

    Found the following URLs for component mysboproj
    NAME               STATE      URL                                           PORT     SECURE     KIND
    java-application-8080     Pushed     http://java-application-8080.apps-crc.testing     8080      false      ingress

    이제 애플리케이션이 클러스터에 배포되었으므로 생성된 URL을 사용하여 액세스할 수 있습니다.

  9. URL을 사용하여 CreatePerson.xhtml 데이터 항목 페이지로 이동하고 양식을 사용하여 사용자 이름과 기간을 입력합니다. 저장을 클릭합니다.

    아직 애플리케이션에 연결된 데이터베이스가 없으므로 사용자 레코드 목록 보기 링크를 클릭하여 데이터를 볼 수 없습니다.

2.4.5.3. odo를 사용하여 데이터베이스 생성

데이터베이스를 생성하려면 데이터베이스 Operator에 대한 액세스 권한이 있어야 합니다. 이 예에서는 Dev4Devs PostgreSQL Operator가 사용됩니다.

절차

  1. 프로젝트의 서비스 목록을 확인합니다.

    $ odo catalog list services

    출력 예

    Operators available in the cluster
    NAME                                             CRDs
    postgresql-operator.v0.1.1                       Backup, Database

  2. 서비스 YAML을 파일에 저장합니다.

    $ odo service create postgresql-operator.v0.1.1/Database --dry-run > db.yaml
  3. db.yaml 파일에 있는 metadata: 섹션 아래의 다음 값을 추가합니다.

      name: sampledatabase
      annotations:
        service.binding/db.name: 'path={.spec.databaseName}'
        service.binding/db.password: 'path={.spec.databasePassword}'
        service.binding/db.user: 'path={.spec.databaseUser}'

    이 구성을 사용하면 데이터베이스 서비스가 시작될 때 적절한 주석이 추가됩니다. 주석은 Service Binding Operator가 databaseName, databasePassworddatabaseUser의 값을 애플리케이션에 삽입하는 데 도움이 됩니다.

  4. YAML 파일에 있는 spec: 섹션 아래의 다음 값을 변경합니다.

      databaseName: "sampledb"
      databasePassword: "samplepwd"
      databaseUser: "sampleuser"
  5. YAML 파일에서 데이터베이스를 생성합니다.

    $ odo service create --from-file db.yaml

    이제 프로젝트에 데이터베이스 인스턴스가 있습니다.

2.4.5.4. Java 애플리케이션을 데이터베이스에 연결

Java 애플리케이션을 데이터베이스에 연결하려면 odo link 명령을 사용합니다.

절차

  1. 서비스 목록을 표시합니다.

    $ odo service list

    출력 예

    NAME                        AGE
    Database/sampledatabase     6m31s

  2. 데이터베이스를 애플리케이션에 연결합니다.

    $ odo link Database/sampledatabase
  3. 변경 사항을 클러스터로 푸시합니다.

    $ odo push

    링크가 생성되고 푸시되면 데이터베이스 연결 데이터가 포함된 시크릿이 생성됩니다.

  4. 데이터베이스 서비스에서 삽입된 값을 구성 요소에서 확인합니다.

    $ odo exec -- bash -c 'env | grep DATABASE'
    declare -x DATABASE_CLUSTERIP="10.106.182.173"
    declare -x DATABASE_DB_NAME="sampledb"
    declare -x DATABASE_DB_PASSWORD="samplepwd"
    declare -x DATABASE_DB_USER="sampleuser"
  5. Java 애플리케이션 URL을 열고 CreatePerson.xhtml 데이터 항목 페이지로 이동합니다. 양식을 사용하여 사용자 이름과 기간을 입력합니다. 저장을 클릭합니다.

    이제 사용자 레코드 목록 보기 링크를 클릭하여 데이터베이스의 데이터를 볼 수 있습니다.

    psql 같은 CLI 툴을 사용하여 데이터베이스를 조작할 수도 있습니다.

2.4.6. odo에서 devfile 사용

2.4.6.1. odo에서 devfile 정보

devfile은 개발 환경에 대해 설명하는 이식 가능한 파일입니다. devfile을 사용하면 재구성 없이도 이식 가능한 개발 환경을 정의할 수 있습니다.

devfile을 사용하면 소스 코드, IDE 툴, 애플리케이션 런타임 및 사전 정의된 명령과 같은 개발 환경에 대해 설명할 수 있습니다. devfile에 대한 자세한 내용은 devfile 문서를 참조하십시오.

odo를 사용하면 devfile에서 구성 요소를 생성할 수 있습니다. devfile을 사용하여 구성 요소를 생성하는 경우 odo는 OpenShift Container Platform, Kubernetes 또는 Docker에서 실행되는 여러 컨테이너가 포함된 작업 공간으로 devfile을 변환합니다. odo는 자동으로 기본 devfile 레지스트리를 사용하지만 사용자가 자체 레지스트리를 추가할 수 있습니다.

2.4.6.2. devfile을 사용하여 Java 애플리케이션 생성

사전 요구 사항

  • odo가 설치되어 있어야 합니다.
  • Ingress 도메인 클러스터 이름을 알아야 합니다. 모르는 경우 클러스터 관리자에게 문의하십시오. 예를 들어 apps-crc.testingRed Hat CodeReady Containers의 클러스터 도메인 이름입니다.
참고

현재 odo는 --git 또는 --binary 플래그를 사용하여 devfile 구성 요소를 생성하는 것을 지원하지 않습니다. 이러한 플래그를 사용하는 경우에만 S2I 구성 요소를 생성할 수 있습니다.

2.4.6.2.1. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.4.6.2.2. 사용 가능한 devfile 구성 요소 나열

odo를 사용하면 클러스터에서 사용 가능한 모든 구성 요소를 표시할 수 있습니다. 사용 가능한 구성 요소는 클러스터 구성에 따라 달라집니다.

절차

  1. 클러스터에서 사용 가능한 devfile 구성 요소를 나열하려면 다음을 실행합니다.

    $ odo catalog list components

    출력에는 사용 가능한 odo 구성 요소가 나열됩니다.

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO
2.4.6.2.3. devfile을 사용하여 Java 애플리케이션 배포

이 섹션에서는 devfile을 사용하여 Maven 및 Java 8 JDK를 사용하는 샘플 Java 프로젝트를 배포하는 방법을 알아봅니다.

절차

  1. 구성 요소의 소스 코드를 저장할 디렉터리를 생성합니다.

    $ mkdir <directory-name>
  2. myspring이라는 Spring Boot 구성 요소 유형을 생성하고 해당 샘플 프로젝트를 다운로드합니다.

    $ odo create java-springboot myspring --starter

    앞의 명령은 다음 출력을 생성합니다.

    Validation
    ✓  Checking devfile compatibility [195728ns]
    ✓  Creating a devfile component from registry: DefaultDevfileRegistry [170275ns]
    ✓  Validating devfile component [281940ns]
    
    Please use `odo push` command to create the component with source deployed

    odo create 명령은 기록된 devfile 레지스트리에서 관련 devfile.yaml 파일을 다운로드합니다.

  3. 디렉터리 콘텐츠를 나열하여 devfile 및 샘플 Java 애플리케이션이 다운로드되었는지 확인합니다.

    $ ls

    앞의 명령은 다음 출력을 생성합니다.

    README.md    devfile.yaml    pom.xml        src
  4. 배포된 구성 요소에 액세스할 URL을 생성합니다.

    $ odo url create --host apps-crc.testing

    앞의 명령은 다음 출력을 생성합니다.

    ✓  URL myspring-8080.apps-crc.testing created for component: myspring
    
    To apply the URL configuration changes, please use odo push
    참고

    URL을 생성할 때 클러스터 호스트 도메인 이름을 사용해야 합니다.

  5. 구성 요소를 클러스터로 푸시합니다.

    $ odo push

    앞의 명령은 다음 출력을 생성합니다.

    Validation
     ✓  Validating the devfile [81808ns]
    
    Creating Kubernetes resources for component myspring
     ✓  Waiting for component to start [5s]
    
    Applying URL changes
     ✓  URL myspring-8080: http://myspring-8080.apps-crc.testing created
    
    Syncing to component myspring
     ✓  Checking files for pushing [2ms]
     ✓  Syncing files to the component [1s]
    
    Executing devfile commands for component myspring
     ✓  Executing devbuild command "/artifacts/bin/build-container-full.sh" [1m]
     ✓  Executing devrun command "/artifacts/bin/start-server.sh" [2s]
    
    Pushing devfile component myspring
     ✓  Changes successfully pushed to component
  6. 구성 요소 URL을 나열하여 구성 요소가 성공적으로 푸시되었는지 확인합니다.

    $ odo url list

    앞의 명령은 다음 출력을 생성합니다.

    Found the following URLs for component myspring
    NAME              URL                                       PORT     SECURE
    myspring-8080     http://myspring-8080.apps-crc.testing     8080     false
  7. 생성된 URL을 사용하여 배포된 애플리케이션을 확인합니다.

    $ curl http://myspring-8080.apps-crc.testing

2.4.6.3. S2I 구성 요소를 devfile 구성 요소로 변환

odo를 사용하여 S2I(Source-to-Image) 구성 요소와 devfile 구성 요소를 둘 다 생성할 수 있습니다. 기존 S2I 구성 요소가 있는 경우 odo utils 명령을 사용하여 devfile 구성 요소로 변환할 수 있습니다.

절차

S2I 구성 요소 디렉터리의 모든 명령을 실행합니다.

  1. odo utils convert-to-devfile 명령을 실행하여 구성 요소를 기반으로 devfile.yamlenv.yaml을 생성합니다.

    $ odo utils convert-to-devfile
  2. 구성 요소를 클러스터로 푸시합니다.

    $ odo push
    참고

    devfile 구성 요소 배포에 실패한 경우 odo delete -a를 실행하여 삭제합니다.

  3. devfile 구성 요소가 성공적으로 배포되었는지 확인합니다.

    $ odo list
  4. S2I 구성 요소를 삭제합니다.

    $ odo delete --s2i

2.4.7. 스토리지 작업

영구 스토리지를 사용하면 odo 재시작 사이에 데이터를 사용 가능하게 유지할 수 있습니다.

2.4.7.1. 애플리케이션 구성 요소에 스토리지 추가

애플리케이션에 영구 데이터를 추가하려면 odo storage 명령을 사용합니다. 유지되어야 하는 데이터의 예로는 데이터베이스 파일, 종속 항목, 빌드 아티팩트(예: .m2 Maven 디렉터리) 등이 있습니다.

절차

  1. 구성 요소에 스토리지를 추가합니다.

    $ odo storage create <storage_name> --path=<path_to_the_directory> --size=<size>
  2. 스토리지를 클러스터로 푸시합니다.

    $ odo push
  3. 구성 요소의 모든 스토리지를 나열하여 스토리지가 구성 요소에 연결되어 있는지 확인합니다.

    $ odo storage list
    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Pushed
  4. 구성 요소에서 스토리지를 삭제합니다.

    $ odo storage delete <storage_name>
  5. 모든 스토리지를 나열하여 스토리지 상태가 Locally Deleted인지 확인합니다.

    $ odo storage list
    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Locally Deleted
  6. 클러스터로 변경 사항을 푸시합니다.

    $ odo push

2.4.7.2. 특정 컨테이너에 스토리지 추가

devfile에 컨테이너가 여러 개 있는 경우 --container 플래그를 사용하여 스토리지를 연결할 컨테이너를 지정할 수 있습니다.

프로세스

  1. 여러 컨테이너가 있는 devfile을 생성합니다.

    components:
      - name: runtime 1
        container:
          image: registry.access.redhat.com/ubi8/nodejs-12:1-36
          memoryLimit: 1024Mi
          endpoints:
            - name: "3000-tcp"
              targetPort: 3000
          mountSources: true
      - name: funtime 2
        container:
          image: registry.access.redhat.com/ubi8/nodejs-12:1-36
          memoryLimit: 1024Mi
    1
    런타임 컨테이너입니다.
    2
    funtime 컨테이너입니다.
  2. runtime 컨테이너용 스토리지를 생성하려면 다음을 수행합니다.

    $ odo storage create store --path /data --size 1Gi --container runtime
    ✓  Added storage store to nodejs-testing-xnfg
      Please use `odo push` command to make the storage accessible to the component
  3. 구성 요소의 모든 스토리지를 나열하여 스토리지가 구성 요소에 연결되어 있는지 확인합니다.

    $ odo storage list
    The component 'nodejs-testing-xnfg' has the following storage attached:
      NAME      SIZE     PATH      CONTAINER     STATE
      store     1Gi      /data     runtime       Not Pushed
  4. 클러스터로 변경 사항을 푸시합니다.

    $ odo push

2.4.7.3. 임시 스토리지와 영구 스토리지 간 전환

odo preference 명령을 사용하여 프로젝트의 임시 스토리지와 영구 스토리지 간에 전환할 수 있습니다. odo preference는 클러스터의 글로벌 기본 설정을 수정합니다.

영구 스토리지가 활성화되면 클러스터는 재시작 사이에 발생한 정보를 저장합니다.

임시 스토리지가 활성화되면 클러스터는 재시작 사이에 발생한 정보를 저장하지 않습니다.

임시 스토리지는 기본적으로 활성화되어 있습니다.

절차

  1. 프로젝트에서 현재 지정되어 있는 기본 설정을 확인합니다.

    $ odo preference view
    PARAMETER             CURRENT_VALUE
    UpdateNotification
    NamePrefix
    Timeout
    BuildTimeout
    PushTimeout
    Experimental
    PushTarget
    Ephemeral             true
  2. 임시 스토리지를 설정 해제하고 영구 스토리지를 설정하려면 다음을 수행합니다.

    $ odo preference set Ephemeral false
  3. 임시 스토리지를 다시 설정하려면 다음을 수행합니다.

    $ odo preference set Ephemeral true

    odo preference 명령은 현재 배포된 모든 구성 요소와 나중에 배포되는 구성 요소의 글로벌 설정을 변경합니다.

  4. odo push를 실행하여 odo에서 구성 요소에 대해 지정된 스토리지를 생성하도록 합니다.

    $ odo push

2.4.8. 애플리케이션 삭제

프로젝트에서 애플리케이션 및 애플리케이션과 관련된 모든 구성 요소를 삭제할 수 있습니다.

2.4.8.1. 애플리케이션 삭제

애플리케이션을 삭제하려면 odo app delete 명령을 사용합니다.

절차

  1. 현재 프로젝트의 애플리케이션을 나열합니다.

    $ odo app list

    출력 예

        The project '<project_name>' has the following applications:
        NAME
        app

  2. 애플리케이션과 관련된 구성 요소를 나열합니다. 이러한 구성 요소는 애플리케이션과 함께 삭제됩니다.

    $ odo component list

    출력 예

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. 애플리케이션을 삭제합니다.

    $ odo app delete <application_name>

    출력 예

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Y를 사용하여 삭제를 확인합니다. -f 플래그를 사용하여 확인 프롬프트를 억제할 수 있습니다.

2.4.9. odo에서 애플리케이션 디버깅

odo를 사용하면 디버거를 연결하여 원격으로 애플리케이션을 디버깅할 수 있습니다. 이 기능은 NodeJS 및 Java 구성 요소에서만 지원됩니다.

odo를 사용하여 생성한 구성 요소는 기본적으로 디버그 모드에서 실행됩니다. 디버거 에이전트는 특정 포트의 해당 구성 요소에서 실행됩니다. 애플리케이션 디버깅을 시작하려면 포트 전달을 시작하고 IDE(통합 개발 환경)에 번들된 로컬 디버거를 연결해야 합니다.

2.4.9.1. 애플리케이션 디버깅

odo에서 odo debug 명령을 사용하여 애플리케이션을 디버깅할 수 있습니다.

절차

  1. 해당 devfile 내에 필요한 debugrun 단계가 포함되어 있는 샘플 애플리케이션을 다운로드합니다.

    $ odo create nodejs --starter

    출력 예

    Validation
     ✓  Checking devfile existence [11498ns]
     ✓  Checking devfile compatibility [15714ns]
     ✓  Creating a devfile component from registry: DefaultDevfileRegistry [17565ns]
     ✓  Validating devfile component [113876ns]
    
    Starter Project
     ✓  Downloading starter project nodejs-starter from https://github.com/odo-devfiles/nodejs-ex.git [428ms]
    
    Please use `odo push` command to create the component with source deployed

  2. 모든 디버깅 배포에 필요한 --debug 플래그를 사용하여 애플리케이션을 푸시합니다.

    $ odo push --debug

    출력 예

    Validation
     ✓  Validating the devfile [29916ns]
    
    Creating Kubernetes resources for component nodejs
     ✓  Waiting for component to start [38ms]
    
    Applying URL changes
     ✓  URLs are synced with the cluster, no changes are required.
    
    Syncing to component nodejs
     ✓  Checking file changes for pushing [1ms]
     ✓  Syncing files to the component [778ms]
    
    Executing devfile commands for component nodejs
     ✓  Executing install command "npm install" [2s]
     ✓  Executing debug command "npm run debug" [1s]
    
    Pushing devfile component nodejs
     ✓  Changes successfully pushed to component

    참고

    --debug-command="custom-step" 플래그를 사용하여 사용자 정의 디버그 명령을 지정할 수 있습니다.

  3. 디버깅 인터페이스에 액세스하려면 로컬 포트에 대해 포트 전달을 실행합니다.

    $ odo debug port-forward

    출력 예

    Started port forwarding at ports - 5858:5858

    참고

    --local-port 플래그를 사용하여 포트를 지정할 수 있습니다.

  4. 디버그 세션이 별도의 터미널 창에서 실행되고 있는지 확인합니다.

    $ odo debug info

    출력 예

    Debug is running for the component on the local port : 5858

  5. 선택한 IDE에 번들된 디버거를 연결합니다. 지침은 VSCode 디버깅 인터페이스와 같은 IDE에 따라 달라집니다.

2.4.9.2. 디버깅 매개변수 구성

원격 포트는 odo config 명령, 로컬 포트는 odo debug 명령을 사용하여 지정할 수 있습니다.

절차

  • 디버깅 에이전트를 실행해야 하는 원격 포트를 설정하려면 다음을 실행합니다.

    $ odo config set DebugPort 9292
    참고

    이 값이 구성 요소에 반영되도록 하려면 구성 요소를 다시 배포해야 합니다.

  • 포트 전달을 실행할 로컬 포트를 설정하려면 다음을 실행합니다.

    $ odo debug port-forward --local-port 9292
    참고

    로컬 포트 값은 유지되지 않습니다. 포트를 변경해야 할 때마다 포트 값을 제공해야 합니다.

2.4.10. 샘플 애플리케이션

odo는 구성 요소 유형에 대한 OpenShift 카탈로그에 나열된 언어 또는 런타임에 부분 호환성을 제공합니다. 예를 들면 다음과 같습니다.

NAME        PROJECT       TAGS
dotnet      openshift     3.1,latest
httpd       openshift     2.4,latest
java        openshift     8,latest
nginx       openshift     1.10,1.12,1.8,latest
nodejs      openshift     0.10,4,6,8,latest
perl        openshift     5.16,5.20,5.24,latest
php         openshift     5.5,5.6,7.0,7.1,latest
python      openshift     2.7,3.3,3.4,3.5,3.6,latest
ruby        openshift     2.0,2.2,2.3,2.4,latest
wildfly     openshift     10.0,10.1,8.1,9.0,latest
참고

odo Java 및 Node.js는 공식적으로 지원되는 구성 요소 유형입니다. 공식적으로 지원되는 구성 요소 유형을 확인하려면 odo catalog list components를 실행합니다.

웹을 통해 구성 요소에 액세스하려면 odo url create를 사용하여 URL을 생성합니다.

2.4.10.1. Git 리포지터리의 예

2.4.10.1.1. httpd

이 예는 CentOS 7에서 httpd를 사용하여 정적 콘텐츠를 빌드하고 제공하는 데 도움이 됩니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 Apache HTTP Server 컨테이너 이미지 리포지터리를 참조하십시오.

$ odo create httpd --git https://github.com/openshift/httpd-ex.git
2.4.10.1.2. java

이 예는 CentOS 7에서 fat JAR Java 애플리케이션을 빌드하고 실행하는 데 도움이 됩니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 Java S2I 빌더 이미지를 참조하십시오.

$ odo create java --git https://github.com/spring-projects/spring-petclinic.git
2.4.10.1.3. nodejs

CentOS 7에서 Node.js 애플리케이션을 빌드하고 실행합니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 Node.js 8 컨테이너 이미지를 참조하십시오.

$ odo create nodejs --git https://github.com/openshift/nodejs-ex.git
2.4.10.1.4. perl

이 예는 CentOS 7에서 Perl 애플리케이션을 빌드하고 실행하는 데 도움이 됩니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 Perl 5.26 컨테이너 이미지를 참조하십시오.

$ odo create perl --git https://github.com/openshift/dancer-ex.git
2.4.10.1.5. php

이 예는 CentOS 7에서 PHP 애플리케이션을 빌드하고 실행하는 데 도움이 됩니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 PHP 7.1 Docker 이미지를 참조하십시오.

$ odo create php --git https://github.com/openshift/cakephp-ex.git
2.4.10.1.6. python

이 예는 CentOS 7에서 Python 애플리케이션을 빌드하고 실행하는 데 도움이 됩니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 Python 3.6 컨테이너 이미지를 참조하십시오.

$ odo create python --git https://github.com/openshift/django-ex.git
2.4.10.1.7. ruby

이 예는 CentOS 7에서 Ruby 애플리케이션을 빌드하고 실행하는 데 도움이 됩니다. OpenShift Container Platform 고려 사항을 비롯한 이 빌더 이미지 사용에 대한 자세한 내용은 Ruby 2.5 컨테이너 이미지를 참조하십시오.

$ odo create ruby --git https://github.com/openshift/ruby-ex.git

2.4.10.2. 바이너리 예

2.4.10.2.1. java

Java는 다음과 같이 바이너리 아티팩트를 배포하는 데 사용할 수 있습니다.

$ git clone https://github.com/spring-projects/spring-petclinic.git
$ cd spring-petclinic
$ mvn package
$ odo create java test3 --binary target/*.jar
$ odo push

2.5. 제한된 환경의 odo 사용

2.5.1. 제한된 환경의 odo 정보

연결이 끊긴 클러스터 또는 제한된 환경에 프로비저닝된 클러스터에서 odo를 실행하려면 클러스터 관리자가 미러링된 레지스트리를 사용하여 클러스터를 생성했는지 확인해야 합니다.

연결이 끊긴 클러스터에서 작업을 시작하려면 먼저 odo init 이미지를 클러스터 레지스트리로 푸시한 다음 ODO_BOOTSTRAPPER_IMAGE 환경 변수를 사용하여 odo init 이미지 경로를 덮어써야 합니다.

odo init 이미지를 푸시한 후 레지스트리에서 지원되는 빌더 이미지를 미러링하고, 미러 레지스트리를 덮어쓰고, 애플리케이션을 생성해야 합니다. 애플리케이션의 런타임 환경을 구성하려면 빌더 이미지가 필요합니다. 빌더 이미지에는 애플리케이션을 빌드하는 데 필요한 빌드 툴(예: Node.js용 npm 또는 Java용 Maven)도 포함되어 있습니다. 미러 레지스트리에는 애플리케이션에 필요한 모든 종속 항목이 포함되어 있습니다.

2.5.2. 제한된 클러스터 레지스트리로 odo init 이미지 푸시

클러스터 및 운영 체제 구성에 따라 odo init 이미지를 미러 레지스트리로 푸시하거나 내부 레지스트리로 직접 푸시할 수 있습니다.

2.5.2.1. 사전 요구 사항

  • 클라이언트 운영 체제에 oc를 설치해야 합니다.
  • 클라이언트 운영 체제에 odo를설치합니다.
  • 내부 레지스트리 또는 미러 레지스트리가 구성되어 있는 제한된 클러스터에 대한 액세스 권한이 있어야 합니다.

2.5.2.2. 미러 레지스트리로 odo init 이미지 푸시

운영 체제에 따라 다음과 같이 미러 레지스트리가 있는 클러스터로 odo init 이미지를 푸시할 수 있습니다.

2.5.2.2.1. Linux에서 미러 레지스트리로 init 이미지 푸시

프로세스

  1. base64를 사용하여 미러 레지스트리의 root CA(인증 기관) 콘텐츠를 인코딩합니다.

    $ echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. 인코딩된 root CA 인증서를 적절한 위치에 복사합니다.

    $ sudo cp ./disconnect-ca.crt /etc/pki/ca-trust/source/anchors/<mirror-registry>.crt
  3. 클라이언트 플랫폼에서 CA를 신뢰하도록 지정하고 OpenShift Container Platform 미러 레지스트리에 로그인합니다.

    $ sudo update-ca-trust enable && sudo systemctl daemon-reload && sudo systemctl restart / docker && docker login <mirror-registry>:5000 -u <username> -p <password>
  4. odo init 이미지를 미러링합니다.

    $ oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  5. ODO_BOOTSTRAPPER_IMAGE 환경 변수를 설정하여 기본 odo init 이미지 경로를 재정의합니다.

    $ export ODO_BOOTSTRAPPER_IMAGE=<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
2.5.2.2.2. MacOS에서 미러 레지스트리로 init 이미지 푸시

프로세스

  1. base64를 사용하여 미러 레지스트리의 root CA(인증 기관) 콘텐츠를 인코딩합니다.

    $ echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. 인코딩된 root CA 인증서를 적절한 위치에 복사합니다.

    1. Docker UI를 사용하여 Docker를 재시작합니다.
    2. 다음 명령을 실행합니다.

      $ docker login <mirror-registry>:5000 -u <username> -p <password>
  3. odo init 이미지를 미러링합니다.

    $ oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  4. ODO_BOOTSTRAPPER_IMAGE 환경 변수를 설정하여 기본 odo init 이미지 경로를 재정의합니다.

    $ export ODO_BOOTSTRAPPER_IMAGE=<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
2.5.2.2.3. Windows에서 미러 레지스트리로 init 이미지 푸시

프로세스

  1. base64를 사용하여 미러 레지스트리의 root CA(인증 기관) 콘텐츠를 인코딩합니다.

    PS C:\> echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. 관리자로 다음 명령을 실행하여 인코딩된 root CA 인증서를 적절한 위치에 복사합니다.

    PS C:\WINDOWS\system32> certutil -addstore -f "ROOT" disconnect-ca.crt
  3. 클라이언트 플랫폼에서 CA를 신뢰하도록 지정하고 OpenShift Container Platform 미러 레지스트리에 로그인합니다.

    1. Docker UI를 사용하여 Docker를 재시작합니다.
    2. 다음 명령을 실행합니다.

      PS C:\WINDOWS\system32> docker login <mirror-registry>:5000 -u <username> -p <password>
  4. odo init 이미지를 미러링합니다.

    PS C:\> oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  5. ODO_BOOTSTRAPPER_IMAGE 환경 변수를 설정하여 기본 odo init 이미지 경로를 재정의합니다.

    PS C:\> $env:ODO_BOOTSTRAPPER_IMAGE="<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>"

2.5.2.3. 내부 레지스트리로 odo init 이미지 직접 푸시

클러스터를 통해 내부 레지스트리로 이미지를 직접 푸시할 수 있는 경우 다음과 같이 해당 레지스트리로 odo init 이미지를 푸시합니다.

2.5.2.3.1. Linux에서 init 이미지 직접 푸시

프로세스

  1. 기본 경로를 활성화합니다.

    $ oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. 와일드카드 경로 CA를 가져옵니다.

    $ oc get secret router-certs-default -n openshift-ingress -o yaml

    출력 예

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. base64를 사용하여 미러 레지스트리의 root CA(인증 기관) 콘텐츠를 인코딩합니다.

    $ echo <tls.crt> | base64 --decode > ca.crt
  4. 클라이언트 플랫폼에서 CA를 신뢰하도록 지정합니다.

    $ sudo cp ca.crt  /etc/pki/ca-trust/source/anchors/externalroute.crt && sudo update-ca-trust enable && sudo systemctl daemon-reload && sudo systemctl restart docker
  5. 내부 레지스트리에 로그인합니다.

    $ oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    $ docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. odo init 이미지를 푸시합니다.

    $ docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. ODO_BOOTSTRAPPER_IMAGE 환경 변수를 설정하여 기본 odo init 이미지 경로를 재정의합니다.

    $ export ODO_BOOTSTRAPPER_IMAGE=<registry_path>/openshiftdo/odo-init-image-rhel7:1.0.1
2.5.2.3.2. MacOS에서 init 이미지 직접 푸시

프로세스

  1. 기본 경로를 활성화합니다.

    $ oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. 와일드카드 경로 CA를 가져옵니다.

    $ oc get secret router-certs-default -n openshift-ingress -o yaml

    출력 예

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. base64를 사용하여 미러 레지스트리의 root CA(인증 기관) 콘텐츠를 인코딩합니다.

    $ echo <tls.crt> | base64 --decode > ca.crt
  4. 클라이언트 플랫폼에서 CA를 신뢰하도록 지정합니다.

    $ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt
  5. 내부 레지스트리에 로그인합니다.

    $ oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    $ docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. odo init 이미지를 푸시합니다.

    $ docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. ODO_BOOTSTRAPPER_IMAGE 환경 변수를 설정하여 기본 odo init 이미지 경로를 재정의합니다.

    $ export ODO_BOOTSTRAPPER_IMAGE=<registry_path>/openshiftdo/odo-init-image-rhel7:1.0.1
2.5.2.3.3. Windows에서 init 이미지 직접 푸시

프로세스

  1. 기본 경로를 활성화합니다.

    PS C:\> oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. 와일드카드 경로 CA를 가져옵니다.

    PS C:\> oc get secret router-certs-default -n openshift-ingress -o yaml

    출력 예

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. base64를 사용하여 미러 레지스트리의 root CA(인증 기관) 콘텐츠를 인코딩합니다.

    PS C:\> echo <tls.crt> | base64 --decode > ca.crt
  4. 관리자로 다음 명령을 실행하여 클라이언트 플랫폼에서 CA를 신뢰하도록 지정합니다.

    PS C:\WINDOWS\system32> certutil -addstore -f "ROOT" ca.crt
  5. 내부 레지스트리에 로그인합니다.

    PS C:\> oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    PS C:\> docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. odo init 이미지를 푸시합니다.

    PS C:\> docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    PS C:\> docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    PS C:\> docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. ODO_BOOTSTRAPPER_IMAGE 환경 변수를 설정하여 기본 odo init 이미지 경로를 재정의합니다.

    PS C:\> $env:ODO_BOOTSTRAPPER_IMAGE="<registry_path>/openshiftdo/odo-init-image-rhel7:<tag>"

2.5.3. 구성 요소를 생성하여 연결이 끊긴 클러스터에 배포

미러링된 레지스트리가 있는 클러스터로 init 이미지를 푸시한 후에는 oc 툴을 사용하여 애플리케이션의 지원되는 빌더 이미지를 미러링하고, 환경 변수를 사용하여 미러 레지스트리를 덮어쓰고, 구성 요소를 생성해야 합니다.

2.5.3.1. 사전 요구 사항

2.5.3.2. 지원되는 빌더 이미지 미러링

Node.js 종속 항목용 npm 패키지 및 Java 종속 항목용 Maven 패키지를 사용하며 애플리케이션의 런타임 환경을 구성하려면 미러 레지스트리의 해당 빌더 이미지를 미러링해야 합니다.

절차

  1. 필요한 이미지 태그를 가져오지 않았는지 확인합니다.

    $ oc describe is nodejs -n openshift

    출력 예

    Name:                   nodejs
    Namespace:              openshift
    [...]
    
    10
      tagged from <mirror-registry>:<port>/rhoar-nodejs/nodejs-10
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs, hidden
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      ! error: Import failed (NotFound): dockerimage.image.openshift.io "<mirror-registry>:<port>/rhoar-nodejs/nodejs-10:latest" not found
          About an hour ago
    
    10-SCL (latest)
      tagged from <mirror-registry>:<port>/rhscl/nodejs-10-rhel7
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      ! error: Import failed (NotFound): dockerimage.image.openshift.io "<mirror-registry>:<port>/rhscl/nodejs-10-rhel7:latest" not found
          About an hour ago
    
    [...]

  2. 지원되는 이미지 태그를 프라이빗 레지스트리로 미러링합니다.

    $ oc image mirror registry.access.redhat.com/rhscl/nodejs-10-rhel7:<tag> <private_registry>/rhscl/nodejs-10-rhel7:<tag>
  3. 이미지를 가져옵니다.

    $ oc tag <mirror-registry>:<port>/rhscl/nodejs-10-rhel7:<tag> nodejs-10-rhel7:latest --scheduled

    이미지는 정기적으로 다시 가져와야 합니다. --scheduled 플래그를 사용하면 자동으로 이미지를 다시 가져올 수 있습니다.

  4. 지정된 태그가 있는 이미지를 가져왔는지 확인합니다.

    $ oc describe is nodejs -n openshift

    출력 예

    Name:                   nodejs
    [...]
    10-SCL (latest)
      tagged from <mirror-registry>:<port>/rhscl/nodejs-10-rhel7
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      * <mirror-registry>:<port>/rhscl/nodejs-10-rhel7@sha256:d669ecbc11ac88293de50219dae8619832c6a0f5b04883b480e073590fab7c54
          3 minutes ago
    
    [...]

2.5.3.3. 미러 레지스트리 덮어쓰기

프라이빗 미러 레지스트리에서 Node.js 종속 항목용 npm 패키지 및 Java 종속 항목용 Maven 패키지를 다운로드하려면 클러스터에서 미러 npm 또는 Maven 레지스트리를 생성하고 구성해야 합니다. 그런 다음 기존 구성 요소에서 미러 레지스트리를 덮어쓰거나 새 구성 요소를 생성할 때 미러 레지스트리를 덮어쓸 수 있습니다.

절차

  • 기존 구성 요소에서 미러 레지스트리를 덮어쓰려면 다음을 실행합니다.

    $ odo config set --env NPM_MIRROR=<npm_mirror_registry>
  • 구성 요소를 생성할 때 미러 레지스트리를 덮어쓰려면 다음을 실행합니다.

    $ odo component create nodejs --env NPM_MIRROR=<npm_mirror_registry>

2.5.3.4. odo를 사용하여 Node.js 애플리케이션 생성

Node.js 구성 요소를 생성하려면 odo를 사용하여 Node.js 애플리케이션을 다운로드하고 소스 코드를 클러스터로 푸시합니다.

절차

  1. 현재 디렉터리를 애플리케이션이 있는 디렉터리로 변경합니다.

    $ cd <directory_name>
  2. Node.js 유형의 구성 요소를 애플리케이션에 추가합니다.

    $ odo create nodejs
    참고

    기본적으로 최신 이미지가 사용됩니다. odo create openshift/nodejs:8을 사용하여 명시적으로 이미지 버전을 지정할 수도 있습니다.

  3. 초기 소스 코드를 구성 요소로 푸시합니다.

    $ odo push

    이제 OpenShift Container Platform에 구성 요소가 배포되었습니다.

  4. URL을 생성하고 다음과 같이 로컬 구성 파일에 항목을 추가합니다.

    $ odo url create --port 8080
  5. 변경 사항을 푸시합니다. 이렇게 하면 클러스터에 URL이 생성됩니다.

    $ odo push
  6. URL이 나열되도록 하여 구성 요소에 원하는 URL이 지정되었는지 확인합니다.

    $ odo url list
  7. 생성된 URL을 사용하여 배포된 애플리케이션을 확인합니다.

    $ curl <url>

2.5.4. 연결이 끊긴 클러스터에 devfile 구성 요소를 생성 및 배포

2.5.4.1. 연결이 끊긴 클러스터에서 devfile을 사용하여 NodeJS 애플리케이션 생성

주의

이 절차에서는 Red Hat에서 유지 관리되지 않는 nodejs-ex.git 애플리케이션과 같은 외부 종속성을 사용합니다. 이러한 종속성은 문서를 통해 유지 관리되지 않으며 해당 기능을 보장할 수 없습니다.

사전 요구 사항

  • 연결이 끊긴 클러스터에 로그인되어 있어야 합니다.
  • 프록시에 raw.githubusercontent.com, registry.access.redhat.comregistry.npmjs.org URL이 추가되어 있어야 합니다.

프로세스

  1. devfile에서 NodeJS 애플리케이션을 정의합니다.

    devfile의 예

    schemaVersion: 2.0.0
    metadata:
    name: nodejs
    starterProjects:
    - name: nodejs-starter
      git:
        remotes:
          origin: "https://github.com/odo-devfiles/nodejs-ex.git"
    components:
    - name: runtime
      container:
        image: registry.access.redhat.com/ubi8/nodejs-12:1-36
        memoryLimit: 1024Mi
        endpoints:
          - name: "3000/tcp"
            targetPort: 3000
        env:
          - name: HTTP_PROXY
            value: http://<proxy-host>:<proxy-port>
          - name: HTTPS_PROXY
            value: http://<proxy-host>:<proxy-port>
        mountSources: true
    commands:
    - id: devbuild
      exec:
        component: runtime
        commandLine: npm install
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: build
          isDefault: true
    - id: build
      exec:
        component: runtime
        commandLine: npm install
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: build
    - id: devrun
      exec:
        component: runtime
        commandLine: npm start
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: run
          isDefault: true
    - id: run
      exec:
        component: runtime
        commandLine: npm start
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: run

  2. 애플리케이션을 생성하고 클러스터로 변경 사항을 푸시합니다.

    $ odo create nodejs --devfile <path-to-your-devfile> --starter $$ odo push

    출력 예

    [...]
    Pushing devfile component nodejs
     ✓  Changes successfully pushed to component

  3. 애플리케이션에 액세스할 URL을 생성하여 클러스터로 푸시합니다.

    $ odo url create url1 --port 3000 --host example.com --ingress && odo push

    출력 예

    Validation
     ✓  Validating the devfile [145374ns]
    
    Creating Kubernetes resources for component nodejs
     ✓  Waiting for component to start [14s]
    
    Applying URL changes
     ✓  URL url1: http://url1.abcdr.com/ created
    
    Syncing to component nodejs
     ✓  Checking file changes for pushing [2ms]
     ✓  Syncing files to the component [3s]
    
    Executing devfile commands for component nodejs
     ✓  Executing devbuild command "npm install" [4s]
     ✓  Executing devrun command "npm start" [3s]
    
    Pushing devfile component nodejs
     ✓  Changes successfully pushed to component

  4. 애플리케이션에 스토리지를 추가합니다.

    $ odo storage create <storage-name> --path /data --size 5Gi

    출력 예

    ✓  Added storage abcde to nodejs
    
    Please use `odo push` command to make the storage accessible to the component

  5. 클러스터로 변경 사항을 푸시합니다.

    $ odo push

2.5.4.2. 연결이 끓긴 클러스터에서 devfile을 사용하여 Java 애플리케이션 생성

주의

이 절차에서는 quay.io/eclipse/che-java11-maven:nightly Red Hat에서 유지 관리하지 않는 애플리케이션 springboot-ex 예제와 같은 외부 종속성을 사용하고 있습니다. 이러한 종속성은 문서를 통해 유지 관리되지 않으며 해당 기능을 보장할 수 없습니다.

사전 요구 사항

  • 연결이 끊긴 클러스터에 로그인되어 있어야 합니다.
  • 프록시 구성에 quay.io, registry.access.redhat.com, apache.org, quayio-production-s3.amazonaws.com URL을 추가했습니다.

프로세스

  1. devfile에서 Java 애플리케이션을 정의합니다.

    devfile의 예

    schemaVersion: 2.0.0
    metadata:
      name: java-maven
      version: 1.1.0
    starterProjects:
      - name: springbootproject
        git:
          remotes:
            origin: "https://github.com/odo-devfiles/springboot-ex.git"
    components:
      - name: tools
        container:
          image: quay.io/eclipse/che-java11-maven:nightly
          memoryLimit: 512Mi
          mountSources: true
          endpoints:
            - name: 'http-8080'
              targetPort: 8080
          volumeMounts:
            - name: m2
              path: /home/user/.m2
      - name: m2
        volume: {}
    commands:
      - id: mvn-package
        exec:
          component: tools
          commandLine: "mvn -Dmaven.repo.local=/home/user/.m2/repository -Dhttp.proxyHost=<proxy-host> -Dhttp.proxyPort=<proxy-port> -Dhttps.proxyHost=<proxy-host> -Dhttps.proxyPort=<proxy-port> package"
          group:
            kind: build
            isDefault: true
      - id: run
        exec:
          component: tools
          commandLine: "java -jar target/*.jar"
          group:
            kind: run
            isDefault: true
      - id: debug
        exec:
          component: tools
          commandLine: "java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=${DEBUG_PORT},suspend=n -jar target/*.jar"
          group:
            kind: debug
            isDefault: true

  2. Java 애플리케이션을 생성합니다.

    $ odo create java-maven --devfile <path-to-your-devfile> --starter

    출력 예

    Validation
     ✓  Checking devfile existence [87716ns]
     ✓  Creating a devfile component from registry: DefaultDevfileRegistry [107247ns]
     ✓  Validating devfile component [396971ns]
    
     Starter Project
     ✓  Downloading starter project springbootproject from https://github.com/odo-devfiles/springboot-ex.git [2s]
    
    Please use `odo push` command to create the component with source deployed

  3. 클러스터로 변경 사항을 푸시합니다.

    $ odo push

    출력 예

    I0224 14:43:18.802512   34741 util.go:727] HTTPGetRequest: https://raw.githubusercontent.com/openshift/odo/master/build/VERSION
    I0224 14:43:18.833631   34741 context.go:115] absolute devfile path: '/Users/pkumari/go/src/github.com/openshift/odo/testim/devfile.yaml'
    [...]
    Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.2.1/plexus-utils-3.2.1.jar (262 kB at 813 kB/s)
    [INFO] Replacing main artifact with repackaged archive
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time:  19.638 s
    [INFO] Finished at: 2021-02-24T08:59:30Z
    [INFO] ------------------------------------------------------------------------
     ✓  Executing mvn-package command "mvn -Dmaven.repo.local=/home/user/.m2/repository -Dhttp.proxyHost=<proxy-host> -Dhttp.proxyPort=<proxy-port> -Dhttps.proxyHost=<proxy-host> -Dhttps.proxyPort=<proxy-port> package" [23s]
     •  Executing run command "java -jar target/*.jar"  ...
    I0224 14:29:30.557676   34426 exec.go:27] Executing command [/opt/odo/bin/supervisord ctl start devrun] for pod: java-maven-5b8f99fcdb-9dnk6 in container: tools
    devrun: started
     ✓  Executing run command "java -jar target/*.jar" [3s]
    
    Pushing devfile component java-maven
     ✓  Changes successfully pushed to component

  4. 로그를 표시하여 애플리케이션이 시작되었는지 확인합니다.

    $ odo log

    출력 예

    time="2021-02-24T08:58:58Z" level=info msg="create process:devrun"
    time="2021-02-24T08:58:58Z" level=info msg="create process:debugrun"
    time="2021-02-24T08:59:32Z" level=debug msg="no auth required"
    time="2021-02-24T08:59:32Z" level=debug msg="succeed to find process:devrun"
    time="2021-02-24T08:59:32Z" level=info msg="try to start program" program=devrun
    time="2021-02-24T08:59:32Z" level=info msg="success to start program" program=devrun
    ODO_COMMAND_RUN is java -jar target/*.jar
    Executing command  java -jar target/*.jar
    [...]

  5. 애플리케이션의 스토리지를 생성합니다.

    $ odo storage create storage-name --path /data --size 5Gi

    출력 예

    ✓  Added storage storage-name to java-maven
    
    Please use `odo push` command to make the storage accessible to the component

  6. 클러스터로 변경 사항을 푸시합니다.

    $ odo push

    출력 결과

    ✓  Waiting for component to start [310ms]
    
    Validation
     ✓  Validating the devfile [100798ns]
    
    Creating Kubernetes resources for component java-maven
     ✓  Waiting for component to start [30s]
     ✓  Waiting for component to start [303ms]
    
    Applying URL changes
     ✓  URLs are synced with the cluster, no changes are required.
    
    Syncing to component java-maven
     ✓  Checking file changes for pushing [5ms]
     ✓  Syncing files to the component [4s]
    
    Executing devfile commands for component java-maven
     ✓  Waiting for component to start [526ms]
     ✓  Executing mvn-package command "mvn -Dmaven.repo.local=/home/user/.m2/repository -Dhttp.proxyHost=<proxy-host> -Dhttp.proxyPort=<proxy-port> -Dhttps.proxyHost=<proxy-host> -Dhttps.proxyPort=<proxy-port> package" [10s]
     ✓  Executing run command "java -jar target/*.jar" [3s]
    
    Pushing devfile component java-maven
     ✓  Changes successfully pushed to component

2.6. Operator에서 관리하는 서비스 인스턴스 생성

Operator는 Kubernetes 서비스를 패키징, 배포 및 관리하는 방법입니다. odo를 사용하면 Operator가 제공하는 CRD(사용자 정의 리소스 정의)에서 서비스 인스턴스를 생성할 수 있습니다. 그런 다음, 프로젝트에서 이러한 인스턴스를 사용할 수 있으며 구성 요소에 연결할 수 있습니다.

Operator에서 서비스를 생성하려면 Operator의 metadata에 요청된 서비스를 시작하는 데 유효한 값이 정의되어 있어야 합니다. odo는 Operator의 metadata.annotations.alm-examples YAML 파일을 사용하여 서비스를 시작합니다. 이 YAML에 자리 표시자 값이나 샘플 값이 있는 경우 서비스를 시작할 수 없습니다. YAML 파일을 수정하면 수정된 값으로 서비스를 시작할 수 있습니다. YAML 파일을 수정하고 이 파일로 서비스를 시작하는 방법을 알아보려면 YAML 파일에서 서비스 생성을 참조하십시오.

2.6.1. 사전 요구 사항

  • oc CLI를 설치하고 클러스터에 로그인해야 합니다.

    • 클러스터 구성에 따라 사용 가능한 서비스가 결정됩니다. Operator 서비스에 액세스하려면 먼저 클러스터 관리자가 클러스터에 해당 Operator를 설치해야 합니다. 자세한 내용은 클러스터에 Operator 추가를 참조하십시오.
  • odo CLI를 설치해야 합니다.

2.6.2. 프로젝트 생성

별도의 단일 단위로 구성된 소스 코드, 테스트 및 라이브러리가 있는 프로젝트를 생성합니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다.

    $ odo login -u developer -p developer
  2. 프로젝트를 생성합니다.

    $ odo project create myproject

    출력 예

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

2.6.3. 클러스터에 설치된 Operator의 사용 가능한 서비스 나열

odo를 사용하면 클러스터에 설치된 Operator 및 제공하는 서비스 목록을 표시할 수 있습니다.

  • 현재 프로젝트에 설치된 Operator를 나열하려면 다음을 실행합니다.

    $ odo catalog list services

    이 명령은 Operator 및 CRD를 나열합니다. 명령 출력은 클러스터에 설치된 Operator를 보여 줍니다. 예를 들면 다음과 같습니다.

    Operators available in the cluster
    NAME                          CRDs
    etcdoperator.v0.9.4           EtcdCluster, EtcdBackup, EtcdRestore
    mongodb-enterprise.v1.4.5     MongoDB, MongoDBUser, MongoDBOpsManager

    etcdoperator.v0.9.4는 Operator이고 EtcdCluster, EtcdBackupEtcdRestore는 Operator에서 제공하는 CRD입니다.

2.6.4. Operator에서 서비스 생성

Operator의 metadata에 요청된 서비스를 시작하는 데 유효한 값이 정의되어 있는 경우 odo service create로 해당 서비스를 사용할 수 있습니다.

  1. 서비스 YAML을 로컬 드라이브의 파일로 출력합니다.

    $ oc get csv/etcdoperator.v0.9.4 -o yaml
  2. 서비스 값이 유효한지 확인합니다.

    apiVersion: etcd.database.coreos.com/v1beta2
    kind: EtcdCluster
    metadata:
      name: example
    spec:
      size: 3
      version: 3.2.13
  3. etcdoperator.v0.9.4 Operator에서 EtcdCluster 서비스를 시작합니다.

    $ odo service create etcdoperator.v0.9.4 EtcdCluster
  4. 서비스가 시작되었는지 확인합니다.

    $ oc get EtcdCluster

2.6.5. YAML 파일에서 서비스 생성

서비스 또는 CR(사용자 정의 리소스)의 YAML 정의에 유효하지 않은 데이터 또는 자리 표시자 데이터가 있는 경우 --dry-run 플래그를 사용하여 YAML 정의를 가져오고, 올바른 값을 지정하고, 수정된 YAML 정의를 사용하여 서비스를 시작할 수 있습니다. 서비스를 시작하기 전에 서비스를 시작하는 데 사용되는 YAML을 출력하고 수정하도록 odo는 Operator에서 제공하는 서비스 또는 CR의 YAML 정의를 출력하는 기능을 지원합니다.

  1. 서비스 YAML을 표시하려면 다음을 실행합니다.

    $ odo service create <operator-name> --dry-run

    예를 들어 etcdoperator.v0.9.4 Operator에서 제공하는 EtcdCluster의 YAML 정의를 출력하려면 다음을 실행합니다.

    $ odo service create etcdoperator.v0.9.4 --dry-run

    YAML은 etcd.yaml 파일로 저장됩니다.

  2. etcd.yaml 파일을 수정합니다.

    apiVersion: etcd.database.coreos.com/v1beta2
    kind: EtcdCluster
    metadata:
      name: my-etcd-cluster 1
    spec:
      size: 1 2
      version: 3.2.13
    1
    이름을 example에서 my-etcd-cluster로 변경합니다.
    2
    크기를 3에서 1로 줄입니다.
  3. YAML 파일에서 서비스를 시작합니다.

    $ odo service create --from-file etcd.yaml
  4. EtcdCluster 서비스가 사전 구성된 세 개의 Pod가 아니라 한 개의 Pod로 시작되었는지 확인합니다.

    $ oc get pods | grep my-etcd-cluster

2.7. 환경 변수 관리

odo는 구성 요소별 구성 및 환경 변수를 config 파일에 저장합니다. odo config 명령을 사용하면 config 파일을 수정할 필요 없이 구성 요소의 환경 변수를 설정하고, 설정 해제하고, 나열할 수 있습니다.

2.7.1. 환경 변수 설정 및 설정 해제

절차

  • 구성 요소의 환경 변수를 설정하려면 다음을 실행합니다.

    $ odo config set --env <variable>=<value>
  • 구성 요소의 환경 변수를 설정 해제하려면 다음을 실행합니다.

    $ odo config unset --env <variable>
  • 구성 요소의 모든 환경 변수를 나열하려면 다음을 실행합니다.

    $ odo config view

2.8. odo CLI 구성

2.8.1. 명령 완료 사용

참고

현재 명령 완료는 bash, zsh 및 fish 쉘에서만 지원됩니다.

odo는 사용자 입력을 기반으로 명령 매개변수에 대한 스마트 완료를 제공합니다. 이 기능이 작동하도록 하려면 odo가 실행 중인 쉘과 통합해야 합니다.

절차

  • 명령 완료를 자동으로 설치하려면 다음을 수행합니다.

    1. 다음을 실행합니다.

      $ odo --complete
    2. 완료 후크를 설치할 것인지 묻는 메시지가 표시되면 Y를 누릅니다.
  • 완료 후크를 수동으로 설치하려면 complete -o nospace -C <full_path_to_your_odo_binary> odo를 쉘 구성 파일에 추가합니다. 쉘 구성 파일을 수정한 후 쉘을 재시작합니다.
  • 완료를 비활성화하려면 다음을 수행합니다.

    1. 다음을 실행합니다.

      $ odo --uncomplete
    2. 완료 후크를 제거할 것인지 묻는 메시지가 표시되면 Y를 누릅니다.
참고

odo 실행 파일의 이름을 바꾸거나 다른 디렉터리로 이동하는 경우 명령 완료를 다시 활성화합니다.

2.8.2. 파일 또는 패턴 무시

애플리케이션 root 디렉터리의 .odoignore 파일을 수정하여 무시할 파일 또는 패턴 목록을 구성할 수 있습니다. 이 파일은 odo pushodo watch 둘 다에 적용됩니다.

.odoignore 파일이 없으면 특정 파일 및 폴더를 무시하는 데 .gitignore 파일이 대신 사용됩니다.

.git 파일, .js 확장자가 있는 모든 파일 및 tests 폴더를 무시하려면 .odoignore 또는 .gitignore 파일에 다음을 추가합니다.

.git
*.js
tests/

.odoignore 파일에는 모든 glob 표현식을 사용할 수 있습니다.

2.9. odo CLI 참조

2.9.1. 기본 odo CLI 명령

2.9.1.1. app

OpenShift Container Platform 프로젝트와 관련된 애플리케이션 작업을 수행합니다.

app 사용 예

  # Delete the application
  odo app delete myapp

  # Describe 'webapp' application,
  odo app describe webapp

  # List all applications in the current project
  odo app list

  # List all applications in the specified project
  odo app list --project myproject

2.9.1.2. catalog

카탈로그 관련 작업을 수행합니다.

catalog 사용 예

  # Get the supported components
  odo catalog list components

  # Get the supported services from service catalog
  odo catalog list services

  # Search for a component
  odo catalog search component python

  # Search for a service
  odo catalog search service mysql

  # Describe a service
  odo catalog describe service mysql-persistent

2.9.1.3. component

애플리케이션 구성 요소를 관리합니다.

component 사용 예

# Create a new component
odo component create

# Create a local configuration and create all objects on the cluster
odo component create --now

2.9.1.4. config

config 파일에서 odo 관련 설정을 수정합니다.

config 사용 예

  # For viewing the current local configuration
  odo config view

  # Set a configuration value in the local configuration
  odo config set Type java
  odo config set Name test
  odo config set MinMemory 50M
  odo config set MaxMemory 500M
  odo config set Memory 250M
  odo config set Ignore false
  odo config set MinCPU 0.5
  odo config set MaxCPU 2
  odo config set CPU 1

  # Set an environment variable in the local configuration
  odo config set --env KAFKA_HOST=kafka --env KAFKA_PORT=6639

  # Create a local configuration and apply the changes to the cluster immediately
  odo config set --now

  # Unset a configuration value in the local config
  odo config unset Type
  odo config unset Name
  odo config unset MinMemory
  odo config unset MaxMemory
  odo config unset Memory
  odo config unset Ignore
  odo config unset MinCPU
  odo config unset MaxCPU
  odo config unset CPU

  # Unset an env variable in the local config
  odo config unset --env KAFKA_HOST --env KAFKA_PORT

애플리케이션

Application은 구성 요소에 포함되어야 하는 애플리케이션의 이름입니다.

CPU

구성 요소에서 사용할 수 있는 최소 및 최대 CPU입니다.

Ignore

푸시 및 감시에서 .odoignore 파일을 고려합니다.

표 2.2. 사용 가능한 로컬 매개변수:

애플리케이션

구성 요소에 포함되어야 하는 애플리케이션의 이름입니다.

CPU

구성 요소에서 사용할 수 있는 최소 및 최대 CPU입니다.

Ignore

푸시 및 감시에서 .odoignore 파일을 고려할 것인지 여부입니다.

MaxCPU

구성 요소에서 사용할 수 있는 최대 CPU입니다.

MaxMemory

구성 요소에서 사용할 수 있는 최대 메모리입니다.

메모리

구성 요소에서 사용할 수 있는 최소 및 최대 메모리입니다.

MinCPU

구성 요소에서 사용할 수 있는 최소 CPU입니다.

MinMemory

구성 요소에 제공되는 최소 메모리입니다.

이름

구성 요소 이름입니다.

포트

구성 요소에서 열 포트입니다.

프로젝트

구성 요소에 포함된 프로젝트의 이름입니다.

Ref

Git 소스에서 구성 요소를 생성하는 데 사용할 Git 참조입니다.

SourceLocation

이 경로는 바이너리 파일 또는 Git 소스의 위치를 나타냅니다.

SourceType

git/binary/local 같은 구성 요소 소스 유형입니다.

스토리지

구성 요소 스토리지입니다.

유형

구성 요소 유형입니다.

Url

구성 요소에 액세스할 URL입니다.

2.9.1.5. create

OpenShift Container Platform에 배포할 구성 요소에 대해 설명하는 구성을 생성합니다. 구성 요소 이름을 제공하지 않으면 이름이 자동으로 생성됩니다.

기본적으로 현재 네임스페이스의 빌더 이미지가 사용됩니다. 네임스페이스를 명시적으로 제공하려면 odo create namespace/name:version을 사용합니다. 버전을 지정하지 않으면 버전이 latest로 기본 설정됩니다.

배포할 수 있는 구성 요소 유형의 전체 목록을 보려면 odo catalog list를 사용합니다.

create 사용 예

  # Create new Node.js component with the source in current directory.
  odo create nodejs

  # Create new Node.js component and push it to the cluster immediately.
  odo create nodejs --now

  # A specific image version may also be specified
  odo create nodejs:latest

  # Create new Node.js component named 'frontend' with the source in './frontend' directory
  odo create nodejs frontend --context ./frontend

  # Create a new Node.js component of version 6 from the 'openshift' namespace
  odo create openshift/nodejs:6 --context /nodejs-ex

  # Create new Wildfly component with binary named sample.war in './downloads' directory
  odo create wildfly wildfly --binary ./downloads/sample.war

  # Create new Node.js component with source from remote git repository
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git

  # Create new Node.js git component while specifying a branch, tag or commit ref
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git --ref master

  # Create new Node.js git component while specifying a tag
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git --ref v1.0.1

  # Create new Node.js component with the source in current directory and ports 8080-tcp,8100-tcp and 9100-udp exposed
  odo create nodejs --port 8080,8100/tcp,9100/udp

  # Create new Node.js component with the source in current directory and env variables key=value and key1=value1 exposed
  odo create nodejs --env key=value,key1=value1

  # Create a new Python component with the source in a Git repository
  odo create python --git https://github.com/openshift/django-ex.git

  # Passing memory limits
  odo create nodejs --memory 150Mi
  odo create nodejs --min-memory 150Mi --max-memory 300 Mi

  # Passing cpu limits
  odo create nodejs --cpu 2
  odo create nodejs --min-cpu 200m --max-cpu 2

2.9.1.6. debug

구성 요소를 디버깅합니다.

debug 사용 예

# Displaying information about the state of debugging
odo debug info

# Starting the port forwarding for a component to debug the application
odo debug port-forward

# Setting a local port to port forward
odo debug port-forward --local-port 9292

2.9.1.7. delete

기존 구성 요소를 삭제합니다.

delete 사용 예

  # Delete component named 'frontend'.
  odo delete frontend
  odo delete frontend --all-apps

2.9.1.8. describe

지정된 구성 요소를 설명합니다.

describe 사용 예

  # Describe nodejs component
  odo describe nodejs

2.9.1.10. list

현재 애플리케이션의 모든 구성 요소와 구성 요소의 상태를 나열합니다.

구성 요소의 상태

푸시됨
구성 요소가 클러스터로 푸시되었습니다.
푸시되지 않음
구성 요소가 클러스터로 푸시되지 않았습니다.
알 수 없음
odo와 클러스터의 연결이 끊겼습니다.

list 사용 예

  # List all components in the application
  odo list

  # List all the components in a given path
  odo list --path <path_to_your_component>

2.9.1.11. log

지정된 구성 요소의 로그를 검색합니다.

log 사용 예

  # Get the logs for the nodejs component
  odo log nodejs

2.9.1.12. login

클러스터에 로그인합니다.

login 사용 예

  # Log in interactively
  odo login

  # Log in to the given server with the given certificate authority file
  odo login localhost:8443 --certificate-authority=/path/to/cert.crt

  # Log in to the given server with the given credentials (basic auth)
  odo login localhost:8443 --username=myuser --password=mypass

  # Log in to the given server with the given credentials (token)
  odo login localhost:8443 --token=xxxxxxxxxxxxxxxxxxxxxxx

2.9.1.13. logout

현재 OpenShift Container Platform 세션에서 로그아웃합니다.

logout 사용 예

  # Log out
  odo logout

2.9.1.14. preference

글로벌 기본 설정 파일에서 odo 관련 구성 설정을 수정합니다.

preference 사용 예

  # For viewing the current preferences
  odo preference view

  # Set a preference value in the global preference
  odo preference set UpdateNotification false
  odo preference set NamePrefix "app"
  odo preference set Timeout 20

  # Enable experimental mode
  odo preference set experimental true

  # Unset a preference value in the global preference
  odo preference unset  UpdateNotification
  odo preference unset  NamePrefix
  odo preference unset  Timeout

  # Disable experimental mode
  odo preference set experimental false

  # Use persistent volumes in the cluster
  odo preference set ephemeral false

참고

기본적으로 글로벌 기본 설정 파일 경로는 ~/.odo/preferece.yaml이며 환경 변수 GLOBALODOCONFIG에 저장됩니다. 환경 변수 값을 새 기본 설정 경로(예: GLOBALODOCONFIG="new_path/preference.yaml")로 설정하여 사용자 정의 경로를 설정할 수 있습니다.

표 2.3. 사용 가능한 매개변수:

NamePrefix

기본 접두사는 현재 디렉터리 이름입니다. 이 값을 사용하여 기본 이름 접두사를 설정합니다.

Timeout

OpenShift Container Platform 서버 연결 확인에 적용되는 제한 시간(초)입니다.

UpdateNotification

업데이트 알림 표시 여부를 제어합니다.

2.9.1.15. project

프로젝트 작업을 수행합니다.

project 사용 예

  # Set the active project
  odo project set

  # Create a new project
  odo project create myproject

  # List all the projects
  odo project list

  # Delete a project
  odo project delete myproject

  # Get the active project
  odo project get

2.9.1.16. push

소스 코드를 구성 요소로 푸시합니다.

push 사용 예

  # Push source code to the current component
  odo push

  # Push data to the current component from the original source.
  odo push

  # Push source code in ~/mycode to component called my-component
  odo push my-component --context ~/mycode

  # Push source code and display event notifications in JSON format.
  odo push -o json

2.9.1.17. 레지스트리

사용자 정의 레지스트리를 생성하고 수정합니다.

registry 사용 예

# Add a registry to the registry list
odo registry add <registry name> <registry URL>

# List a registry in the registry list
odo registry list

# Delete a registry from the registry list
odo registry delete <registry name>

# Update a registry in the registry list
odo registry update <registry name> <registry URL>

# List a component with a corresponding registry
odo catalog list components

# Create a component that is hosted by a specific registry
odo create <component type> --registry <registry name>

2.9.1.18. service

서비스 카탈로그 작업을 수행합니다.

service 사용 예

  # Create new postgresql service from service catalog using dev plan and name my-postgresql-db.
  odo service create dh-postgresql-apb my-postgresql-db --plan dev -p postgresql_user=luke -p postgresql_password=secret

  # Delete the service named 'mysql-persistent'
  odo service delete mysql-persistent

  # List all services in the application
  odo service list

2.9.1.19. storage

스토리지 작업을 수행합니다.

storage 사용 예

  # Create storage of size 1Gb to a component
  odo storage create mystorage --path=/opt/app-root/src/storage/ --size=1Gi

  # Delete storage mystorage from the currently active component
  odo storage delete mystorage

  # List all storage attached or mounted to the current component and
  # all unattached or unmounted storage in the current application
  odo storage list

  # Set the `-o json` flag to get a JSON formatted output
  odo storage list -o json

2.9.1.21. update

구성 요소의 소스 코드 경로를 업데이트합니다.

update 사용 예

  # Change the source code path of a currently active component to local (use the current directory as a source)
  odo update --local

  # Change the source code path of the frontend component to local with source in ./frontend directory
  odo update frontend --local ./frontend

  # Change the source code path of a currently active component to git
  odo update --git https://github.com/openshift/nodejs-ex.git

  # Change the source code path of the component named node-ex to git
  odo update node-ex --git https://github.com/openshift/nodejs-ex.git

  # Change the source code path of the component named wildfly to a binary named sample.war in ./downloads directory
  odo update wildfly --binary ./downloads/sample.war

2.9.1.22. url

구성 요소를 외부 환경에 노출합니다.

url 사용 예

  # Create a URL for the current component with a specific port
  odo url create --port 8080

  # Create a URL with a specific name and port
  odo url create example --port 8080

  # Create a URL with a specific name by automatic detection of port (only for components which expose only one service port)
  odo url create example

  # Create a URL with a specific name and port for component frontend
  odo url create example --port 8080 --component frontend

  # Delete a URL to a component
  odo url delete myurl

  # List the available URLs
  odo url list

  # Create a URL in the configuration and apply the changes to the cluster
  odo url create --now

  # Create an HTTPS URL
  odo url create --secure

이 명령을 사용하여 생성된 URL은 클러스터 외부에서 배포된 구성 요소에 액세스하는 데 사용할 수 있습니다.

2.9.1.23. utils

터미널 명령 유틸리티로 odo 구성 수정에 사용됩니다.

utils 사용 예

  # Bash terminal PS1 support
  source <(odo utils terminal bash)

  # Zsh terminal PS1 support
  source <(odo utils terminal zsh)

2.9.1.24. version

클라이언트 버전 정보를 출력합니다.

version 사용 예

  # Print the client version of odo
  odo version

2.9.1.25. watch

odo는 변경에 대한 감시를 시작하고 변경이 수행되면 자동으로 구성 요소를 업데이트합니다.

watch 사용 예

  # Watch for changes in directory for current component
  odo watch

  # Watch for changes in directory for component called frontend
  odo watch frontend

2.10. odo 아키텍처

이 섹션에서는 odo 아키텍처 및 odo가 클러스터에서 리소스를 관리하는 방법에 대해 설명합니다.

2.10.1. 개발자 설정

odo를 사용하면 터미널에서 OpenShift Container Platform 클러스터에 애플리케이션을 생성하고 배포할 수 있습니다. 코드 편집기 플러그인은 odo를 사용하므로 사용자가 해당 IDE 터미널에서 OpenShift Container Platform 클러스터와 상호 작용할 수 있습니다. odo를 사용하는 플러그인의 예로는 VS Code OpenShift Connector, OpenShift Connector for Intellij, Codewind for Eclipse Che가 있습니다.

odo는 Windows, macOS 및 Linux 운영 체제의 모든 터미널에서 작동합니다. odo는 bash 및 zsh 명령줄 쉘에 자동 완성 기능을 제공합니다.

odo는 Node.js 및 Java 구성 요소를 지원합니다.

2.10.2. OpenShift S2I(Source-to-Image)

OpenShift S2I(Source-to-Image)는 소스 코드에서 아티팩트를 빌드하고 컨테이너 이미지에 삽입하는 데 도움이 되는 오픈 소스 프로젝트입니다. S2I는 Dockerfile 없이도 소스 코드를 빌드하여 바로 실행할 수 있는 이미지를 생성합니다. odo는 컨테이너 내에서 개발자 소스 코드를 실행하는 데 S2I 빌더 이미지를 사용합니다.

2.10.3. OpenShift 클러스터 오브젝트

2.10.3.1. Init 컨테이너

Init 컨테이너는 애플리케이션 컨테이너가 시작되기 전에 실행되는 특수 컨테이너로, 애플리케이션 컨테이너 실행에 필요한 환경을 구성합니다. Init 컨테이너는 애플리케이션 이미지에 없는 파일(예: 설정 스크립트)을 포함할 수 있습니다. Init 컨테이너는 항상 완료될 때까지 실행되며 실패하는 Init 컨테이너가 있는 경우 애플리케이션 컨테이너가 시작되지 않습니다.

odo에서 생성된 Pod는 다음 두 개의 Init 컨테이너를 실행합니다.

  • copy-supervisord Init 컨테이너
  • copy-files-to-volume Init 컨테이너
2.10.3.1.1. copy-supervisord

copy-supervisord Init 컨테이너는 필요한 파일을 emptyDir 볼륨에 복사합니다. 주요 애플리케이션 컨테이너는 emptyDir 볼륨에서 이러한 파일을 사용합니다.

emptyDir 볼륨에 복사되는 파일은 다음과 같습니다.

  • 바이너리:

    • go-init은 최소 init 시스템입니다. 애플리케이션 컨테이너 내에서 첫 번째 프로세스(PID 1)로 실행됩니다. go-init은 개발자 코드를 실행하는 SupervisorD 데몬을 시작합니다. go-init은 고립된 프로세스를 처리하는 데 필요합니다.
    • SupervisorD는 프로세스 제어 시스템입니다. 구성된 프로세스를 감시하고 실행 중인지 확인합니다. 필요한 경우 서비스를 재시작합니다. odo의 경우 SupervisorD는 개발자 코드를 실행하고 모니터링합니다.
  • 구성 파일:

    • supervisor.conf는 SupervisorD 데몬을 시작하는 데 필요한 구성 파일입니다.
  • 스크립트:

    • assemble-and-restart는 사용자 소스 코드 빌드 및 배포에 대한 OpenShift S2I 개념입니다. assemble-and-restart 스크립트는 먼저 애플리케이션 컨테이너 내에서 사용자 소스 코드를 어셈블한 후 사용자 변경 사항이 적용되도록 SupervisorD를 재시작합니다.
    • Run은 어셈블된 소스 코드 실행에 대한 OpenShift S2I 개념입니다. run 스크립트는 assemble-and-restart 스크립트에서 생성한 어셈블된 코드를 실행합니다.
    • s2i-setupassemble-and-restart에 필요한 파일 및 디렉터리를 생성하는 스크립트이며 어셈블된 스크립트가 성공적으로 실행되도록 스크립트를 실행합니다. 이 스크립트는 애플리케이션 컨테이너가 시작될 때마다 실행됩니다.
  • 디렉터리:

    • language-scripts: OpenShift S2I에서는 사용자 정의 assemblerun 스크립트를 사용할 수 있습니다. language-scripts 디렉터리에는 몇 개의 언어별 사용자 정의 스크립트가 있습니다. 사용자 정의 스크립트는 odo debug를 작동하게 하는 추가 구성을 제공합니다.

emptyDir 볼륨은 Init 컨테이너와 애플리케이션 컨테이너 둘 다에서 /opt/odo 마운트 옵션에 마운트됩니다.

2.10.3.1.2. copy-files-to-volume

copy-files-to-volume Init 컨테이너는 S2I 빌더 이미지의 /opt/app-root에 있는 파일을 영구 볼륨으로 복사합니다. 그러면 볼륨이 애플리케이션 컨테이너의 동일한 위치(/opt/app-root)에 마운트됩니다.

/opt/app-root에 영구 볼륨이 없으면 동일한 위치에 영구 볼륨 클레임이 마운트될 때 이 디렉터리의 데이터가 손실됩니다.

PVC는 Init 컨테이너 내 /mnt 마운트 옵션에 마운트됩니다.

2.10.3.2. 애플리케이션 컨테이너

애플리케이션 컨테이너는 사용자 소스 코드가 실행되는 컨테이너 내 주요 컨테이너입니다.

애플리케이션 컨테이너는 두 개의 볼륨으로 마운트됩니다.

  • /opt/odo에서 마운트된 emptyDir 볼륨
  • /opt/app-root에서 마운트된 영구 볼륨

go-init은 애플리케이션 컨테이너 내에서 첫 번째 프로세스로 실행됩니다. 그런 다음 go-init 프로세스는 SupervisorD 데몬을 시작합니다.

SupervisorD는 사용자가 어셈블한 소스 코드를 실행하고 모니터링합니다. 사용자 프로세스가 충돌하면 SupervisorD가 재시작됩니다.

2.10.3.3. 영구 볼륨 및 영구 볼륨 클레임

PVC(영구 볼륨 클레임)는 영구 볼륨을 프로비저닝하는 Kubernetes의 볼륨 유형입니다. 영구 볼륨의 수명은 Pod 라이프사이클과 별개입니다. Pod를 재시작해도 영구 볼륨의 데이터는 유지됩니다.

copy-files-to-volume Init 컨테이너는 영구 볼륨에 필요한 파일을 복사합니다. 기본 애플리케이션 컨테이너는 런타임 시 실행을 위해 이러한 파일을 활용합니다.

영구 볼륨의 이름 지정 규칙은 <component_name>-s2idata입니다.

컨테이너PVC 마운트 위치

copy-files-to-volume

/mnt

애플리케이션 컨테이너

/opt/app-root

2.10.3.4. emptyDir 볼륨

emptyDir 볼륨은 Pod가 노드에 할당될 때 생성되며 노드에서 Pod가 실행되는 동안 존재합니다. 컨테이너를 재시작하거나 이동하면 emptyDir 콘텐츠가 제거되며 Init 컨테이너가 데이터를 다시 emptyDir로 복원합니다. 처음에는 emptyDir이 비어 있습니다.

copy-supervisord Init 컨테이너는 필요한 파일을 emptyDir 볼륨에 복사합니다. 그러면 기본 애플리케이션 컨테이너가 런타임 시 실행을 위해 이러한 파일을 활용합니다.

컨테이너emptyDir volume 마운트 위치

copy-supervisord

/opt/odo

애플리케이션 컨테이너

/opt/odo

2.10.3.5. Service

서비스는 Pod 세트와 통신하는 방식 추상화에 대한 Kubernetes 개념입니다.

odo는 모든 애플리케이션 Pod에 대해 서비스를 생성하여 통신할 때 액세스할 수 있도록 합니다.

2.10.4. odo push 워크플로

이 섹션에서는 odo push 워크플로에 대해 설명합니다. odo push는 OpenShift Container Platform 클러스터에서 모든 필요한 OpenShift Container Platform 리소스와 함께 사용자 코드를 배포합니다.

  1. 리소스 생성

    odo push는 다음 OpenShift Container Platform 리소스가 아직 생성되지 않은 경우 해당 리소스를 생성합니다.

    • DeploymentConfig 오브젝트:

      • 두 개의 Init 컨테이너 copy-supervisordcopy-files-to-volume이 실행됩니다. Init 컨테이너는 emptyDirPersistentVolume 유형의 볼륨에 파일을 각각 복사합니다.
      • 애플리케이션 컨테이너가 시작됩니다. 애플리케이션 컨테이너의 첫 번째 프로세스는 PID=1인 go-init 프로세스입니다.
      • go-init 프로세스는 SupervisorD 데몬을 시작합니다.

        참고

        사용자 애플리케이션 코드는 아직 애플리케이션 컨테이너에 복사되지 않았으므로 SupervisorD 데몬에서 run 스크립트를 실행하지 않습니다.

    • Service 오브젝트
    • Secret 오브젝트
    • PersistentVolumeClaim 오브젝트
  2. 파일 인덱싱

    • 파일 인덱서는 소스 코드 디렉터리의 파일을 인덱싱합니다. 인덱서는 소스 코드 디렉터리에서 반복적으로 트래버스하여 생성되거나, 삭제되거나, 이름이 변경된 파일을 찾습니다.
    • 파일 인덱서는 .odo 디렉터리 내 odo 인덱스 파일에서 인덱싱된 정보를 유지 관리합니다.
    • odo 인덱스 파일이 없으면 파일 인덱서가 처음 실행되는 것이며 새 odo 인덱스 JSON 파일을 생성합니다. odo 인덱스 JSON 파일에는 트래버스된 파일의 상대 파일 경로와 변경되고 삭제된 파일의 절대 경로가 있는 파일 맵이 포함되어 있습니다.
  3. 코드 푸시

    로컬 코드가 애플리케이션 컨테이너, 주로 /tmp/src에 복사됩니다.

  4. assemble-and-restart 실행

    소스 코드가 성공적으로 복사되면 실행 중인 애플리케이션 컨테이너 내에서 assemble-and-restart 스크립트가 실행됩니다.

3장. Helm CLI

3.1. OpenShift Container Platform에서 Helm 3 시작하기

3.1.1. Helm 이해

Helm은 OpenShift Container Platform 클러스터에 대한 애플리케이션 및 서비스 배포를 간소화하는 소프트웨어 패키지 관리자입니다.

Helm은 차트라는 패키징 형식을 사용합니다. Helm 차트는 OpenShift Container Platform 리소스에 대해 설명하는 파일 컬렉션입니다.

클러스터에 있는 차트의 실행 중인 인스턴스를 릴리스라고 합니다. 클러스터에 차트가 설치될 때마다 새 릴리스가 생성됩니다.

차트를 설치하거나 릴리스를 업그레이드하거나 롤백할 때마다 번호가 증가한 리버전이 생성됩니다.

3.1.1.1. 주요 기능

Helm은 다음을 수행할 수 있는 기능을 제공합니다.

  • 차트 리포지토리에 저장된 대규모 차트 컬렉션에서 검색합니다.
  • 기존 차트를 수정합니다.
  • OpenShift Container Platform 또는 Kubernetes 리소스를 사용하여 자체 차트를 생성합니다.
  • 애플리케이션을 차트로 패키징하고 공유합니다.

3.1.2. Helm 설치

다음 섹션에서는 CLI를 사용하여 다양한 플랫폼에 Helm을 설치하는 방법을 설명합니다.

오른쪽 상단에 있는 ? 아이콘을 클릭하고 명령줄 툴을 선택하여 OpenShift Container Platform 웹 콘솔의 최신 바이너리 URL을 찾을 수도 있습니다.

사전 요구 사항

  • Go 버전 1.13 이상이 설치되어 있어야 합니다.

3.1.2.1. On Linux

  1. Helm 바이너리를 다운로드하여 경로에 추가합니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm
  2. 바이너리 파일을 실행 가능하게 합니다.

    # chmod +x /usr/local/bin/helm
  3. 설치된 버전을 확인합니다.

    $ helm version

    출력 예

    version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

3.1.2.2. Windows 7/8

  1. 최신 .exe 파일을 다운로드하여 기본 설정 디렉터리에 배치합니다.
  2. 시작을 마우스 오른쪽 버튼으로 클릭하고 제어판을 클릭합니다.
  3. 시스템 및 보안을 선택하고 시스템을 클릭합니다.
  4. 왼쪽 메뉴에서 고급 시스템 설정을 선택하고 아래에 있는 환경 변수를 클릭합니다.
  5. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
  6. 새로 생성을 클릭하고 필드에 .exe 파일이 있는 폴더의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

3.1.2.3. Windows 10

  1. 최신 .exe 파일을 다운로드하여 기본 설정 디렉터리에 배치합니다.
  2. 검색을 클릭하고 env 또는 environment를 입력합니다.
  3. 계정의 환경 변수 편집을 선택합니다.
  4. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
  5. 새로 생성을 클릭하고 필드에 exe 파일이 있는 디렉터리의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

3.1.2.4. MacOS

  1. Helm 바이너리를 다운로드하여 경로에 추가합니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm
  2. 바이너리 파일을 실행 가능하게 합니다.

    # chmod +x /usr/local/bin/helm
  3. 설치된 버전을 확인합니다.

    $ helm version

    출력 예

    version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

3.1.3. OpenShift Container Platform 클러스터에 Helm 차트 설치

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있고 로그인되어 있어야 합니다.
  • Helm이 설치되어 있어야 합니다.

절차

  1. 새 프로젝트를 생성합니다.

    $ oc new-project mysql
  2. 로컬 Helm 클라이언트에 Helm 차트 리포지터리를 추가합니다.

    $ helm repo add stable https://kubernetes-charts.storage.googleapis.com/

    출력 예

    "stable" has been added to your repositories

  3. 리포지터리를 업데이트합니다.

    $ helm repo update
  4. MySQL 차트 예를 설치합니다.

    $ helm install example-mysql stable/mysql
  5. 차트가 성공적으로 설치되었는지 확인합니다.

    $ helm list

    출력 예

    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    example-mysql mysql 1 2019-12-05 15:06:51.379134163 -0500 EST deployed mysql-1.5.0 5.7.27

3.1.4. OpenShift Container Platform에서 사용자 정의 Helm 차트 생성

절차

  1. 새 프로젝트를 생성합니다.

    $ oc new-project nodejs-ex-k
  2. OpenShift Container Platform 오브젝트가 포함된 Node.js 차트 예를 다운로드합니다.

    $ git clone https://github.com/redhat-developer/redhat-helm-charts
  3. 샘플 차트가 있는 디렉터리로 이동합니다.

    $ cd redhat-helm-charts/alpha/nodejs-ex-k/
  4. Chart.yaml 파일을 편집하고 차트에 대한 설명을 추가합니다.

    apiVersion: v2 1
    name: nodejs-ex-k 2
    description: A Helm chart for OpenShift 3
    icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
    1
    차트 API 버전. Helm 3 이상이 필요한 Helm 차트 v2여야 합니다.
    2
    차트 이름.
    3
    차트 설명.
    4
    아이콘으로 사용할 이미지의 URL.
  5. 차트 형식이 올바르게 지정되었는지 확인합니다.

    $ helm lint

    출력 예

    [INFO] Chart.yaml: icon is recommended
    
    1 chart(s) linted, 0 chart(s) failed

  6. 이전 디렉터리 수준으로 이동합니다.

    $ cd ..
  7. 차트를 설치합니다.

    $ helm install nodejs-chart nodejs-ex-k
  8. 차트가 성공적으로 설치되었는지 확인합니다.

    $ helm list

    출력 예

    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

3.2. 사용자 정의 Helm 차트 리포지터리 구성

개발자 카탈로그는 웹 콘솔의 개발자 관점으로 클러스터에서 사용할 수 있는 Helm 차트를 표시합니다. 기본적으로 Red Hat Helm 차트 리포지터리의 Helm 차트를 나열합니다. 차트 목록은 Red Hat Helm 인덱스 파일을 참조하십시오.

클러스터 관리자는 기본 리포지터리 외에도 여러 Helm 차트 리포지터리를 추가하여 해당 리포지터리의 Helm 차트를 개발자 카탈로그에 표시할 수 있습니다.

3.2.1. 사용자 정의 Helm 차트 리포지터리 추가

클러스터 관리자는 사용자 정의 Helm 차트 리포지터리를 클러스터에 추가하여 개발자 카탈로그에서 해당 리포지터리의 Helm 차트에 대한 액세스를 활성화할 수 있습니다.

절차

  1. 새 Helm 차트 리포지터리를 추가하려면 클러스터에 Helm 차트 리포지터리 CR(사용자 정의 리소스)을 추가해야 합니다.

    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: <name>
    spec:
     # optional name that might be used by console
     # name: <chart-display-name>
      connectionConfig:
        url: <helm-chart-repository-url>

    예를 들어 Azure 샘플 차트 리포지터리를 추가하려면 다음을 실행합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: azure-sample-repo
    spec:
      name: azure-sample-repo
      connectionConfig:
        url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
    EOF
  2. 웹 콘솔에서 개발자 카탈로그로 이동하여 차트 리포지터리의 Helm 차트가 표시되는지 확인합니다.

    예를 들어 차트 리포지터리 필터를 사용하여 리포지터리의 Helm 차트를 검색합니다.

    그림 3.1. 차트 리포지터리 필터

    odc helm 차트 리포지터리 필터
    참고

    클러스터 관리자가 모든 차트 리포지터리를 제거하는 경우 +추가 보기, 개발자 카탈로그 및 왼쪽 탐색 패널에서 Helm 옵션을 볼 수 없습니다.

3.2.2. 인증 정보 및 CA 인증서를 생성하여 Helm 차트 리포지터리 추가

일부 Helm 차트 리포지터리는 연결하려면 인증 정보 및 사용자 정의 CA(인증 기관) 인증서가 필요합니다. 웹 콘솔 및 CLI를 사용하여 인증 정보 및 인증서를 추가할 수 있습니다.

절차

CLI를 사용하여 인증 정보 및 인증서를 구성한 후 Helm 차트 리포지터리를 추가하려면 다음을 실행합니다.

  1. openshift-config 네임스페이스에서 PEM 인코딩 형식의 사용자 정의 CA 인증서로 ConfigMap 오브젝트를 생성한 후 구성 맵 내의 ca-bundle.crt 키에 저장합니다.

    $ oc create configmap helm-ca-cert \
    --from-file=ca-bundle.crt=/path/to/certs/ca.crt \
    -n openshift-config
  2. openshift-config 네임스페이스에서 Secret 오브젝트를 생성하여 클라이언트 TLS 구성을 추가합니다.

    $ oc create secret generic helm-tls-configs \
    --from-file=tls.crt=/path/to/certs/client.crt \
    --from-file=tls.key=/path/to/certs//client.key \
    -n openshift-config

    클라이언트 인증서 및 키는 PEM 인코딩 형식이어야 하며 각각 tls.crttls.key 키에 저장되어야 합니다.

  3. 다음과 같이 Helm 리포지터리를 추가합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: <helm-repository>
    spec:
      name: <helm-repository>
      connectionConfig:
        url: <URL for the Helm repository>
        tlsConfig:
            name: helm-tls-configs
        ca:
    	name: helm-ca-cert
    EOF

    ConfigMapSecrettlsConfigca 필드를 사용하는 HelmChartRepository CR에서 사용됩니다. 이러한 인증서는 Helm 리포지터리 URL에 연결하는 데 사용됩니다.

  4. 기본적으로 모든 인증된 사용자는 모든 구성된 차트에 액세스할 수 있습니다. 하지만 인증서가 필요한 차트 리포지터리의 경우 다음과 같이 사용자에게 openshift-config 네임스페이스의 helm-ca-cert 구성 맵과 helm-tls-configs 시크릿에 대한 읽기 액세스 권한을 제공해야 합니다.

    $ cat <<EOF | kubectl apply -f -
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: openshift-config
      name: helm-chartrepos-tls-conf-viewer
    rules:
    - apiGroups: [""]
      resources: ["configmaps"]
      resourceNames: ["helm-ca-cert"]
      verbs: ["get"]
    - apiGroups: [""]
      resources: ["secrets"]
      resourceNames: ["helm-tls-configs"]
      verbs: ["get"]
    ---
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: openshift-config
      name: helm-chartrepos-tls-conf-viewer
    subjects:
      - kind: Group
        apiGroup: rbac.authorization.k8s.io
        name: 'system:authenticated'
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: helm-chartrepos-tls-conf-viewer
    EOF

3.2.3. 인증 수준에 따라 Helm 차트 필터링

개발자 카탈로그의 인증 수준에 따라 Helm 차트를 필터링할 수 있습니다.

프로세스

  1. 개발자 관점에서 +추가 보기로 이동하여 프로젝트를 선택합니다.
  2. 개발자 카탈로그 타일에서 Helm 차트 옵션을 선택하여 개발자 카탈로그의 모든 Helm 차트를 확인합니다.
  3. 필요한 차트를 필터링하려면 Helm 차트 목록 왼쪽에 있는 필터를 사용합니다.

    • 차트 리포지토리 필터를 사용하여 Red Hat 인증 차트 또는 OpenShift Helm 차트에서 제공하는 차트를 필터링합니다.
    • Source 필터를 사용하여 파트너,커뮤니티 또는 Red Hat에서 제공한 차트를 필터링합니다. 인증 차트는 ( odc verified icon ) 아이콘으로 표시됩니다.
참고

공급업체 유형이 하나뿐이면 Source 필터가 표시되지 않습니다.

이제 필요한 차트를 선택하고 설치할 수 있습니다.

3.3. Helm 차트 리포지터리 비활성화

클러스터 관리자는 클러스터에서 Helm 차트 리포지터리를 제거하여 더 이상 개발자 카탈로그에 표시되지 않도록 할 수 있습니다.

3.3.1. 클러스터에서 Helm 차트 리포지터리 비활성화

HelmChartRepository 사용자 정의 리소스에서 disabled 속성을 추가하여 카탈로그에서 Helm 차트를 비활성화할 수 있습니다.

절차

  • CLI를 사용하여 Helm 차트 리포지터리를 비활성화하려면 disabled: true 플래그를 사용자 정의 리소스에 추가합니다. 예를 들어 Azure 샘플 차트 리포지터리를 제거하려면 다음을 실행합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: azure-sample-repo
    spec:
      connectionConfig:
       url:https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
      disabled: true
    EOF
  • 웹 콘솔을 사용하여 최근에 추가된 Helm 차트 리포지터리를 비활성화하려면 다음을 수행합니다.

    1. 사용자 정의 리소스 정의로 이동하여 HelmChartRepository 사용자 정의 리소스를 검색합니다.
    2. 인스턴스로 이동하여 비활성화할 저장소를 찾아 이름을 클릭합니다.
    3. YAML 탭으로 이동하여 spec 섹션에 disabled: true 플래그를 추가하고 저장을 클릭합니다.

      spec:
        connectionConfig:
          url: <url-of-the-repositoru-to-be-disabled>
        disabled: true

      이제 리포지터리가 비활성화되어 카탈로그에 표시되지 않습니다.

4장. OpenShift Serverless와 함께 사용할 Knative CLI(kn)

Knative kn CLI를 사용하면 OpenShift Container Platform의 Knative 구성 요소와 간단한 상호 작용을 할 수 있습니다.

OpenShift Serverless를 설치하여 OpenShift Container Platform에서 Knative를 활성화할 수 있습니다. 자세한 내용은 OpenShift Serverless 시작하기를 참조하십시오.

참고

OpenShift Serverless는 kn CLI를 사용하여 설치할 수 없습니다. 클러스터 관리자는 OpenShift Container Platform의 Serverless 애플리케이션 문서에 설명된 대로 OpenShift Serverless Operator를 설치하고 Knative 구성 요소를 설정해야 합니다.

4.1. 주요 기능

kn CLI는 서버리스 컴퓨팅 작업을 간소하고 간결하게 만들도록 설계되었습니다. kn CLI의 주요 기능은 다음과 같습니다.

  • 명령줄에서 서버리스 애플리케이션을 배포합니다.
  • 서비스, 개정, 트래픽 분할 등 Knative Serving 기능을 관리합니다.
  • 이벤트 소스 및 트리거와 같은 Knative 이벤트 구성 요소를 생성하고 관리합니다.
  • 기존 Kubernetes 애플리케이션 및 Knative 서비스를 연결하는 싱크 바인딩을 생성합니다.
  • kubectl CLI와 유사한 유연한 플러그인 아키텍처를 사용하여 kn CLI를 확장합니다.
  • Knative 서비스에 대한 자동 스케일링 매개변수를 구성합니다.
  • 작업 결과 대기나 사용자 정의 롤아웃 및 롤백 전략 배포와 같은 사용법을 스크립팅합니다.

4.2. Knative CLI 설치

Knative CLI 설치를 참조하십시오.

5장. Pipelines CLI(tkn)

5.1. tkn 설치

tkn CLI를 사용하여 터미널에서 Red Hat OpenShift Pipelines를 관리합니다. 다음 섹션에서는 다양한 플랫폼에 tkn을 설치하는 방법을 설명합니다.

오른쪽 상단에 있는 ? 아이콘을 클릭하고 명령줄 툴을 선택하여 OpenShift Container Platform 웹 콘솔의 최신 바이너리 URL을 찾을 수도 있습니다.

5.1.1. Linux에서 Red Hat OpenShift Pipelines CLI(tkn) 설치

Linux 배포판의 경우 tar.gz 아카이브로 직접 CLI를 다운로드할 수 있습니다.

절차

  1. 관련 CLI를 다운로드합니다.

  2. 아카이브의 압축을 풉니다.

    $ tar xvzf <file>
  3. tkn 바이너리를 PATH에 있는 디렉터리에 배치합니다.
  4. PATH를 확인하려면 다음을 실행합니다.

    $ echo $PATH

5.1.2. RPM을 사용하여 Linux에서 Red Hat OpenShift Pipelines CLI(tkn) 설치

RHEL(Red Hat Enterprise Linux) 버전 8의 경우 Red Hat OpenShift Pipelines CLI(tkn)를 RPM으로 설치할 수 있습니다.

사전 요구 사항

  • Red Hat 계정에 활성 OpenShift Container Platform 서브스크립션이 있어야 합니다.
  • 로컬 시스템에 root 또는 sudo 권한이 있어야 합니다.

절차

  1. Red Hat Subscription Manager에 등록합니다.

    # subscription-manager register
  2. 최신 서브스크립션 데이터를 가져옵니다.

    # subscription-manager refresh
  3. 사용 가능한 서브스크립션을 나열하십시오.

    # subscription-manager list --available --matches '*pipelines*'
  4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이 서브스크립션을 등록된 시스템에 연결합니다.

    # subscription-manager attach --pool=<pool_id>
  5. Red Hat OpenShift Pipelines에 필요한 리포지터리를 활성화합니다.

    • Linux (x86_64, amd64)

      # subscription-manager repos --enable="pipelines-1.4-for-rhel-8-x86_64-rpms"
    • Linux on IBM Z 및 LinuxONE(s390x)

      # subscription-manager repos --enable="pipelines-1.4-for-rhel-8-s390x-rpms"
    • Linux on IBM Power Systems(ppc64le)

      # subscription-manager repos --enable="pipelines-1.4-for-rhel-8-ppc64le-rpms"
  6. openshift-pipelines-client 패키지를 설치합니다.

    # yum install openshift-pipelines-client

CLI를 설치한 후 tkn 명령을 사용할 수 있습니다.

$ tkn version

5.1.3. Windows에서 Red Hat OpenShift Pipelines CLI(tkn) 설치

Windows에서는 tkn CLI가 zip 아카이브로 제공됩니다.

절차

  1. CLI를 다운로드합니다.
  2. ZIP 프로그램으로 아카이브의 압축을 풉니다.
  3. tkn.exe 파일의 위치를 PATH 환경 변수에 추가합니다.
  4. PATH를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.

    C:\> path

5.1.4. macOS에서 Red Hat OpenShift Pipelines CLI(tkn) 설치

macOS에서는 tkn CLI가 tar.gz 아카이브로 제공됩니다.

절차

  1. CLI를 다운로드합니다.
  2. 아카이브의 압축을 해제하고 압축을 풉니다.
  3. tkn 바이너리를 PATH에 있는 디렉터리로 이동합니다.
  4. PATH를 확인하려면 터미널 창을 열고 다음을 실행합니다.

    $ echo $PATH

5.2. OpenShift Pipelines tkn CLI 구성

탭 완료가 활성화되도록 Red Hat OpenShift Pipelines tkn CLI를 구성합니다.

5.2.1. 탭 완료 활성화

tkn CLI를 설치한 후에는 탭 완료를 활성화하여 자동으로 tkn 명령을 완료하거나 탭을 누를 때 옵션을 제안하도록 할 수 있습니다.

사전 요구 사항

  • tkn CLI 툴이 설치되어 있어야 합니다.
  • 로컬 시스템에 bash-completion이 설치되어 있어야 합니다.

절차

Bash 탭 완료를 활성화하는 절차는 다음과 같습니다.

  1. Bash 완료 코드를 파일에 저장합니다.

    $ tkn completion bash > tkn_bash_completion
  2. 파일을 /etc/bash_completion.d/에 복사합니다.

    $ sudo cp tkn_bash_completion /etc/bash_completion.d/

    또는 파일을 로컬 디렉터리에 저장하여 .bashrc 파일에서 소싱할 수도 있습니다.

새 터미널을 열면 탭 완료가 활성화됩니다.

5.3. OpenShift Pipelines tkn 참조

이 섹션에는 기본 tkn CLI 명령이 나열됩니다.

5.3.1. 기본 구문

tkn [command or options] [arguments…​]

5.3.2. 글로벌 옵션

--help, -h

5.3.3. 유틸리티 명령

5.3.3.1. tkn

tkn CLI의 상위 명령입니다.

예: 모든 옵션 표시

$ tkn

5.3.3.2. completion [shell]

대화형 완료를 제공하려면 평가해야 하는 쉘 완료 코드를 출력합니다. 지원되는 쉘은 bashzsh입니다.

예: bash 쉘 완료 코드

$ tkn completion bash

5.3.3.3. version

tkn CLI의 버전 정보를 출력합니다.

예: tkn 버전 확인

$ tkn version

5.3.4. 파이프라인 관리 명령

5.3.4.1. pipeline

파이프라인을 관리합니다.

예: 도움말 표시

$ tkn pipeline --help

5.3.4.2. pipeline delete

파이프라인을 삭제합니다.

예: 네임스페이스에서 mypipeline 파이프라인 삭제

$ tkn pipeline delete mypipeline -n myspace

5.3.4.3. pipeline describe

파이프라인을 설명합니다.

예: mypipeline 파이프라인 설명

$ tkn pipeline describe mypipeline

5.3.4.4. pipeline list

파이프라인을 나열합니다.

예: 파이프라인 목록 표시

$ tkn pipeline list

5.3.4.5. pipeline logs

특정 파이프라인의 파이프라인 로그를 표시합니다.

예: mypipeline 파이프라인의 실시간 로그 스트리밍

$ tkn pipeline logs -f mypipeline

5.3.4.6. pipeline start

파이프라인을 시작합니다.

예: mypipeline 파이프라인 시작

$ tkn pipeline start mypipeline

5.3.5. PipelineRun 명령

5.3.5.1. pipelinerun

PipelineRun을 관리합니다.

예: 도움말 표시

$ tkn pipelinerun -h

5.3.5.2. pipelinerun cancel

PipelineRun을 취소합니다.

예: 네임스페이스에서 mypipelinerun PipelineRun 취소

$ tkn pipelinerun cancel mypipelinerun -n myspace

5.3.5.3. pipelinerun delete

PipelineRun을 삭제합니다.

예: 네임스페이스에서 PipelineRun 삭제

$ tkn pipelinerun delete mypipelinerun1 mypipelinerun2 -n myspace

5.3.5.4. pipelinerun describe

PipelineRun을 설명합니다.

예: 네임스페이스에서 mypipelinerun PipelineRun 설명

$ tkn pipelinerun describe mypipelinerun -n myspace

5.3.5.5. pipelinerun list

PipelineRun을 나열합니다.

예: 네임스페이스에서 PipelineRun 목록 표시

$ tkn pipelinerun list -n myspace

5.3.5.6. pipelinerun logs

PipelineRun 로그를 표시합니다.

예: 네임스페이스의 모든 작업 및 단계와 함께 mypipelinerun PipelineRun 로그 표시

$ tkn pipelinerun logs mypipelinerun -a -n myspace

5.3.6. 작업 관리 명령

5.3.6.1. task

작업을 관리합니다.

예: 도움말 표시

$ tkn task -h

5.3.6.2. task delete

작업을 삭제합니다.

예: 네임스페이스에서 mytask1mytask2 작업 삭제

$ tkn task delete mytask1 mytask2 -n myspace

5.3.6.3. task describe

작업을 설명합니다.

예: 네임스페이스의 mytask 작업 설명

$ tkn task describe mytask -n myspace

5.3.6.4. task list

작업을 나열합니다.

예: 네임스페이스의 모든 작업 나열

$ tkn task list -n myspace

5.3.6.5. task logs

작업 로그를 표시합니다.

예: mytask 작업의 mytaskrun TaskRun 로그 표시

$ tkn task logs mytask mytaskrun -n myspace

5.3.6.6. task start

작업을 시작합니다.

예: 네임스페이스에서 mytask 작업 시작

$ tkn task start mytask -s <ServiceAccountName> -n myspace

5.3.7. TaskRun 명령

5.3.7.1. taskrun

TaskRun을 관리합니다.

예: 도움말 표시

$ tkn taskrun -h

5.3.7.2. taskrun cancel

TaskRun을 취소합니다.

예: 네임스페이스에서 mytaskrun TaskRun 취소

$ tkn taskrun cancel mytaskrun -n myspace

5.3.7.3. taskrun delete

TaskRun을 삭제합니다.

예: 네임스페이스에서 mytaskrun1mytaskrun2 TaskRun 삭제

$ tkn taskrun delete mytaskrun1 mytaskrun2 -n myspace

5.3.7.4. taskrun describe

TaskRun을 설명합니다.

예: 네임스페이스에서 mytaskrun TaskRun 설명

$ tkn taskrun describe mytaskrun -n myspace

5.3.7.5. taskrun list

TaskRun을 나열합니다.

예: 네임스페이스의 모든 TaskRun 나열

$ tkn taskrun list -n myspace

5.3.7.6. taskrun logs

TaskRun 로그를 표시합니다.

예: 네임스페이스의 mytaskrun TaskRun 실시간 로그 표시

$ tkn taskrun logs -f mytaskrun -n myspace

5.3.8. 상태 관리 명령

5.3.8.1. condition

상태를 관리합니다.

예: 도움말 표시

$ tkn condition --help

5.3.8.2. condition delete

상태를 삭제합니다.

예: 네임스페이스에서 mycondition1 상태 삭제

$ tkn condition delete mycondition1 -n myspace

5.3.8.3. condition describe

상태를 설명합니다.

예: 네임스페이스의 mycondition1 상태 설명

$ tkn condition describe mycondition1 -n myspace

5.3.8.4. condition list

상태를 나열합니다.

예: 네임스페이스의 상태 나열

$ tkn condition list -n myspace

5.3.9. 파이프라인 리소스 관리 명령

5.3.9.1. resource

파이프라인 리소스를 관리합니다.

예: 도움말 표시

$ tkn resource -h

5.3.9.2. resource create

파이프라인 리소스를 생성합니다.

예: 네임스페이스에서 파이프라인 리소스 생성

$ tkn resource create -n myspace

이 명령은 리소스 이름, 리소스 유형, 리소스 유형 기반 값 입력을 요청하는 대화형 명령입니다.

5.3.9.3. resource delete

파이프라인 리소스를 삭제합니다.

예: 네임스페이스에서 myresource 파이프라인 리소스 삭제

$ tkn resource delete myresource -n myspace

5.3.9.4. resource describe

파이프라인 리소스를 설명합니다.

예: myresource 파이프라인 리소스 설명

$ tkn resource describe myresource -n myspace

5.3.9.5. resource list

파이프라인 리소스를 나열합니다.

예: 네임스페이스의 모든 파이프 라인 리소스 나열

$ tkn resource list -n myspace

5.3.10. ClusterTask 관리 명령

5.3.10.1. clustertask

ClusterTask를 관리합니다.

예: 도움말 표시

$ tkn clustertask --help

5.3.10.2. clustertask delete

클러스터의 ClusterTask 리소스를 삭제합니다.

예: mytask1mytask2 ClusterTask 삭제

$ tkn clustertask delete mytask1 mytask2

5.3.10.3. clustertask describe

ClusterTask를 설명합니다.

예: mytask ClusterTask 설명

$ tkn clustertask describe mytask1

5.3.10.4. clustertask list

ClusterTask를 나열합니다.

예: ClusterTask 나열

$ tkn clustertask list

5.3.10.5. clustertask start

ClusterTask를 시작합니다.

예: mytask ClusterTask 시작

$ tkn clustertask start mytask

5.3.11. 트리거 관리 명령

5.3.11.1. eventlistener

EventListener를 관리합니다.

예: 도움말 표시

$ tkn eventlistener -h

5.3.11.2. eventlistener delete

EventListener를 삭제합니다.

예: 네임스페이스에서 mylistener1mylistener2 EventListener 삭제

$ tkn eventlistener delete mylistener1 mylistener2 -n myspace

5.3.11.3. eventlistener describe

EventListener를 설명합니다.

예: 네임스페이스의 mylistener EventListener 설명

$ tkn eventlistener describe mylistener -n myspace

5.3.11.4. eventlistener list

EventListener를 나열합니다.

예: 네임스페이스의 모든 EventListener 나열

$ tkn eventlistener list -n myspace

5.3.11.5. 이벤트 리스너 로그

EventListener 로그 표시.

예: 네임스페이스에서 mylistener EventListener 로그 표시

$ tkn eventlistener logs mylistener -n myspace

5.3.11.6. triggerbinding

TriggerBinding을 관리합니다.

예: TriggerBinding 도움말 표시

$ tkn triggerbinding -h

5.3.11.7. triggerbinding delete

TriggerBinding을 삭제합니다.

예: 네임스페이스에서 mybinding1mybinding2 TriggerBinding 삭제

$ tkn triggerbinding delete mybinding1 mybinding2 -n myspace

5.3.11.8. triggerbinding describe

TriggerBinding을 설명합니다.

예: 네임스페이스의 mybinding TriggerBinding 설명

$ tkn triggerbinding describe mybinding -n myspace

5.3.11.9. triggerbinding list

TriggerBinding을 나열합니다.

예: 네임스페이스의 모든 TriggerBinding 나열

$ tkn triggerbinding list -n myspace

5.3.11.10. triggertemplate

TriggerTemplate을 관리합니다.

예: TriggerTemplate 도움말 표시

$ tkn triggertemplate -h

5.3.11.11. triggertemplate delete

TriggerTemplate을 삭제합니다.

예: 네임스페이스에서 mytemplate1mytemplate2 TriggerTemplate 삭제

$ tkn triggertemplate delete mytemplate1 mytemplate2 -n `myspace`

5.3.11.12. triggertemplate describe

TriggerTemplate을 설명합니다.

예: 네임스페이스의 mytemplate TriggerTemplate 설명

$ tkn triggertemplate describe mytemplate -n `myspace`

5.3.11.13. triggertemplate list

TriggerTemplate을 나열합니다.

예: 네임스페이스의 모든 TriggerTemplate 나열

$ tkn triggertemplate list -n myspace

5.3.11.14. clustertriggerbinding

Manage ClusterTriggerBindings.

예: ClusterTriggerBinding 도움말 표시

$ tkn clustertriggerbinding -h

5.3.11.15. clustertriggerbinding delete

ClusterTriggerBinding을 삭제합니다.

예: myclusterbinding1myclusterbinding2 ClusterTriggerBinding 삭제

$ tkn clustertriggerbinding delete myclusterbinding1 myclusterbinding2

5.3.11.16. clustertriggerbinding describe

ClusterTriggerBinding을 설명합니다.

예: myclusterbinding ClusterTriggerBinding 설명

$ tkn clustertriggerbinding describe myclusterbinding

5.3.11.17. clustertriggerbinding list

ClusterTriggerBinding을 나열합니다.

예: 모든 ClusterTriggerBinding 나열

$ tkn clustertriggerbinding list

5.3.12. 허브 상호 작용 명령

작업 및 파이프라인과 같은 리소스에 대해 Tekton Hub와 상호 작용합니다.

5.3.12.1. hub

hub와 상호 작용.

예: 도움말 표시

$ tkn hub -h

예: hub API 서버와 상호 작용

$ tkn hub --api-server https://api.hub.tekton.dev

참고

각 예에서는 해당 하위 명령 및 플래그를 가져오려면 tkn hub <command> --help를 실행합니다.

5.3.12.2. hub 다운 그레이드

설치된 리소스를 다운그레이드합니다.

예: mynamespace 네임스페이스의 mytask 작업을 이전 버전으로 다운그레이드

$ tkn hub downgrade task mytask --to version -n mynamespace

5.3.12.3. hub get

이름, 종류, 카탈로그, 버전으로 리소스 매니페스트를 가져옵니다.

예: tekton 카탈로그에서 특정 버전의 myresource 파이프라인 또는 작업에 대한 매니페스트 가져오기

$ tkn hub get [pipeline | task] myresource --from tekton --version version

5.3.12.4. hub 정보

이름, 종류, 카탈로그, 버전으로 리소스에 대한 정보를 표시합니다.

예: tekton 카탈로그에서 특정 버전의 mytask 작업에 대한 정보 표시

$ tkn hub info task mytask --from tekton --version version

5.3.12.5. hub 설치

종류, 이름 및 버전으로 카탈로그에서 리소스를 설치합니다.

예: mynamespace 네임스페이스의 tekton 카탈로그에서 특정 버전의 mytask 작업 설치

$ tkn hub install task mytask --from tekton --version version -n mynamespace

5.3.12.6. hub 재설치

리소스 종류와 이름을 사용하여 리소스를 다시 설치합니다.

예: mynamespace 네임스페이스의 tekton 카탈로그에서 특정 버전의 mytask 작업 재설치

$ tkn hub reinstall task mytask --from tekton --version version -n mynamespace

5.3.12.8. hub 업그레이드

설치된 리소스를 업그레이드합니다.

예: mynamespace 네임스페이스에 설치된 mytask 작업을 새 버전으로 업그레이드

$ tkn hub upgrade task mytask --to version -n mynamespace

6장. opm CLI

6.1. opm 정보

opm CLI 툴은 Operator 번들 형식과 함께 사용할 수 있도록 Operator 프레임워크에서 제공합니다. 이 툴을 사용하면 소프트웨어 리포지토리와 유사한 인덱스라는 번들 목록에서 Operator 카탈로그를 생성하고 유지 관리할 수 있습니다. 결과적으로 인덱스 이미지라는 컨테이너 이미지를 컨테이너 레지스트리에 저장한 다음 클러스터에 설치할 수 있습니다.

인덱스에는 컨테이너 이미지 실행 시 제공된 포함 API를 통해 쿼리할 수 있는 Operator 매니페스트 콘텐츠에 대한 포인터 데이터베이스가 포함되어 있습니다. OpenShift Container Platform에서 OLM(Operator Lifecycle Manager)은 CatalogSource 오브젝트에서 인덱스 이미지를 카탈로그로 참조할 수 있으며 주기적으로 이미지를 폴링하여 클러스터에 설치된 Operator를 자주 업데이트할 수 있습니다.

추가 리소스

6.2. opm 설치

Linux, macOS 또는 Windows 워크스테이션에 opm CLI 툴을 설치할 수 있습니다.

사전 요구 사항

  • Linux의 경우 다음 패키지를 제공해야 합니다.

    • podman 버전 1.9.3 이상(버전 2.0 이상 권장)
    • glibc 버전 2.28 이상

절차

  1. OpenShift 미러 사이트로 이동하여 운영 체제와 일치하는 최신 tarball 버전을 다운로드합니다.
  2. 아카이브의 압축을 풉니다.

    • Linux 또는 macOS의 경우:

      $ tar xvf <file>
    • Windows의 경우 ZIP 프로그램으로 아카이브의 압축을 풉니다.
  3. PATH에 있는 임의의 위치에 파일을 배치합니다.

    • Linux 또는 macOS의 경우:

      1. PATH를 확인합니다.

        $ echo $PATH
      2. 파일을 이동합니다. 예를 들면 다음과 같습니다.

        $ sudo mv ./opm /usr/local/bin/
    • Windows의 경우:

      1. PATH를 확인합니다.

        C:\> path
      2. 파일을 이동합니다.

        C:\> move opm.exe <directory>

검증

  • opm CLI를 설치한 후 사용할 수 있는지 확인합니다.

    $ opm version

    출력 예

    Version: version.Version{OpmVersion:"v1.15.4-2-g6183dbb3", GitCommit:"6183dbb3567397e759f25752011834f86f47a3ea", BuildDate:"2021-02-13T04:16:08Z", GoOs:"linux", GoArch:"amd64"}

6.3. 추가 리소스

  • 인덱스 이미지 생성, 업데이트 및 정리를 비롯한 opm 프로시저는 사용자 정의 카탈로그 관리를 참조하십시오.

7장. Operator SDK

7.1. Operator SDK CLI 설치

Operator SDK는 Operator 개발자가 Operator를 빌드, 테스트, 배포하는 데 사용할 수 있는 CLI(명령줄 인터페이스) 툴을 제공합니다. 워크스테이션에 Operator SDK CLI를 설치하여 자체 Operator 작성을 시작할 준비를 할 수 있습니다.

Operator SDK에 대한 자세한 내용은 Operator 개발에서 참조하십시오.

참고

OpenShift Container Platform 4.8 이상에서는 Operator SDK v1.8.0을 지원합니다.

7.1.1. Operator SDK CLI 설치

Linux에 OpenShift SDK CLI 툴을 설치할 수 있습니다.

사전 요구 사항

  • Go v1.16+
  • docker v17.03 이상, podman v1.9.3 이상 또는 buildah v1.7 이상

프로세스

  1. OpenShift 미러 사이트로 이동합니다.
  2. latest 디렉터리에서 최신 버전의 Linux용 tarball을 다운로드합니다.
  3. 아카이브의 압축을 풉니다.

    $ tar xvf operator-sdk-v1.8.0-ocp-linux-x86_64.tar.gz
  4. 파일을 실행 가능으로 설정합니다.

    $ chmod +x operator-sdk
  5. 추출된 operator-sdk 바이너리를 PATH에 있는 디렉터리로 이동합니다.

    작은 정보

    PATH를 확인하려면 다음을 실행합니다.

    $ echo $PATH
    $ sudo mv ./operator-sdk /usr/local/bin/operator-sdk

검증

  • Operator SDK CLI를 설치한 후 사용할 수 있는지 확인합니다.

    $ operator-sdk version

    출력 예

    operator-sdk version: "v1.8.0-ocp", ...

7.2. Operator SDK CLI 참조

Operator SDK CLI(명령줄 인터페이스)는 Operator를 더 쉽게 작성할 수 있도록 설계된 개발 키트입니다.

Operator SDK CLI 구문

$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]

Kubernetes 기반 클러스터(예: OpenShift Container Platform)에 대한 클러스터 관리자 액세스 권한이 있는 Operator 작성자는 Operator SDK CLI를 사용하여 Go, Ansible 또는 Helm을 기반으로 자체 Operator를 개발할 수 있습니다. Kubebuilder는 Go 기반 Operator의 스캐폴딩 솔루션으로 Operator SDK에 포함되어 있습니다. 즉, 기존 Kubebuilder 프로젝트를 그대로 Operator SDK와 함께 사용할 수 있으며 계속 작업할 수 있습니다.

Operator SDK에 대한 자세한 내용은 Operator 개발에서 참조하십시오.

7.2.1. bundle

operator-sdk bundle 명령은 Operator 번들 메타데이터를 관리합니다.

7.2.1.1. 검증

bundle validate 하위 명령은 Operator 번들을 검증합니다.

표 7.1. bundle validate 플래그

플래그Description

-h, --help

bundle validate 하위 명령에 대한 도움말 출력입니다.

--index-builder(문자열)

번들 이미지를 가져오고 압축 해제하는 툴입니다. 번들 이미지를 검증할 때만 사용됩니다. 사용 가능한 옵션은 docker(기본값), podman 또는 none입니다.

--list-optional

사용 가능한 선택적 검증기를 모두 나열합니다. 이 플래그를 설정하면 검증기가 실행되지 않습니다.

--select-optional(문자열)

실행할 선택적 검증기를 선택하는 라벨 선택기입니다. --list-optional 플래그를 사용하여 실행하는 경우 사용 가능한 선택적 검증기를 나열합니다.

7.2.2. cleanup

operator-sdk cleanup 명령은 run 명령을 사용하여 배포한 Operator용으로 생성된 리소스를 삭제하고 제거합니다.

표 7.2. cleanup 플래그

플래그Description

-h, --help

run bundle 하위 명령에 대한 도움말 출력입니다.

--kubeconfig(문자열)

CLI 요청에 사용할 kubeconfig 파일 경로입니다.

-n, --namespace(문자열)

이 플래그가 있는 경우 CLI 요청을 실행할 네임스페이스입니다.

--timeout <duration>

실패 전 명령이 완료될 때까지 대기하는 시간입니다. 기본값은 2m0s입니다.

7.2.3. 완료

operator-sdk completion 명령은 CLI 명령을 더 신속하고 쉽게 실행할 수 있도록 쉘 완료를 생성합니다.

표 7.3. completion 하위 명령

하위 명령Description

bash

bash 완료를 생성합니다.

zsh

zsh 완료를 생성합니다.

표 7.4. completion 플래그

플래그Description

-h, --help

사용법 도움말 출력입니다.

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

$ operator-sdk completion bash

출력 예

# bash completion for operator-sdk                         -*- shell-script -*-
...
# ex: ts=4 sw=4 et filetype=sh

7.2.4. create

operator-sdk create 명령은 Kubernetes API를 생성하거나 스캐폴드하는 데 사용됩니다.

7.2.4.1. api

create api 하위 명령은 Kubernetes API를 스캐폴드합니다. 하위 명령은 init 명령을 사용하여 초기화한 프로젝트에서 실행해야 합니다.

표 7.5. create api 플래그

플래그Description

-h, --help

run bundle 하위 명령에 대한 도움말 출력입니다.

7.2.5. generate

operator-sdk generate 명령은 특정 생성기를 호출하여 코드 또는 매니페스트를 생성합니다.

7.2.5.1. 번들

generate bundle 하위 명령은 Operator 프로젝트에 대해 일련의 번들 매니페스트, 메타데이터, bundle.Dockerfile 파일을 생성합니다.

참고

일반적으로 generate kustomize manifests 하위 명령을 먼저 실행하여 generate bundle 하위 명령에 사용되는 입력 Kustomize 베이스를 생성합니다. 그러나 초기화된 프로젝트에서 make bundle 명령을 사용하여 이러한 명령을 순서대로 실행하도록 자동화할 수 있습니다.

표 7.6. generate bundle 플래그

플래그Description

--channels(문자열)

번들이 속한 채널의 쉼표로 구분된 목록입니다. 기본값은 alpha입니다.

--crds-dir(문자열)

CustomResoureDefinition 매니페스트의 루트 디렉터리입니다.

--default-channel(문자열)

번들의 기본 채널입니다.

--deploy-dir(문자열)

배포 및 RBAC와 같은 Operator 매니페스트용 루트 디렉터리입니다. 이 디렉터리는 --input-dir 플래그로 전달되는 디렉터리와 다릅니다.

-h, --help

generate bundle에 대한 도움말입니다.

--input-dir(문자열)

기존 번들을 읽을 디렉터리입니다. 이 디렉터리는 번들 manifests 디렉터리의 상위이며 --deploy-dir 디렉터리와 다릅니다.

--kustomize-dir(문자열)

번들 매니페스트용 Kustomize 베이스 및 kustomization.yaml 파일이 포함된 디렉터리입니다. 기본 경로는 config/manifests입니다.

--manifests

번들 매니페스트를 생성합니다.

--metadata

번들 메타데이터 및 Dockerfile을 생성합니다.

--output-dir(문자열)

번들을 작성할 디렉터리입니다.

--overwrite

번들 메타데이터 및 Dockerfile이 있는 경우 덮어씁니다. 기본값은 true입니다.

--package(문자열)

번들의 패키지 이름입니다.

-q, --quiet

자동 모드로 실행됩니다.

--stdout

번들 매니페스트를 표준 출력에 작성합니다.

--version(문자열)

생성된 번들에 있는 Operator의 의미 체계 버전입니다. 새 번들을 생성하거나 Operator를 업그레이드하는 경우에만 설정됩니다.

추가 리소스

7.2.5.2. kustomize

generate kustomize 하위 명령에는 Operator에 대한 Kustomize 데이터를 생성하는 하위 명령이 포함되어 있습니다.

7.2.5.2.1. 매니페스트

generate kustomize manifests 하위 명령은 다른 Operator SDK 명령에서 번들 매니페스트를 빌드하는 데 사용하는 Kustomize 베이스 및 kustomization.yaml 파일을 config/manifests 디렉터리에 생성하거나 다시 생성합니다. 베이스가 존재하지 않거나 --interactive=false 플래그를 설정하지 않은 경우 이 명령은 기본적으로 매니페스트 베이스의 중요한 구성 요소인 UI 메타데이터를 대화형으로 요청합니다.

표 7.7. generate kustomize manifests 플래그

플래그Description

--apis-dir(문자열)

API 유형 정의를 위한 루트 디렉터리입니다.

-h, --help

generate kustomize manifests에 대한 도움말입니다.

--input-dir(문자열)

기존 Kustomize 파일이 있는 디렉터리입니다.

--interactive

false로 설정하면 Kustomize 베이스가 없는 경우 사용자 정의 메타데이터를 수락하도록 대화형 명령 프롬프트가 표시됩니다.

--output-dir(문자열)

Kustomize 파일을 작성할 디렉터리입니다.

--package(문자열)

패키지 이름입니다.

-q, --quiet

자동 모드로 실행됩니다.

7.2.6. init

operator-sdk init 명령은 Operator 프로젝트를 초기화하고 지정된 플러그인의 기본 프로젝트 디렉터리 레이아웃을 생성하거나 스캐폴드합니다.

이 명령은 다음 파일을 작성합니다.

  • 상용구 라이센스 파일
  • 도메인 및 리포지토리가 있는 PROJECT 파일
  • 프로젝트를 빌드할 Makefile
  • 프로젝트 종속 항목이 있는 go.mod 파일
  • 매니페스트를 사용자 정의하는 kustomization.yaml 파일
  • 관리자 매니페스트용 이미지를 사용자 정의하는 패치 파일
  • Prometheus 지표를 활성화하는 패치 파일
  • 실행할 main.go 파일

표 7.8. init 플래그

플래그Description

--help, -h

init 명령에 대한 도움말 출력입니다.

--plugins(문자열)

프로젝트를 초기화할 플러그인의 이름 및 버전(선택 사항)입니다. 사용 가능한 플러그인은 ansible.sdk.operatorframework.io/v1, go.kubebuilder.io/v2, go.kubebuilder.io/v3, helm.sdk.operatorframework.io/v1입니다.

--project-version

프로젝트 버전입니다. 사용 가능한 값은 2 및 기본값인 3-alpha 입니다.

7.2.7. run

operator-sdk run 명령은 다양한 환경에서 Operator를 시작할 수 있는 옵션을 제공합니다.

7.2.7.1. 번들

run bundle 하위 명령은 OLM(Operator Lifecycle Manager)을 사용하여 번들 형식으로 Operator를 배포합니다.

표 7.9. run bundle 플래그

플래그Description

--index-image(문자열)

번들을 삽입할 인덱스 이미지입니다. 기본 이미지는 quay.io/operator-framework/upstream-opm-builder:latest입니다.

--install-mode <install_mode_value>

Operator CSV(클러스터 서비스 버전)에서 지원되는 설치 모드(예: AllNamespaces 또는 SingleNamespace)입니다.

--timeout <duration>

설치 제한 시간입니다. 기본값은 2m0s입니다.

--kubeconfig(문자열)

CLI 요청에 사용할 kubeconfig 파일 경로입니다.

-n, --namespace(문자열)

이 플래그가 있는 경우 CLI 요청을 실행할 네임스페이스입니다.

-h, --help

run bundle 하위 명령에 대한 도움말 출력입니다.

추가 리소스

7.2.7.2. bundle-upgrade

run bundle-upgrade 하위 명령은 이전에 OLM(Operator Lifecycle Manager)을 사용하여 번들 형식으로 설치한 Operator를 업그레이드합니다.

표 7.10. run bundle-upgrade 플래그

플래그Description

--timeout <duration>

업그레이드 제한 시간입니다. 기본값은 2m0s입니다.

--kubeconfig(문자열)

CLI 요청에 사용할 kubeconfig 파일 경로입니다.

-n, --namespace(문자열)

이 플래그가 있는 경우 CLI 요청을 실행할 네임스페이스입니다.

-h, --help

run bundle 하위 명령에 대한 도움말 출력입니다.

7.2.8. scorecard

operator-sdk scorecard 명령은 스코어 카드 툴을 실행하여 Operator 번들을 검증하고 개선을 위해 제안 사항을 제공합니다. 이 명령은 하나의 인수를 사용하며, 인수는 번들 이미지이거나 매니페스트 및 메타데이터가 포함된 디렉터리입니다. 인수에 이미지 태그가 있으면 이미지가 원격으로 존재해야 합니다.

표 7.11. scorecard 플래그

플래그Description

-c, --config(문자열)

스코어 카드 구성 파일 경로입니다. 기본 경로는 bundle/tests/scorecard/config.yaml입니다.

-h, --help

scorecard 명령에 대한 도움말 출력입니다.

--kubeconfig(문자열)

kubeconfig 파일 경로입니다.

-L, --list

실행할 수 있는 테스트를 나열합니다.

-n, --namespace(문자열)

테스트 이미지를 실행할 네임스페이스입니다.

-o, --output(문자열)

결과 출력 형식입니다. 사용 가능한 값은 text(기본값) 및 json입니다.

-l, --selector(문자열)

실행할 테스트를 결정하는 라벨 선택기입니다.

-s, --service-account(문자열)

테스트에 사용할 서비스 계정입니다. 기본값은 default입니다.

-x, --skip-cleanup

테스트가 실행된 후 리소스 정리를 비활성화합니다.

-w, --wait-time <duration>

테스트가 완료될 때까지 대기할 시간(초)입니다(예: 35s). 기본값은 30s입니다.

법적 공지

Copyright © 2021 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.