Ansible을 활용한 NVIDIA-Driver 설치 과정 자동화

1. 목적

• 서버를 효율적으로 관리하기 위해 고안된 환경 구성 자동화 도구 (IaC를 지향)
• 하며 여러 설치 과정을 자동화하여 불필요한 시간 낭비 절약
• 절차를 수행하는 모든 서버에 환경을 동일하게 유지 및 적용하는 멱등성이 특징
  • 수동 설치시에 생기는 사람의 실수 최소화
• Agentless 방식으로 agent 없이 구동이 가능
• 직관적인 구문
• 오픈소스로서 리눅스에서 사용되는 다양한 명령어들을 모듈로 사용 가능
• 사용자 친화적인 공식문서 를 가짐

► NVIDIA-Driver를 설치하는 절차를 ansible로 구성하여 기능 테스트 진행

2. NVIDIA-Driver 설치 과정

<설치과정 다이어그램>

4. Ansible을 통한 자동화 과정

• 기능별 playbook을 제작으로 오류 발생시 대응시간 감소
• 기능 테스트 후 import를 진행하므로서 main.yaml 간결화
• 특정 기능 필요시 재사용 가능 (06_reboot_tool.yaml)

5. Ansible 문법 및 스토리라인

5-1. 공개키 연결

• ansible 서버에서 key-gen 명령어를 통한 공개키를 생성
• ansible 서버의 공개키(id_rsa.pub)를 scp, ssh-copy-id 등의 명령어를 사용하여 client의 authorized_keys로 복사
• .pem 키 및 Passwd 설정 없이 접속 확인

5-2. host 파일(hosts.ini) 설정

Ansible로 관리하려는 노드들 즉 Managed node들에 대해서 관리하려면 Inventory 파일을 먼저 작성을 해야한다.
Inventory 파일이 hosts 파일이다. 다음과 같이 그룹으로 나누어 진행할 수 있다.

• hosts.ini 파일에 저장된 모든 노드를 대상으로 Push 한다면 playbook에서 hosts: all로 지정
• 특정 노드에만 Push 한다면 playbook에서 hosts: client-group1 로 지정

playbook에서 지정하여 논리적인 적용이 가능케한다.

(/etc/ansible/hosts)

[client-group1]
133.186.155.10
133.186.155.11
133.186.155.12

[client-group2]
133.186.152.10
133.186.152.11
133.186.152.12

5-3. 기본 문법

(test.yaml)

  1 - name: Insert Full name
  2   gather_facts: false
  3   hosts: all
  4   vars:
  5     vars_name: 'This is Variable contents'
  6   tasks:
  7   - name: Insert function name
  8     shell: echo "{{vars_name}}"
  9     register: shell_command_result

• - name: (Line-1) - yaml 파일의 이름 (line-1)
• gather_facts: - 각기 노드들의 정보들을 수집
• hosts: - playbook을 적용시킬 host 지정 / hosts 파일 기준으로 작동
• vars: - 변수를 제작하여 task에서 사용 가능
• tasks: - 실제 수행시킬 작업을 위 구문 아래에 작성
• - name: (Line-7) - 개별 task의 이름 / 위 구문 아래로 command 작성
• shell: - shell command를 사용할 수 있는 모듈
• register: - 결과 값을 담는 변수 생성 / 이후 다른 task에서 사용 가능

5-3. ansible 실행

ansible-playbook test.yaml

(detail debug)
-v
-vv
-vvv

(yaml 파일 적용 테스트)
--check

5-4. ansible 동작 방식

ansible은 Push를 진행하였을 때, 클라이언트들은 작업을 병렬적으로 수행한다.

• 클라이언트(관리 노드)로 작업 Push

• 모든 클라이언트(관리 노드)들이 작업 완료 시 다음 task 진행

• 하지만, 이러한 동시 시작에 대한 분기 처리는 소분화 된 단위(block 혹은 task) 로 진행
  

  reboot_tool을 이용하여 다음과 같이 분기가 끝나야만 동시에 다음 테스크로 넘어가는 것을 검증할 수 있었다.

