실습 Ansible - EE(Execution Environments) - 2
페이지 정보
본문
3. 첫 번째 실행 환경 빌드하기
이 게시글에서는 Ansible EE 빌드에 대한 문서를 살펴보고, 예시만 안내드리는 글입니다.
이제 본격적으로 첫 번째 실행 환경을 직접 빌드해보겠습니다. 우리가 구축할 EE는 `ansible-core`, Python과 같은 표준 패키지는 물론, `community.postgresql` 컬렉션과 그 의존성인 `psycopg2-binary` Python 커넥터까지 포함하는 완전한 Ansible 컨트롤 노드를 구현하게 될 것입니다. 이는 데이터베이스 자동화에 특화된 실용적인 EE가 될 것입니다.
실제 운영 환경에서 기존에는 각 서버마다 psycopg2 라이브러리의 버전이 다르거나, 시스템 파이썬과 충돌하는 문제 때문에 많은 어려움을 겪었을 것입니다. EE를 사용하면 이러한 모든 문제가 해결됩니다.
3.1. 프로젝트 환경 설정
첫 번째 실행 환경을 빌드하기 위한 단계별 과정을 상세히 살펴보겠습니다. 모든 작업은 체계적이고 재현 가능한 방식으로 진행되어야 하며, 이는 운영 환경에서의 일관성을 보장하는 핵심 요소입니다.
3.1.1. 프로젝트 디렉토리 생성
먼저 파일 시스템에 프로젝트 폴더를 생성해야 합니다. 이 디렉토리는 EE 빌드에 필요한 모든 정의 파일과 설정들을 담게 될 작업 공간입니다. 체계적인 디렉토리 구조는 향후 여러 EE를 관리할 때 매우 중요한 역할을 합니다.
```bash
mkdir my_first_ee && cd my_first_ee
```
>해당 명령을 실행할 시 현재 위치에 `my_first_ee`라는 새로운 디렉토리를 생성하고 해당 디렉토리로 이동하는 효과를 얻습니다.
생성된 디렉토리는 단순한 폴더가 아닙니다.향후 이 디렉토리 안에는 실행 환경 정의 파일, 의존성 명세, 그리고 빌드 과정에서 생성되는 다양한 아티팩트들이 저장됩니다.
3.1.2. 실행 환경 정의 파일 작성
이제 이미지에 포함할 의존성을 지정하는 `execution-environment.yml` 파일을 생성해야 합니다. 이 파일은 Ansible Builder가 컨테이너 이미지를 구성하는 데 필요한 모든 정보를 담고 있습니다. 이 파일의 구조와 내용을 이해하는 것은 EE 관리의 핵심입니다.
다음과 같은 내용으로 `execution-environment.yml` 파일을 작성합니다:
```yaml
---
version: 3
images:
base_image:
name: quay.io/ansible/ansible-runner:latest
dependencies:
galaxy: requirements.yml
python: requirements.txt
system: bindep.txt
additional_build_steps:
prepend: |
RUN whoami
RUN cat /etc/os-release
append: |
RUN echo "Custom EE build completed"
```
이 정의 파일의 각 섹션은 특별한 의미를 가집니다. `version: 3`은 최신 정의 형식을 사용한다는 의미이며, 이를 통해 Ansible Builder의 모든 고급 기능을 활용할 수 있습니다. `base_image`는 우리 EE의 기반이 되는 이미지를 지정하며, 공식 ansible-runner 이미지를 사용함으로써 검증된 안정성을 확보합니다.
`dependencies` 섹션은 EE의 핵심이라고 할 수 있습니다. 여기서 지정된 파일들이 실제 의존성을 정의하며, 각각 Ansible 컬렉션, Python 패키지, 시스템 패키지를 담당합니다. 이러한 분리된 구조는 의존성 관리를 체계적으로 할 수 있게 해주며, 문제 발생 시 디버깅을 용이하게 만듭니다.
3.2. 의존성 파일 구성
3.2.1. Ansible 컬렉션 의존성 정의
PostgreSQL 자동화를 위한 `requirements.yml` 파일을 생성해야 합니다. 이 파일은 우리 EE에 포함될 Ansible 컬렉션들을 정의합니다:
```yaml
---
collections:
- name: community.postgresql
version: ">=2.4.0"
- name: community.general
version: ">=6.0.0"
```
>해당 명령을 실행할 시 지정된 버전 이상의 community.postgresql과 community.general 컬렉션이 EE 이미지에 포함되어, PostgreSQL 데이터베이스 관리와 일반적인 시스템 관리 작업을 수행할 수 있는 효과를 얻습니다.
3.2.2. Python 의존성 명세
`requirements.txt` 파일을 생성하여 필요한 Python 패키지를 지정합니다. `psycopg2-binary` Python 패키지는 community.postgresql 컬렉션의 `requirements.txt` 파일에 포함되어 있다는 점을 주목해야 합니다. 하지만 모든 컬렉션이 이러한 파일을 포함하고 있지는 않으므로, 직접 Python 의존성을 명시해야 하는 경우도 있습니다.
```txt
psycopg2-binary>=2.8.6
requests>=2.25.1
PyYAML>=5.4.1
```
이러한 명시적인 의존성 관리는 운영 환경에서 매우 중요합니다. 특히 `psycopg2-binary`는 PostgreSQL과의 연결을 담당하는 핵심 라이브러리이므로, 안정적인 버전을 명시하여 예기치 못한 호환성 문제를 방지해야 합니다.
3.2.3. 시스템 레벨 의존성 처리
시스템 패키지 의존성을 위한 `bindep.txt` 파일도 생성합니다:
```txt
postgresql-devel [platform:centos-8 platform:rhel-8]
libpq-dev [platform:ubuntu-20.04 platform:debian-10]
gcc [compile]
python3-dev [compile]
```
이 파일은 플랫폼별로 필요한 시스템 패키지를 정의합니다. PostgreSQL 클라이언트 라이브러리는 배포판마다 다른 이름을 가지므로, 이러한 조건부 의존성 정의가 필수적입니다.
3.3. EE 이미지 빌드 실행
3.3.1. Ansible Builder를 이용한 빌드
이제 `postgresql_ee`라는 이름의 EE 컨테이너 이미지를 빌드합니다. 이 과정에서 Ansible Builder는 우리가 정의한 모든 의존성을 포함하는 완전한 실행 환경을 생성합니다.
```bash
ansible-builder build --tag postgresql_ee
```
>해당 명령을 실행할 시 현재 디렉토리의 execution-environment.yml 파일을 기반으로 postgresql_ee:latest 태그를 가진 완전한 Ansible 실행 환경 컨테이너 이미지를 생성하는 효과를 얻습니다.
Docker를 사용하는 환경이라면 `--container-runtime docker` 인수를 추가해야 합니다. 빌드 과정은 몇 분 정도 소요될 수 있으며, 이 시간 동안 기본 이미지 다운로드, 의존성 설치, 레이어 생성 등의 작업이 진행됩니다.
```bash
ansible-builder build --tag postgresql_ee --container-runtime docker
```
3.3.2. 빌드 과정 상세 분석
빌드 과정에서 Ansible Builder는 여러 단계를 거쳐 최종 이미지를 생성합니다. 먼저 기본 이미지를 가져온 후, 시스템 패키지를 설치하고, Python 의존성을 처리하며, 마지막으로 Ansible 컬렉션을 설치합니다. 각 단계는 컨테이너 레이어로 저장되어, 향후 빌드 시 캐시를 활용한 빠른 빌드가 가능합니다.
빌드 과정에서 발생할 수 있는 일반적인 문제들도 미리 알아두면 좋습니다. 네트워크 연결 문제로 인한 패키지 다운로드 실패, 의존성 버전 충돌, 또는 시스템 패키지 설치 권한 문제 등이 있을 수 있습니다. 이러한 문제들은 대부분 정의 파일을 수정하거나 빌드 환경을 조정하여 해결할 수 있습니다.
3.4. 빌드 결과 확인 및 검증
3.4.1. 이미지 목록 확인
컨테이너 이미지를 나열하여 성공적으로 빌드되었는지 확인합니다.
```bash
podman image list
```
>해당 명령을 실행할 시 로컬 시스템에 저장된 모든 컨테이너 이미지 목록을 출력하여, 방금 빌드한 postgresql_ee 이미지가 포함되어 있는지 확인하는 효과를 얻습니다.
정상적으로 빌드가 완료되었다면 다음과 같은 출력을 볼 수 있을 것입니다:
```bash
localhost/postgresql_eelatest2e866777269b6 minutes ago1.11 GB
```
이미지 크기가 1GB를 넘는 것은 정상적인 현상입니다. EE는 완전한 실행 환경을 포함하고 있기 때문에, 운영체제 기본 패키지, Python 런타임, Ansible Core, 그리고 모든 의존성을 포함하고 있습니다.
3.4.2. 컨테이너 파일 구조 검사
생성된 이미지를 `context` 디렉토리의 `Containerfile` 또는 `Dockerfile`을 검사하여 그 구성을 확인할 수 있습니다.
```bash
less context/Containerfile
```
>해당 명령을 실행할 시 Ansible Builder가 생성한 컨테이너 빌드 파일의 내용을 확인하여, 정의한 의존성들이 어떻게 이미지에 적용되었는지 상세히 파악하는 효과를 얻습니다.
이 파일을 살펴보면 Ansible Builder가 우리의 정의를 어떻게 실제 컨테이너 빌드 지시문으로 변환했는지 알 수 있습니다. 각 의존성이 어떤 순서로 설치되었는지, 어떤 환경 변수가 설정되었는지, 그리고 최종 작업 디렉토리가 어디인지 등의 정보를 확인할 수 있습니다.
3.4.3. Ansible Navigator를 통한 상세 정보 확인
Ansible Navigator를 사용하여 이미지에 대한 상세 정보를 확인할 수도 있습니다. 이는 EE의 내용을 시각적으로 탐색할 수 있는 강력한 도구입니다.
```bash
ansible-navigator
```
>해당 명령을 실행할 시 텍스트 기반 사용자 인터페이스가 실행되어, EE 이미지의 구성 요소들을 대화형으로 탐색할 수 있는 효과를 얻습니다.
Navigator의 TUI에서 `:images`를 입력한 다음 `postgresql_ee`를 선택하면, 설치된 컬렉션 목록, Python 패키지, 환경 변수 등을 자세히 확인할 수 있습니다.
3.5. 빌드된 EE의 실용적 활용
3.5.1. 이미지 내부 검증
빌드가 완료된 후에는 실제로 EE 내부에서 필요한 구성 요소들이 제대로 설치되었는지 확인해야 합니다. 이는 운영 환경에 배포하기 전 필수적인 검증 과정입니다.
```bash
podman run --rm postgresql_ee:latest ansible --version
podman run --rm postgresql_ee:latest python -c "import psycopg2; print('PostgreSQL connector available')"
podman run --rm postgresql_ee:latest ansible-galaxy collection list
```
>해당 명령을 실행할 시 생성된 EE 내부에서 Ansible 버전 확인, PostgreSQL 커넥터 가용성 검증, 설치된 컬렉션 목록 출력을 통해 모든 의존성이 올바르게 설치되었음을 확인할 수 있습니다.
3.5.2. 레지스트리 관리 고려사항
실제 운영 환경에서는 생성한 EE 이미지를 컨테이너 레지스트리에서 관리해야 합니다. 로컬에서만 사용하는 것이 아니라, 팀 전체가 동일한 EE를 사용할 수 있도록 중앙화된 저장소가 필요합니다.
```bash
podman tag postgresql_ee:latest registry.company.com/ansible/postgresql_ee:v1.0.0
podman push registry.company.com/ansible/postgresql_ee:v1.0.0
```
>해당 명령을 실행할 시 로컬에서 빌드한 EE 이미지에 적절한 태그를 부여하고 기업 내부 레지스트리에 업로드하여, 팀 전체가 동일한 실행 환경을 공유할 수 있는 효과를 얻습니다.
버전 관리는 EE 운영에서 핵심적인 요소입니다. 의미있는 버전 번호를 사용하고, 변경 사항을 문서화하며, 이전 버전과의 호환성을 고려해야 합니다.
3.5.3. 마무리
생성된 EE는 단순히 동작하는 것으로 끝나는 것이 아니라, 성능과 보안 측면에서도 최적화되어야 합니다. 불필요한 패키지 제거, 보안 업데이트 적용, 그리고 이미지 크기 최소화 등의 작업이 필요할 수 있습니다.
또한 EE 내부에 저장되는 민감한 정보들에 대한 보안 정책도 수립해야 합니다. 비밀번호나 API 키 같은 정보는 이미지에 하드코딩하지 않고, 런타임에 환경 변수나 시크릿을 통해 주입하는 방식을 사용해야 합니다.
- 다음글Ansible - EE(Execution Environments) - 1 25.08.04
댓글목록
등록된 댓글이 없습니다.