OpenShift상의 EE Builder with Ansible Automation Platform

Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/07/10/ee-builder-ansible-automation-platform-openshift

Red Hat Ansible Automation Platform 에서 Ansible 플레이북을 실행하는 핵심 구성 요소는 실행 환경입니다. 이러한 실행 환경은 여러 도메인과 대상에 걸친 자동화 에 필요한 다양한 컬렉션을 하나로 묶습니다 . 이러한 환경의 라이프사이클을 효과적으로 관리하는 것은 Ansible Automation Platform의 전반적인 운영에 있어 중요한 프로세스입니다.

프로세스 개요

현재 Ansible Automation Platform을 베어메탈, 가상 머신 또는 Red Hat OpenShift Container Platform 에 설치하든 , 이러한 실행 환경을 구축하려면 Linux 머신에 대한 액세스가 필요하며, 빌드 및 릴리스 프로세스를 관리하기 위한 외부 파이프라인을 구축해야 하는 경우가 많았습니다. 하지만 지금까지는 그렇지 않았습니다. OpenShift의 최신 기술 미리보기 기능을 통해 OpenShift의 User Namespaces에서 Ansible Automation Platform을 배포하고 실행하는 사용자는 이제 Ansible Automation Platform 내에서 실행 환경의 라이프사이클을 완벽하게 관리할 수 있습니다. 그 방법을 자세히 살펴보겠습니다.

사실상의 표준인 Ansible Builder와 함께 제공되는 Ansible Community of Practice Builder 역할을 활용하여 실행 환경을 구축할 것입니다. Ansible Builder는 Podman을 사용하여 실행 노드로 사용되는 컨테이너 이미지를 패키징합니다. OpenShift와 컨테이너 사용 경험이 있는 예리한 독자라면 이 부분이 다소 낯설게 느껴질 수 있습니다. OpenShift 컨테이너 내에서 Podman을 실행하려면 보안 제약 조건을 완화하여 사용자가 루트 권한이 없는 컨테이너를 실행할 수 있도록 해야 하는데, 이는 보안 문제를 야기하지 않을까요? 네, 지금까지는 그렇습니다.

OpenShift 4.17+에서 User Namespaces 기술 미리보기가 도입됨에 따라 이제 crun 컨테이너 런타임으로 활용할 수 있습니다. 사용자 지정 보안 컨텍스트 제약 조건을 생성하면 컨테이너 내에서 OpenShift Pod 내부에서 Podman을 실행할 수 있으며, 이를 통해 OpenShift에서 Ansible Builder를 실행할 수 있습니다. 이 문서에서는 Red Hat OpenShift Dev Spaces 에서 사용할 수 있도록 OpenShift에서 중첩 컨테이너를 활성화하는 방법을 보여주는 Gaurav, Peter, Charro의 훌륭한 작업을 기반으로 합니다. 활용할 내용, 특히 사용자 네임스페이스의 이점과 구현에 대한 배경 정보는 해당 문서를 참조하십시오. 이 문서에서는 Dev Spaces를 배포하지 않지만 개념은 완전히 동일합니다.

필수 조건

이 문서에서는 OpenShift 클러스터 버전 4.17 이상과 Ansible Automation Platform 2.5가 OpenShift에 배포되어 실행 중이라고 가정합니다. 프로덕션 환경에서는 다음 작업을 수행하지 않는 것이 좋습니다. 

OpenShift에서 기술 미리 보기를 활성화하면 클러스터를 이후 릴리스로 업그레이드할 수 없습니다. User Namespaces는 결국에는 일반 공급으로 출시되어 기술 미리 보기가 필요하지 않지만, 지금은 개념 증명으로 비생산 환경에 배포합니다.

OpenShift에서 실행되는 Ansible Automation Platform 외에도, 컴퓨터에서 실행되는 Podman과 Ansible Automation Platform에서 액세스할 수 있는 Git 저장소가 필요합니다.

OpenShift 구성

클러스터를 구성하여 User Namespaces를 활성화해 보겠습니다. 먼저, 기술 미리보기 기능 게이트를 활성화해야 합니다.

apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade

다음으로, 기본값 cri-o 대신 crun 컨테이너 런타임을 활성화합니다.

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: enable-crun-worker
spec:
 machineConfigPoolSelector:
   matchLabels:
  pools.operator.machineconfiguration.openshift.io/worker: ""
 containerRuntimeConfig:
   defaultRuntime: crun

그런 다음 컨테이너 내에서 Podman을 실행하는 데 필요한 기능을 허용하는 사용자 지정 보안 컨텍스트 제약 조건을 만듭니다.

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: nested-podman-scc
priority: null
allowPrivilegeEscalation: true
allowedCapabilities:
- SETUID
- SETGID
fsGroup:
  type: MustRunAs
  ranges:
  - min: 1000
    max: 65534
runAsUser:
  type: MustRunAs
  uid: 1000
seLinuxContext:
  type: MustRunAs
  seLinuxOptions:
    type: container_engine_t
supplementalGroups:
  type: MustRunAs
  ranges:
  - min: 1000
    max: 65534

다음으로, 실행 환경 빌더 작업에 특별히 사용할 서비스 계정을 생성합니다. 실행 중인 모든 Ansible Automation Platform 작업에 대한 승격된 권한을 부여하는 것이 아니라, 특정 빌더 작업에만 권한을 부여할 것이므로 default 서비스 계정을 사용하지 않습니다.

oc create sa automation-job-podman -n aap

마지막으로 새로 만든 보안 컨텍스트 제약 조건을 새 서비스 계정에 바인딩합니다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: automation-job-podman
  namespace: aap
subjects:
  - kind: ServiceAccount
    name: automation-job-podman
    namespace: aap
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: 'system:openshift:scc:nested-podman-scc'

이제 OpenShift를 구성했으므로 Ansible Automation Platform을 구성하고 실행 환경 빌더 작업을 위한 사용자 지정 러너 이미지를 빌드해 보겠습니다.

Ansible 자동화 플랫폼 구성

이 패턴과 해당 플레이북의 목적은 이전 문서의 작업을 기반으로  개발/빌드 서버를 설정하지 않고도 GitOps 방법론과 파이프라인을 사용하여 새로운 실행 및 의사 결정 환경을 구축하는 것입니다 . 지금까지 실행 환경을 구축하려면 가상 머신이나 실행기(Runner)와 같은 별도의 호스트, Ansible Automation Platform 외부 리소스, 또는 Ansible Automation Platform과 완전히 분리된 타사 파이프라인 및 도구가 필요했습니다. 이제 외부 호스트 및 도구에 대한 종속성을 제거하고 관리 기능을 플랫폼으로 다시 통합하여 OpenShift 기반으로 구축하고 Ansible Automation Platform에서 실행합니다.

Ansible Automation Platform 2.5의 GUI 내에서 Controller, Automation Hub, Event-Driven Ansible을 포함한 모든 플랫폼 구성 요소를 관리할 수 있습니다 . 이 연습에서는 Controller 구성 요소에 있는 Automation Execution 리소스와 Hub 구성 요소인 Automation Content에 있는 Pushing Execution Environment(EE)/Decision Environment(DE) 리소스를 생성합니다. 또한, 통합 GUI에서 세 가지 구성 요소 모두에 액세스할 수 있도록 Access Management 섹션에 사용자를 생성합니다.

앞으로 만들 모든 리소스는 Ansible의 핵심인 플레이북/룰북을 지원하기 위해서만 제작되었습니다. 이것이 바로 시작점입니다. 먼저, 프로덕션 환경이 아닌 Ansible Automation Platform 클러스터에서 프로젝트를 생성하겠습니다.

프로젝트 만들기

Ansible Automation Platform에서 그림 1과 같이 Infrastructure > Projects > Create Project 로 이동합니다.

