인벤토리 plugin 과연 이건 어떨까요?
이것을 이해하려면, 과거로 돌아가야 합니다. 신경도 잘 안 썼던 그때로 말이죠
inventory는 기본적으로 /etc/ansible/hosts에 위치해 있고, 여기를 수정해서 작성합니다.
하지만, 꼭 항상 언제나 여기를 써야 할까요?
아니죠 ansible, 또는 ansible-playbook은 -i 또는 --inventory라는 옵션이 있습니다.
즉 우리가 원하는 곳에 inventory를 끌어다 쓸수 있는거죠.
예제를 볼까요?
m_hosts라는 파일을 읽어서 해당 부분에 대한 그룹을 볼 것입니다.
[vagrant@ansible-server inventory]$ cat m_hosts
node01
node02
node03
node04
이렇게 하면, 그냥 그룹소속과 아닌 것만 보이게 되죠
원래 /etc/ansible/hosts에 있던 파일을 이렇게 나오고 결과 값은 이렇습니다.
# BEGIN ANSIBLE MANAGED BLOCK
[CentOS]
node01
node02
[Ubuntu]
node03
node04
[Win]
node05
# END ANSIBLE MANAGED BLOCK
이건 그룹이 좀 되어 있는 편이죠 :)
여튼 우리는 인벤토리를 임의로 할수 있다는 것을 확인했습니다.
5. Inventory (tag : 과연 내가 널 쓸까?)
Action PluginsCache PluginsCallback PluginsConnection Plugins- Inventory Plugins
- Lookup Plugins
- Shell Plugins
- Strategy Plugins
- Vars Plugins
- Filters
- Tests
그렇습니다. 이 인벤토리를 좀 더 자유롭게 쓸수 있는게 인벤토리 plugin입니다.
예시를 한번 봅시다.
특히 inventory plugin은 예시가 아니면 이해가 잘 안됩니다. ㅠㅠ
[vagrant@ansible-server inventory]$ cat m_hosts
node01
node02
node03 Prod=Ubuntu
node04 Test=Ubuntu
node05 Prod=CentOS
node06 Test=Win
node07 Prod=Win
기존에 이렇게 작성된 hosts 파일이 있다고 가정합시다.
어디에도 group이 되어 있지가 않죠?
아니아니 -_-; 이게 아니고요...
이것을 plugin을 통해서 자동으로 그룹해 보도록 하겠습니다.
자동화를 위해서 constructed 를 사용하겠습니다.
아니....제 마음이 계속 표시가....-_-; 집에 가고 싶어서....
여튼...다시 잠시만요..;;;;
[vagrant@ansible-server inventory]$ cat cons.config
plugin: constructed
strict: False
keyed_groups:
- prefix: Prod
key: Prod|default('none')
- prefix: Test
key: Test|default('none')
이런식으로 나는 플러그인으로 constructed를 쓸꺼고 심각하게는 안 볼꺼고 그룹은 이렇게 할꺼라구! 라고 정리해서 꼭꼭꼭 확장자를 config로 줍니다. 또는 yaml로요.
(이거 틀려서 몇시간 까먹었습니다. 하하하하 conf로 주니까 동작을 안 하더라고요 ㅎㅎㅎ)
그러면 한번 실행해 볼까요?
엄머! -_- 이건 무슨 일일까요?
이게 왜 이렇게 되었냐면 말이죠...
기본적인 inventory 플러그인은 'host_list', 'script', 'yaml', 'ini' 를 받아 들입니다.
근데 쌩판 본적도 없는 contru...머시기가 들어오니 난 모르겠다라고 하는거죠.
그래도 출력물이 나오는걸 보면 양반입니다.
그래서 enable_plugins 자체를 수정해 줍니다.
이때, 순서 같은 것은 상관 없습니다. 내가 허용해 주는 것들을 whitelist처럼 정리하는 거라서요.
해당 내용을 저장하고 다시 실행하면, 아래와 같이 그룹을 자동으로 정리되어 있는 것을 확인할 수 있습니다.
이와 같은 inventory 관련 plugin은 다음과 같습니다.
그런데 말이죠 가장 중요한 포인트...이걸 어디다가 쓸까요 -_-?
가장....사용에 필요한 것은 자동으로 VM들이 관리되는 환경...즉 AWS, Azure와 같은 VM들이 동적으로 할당되고 삭제되는 환경내에서 CI/CD환경을 만들기 위해서 적용이 필요한 경우가 있습니다.
또는 대형 IDC환경에서 CMDB에 정확하게 값들이 들어가도록 input을 규정화 하고 정확하게 들어가게 해줘야 할때도 관리의 편의성이 좋아질 것 같습니다. 이 역시 동적으로 운영되는 걸 mapping해주는 것이겠죠.
아래는 inventory plugin을 새로 개발해서 쓴 경우입니다. 참고로 보시면 될 것 같아요 :)
http://willthames.github.io/2017/11/01/generating-inventory.html
그러면 이만 빠잉~! 얼릉 집에 가서 잘껍니다 ㅠㅠ
해당 내용을 저장하고 다시 실행하면, 아래와 같이 그룹을 자동으로 정리되어 있는 것을 확인할 수 있습니다.
이와 같은 inventory 관련 plugin은 다음과 같습니다.
- advanced_host_list - Parses a ‘host list’ with ranges
- auto - Loads and executes an inventory plugin specified in a YAML config
- constructed - Uses Jinja2 to construct vars and groups based on existing inventory.
- host_list - Parses a ‘host list’ string
- ini - Uses an Ansible INI file as inventory source.
- openstack - OpenStack inventory source
- script - Executes an inventory script that returns JSON
- virtualbox - virtualbox inventory source
- yaml - Uses a specifically YAML file as inventory source.
그런데 말이죠 가장 중요한 포인트...이걸 어디다가 쓸까요 -_-?
가장....사용에 필요한 것은 자동으로 VM들이 관리되는 환경...즉 AWS, Azure와 같은 VM들이 동적으로 할당되고 삭제되는 환경내에서 CI/CD환경을 만들기 위해서 적용이 필요한 경우가 있습니다.
또는 대형 IDC환경에서 CMDB에 정확하게 값들이 들어가도록 input을 규정화 하고 정확하게 들어가게 해줘야 할때도 관리의 편의성이 좋아질 것 같습니다. 이 역시 동적으로 운영되는 걸 mapping해주는 것이겠죠.
아래는 inventory plugin을 새로 개발해서 쓴 경우입니다. 참고로 보시면 될 것 같아요 :)
http://willthames.github.io/2017/11/01/generating-inventory.html
그러면 이만 빠잉~! 얼릉 집에 가서 잘껍니다 ㅠㅠ
0 개의 댓글:
댓글 쓰기