Seungdols Company

Ansible의 사용기 후기 본문

인프라/Ansible

Ansible의 사용기 후기

글쓰는 프로그래머 seungdols 2017. 9. 16. 00:30

Ansible의 사용기 후기

노가다 후기라고 해야 할지, 삽질이라고 해야 할지 그냥 둘다..

unarchive

이 모듈에 대해선 할 말이 참 많다. 이 모듈은 자그마치 메이저 버전이 v1 에서 v2로 왔음에도 버그가 존재한다.

이를 테면, 압축 파일 내에 디렉토리 하위 디렉토리 구조라면, 하위 디렉토리의 owner에 대한 지정하는 옵션이 적용 되지 않는다.

이미 Github Issue에 나도 여전히 안된다고 리포트를 올리긴 했다.

인프라 구성 설정 관리 툴 도입에 대한!

Ansible이 모든 것을 해줄 것 같지만, 생각보다 서비스 하는 서버의 구성을 자동화 한다는게 생각보다 쉽지는 않다.

우선, Ansible이든, Chef 혹은 Puppet이라는 Automation Infra Tool을 도입하려 한다면, 검토해야 하는 일이 있다.

  1. Agent 구동 이슈

  2. SSH Key 관리

  3. 다양한 서버 설정

Agent에 대해서는 Chef를 예로 들자면, 관리해야 하는 서버가 100대 이하라면, Chef를 도입하는데 나쁜 것은 없다. 다만, 각 client host에 Chef agent를 설치 해줘야 한다. (이또한 관리 Cost증가)

그와 반대로 Ansible은 Agentless라는 장점이 있고, SSH 통신 하게 된다. 물론, Chef도 SSH로 통신을 하긴 한다.

다만, 서버 관리 대상이 늘어날 수록, Terminal에서 작업하는 작업의 고통은 배가 된다.

고로, GUI환경을 도입하는 것이 좋다.

  • Puppet/Chef용 GUI는 Foreman이라는 녀석이 있다.

  • Ansible은 Ansible Tower가 있으나, 정말 비싸다.

 

theforeman/foreman_ansible

:arrow_forward: Ansible integration in Foreman. Contribute to theforeman/foreman_ansible development by creating an account on GitHub.

github.com

 

ansible-semaphore/semaphore

Open Source alternative to Ansible Tower. Contribute to ansible-semaphore/semaphore development by creating an account on GitHub.

github.com

 

ansible/awx

AWX Project. Contribute to ansible/awx development by creating an account on GitHub.

github.com

중요한 부분은 foreman으로 설정 하는 부분은 굉장히 어렵다. 특히, 콜백 셋팅은 왜 안되는지 모르겠더라.. 그래서 그 다음 semaphore를 해봤지만, 기능이 너무 부족하다. 그래서 역시 제일 괜찮은 것은 awx가 좋다. 그런데, 이미 나는 다중 Role 구성으로 사용하고 있어서 awx 환경에 맞게 다시 바꾸기가 애매했다. 개발 일정 외적으로 운영을 해야 했기에 시간도 없었다. 물론, 초기에 도입해서 사용하는 것은 좋다고 생각 한다. 이미 터미널 환경에서 잘 사용하고 있다면, 굳이 쓸 필요 없고, 명령어를 매번 입력하기 힘드니, 명령어 저장 해두고 shell script로 실행 하는 것도 괜찮은 방법이라고 생각 한다. 

심지어 Config파일이 많다면, 당연히 copy 혹은 template을 많이 쓰게 될 것이다. 그리고 나면, 항상 꼭 Config 파일을 업데이트 해야하는 상황이 생긴다. 여기서 관리 Cost는 증가한다.

가장 중요한 것은 시나리오 짜기

결국에는 Chef의 Cookbook이든 Ansible의 playbook이든, 무엇 무엇을 설정 할지에 대한 시나리오부터 작성해두는 것이 좋다.

playbook을 작성하기 전에 시나리오를 모르면, 작성하는데 시간이 더 오래 걸리는 사태가 발생한다. 🙌

고로, 미리 준비 하는 것이 좋습니다.

config 파일은 어딘가에서 받아오도록 해야 할지 말지에 대한 고민

생각해보면, 실제로 git repogitory 안에서 쓰임새에 맞게 Playbook을 작성을 해주긴 하는데, 문제는 config파일이 생각보다 관리 하기가 어렵다는 문제다.

사실, 나도 이제 막, Ansible을 조금 이해하고 yaml 파일을 만들어 playbook을 작성하는 수준에 와있는데, config 파일도 playbook에서 관리하는 것이 맞긴 하다. 왜냐면, jinja2 template을 지원하므로, 일부분만 다른 config를 변수 치환만으로 적용 할 수 있기 때문이다.

그런데, 이제는 Config가 많아지면, 그 Config 파일 자체 관리 하는 것도 일이다. 관심사를 분리 시키고 싶다.

그래서 같이 사용하는 파일들인데, 동적으로 심어 주어야 하는 Config파일이 아니면, Copy로 전송하기보다, 다른 레포에서 _다운 받아 지정 된 위치로 옮겨주는 방식_이 적합해보인다.

그 외 내용은 다음에 이어서 하도록 해야할 것 같습니다.

Tag
,

공유하기 링크
0 Comments
댓글쓰기 폼