프로젝트를 생성할 때 “Ansible EE Builder Stream”과 같이 의미 있는 이름을 지정하고 Default 조직에 할당하며,  Source control typ으로 Git을 선택합니다. 이 랩의 소스 제어 URL (https://github.com/na-launch/aap-ocp-ee-builder-stream )과  infra.ee_utilities 컬렉션의  ee_builder 역할을 활용하는 예제 플레이북이 포함된  저장소를 입력하여 계속 진행할 수 있습니다  .

여기서 강력한 기능 중 하나는 이 프로젝트에서 체크아웃할 코드의 브랜치 또는 태그를 정의하는 것입니다. 이 예시에서는 working  브랜치를 선택하고 “Update revision on launch“를 활성화하여  작업 템플릿이 실행될 때마다 정의된 브랜치의 최신 코드와 프로젝트를 동기화합니다. 

저장소는 종종 어떤 형태의 인증을 요구하며, 이 경우 프로젝트가 성공적으로 동기화되기 전에 자격 증명을 생성해야 합니다. 이 경우, 이 저장소는 공개 저장소입니다.

여기서는 실행 환경을 비워두겠지만, 이 프로젝트의 코드에 대한 실행 환경을 지정하지 않은 모든 작업 템플릿에 대해 특정 실행 환경을 사용하려는 경우 여기에서 정의하는 것이 좋습니다.

다음으로, 이 플레이북을 실행할 Job Template를 생성하기 전에  사용자 지정 실행 환경을 제공하고  Ansible Automation Platform과 OpenShift Container Platform 내에서 새로운 실행 환경을 빌드, 정의, 푸시하기 위한 Container Group를 정의합니다. 기본적으로 이러한 환경의 수명 주기를 관리합니다.

실행 환경 생성

실행 및 의사결정 환경은 기본적으로 플레이북 실행을 지원하는 데 필요한 시스템 패키지, Python 종속성, 그리고 Ansible 컬렉션을 포함하는 컨테이너 이미지입니다. 이러한 환경을 구축하기 위해 infra.ee_utilities.ee_builder 컬렉션과 역할을 활용합니다. 이 역할은 내부적으로 Ansible Builder Python 패키지를 사용합니다. Ansible Builder 라이브러리는 Podman을 사용하여 컨테이너 이미지를 구축하며, 이는 궁극적으로 최종 실행 또는 의사결정 환경이 됩니다. 이 모든 것을 구현하려면 필요한 모든 구성 요소를 포함하는 사용자 지정 컨테이너 이미지를 만들어야 합니다.

OpenShift Pod 내부에서 실행되고 빌더 플레이북이 실행되는 기반이 되는 기본 러너 이미지가 될 사용자 지정 컨테이너 이미지를 빌드해 보겠습니다. 이 이미지는 Ansible Builder를 실행하는 데 필요한 Podman in a Pod 기능을 제공합니다.

먼저 다음과 같은 내용으로 Containerfile을 만듭니다.

# Containerfile
FROM registry.fedoraproject.org/fedora-minimal:latest
ARG FLAVOR=stable
ENV UID=1000
ENV GID=0
ENV USERNAME="runner"
# This is to mimic the OpenShift behaviour of adding the dynamic user to group 0.
RUN useradd -G 0 $USERNAME
ENV USER_HOME=/home/${USERNAME}
ENV _CONTAINERS_USERNS_CONFIGURED=""
ENV BUILDAH_ISOLATION=chroot
COPY --chown=0:0 /entrypoint.sh /
ARG RPM_PACKAGES="ansible git buildah skopeo unzip podman fuse-overlayfs openssh-clients ucpp python3 python3-pip slirp4netns"
ARG PIP_PACKAGES="ansible-navigator ansible-builder ansible-runner"
ARG ANSIBLE_COLLECTIONS="infra.ee_utilities"
RUN dnf install -y ${RPM_PACKAGES} --exclude container-selinux \
  && dnf update -y \
  && dnf clean all \
  && pip3 install ${PIP_PACKAGES} \
  && ansible-galaxy collection install ${ANSIBLE_COLLECTIONS}
#
# Setup for root-less podman
#
RUN setcap cap_setuid+ep /usr/bin/newuidmap \
  && setcap cap_setgid+ep /usr/bin/newgidmap \
  && touch /etc/subgid /etc/subuid \
  && chown 0:0 /etc/subgid \
  && chown 0:0 /etc/subuid \
  && chown 0:0 /etc/passwd \
  && chown 0:0 /etc/group \
  && chmod +x /entrypoint.sh \
  && chmod -R g=u /etc/passwd /etc/group /etc/subuid /etc/subgid /home
COPY --chmod=644 /containers.conf /etc/containers/containers.conf
# Make and set the working directory
RUN mkdir -p ${USER_HOME}/.config/containers \
  && mkdir -p ${USER_HOME}/.local/share/containers \
  && chown -R $USERNAME:$GID -R ${USER_HOME}
# Copy & modify the defaults to provide reference if runtime changes needed.
# Changes here are required for running with fuse-overlay storage inside container.
RUN sed -e 's|^#mount_program|mount_program|g' \
  -e '/additionalimage.*/a "/var/lib/shared",' \
  -e 's|^mountopt[[:space:]]*=.*$|mountopt = "nodev,fsync=0"|g' \
  /usr/share/containers/storage.conf \
  > /etc/containers/storage.conf 
# Note VOLUME options must always happen after the chown call above
# RUN commands can not modify existing volumes
VOLUME /var/lib/containers
RUN mkdir -p /var/lib/shared/overlay-images \
  /var/lib/shared/overlay-layers \
  /var/lib/shared/vfs-images \
  /var/lib/shared/vfs-layers \
  && touch /var/lib/shared/overlay-images/images.lock \
  && touch /var/lib/shared/overlay-layers/layers.lock \
  && touch /var/lib/shared/vfs-images/images.lock \
  && touch /var/lib/shared/vfs-layers/layers.lock
RUN mkdir /runner \
  && chown -R $USERNAME:$GID /runner
WORKDIR /home/runner
USER $USERNAME
ENTRYPOINT [ "/entrypoint.sh" ]
CMD [ "tail", "-f", "/dev/null" ]

다음으로 Containerfile 옆에 containers.conf 파일을 만들어야 합니다 . 이 containers.conf 파일에는 OpenShift Pod 컨테이너 내부에서 Podman을 실행하는 데 필요한 구성 변경 사항이 포함되어 있습니다 .

# containers.conf
[containers]
cgroupns="host"
cgroups="disabled"
default_sysctls = []
ipcns="host"
log_driver = "k8s-file"
netns="host"
userns="host"
utsns="host"
volumes = [
"/proc:/proc",
]
[engine]
cgroup_manager = "cgroupfs"
events_logger="file"
runtime="crun"

다음 entrypoint.sh파일은 다음과 같습니다.

#!/usr/bin/env bash
USER=$(whoami)
START_ID=$(($(id -u) + 1))
END_ID=$((65536 - ${START_ID}))
echo "${USER}:${START_ID}:${END_ID}" >/etc/subuid
echo "${USER}:${START_ID}:${END_ID}" >/etc/subgid
/usr/libexec/podman/catatonit -- "$@"

마지막으로, 결과 컨테이너 이미지를 빌드하고 태그를 지정하고 Ansible Automation Platform의 콘텐츠 허브에 푸시합니다.

podman build --arch amd64 --file Containerfile --tag ee-builder-runner-openshift:latest
podman login platform-one-aap.apps.blinker.sandbox2589.opentlc.com 
podman push localhost/ee-builder-runner-openshift:latest docker://platform-one-aap.apps.blinker.sandbox2589.opentlc.com/ee-builder/ee-builder-runner-openshift:latest

다음으로 새로 만든 컨테이너 이미지를 가져와 자동화 실행에 사용할 실행 환경으로 추가합니다.  

이제 EE가 게시되어 Automation Hub 레지스트리에 사용 가능해졌으므로, Controller에서 템플릿 또는 프로젝트의 Automation Execution을 위한 실행 환경  리소스 도 생성해야 합니다  . 새 이미지에 태그가 제대로 지정되도록 Controller에서 다음 작업을 수행하는 것이 좋습니다.

1. 통합 GUI의  Automation Content 구성 요소 로 이동하여 Execution Environments을 선택한 다음 새로 푸시된 EE( ee-builder-pipeline/ee-builder-runner-openshift ) 를 선택합니다 .
2. 그림 2에 표시된 대로 Images 탭을 선택합니다 .

3. “ee-builder-runner-openshift”와 같이 의미 있는 이름과 설명을 입력하세요. 테스트를 위해 Default 구성을 선택했지만, 더 중요한 것은 이미지 정의와 풀 정책입니다.

이미지에 대한 지속적인 테스트를 수행하지 않는 한,  Only pull when image is not present before running를 선택하면 작업이 실행될 때마다 이미지를 가져오지 않아도 되므로 좋은 옵션입니다.

이미지 섹션에서 검사할 때 Ansible Automation Platform의 콘텐츠 허브로 가는 경로, 이미지 이름, 버전 태그(예: platform-one-aap.apps.blinker.sandbox2589.opentlc.com/ee-builder/ee-builder-runner-openshift:latest)를 포함한 전체 이미지 위치를 검사합니다.

컨테이너 그룹 만들기

컨테이너 그룹은 특정 컨테이너 그룹에서 작업을 실행할 수 있는 강력한 기능으로, 노드를 지정할 수 있는 인스턴스 그룹과 유사합니다. 컨테이너 그룹을 생성할 때 OpenShift가 이미지 실행을 위해 실행할 Pod에 대한 사용자 지정 Pod 사양을 정의할 수도 있습니다. Pod 사양에는 해당 컨테이너 내에서 Podman을 실행하는 데 필요한 추가 기능이 추가됩니다. 컨테이너 그룹을 생성하려면 다음 단계를 따르세요.

1. 그림 3에 표시된 대로 Automation Execution > Infrastructure > Instance Groups > Create group 로 이동합니다 .

이 예에서는 작업 템플릿 실행을 담당할 사용자 지정 컨테이너 그룹에 대한 사용자 지정 포드 사양을 정의합니다. 이를 통해 새로운 실행 및 의사 결정 환경을 자동으로 생성하고 원하는 저장소 또는 허브에 푸시하는 파이프라인을 구축할 수 있습니다.

2. 사용자 정의 포드 사양을 정의합니다.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    io.kubernetes.cri-o.Devices: /dev/fuse,/dev/net/tun #(1)
  namespace: aap
  labels:
    ansible_job: ''
spec:
  hostUsers: false #(2)
  serviceAccountName: automation-job-podman #(3)
  automountServiceAccountToken: false
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector: #(4)
              matchExpressions:
                - key: ansible_job
                  operator: Exists
            topologyKey: kubernetes.io/hostname
  containers:
    - name: worker
      securityContext: #(5)
        capabilities:
          add:
            - SETUID
            - SETGID
        runAsUser: 1000
        runAsNonRoot: true
        allowPrivilegeEscalation: true
        procMount: Unmasked
      args: #(6)
        - ansible-runner
        - worker
        - '--private-data-dir=/runner'
      resources:
        requests:
          cpu: 250m
          memory: 100Mi

3. Podman 오버레이 파일 시스템과 권한이 없는 네트워크 네임스페이스를 위한 /dev/fuse와 /dev/tun을 추가 합니다 .
4. 컨테이너가 OpenShift 기본 범위를 벗어난 UID로 실행될 수 있도록 hostUsers를 비활성화합니다.
5. 사용자 정의 보안 컨텍스트 제약 조건에 바인딩된 서비스 계정으로 실행되도록 지정합니다.
6. 컨테이너 그룹이 사용자 정의 Pod 사양을 선택할 수 있도록 레이블 선택기를 추가합니다.
7. 컨테이너 내에서 Podman을 실행하는 데 필요한 추가 기능을 추가합니다.
8. 사용자 정의 빌더 이미지의 작업 디렉토리를 제공하여 ansible-runner에 추가 인수를 전달합니다.

작업 템플릿 만들기

이제 프로젝트에서 플레이북을 실행하는 작업 템플릿을 만드는 데 필요한 필수 리소스가 정의되었습니다. 작업 템플릿을 만들려면 다음 지침을 따르세요.

1. Automation Execution > Templates > Create Job templates 으로 이동합니다 . 그림 4와 같이 Edit EE Builder Stream Survey 페이지가 나타납니다 .

2. 이 페이지의 양식을 다음과 같이 작성하세요.
   • Playbook: 실행할 플레이북에 대해 ‘EE Builder Stream Survey’라는 작업 템플릿을 만듭니다. 먼저  ee_builder_survey.yml 플레이북을 선택합니다.
   • Execution Environment:  ee-builder-runner-openshift라 부르는 방금 만든 사용자 지정 실행 환경을 선택합니다.
   • Instance Group:   ansible_builder라는 컨테이너 그룹을 선택합니다.
   • Credentials:  이 부분은 관리자가 아닌 사용자를 Automation Hub에 인증하고 권한을 부여하는 방법이므로 나중에 다시 살펴보겠습니다. 하지만 지금은 작업 템플릿 초기화에 영향을 미치지 않으므로 비워 두겠습니다.
   • Labels: ansible_job 컨테이너 그룹에 대해 생성한 사용자 정의 포드 사양에서 선택할 수 있도록 템플릿에 대한 레이블을 만드는 것이 중요합니다.
3. 새로 만든 작업 템플릿을 열고 Survey 탭을 선택하여 다음 질문으로 새 설문 조사를 만들고 Survey enabled 확인란을 선택합니다.
   • Question: Execution or Decision Environment type 이름 : text, default: ee-fedora-test
   • Question: Galaxy Collections type 목록: text, default: infra.aap_configuration

작업 템플릿이 생성되었으므로 이제 액세스 관리에 대한 권장 사례와 기본 제공 역할 기반 액세스 제어(RBAC)를 활용하여 컨테이너 그룹의 재정의된 Pod 사양에서 권한이 상승된 이 작업을 실행할 수 있는 사용자를 제한하는 방법을 살펴보겠습니다.

사용자 및 RBAC 생성

사용자와 RBAC를 생성하려면 다음 단계를 따르세요.

1. Access Management > Users 로 이동합니다 (그림 5).

이 예에서는 관리자가 아니고 최소 권한의 권장 관행에 따라 다음 역할만 갖는 EE-Builder 라는 새 사용자를 만듭니다  .

2. 사용자 페이지에서 EE-Builder > Roles 로 이동합니다 .

먼저, ‘Automation Execution‘ 탭에서 작업 템플릿 리소스에만 “JobTemplate Execute” 역할을 부여합니다. 다음으로, ‘Automation Content‘ 탭에서 실행 환경 리소스에만 “owner” 역할을 부여합니다(그림 6).

이렇게 하면 RBAC를 통해 사용자가 작업을 실행하는 데 필요한 리소스에만 접근하고, 새로운 EE/DE를 자동화 허브에 푸시하여 즉시 사용할 수 있도록 제한합니다. 이 사용자는 이 제한된 RBAC를 통해 프로젝트를 보거나 다른 자동화를 실행할 수 없습니다.

자격 증명 만들기

자격 증명을 생성하려면 Automation Execution > Infrastructure > Credentials 으로 이동합니다 (그림 7).

마지막으로, Ansible Automation Platform에 내장된 자격 증명 유형을 사용하여 자격 증명을 생성합니다  . 이 예에서는 EE-Builder 사용자의 사용자 이름과 비밀번호, 그리고 Ansible Automation Platform의 Fully Qualified Domain Name(FQDN)을 전달합니다. 이 자격 증명을 작업 템플릿에 포함하면 실행된 플레이북에 이러한 변수와 비밀 정보를 안전하게 삽입할 수 있으며, 이를 통해 해당 사용자의 자동화 콘텐츠 네임스페이스에서 EE/DE를 푸시하고 관리할 수 있습니다. 

함께 가져와

이러한 각 리소스와 구성 요소를 성공적으로 구성한 후 새 프로세스를 활용하는 두 가지 페르소나를 살펴볼 수 있습니다.

• 플랫폼 관리자는 자동화 콘텐츠를 사용하는 사용자와 파이프라인을 생성, 유지 관리하고 관리할 수 있습니다.
• 플랫폼 소비자는 자동화된 방식으로 실행 및 의사 결정 환경을 만들고, 공유하고, 개발할 수 있습니다.

예를 들어 이 실험실을 살펴보겠습니다.

1. 플랫폼 관리자는 ee_builder_survey.yml라 부르는 플레이북을 저장하는 GitHub 저장소를 소유하게 됩니다.
2. 플랫폼 관리자는 또한 Ansible Automation Platform에서 작업 템플릿을 제어하는데, 여기에는 작업 실행 전에 플랫폼 소비자가 완료해야 하는 설문 조사가 포함됩니다.
3. 설문조사를 통해 EE-Builder 역할은 설문조사 질문에 답하고 플레이북에 대한 입력을 사용자 정의할 수 있으며, 이 경우 실행 환경 이미지를 사용자 정의할 수 있습니다.
4. 설문조사를 통해 플랫폼 관리자는 EE-Builder 역할에 따라 사용자 정의 또는 수정 가능한 항목에 대한 가드레일을 설정할 수도 있습니다.
5. 플랫폼 관리자는 Automation Hub에서 실행 및 의사 결정 환경을 게시하고 공유하기 위한 네임스페이스를 소유합니다.
6. 간단한 RBAC를 통해 설문 조사를 통해 사용자 정의가 허용되는 범위에 대한 유연성을 제공하며, 필요한 작업과 네임스페이스에만 권한을 부여합니다.

빌더 작업 실행

이제 가능성의 예술과 GitOps 방법론을 결합하여 실행 및 의사 결정 환경의 수명 주기를 관리하는 엔드투엔드 프로세스를 구축했습니다. 빌더 작업을 실행하여 실행 또는 의사 결정을 빌드하고 Content Hub에 푸시하는 전체 엔드투엔드 흐름을 테스트해 보겠습니다.

개발자나 NetOps 엔지니어가 Terraform을 사용하여 일부 기기에 프로비저닝을 목표로 Ansible 플레이북을 작성한다고 상상해 보세요. Terraform 개발 속도를 높이기 위해 커뮤니티의 cloud.terraform 컬렉션을 활용하고 사용 가능한 역할을 사용할 수 있습니다.

Ansible 관리자는 이러한 설명된 단계를 따르고 DevNetSecOps 엔지니어에게 RBAC(위에서 설명)가 정의된 자체 자격 증명을 제공했습니다.

DevNetSecOps 엔지니어가 플레이북을 신속하게 개발하고 테스트하기 위해 취할 수 있는 단계는 다음과 같습니다.

1. EE-Builder 사용자로 로그인하고 Templates 으로 이동하면 RBAC로 인해 작업 템플릿이 하나만 표시되는 것을 볼 수 있습니다.
2. 직무 템플릿을 실행하고 플레이북과 목적에 맞는 설문조사를 작성하세요.  인프라 프로비저닝과 구성을 통합하기 위해 Ansible과 Terraform을 사용하고 있으므로 cloud.terraform 컬렉션을 사용하고 싶습니다. EE/DE의 이름을 지정할 때 언급하는 것이 좋습니다. EE가 구축되는 기본 이미지와 설치되는 특정 패키지 또는 컬렉션의 용도를 함께 나타내는 것이 좋습니다. DevSecNetOps 엔지니어는 가장 작은 기본 이미지를 선택하여 기본 이미지와 랩의 컬렉션 또는 용도를 나타내는 이름을 지정할 수 있습니다(그림 8).

이는 RBAC 패턴을 강조하고 작업 템플릿에서 설문 조사를 활용하여 Ansible Automation Platform에서 더 많은 기능과 역량을 얻는 힘을 보여주기 위한 간단한 설문 조사 예입니다.  

DevSecNetOps 엔지니어는 실행하기 전에 규칙집/플레이북에 전달되는 변수와 값을 검토할 기회를 갖게 됩니다.

기본 이미지의 크기, 추가되는 요구 사항의 수, 운영 환경은 모두 작업이 실행되는 시간에 영향을 미칠 수 있습니다.  

플랫폼 관리자는 초기 설정 이후 현재까지 DevSecNetOps 엔지니어와 EE 구축 또는 플레이북 개발에 대한 상호 작용을 하지 않았습니다.

플랫폼 관리자는 문제 해결이나 추가 로깅 목적으로 OpenShift의 aap 네임스페이스에서 Pod를 확인할 수 있습니다.

$ oc get pods -n aap | grep -i job

작업이 성공적으로 완료되면 DevSecNetOps 엔지니어는 작업 템플릿의 출력을 검토하여 플레이북 출력의 세부 정보를 확인할 수 있습니다. Ansible Automation Platform 알림 및 승인 워크플로와의 통합을 통해 이러한 패턴을 보완하고 RBAC 기능을 더욱 향상시킬 뿐만 아니라, 개발자에서 최고 승인자까지의 수동 상호 작용을 없애기 위해 더 많은 페르소나를 간소화할 수 있습니다(그림 9).

다른 DevSecNetOps 엔지니어가 EE/DE를 얼마나 많이 생성했는지에 따라 여기에 여러 개가 나열될 수 있습니다. 자동화 거버넌스 정책을 사용하여 조직 내 네임스페이스 규칙을 문서화하는 것이 좋습니다.

ee_builder 역할과 플랫폼 관리자의 구성의 결과로 이제 통합 UI의 Automation Content > Execution Environments (그림 10) 에서 볼 수 있는 자동화 허브에서 사용 가능한 새 실행 환경 또는 새 버전을 찾을 수 있습니다 .

새로 설치된 컬렉션을 확인하기 위해 Automation Hub에서 로컬 노트북으로 이미지를 직접 가져와 보겠습니다. 새로 생성하고 푸시한 EE의  Images 탭에서 podman push 명령을 복사합니다.

DevSecNetOps 엔지니어는 개발 또는 운영 요구 사항과 환경에 따라 ansible-navigator를 사용하거나 Podman과 ansible-galaxy 명령을 함께 사용하여 이미지를 검사할 수 있습니다 .

$ podman run -it --rm platform.one.app.apps.blinker.sandbox542.opentlc.com/ee-builder-pipeline/ubi9-builder-cloud-terraform:latest bash
$ ansible-galaxy collection list | grep -i terraform
cloud.terraform.3.0.0

이 패턴은 플랫폼 관리자와 DevSecNetOps 엔지니어를 하나로 모으고, 각자의 워크플로와 책임을 반복 가능하고 확장 가능한 방식으로 연결합니다. 이를 기반으로 DevSecNetOps 개발자의 업무 속도를 높이고 역량을 강화하는 동시에 플랫폼 소유자의 반복적인 수동 구성 및 관리 부담을 줄여줍니다.

마무리

모든 요소가 준비됨에 따라, 이제 Ansible Automation Platform은 OpenShift에서 실행 및 의사 결정 환경을 구축하고, 그 결과 환경 이미지를 Ansible Automation Platform의 콘텐츠 허브에 저장하는 작업을 담당하게 되었습니다. 이러한 환경의 라이프사이클을 조율하는 작업은 이제 외부 파이프라인, 빌드 도구 또는 컨테이너 레지스트리에 의존하지 않고 플랫폼 내에서 완벽하게 이루어집니다. 이는 독립적인 솔루션입니다. 

이 기능은 현재 사용자 네임스페이스의 기술 미리보기에서만 사용할 수 있습니다. 이 문서가 게시될 당시에는 공식적으로 지원되는 기능이 아닙니다. 하지만 이 글을 통해 어떤 기능이 가능한지, 그리고 향후 일반적으로 사용 가능하고 지원되는 기능이 될 수 있는지 대략적으로 파악할 수 있을 것입니다.