Ansible Role의 정의와 사용 방법

Ansible® Role은 Ansible 자동화의 독립적 단위로 이식성을 갖추고 있으며, 관련 태스크 및 변수, 파일, 핸들러, 기타 자산을 알려진 파일 구조로 그룹화하는 데 자주 사용되는 방식입니다. 자동화 태스크는 Ansible Playbook에서만 작성될 수 있는 반면, Ansible Role을 사용하면 오토메이션 콘텐츠 번들을 만들어 한 개 이상의 플레이에서 실행하고 플레이북 전반에서 재사용하며 컬렉션에서 다른 사용자들과 공유할 수 있습니다.

Ansible Role은 구성 파일 작성에 사용되어 인간이 읽을 수 있는 데이터 직렬화 언어인 YAML로 표현됩니다. 태스크나 플레이에 롤이 포함되면 Ansible이 표준 롤 디렉터리 8개 중 최소 1개에서 main.yml 파일을 찾습니다. 주석과 함께 아래에 설명되어 있는 디렉터리에는 롤 태스크, 핸들러, 모듈, 기본값, 변수, 파일, 템플릿, 메타 등이 포함되어 있습니다.

roles/ common/ # this hierarchy represents a "role" tasks/ # main.yml # <-- tasks file can include smaller files if warranted handlers/ # main.yml # <-- handlers file templates/ # <-- files for use with the template resource ntp.conf.j2 # <------- templates end in .j2 files/ # bar.txt # <-- files for use with the copy resource foo.sh # <-- script files for use with the script resource vars/ # main.yml # <-- variables associated with this role defaults/ # main.yml # <-- default lower priority variables for this role meta/ # main.yml # <-- role dependencies library/ # roles can also include custom modules module_utils/ # roles can also include custom module_utils lookup_plugins/ # or other types of plugins, like lookup in this case webtier/ # same kind of structure as "common" was above, done for the webtier role monitoring/ # "" fooapp/ # "" 

롤 옵션이 함께 나열하거나 include_role 또는 import_role 커맨드로 롤 태스크 섹션에 추가하여 플레이북에서 호출하는 방식으로 Ansible Role을 사용할 수 있습니다. 롤 옵션이 나열되거나 import_role이 추가된 롤은 플레이에서 다른 모든 태스크보다 먼저 실행되는 반면, include_role이 추가된 롤은 태스크 목록 내에 정의된 순서대로 실행됩니다.

Ansible Role과 Ansible Playbook은 모두 자동화 태스크를 준비하고 실행하기 위한 툴이지만 각각의 용도는 다릅니다. Ansible Role을 생성할 것인지, 아니면 Ansible Playbook에서 모든 태스크를 작성할 것인지는 구체적인 활용 사례와 Ansible 경험 정도에 따라 결정됩니다.

대부분의 자동화 개발자와 시스템 관리자는 개별 플레이북을 사용하여 오토메이션 콘텐츠를 생성합니다. 플레이북은 정의된 인벤토리에 대해 실행되는 자동화 태스크의 목록입니다. 여러 태스크가 모여 하나의 플레이를 구성할 수 있습니다. 즉, 플레이는 특정 호스트에 매핑되어 순서대로 실행되는 하나 이상의 태스크로 구성된 그룹입니다. 플레이북은 하나 이상의 플레이를 포함할 수 있으며, 단일 파일에서 Ansible 자동화를 실행하기 위한 유연한 메커니즘을 제공합니다.

플레이북은 Ansible을 사용한 강력한 자동화 방식이지만 플레이북에서 모든 태스크를 작성하는 것이 언제나 최선인 것은 아닙니다. 범위와 변수가 복잡하고 재사용성이 도움이 되는 경우 Ansible Role에서 대부분의 오토메이션 콘텐츠를 생성하고 이를 플레이북 내에서 호출하는 편이 더 적절할 수 있습니다.

다음 예시에는 플레이북 내 롤(linux-systemr-roles.timesync) 사용법이 나와 있습니다. 이 경우 단일 롤의 작업 수행을 위해 4개 이상의 태스크가 필요합니다. 

