• 목록

1. 개요

이 게시글에서는 Ansible EE가 무엇인가에 대한 문서를 살펴보고, 예시만 안내드리는 글입니다.

1.1. Ansible 실행 환경(Execution Environments) 시작하기

최신 소프트웨어 애플리케이션과 마찬가지로, 이제 Ansible 자동화 역시 컨테이너 기술을 기반으로 실행할 수 있습니다. 현업에서 Ansible을 사용하다 보면 컨트롤 노드의 파이썬 버전이나 라이브러리 의존성 문제로 골머리를 앓았던 경험, 다들 한 번쯤은 있으실 겁니다. 바로 이러한 문제를 해결하기 위해 등장한 것이 실행 환경(Execution Environments, 이하 EE)입니다.

Ansible은 EE라고 알려진 컨테이너 이미지를 컨트롤 노드로 사용합니다. EE는 자동화 프로젝트의 확장을 방해하는 복잡성을 제거하고, 배포와 같은 운영 작업을 훨씬 더 간단하고 예측 가능하게 만들어 줍니다. 더 이상 운영체제나 주변 환경에 따라 자동화 실행 결과가 달라지는 일을 걱정하지 않아도 됩니다.

실행 환경 이미지는 기본적으로 다음과 같은 핵심 패키지를 포함하고 있습니다. 이 패키지들은 EE의 근간을 이루며, 일관된 실행을 보장하는 역할을 합니다.

1.2. EE 표준 구성 요소

- ansible-core: Ansible의 핵심 엔진입니다. 플레이북을 파싱하고 실행하는 기본적인 기능이 모두 여기에 담겨 있습니다.

- ansible-runner: Ansible 실행을 위한 표준화된 인터페이스를 제공하는 도구입니다. 복잡한 Ansible 명령을 추상화하고, 실행 결과나 아티팩트를 구조화된 방식으로 관리할 수 있게 도와줍니다.

- Python: ansible-core와 컬렉션들이 실행되는 기반이 되는 언어입니다. EE는 격리된 Python 환경을 제공하여 버전 충돌 문제를 원천적으로 차단합니다.

- Ansible 콘텐츠 의존성: 컬렉션이나 롤이 필요로 하는 기본적인 라이브러리들이 포함됩니다.

표준 패키지 외에도, 특정 목적에 맞게 EE를 맞춤 제작할 수 있습니다. 예를 들어, 데이터베이스 자동화를 위한 EE를 만든다면 관련 컬렉션과 파이썬 라이브러리를 추가할 수 있습니다.

1.3. EE 맞춤형 추가 구성 요소

- 하나 이상의 Ansible 컬렉션 및 그 의존성: 예를 들어 네트워크 장비 자동화를 위해 `cisco.ios` 컬렉션을, 클라우드 관리를 위해 `amazon.aws` 컬렉션을 추가할 수 있습니다.

- 기타 사용자 정의 구성 요소: 조직 내부의 보안 규정을 준수하기 위한 특정 시스템 라이브러리나 스크립트 등을 포함시킬 수 있습니다.

이 시작 가이드에서는 간단한 실행 환경을 구축하고 테스트하는 방법을 보여줍니다. 결과적으로 생성될 컨테이너 이미지는 표준 EE 패키지, `community.postgresql` 컬렉션, 그리고 `psycopg2-binary` Python 패키지를 포함하는 완벽한 Ansible 컨트롤 노드를 나타냅니다.

2. 실행 환경(EE) 소개

Ansible 실행 환경은 컨테이너화가 제공하는 모든 이점을 활용하여 기존의 복잡성 문제를 해결하는 것을 목표로 합니다. 시니어 운영자로서 우리는 시스템 간의 미묘한 차이가 얼마나 큰 장애로 이어질 수 있는지 잘 알고 있습니다. EE는 이러한 문제를 해결하기 위한 강력한 해답입니다.

2.1. 복잡성 감소

EE가 복잡성을 줄일 수 있는 세 가지 주요 영역은 소프트웨어 의존성, 이식성, 그리고 콘텐츠 분리입니다. 이 세 가지는 자동화 환경을 관리할 때 가장 많은 시간이 소요되는 부분이기도 합니다.

2.1.1. 의존성 문제 해결

모든 소프트웨어 애플리케이션에는 의존성이 있으며, Ansible도 예외는 아닙니다. 이러한 의존성에는 소프트웨어 라이브러리, 설정 파일 또는 다른 서비스 등이 포함될 수 있습니다. 전통적으로 관리자들은 RPM이나 Python-pip과 같은 패키지 관리 도구를 사용하여 운영 체제 위에 애플리케이션 의존성을 직접 설치했습니다.

이러한 접근 방식의 가장 큰 단점은 애플리케이션이 기본적으로 제공되는 것과 다른 버전의 의존성을 요구할 수 있다는 점입니다. 예를 들어, 시스템에 설치된 파이썬은 3.6인데, 특정 Ansible 컬렉션은 파이썬 3.8 이상을 요구하는 상황이 발생할 수 있습니다. 이 경우, 운영체제 전체의 파이썬 버전을 변경하는 것은 매우 위험하고 어려운 일입니다.

Ansible의 일반적인 설치는 `ansible-core`와 여러 Ansible 컬렉션으로 구성됩니다. 이들 중 다수는 제공하는 플러그인, 모듈, 롤 및 플레이북에 대한 의존성을 가지고 있습니다. Ansible 컬렉션은 다음과 같은 소프트웨어 및 버전에 의존할 수 있습니다.

