CLI 툴
OpenShift Container Platform 명령줄 툴 사용 방법 알아보기
초록
1장. OpenShift Container Platform CLI 툴 개요
사용자는 다음과 같은 OpenShift Container Platform에서 작업하는 동안 다양한 작업을 수행합니다.
- 클러스터 관리
- 애플리케이션 구축, 배포 및 관리
- 배포 프로세스 관리
- Operator 개발
- Operator 카탈로그 생성 및 유지 관리
OpenShift Container Platform은 사용자가 터미널에서 다양한 관리 및 개발 작업을 수행할 수 있도록 하여 이러한 작업을 간소화하는 CLI(명령줄 인터페이스) 툴 세트를 제공합니다. 이러한 툴을 사용하면 간단한 명령을 사용하여 애플리케이션을 관리할 수 있을 뿐 아니라 시스템의 각 구성 요소와 상호 작용할 수 있습니다.
1.1. CLI 툴 목록
OpenShift Container Platform에서는 다음 CLI 툴 세트를 사용할 수 있습니다.
- OpenShift CLI (oc): OpenShift Container Platform 사용자가 가장 일반적으로 사용하는 CLI 툴입니다. 클러스터 관리자와 개발자가 터미널을 사용하여 OpenShift Container Platform에서 포괄적인 작업을 수행할 수 있습니다. 웹 콘솔과 달리 사용자는 명령 스크립트를 사용하여 프로젝트 소스 코드와 직접 작업할 수 있습니다.
-
개발자 CLI (odo):
odo
CLI 툴을 사용하면 개발자가 복잡한 Kubernetes 및 OpenShift Container Platform 개념을 추상화하여 OpenShift Container Platform에서 애플리케이션을 생성하고 유지 관리하는 기본 목표에 집중할 수 있습니다. 개발자가 클러스터를 관리할 필요 없이 터미널에서 클러스터에서 애플리케이션을 작성, 빌드 및 디버깅할 수 있습니다. - Helm CLI: Helm은 Helm 차트로 패키지된 애플리케이션을 정의, 설치 및 업그레이드할 수 있는 Kubernetes 애플리케이션의 패키지 관리자입니다. Helm CLI를 사용하면 터미널에서 간단한 명령을 사용하여 사용자가 OpenShift Container Platform 클러스터에 애플리케이션 및 서비스를 배포할 수 있습니다.
-
Knative CLI(kn): Knative(
kn
) CLI 툴은 Knative Serving 및 Eventing과 같은 OpenShift Serverless 구성 요소와 상호 작용하는 데 사용할 수 있는 간단하고 직관적인 터미널 명령을 제공합니다. -
Pipeline CLI(tkn): OpenShift Pipelines는 OpenShift Container Platform의 CI/CD(지속적 통합 및 연속 제공) 솔루션으로, 내부적으로 Tekton을 사용합니다.
tkn
CLI 툴은 터미널을 사용하여 OpenShift Pipelines와 상호 작용할 수 있는 간단하고 직관적인 명령을 제공합니다. -
opm CLI:
opm
CLI 툴을 사용하면 Operator 개발자와 클러스터 관리자가 터미널에서 Operator 카탈로그를 생성하고 유지 관리할 수 있습니다.
2장. OpenShift CLI(oc)
2.1. OpenShift CLI 시작하기
2.1.1. OpenShift CLI 정보
OpenShift CLI(명령줄 인터페이스) 즉, oc
명령을 사용하면 터미널에서 애플리케이션을 생성하고 OpenShift Container Platform 프로젝트를 관리할 수 있습니다. OpenShift CLI를 사용하기에 적합한 경우는 다음과 같습니다.
- 직접 프로젝트 소스 코드로 작업하는 경우
- OpenShift Container Platform 작업 스크립트를 작성하는 경우
- 대역폭 리소스가 제한되고 웹 콘솔을 사용할 수 없는 상태에서 프로젝트를 관리하는 경우
2.1.2. OpenShift CLI 설치
OpenShift CLI(oc
)는 바이너리를 다운로드하거나 RPM을 사용하여 설치할 수 있습니다.
2.1.2.1. 바이너리를 다운로드하여 OpenShift CLI 설치
명령줄 인터페이스를 사용하여 OpenShift Container Platform과 상호 작용하기 위해 OpenShift CLI(oc
)를 설치할 수 있습니다. Linux, Windows 또는 macOS에 oc
를 설치할 수 있습니다.
이전 버전의 oc
를 설치한 경우, OpenShift Container Platform 4.6의 모든 명령을 완료하는 데 해당 버전을 사용할 수 없습니다. 새 버전의 oc
를 다운로드하여 설치합니다.
2.1.2.1.1. Linux에서 OpenShift CLI 설치
다음 절차를 사용하여 Linux에서 OpenShift CLI(oc
) 바이너리를 설치할 수 있습니다.
프로세스
- Red Hat 고객 포털에서 OpenShift Container Platform 다운로드 페이지로 이동합니다.
- 버전 드롭다운 메뉴에서 적절한 버전을 선택합니다.
- OpenShift v4.6 Linux Client 항목 옆에 있는 Download Now (지금 다운로드)를 클릭하고 파일을 저장합니다.
아카이브의 압축을 풉니다.
$ tar xvzf <file>
oc
바이너리를PATH
에 있는 디렉터리에 배치합니다.PATH
를 확인하려면 다음 명령을 실행합니다.$ echo $PATH
OpenShift CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
$ oc <command>
2.1.2.1.2. Windows에서 OpenSfhit CLI 설치
다음 절차에 따라 Windows에 OpenShift CLI(oc
) 바이너리를 설치할 수 있습니다.
프로세스
- Red Hat 고객 포털에서 OpenShift Container Platform 다운로드 페이지로 이동합니다.
- 버전 드롭다운 메뉴에서 적절한 버전을 선택합니다.
- OpenShift v4.6 Windows Client 항목 옆에 있는 지금 다운로드를 클릭하고 파일을 저장합니다.
- ZIP 프로그램으로 아카이브의 압축을 풉니다.
oc
바이너리를PATH
에 있는 디렉터리로 이동합니다.PATH
를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.C:\> path
OpenShift CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
C:\> oc <command>
2.1.2.1.3. macOS에 OpenShift CLI 설치
다음 절차에 따라 macOS에서 OpenShift CLI(oc
) 바이너리를 설치할 수 있습니다.
프로세스
- Red Hat 고객 포털에서 OpenShift Container Platform 다운로드 페이지로 이동합니다.
- 버전 드롭다운 메뉴에서 적절한 버전을 선택합니다.
- OpenShift v4.6 MacOSX Client 항목 옆에 있는 지금 다운로드를 클릭하고 파일을 저장합니다.
- 아카이브의 압축을 해제하고 압축을 풉니다.
oc
바이너리 PATH의 디렉터리로 이동합니다.PATH
를 확인하려면 터미널을 열고 다음 명령을 실행합니다.$ echo $PATH
OpenShift CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
$ oc <command>
2.1.2.2. 웹 콘솔을 사용하여 OpenShift CLI 설치
웹 콘솔에서 OpenShift Container Platform과 상호 작용하기 위해 OpenShift CLI(oc
)를 설치할 수 있습니다. Linux, Windows 또는 macOS에 oc
를 설치할 수 있습니다.
이전 버전의 oc
를 설치한 경우, OpenShift Container Platform 4.6의 모든 명령을 완료하는 데 해당 버전을 사용할 수 없습니다. 새 버전의 oc
를 다운로드하여 설치합니다.
2.1.2.2.1. 웹 콘솔을 사용하여 Linux에 OpenShift CLI 설치
다음 절차를 사용하여 Linux에서 OpenShift CLI(oc
) 바이너리를 설치할 수 있습니다.
절차
웹 콘솔에서 ? 를 클릭합니다.
명령줄 툴 을 클릭합니다.
-
Linux 플랫폼에 적합한
oc
바이너리를 선택한 다음 Download oc for Linux(Linux 용 oc 다운로드)를 클릭합니다. - 파일을 저장합니다.
아카이브의 압축을 풉니다.
$ tar xvzf <file>
oc
바이너리를PATH
에 있는 디렉터리로 이동합니다.PATH
를 확인하려면 다음 명령을 실행합니다.$ echo $PATH
OpenShift CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
$ oc <command>
2.1.2.2.2. 웹 콘솔을 사용하여 Windows에서 OpenShift CLI 설치
다음 절차를 사용하여 Winndows에 OpenShift CLI(oc
) 바이너리를 설치할 수 있습니다.
절차
웹 콘솔에서 ? 를 클릭합니다.
명령줄 툴 을 클릭합니다.
-
Windows용
oc
바이너리를 선택한 다음 x86_64용 Windows용 oc 다운로드를 클릭합니다. - 파일을 저장합니다.
- ZIP 프로그램으로 아카이브의 압축을 풉니다.
oc
바이너리를PATH
에 있는 디렉터리로 이동합니다.PATH
를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.C:\> path
OpenShift CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
C:\> oc <command>
2.1.2.2.3. 웹 콘솔을 사용하여 macOS에 OpenShift CLI 설치
다음 절차에 따라 macOS에서 OpenShift CLI(oc
) 바이너리를 설치할 수 있습니다.
절차
웹 콘솔에서 ? 를 클릭합니다.
명령줄 툴 을 클릭합니다.
-
macOS용
oc
바이너리를 선택한 다음 x86_64용 Mac용 oc 다운로드를 클릭합니다. - 파일을 저장합니다.
- 아카이브의 압축을 해제하고 압축을 풉니다.
oc
바이너리 PATH의 디렉터리로 이동합니다.PATH
를 확인하려면 터미널을 열고 다음 명령을 실행합니다.$ echo $PATH
OpenShift CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
$ oc <command>
2.1.2.3. RPM을 사용하여 OpenShift CLI 설치
RHEL(Red Hat Enterprise Linux)의 경우 Red Hat 계정에 활성 OpenShift Container Platform 서브스크립션이 있으면 OpenShift CLI(oc
)를 RPM으로 설치할 수 있습니다.
사전 요구 사항
- root 또는 sudo 권한이 있어야 합니다.
절차
Red Hat Subscription Manager에 등록합니다.
# subscription-manager register
최신 서브스크립션 데이터를 가져옵니다.
# subscription-manager refresh
사용 가능한 서브스크립션을 나열하십시오.
# subscription-manager list --available --matches '*OpenShift*'
이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이 서브스크립션을 등록된 시스템에 연결합니다.
# subscription-manager attach --pool=<pool_id>
OpenShift Container Platform 4.6에 필요한 리포지토리를 활성화합니다.
Red Hat Enterprise Linux 8의 경우:
# subscription-manager repos --enable="rhocp-4.6-for-rhel-8-x86_64-rpms"
Red Hat Enterprise Linux 7의 경우:
# subscription-manager repos --enable="rhel-7-server-ose-4.6-rpms"
openshift-clients
패키지를 설치합니다.# yum install openshift-clients
CLI를 설치한 후 oc
명령을 사용할 수 있습니다.
$ oc <command>
2.1.2.4. Homebrew를 사용하여 OpenShift CLI 설치
macOS의 경우 Homebrew 패키지 관리자를 사용하여 OpenShift CLI(oc
)를 설치할 수 있습니다.
사전 요구 사항
-
Homebrew(
brew
)가 설치되어 있어야 합니다.
절차
다음 명령을 실행하여 openshift-cli 패키지를 설치합니다.
$ brew install openshift-cli
2.1.3. OpenShift CLI에 로그인
oc
CLI에 로그인하면 클러스터에 액세스하여 관리할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 대한 액세스 권한이 있어야 합니다.
- CLI가 설치되어 있어야 합니다.
HTTP 프록시 서버를 통해서만 액세스할 수 있는 클러스터에 액세스하려면 HTTP_PROXY
, HTTPS_PROXY
및 NO_PROXY
변수를 설정할 수 있습니다. oc
CLI에서는 이러한 환경 변수를 준수하므로 클러스터와의 모든 통신이 HTTP 프록시를 통해 이루어집니다.
인증 헤더는 HTTPS 전송을 사용하는 경우에만 전송됩니다.
절차
oc login
명령을 사용하여 CLI에 로그인하고 메시지가 표시되면 필요한 정보를 입력합니다.$ oc login
출력 예
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 3 Password: 4 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.
웹 콘솔에 로그인한 경우 토큰 및 서버 정보를 포함하는 oc login
명령을 생성할 수 있습니다. 명령을 사용하여 대화형 프롬프트 없이 OpenShift Container Platform CLI에 로그인할 수 있습니다. 명령을 생성하려면 웹 콘솔의 오른쪽 상단에 있는 사용자 이름 드롭다운 메뉴에서 로그인 복사 명령을 선택합니다.
이제 클러스터를 관리하기 위한 프로젝트를 생성하거나 다른 명령을 실행할 수 있습니다.
2.1.4. OpenShift CLI 사용
다음 섹션을 검토하여 CLI로 일반적인 작업을 완료하는 방법을 알아봅니다.
2.1.4.1. 프로젝트 생성
oc new-project
명령을 사용하여 새 프로젝트를 생성합니다.
$ oc new-project my-project
출력 예
Now using project "my-project" on server "https://openshift.example.com:6443".
2.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.
2.1.4.3. Pod 보기
oc get pods
명령을 사용하여 현재 프로젝트의 Pod를 봅니다.
Pod 내부에서 oc
를 실행하고 네임스페이스를 지정하지 않으면 기본적으로 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>
2.1.4.4. Pod 로그 보기
oc logs
명령을 사용하여 특정 Pod의 로그를 봅니다.
$ oc logs cakephp-ex-1-deploy
출력 예
--> Scaling cakephp-ex-1 to 1 --> Success
2.1.4.5. 현재 프로젝트 보기
oc project
명령을 사용하여 현재 프로젝트를 봅니다.
$ oc project
출력 예
Using project "my-project" on server "https://openshift.example.com:6443".
2.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.
2.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 ...
2.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 ...
2.1.6. OpenShift CLI에서 로그아웃
OpenShift CLI에서 로그아웃하여 현재 세션을 종료할 수 있습니다.
oc logout
명령을 사용합니다.$ oc logout
출력 예
Logged "user1" out on "https://openshift.example.com"
이렇게 하면 저장된 인증 토큰이 서버에서 삭제되고 구성 파일에서 제거됩니다.
2.2. OpenShift CLI 구성
2.2.1. 탭 완료 활성화
Bash 또는 Zsh 쉘의 탭 완료를 활성화할 수 있습니다.
2.2.1.1. Bash의 탭 완료 활성화
OpenShift CLI(oc
)를 설치한 후 탭 완료를 활성화하여 oc
명령을 자동으로 완료하거나 탭을 누를 때 옵션을 제안할 수 있습니다. 다음 절차에서는 Bash 쉘에 대한 탭 완료를 활성화합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있어야 합니다. -
bash-completion
패키지가 설치되어 있어야 합니다.
절차
Bash 완료 코드를 파일에 저장합니다.
$ oc completion bash > oc_bash_completion
파일을
/etc/bash_completion.d/
에 복사합니다.$ sudo cp oc_bash_completion /etc/bash_completion.d/
파일을 로컬 디렉터리에 저장하고
.bashrc
파일에서 소싱할 수도 있습니다.
새 터미널을 열면 탭 완료가 활성화됩니다.
2.2.1.2. Zsh에 대한 탭 완료 활성화
OpenShift CLI(oc
)를 설치한 후 탭 완료를 활성화하여 oc
명령을 자동으로 완료하거나 탭을 누를 때 옵션을 제안할 수 있습니다. 다음 절차에서는 Zsh 쉘에 대한 탭 완료를 활성화합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있어야 합니다.
절차
oc
에 대한 탭 완료를.zshrc
파일에 추가하려면 다음 명령을 실행합니다.$ cat >>~/.zshrc<<EOF if [ $commands[oc] ]; then source <(oc completion zsh) compdef _oc oc fi EOF
새 터미널을 열면 탭 완료가 활성화됩니다.
2.3. CLI 프로필 관리
CLI 구성 파일을 사용하면 CLI 툴 개요 와 함께 사용할 다양한 프로필 또는 컨텍스트를 구성할 수 있습니다. 컨텍스트는 nickname 과 관련된 사용자 인증 및 OpenShift Container Platform 서버 정보로 구성됩니다.
2.3.1. CLI 프로필 간 전환 정보
컨텍스트를 사용하면 CLI 작업을 사용할 때 여러 OpenShift Container Platform 서버 또는 클러스터에서 여러 사용자 간에 쉽게 전환할 수 있습니다. nickname은 컨텍스트, 사용자 인증 정보 및 클러스터 세부 정보에 대한 간단한 참조를 제공하여 CLI 구성을 보다 쉽게 관리할 수 있습니다. CLI로 처음으로 로그인한 후 OpenShift Container Platform은 아직 존재하지 않는 경우 ~/.kube/config
파일을 생성합니다. oc login
작업 중에 자동으로 또는 CLI 프로필을 수동으로 구성하여 CLI에 인증 및 연결 세부 정보가 제공되면 구성 파일에 업데이트된 정보가 저장됩니다.
CLI 구성 파일
apiVersion: v1 clusters: 1 - cluster: insecure-skip-tls-verify: true server: https://openshift1.example.com:8443 name: openshift1.example.com:8443 - cluster: insecure-skip-tls-verify: true server: https://openshift2.example.com:8443 name: openshift2.example.com:8443 contexts: 2 - context: cluster: openshift1.example.com:8443 namespace: alice-project user: alice/openshift1.example.com:8443 name: alice-project/openshift1.example.com:8443/alice - context: cluster: openshift1.example.com:8443 namespace: joe-project user: alice/openshift1.example.com:8443 name: joe-project/openshift1/alice current-context: joe-project/openshift1.example.com:8443/alice 3 kind: Config preferences: {} users: 4 - name: alice/openshift1.example.com:8443 user: token: xZHd2piv5_9vQrg-SKXRJ2Dsl9SceNJdhNTljEKTb8k
- 1
- cluster
섹션은
마스터 서버의 주소를 포함하여 OpenShift Container Platform 클러스터에 대한 연결 세부 정보를 정의합니다. 이 예에서는 하나의 클러스터 이름이openshift1.example.com:8443
이고 다른 클러스터는 이름이openshift2.example.com:8443
입니다. - 2
- 이
context
섹션은alice-project
프로젝트,openshift1.example.com:8443
클러스터,alice
사용자, 다른 nick 이름의joe-project/openshift1.example.com:8443/alice
, 즉 하나의 컨텍스트 이름을alice-project/openshift1.example.com:8443/alice
, 즉 하나의 컨텍스트를 정의합니다.joe-project
프로젝트,openshift1.example.com:8443
클러스터 및alice
사용자 사용. - 3
current-context
매개변수는joe-project/openshift1.example.com:8443/alice
컨텍스트가 현재 사용 중이며,alice
사용자가openshift1.example.com:8443
클러스터의joe-project
프로젝트에서 작업할 수 있음을 보여줍니다.- 4
users
섹션은 사용자 자격 증명을 정의합니다. 이 예에서 사용자 nicknamealice/openshift1.example.com:8443
은 액세스 토큰을 사용합니다.
CLI는 런타임 시 로드되고 명령줄에서 지정된 덮어쓰기 옵션과 함께 병합되는 여러 구성 파일을 지원할 수 있습니다. 로그인한 후 oc status
또는 oc project
명령을 사용하여 현재 작업 환경을 확인할 수 있습니다.
현재 작업 중인 환경 확인
$ oc status
출력 예
oc status In project Joe's Project (joe-project) service database (172.30.43.12:5434 -> 3306) database deploys docker.io/openshift/mysql-55-centos7:latest #1 deployed 25 minutes ago - 1 pod service frontend (172.30.159.137:5432 -> 8080) frontend deploys origin-ruby-sample:latest <- builds https://github.com/openshift/ruby-hello-world with joe-project/ruby-20-centos7:latest #1 deployed 22 minutes ago - 2 pods To see more information about a service or deployment, use 'oc describe service <name>' or 'oc describe dc <name>'. You can use 'oc get all' to see lists of each of the types described in this example.
현재 프로젝트 나열
$ oc project
출력 예
Using project "joe-project" from context named "joe-project/openshift1.example.com:8443/alice" on server "https://openshift1.example.com:8443".
oc login
명령을 다시 실행하고 대화형 프로세스 중에 필요한 정보를 제공하여 사용자 인증 정보 및 클러스터 세부 정보의 다른 조합을 사용하여 로그인할 수 있습니다. 컨텍스트는 아직 존재하지 않는 경우 제공된 정보를 기반으로 구성됩니다. 이미 로그인한 후 현재 사용자가 이미 액세스할 수 있는 다른 프로젝트로 전환하려면 oc project
명령을 사용하여 프로젝트 이름을 입력합니다.
$ oc project alice-project
출력 예
Now using project "alice-project" on server "https://openshift1.example.com:8443".
출력에 표시된 대로 oc config view
명령을 사용하여 현재 CLI 구성을 볼 수 있습니다. 고급 사용을 위해 추가 CLI 구성 명령을 사용할 수도 있습니다.
관리자 자격 증명에 액세스할 수 있지만 더 이상 기본 시스템 사용자 system:admin
으로 로그인하지 않은 경우 CLI 구성 파일에 인증 정보가 계속 있는 한 언제든지 이 사용자로 다시 로그인할 수 있습니다. 다음 명령은 기본 프로젝트에 로그인하여 전환합니다.
$ oc login -u system:admin -n default
2.3.2. CLI 프로필 수동 구성
이 섹션에서는 CLI 구성의 고급 사용에 대해 설명합니다. 대부분의 경우 oc login
및 oc project
명령을 사용하여 컨텍스트와 프로젝트를 로그인하고 전환할 수 있습니다.
CLI 구성 파일을 수동으로 구성하려면 파일을 직접 수정하는 대신 oc config
명령을 사용할 수 있습니다. oc config
명령에는 다음과 같은 목적으로 유용한 여러 하위 명령이 포함되어 있습니다.
하위 명령 | 사용법 |
---|---|
| CLI 구성 파일에 클러스터 항목을 설정합니다. 참조된 클러스터 닉네임이 이미 존재하는 경우 지정된 정보가 에 병합됩니다. $ oc config set-cluster <cluster_nickname> [--server=<master_ip_or_fqdn>] [--certificate-authority=<path/to/certificate/authority>] [--api-version=<apiversion>] [--insecure-skip-tls-verify=true] |
| CLI 구성 파일에 컨텍스트 항목을 설정합니다. 참조된 컨텍스트 닉네임이 이미 있는 경우 지정된 정보가 에 병합됩니다. $ oc config set-context <context_nickname> [--cluster=<cluster_nickname>] [--user=<user_nickname>] [--namespace=<namespace>] |
| 지정된 컨텍스트 nickname을 사용하여 현재 컨텍스트를 설정합니다. $ oc config use-context <context_nickname> |
| CLI 구성 파일에서 개별 값을 설정합니다. $ oc config set <property_name> <property_value>
|
| CLI 구성 파일에서 개별 값을 설정 해제합니다. $ oc config unset <property_name>
|
| 현재 사용 중인 병합된 CLI 구성을 표시합니다. $ oc config view 지정된 CLI 구성 파일의 결과를 표시합니다. $ oc config view --config=<specific_filename> |
사용 예
-
액세스 토큰을 사용하는 사용자로 로그인합니다. 이 토큰은
alice
사용자가 사용합니다.
$ oc login https://openshift1.example.com --token=ns7yVhuRNpDM9cgzfhhxQ7bM5s7N2ZVrkZepSRf4LC0
- 자동으로 생성된 클러스터 항목을 확인합니다.
$ oc config view
출력 예
apiVersion: v1 clusters: - cluster: insecure-skip-tls-verify: true server: https://openshift1.example.com name: openshift1-example-com contexts: - context: cluster: openshift1-example-com namespace: default user: alice/openshift1-example-com name: default/openshift1-example-com/alice current-context: default/openshift1-example-com/alice kind: Config preferences: {} users: - name: alice/openshift1.example.com user: token: ns7yVhuRNpDM9cgzfhhxQ7bM5s7N2ZVrkZepSRf4LC0
- 사용자가 원하는 네임스페이스에 로그인하도록 현재 컨텍스트를 업데이트합니다.
$ oc config set-context `oc config current-context` --namespace=<project_name>
- 현재 컨텍스트를 검사하여 변경 사항이 구현되었는지 확인합니다.
$ oc whoami -c
CLI 옵션을 재정의하거나 컨텍스트가 전환될 때까지 달리 지정하지 않는 한 모든 후속 CLI 작업은 새 컨텍스트를 사용합니다.
2.3.3. 규칙 로드 및 병합
CLI 구성에 대한 CLI 작업을 실행할 때 다음 규칙을 따를 수 있습니다.
CLI 구성 파일은 다음 계층 및 병합 규칙을 사용하여 워크스테이션에서 검색됩니다.
-
--config
옵션이 설정되면 해당 파일만 로드됩니다. 플래그는 한 번 설정되고 병합이 수행되지 않습니다. -
$KUBECONFIG
환경 변수가 설정되면 사용됩니다. 변수가 경로 목록일 수 있으며, 경로가 함께 병합되는 경우도 있습니다. 값을 수정하면 스탠자를 정의하는 파일에서 수정됩니다. 값이 생성되면 존재하는 첫 번째 파일에 생성됩니다. 체인에 파일이 없으면 목록에 마지막 파일을 만듭니다. -
그렇지 않으면
~/.kube/config
파일이 사용되며 병합이 수행되지 않습니다.
-
사용할 컨텍스트는 다음 흐름의 첫 번째 일치에 따라 결정됩니다.
-
--context
옵션의 값입니다. -
CLI 구성 파일의
current-context
값입니다. - 이 단계에서는 빈 값이 허용됩니다.
-
사용할 사용자 및 클러스터가 결정됩니다. 이 시점에는 컨텍스트가 있거나 없을 수 있습니다. 다음 흐름에서 첫 번째 일치를 기반으로 빌드되며, 이는 사용자와 클러스터에 대해 한 번 실행됩니다.
-
클러스터 이름에 대한
--user
및 사용자 이름에 대한--cluster
옵션의 값입니다. -
context
옵션이 있는
경우 컨텍스트의 값을 사용합니다. - 이 단계에서는 빈 값이 허용됩니다.
-
클러스터 이름에 대한
사용할 실제 클러스터 정보가 결정됩니다. 이 시점에서 클러스터 정보가 있거나 없을 수 있습니다. 클러스터 정보의 각 조각은 다음 흐름에서 첫 번째 일치를 기반으로 빌드됩니다.
다음 명령줄 옵션의 값:
-
--server
, -
--api-version
-
--certificate-authority
-
--insecure-skip-tls-verify
-
- 클러스터 정보와 속성 값이 있는 경우 이를 사용합니다.
- 서버 위치가 없는 경우 오류가 발생합니다.
사용할 실제 사용자 정보가 결정됩니다. 사용자는 사용자당 하나의 인증 기술만 가질 수 있다는 점을 제외하고 클러스터와 동일한 규칙을 사용하여 빌드됩니다. 충돌하는 기술은 작업이 실패합니다. 명령줄 옵션이 구성 파일 값보다 우선합니다. 유효한 명령줄 옵션은 다음과 같습니다.
-
--auth-path
-
--client-certificate
-
--client-key
-
--token
-
- 여전히 누락된 모든 정보에 대해 기본값이 사용되며 추가 정보를 입력하라는 메시지가 표시됩니다.
2.4. 플러그인을 사용하여 OpenShift CLI 확장
기본 oc
명령에 빌드할 플러그인을 작성하고 설치하여 OpenShift Container Platform CLI에서 새롭고 더 복잡한 작업을 수행할 수 있습니다.
2.4.1. CLI 플러그인 작성
명령줄 명령을 작성할 수 있는 모든 프로그래밍 언어 또는 스크립트로 OpenShift Container Platform CLI용 플러그인을 작성할 수 있습니다. 기존 oc
명령은 플러그인으로 덮어쓸 수 없습니다.
OpenShift CLI 플러그인은 현재 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 고객은 출시 예정된 제품 기능을 프리뷰를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.
자세한 내용은 Red Hat 기술 프리뷰 기능 지원 범위를 참조하십시오.
절차
이 절차에서는 oc foo
명령을 실행할 때 메시지를 터미널에 출력하는 간단한 Bash 플러그인을 생성합니다.
oc-foo
라는 파일을 생성합니다.플러그인 파일 이름을 지정할 때 다음 사항에 유의합니다.
-
파일이 플러그인으로 인식되려면
oc-
또는kubectl-
로 시작되어야 합니다. -
파일 이름에 따라 플러그인을 호출하는 명령이 결정됩니다. 예를 들어 파일 이름이
oc-foo-bar
인 플러그인은oc foo bar
명령으로 호출할 수 있습니다. 명령에 대시를 포함하기 위해 밑줄을 사용할 수도 있습니다. 예를 들어 파일 이름이oc-foo_bar
인 플러그인은oc foo-bar
명령으로 호출할 수 있습니다.
-
파일이 플러그인으로 인식되려면
파일에 다음 콘텐츠를 추가합니다.
#!/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
명령을 사용하여 호출할 수 있습니다.
추가 리소스
- Go로 작성된 플러그인의 예는 샘플 플러그인 리포지터리를 검토하십시오.
- Go로 플러그인을 작성하는 데 유용한 유틸리티 세트는 CLI 런타임 리포지터리를 검토하십시오.
2.4.2. CLI 플러그인 설치 및 사용
OpenShift Container Platform CLI용 사용자 정의 플러그인을 작성한 후에는 플러그인을 설치해야 플러그인에서 제공하는 기능을 사용할 수 있습니다.
OpenShift CLI 플러그인은 현재 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 고객은 출시 예정된 제품 기능을 프리뷰를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.
자세한 내용은 Red Hat 기술 프리뷰 기능 지원 범위를 참조하십시오.
사전 요구 사항
-
oc
CLI 툴이 설치되어 있어야 합니다. -
oc-
또는kubectl-
로 시작하는 CLI 플러그인 파일이 있어야 합니다.
절차
필요한 경우 플러그인 파일을 실행 가능하게 업데이트합니다.
$ chmod +x <plugin_file>
파일을
PATH
에 있는 임의의 위치(예:/usr/local/bin/
)에 배치합니다.$ sudo mv <plugin_file> /usr/local/bin/.
oc plugin list
를 실행하여 플러그인이 나열되는지 확인합니다.$ oc plugin list
출력 예
The following compatible plugins are available: /usr/local/bin/<plugin_file>
여기에 플러그인이 나열되지 않으면 파일이
oc-
또는kubectl-
로 시작하고, 실행 가능하며,PATH
에 있는지 확인합니다.플러그인에서 도입한 새 명령 또는 옵션을 호출합니다.
예를 들어 샘플 플러그인 리포지터리에서
kubectl-ns
플러그인을 빌드하고 설치한 경우 다음 명령을 사용하여 현재 네임스페이스를 볼 수 있습니다.$ oc ns
플러그인을 호출하는 명령은 플러그인 파일 이름에 따라 달라집니다. 예를 들어 파일 이름이
oc-foo-bar
인 플러그인은oc foo bar
명령으로 호출합니다.
2.5. OpenShift CLI 개발자 명령
2.5.1. 기본 CLI 명령
2.5.1.1. explain
특정 리소스에 대한 문서를 표시합니다.
예제: Pod 문서 표시
$ oc explain pods
2.5.1.2. login
OpenShift Container Platform 서버에 로그인하고, 나중에 사용할 수 있도록 로그인 정보를 저장합니다.
예제: 대화형 로그인
$ oc login
예제: 사용자 이름을 지정하여 로그인합니다.
$ oc login -u user1
2.5.1.3. new-app
소스 코드, 템플릿 또는 이미지를 지정하여 새 애플리케이션을 생성합니다.
예제: 로컬 Git 리포지토리에서 새 애플리케이션 생성
$ oc new-app .
예제: 원격 Git 리포지토리에서 새 애플리케이션 생성
$ oc new-app https://github.com/sclorg/cakephp-ex
예제: 개인 원격 리포지터리에서 새 애플리케이션 생성
$ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret
2.5.1.4. new-project
새 프로젝트를 생성하여 구성의 기본 프로젝트로 전환합니다.
예제: 새 프로젝트 만들기
$ oc new-project myproject
2.5.1.5. project
다른 프로젝트로 전환하여 구성의 기본값으로 설정합니다.
예제: 다른 프로젝트로 전환
$ oc project test-project
2.5.1.6. projects
서버에 있는 현재 활성 프로젝트 및 기존 프로젝트에 대한 정보를 표시합니다.
예제: 모든 프로젝트 나열
$ oc projects
2.5.1.7. status
현재 프로젝트의 상위 수준 개요를 표시합니다.
예제: 현재 프로젝트의 상태 표시
$ oc status
2.5.2. 빌드 및 배포 CLI 명령
2.5.2.1. cancel-build
실행 중이거나 보류 중인 빌드 또는 새 빌드를 취소합니다.
예제: 빌드 취소
$ oc cancel-build python-1
예제: python
빌드 구성에서 보류 중인 모든 빌드 취소
$ oc cancel-build buildconfig/python --state=pending
2.5.2.2. import-image
이미지 리포지터리에서 최신 태그 및 이미지 정보를 가져옵니다.
예제: 최신 이미지 정보 가져오기
$ oc import-image my-ruby
2.5.2.3. new-build
소스 코드에서 새 빌드 구성을 생성합니다.
예제: 로컬 Git 리포지토리에서 빌드 구성 생성
$ oc new-build .
예제: 원격 Git 리포지토리에서 빌드 구성 생성
$ oc new-build https://github.com/sclorg/cakephp-ex
2.5.2.4. rollback
애플리케이션을 이전 배포로 되돌립니다.
예제: 마지막으로 성공한 배포로 롤백
$ oc rollback php
예제: 특정 버전으로 롤백
$ oc rollback php --to-version=3
2.5.2.5. rollout
새 롤아웃을 시작하거나, 해당 상태 또는 기록을 보거나, 애플리케이션의 이전 개정 버전으로 롤백합니다.
예제: 마지막으로 성공한 배포로 롤백
$ oc rollout undo deploymentconfig/php
예제: 최신 상태로 배포의 새 롤아웃 시작
$ oc rollout latest deploymentconfig/php
2.5.2.6. start-build
빌드 구성에서 빌드를 시작하거나 기존 빌드를 복사합니다.
예제: 지정된 빌드 구성에서 빌드 시작
$ oc start-build python
예제: 이전 빌드에서 빌드 시작
$ oc start-build --from-build=python-1
예제: 현재 빌드에 사용할 환경 변수 설정
$ oc start-build python --env=mykey=myvalue
2.5.2.7. tag
기존 이미지를 이미지 스트림에 태깅합니다.
예제: ruby
이미지의 latest
태그가 2.0
태그의 이미지를 참조하도록 구성
$ oc tag ruby:latest ruby:2.0
2.5.3. 애플리케이션 관리 CLI 명령
2.5.3.1. annotate
하나 이상의 리소스에서 주석을 업데이트합니다.
예제: 경로에 주석 추가
$ oc annotate route/test-route haproxy.router.openshift.io/ip_whitelist="192.168.1.10"
예제: 경로에서 주석 제거
$ oc annotate route/test-route haproxy.router.openshift.io/ip_whitelist-
2.5.3.2. apply
JSON 또는 YAML 형식의 파일 이름 또는 stdin(표준 입력)별 리소스에 구성을 적용합니다.
예제: pod.json의 구성을 Pod
에 적용합니다.
$ oc apply -f pod.json
2.5.3.3. autoscale
배포 또는 복제 컨트롤러를 자동 스케일링합니다.
예제: 최소 2개 및 최대 5개의 Pod로 자동 스케일링
$ oc autoscale deploymentconfig/parksmap-katacoda --min=2 --max=5
2.5.3.4. create
JSON 또는 YAML 형식의 파일 이름 또는 stdin(표준 입력)별 리소스를 생성합니다.
예제: pod .json의 콘텐츠를 사용하여 Pod
생성
$ oc create -f pod.json
2.5.3.5. delete
리소스를 삭제합니다.
예제: 이름이 norths map-katacoda-1-qfqz4
인 Pod 삭제
$ oc delete pod/parksmap-katacoda-1-qfqz4
예제: app=parksmap-katacoda
레이블이 있는 모든 포드 삭제
$ oc delete pods -l app=parksmap-katacoda
2.5.3.6. describe
특정 오브젝트에 대한 자세한 정보를 반환합니다.
예제: 이름이 example
인 배포를 설명합니다.
$ oc describe deployment/example
예제: 모든 Pod 설명
$ oc describe pods
2.5.3.7. edit
리소스를 편집합니다.
예제: 기본 편집기를 사용하여 배포 편집
$ oc edit deploymentconfig/parksmap-katacoda
예제: 다른 편집기를 사용하여 배포 편집
$ OC_EDITOR="nano" oc edit deploymentconfig/parksmap-katacoda
예제: JSON 형식으로 배포 편집
$ oc edit deploymentconfig/parksmap-katacoda -o json
2.5.3.8. expose
서비스를 경로로 외부에 노출합니다.
예제: 서비스 노출
$ oc expose service/parksmap-katacoda
예제: 서비스 노출 및 호스트 이름 지정
$ oc expose service/parksmap-katacoda --hostname=www.my-host.com
2.5.3.9. get
리소스를 하나 이상 표시합니다.
예제: default
네임스페이스에 Pod 나열
$ oc get pods -n default
예제: JSON 형식의 python
배포에 대한 세부 정보 가져오기
$ oc get deploymentconfig/python -o json
2.5.3.10. label
하나 이상의 리소스에서 레이블을 업데이트합니다.
예제: 라벨 status
를 unhealthy로 설정하여 python-1-mz2rf
Pod를 업데이트합니다 .
$ oc label pod/python-1-mz2rf status=unhealthy
2.5.3.11. scale
복제 컨트롤러 또는 배포에 대해 필요한 복제본 수를 설정합니다.
예제: ruby-app
배포를 3개의 포드로 스케일링
$ oc scale deploymentconfig/ruby-app --replicas=3
2.5.3.12. secrets
프로젝트의 시크릿을 관리합니다.
예제: my-pull-secret
을 default
서비스 계정에서 이미지 풀 시크릿으로 사용하도록 허용
$ oc secrets link default my-pull-secret --for=pull
2.5.3.13. serviceaccounts
서비스 계정에 토큰을 할당하거나 서비스 계정에 사용할 새 토큰 또는 kubeconfig
파일을 생성합니다.
예제: default
서비스 계정에 토큰 할당
$ oc serviceaccounts get-token default
2.5.3.14. set
기존 애플리케이션 리소스를 구성합니다.
예제: 빌드 구성에 보안 이름 설정
$ oc set build-secret --source buildconfig/mybc mysecret
2.5.4. 문제 해결 및 디버깅 CLI 명령
2.5.4.1. attach
실행 중인 컨테이너에 쉘을 연결합니다.
예제: Pod python
-1-mz2rf에서 python
컨테이너에서 출력 가져오기
$ oc attach python-1-mz2rf -c python
2.5.4.2. cp
컨테이너 간에 파일 및 디렉터리를 복사
예제: python-1-mz2rf
Pod에서 로컬 파일 시스템으로 파일 복사
$ oc cp default/python-1-mz2rf:/opt/app-root/src/README.md ~/mydirectory/.
2.5.4.3. debug
실행 중인 애플리케이션을 디버깅하는 명령 쉘을 시작합니다.
예제: python
배포를 디버그
$ oc debug deploymentconfig/python
2.5.4.4. exec
컨테이너에서 명령을 실행합니다.
예제: Pod python -1-mz2rf의
컨테이너에서 python
ls
명령을 실행합니다.
$ oc exec python-1-mz2rf -c python ls
2.5.4.5. logs
특정 빌드, 빌드 구성, 배포 또는 Pod에 대한 로그 출력을 검색합니다.
예제: python
배포에서 최신 로그 스트리밍
$ oc logs -f deploymentconfig/python
2.5.4.6. port-forward
Pod에 하나 이상의 로컬 포트를 전달합니다.
예제: 포트 8888
에서 로컬로 수신 대기하고 Pod의 포트 5000
으로 전달합니다.
$ oc port-forward python-1-mz2rf 8888:5000
2.5.4.7. proxy
Kubernetes API 서버에 대해 프록시를 실행합니다.
예제: 포트 8011
의 API 서버로 프록시를 실행합니다 ./local/www/에서 정적 콘텐츠를 제공합니다.
$ oc proxy --port=8011 --www=./local/www/
2.5.4.8. rsh
컨테이너에 대해 원격 쉘 세션을 엽니다.
예제: python-1-mz2rf
Pod의 첫 번째 컨테이너에서 쉘 세션을 엽니다.
$ oc rsh python-1-mz2rf
2.5.4.9. rsync
실행 중인 Pod 컨테이너로 또는 실행 중인 Pod 컨테이너에서 디렉터리 콘텐츠를 복사합니다. 변경된 파일만 운영 체제의 rsync
명령으로 복사됩니다.
예제: Pod 디렉터리와 로컬 디렉터리의 파일 동기화
$ oc rsync ~/mydirectory/ python-1-mz2rf:/opt/app-root/src/
2.5.4.10. run
특정 이미지를 실행하는 Pod를 생성합니다.
예제: perl
이미지를 실행하는 포드 시작
$ oc run my-test --image=perl
2.5.4.11. wait
하나 이상의 리소스에서 특정 조건을 대기합니다.
이 명령은 실험적인 기능으로, 사전 공지 없이 변경될 수 있습니다.
예제: python-1-mz2rf
Pod가 삭제될 때까지 기다립니다.
$ oc wait --for=delete pod/python-1-mz2rf
2.5.5. 고급 개발자 CLI 명령
2.5.5.1. api-resources
서버에서 지원하는 전체 API 리소스 목록을 표시합니다.
예제: 지원되는 API 리소스 나열
$ oc api-resources
2.5.5.2. api-versions
서버에서 지원하는 전체 API 버전 목록을 표시합니다.
예제: 지원되는 API 버전 나열
$ oc api-versions
2.5.5.3. auth
권한을 검사하고 RBAC 역할을 조정합니다.
예제: 현재 사용자가 Pod 로그를 읽을 수 있는지 확인
$ oc auth can-i get pods --subresource=log
예제: 파일에서 RBAC 역할 및 권한 조정
$ oc auth reconcile -f policy.json
2.5.5.4. cluster-info
마스터 및 클러스터 서비스 주소를 표시합니다.
예제: 클러스터 정보 표시
$ oc cluster-info
2.5.5.5. convert
YAML 또는 JSON 구성 파일을 다른 API 버전으로 변환하고 표준 출력(stdout)으로 출력합니다.
예제: pod.yaml
을 최신 버전으로 변환
$ oc convert -f pod.yaml
2.5.5.6. extract
구성 맵 또는 시크릿 콘텐츠를 추출합니다. 구성 맵 또는 시크릿의 각 키는 키 이름을 사용하여 별도의 파일로 생성됩니다.
예제: ruby-1-ca
구성 맵의 콘텐츠를 현재 디렉터리로 다운로드합니다.
$ oc extract configmap/ruby-1-ca
예제: ruby-1-ca
구성 맵의 내용을 stdout로 출력
$ oc extract configmap/ruby-1-ca --to=-
2.5.5.7. idle
확장 가능한 리소스를 유휴 상태로 설정합니다. 유휴 상태로 설정된 서비스는 트래픽이 수신되거나 oc scale
명령을 통해 수동으로 유휴 상태가 해제될 수 있는 경우 자동으로 유휴 상태가 해제됩니다.
예제: ruby-app
서비스 유휴 상태
$ oc idle ruby-app
2.5.5.8. image
OpenShift Container Platform 클러스터에서 이미지를 관리합니다.
예제: 다른 태그에 이미지 복사
$ oc image mirror myregistry.com/myimage:latest myregistry.com/myimage:stable
2.5.5.9. observe
리소스에 대한 변경 사항을 관찰하고 작업을 수행합니다.
예제: 서비스 변경 사항 관찰
$ oc observe services
2.5.5.10. patch
JSON 또는 YAML 형식의 전략적 병합 패치를 사용하여 오브젝트 필드를 하나 이상 업데이트합니다.
예제: node1
노드의 spec.unschedulable
필드를 true
로 업데이트합니다.
$ oc patch node/node1 -p '{"spec":{"unschedulable":true}}'
사용자 지정 리소스 정의를 패치해야 하는 경우 명령에 --type merge
또는 --type json
옵션을 포함해야 합니다.
2.5.5.11. policy
권한 부여 정책을 관리합니다.
예제: 현재 프로젝트의 user1
에 편집
역할을 추가합니다.
$ oc policy add-role-to-user edit user1
2.5.5.12. process
템플릿을 리소스 목록으로 처리합니다.
예제: template.json
을 리소스 목록으로 변환하고 oc create
로 전달합니다.
$ oc process -f template.json | oc create -f -
2.5.5.13. 레지스트리
OpenShift Container Platform의 통합 레지스트리를 관리합니다.
예제: 통합 레지스트리에 대한 정보 표시
$ oc registry info
2.5.5.14. replace
지정된 구성 파일의 콘텐츠를 기반으로 기존 오브젝트를 수정합니다.
예제: pod .json의 콘텐츠를 사용하여 Pod
업데이트
$ oc replace -f pod.json
2.5.6. 설정 CLI 명령
2.5.6.1. completion
지정된 쉘에 대한 쉘 완료 코드를 출력합니다.
예제: Bash 완료 코드 표시
$ oc completion bash
2.5.6.2. config
클라이언트 구성 파일을 관리합니다.
예제: 현재 설정 표시
$ oc config view
예제: 다른 컨텍스트로 전환
$ oc config use-context test-context
2.5.6.3. logout
현재 세션에서 로그아웃합니다.
예제: 현재 세션 종료
$ oc logout
2.5.6.4. whoami
현재 세션에 대한 정보를 표시합니다.
예제: 현재 인증된 사용자 표시
$ oc whoami
2.5.7. 기타 개발자 CLI 명령
2.5.7.1. help
CLI에 대한 일반적인 도움말 정보와 사용 가능한 명령 목록을 표시합니다.
예제: 사용 가능한 명령 표시
$ oc help
예제: new-project
명령에 대한 도움말 표시
$ oc help new-project
2.5.7.2. plugin
사용자 PATH
의 사용 가능한 플러그인을 나열합니다.
예제: 사용 가능한 플러그인 나열
$ oc plugin list
2.5.7.3. 버전
oc
클라이언트 및 서버 버전을 표시합니다.
예제: 버전 정보 표시
$ oc version
클러스터 관리자의 경우 OpenShift Container Platform 서버 버전도 표시됩니다.
2.6. OpenShift CLI 관리자 명령
이러한 관리자 명령을 사용하려면 cluster-admin
또는 이와 동등한 권한이 있어야 합니다.
2.6.1. 클러스터 관리 CLI 명령
2.6.1.1. inspect
특정 리소스에 대한 디버깅 정보를 수집합니다.
이 명령은 실험적인 기능으로, 사전 공지 없이 변경될 수 있습니다.
예제: OpenShift API 서버 클러스터 Operator의 디버깅 데이터 수집
$ oc adm inspect clusteroperator/openshift-apiserver
2.6.1.2. must-gather
클러스터의 현재 상태에 대한 데이터를 대규모로 수집하여 문제를 디버깅합니다.
이 명령은 실험적인 기능으로, 사전 공지 없이 변경될 수 있습니다.
예제: 디버깅 정보 수집
$ oc adm must-gather
2.6.1.3. top
서버의 리소스 사용량 통계를 표시합니다.
예제: Pod의 CPU 및 메모리 사용량 표시
$ oc adm top pods
예제: 이미지에 대한 사용량 통계 표시
$ oc adm top images
2.6.2. 노드 관리 CLI 명령
2.6.2.1. cordon
노드를 예약 불가로 표시합니다. 수동으로 노드를 예약 불가로 표시하면 노드에서 새 Pod는 예약되지 않도록 방지하지만 노드의 기존 Pod는 영향을 받지 않습니다.
예제: node1
을 예약 불가로 표시
$ oc adm cordon node1
2.6.2.2. drain
유지 관리를 위해 노드를 드레이닝합니다.
예제: node1
드레이닝
$ oc adm drain node1
2.6.2.3. node-logs
노드 로그를 표시하고 필터링합니다.
예제: NetworkManager
에 대한 로그 가져오기
$ oc adm node-logs --role master -u NetworkManager.service
2.6.2.4. taint
하나 이상의 노드에서 테인트를 업데이트합니다.
예제: 일련의 사용자 전용 노드를 전용으로 표시하는 테인트를 추가합니다.
$ oc adm taint nodes node1 dedicated=groupName:NoSchedule
예제: node1
노드에서 전용
키가 있는 테인트를 제거합니다.
$ oc adm taint nodes node1 dedicated-
2.6.2.5. uncordon
노드를 예약 가능으로 표시합니다.
예제: node1
을 예약 가능으로 표시
$ oc adm uncordon node1
2.6.3. 보안 및 정책 CLI 명령
2.6.3.1. certificate
CSR(인증서 서명 요청)을 승인하거나 거부합니다.
예제: CSR 승인
$ oc adm certificate approve csr-sqgzp
2.6.3.2. groups
클러스터에서 그룹을 관리합니다.
예제: 새 그룹 생성
$ oc adm groups new my-group
2.6.3.3. new-project
새 프로젝트를 생성하고 관리 옵션을 지정합니다.
예제: 노드 선택기를 사용하여 새 프로젝트 생성
$ oc adm new-project myproject --node-selector='type=user-node,region=east'
2.6.3.4. pod-network
클러스터에서 Pod 네트워크를 관리합니다.
예제: 다른 글로벌 이외의 프로젝트에서
격리project1
및 project2
$ oc adm pod-network isolate-projects project1 project2
2.6.3.5. policy
클러스터의 역할 및 정책을 관리합니다.
예제: 모든 프로젝트의 user1
에 edit
역할을 추가합니다.
$ oc adm policy add-cluster-role-to-user edit user1
예제: 서비스 계정에 권한 있는
보안 컨텍스트 제약 조건 추가
$ oc adm policy add-scc-to-user privileged -z myserviceaccount
2.6.4. 유지 관리 CLI 명령
2.6.4.1. migrate
사용된 하위 명령에 따라 클러스터의 리소스를 새 버전 또는 형식으로 마이그레이션합니다.
예제: 저장된 모든 오브젝트 업데이트 수행
$ oc adm migrate storage
예제: Pod만 업데이트 수행
$ oc adm migrate storage --include=pods
2.6.4.2. prune
서버에서 이전 버전의 리소스를 제거합니다.
예제: 빌드 구성이 더 이상 존재하지 않는 빌드를 포함하여 이전 빌드 정리
$ oc adm prune builds --orphans
2.6.5. 구성 CLI 명령
2.6.5.1. create-bootstrap-project-template
부트스트랩 프로젝트 템플릿을 생성합니다.
예제: YAML 형식으로 부트스트랩 프로젝트 템플릿을 stdout로 출력
$ oc adm create-bootstrap-project-template -o yaml
2.6.5.2. create-error-template
오류 페이지를 사용자 정의할 템플릿을 생성합니다.
예제: 오류 페이지의 템플릿을 stdout로 출력
$ oc adm create-error-template
2.6.5.3. create-kubeconfig
클라이언트 인증서에서 기본 .kubeconfig
파일을 생성합니다.
예제: 제공된 클라이언트 인증서로 .kubeconfig
파일 생성
$ oc adm create-kubeconfig \ --client-certificate=/path/to/client.crt \ --client-key=/path/to/client.key \ --certificate-authority=/path/to/ca.crt
2.6.5.4. create-login-template
로그인 페이지를 사용자 정의할 템플릿을 생성합니다.
예제: 로그인 페이지의 템플릿을 stdout로 출력
$ oc adm create-login-template
2.6.5.5. create-provider-selection-template
공급자 선택 페이지를 사용자 정의할 템플릿을 생성합니다.
예제: 공급자 선택 페이지 템플릿을 stdout로 출력
$ oc adm create-provider-selection-template
2.6.6. 기타 관리자 CLI 명령
2.6.6.1. build-chain
빌드의 입력 및 종속 항목을 출력합니다.
예제: perl
이미지 스트림의 종속성 출력
$ oc adm build-chain perl
2.6.6.2. 완료
지정된 쉘에 대한 oc adm
명령의 쉘 완료 코드를 출력합니다.
예제: Bash의 oc adm
완료 코드 표시
$ oc adm completion bash
2.6.6.3. config
클라이언트 구성 파일을 관리합니다. 이 명령은 oc config
명령과 동작이 동일합니다.
예제: 현재 설정 표시
$ oc adm config view
예제: 다른 컨텍스트로 전환
$ oc adm config use-context test-context
2.6.6.4. 릴리스
릴리스에 대한 정보 보기 또는 릴리스 콘텐츠 검사와 같은 OpenShift Container Platform 릴리스 프로세스의 다양한 측면을 관리합니다.
예제: 두 릴리스 간에 변경 로그를 생성하고 changelog.md
에 저장
$ oc adm release info --changelog=/tmp/git \ quay.io/openshift-release-dev/ocp-release:4.6.0-rc.7-x86_64 \ quay.io/openshift-release-dev/ocp-release:4.6.4-x86_64 \ > changelog.md
2.6.6.5. verify-image-signature
로컬 공개 GPG 키를 사용하여 내부 레지스트리로 가져온 이미지의 이미지 서명을 확인합니다.
예제: nodejs
이미지 서명 확인
$ oc adm verify-image-signature \ sha256:2bba968aedb7dd2aafe5fa8c7453f5ac36a0b9639f1bf5b03f95de325238b288 \ --expected-identity 172.30.1.1:5000/openshift/nodejs:latest \ --public-key /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \ --save
2.7. oc 및 kubectl 명령 사용
Kubernetes CLI(명령줄 인터페이스), kubectl
은 Kubernetes 클러스터에 대해 명령을 실행하는 데 사용할 수 있습니다. OpenShift Container Platform은 인증된 Kubernetes 배포판이므로 OpenShift Container Platform과 함께 제공된 지원되는 kubectl
바이너리를 사용할 수도 있고 oc
바이너리를 사용하여 확장 기능을 받을 수도 있습니다.
2.7.1. oc 바이너리
oc
바이너리는 kubectl
바이너리와 동일한 기능을 제공하지만 다음을 비롯하여 추가 OpenShift Container Platform 기능을 지원하도록 기본적으로 확장됩니다.
OpenShift Container Platform 리소스 전체 지원
DeploymentConfig
,BuildConfig
,Route
,ImageStream
및ImageStreamTag
오브젝트와 같은 리소스는 OpenShift Container Platform 배포판에 고유하며 표준 Kubernetes 프리미티브에 빌드됩니다.인증
oc
바이너리에서 제공하는 기본login
명령은 인증을 허용하며 Kubernetes 네임스페이스를 인증된 사용자에 매핑하는 OpenShift Container Platform 프로젝트 작업을 지원합니다. 자세한 내용은 인증 이해를 참조하십시오.추가 명령
예를 들어 추가 명령
oc new-app
을 사용하면 기존 소스 코드 또는 미리 빌드된 이미지를 사용하여 새 애플리케이션을 보다 쉽게 시작할 수 있습니다. 마찬가지로, 추가 명령oc new-project
를 사용하면 기본값으로 전환할 수 있는 프로젝트를 보다 쉽게 시작할 수 있습니다.
이전 버전의 oc
바이너리를 설치한 경우 OpenShift Container Platform 4.6의 모든 명령을 완료하는 데 사용할 수 없습니다. 최신 기능을 사용하려면 OpenShift Container Platform 서버 버전에 해당하는 최신 버전의 oc
바이너리를 다운로드하여 설치해야 합니다.
비보안 API 변경에는 이전 oc
바이너리를 업데이트할 수 있도록 최소한 두 개의 마이너 릴리스(예: 4.1-4.2 - 4.3)가 포함됩니다. 새 기능을 사용하려면 최신 oc
바이너리가 필요할 수 있습니다. 4.3 서버에는 4.2 oc
바이너리에서 사용할 수 없는 추가 기능이 있을 수 있으며 4.3 oc
바이너리에 4.2 서버에서 지원하지 않는 추가 기능이 있을 수 있습니다.
XY( |
X.Y+N [a] ( | |
X.Y(서버) |
|
|
X.Y+N [a] (서버) |
|
|
[a]
여기서 N 은 1보다 크거나 같은 숫자입니다.
|
완전하게 호환됩니다.
oc
클라이언트에서 서버 기능에 액세스할 수 없습니다.
oc
클라이언트에서 액세스한 서버와 호환되지 않는 옵션 및 기능을 제공할 수 있습니다.
2.7.2. kubectl 바이너리
kubectl
바이너리는 표준 Kubernetes 환경의 새로운 OpenShift Container Platform 사용자 또는 kubectl
CLI 사용을 선호하는 사용자를 위해 기존 워크플로우 및 스크립트를 지원하는 수단으로 제공됩니다. kubectl
의 기존 사용자는 OpenShift Container Platform 클러스터를 변경할 필요 없이 이 바이너리를 사용하여 Kubernetes 프리미티브와 계속 상호 작용할 수 있습니다.
지원되는 kubectl
바이너리는 OpenShift CLI 설치 단계에 따라 설치할 수 있습니다. kubectl
바이너리는 바이너리를 다운로드한 경우 아카이브에 포함되어 있습니다. RPM을 사용하여 CLI를 설치할 때 이 바이너리가 설치됩니다.
자세한 내용은 kubectl 문서를 참조하십시오.
3장. 개발자 CLI(odo)
3.1. odo
릴리스 노트
3.1.1. odo
버전 2.5.0의 주요 변경 사항 및 개선 사항
-
adler32
해시를 사용하여 각 구성 요소에 대해 고유한 경로를 만듭니다. 리소스 할당을 위해 devfile의 추가 필드를 지원합니다.
- cpuRequest
- cpuLimit
- memoryRequest
- memoryLimit
odo
명령에 추가합니다.deploy 명령을 사용하여 배포된 구성 요소를 제거하려면
delete--deploy
플래그를 odo$ odo delete --deploy
-
odo link
명령에 매핑 지원 추가 -
볼륨 구성 요소의
임시
필드를 사용하여 임시볼륨
지원 -
Telemetry 옵트인을 요청할 때 기본 답변을
yes
로 설정합니다. - devfile 레지스트리로 추가 Telemetry 데이터를 전송하여 지표 개선
-
부트스트랩 이미지를
registry.access.redhat.com/ocp-tools-4/odo-init-container-rhel8:1.1.11로 업데이트합니다.
- 업스트림 리포지토리는 https://github.com/redhat-developer/odo에서 사용할 수 있습니다.
3.1.2. 버그 수정
-
이전에는
.odo/env
파일이 없으면odo deploy
가 실패했습니다. 필요한 경우 이 명령은.odo/env
파일을 생성합니다. -
이전에는 클러스터에서 연결을 끊으면
odo create
명령을 사용한 대화형 구성 요소 생성에 실패했습니다. 이 문제는 최신 릴리스에서 해결되었습니다.
3.1.3. 지원 요청
제품의 경우
오류를 발견하거나, 버그가 발생하거나, odo
의 기능 개선을 위한 제안 사항이 있는 경우 Bugzilla에 문제를 제출합니다. Red Hat odo for OpenShift Container Platform 제품 유형을 선택합니다.
문제 설명에 가능한 한 많은 세부 정보를 제공합니다.
문서의 경우
오류를 발견하거나 문서 개선을 위한 제안 사항이 있는 경우 가장 관련 있는 문서 구성 요소에 대한 Jira 문제를 제출하십시오.
3.2. odo 이해
Red Hat OpenShift Developer CLI(odo
)는 OpenShift Container Platform 및 Kubernetes에서 애플리케이션을 생성하는 툴입니다. odo
를 사용하면 플랫폼을 깊이 이해하지 못해도 Kubernetes 클러스터에서 마이크로서비스 기반 애플리케이션을 개발, 테스트, 디버그, 배포할 수 있습니다.
odo
는 생성 및 푸시 워크플로를 따릅니다. 사용자가 를 생성할 때 정보(또는 매니페스트)가 구성 파일에 저장됩니다. 를 푸시 하면 Kubernetes 클러스터에 해당 리소스가 생성됩니다. 이 모든 구성은 원활한 접근성 및 기능을 위해 Kubernetes API에 저장됩니다.
odo
는 service 및 link 명령을 사용하여 구성 요소 및 서비스를 연결합니다. odo
는 클러스터의 Kubernetes Operator를 기반으로 서비스를 생성하고 배포하여 이를 수행합니다. Operator Hub에서 사용 가능한 Operator를 사용하여 서비스를 생성할 수 있습니다. 서비스를 연결한 후 odo
는 서비스 구성을 구성 요소에 삽입합니다. 그러면 애플리케이션에서 이 구성을 사용하여 Operator 지원 서비스와 통신할 수 있습니다.
3.2.1. odo 주요 기능
odo
는 다음과 같은 기능을 통해 개발자에게 친숙한 Kubernetes 인터페이스로 설계되었습니다.
- 새 매니페스트를 생성하거나 기존 매니페스트를 사용하여 Kubernetes 클러스터에 애플리케이션을 빠르게 배포합니다.
- Kubernetes 구성 파일을 이해하고 유지 관리할 필요 없이 명령을 사용하여 매니페스트를 쉽게 생성하고 업데이트합니다.
- Kubernetes 클러스터에서 실행되는 애플리케이션에 대한 보안 액세스 제공
- Kubernetes 클러스터에서 애플리케이션의 추가 스토리지 추가 및 제거
- Operator 지원 서비스를 생성하고 애플리케이션을 연결합니다.
-
odo
구성 요소로 배포된 여러 마이크로 서비스 간 링크 생성 -
IDE에서
odo
를 사용하여 배포한 원격 애플리케이션 디버깅 -
odo
를 사용하여 Kubernetes에 배포된 애플리케이션을 쉽게 테스트
3.2.2. odo 핵심 개념
odo
는 Kubernetes 개념을 개발자에게 친숙한 용어로 요약합니다.
- 애플리케이션
특정 작업을 수행하는 데 사용되는 클라우드 네이티브 접근 방식으로 개발된 일반적인 애플리케이션입니다.
애플리케이션의 예로는 온라인 비디오 스트리밍, 온라인 구매 및 호텔 예약 시스템이 있습니다.
- 구성 요소
별도로 실행하고 배포할 수 있는 Kubernetes 리소스 집합입니다. 클라우드 네이티브 애플리케이션은 작고 독립적이며 느슨하게 연결된 구성 요소의 컬렉션입니다.
구성 요소의 예로는 API 백엔드, 웹 인터페이스, 결제 백엔드가 포함됩니다.
- 프로젝트
- 소스 코드, 테스트 및 라이브러리가 포함된 단일 단위입니다.
- 컨텍스트
-
단일 구성 요소에 대한 소스 코드, 테스트, 라이브러리 및
odo
구성 파일이 포함된 디렉터리입니다. - URL
- 클러스터 외부에서 액세스할 수 있는 구성 요소를 노출하는 메커니즘입니다.
- 스토리지
- 클러스터의 영구 스토리지. 다시 시작해도 데이터를 유지하고 구성 요소를 다시 빌드합니다.
- Service
구성 요소에 추가 기능을 제공하는 외부 애플리케이션입니다.
서비스의 예로는 PostgreSQL, MySQL, Redis 및 RabbitMQ가 있습니다.
odo
에서는 서비스가 OpenShift 서비스 카탈로그에서 프로비저닝되며, 클러스터 내에서 활성화되어야 합니다.- devfile
개발자 툴에서 워크플로를 단순화하고 가속화할 수 있도록 컨테이너화된 개발 환경을 정의하기 위한 오픈 표준입니다. 자세한 내용은 https://devfile.io 의 문서를 참조하십시오.
공개적으로 사용 가능한 devfile 레지스트리에 연결하거나 보안 레지스트리를 설치할 수 있습니다.
3.2.3. odo의 구성 요소 나열
odo
는 이식 가능한 devfile 형식을 사용하여 구성 요소 및 관련 URL, 스토리지 및 서비스를 설명합니다. odo
는 다양한 devfile 레지스트리에 연결하여 다양한 언어 및 프레임워크의 devfile을 다운로드할 수 있습니다. odo
에서 devfile 정보를 검색하는 데 사용하는 레지스트리를 관리하는 방법에 대한 자세한 내용은 odo registry
명령 설명서를 참조하십시오.
odo catalog list components
명령을 사용하여 다양한 레지스트리에서 사용할 수 있는 devfile 을 모두 나열할 수 있습니다.
절차
odo
를 사용하여 클러스터에 로그인합니다.$ odo login -u developer -p developer
사용 가능한
odo
구성 요소를 나열합니다.$ odo catalog list components
출력 예
Odo Devfile Components: NAME DESCRIPTION REGISTRY dotnet50 Stack with .NET 5.0 DefaultDevfileRegistry dotnet60 Stack with .NET 6.0 DefaultDevfileRegistry dotnetcore31 Stack with .NET Core 3.1 DefaultDevfileRegistry go Stack with the latest Go version DefaultDevfileRegistry java-maven Upstream Maven and OpenJDK 11 DefaultDevfileRegistry java-openliberty Java application Maven-built stack using the Open Liberty ru... DefaultDevfileRegistry java-openliberty-gradle Java application Gradle-built stack using the Open Liberty r... DefaultDevfileRegistry java-quarkus Quarkus with Java DefaultDevfileRegistry java-springboot Spring Boot® using Java DefaultDevfileRegistry java-vertx Upstream Vert.x using Java DefaultDevfileRegistry java-websphereliberty Java application Maven-built stack using the WebSphere Liber... DefaultDevfileRegistry java-websphereliberty-gradle Java application Gradle-built stack using the WebSphere Libe... DefaultDevfileRegistry java-wildfly Upstream WildFly DefaultDevfileRegistry java-wildfly-bootable-jar Java stack with WildFly in bootable Jar mode, OpenJDK 11 and... DefaultDevfileRegistry nodejs Stack with Node.js 14 DefaultDevfileRegistry nodejs-angular Stack with Angular 12 DefaultDevfileRegistry nodejs-nextjs Stack with Next.js 11 DefaultDevfileRegistry nodejs-nuxtjs Stack with Nuxt.js 2 DefaultDevfileRegistry nodejs-react Stack with React 17 DefaultDevfileRegistry nodejs-svelte Stack with Svelte 3 DefaultDevfileRegistry nodejs-vue Stack with Vue 3 DefaultDevfileRegistry php-laravel Stack with Laravel 8 DefaultDevfileRegistry python Python Stack with Python 3.7 DefaultDevfileRegistry python-django Python3.7 with Django DefaultDevfileRegistry
3.2.4. odo에서 Telemetry
는 운영 체제, RAM, CPU, 코어 수, odo
odo
버전, 오류, 성공/실패, 완료하는 데 걸리는 기간을 포함하여 사용 중인 방법에 대한 정보를 수집합니다.
odo preference
명령을 사용하여 Telemetry 동의를 수정할 수 있습니다.
-
odo preference set ConsentTelemetry true
로 Telemetry에 동의합니다. -
odo preference unset ConsentTelemetry
는 Telemetry를 비활성화합니다. -
odo preference 뷰에
는 현재 기본 설정이 표시됩니다.
3.3. odo 설치
바이너리를 다운로드하여 Linux, Windows 또는 macOS에 odo
CLI를 설치할 수 있습니다. odo
및 oc
바이너리를 사용하여 OpenShift Container Platform 클러스터와 상호 작용하는 OpenShift VS Code 확장 기능을 설치할 수도 있습니다. RHEL(Red Hat Enterprise Linux)의 경우 odo
CLI를 RPM으로 설치할 수 있습니다.
현재 제한된 네트워크 환경에서는 odo
가 설치를 지원하지 않습니다.
3.3.1. Linux에 odo 설치
odo
CLI는 다음을 포함하여 여러 운영 체제 및 아키텍처의 tarball로 다운로드할 수 있습니다.
운영 체제 | 바이너리 | tarball |
---|---|---|
Linux | ||
Linux on IBM Power | ||
Linux on IBM Z 및 LinuxONE |
절차
콘텐츠 게이트웨이로 이동하여 운영 체제 및 아키텍처에 적절한 파일을 다운로드합니다.
바이너리를 다운로드하는 경우
odo
로 이름을 바꿉니다.$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-linux-amd64 -o odo
tarball을 다운로드하는 경우 바이너리를 추출합니다.
$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-linux-amd64.tar.gz -o odo.tar.gz $ tar xvzf odo.tar.gz
바이너리의 권한을 변경합니다.
$ chmod +x <filename>
odo
바이너리를PATH에 있는 디렉터리에 배치합니다
.PATH
를 확인하려면 다음 명령을 실행합니다.$ echo $PATH
시스템에서
odo
를 사용할 수 있는지 확인합니다.$ odo version
3.3.2. Windows에 odo 설치
Windows용 odo
CLI는 바이너리 및 아카이브로 다운로드할 수 있습니다.
운영 체제 | 바이너리 | tarball |
---|---|---|
Windows |
절차
콘텐츠 게이트웨이로 이동하여 적절한 파일을 다운로드합니다.
-
바이너리를 다운로드하는 경우
odo.exe
로 이름을 바꿉니다. -
아카이브를 다운로드하는 경우 ZIP 프로그램으로 바이너리의 압축을 풀고
odo.exe
로 이름을 바꿉니다.
-
바이너리를 다운로드하는 경우
odo.exe
바이너리를PATH에 있는 디렉터리로 이동합니다
.PATH
를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.C:\> path
시스템에서
odo
를 사용할 수 있는지 확인합니다.C:\> odo version
3.3.3. macOS에 odo 설치
macOS용 odo
CLI는 바이너리 및 tarball로 다운로드할 수 있습니다.
운영 체제 | 바이너리 | tarball |
---|---|---|
macOS |
절차
콘텐츠 게이트웨이로 이동하여 적절한 파일을 다운로드합니다.
바이너리를 다운로드하는 경우
odo
로 이름을 바꿉니다.$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64 -o odo
tarball을 다운로드하는 경우 바이너리를 추출합니다.
$ curl -L https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64.tar.gz -o odo.tar.gz $ tar xvzf odo.tar.gz
바이너리의 권한을 변경합니다.
# chmod +x odo
odo
바이너리를PATH에 있는 디렉터리에 배치합니다
.PATH
를 확인하려면 다음 명령을 실행합니다.$ echo $PATH
시스템에서
odo
를 사용할 수 있는지 확인합니다.$ odo version
3.3.4. VS Code에 odo 설치
OpenShift VS Code 확장에서는 OpenShift Container Platform 클러스터와 상호 작용하는 데 odo
및 oc
바이너리를 둘 다 사용합니다. 이러한 기능으로 작업하려면 VS Code에 OpenShift VS Code 확장을 설치하십시오.
사전 요구 사항
- VS Code가 설치되어 있어야 합니다.
절차
- VS Code를 엽니다.
-
Ctrl
+P
로 VS Code Quick Open을 시작합니다. 다음 명령을 실행합니다.
$ ext install redhat.vscode-openshift-connector
3.3.5. RPM을 사용하여 RHEL(Red Hat Enterprise Linux)에 odo 설치
RHEL(Red Hat Enterprise Linux)의 경우 odo
CLI를 RPM으로 설치할 수 있습니다.
절차
Red Hat Subscription Manager에 등록합니다.
# subscription-manager register
최신 서브스크립션 데이터를 가져옵니다.
# subscription-manager refresh
사용 가능한 서브스크립션을 나열하십시오.
# subscription-manager list --available --matches '*OpenShift Developer Tools and Services*'
이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의
Pool ID
를 찾아서 이 서브스크립션을 등록된 시스템에 연결합니다.# subscription-manager attach --pool=<pool_id>
odo
에 필요한 리포지토리를 활성화합니다.# subscription-manager repos --enable="ocp-tools-4.9-for-rhel-8-x86_64-rpms"
odo
패키지를 설치합니다.# yum install odo
시스템에서
odo
를 사용할 수 있는지 확인합니다.$ odo version
3.4. odo CLI 구성
기본적으로 $HOME/.odo
디렉터리에 있는 preference.yaml
파일에서 odo
의 글로벌 설정을 찾을 수 있습니다.
GLOBALODOCONFIG
변수를 내보내서 preference.yaml
파일의 다른 위치를 설정할 수 있습니다.
3.4.1. 현재 구성 보기
다음 명령을 사용하여 현재 odo
CLI 구성을 볼 수 있습니다.
$ odo preference view
출력 예
PARAMETER CURRENT_VALUE UpdateNotification NamePrefix Timeout BuildTimeout PushTimeout Ephemeral ConsentTelemetry true
3.4.2. 값 설정
다음 명령을 사용하여 기본 키의 값을 설정할 수 있습니다.
$ odo preference set <key> <value>
기본 설정 키는 대소문자를 구분하지 않습니다.
명령 예
$ odo preference set updatenotification false
출력 예
Global preference was successfully updated
3.4.3. 값 설정 해제
다음 명령을 사용하여 기본 키의 값을 설정 해제할 수 있습니다.
$ odo preference unset <key>
-f
플래그를 사용하여 확인을 건너뛸 수 있습니다.
명령 예
$ odo preference unset updatenotification ? Do you want to unset updatenotification in the preference (y/N) y
출력 예
Global preference was successfully updated
3.4.4. 기본 설정 키 테이블
다음 표는 odo
CLI에 기본 키를 설정하는 데 사용할 수 있는 옵션을 보여줍니다.
기본 설정 키 | 설명 | 기본값 |
---|---|---|
|
| True |
|
| 현재 디렉터리 이름 |
| Kubernetes 서버 연결 확인에 대한 타임아웃입니다. | 1초 |
| git 구성 요소 빌드가 완료될 때까지 대기하는 시간 초과 | 300초 |
| 구성 요소가 시작될 때까지 대기하는 시간 초과입니다. | 240초 |
|
소스 코드를 저장하기 위해 | True |
|
odo가 사용자의 | False |
3.4.5. 파일 또는 패턴 무시
애플리케이션 root 디렉터리의 .odoignore
파일을 수정하여 무시할 파일 또는 패턴 목록을 구성할 수 있습니다. 이 파일은 odo push
및 odo watch
둘 다에 적용됩니다.
.odoignore
파일이 없으면 특정 파일 및 폴더를 무시하는 데 .gitignore
파일이 대신 사용됩니다.
.git
파일, .js
확장자가 있는 모든 파일 및 tests
폴더를 무시하려면 .odoignore
또는 .gitignore
파일에 다음을 추가합니다.
.git *.js tests/
.odoignore
파일에는 모든 glob 표현식을 사용할 수 있습니다.
3.5. odo CLI 참조
3.5.1. odo build-images
odo
는 Dockerfile을 기반으로 컨테이너 이미지를 빌드하고 이러한 이미지를 레지스트리에 푸시할 수 있습니다.
odo build-images
명령을 실행할 때 odo
는 이미지
유형을 사용하여 devfile.yaml
의 모든 구성 요소를 검색합니다. 예를 들면 다음과 같습니다.
components: - image: imageName: quay.io/myusername/myimage dockerfile: uri: ./Dockerfile 1 buildContext: ${PROJECTS_ROOT} 2 name: component-built-from-dockerfile
각 이미지 구성 요소에 대해 odo는 podman
또는 docker
(이 순서대로 발견된 첫 번째)를 실행하여 지정된 Dockerfile, 빌드 컨텍스트 및 인수를 사용하여 이미지를 빌드합니다.
--push
플래그가 명령에 전달되면 이미지가 빌드 후 해당 레지스트리로 푸시됩니다.
3.5.2. odo catalog
odo
는 다양한 카탈로그 를 사용하여 구성 요소 및 서비스를 배포합니다.
3.5.2.1. components
odo
는 이식 가능한 devfile 형식을 사용하여 구성 요소를 설명합니다. 다양한 devfile 레지스트리에 연결하여 다양한 언어 및 프레임워크에 대한 devfile을 다운로드할 수 있습니다. 자세한 내용은 odo
Registry를 참조하십시오.
3.5.2.1.1. 구성 요소 나열
다른 레지스트리에서 사용 가능한 모든 devfile 을 나열하려면 명령을 실행합니다.
$ odo catalog list components
출력 예
NAME DESCRIPTION REGISTRY go Stack with the latest Go version DefaultDevfileRegistry java-maven Upstream Maven and OpenJDK 11 DefaultDevfileRegistry nodejs Stack with Node.js 14 DefaultDevfileRegistry php-laravel Stack with Laravel 8 DefaultDevfileRegistry python Python Stack with Python 3.7 DefaultDevfileRegistry [...]
3.5.2.1.2. 구성 요소에 대한 정보 가져오기
특정 구성 요소에 대한 자세한 내용을 보려면 명령을 실행합니다.
$ odo catalog describe component
예를 들어 다음 명령을 실행합니다.
$ odo catalog describe component nodejs
출력 예
* Registry: DefaultDevfileRegistry 1 Starter Projects: 2 --- name: nodejs-starter attributes: {} description: "" subdir: "" projectsource: sourcetype: "" git: gitlikeprojectsource: commonprojectsource: {} checkoutfrom: null remotes: origin: https://github.com/odo-devfiles/nodejs-ex.git zip: null custom: null
starter 프로젝트에서 프로젝트를 생성하는 방법에 대한 자세한 내용은 odo create
를 참조하십시오.
3.5.2.2. 서비스
odo
는 Operator 의 도움을 받아 서비스를 배포할 수 있습니다.
Operator Lifecycle Manager 를 사용하여 배포된 Operator만 odo에서 지원됩니다.
3.5.2.2.1. 서비스 나열
사용 가능한 Operator 및 관련 서비스를 나열하려면 명령을 실행합니다.
$ odo catalog list services
출력 예
Services available through Operators NAME CRDs postgresql-operator.v0.1.1 Backup, Database redis-operator.v0.8.0 RedisCluster, Redis
이 예에서는 클러스터에 두 개의 Operator가 설치되어 있습니다. postgresql-operator.v0.1.1
Operator는 PostgreSQL과 관련된 서비스를 배포합니다. 백업
및 데이터베이스
. redis-operator.v0.8.0
Operator는 Redis와 관련된 서비스를 배포합니다. RedisCluster
및 Redis
.
사용 가능한 모든 Operator 목록을 가져오기 위해 odo
는 Succeeded 단계에 있는 현재 네임스페이스의 CSV(ClusterServiceVersion) 리소스를 가져옵니다. 클러스터 전체 액세스를 지원하는 Operator의 경우 새 네임스페이스가 생성되면 해당 리소스가 자동으로 추가됩니다. 그러나 성공 단계에 있을 때까지 다소 시간이 걸릴 수 있으며 odo
는 리소스가 준비될 때까지 빈 목록을 반환할 수 있습니다.
3.5.2.2.2. 서비스 검색
키워드로 특정 서비스를 검색하려면 명령을 실행합니다.
$ odo catalog search service
예를 들어 PostgreSQL 서비스를 검색하려면 명령을 실행합니다.
$ odo catalog search service postgres
출력 예
Services available through Operators NAME CRDs postgresql-operator.v0.1.1 Backup, Database
해당 이름에 searched 키워드가 포함된 Operator 목록이 표시됩니다.
3.5.2.2.3. 서비스에 대한 정보 얻기
특정 서비스에 대한 자세한 내용을 보려면 명령을 실행합니다.
$ odo catalog describe service
예를 들면 다음과 같습니다.
$ odo catalog describe service postgresql-operator.v0.1.1/Database
출력 예
KIND: Database VERSION: v1alpha1 DESCRIPTION: Database is the Schema for the the Database Database API FIELDS: awsAccessKeyId (string) AWS S3 accessKey/token ID Key ID of AWS S3 storage. Default Value: nil Required to create the Secret with the data to allow send the backup files to AWS S3 storage. [...]
서비스는 CRD(CustomResourceDefinition) 리소스로 클러스터로 표시됩니다. 이전 명령은 이 사용자 정의 리소스의 인스턴스를 정의하는 데 사용할 수 있는 종류
,버전
, 필드 목록과 같은 CRD에 대한 세부 정보를 표시합니다.
필드 목록은 CRD에 포함된 OpenAPI 스키마 에서 추출됩니다. 이 정보는 CRD에서 선택 사항이며, 없는 경우 서비스를 나타내는 CSV(ClusterServiceVersion) 리소스에서 추출됩니다.
CRD 유형 정보를 제공하지 않고 Operator 지원 서비스에 대한 설명을 요청할 수도 있습니다. CRD 없이 클러스터에서 Redis Operator를 설명하려면 다음 명령을 실행합니다.
$ odo catalog describe service redis-operator.v0.8.0
출력 예
NAME: redis-operator.v0.8.0 DESCRIPTION: A Golang based redis operator that will make/oversee Redis standalone/cluster mode setup on top of the Kubernetes. It can create a redis cluster setup with best practices on Cloud as well as the Bare metal environment. Also, it provides an in-built monitoring capability using ... (cut short for beverity) Logging Operator is licensed under [Apache License, Version 2.0](https://github.com/OT-CONTAINER-KIT/redis-operator/blob/master/LICENSE) CRDs: NAME DESCRIPTION RedisCluster Redis Cluster Redis Redis
3.5.3. odo create
odo
는 devfile 을 사용하여 구성 요소의 구성을 저장하고 스토리지 및 서비스와 같은 구성 요소의 리소스를 설명합니다. odo create 명령은 이 파일을 생성합니다.
3.5.3.1. 구성 요소 생성
기존 프로젝트에 대한 devfile 을 생성하려면 구성 요소의 이름 및 유형으로 odo create
명령을 실행합니다(예: nodejs
또는 go
).
odo create nodejs mynodejs
예제에서 nodejs
는 구성 요소의 유형이며, mynodejs
는 odo
가 생성하는 구성 요소의 이름입니다.
지원되는 모든 구성 요소 유형 목록을 보려면 odo catalog list components
명령을 실행합니다.
소스 코드가 현재 디렉터리 외부에 있는 경우 --context
플래그를 사용하여 경로를 지정할 수 있습니다. 예를 들어 nodejs 구성 요소의 소스가 현재 작업 디렉터리를 기준으로 node-backend
라는 폴더에 있는 경우 명령을 실행합니다.
odo create nodejs mynodejs --context ./node-backend
--context
플래그는 상대 경로 및 절대 경로를 지원합니다.
구성 요소가 배포될 프로젝트 또는 앱을 지정하려면 --project
및 --app
플래그를 사용합니다. 예를 들어 backend
프로젝트 내의 myapp
앱의 일부인 구성 요소를 생성하려면 명령을 실행합니다.
odo create nodejs --app myapp --project backend
이러한 플래그를 지정하지 않으면 기본적으로 활성 앱 및 프로젝트로 설정됩니다.
3.5.3.2. 시작 프로젝트
기존 소스 코드가 없지만 devfile 및 구성 요소를 실험하기 위해 빠르게 실행하려는 경우 시작 프로젝트를 사용합니다. 시작 프로젝트를 사용하려면 --starter
플래그를 odo create
명령에 추가합니다.
구성 요소 유형에 사용 가능한 시작 프로젝트 목록을 가져오려면 odo catalog describe component
명령을 실행합니다. 예를 들어 nodejs 구성 요소 유형에 사용 가능한 모든 시작 프로젝트를 가져오려면 명령을 실행합니다.
odo catalog describe component nodejs
그런 다음 odo create
명령에서 --starter
플래그를 사용하여 원하는 프로젝트를 지정합니다.
odo create nodejs --starter nodejs-starter
이렇게 하면 선택한 구성 요소 유형(이 인스턴스에서 nodejs
)에 해당하는 예제 템플릿이 다운로드됩니다. 템플릿은 현재 디렉터리 또는 --context
플래그로 지정된 위치로 다운로드됩니다. 시작 프로젝트에 자체 devfile이 있는 경우 이 devfile은 유지됩니다.
3.5.3.3. 기존 devfile 사용
기존 devfile에서 새 구성 요소를 생성하려면 --devfile
플래그를 사용하여 devfile에 대한 경로를 지정하여 이를 수행할 수 있습니다. 예를 들어 GitHub의 devfile을 기반으로 mynodejs
라는 구성 요소를 생성하려면 다음 명령을 사용합니다.
odo create mynodejs --devfile https://raw.githubusercontent.com/odo-devfiles/registry/master/devfiles/nodejs/devfile.yaml
3.5.3.4. 대화형 생성
odo create
명령을 대화식으로 실행하여 구성 요소를 생성하는 데 필요한 단계를 안내할 수도 있습니다.
$ odo create
? Which devfile component type do you wish to create go
? What do you wish to name the new devfile component go-api
? What project do you want the devfile component to be created in default
Devfile Object Validation
✓ Checking devfile existence [164258ns]
✓ Creating a devfile component from registry: DefaultDevfileRegistry [246051ns]
Validation
✓ Validating if devfile name is correct [92255ns]
? Do you want to download a starter project Yes
Starter Project
✓ Downloading starter project go-starter from https://github.com/devfile-samples/devfile-stack-go.git [429ms]
Please use odo push
command to create the component with source deployed
구성 요소 유형, 이름 및 구성 요소에 대한 프로젝트를 선택하라는 메시지가 표시됩니다. starter 프로젝트를 다운로드할지 여부를 선택할 수도 있습니다. 완료되면 작업 디렉터리에 새 devfile.yaml
파일이 생성됩니다.
이러한 리소스를 클러스터에 배포하려면 odo push
명령을 실행합니다.
3.5.4. odo delete
odo delete
명령은 odo
에서 관리하는 리소스를 삭제하는 데 유용합니다.
3.5.4.1. 구성 요소 삭제
devfile 구성 요소를 삭제하려면 odo delete
명령을 실행합니다.
$ odo delete
구성 요소가 클러스터로 푸시되면 종속 스토리지, URL, 시크릿 및 기타 리소스와 함께 구성 요소가 클러스터에서 삭제됩니다. 구성 요소를 푸시하지 않은 경우 명령은 클러스터에서 리소스를 찾을 수 없다는 오류와 함께 종료됩니다.
확인 질문을 방지하려면 -f
또는 --force
플래그를 사용합니다.
3.5.4.2. devfile Kubernetes 구성 요소 배포
odo deploy
를 사용하여 배포된 devfile Kubernetes 구성 요소 배포를 취소하려면 --deploy
플래그를 사용하여 odo delete
명령을 실행합니다.
$ odo delete --deploy
확인 질문을 방지하려면 -f
또는 --force
플래그를 사용합니다.
3.5.4.3. 모두 삭제
다음 항목을 포함한 모든 아티팩트를 삭제하려면 --all
플래그를 사용하여 odo delete
명령을 실행합니다.
- devfile 구성 요소
-
odo deploy
명령을 사용하여 배포된 devfile Kubernetes 구성 요소 - devfile
- 로컬 구성
$ odo delete --all
3.5.4.4. 사용 가능한 플래그
-f
,--force
- 확인 질문을 방지하려면 이 플래그를 사용합니다.
-w
,--wait
- 이 플래그를 사용하여 구성 요소를 삭제하고 종속성을 기다립니다. 이 플래그는 배포 취소 시 작동하지 않습니다.
Common Flags 에 대한 설명서는 명령에 사용 가능한 플래그에 대한 자세한 정보를 제공합니다.
3.5.5. odo deploy
odo
는 CI/CD 시스템을 사용하여 배포되는 방식과 유사한 방식으로 구성 요소를 배포하는 데 사용할 수 있습니다. 먼저 odo
는 컨테이너 이미지를 빌드한 다음 구성 요소를 배포하는 데 필요한 Kubernetes 리소스를 배포합니다.
odo deploy
명령을 실행할 때odo
는 devfile에서 deploy
의 기본 명령을 검색하고 이 명령을 실행합니다. kind deploy
는 버전 2.2.0부터 devfile 형식에서 지원됩니다.
deploy
명령은 일반적으로 몇 가지 apply 명령으로 구성된 복합 명령입니다.
-
이미지
구성 요소를 참조하는 명령은 배포할 컨테이너 이미지를 빌드한 다음 해당 레지스트리로 내보냅니다. - Kubernetes 구성 요소를 참조하는 명령은 클러스터에 Kubernetes 리소스를 생성합니다.
다음 예제 devfile.yaml
파일을 사용하면 디렉터리에 있는 Dockerfile
을 사용하여 컨테이너 이미지가 빌드됩니다. 이미지는 레지스트리로 푸시된 다음 이 새로 빌드된 이미지를 사용하여 클러스터에 Kubernetes 배포 리소스가 생성됩니다.
schemaVersion: 2.2.0 [...] variables: CONTAINER_IMAGE: quay.io/phmartin/myimage commands: - id: build-image apply: component: outerloop-build - id: deployk8s apply: component: outerloop-deploy - id: deploy composite: commands: - build-image - deployk8s group: kind: deploy isDefault: true components: - name: outerloop-build image: imageName: "{{CONTAINER_IMAGE}}" dockerfile: uri: ./Dockerfile buildContext: ${PROJECTS_ROOT} - name: outerloop-deploy kubernetes: inlined: | kind: Deployment apiVersion: apps/v1 metadata: name: my-component spec: replicas: 1 selector: matchLabels: app: node-app template: metadata: labels: app: node-app spec: containers: - name: main image: {{CONTAINER_IMAGE}}
3.5.6. odo link
odo link
명령은 odo
구성 요소를 Operator 지원 서비스 또는 다른 odo
구성 요소에 연결하는 데 도움이 됩니다. Service Binding Operator 를 사용하여 이 작업을 수행합니다. 현재 odo
는 Service Binding 라이브러리를 사용하며 Operator 자체가 원하는 기능을 수행하지 않습니다.
3.5.6.1. 다양한 연결 옵션
odo
는 구성 요소를 Operator 지원 서비스 또는 다른 odo
구성 요소와 연결하는 다양한 옵션을 제공합니다. 이러한 모든 옵션(또는 플래그)은 구성 요소를 서비스 또는 다른 구성 요소에 연결하는지 여부에 관계없이 사용할 수 있습니다.
3.5.6.1.1. 기본 동작
기본적으로 odo link
명령은 구성 요소 디렉터리에 kubernetes/
라는 디렉터리를 생성하고 서비스 및 링크에 대한 정보(YAML 매니페스트)를 저장합니다. odo push
를 사용하는 경우odo
는 이러한 매니페스트를 Kubernetes 클러스터의 리소스 상태와 비교하고 사용자가 지정한 내용과 일치하도록 리소스를 생성, 수정 또는 삭제해야 하는지 결정합니다.
3.5.6.1.2. --inlined
플래그
--inlined
플래그를 odo link
명령에 지정하는 경우 odo
는 kubernetes/
디렉터리에 파일을 생성하는 대신 devfile.yaml
의 devfile.yaml에 링크 정보를 저장합니다. --inlined
플래그의 동작은 odo link
및 odo service create
명령 모두에서 유사합니다. 이 플래그는 모든 항목을 단일 devfile.yaml
에 저장하려는 경우 유용합니다. 각 odo link
와 함께 --inlined
플래그를 사용하고 구성 요소에 대해 실행하는 odo service create
명령을 사용해야 합니다.
3.5.6.1.3. --map
플래그
기본적으로 사용 가능한 항목 외에도 구성 요소에 더 많은 바인딩 정보를 추가할 수 있습니다. 예를 들어 구성 요소를 서비스와 연결하고 서비스 사양의 일부 정보를 바인딩하려는 경우 --map
플래그를 사용할 수 있습니다. odo
는 연결 중인 서비스 또는 구성 요소의 사양에 대한 유효성 검사를 수행하지 않습니다. Kubernetes YAML 매니페스트를 편리하게 사용하는 경우에만 이 플래그를 사용하는 것이 좋습니다.
3.5.6.1.4. --bind-as-files
플래그
지금까지 논의된 모든 연결 옵션에 대해 odo
는 바인딩 정보를 환경 변수로 구성 요소에 삽입합니다. 이 정보를 파일로 마운트하려면 --bind-as-files
플래그를 사용할 수 있습니다. 이로 인해 odo
가 바인딩 정보를 구성 요소의 Pod 내의 /bindings
위치에 파일로 삽입합니다. 환경 변수 시나리오와 비교하여 --bind-as-files
를 사용할 때 파일의 이름은 키 뒤에 지정되며 이러한 키의 값은 이러한 파일의 콘텐츠로 저장됩니다.
3.5.6.2. 예제
3.5.6.2.1. 기본 odo link
다음 예에서 백엔드 구성 요소는 기본 odo link
명령을 사용하여 PostgreSQL 서비스와 연결됩니다. 백엔드 구성 요소의 경우 구성 요소 및 서비스가 클러스터로 푸시되었는지 확인합니다.
$ odo list
샘플 출력
APP NAME PROJECT TYPE STATE MANAGED BY ODO app backend myproject spring Pushed Yes
$ odo service list
샘플 출력
NAME MANAGED BY ODO STATE AGE PostgresCluster/hippo Yes (backend) Pushed 59m41s
이제 odo 링크를
실행하여 백엔드 구성 요소를 PostgreSQL 서비스와 연결합니다.
$ odo link PostgresCluster/hippo
출력 예
✓ Successfully created link between component "backend" and service "PostgresCluster/hippo" To apply the link, please use `odo push`
그런 다음 odo push
를 실행하여 실제로 Kubernetes 클러스터에 링크를 생성합니다.
odo push
가 성공하면 다음과 같은 몇 가지 결과가 나타납니다.
백엔드 구성 요소에서 배포한 애플리케이션의 URL을 열면 데이터베이스에 할 일
항목
목록이 표시됩니다. 예를 들어odo url list
명령의 출력에서 polkit이나열되는
경로가 포함됩니다.$ odo url list
샘플 출력
Found the following URLs for component backend NAME STATE URL PORT SECURE KIND 8080-tcp Pushed http://8080-tcp.192.168.39.112.nip.io 8080 false ingress
URL의 올바른 경로는 http://8080-tcp.192.168.39.112.nip.io/api/v1/todos입니다. 정확한 URL은 설정에 따라 다릅니다. 또한 일부 항목을 추가하지 않는 한 데이터베이스에
todos
가 없으므로 URL에 빈 JSON 오브젝트만 표시될 수 있습니다.백엔드 구성 요소에 삽입된 Postgres 서비스와 관련된 바인딩 정보를 확인할 수 있습니다. 이 바인딩 정보는 기본적으로 환경 변수로 삽입됩니다. backend 구성 요소의 디렉터리에서
odo describe
명령을 사용하여 확인할 수 있습니다.$ odo describe
출력 예:
Component Name: backend Type: spring Environment Variables: · PROJECTS_ROOT=/projects · PROJECT_SOURCE=/projects · DEBUG_PORT=5858 Storage: · m2 of size 3Gi mounted to /home/user/.m2 URLs: · http://8080-tcp.192.168.39.112.nip.io exposed via 8080 Linked Services: · PostgresCluster/hippo Environment Variables: · POSTGRESCLUSTER_PGBOUNCER-EMPTY · POSTGRESCLUSTER_PGBOUNCER.INI · POSTGRESCLUSTER_ROOT.CRT · POSTGRESCLUSTER_VERIFIER · POSTGRESCLUSTER_ID_ECDSA · POSTGRESCLUSTER_PGBOUNCER-VERIFIER · POSTGRESCLUSTER_TLS.CRT · POSTGRESCLUSTER_PGBOUNCER-URI · POSTGRESCLUSTER_PATRONI.CRT-COMBINED · POSTGRESCLUSTER_USER · pgImage · pgVersion · POSTGRESCLUSTER_CLUSTERIP · POSTGRESCLUSTER_HOST · POSTGRESCLUSTER_PGBACKREST_REPO.CONF · POSTGRESCLUSTER_PGBOUNCER-USERS.TXT · POSTGRESCLUSTER_SSH_CONFIG · POSTGRESCLUSTER_TLS.KEY · POSTGRESCLUSTER_CONFIG-HASH · POSTGRESCLUSTER_PASSWORD · POSTGRESCLUSTER_PATRONI.CA-ROOTS · POSTGRESCLUSTER_DBNAME · POSTGRESCLUSTER_PGBOUNCER-PASSWORD · POSTGRESCLUSTER_SSHD_CONFIG · POSTGRESCLUSTER_PGBOUNCER-FRONTEND.KEY · POSTGRESCLUSTER_PGBACKREST_INSTANCE.CONF · POSTGRESCLUSTER_PGBOUNCER-FRONTEND.CA-ROOTS · POSTGRESCLUSTER_PGBOUNCER-HOST · POSTGRESCLUSTER_PORT · POSTGRESCLUSTER_ROOT.KEY · POSTGRESCLUSTER_SSH_KNOWN_HOSTS · POSTGRESCLUSTER_URI · POSTGRESCLUSTER_PATRONI.YAML · POSTGRESCLUSTER_DNS.CRT · POSTGRESCLUSTER_DNS.KEY · POSTGRESCLUSTER_ID_ECDSA.PUB · POSTGRESCLUSTER_PGBOUNCER-FRONTEND.CRT · POSTGRESCLUSTER_PGBOUNCER-PORT · POSTGRESCLUSTER_CA.CRT
이러한 변수 중 일부는 백엔드 구성 요소의
src/main/resources/application.properties
파일에서 사용되어 Java Spring Boot 애플리케이션이 PostgreSQL 데이터베이스 서비스에 연결할 수 있습니다.마지막으로
odo
는 다음 파일이 포함된 백엔드 구성 요소의 디렉터리에kubernetes/
라는 디렉터리를 생성했습니다.$ ls kubernetes odo-service-backend-postgrescluster-hippo.yaml odo-service-hippo.yaml
이러한 파일에는 두 리소스에 대한 정보(YAML 매니페스트)가 포함되어 있습니다.
-
odo-service-hippo.yaml
-odo service create --from-file ../postgrescluster.yaml
명령을 사용하여 생성된 Postgres 서비스입니다. -
odo-service-backend-postgrescluster-hippo.yaml
-odo link
명령을 사용하여 생성된 링크입니다.
-
3.5.6.2.2. --inlined 플래그로 odo 링크 사용
--inlined
플래그를 odo link
명령과 함께 사용하면 바인딩 정보를 삽입하는 플래그 없이 odo link
명령과 동일한 효과가 있습니다. 그러나 미묘한 차이점은 위의 경우 kubernetes/
디렉터리에는 두 개의 매니페스트 파일이 있습니다. 하나는 Postgres 서비스용이고 다른 하나는 백엔드 구성 요소와 이 서비스 간의 링크에 대한 것입니다. 그러나 --inlined
플래그를 전달할 때 odo
는 YAML 매니페스트를 저장하기 위해 kubernetes/
디렉터리에 파일을 생성하지 않고 devfile.yaml
파일에 인라인을 저장합니다.
이를 확인하려면 먼저 PostgreSQL 서비스에서 구성 요소를 연결 해제합니다.
$ odo unlink PostgresCluster/hippo
출력 예:
✓ Successfully unlinked component "backend" from service "PostgresCluster/hippo" To apply the changes, please use `odo push`
클러스터에서 연결을 해제하려면 odo push
를 실행합니다. 이제 kubernetes/
디렉터리를 검사하면 하나의 파일만 표시됩니다.
$ ls kubernetes odo-service-hippo.yaml
다음으로 --inlined
플래그를 사용하여 링크를 생성합니다.
$ odo link PostgresCluster/hippo --inlined
출력 예:
✓ Successfully created link between component "backend" and service "PostgresCluster/hippo" To apply the link, please use `odo push`
--inlined
플래그를 생략하는 절차와 같이 클러스터에서 생성되려면 odo push
를 실행해야 합니다. odo
는 devfile.yaml
에 구성을 저장합니다. 이 파일에서 다음과 같은 항목을 볼 수 있습니다.
kubernetes: inlined: | apiVersion: binding.operators.coreos.com/v1alpha1 kind: ServiceBinding metadata: creationTimestamp: null name: backend-postgrescluster-hippo spec: application: group: apps name: backend-app resource: deployments version: v1 bindAsFiles: false detectBindingResources: true services: - group: postgres-operator.crunchydata.com id: hippo kind: PostgresCluster name: hippo version: v1beta1 status: secret: "" name: backend-postgrescluster-hippo
이제 odo unlink PostgresCluster/hippo
를 실행하는 경우odo
는 먼저 devfile.yaml
에서 링크 정보를 제거한 다음 후속 odo push
는 클러스터에서 링크를 삭제합니다.
3.5.6.2.3. 사용자 정의 바인딩
odo link
는 구성 요소에 사용자 정의 바인딩 정보를 삽입할 수 있는 --map
플래그를 허용합니다. 이러한 바인딩 정보는 구성 요소에 연결하는 리소스의 매니페스트에서 가져옵니다. 예를 들어 백엔드 구성 요소 및 PostgreSQL 서비스의 컨텍스트에서 PostgreSQL 서비스의 매니페스트 postgrescluster.yaml
파일의 정보를 백엔드 구성 요소에 삽입할 수 있습니다.
PostgresCluster
서비스의 이름이 hippo
(또는 PostgresCluster 서비스
의 이름이 다르게 지정되는 경우)인 경우 해당 YAML 정의의 postgresVersion
값을 백엔드 구성 요소에 삽입하려면 명령을 실행합니다.
$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}'
Postgres 서비스의 이름이 hippo
와 다른 경우, pgVersion
값으로 .hippo
대신 위의 명령에 해당 이름을 지정해야 합니다.
링크 작업 후 odo push
를 정상적으로 실행합니다. 푸시 작업이 완료되면 백엔드 구성 요소 디렉터리에서 다음 명령을 실행하여 사용자 정의 매핑이 올바르게 삽입되었는지 확인할 수 있습니다.
$ odo exec -- env | grep pgVersion
출력 예:
pgVersion=13
사용자 정의 바인딩 정보를 두 개 이상 삽입하려는 경우 odo link
는 여러 개의 키-값 쌍의 매핑을 허용합니다. 유일한 제약 조건은 이러한 값을 --map <key>=<value>로 지정해야 한다는 것입니다
. 예를 들어, PostgreSQL 이미지 정보를 버전과 함께 삽입하려면 다음을 실행할 수 있습니다.
$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}'
odo push
를 실행합니다. 두 매핑이 모두 올바르게 삽입되었는지 확인하려면 다음 명령을 실행합니다.
$ odo exec -- env | grep -e "pgVersion\|pgImage"
출력 예:
pgVersion=13 pgImage=registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
3.5.6.2.3.1. 인라인으로, 또는 아니오?
odo 링크가
대한 매니페스트 파일을 생성하는 기본 동작을 허용할 수 있습니다. 또는 모든 것을 단일 kubernetes/
디렉터리에 링크에devfile.yaml
파일에 저장하려는 경우 --inlined
플래그를 사용할 수 있습니다.
3.5.6.3. 파일로 바인딩
odo link
에서 제공하는 또 다른 유용한 플래그는 --bind-as-files
입니다. 이 플래그를 전달하면 바인딩 정보가 구성 요소의 포드에 삽입되지 않지만 파일 시스템으로 마운트됩니다.
백엔드 구성 요소와 PostgreSQL 서비스 사이에 기존 링크가 없는지 확인합니다. 백엔드 구성 요소의 디렉터리에서 odo describe
를 실행하고 다음과 유사한 출력이 표시되는지 확인하여 이 작업을 수행할 수 있습니다.
Linked Services: · PostgresCluster/hippo
다음을 사용하여 구성 요소에서 서비스를 끊습니다.
$ odo unlink PostgresCluster/hippo $ odo push
3.5.6.4. --bind-as-files 예제
3.5.6.4.1. 기본 odo 링크 사용
기본적으로 odo
는 링크 정보를 저장하기 위해 kubernetes/
디렉터리에 매니페스트 파일을 생성합니다. 다음을 사용하여 백엔드 구성 요소 및 PostgreSQL 서비스를 연결합니다.
$ odo link PostgresCluster/hippo --bind-as-files $ odo push
예제 odo describe
출력:
$ odo describe Component Name: backend Type: spring Environment Variables: · PROJECTS_ROOT=/projects · PROJECT_SOURCE=/projects · DEBUG_PORT=5858 · SERVICE_BINDING_ROOT=/bindings · SERVICE_BINDING_ROOT=/bindings Storage: · m2 of size 3Gi mounted to /home/user/.m2 URLs: · http://8080-tcp.192.168.39.112.nip.io exposed via 8080 Linked Services: · PostgresCluster/hippo Files: · /bindings/backend-postgrescluster-hippo/pgbackrest_instance.conf · /bindings/backend-postgrescluster-hippo/user · /bindings/backend-postgrescluster-hippo/ssh_known_hosts · /bindings/backend-postgrescluster-hippo/clusterIP · /bindings/backend-postgrescluster-hippo/password · /bindings/backend-postgrescluster-hippo/patroni.yaml · /bindings/backend-postgrescluster-hippo/pgbouncer-frontend.crt · /bindings/backend-postgrescluster-hippo/pgbouncer-host · /bindings/backend-postgrescluster-hippo/root.key · /bindings/backend-postgrescluster-hippo/pgbouncer-frontend.key · /bindings/backend-postgrescluster-hippo/pgbouncer.ini · /bindings/backend-postgrescluster-hippo/uri · /bindings/backend-postgrescluster-hippo/config-hash · /bindings/backend-postgrescluster-hippo/pgbouncer-empty · /bindings/backend-postgrescluster-hippo/port · /bindings/backend-postgrescluster-hippo/dns.crt · /bindings/backend-postgrescluster-hippo/pgbouncer-uri · /bindings/backend-postgrescluster-hippo/root.crt · /bindings/backend-postgrescluster-hippo/ssh_config · /bindings/backend-postgrescluster-hippo/dns.key · /bindings/backend-postgrescluster-hippo/host · /bindings/backend-postgrescluster-hippo/patroni.crt-combined · /bindings/backend-postgrescluster-hippo/pgbouncer-frontend.ca-roots · /bindings/backend-postgrescluster-hippo/tls.key · /bindings/backend-postgrescluster-hippo/verifier · /bindings/backend-postgrescluster-hippo/ca.crt · /bindings/backend-postgrescluster-hippo/dbname · /bindings/backend-postgrescluster-hippo/patroni.ca-roots · /bindings/backend-postgrescluster-hippo/pgbackrest_repo.conf · /bindings/backend-postgrescluster-hippo/pgbouncer-port · /bindings/backend-postgrescluster-hippo/pgbouncer-verifier · /bindings/backend-postgrescluster-hippo/id_ecdsa · /bindings/backend-postgrescluster-hippo/id_ecdsa.pub · /bindings/backend-postgrescluster-hippo/pgbouncer-password · /bindings/backend-postgrescluster-hippo/pgbouncer-users.txt · /bindings/backend-postgrescluster-hippo/sshd_config · /bindings/backend-postgrescluster-hippo/tls.crt
이전 odo describe
출력의 key=value
형식의 환경 변수가 모두 이제 파일로 마운트됩니다. cat
명령을 사용하여 다음 파일의 일부 내용을 봅니다.
예제 명령:
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/password
출력 예:
q({JC:jn^mm/Bw}eu+j.GX{k
예제 명령:
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/user
출력 예:
hippo
예제 명령:
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/clusterIP
출력 예:
10.101.78.56
3.5.6.4.2. --inlined
사용
--bind-as-files
및 --inlined
를 함께 사용한 결과는 odo link --inlined
를 사용하는 것과 유사합니다. 링크의 매니페스트는 kubernetes/
디렉터리에 별도의 파일에 저장하는 대신 devfile.yaml
에 저장됩니다. 그 외에는 odo describe
출력이 이전과 동일합니다.
3.5.6.4.3. 사용자 정의 바인딩
PostgreSQL 서비스와 백엔드 구성 요소를 연결하는 동안 사용자 정의 바인딩을 전달하면 이러한 사용자 지정 바인딩이 환경 변수가 아닌 파일로 삽입됩니다. 예를 들면 다음과 같습니다.
$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}' --bind-as-files $ odo push
이러한 사용자 정의 바인딩은 환경 변수로 삽입되는 대신 파일로 마운트됩니다. 이 작업이 완료되었는지 확인하려면 다음 명령을 실행합니다.
예제 명령:
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/pgVersion
출력 예:
13
예제 명령:
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/pgImage
출력 예:
registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
3.5.7. odo 레지스트리
odo
는 이식 가능한 devfile 형식을 사용하여 구성 요소를 설명합니다. odo
는 다양한 devfile 레지스트리에 연결하여 다양한 언어 및 프레임워크에 대한 devfile을 다운로드할 수 있습니다.
공개적으로 사용 가능한 devfile 레지스트리에 연결하거나 자체 보안 레지스트리를 설치할 수 있습니다.
odo registry
명령을 사용하여 odo
에서 devfile 정보를 검색하는 데 사용하는 레지스트리를 관리할 수 있습니다.
3.5.7.1. 레지스트리 나열
현재 odo
에서 연결하는 레지스트리를 나열하려면 다음 명령을 실행합니다.
$ odo registry list
출력 예:
NAME URL SECURE DefaultDevfileRegistry https://registry.devfile.io No
DefaultDevfileRegistry
는 odo에서 사용하는 기본 레지스트리이며 devfile.io 프로젝트에서 제공합니다.
3.5.7.2. 레지스트리 추가
레지스트리를 추가하려면 명령을 실행합니다.
$ odo registry add
출력 예:
$ odo registry add StageRegistry https://registry.stage.devfile.io New registry successfully added
자체 보안 레지스트리를 배포하는 경우 개인 액세스 토큰을 지정하여 --token
플래그를 사용하여 보안 레지스트리에 인증할 수 있습니다.
$ odo registry add MyRegistry https://myregistry.example.com --token <access_token> New registry successfully added
3.5.7.3. 레지스트리 삭제
레지스트리를 삭제하려면 명령을 실행합니다.
$ odo registry delete
출력 예:
$ odo registry delete StageRegistry ? Are you sure you want to delete registry "StageRegistry" Yes Successfully deleted registry
--force
(또는 -f
) 플래그를 사용하여 확인 없이 레지스트리를 강제로 삭제합니다.
3.5.7.4. 레지스트리 업데이트
이미 등록된 레지스트리의 URL 또는 개인 액세스 토큰을 업데이트하려면 명령을 실행합니다.
$ odo registry update
출력 예:
$ odo registry update MyRegistry https://otherregistry.example.com --token <other_access_token> ? Are you sure you want to update registry "MyRegistry" Yes Successfully updated registry
--force
(또는 -f
) 플래그를 사용하여 확인 없이 레지스트리 업데이트를 강제 적용합니다.
3.5.8. odo 서비스
odo
는 Operator 의 도움을 받아 서비스를 배포할 수 있습니다.
설치에 사용 가능한 Operator 및 서비스 목록은 odo catalog
명령을 사용하여 확인할 수 있습니다.
서비스는 구성 요소 의 컨텍스트에서 생성되므로 서비스를 배포하기 전에 odo create
명령을 실행합니다.
서비스는 다음 두 단계를 사용하여 배포됩니다.
- 서비스를 정의하고 해당 정의를 devfile에 저장합니다.
-
odo push
명령을 사용하여 정의된 서비스를 클러스터에 배포합니다.
3.5.8.1. 새 서비스 생성
새 서비스를 생성하려면 명령을 실행합니다.
$ odo service create
예를 들어 my-redis-service
라는 Redis 서비스의 인스턴스를 생성하려면 다음 명령을 실행합니다.
출력 예
$ odo catalog list services Services available through Operators NAME CRDs redis-operator.v0.8.0 RedisCluster, Redis $ odo service create redis-operator.v0.8.0/Redis my-redis-service Successfully added service to the configuration; do 'odo push' to create service on the cluster
이 명령은 서비스 정의가 포함된 kubernetes/
디렉터리에 Kubernetes 매니페스트를 생성하고 이 파일은 devfile.yaml
파일에서 참조합니다.
$ cat kubernetes/odo-service-my-redis-service.yaml
출력 예
apiVersion: redis.redis.opstreelabs.in/v1beta1 kind: Redis metadata: name: my-redis-service spec: kubernetesConfig: image: quay.io/opstree/redis:v6.2.5 imagePullPolicy: IfNotPresent resources: limits: cpu: 101m memory: 128Mi requests: cpu: 101m memory: 128Mi serviceType: ClusterIP redisExporter: enabled: false image: quay.io/opstree/redis-exporter:1.0 storage: volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
명령 예
$ cat devfile.yaml
출력 예
[...] components: - kubernetes: uri: kubernetes/odo-service-my-redis-service.yaml name: my-redis-service [...]
생성된 인스턴스의 이름은 선택 사항입니다. 이름을 지정하지 않으면 서비스의 소문자가 됩니다. 예를 들어 다음 명령은 redis
라는 Redis 서비스의 인스턴스를 생성합니다.
$ odo service create redis-operator.v0.8.0/Redis
3.5.8.1.1. 매니페스트 간소화
기본적으로 devfile.yaml
파일에서 참조하는 kubernetes/
디렉터리에 새 매니페스트가 생성됩니다. --inlined
플래그를 사용하여 devfile.yaml
파일 내의 매니페스트를 인라인할 수 있습니다.
$ odo service create redis-operator.v0.8.0/Redis my-redis-service --inlined Successfully added service to the configuration; do 'odo push' to create service on the cluster
명령 예
$ cat devfile.yaml
출력 예
[...] components: - kubernetes: inlined: | apiVersion: redis.redis.opstreelabs.in/v1beta1 kind: Redis metadata: name: my-redis-service spec: kubernetesConfig: image: quay.io/opstree/redis:v6.2.5 imagePullPolicy: IfNotPresent resources: limits: cpu: 101m memory: 128Mi requests: cpu: 101m memory: 128Mi serviceType: ClusterIP redisExporter: enabled: false image: quay.io/opstree/redis-exporter:1.0 storage: volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi name: my-redis-service [...]
3.5.8.1.2. 서비스 구성
특정 사용자 지정이 없으면 기본 구성으로 서비스가 생성됩니다. 명령줄 인수 또는 파일을 사용하여 고유한 구성을 지정할 수 있습니다.
3.5.8.1.2.1. 명령줄 인수 사용
--parameters
(또는 -p
) 플래그를 사용하여 고유한 구성을 지정합니다.
다음 예제에서는 세 가지 매개 변수를 사용하여 Redis 서비스를 구성합니다.
$ odo service create redis-operator.v0.8.0/Redis my-redis-service \ -p kubernetesConfig.image=quay.io/opstree/redis:v6.2.5 \ -p kubernetesConfig.serviceType=ClusterIP \ -p redisExporter.image=quay.io/opstree/redis-exporter:1.0 Successfully added service to the configuration; do 'odo push' to create service on the cluster
명령 예
$ cat kubernetes/odo-service-my-redis-service.yaml
출력 예
apiVersion: redis.redis.opstreelabs.in/v1beta1 kind: Redis metadata: name: my-redis-service spec: kubernetesConfig: image: quay.io/opstree/redis:v6.2.5 serviceType: ClusterIP redisExporter: image: quay.io/opstree/redis-exporter:1.0
odo catalog describe service
명령을 사용하여 특정 서비스에 사용 가능한 매개변수를 가져올 수 있습니다.
3.5.8.1.2.2. 파일 사용
YAML 매니페스트를 사용하여 자체 사양을 구성합니다. 다음 예에서 Redis 서비스는 세 개의 매개 변수로 구성됩니다.
매니페스트를 생성합니다.
$ cat > my-redis.yaml <<EOF apiVersion: redis.redis.opstreelabs.in/v1beta1 kind: Redis metadata: name: my-redis-service spec: kubernetesConfig: image: quay.io/opstree/redis:v6.2.5 serviceType: ClusterIP redisExporter: image: quay.io/opstree/redis-exporter:1.0 EOF
매니페스트에서 서비스를 생성합니다.
$ odo service create --from-file my-redis.yaml Successfully added service to the configuration; do 'odo push' to create service on the cluster
3.5.8.2. 서비스 삭제
서비스를 삭제하려면 명령을 실행합니다.
$ odo service delete
출력 예
$ odo service list NAME MANAGED BY ODO STATE AGE Redis/my-redis-service Yes (api) Deleted locally 5m39s
$ odo service delete Redis/my-redis-service ? Are you sure you want to delete Redis/my-redis-service Yes Service "Redis/my-redis-service" has been successfully deleted; do 'odo push' to delete service from the cluster
--force
(또는 -f
) 플래그를 사용하여 확인 없이 서비스를 강제로 삭제합니다.
3.5.8.3. 서비스 나열
구성 요소용으로 생성된 서비스를 나열하려면 다음 명령을 실행합니다.
$ odo service list
출력 예
$ odo service list NAME MANAGED BY ODO STATE AGE Redis/my-redis-service-1 Yes (api) Not pushed Redis/my-redis-service-2 Yes (api) Pushed 52s Redis/my-redis-service-3 Yes (api) Deleted locally 1m22s
각 서비스에 대해 STATE
는 odo push
명령을 사용하여 서비스가 클러스터로 푸시되었는지 또는 서비스가 여전히 클러스터에서 실행 중이지만 odo service delete
명령을 사용하여 로컬에서 devfile에서 제거되었는지를 나타냅니다.
3.5.8.4. 서비스에 대한 정보 얻기
구성된 매개 변수의 종류, 버전, 이름 및 목록과 같은 서비스의 세부 정보를 얻으려면 명령을 실행합니다.
$ odo service describe
출력 예
$ odo service describe Redis/my-redis-service Version: redis.redis.opstreelabs.in/v1beta1 Kind: Redis Name: my-redis-service Parameters: NAME VALUE kubernetesConfig.image quay.io/opstree/redis:v6.2.5 kubernetesConfig.serviceType ClusterIP redisExporter.image quay.io/opstree/redis-exporter:1.0
3.5.9. odo 스토리지
odo
를 사용하면 구성 요소에 연결된 스토리지 볼륨을 관리할 수 있습니다. 스토리지 볼륨은 emptyDir
Kubernetes 볼륨을 사용하는 임시 볼륨 또는 PVC( 영구 볼륨 클레임 )일 수 있습니다. PVC를 사용하면 특정 클라우드 환경의 세부 정보를 이해하지 않고도 영구 볼륨(예: GCE PersistentDisk 또는 iSCSI 볼륨)을 요청할 수 있습니다. 영구 스토리지 볼륨은 재시작 시 데이터를 유지하고 구성 요소를 다시 빌드하는 데 사용할 수 있습니다.
3.5.9.1. 스토리지 볼륨 추가
클러스터에 스토리지 볼륨을 추가하려면 명령을 실행합니다.
$ odo storage create
출력 예:
$ odo storage create store --path /data --size 1Gi ✓ Added storage store to nodejs-project-ufyy $ odo storage create tempdir --path /tmp --size 2Gi --ephemeral ✓ Added storage tempdir to nodejs-project-ufyy Please use `odo push` command to make the storage accessible to the component
위의 예에서 첫 번째 스토리지 볼륨이 /data
경로에 마운트되었으며 크기가 1Gi
로 설정되어 두 번째 볼륨이 /tmp
에 마운트되어 임시입니다.
3.5.9.2. 스토리지 볼륨 나열
현재 구성 요소에서 사용하는 스토리지 볼륨을 확인하려면 명령을 실행합니다.
$ odo storage list
출력 예:
$ odo storage list The component 'nodejs-project-ufyy' has the following storage attached: NAME SIZE PATH STATE store 1Gi /data Not Pushed tempdir 2Gi /tmp Not Pushed
3.5.9.3. 스토리지 볼륨 삭제
스토리지 볼륨을 삭제하려면 명령을 실행합니다.
$ odo storage delete
출력 예:
$ odo storage delete store -f Deleted storage store from nodejs-project-ufyy Please use `odo push` command to delete the storage from the cluster
위의 예에서 -f
플래그를 사용하면 사용자 권한을 요청하지 않고 스토리지를 강제로 삭제합니다.
3.5.9.4. 특정 컨테이너에 스토리지 추가
devfile에 여러 컨테이너가 있는 경우 odo storage create
명령에서 --container
플래그를 사용하여 스토리지를 연결할 컨테이너를 지정할 수 있습니다.
다음 예제는 여러 컨테이너가 있는 devfile에서 발췌한 것입니다.
components: - name: nodejs1 container: image: registry.access.redhat.com/ubi8/nodejs-12:1-36 memoryLimit: 1024Mi endpoints: - name: "3000-tcp" targetPort: 3000 mountSources: true - name: nodejs2 container: image: registry.access.redhat.com/ubi8/nodejs-12:1-36 memoryLimit: 1024Mi
이 예제에는nodejs1
및 nodejs2
라는 두 개의 컨테이너가 있습니다. 스토리지를 nodejs2
컨테이너에 연결하려면 다음 명령을 사용합니다.
$ odo storage create --container
출력 예:
$ odo storage create store --path /data --size 1Gi --container nodejs2 ✓ Added storage store to nodejs-testing-xnfg Please use `odo push` command to make the storage accessible to the component
odo storage list
명령을 사용하여 스토리지 리소스를 나열할 수 있습니다.
$ odo storage list
출력 예:
The component 'nodejs-testing-xnfg' has the following storage attached: NAME SIZE PATH CONTAINER STATE store 1Gi /data nodejs2 Not Pushed
3.5.10. 공통 플래그
대부분의 odo
명령에서 다음 플래그를 사용할 수 있습니다.
명령 | 설명 |
---|---|
| 구성 요소가 정의된 컨텍스트 디렉터리를 설정합니다. |
| 구성 요소의 프로젝트를 설정합니다. 기본값은 로컬 구성에 정의된 프로젝트입니다. 사용할 수 없는 경우 클러스터의 현재 프로젝트입니다. |
| 구성 요소의 애플리케이션을 설정합니다. 기본값은 로컬 구성에 정의된 애플리케이션입니다. 사용할 수 없는 경우 앱. |
|
기본 구성을 사용하지 않는 경우 |
| 이 플래그를 사용하여 로그를 확인합니다. |
| 이 플래그를 사용하여 사용자에게 확인 메시지를 표시하지 않도록 명령에 알립니다. |
| 상세 수준을 설정합니다. 자세한 내용은 odo에서 로깅 을 참조하십시오. |
| 명령에 대한 도움말을 출력합니다. |
일부 명령에는 일부 플래그를 사용할 수 없습니다. --help
플래그와 함께 명령을 실행하여 사용 가능한 모든 플래그 목록을 가져옵니다.
3.5.11. JSON 출력
콘텐츠를 출력하는 odo
명령은 일반적으로 -o json
플래그를 수락하여 이 콘텐츠를 JSON 형식으로 출력하는 경우 다른 프로그램이 이 출력을 더 쉽게 구문 분석하는 데 적합합니다.
출력 구조는 kind
,apiVersion
,metadata
,spec
, status
필드와 함께 Kubernetes 리소스와 유사합니다.
나열 명령은 목록의 항목을 나열하는 항목
(또는 유사한) 필드를 포함하는 List
리소스를 반환하며 각 항목은 Kubernetes 리소스와 유사합니다.
삭제 명령은 상태
리소스를 반환합니다. Status Kubernetes 리소스 를 참조하십시오.
다른 명령은 명령과 관련된 리소스를 반환합니다(예: 애플리케이션
, 스토리지
,URL
등).
현재 -o json
플래그를 수락하는 명령의 전체 목록은 다음과 같습니다.
명령 | 종류(버전) | 목록 항목의 종류(버전) | 완전한 콘텐츠입니까? |
---|---|---|---|
odo application describe | 애플리케이션(odo.dev/v1alpha1) | 해당 없음 | 제공되지 않음 |
odo 애플리케이션 목록 | 목록 (odo.dev/v1alpha1) | 애플리케이션(odo.dev/v1alpha1) | ? |
odo catalog list components | 목록 (odo.dev/v1alpha1) | 누락됨 | 제공됨 |
odo catalog list services | 목록 (odo.dev/v1alpha1) | ClusterServiceVersion (operators.coreos.com/v1alpha1) | ? |
odo catalog describe 구성 요소 | 누락됨 | 해당 없음 | 제공됨 |
odo catalog describe service | CRDDescription(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo 구성 요소 생성 | 구성 요소(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo component describe | 구성 요소(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo 구성 요소 목록 | 목록 (odo.dev/v1alpha1) | 구성 요소(odo.dev/v1alpha1) | 제공됨 |
odo config view | DevfileConfiguration(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo debug info | OdoDebugInfo (odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo env view | EnvInfo (odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo preference view | PreferenceList (odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo project create | 프로젝트(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo project delete | 상태(v1) | 해당 없음 | 제공됨 |
odo project get | 프로젝트(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo 프로젝트 목록 | 목록 (odo.dev/v1alpha1) | 프로젝트(odo.dev/v1alpha1) | 제공됨 |
odo 레지스트리 목록 | 목록 (odo.dev/v1alpha1) | 누락됨 | 제공됨 |
odo service create | Service | 해당 없음 | 제공됨 |
odo service describe | Service | 해당 없음 | 제공됨 |
odo 서비스 목록 | 목록 (odo.dev/v1alpha1) | Service | 제공됨 |
odo storage create | 스토리지(odo.dev/v1alpha1) | 해당 없음 | 제공됨 |
odo storage delete | 상태(v1) | 해당 없음 | 제공됨 |
odo 스토리지 목록 | 목록 (odo.dev/v1alpha1) | 스토리지(odo.dev/v1alpha1) | 제공됨 |
odo url 목록 | 목록 (odo.dev/v1alpha1) | URL (odo.dev/v1alpha1) | 제공됨 |
4장. Helm CLI
4.1. Helm 3 시작하기
4.1.1. Helm 이해
Helm은 OpenShift Container Platform 클러스터에 대한 애플리케이션 및 서비스 배포를 간소화하는 소프트웨어 패키지 관리자입니다.
Helm은 차트라는 패키징 형식을 사용합니다. Helm 차트는 OpenShift Container Platform 리소스에 대해 설명하는 파일 컬렉션입니다.
클러스터에 있는 차트의 실행 중인 인스턴스를 릴리스라고 합니다. 클러스터에 차트가 설치될 때마다 새 릴리스가 생성됩니다.
차트를 설치하거나 릴리스를 업그레이드하거나 롤백할 때마다 번호가 증가한 리버전이 생성됩니다.
4.1.1.1. 주요 기능
Helm은 다음을 수행할 수 있는 기능을 제공합니다.
- 차트 리포지토리에 저장된 대규모 차트 컬렉션에서 검색합니다.
- 기존 차트를 수정합니다.
- OpenShift Container Platform 또는 Kubernetes 리소스를 사용하여 자체 차트를 생성합니다.
- 애플리케이션을 차트로 패키징하고 공유합니다.
4.1.2. Helm 설치
다음 섹션에서는 CLI를 사용하여 다양한 플랫폼에 Helm을 설치하는 방법을 설명합니다.
오른쪽 상단에 있는 ? 아이콘을 클릭하고 명령줄 툴을 선택하여 OpenShift Container Platform 웹 콘솔의 최신 바이너리 URL을 찾을 수도 있습니다.
사전 요구 사항
- Go 버전 1.13 이상이 설치되어 있어야 합니다.
4.1.2.1. On Linux
Helm 바이너리를 다운로드하여 경로에 추가합니다.
# curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm
바이너리 파일을 실행 가능하게 합니다.
# chmod +x /usr/local/bin/helm
설치된 버전을 확인합니다.
$ helm version
출력 예
version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}
4.1.2.2. Windows 7/8
-
최신
.exe
파일을 다운로드하여 기본 설정 디렉터리에 배치합니다. - 시작을 마우스 오른쪽 버튼으로 클릭하고 제어판을 클릭합니다.
- 시스템 및 보안을 선택하고 시스템을 클릭합니다.
- 왼쪽 메뉴에서 고급 시스템 설정을 선택하고 아래에 있는 환경 변수를 클릭합니다.
- 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
-
새로 생성을 클릭하고 필드에
.exe
파일이 있는 폴더의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.
4.1.2.3. Windows 10
-
최신
.exe
파일을 다운로드하여 기본 설정 디렉터리에 배치합니다. -
검색을 클릭하고
env
또는environment
를 입력합니다. - 계정의 환경 변수 편집을 선택합니다.
- 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
- 새로 생성을 클릭하고 필드에 exe 파일이 있는 디렉터리의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.
4.1.2.4. MacOS
Helm 바이너리를 다운로드하여 경로에 추가합니다.
# curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm
바이너리 파일을 실행 가능하게 합니다.
# chmod +x /usr/local/bin/helm
설치된 버전을 확인합니다.
$ helm version
출력 예
version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}
4.1.3. OpenShift Container Platform 클러스터에 Helm 차트 설치
사전 요구 사항
- 실행 중인 OpenShift Container Platform 클러스터가 있고 로그인되어 있어야 합니다.
- Helm이 설치되어 있어야 합니다.
절차
새 프로젝트를 생성합니다.
$ oc new-project mysql
로컬 Helm 클라이언트에 Helm 차트 리포지터리를 추가합니다.
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
출력 예
"stable" has been added to your repositories
리포지터리를 업데이트합니다.
$ helm repo update
MySQL 차트 예를 설치합니다.
$ helm install example-mysql stable/mysql
차트가 성공적으로 설치되었는지 확인합니다.
$ 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
4.1.4. OpenShift Container Platform에서 사용자 정의 Helm 차트 생성
절차
새 프로젝트를 생성합니다.
$ oc new-project nodejs-ex-k
OpenShift Container Platform 오브젝트가 포함된 Node.js 차트 예를 다운로드합니다.
$ git clone https://github.com/redhat-developer/redhat-helm-charts
샘플 차트가 있는 디렉터리로 이동합니다.
$ cd redhat-helm-charts/alpha/nodejs-ex-k/
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
차트 형식이 올바르게 지정되었는지 확인합니다.
$ helm lint
출력 예
[INFO] Chart.yaml: icon is recommended 1 chart(s) linted, 0 chart(s) failed
이전 디렉터리 수준으로 이동합니다.
$ cd ..
차트를 설치합니다.
$ helm install nodejs-chart nodejs-ex-k
차트가 성공적으로 설치되었는지 확인합니다.
$ 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
4.2. 사용자 정의 Helm 차트 리포지터리 구성
개발자 카탈로그는 웹 콘솔의 개발자 관점으로 클러스터에서 사용할 수 있는 Helm 차트를 표시합니다. 기본적으로 Red Hat Helm 차트 리포지터리의 Helm 차트를 나열합니다. 차트 목록은 Red Hat Helm 인덱스
파일을 참조하십시오.
클러스터 관리자는 기본 리포지터리 외에도 여러 Helm 차트 리포지터리를 추가하여 해당 리포지터리의 Helm 차트를 개발자 카탈로그에 표시할 수 있습니다.
4.2.1. 사용자 정의 Helm 차트 리포지터리 추가
사용자 정의 Helm 차트 리포지터리를 클러스터에 추가하고 개발자 카탈로그 의 해당 리포지터리에서 Helm 차트에 대한 액세스를 활성화할 수 있습니다.
절차
새 Helm 차트 리포지터리를 추가하려면 클러스터에 Helm 차트 리포지터리 CR(사용자 정의 리소스)을 추가해야 합니다.
샘플 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
- 웹 콘솔에서 개발자 카탈로그 로 이동하여 Azure 차트 리포지토리의 helm 차트가 표시되는지 확인합니다.
4.2.2. 인증 정보 및 CA 인증서를 생성하여 Helm 차트 리포지터리 추가
일부 Helm 차트 리포지터리는 연결하려면 인증 정보 및 사용자 정의 CA(인증 기관) 인증서가 필요합니다. 웹 콘솔 및 CLI를 사용하여 인증 정보 및 인증서를 추가할 수 있습니다.
절차
CLI를 사용하여 인증 정보 및 인증서를 구성한 후 Helm 차트 리포지터리를 추가하려면 다음을 실행합니다.
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
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.crt
및tls.key
키에 저장되어야 합니다.다음과 같이 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
ConfigMap
및Secret
은tlsConfig
및ca
필드를 사용하는 HelmChartRepository CR에서 사용됩니다. 이러한 인증서는 Helm 리포지터리 URL에 연결하는 데 사용됩니다.기본적으로 모든 인증된 사용자는 모든 구성된 차트에 액세스할 수 있습니다. 하지만 인증서가 필요한 차트 리포지터리의 경우 다음과 같이 사용자에게
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
5장. OpenShift Serverless에서 사용할 Knative CLI
Knative(kn
) CLI를 사용하면 OpenShift Container Platform의 Knative 구성 요소와 간단한 상호 작용을 수행할 수 있습니다.
5.1. 주요 기능
Knative(kn
) CLI는 서버리스 컴퓨팅 작업을 간단하고 간결하게 만들기 위해 설계되었습니다. Knative CLI의 주요 기능은 다음과 같습니다.
- 명령줄에서 서버리스 애플리케이션을 배포합니다.
- 서비스, 개정, 트래픽 분할 등 Knative Serving 기능을 관리합니다.
- 이벤트 소스 및 트리거와 같은 Knative 이벤트 구성 요소를 생성하고 관리합니다.
- 기존 Kubernetes 애플리케이션 및 Knative 서비스를 연결하는 싱크 바인딩을 생성합니다.
-
kubectl
CLI와 유사하게 유연한 플러그인 아키텍처를 사용하여 Knative CLI를 확장합니다. - Knative 서비스에 대한 자동 스케일링 매개변수를 구성합니다.
- 작업 결과 대기나 사용자 정의 롤아웃 및 롤백 전략 배포와 같은 사용법을 스크립팅합니다.
5.2. Knative CLI 설치
Knative CLI 설치를 참조하십시오.
6장. Pipelines CLI(tkn)
6.1. tkn 설치
tkn
CLI를 사용하여 터미널에서 Red Hat OpenShift Pipelines를 관리합니다. 다음 섹션에서는 다양한 플랫폼에 tkn
을 설치하는 방법을 설명합니다.
오른쪽 상단에 있는 ? 아이콘을 클릭하고 명령줄 툴을 선택하여 OpenShift Container Platform 웹 콘솔의 최신 바이너리 URL을 찾을 수도 있습니다.
6.1.1. Linux에서 Red Hat OpenShift Pipelines CLI(tkn) 설치
Linux 배포판의 경우 tar.gz
아카이브로 직접 CLI를 다운로드할 수 있습니다.
절차
관련 CLI를 다운로드합니다.
아카이브의 압축을 풉니다.
$ tar xvzf <file>
-
tkn
바이너리를PATH
에 있는 디렉터리에 배치합니다. PATH
를 확인하려면 다음을 실행합니다.$ echo $PATH
6.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 권한이 있어야 합니다.
절차
Red Hat Subscription Manager에 등록합니다.
# subscription-manager register
최신 서브스크립션 데이터를 가져옵니다.
# subscription-manager refresh
사용 가능한 서브스크립션을 나열하십시오.
# subscription-manager list --available --matches '*pipelines*'
이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이 서브스크립션을 등록된 시스템에 연결합니다.
# subscription-manager attach --pool=<pool_id>
Red Hat OpenShift Pipelines에 필요한 리포지터리를 활성화합니다.
# subscription-manager repos --enable="pipelines-1.2-for-rhel-8-x86_64-rpms"
openshift-pipelines-client
패키지를 설치합니다.# yum install openshift-pipelines-client
CLI를 설치한 후 tkn
명령을 사용할 수 있습니다.
$ tkn version
6.1.3. Windows에서 Red Hat OpenShift Pipelines CLI(tkn) 설치
Windows에서는 tkn
CLI가 zip
아카이브로 제공됩니다.
절차
- CLI를 다운로드합니다.
- ZIP 프로그램으로 아카이브의 압축을 풉니다.
-
tkn.exe
파일의 위치를PATH
환경 변수에 추가합니다. PATH
를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.C:\> path
6.1.4. macOS에서 Red Hat OpenShift Pipelines CLI(tkn) 설치
macOS에서는 tkn
CLI가 tar.gz
아카이브로 제공됩니다.
절차
- CLI를 다운로드합니다.
- 아카이브의 압축을 해제하고 압축을 풉니다.
-
tkn
바이너리를 PATH에 있는 디렉터리로 이동합니다. PATH
를 확인하려면 터미널 창을 열고 다음을 실행합니다.$ echo $PATH
6.2. OpenShift Pipelines tkn CLI 구성
탭 완료가 활성화되도록 Red Hat OpenShift Pipelines tkn
CLI를 구성합니다.
6.2.1. 탭 완료 활성화
tkn
CLI를 설치한 후에는 탭 완료를 활성화하여 자동으로 tkn
명령을 완료하거나 탭을 누를 때 옵션을 제안하도록 할 수 있습니다.
사전 요구 사항
-
tkn
CLI 툴이 설치되어 있어야 합니다. -
로컬 시스템에
bash-completion
이 설치되어 있어야 합니다.
절차
Bash 탭 완료를 활성화하는 절차는 다음과 같습니다.
Bash 완료 코드를 파일에 저장합니다.
$ tkn completion bash > tkn_bash_completion
파일을
/etc/bash_completion.d/
에 복사합니다.$ sudo cp tkn_bash_completion /etc/bash_completion.d/
또는 파일을 로컬 디렉터리에 저장하여
.bashrc
파일에서 소싱할 수도 있습니다.
새 터미널을 열면 탭 완료가 활성화됩니다.
6.3. OpenShift Pipelines tkn 참조
이 섹션에는 기본 tkn
CLI 명령이 나열됩니다.
6.3.1. 기본 구문
tkn [command or options] [arguments…]
6.3.2. 글로벌 옵션
--help, -h
6.3.3. 유틸리티 명령
6.3.3.1. tkn
tkn
CLI의 상위 명령입니다.
예제: 모든 옵션 표시
$ tkn
6.3.3.2. completion [shell]
대화형 완료를 제공하려면 평가해야 하는 쉘 완료 코드를 출력합니다. 지원되는 쉘은 bash
및 zsh
입니다.
예제: bash
쉘 완료 코드
$ tkn completion bash
6.3.3.3. version
tkn
CLI의 버전 정보를 출력합니다.
예제: tkn
버전 확인
$ tkn version
6.3.4. 파이프라인 관리 명령
6.3.4.1. pipeline
파이프라인을 관리합니다.
예제: 도움말 표시
$ tkn pipeline --help
6.3.4.2. pipeline delete
파이프라인을 삭제합니다.
예제: 네임스페이스 에서 mypipeline
파이프라인 삭제
$ tkn pipeline delete mypipeline -n myspace
6.3.4.3. pipeline describe
파이프라인을 설명합니다.
예제: mypipeline 파이프라인
설명
$ tkn pipeline describe mypipeline
6.3.4.4. pipeline list
파이프라인을 나열합니다.
예제: Pipeline 목록 표시
$ tkn pipeline list
6.3.4.5. pipeline logs
특정 파이프라인의 파이프라인 로그를 표시합니다.
예제: mypipeline
파이프라인의 스트림 실시간 로그
$ tkn pipeline logs -f mypipeline
6.3.4.6. pipeline start
파이프라인을 시작합니다.
예제: mypipeline 파이프라인
시작
$ tkn pipeline start mypipeline
6.3.5. PipelineRun 명령
6.3.5.1. pipelinerun
PipelineRun을 관리합니다.
예제: 도움말 표시
$ tkn pipelinerun -h
6.3.5.2. pipelinerun cancel
PipelineRun을 취소합니다.
예제: 네임스페이스 에서 mypipelinerun
PipelineRun 취소
$ tkn pipelinerun cancel mypipelinerun -n myspace
6.3.5.3. pipelinerun delete
PipelineRun을 삭제합니다.
예제: 네임스페이스에서 PipelineRun 삭제
$ tkn pipelinerun delete mypipelinerun1 mypipelinerun2 -n myspace
6.3.5.4. pipelinerun describe
PipelineRun을 설명합니다.
예제: 네임스페이스의 mypipelinerun
PipelineRun 설명
$ tkn pipelinerun describe mypipelinerun -n myspace
6.3.5.5. pipelinerun list
PipelineRun을 나열합니다.
예제: 네임스페이스의 PipelineRun 목록 표시
$ tkn pipelinerun list -n myspace
6.3.5.6. pipelinerun logs
PipelineRun 로그를 표시합니다.
예제: 네임스페이스의 모든 작업 및 단계와 함께 mypipelinerun
PipelineRun 로그 표시
$ tkn pipelinerun logs mypipelinerun -a -n myspace
6.3.6. 작업 관리 명령
6.3.6.1. task
작업을 관리합니다.
예제: 도움말 표시
$ tkn task -h
6.3.6.2. task delete
작업을 삭제합니다.
예제: 네임스페이스에서 mytask1
및 mytask2
작업 삭제
$ tkn task delete mytask1 mytask2 -n myspace
6.3.6.3. task describe
작업을 설명합니다.
예제: 네임스페이스의 mytask
작업을 설명합니다.
$ tkn task describe mytask -n myspace
6.3.6.4. task list
작업을 나열합니다.
예제: 네임스페이스의 모든 작업 나열
$ tkn task list -n myspace
6.3.6.5. task logs
작업 로그를 표시합니다.
예제: mytask 작업의 mytaskrun
TaskRun 로그 표시
$ tkn task logs mytask mytaskrun -n myspace
6.3.6.6. task start
작업을 시작합니다.
예제: 네임스페이스 에서 mytask
작업 시작
$ tkn task start mytask -s <ServiceAccountName> -n myspace
6.3.7. TaskRun 명령
6.3.7.1. taskrun
TaskRun을 관리합니다.
예제: 도움말 표시
$ tkn taskrun -h
6.3.7.2. taskrun cancel
TaskRun을 취소합니다.
예제: 네임스페이스 에서 mytaskrun
TaskRun 취소
$ tkn taskrun cancel mytaskrun -n myspace
6.3.7.3. taskrun delete
TaskRun을 삭제합니다.
예제: 네임스페이스에서 mytaskrun1
및 mytaskrun2
TaskRuns 삭제
$ tkn taskrun delete mytaskrun1 mytaskrun2 -n myspace
6.3.7.4. taskrun describe
TaskRun을 설명합니다.
예제: 네임스페이스의 mytaskrun
TaskRun 설명
$ tkn taskrun describe mytaskrun -n myspace
6.3.7.5. taskrun list
TaskRun을 나열합니다.
예제: 네임스페이스의 모든 TaskRun 나열
$ tkn taskrun list -n myspace
6.3.7.6. taskrun logs
TaskRun 로그를 표시합니다.
예제: 네임스페이스에서 mytaskrun
TaskRun의 실시간 로그 표시
$ tkn taskrun logs -f mytaskrun -n myspace
6.3.8. 상태 관리 명령
6.3.8.1. condition
상태를 관리합니다.
예제: 도움말 표시
$ tkn condition --help
6.3.8.2. condition delete
상태를 삭제합니다.
예제: 네임스페이스에서 mycondition1
상태를 삭제합니다.
$ tkn condition delete mycondition1 -n myspace
6.3.8.3. condition describe
상태를 설명합니다.
예제: 네임스페이스의 mycondition1
상태 설명
$ tkn condition describe mycondition1 -n myspace
6.3.8.4. condition list
상태를 나열합니다.
예제: 네임스페이스의 상태 나열
$ tkn condition list -n myspace
6.3.9. 파이프라인 리소스 관리 명령
6.3.9.1. resource
파이프라인 리소스를 관리합니다.
예제: 도움말 표시
$ tkn resource -h
6.3.9.2. resource create
파이프라인 리소스를 생성합니다.
예제: 네임스페이스에서 파이프라인 리소스 생성
$ tkn resource create -n myspace
이 명령은 리소스 이름, 리소스 유형, 리소스 유형 기반 값 입력을 요청하는 대화형 명령입니다.
6.3.9.3. resource delete
파이프라인 리소스를 삭제합니다.
예제: 네임스페이스에서 myresource
파이프라인 리소스를 삭제합니다.
$ tkn resource delete myresource -n myspace
6.3.9.4. resource describe
파이프라인 리소스를 설명합니다.
예제: myresource
파이프라인 리소스 설명
$ tkn resource describe myresource -n myspace
6.3.9.5. resource list
파이프라인 리소스를 나열합니다.
예제: 네임스페이스의 모든 파이프라인 리소스 나열
$ tkn resource list -n myspace
6.3.10. ClusterTask 관리 명령
6.3.10.1. clustertask
ClusterTask를 관리합니다.
예제: 도움말 표시
$ tkn clustertask --help
6.3.10.2. clustertask delete
클러스터의 ClusterTask 리소스를 삭제합니다.
예제: mytask1
및 mytask2
ClusterTasks 삭제
$ tkn clustertask delete mytask1 mytask2
6.3.10.3. clustertask describe
ClusterTask를 설명합니다.
예제: mytask
ClusterTask 설명
$ tkn clustertask describe mytask1
6.3.10.4. clustertask list
ClusterTask를 나열합니다.
예제: ClusterTask 나열
$ tkn clustertask list
6.3.10.5. clustertask start
ClusterTask를 시작합니다.
예제: mytask
ClusterTask 시작
$ tkn clustertask start mytask
6.3.11. 트리거 관리 명령
6.3.11.1. eventlistener
EventListener를 관리합니다.
예제: 도움말 표시
$ tkn eventlistener -h
6.3.11.2. eventlistener delete
EventListener를 삭제합니다.
예제: 네임스페이스에서 mylistener1
및 mylistener2
EventListeners 삭제
$ tkn eventlistener delete mylistener1 mylistener2 -n myspace
6.3.11.3. eventlistener describe
EventListener를 설명합니다.
예제: 네임스페이스의 mylistener
EventListener 설명
$ tkn eventlistener describe mylistener -n myspace
6.3.11.4. eventlistener list
EventListener를 나열합니다.
예제: 네임스페이스의 모든 EventListener 나열
$ tkn eventlistener list -n myspace
6.3.11.5. triggerbinding
TriggerBinding을 관리합니다.
예제: TriggerBinding 도움말 표시
$ tkn triggerbinding -h
6.3.11.6. triggerbinding delete
TriggerBinding을 삭제합니다.
예제: 네임스페이스에서 mybinding1
및 mybinding2
TriggerBindings 삭제
$ tkn triggerbinding delete mybinding1 mybinding2 -n myspace
6.3.11.7. triggerbinding describe
TriggerBinding을 설명합니다.
예제: 네임스페이스의 mybinding
TriggerBinding 설명
$ tkn triggerbinding describe mybinding -n myspace
6.3.11.8. triggerbinding list
TriggerBinding을 나열합니다.
예제: 네임스페이스의 모든 TriggerBinding 나열
$ tkn triggerbinding list -n myspace
6.3.11.9. triggertemplate
TriggerTemplate을 관리합니다.
예제: TriggerTemplate 도움말 표시
$ tkn triggertemplate -h
6.3.11.10. triggertemplate delete
TriggerTemplate을 삭제합니다.
예제: 네임스페이스에서 mytemplate1
및 mytemplate2
TriggerTemplates 삭제
$ tkn triggertemplate delete mytemplate1 mytemplate2 -n `myspace`
6.3.11.11. triggertemplate describe
TriggerTemplate을 설명합니다.
예제: 네임스페이스의 mytemplate
TriggerTemplate 설명
$ tkn triggertemplate describe mytemplate -n `myspace`
6.3.11.12. triggertemplate list
TriggerTemplate을 나열합니다.
예제: 네임스페이스의 모든 TriggerTemplate 나열
$ tkn triggertemplate list -n myspace
6.3.11.13. clustertriggerbinding
Manage ClusterTriggerBindings.
예제: ClusterTriggerBinding 도움말 표시
$ tkn clustertriggerbinding -h
6.3.11.14. clustertriggerbinding delete
ClusterTriggerBinding을 삭제합니다.
예제: myclusterbinding1
및 myclusterbinding2
ClusterTriggerBindings 삭제
$ tkn clustertriggerbinding delete myclusterbinding1 myclusterbinding2
6.3.11.15. clustertriggerbinding describe
ClusterTriggerBinding을 설명합니다.
예제: myclusterbinding
ClusterTriggerBinding 설명
$ tkn clustertriggerbinding describe myclusterbinding
6.3.11.16. clustertriggerbinding list
ClusterTriggerBinding을 나열합니다.
예제: 모든 ClusterTriggerBinding 나열
$ tkn clustertriggerbinding list
7장. opm CLI
7.1. opm 정보
opm
CLI 툴은 Operator 번들 형식과 함께 사용할 수 있도록 Operator 프레임워크에서 제공합니다. 이 툴을 사용하면 소프트웨어 리포지토리와 유사한 인덱스라는 번들 목록에서 Operator 카탈로그를 생성하고 유지 관리할 수 있습니다. 결과적으로 인덱스 이미지라는 컨테이너 이미지를 컨테이너 레지스트리에 저장한 다음 클러스터에 설치할 수 있습니다.
인덱스에는 컨테이너 이미지 실행 시 제공된 포함 API를 통해 쿼리할 수 있는 Operator 매니페스트 콘텐츠에 대한 포인터 데이터베이스가 포함되어 있습니다. OpenShift Container Platform에서 OLM(Operator Lifecycle Manager)은 CatalogSource
오브젝트에서 인덱스 이미지를 카탈로그로 참조할 수 있으며 주기적으로 이미지를 폴링하여 클러스터에 설치된 Operator를 자주 업데이트할 수 있습니다.
추가 리소스
- 번들 형식에 대한 자세한 내용은 Operator Framework 패키징 형식을 참조하십시오.
- Operator SDK를 사용하여 번들 이미지를 생성하려면 번들 이미지 작업을 참조하십시오.
7.2. opm 설치
Linux, macOS 또는 Windows 워크스테이션에 opm
CLI 툴을 설치할 수 있습니다.
사전 요구 사항
Linux의 경우 다음 패키지를 제공해야 합니다. RHEL 8은 다음과 같은 요구 사항을 충족합니다.
-
podman
버전 1.9.3 이상(버전 2.0 이상 권장) -
glibc
버전 2.28 이상
-
절차
- OpenShift 미러 사이트로 이동하여 운영 체제와 일치하는 최신 tarball 버전을 다운로드합니다.
아카이브의 압축을 풉니다.
Linux 또는 macOS의 경우:
$ tar xvf <file>
- Windows의 경우 ZIP 프로그램으로 아카이브의 압축을 풉니다.
PATH
에 있는 임의의 위치에 파일을 배치합니다.Linux 또는 macOS의 경우:
PATH
를 확인합니다.$ echo $PATH
파일을 이동합니다. 예를 들면 다음과 같습니다.
$ sudo mv ./opm /usr/local/bin/
Windows의 경우:
PATH
를 확인합니다.C:\> path
파일을 이동합니다.
C:\> move opm.exe <directory>
검증
opm
CLI를 설치한 후 사용할 수 있는지 확인합니다.$ opm version
출력 예
Version: version.Version{OpmVersion:"v1.14.3-29-ge82c4649", GitCommit:"e82c4649b208cd0b08dbd5b88da55450f97b3a2d", BuildDate:"2021-02-13T02:20:52Z", GoOs:"linux", GoArch:"amd64"}
7.3. 추가 리소스
-
인덱스 이미지 생성, 업데이트, 정리를 비롯한
opm
프로시저는 사용자 정의 카탈로그 관리를 참조하십시오.