6. Ansible 모듈 소개

6-1. 다양한 Ansible 모듈

NVIDIA-Driver 설치를 위해 사용된 Ansible의 여러 모듈들로 복잡한 설치 과정을 간소화 할 수 있다.

6-2. 모듈 소개

여러가지 모듈이 존재하지만 NVIDIA-Driver 설치를 위해 사용한 모듈에 대해 정리하였다.
<file 모듈, apt 모듈, lineinfile 모듈>

\<stat 모듈, reboot 모듈, copy 모듈, pause 모듈>

<vars, block, when, get_url 모듈>

7. 추가한 기능

위와 같은 준비가 끝나고 ansible을 실행하게되면 다음과 같은 결과를 볼 수 있다.

사용자는 설정한 task의 이름을 기준으로 진행상황을 확인 가능하다. 하지만 task의 이름이 중복되거나 이름의 고유성이 없게 되면 확실하게 식별할 수 없다.
그렇기 때문에 -debug: msg: 모듈 및 log 파일을 사용한다면 정확한 상태 확인 메시지를 출력이 가능해진다.

7-1. 로그로 진행 확인하기

• ansible.cfg 파일 생성
• ansible.cfg속 log_path 검색 및 수정
• ansible-playbook 작성 및 실행
  
  tail 명령어 및 debug: 모듈을 사용하여 실시간 진행상황을 확인할 수 있다.
  후에 실제로 사용하게 된다면, gather_facts를 사용, 노드들의 IP주소를 받아와 서버 별 msg를 시각화 하면 활용도가 높아질 것이다.

9. 추가 검토 내용

9-1. 쉘스크립트와 ansible-yaml 비교

비교	shell script	anisble-yaml
함수 사용 시	함수 제작	모듈 사용
직관성	낮음	높음
호환성	중간	높음
유지보수	어려움	쉬움
함수 제작 가능 여부	가능	가능
재사용	가능	가능
변수 사용	가능	가능
클라이언트 변수 사용	가능	가능
조건문 처리	가능	가능

9-3. ansible을 활용해야하는 이유

• 디버깅 시의 오류 해결이 ansible-yaml은 간편함
• shell-script 진행 부분을 다양한 모듈로 대체 가능
• ansible-yaml은 협업하여 프로젝트를 수행하는 경우 짧은 시간안에 직관적으로 코드를 이해할 수 있음
• shell-script는 작성자 자신만의 색으로 작성하기 때문에 타인이 유지보수하는데 어려움이 있음
• ansible은 이미 제작된 모듈로 간편한 사용이 가능하며 공식문서를 통한 코드 해석에 어려움이 없음
• 지속적인 수행에도 멱등성을 가지기 때문에 사람의 수동 설치 시와 다르게 실수가 일어나지 않음
• ansible 자동화로 시간 절약 가능

9-4. 절차 수행에 따른 적합 유무 확인

• 전체 절차 진행시 조건 진행이 가능한가? YES
• ansible을 사용하여 설치 시간을 감소할 수 있는가? YES
• 여러 대의 서버에 설치가 가능한가? YES
• 설치 전 부가적 서비스가 필요한가 ? NO (ssh로 해결 가능)
• 기업 사용 시 가격 부담은 없는가? YES

10. 느낀점

Ansible을 사용하여 GPU에 대한 NVIDIA-Driver를 설치하는 것은 많은 이점이 있다고 생각한다.
사용자 친화적인 공식문서로 인하여 학습에 어려움이 적으며, 유지보수 시에 모듈을 검색만 하면 빠른 습득이 가능하다.
다양한 모듈이 존재하기 때문에 실질적인 함수 제작에 시간이 들지 않아 프로젝트의 빠른 진행이 가능할 것이라고 생각한다.
또한, 가장 중요한 반복적인 작업의 자동화를 통하여 불필요 시간이 낭비되지 않는다.