- name: Manage timesync with 3 servers hosts: targets vars: timesync_ntp_servers: - hostname: foo.example.com iburst: true - hostname: bar.example.com iburst: true - hostname: baz.example.com iburst: true roles: - linux-system-roles.timesync 

모든 오토메이션 콘텐츠를 단일 플레이북에 작성하는 대신 Ansible Role을 사용하면 다음과 같은 장점을 누릴 수 있습니다.

재사용성 및 공유

롤은 재사용 가능한 자동화 단위로 설계되었습니다. 롤은 자동화 태스크의 논리적 그룹을 단일 플레이나 플레이북의 컨텍스트에서 분리하는 데 도움이 되므로 여러 플레이 또는 플레이북 전반에서 롤을 재사용하고 이를 공유하여 다른 프로젝트에서 재사용할 수 있습니다.

모듈성

롤 사용 시 각 롤이 기능의 특정 부분을 담당하는 모듈식 자동화 방식을 채택하는 것이 좋습니다. 이러한 방식은 자동화 코드의 이해와 유지 관리 및 트러블슈팅을 더 수월하게 해줍니다.

조직

Ansible Role을 사용하면 구조화된 방식으로 태스크, 템플릿, 파일, 변수를 구성할 수 있습니다. 특정 롤에 관련된 모든 요소가 해당 디렉터리 내에 포함되므로 구조화된 방식을 통해 복잡한 자동화 설정을 더 손쉽게 관리할 수 있습니다.

매개변수화

롤을 사용하면 기본 변수를 정의하고 Ansible Playbook에서 롤이 사용될 때 재정의할 수 있습니다. 그러면 롤 자체를 수정하지 않고도 롤의 동작을 다양한 환경 또는 활용 사례에 맞게 조정하기가 쉬워집니다.

버전 및 종속성 관리

롤은 버전 관리가 가능하며, 롤 내의 meta/main.yml 파일에서 롤 종속성을 지정할 수 있습니다. 그 결과, 버전과 종속성을 명시적으로 관리할 수 있어 여러 환경 전반에서 안정성과 일관성을 보장할 수 있습니다.

테스트

롤의 구조를 통해 테스트 방법론을 더 쉽게 적용할 수 있습니다. 롤별로 테스트를 작성할 수 있으므로 롤이 더 큰 플레이북으로 통합되기 전에 예상대로 작동하는지 확인할 수 있습니다.

간소화

규모가 크거나 복잡한 프로젝트의 경우 롤을 통해 Ansible Playbook 사용을 간소화할 수 있습니다. 태스크, 핸들러, 템플릿을 모두 포함하는 대규모 플레이북 대신 사람들이 쉽게 읽고 이해할 수 있는 훨씬 간결한 플레이북을 작성할 수 있습니다. 따라서 새로운 프로젝트에서 재사용하기 위한 롤을 더 쉽게 식별할 수 있으므로 오토메이션 콘텐츠를 작성하는 데 소요되는 시간이 단축되고 워크플로우가 간소화됩니다. 

ansible-galaxy role init role_name 커맨드로 새 롤을 생성해 표준 롤 디렉터리 구조를 따르는 디렉터리를 빌드할 수 있습니다. 디렉터리를 검증한 후에는 태스크, 기본 변수, 기타 구성 요소를 정의할 수 있습니다. 롤이 기능하는 데 필수는 아니지만 README.md 파일과 meta/main.yml에 도큐멘테이션을 추가할 수도 있습니다.

새 롤을 만들려면 고도의 Ansible 경험이 필요할 수 있으며, 아직 오토메이션 콘텐츠 구축 방법을 배우고 있는 팀에게는 어려울 수 있습니다. 자동화 개발자의 경력에 상관없이 콘텐츠를 손쉽게 생성하려면 Ansible 모범 사례를 기반으로 코드 권장 사항을 제공하는 생성형 AI 서비스인 IBM watsonx Code Assistant가 통합된 Red Hat® Ansible Lightspeed를 활용하면 됩니다. 자연어 프롬프트를 사용하여 실현하고자 하는 자동화를 설명하고 watsonx Code Assistant가 통합된 Ansible Lightspeed로부터 단일 태스크와 멀티태스크 콘텐츠 제안을 받을 수 있습니다. 그러면 생성된 태스크가 Ansible Role 또는 플레이북에 포함될 수 있습니다.