- `ansible-core`의 특정 버전

- 특정 버전의 Python

- Python 패키지 (예: requests, boto3)

- 시스템 패키지 (예: libselinux-python)

- 다른 Ansible 컬렉션

이러한 의존성은 모두 컨트롤 노드에 설치되어야 하며, 때로는 서로 충돌할 수도 있습니다. 예를 들어, 컬렉션 A는 `requests` 라이브러리 2.20 버전을 요구하고, 컬렉션 B는 2.25 버전을 요구하는 경우, 두 컬렉션을 동시에 사용하는 것은 매우 까다로워집니다.

이러한 의존성 문제를 '부분적으로' 해결하는 한 가지 방법은 Ansible 컨트롤 노드에서 Python 가상 환경을 사용하는 것입니다. 하지만 Ansible에 적용할 경우, 가상 환경은 단점과 명백한 한계를 가집니다. 시스템 레벨의 패키지 의존성은 해결하지 못하기 때문입니다. EE는 이러한 모든 의존성을 컨테이너 이미지 안에 완벽하게 패키징하여, 어떤 환경에서도 동일하게 동작하는 실행 환경을 보장합니다.

>해당 명령을 실행할 시 컨테이너 내부의 파이썬 경로와 설치된 패키지 목록을 확인하여, 실행 환경이 호스트 시스템과 완전히 격리되어 독립적인 의존성을 가짐을 확인할 수 있습니다.

```bash

podman run --rm my-custom-ee:latest which python

podman run --rm my-custom-ee:latest pip list

```

2.1.2. 이식성 확보

Ansible 사용자는 로컬 환경에서 자동화 콘텐츠를 작성하고, 컨테이너 기술을 활용하여 자동화 런타임을 이식 가능하고, 공유 가능하며, 테스트 및 프로덕션 환경에 쉽게 배포할 수 있기를 원합니다. EE를 사용하면, 개발자의 노트북에서 동작하던 자동화 코드가 테스트 서버나 프로덕션 환경에서도 정확히 동일하게 동작하는 것을 보장할 수 있습니다. "제 컴퓨터에서는 잘 됐는데요"라는 말은 이제 과거의 유물이 됩니다.

2.1.3. 콘텐츠 분리

여러 사용자가 Ansible 컨트롤 노드나 Ansible AWX/Controller와 같은 도구를 공유하는 상황에서는 설정 및 의존성 충돌을 피하기 위해 콘텐츠를 분리하고자 할 수 있습니다. 예를 들어, 네트워크 팀은 네트워크 장비용 컬렉션이 포함된 EE를 사용하고, 서버 팀은 리눅스 서버 관리용 컬렉션이 포함된 EE를 사용하여 서로의 작업에 영향을 주지 않고 독립적으로 자동화를 실행할 수 있습니다. 이는 멀티테넌시 환경에서 매우 중요한 기능입니다.

2.2. EE를 위한 Ansible 생태계 도구들

Ansible 생태계의 프로젝트들은 EE와 함께 사용할 수 있는 여러 도구를 제공합니다. 이 도구들은 EE의 생성, 관리, 실행을 도와 자동화 경험을 한층 더 향상시킵니다.

- Ansible Builder: EE 이미지를 쉽게 생성할 수 있도록 도와주는 명령줄 도구입니다. 정의 파일을 기반으로 필요한 ansible-core, 컬렉션, 파이썬 라이브러리 등을 포함하는 컨테이너 이미지를 빌드합니다.

>해당 명령을 실행할 시 현재 디렉토리의 `execution-environment.yml` 정의 파일을 기반으로 `my-custom-ee:latest`라는 태그를 가진 컨테이너 이미지를 빌드하는 효과를 얻습니다.

```bash

ansible-builder build --tag my-custom-ee:latest .

```

- Ansible Navigator: 플레이북 실행 및 Ansible 콘텐츠 탐색을 위한 텍스트 기반 사용자 인터페이스(TUI)를 제공합니다. EE를 활용하여 플레이북을 실행하고 그 결과를 시각적으로 확인하는 데 매우 유용합니다.

- Ansible AWX / Controller: 웹 기반 UI와 REST API를 제공하는 엔터프라이즈급 자동화 플랫폼입니다. 작업 템플릿에서 특정 EE를 지정하여, 중앙에서 표준화된 실행 환경으로 자동화를 관리하고 실행할 수 있습니다.

- Ansible Runner: 위에서 언급했듯이, Ansible을 실행하고 그 출력을 다른 시스템과 통합하기 위한 안정적인 인터페이스를 제공하는 구성 요소입니다. Navigator나 AWX도 내부적으로는 Runner를 사용합니다.

- VS Code Ansible 확장 프로그램: Visual Studio Code에서 Ansible 콘텐츠를 개발할 때, EE와 통합하여 개발 환경 자체를 컨테이너화하고, 코드 작성 시점부터 실행 환경과의 일관성을 유지할 수 있게 해줍니다.

- Dev Containers 확장 프로그램: VS Code의 또 다른 확장 기능으로, 개발 환경 전체를 컨테이너로 정의하고 실행할 수 있게 해줍니다. 이를 통해 Ansible EE를 개발 환경으로 직접 사용하여, 개발과 실행의 간극을 완전히 없앨 수 있습니다.