5.4. Ansible 기반 Operator 생성
이 가이드에서는 Operator SDK의 Ansible 지원을 간략하게 설명하고 Ansible 플레이북 및 모듈을 사용하는 operator-sdk CLI 툴을 사용하여 Ansible 기반 Operator를 빌드하고 실행하는 예제를 안내합니다.
5.4.1. Operator SDK의 Ansible 지원
Operator 프레임워크는 Operator라는 Kubernetes 네이티브 애플리케이션을 효율적이고 확장 가능하며 자동화된 방식으로 관리하는 오픈 소스 툴킷입니다. 이 프레임워크에는 개발자가 Kubernetes API 복잡성에 대한 지식이 없어도 전문 지식을 기반으로 Operator를 부트스트래핑하고 빌드할 수 있도록 지원하는 Operator SDK가 포함되어 있습니다.
Operator 프로젝트를 생성하기 위한 Operator SDK 옵션 중 하나는 Go 코드를 작성하지 않고도 기존 Ansible 플레이북 및 모듈을 활용하여 Kubernetes 리소스를 통합 애플리케이션으로 배포하는 것입니다.
5.4.1.1. 사용자 정의 리소스 파일
Operator는 Kubernetes 확장 메커니즘인 CRD(사용자 정의 리소스 정의)를 사용하므로 CR(사용자 정의 리소스)이 기본 제공되는 네이티브 Kubernetes 오브젝트처럼 보이고 작동합니다.
CR 파일 형식은 Kubernetes 리소스 파일입니다. 오브젝트에는 필수 및 선택적 필드가 있습니다.
표 5.1. 사용자 정의 리소스 필드
| 필드 | 설명 |
|---|---|
|
| 생성할 CR의 버전입니다. |
|
| 생성할 CR의 종류입니다. |
|
| 생성할 Kubernetes별 메타데이터입니다. |
|
| Ansible에 전달되는 변수의 키-값 목록입니다. 이 필드는 기본적으로 비어 있습니다. |
|
|
오브젝트의 현재 상태를 요약합니다. Ansible 기반 Operator의 경우 CRD에 대해 |
|
| CR에 추가할 Kubernetes별 주석입니다. |
다음 CR 주석 목록은 Operator의 동작을 수정합니다.
표 5.2. Ansible 기반 Operator 주석
| 주석 | 설명 |
|---|---|
|
|
CR 조정 간격을 지정합니다. 이 값은 표준 Golang 패키지 |
Ansible 기반 Operator 주석의 예
apiVersion: "test1.example.com/v1alpha1" kind: "Test1" metadata: name: "example" annotations: ansible.operator-sdk/reconcile-period: "30s"
5.4.1.2. watches.yaml 파일
GVK(그룹/버전/종류)는 Kubernetes API의 고유 ID입니다. watches.yaml 파일에는 GVK로 확인하는 CR(사용자 정의 리소스)에서 Ansible 역할 또는 플레이북으로의 매핑 목록이 포함됩니다. Operator는 이 매핑 파일이 미리 정의된 위치(/opt/ansible/watches.yaml)에 있을 것으로 예상합니다.
표 5.3. watches.yaml 파일 매핑
| 필드 | 설명 |
|---|---|
|
| 조사할 CR 그룹입니다. |
|
| 조사할 CR 버전입니다. |
|
| 조사할 CR의 종류입니다. |
|
|
컨테이너에 추가된 Ansible 역할의 경로입니다. 예를 들어 |
|
|
컨테이너에 추가된 Ansible 플레이북의 경로입니다. 이 플레이북은 역할을 호출하는 방법이 될 것으로 예상됩니다. 이 필드는 |
|
| 지정된 CR에 대한 조정 간격, 즉 역할 또는 플레이북이 실행되는 간격입니다. |
|
|
|
watches.yaml 파일의 예
- version: v1alpha1 1 group: test1.example.com kind: Test1 role: /opt/ansible/roles/Test1 - version: v1alpha1 2 group: test2.example.com kind: Test2 playbook: /opt/ansible/playbook.yml - version: v1alpha1 3 group: test3.example.com kind: Test3 playbook: /opt/ansible/test3.yml reconcilePeriod: 0 manageStatus: false
5.4.1.2.1. 고급 옵션
GVK별 watches.yaml 파일에 고급 기능을 추가하여 사용할 수 있습니다. 해당 기능은 group, version, kind, playbook 또는 role 필드로 이동할 수 있습니다.
일부 기능은 해당 CR의 주석을 사용하여 리소스별로 덮어쓸 수 있습니다. 덮어쓸 수 있는 옵션에는 아래에 지정된 주석이 있습니다.
표 5.4. 고급 watches.yaml 파일 옵션
| 기능 | YAML 키 | 설명 | 덮어쓸 주석 | 기본값 |
|---|---|---|---|---|
| 기간 조정 |
| 특정 CR에 대한 조정 실행 간격입니다. |
|
|
| 상태 관리 |
|
Operator에서 각 CR |
| |
| 종속 리소스 조사 |
| Operator에서 Ansible을 통해 생성한 리소스를 동적으로 조사할 수 있습니다. |
| |
| 클러스터 범위 리소스 조사 |
| Operator에서 Ansible을 통해 생성한 클러스터 범위 리소스를 조사할 수 있습니다. |
| |
| 최대 실행기 아티팩트 수 |
| Ansible Runner에서 각 개별 리소스에 대해 Operator 컨테이너에 보관하는 아티팩트 디렉터리의 수를 관리합니다. |
|
|
고급 옵션이 있는 watches.yml 파일의 예
- version: v1alpha1 group: app.example.com kind: AppService playbook: /opt/ansible/playbook.yml maxRunnerArtifacts: 30 reconcilePeriod: 5s manageStatus: False watchDependentResources: False
5.4.1.3. Ansible로 전송된 추가 변수
추가 변수는 Ansible로 보낸 다음 Operator에서 관리할 수 있습니다. CR(사용자 정의 리소스)의 spec 섹션은 키-값 쌍을 추가 변수로 전달합니다. 이는 ansible-playbook 명령에 전달된 추가 변수와 동일합니다.
또한 Operator는 CR 이름 및 CR 네임스페이스에 대한 meta 필드에 추가 변수를 전달합니다.
다음 CR 예제의 경우
apiVersion: "app.example.com/v1alpha1" kind: "Database" metadata: name: "example" spec: message: "Hello world 2" newParameter: "newParam"
Ansible에 추가 변수로 전달되는 구조는 다음과 같습니다.
{ "meta": {
"name": "<cr_name>",
"namespace": "<cr_namespace>",
},
"message": "Hello world 2",
"new_parameter": "newParam",
"_app_example_com_database": {
<full_crd>
},
}
message 및 newParameter 필드는 최상위 레벨에서 추가 변수로 설정되며, meta는 Operator에 정의된 CR에 대한 관련 메타데이터를 제공합니다. meta 필드는 Ansible의 점 표기법을 사용하여 액세스할 수 있습니다. 예를 들면 다음과 같습니다.
- debug:
msg: "name: {{ meta.name }}, {{ meta.namespace }}"5.4.1.4. Ansible Runner 디렉터리
Ansible Runner는 컨테이너에서 실행되는 Ansible에 대한 정보를 보관합니다. 해당 정보는 /tmp/ansible-operator/runner/<group>/<version>/<kind>/<namespace>/<name>에 있습니다.
추가 리소스
-
runner디렉터리에 대한 자세한 내용은 Ansible Runner 설명서를 참조하십시오.