watsonx Code Assistant가 통합된 Ansible Lightspeed는 Ansible 코드의 생성, 유지 관리 및 품질 개선에 필요한 작업을 줄여 생산성을 향상시키고 도입 시간을 단축합니다. 

Ansible Role은 공유하기가 쉬우므로 올바르게 유지 관리되고 검증된 롤을 자동화에 통합할 수 있습니다. 다음 리포지토리를 사용하여 롤을 공유할 수 있습니다.

• Ansible Galaxy- 롤과 기타 Ansible 콘텐츠를 대규모 Ansible 커뮤니티와 공유하기 위한 무료 리포지토리입니다. 롤은 커맨드라인(CLI)을 통해 Ansible Galaxy로 업로드할 수 있는 반면, 컬렉션은 웹 인터페이스에서 공유할 수 있습니다. Ansible Galaxy는 커뮤니티 사이트이므로 Red Hat이 콘텐츠를 검증, 인증 또는 지원하지 않습니다.
• Ansible 오토메이션 허브 - Red Hat Ansible Automation Platform 서브스크립션에 포함된 Ansible 오토메이션 허브는 Ansible Content Collections를 찾고, 다운로드하고, 공유하기 위한 중앙 리포지토리입니다. Ansible 오토메이션 허브는 Red Hat이 호스팅하며, Red Hat과 독립 소프트웨어 벤더(ISV) 파트너의 인증 및 검증된 콘텐츠를 모두 포함합니다.
• 프라이빗 오토메이션 허브 - 온프레미스 리포지토리 프라이빗 오토메이션 허브로, 조직이 내부 전용으로 콘텐츠를 관리, 공유 및 큐레이션하는 데 사용됩니다. 롤과 기타 오토메이션 콘텐츠를 기업과 공유할 수 있기 때문에 팀은 워크플로우를 간소화하고 자동화를 가속화할 수 있습니다. 

Red Hat Ansible Automation Platform은 조직이 자동화를 통해 가속화, 오케스트레이션, 혁신을 실현하도록 설계된 통합 플랫폼입니다. Red Hat 서브스크립션을 이용하면 Ansible 오토메이션 허브에서 제공되는 Red Hat Certified Content Collections와 Ansible 검증 콘텐츠에 액세스할 수 있습니다.

서브스크립션에는 IBM watsonx Code Assistant가 통합된 Red Hat Ansible Lightspeed도 포함되며, 이를 통해 Ansible Role에 포함된 태스크를 작성하고 개선하는 프로세스가 간소화되므로 자동화 팀이 콘텐츠를 더욱 효율적으로 생성할 수 있습니다. Visual Studio Code에 완전히 통합된 Ansible Lightspeed는 자동화 개발자가 어디에서든지 사용할 수 있습니다. 따라서 개발 환경을 전환할 필요 없이 모범 사례에 맞게 조정된 Ansible Role과 플레이북을 생성할 수 있습니다.

또한 Ansible Lightspeed는 기능에 맞는 콘텐츠 소스를 제공하므로 제공되는 제안에 따라 소스 훈련 데이터를 확인하여 사용자를 위한 롤을 생성할 때 더 나은 의사 결정을 내릴 수 있습니다. 그리고 Ansible 커뮤니티에서 제공되는 수천 개의 롤과 Red Hat이 제공하는 데이터 포인트를 기반으로 훈련된 모델을 통해 Ansible Lightspeed는 Ansible 코드를 정확하고 투명하게 생성하고 개선하도록 지원하므로 조직의 요구 사항을 충족하고 도입을 가속화할 수 있습니다.