시작하기에 앞서 지난 글에서 redis를 썼었는데요
이걸 왜 쓴다고 하는걸 안 쓴거 같더라고요.
예제를 볼까요~? 이해를 위해서는 예제가 제일 편합니다.
/etc/ansible/ansible.cfg에 fact_caching을 주석으로 없앴습니다.
이렇게 하면 default인 memcache를 사용하게 됩니다.
그러면 어떻게 동작할까요?
두번 실행해 보겠습니다.
대략 10초 후에~!
같은 점과 차이 점이 보이시나요?
아니아니 이렇게 생긴 것도 아닌데...-_-; 금방 다 찾으셨겠죠?
같은 점
Gathering FACT 즉, 인자 값을 또 수집합니다. -_-
redis에 저장했을때는 안 했었죠!!
차이 점
인자 값인 시간이 변경되었습니다.
memcache이기 때문에, playbook이 생성되고, 실행되는 동안에 유지하고, playbook을 다시 실행할때는 FACT를 다시 생성하고 저장합니다.
이런 것들로 비추어봤을때 redis를 쓰면 어떤게 유리할까요?
여러번의 playbook을 반복 실행할때 소요시간을 줄여 줄수 있습니다.
또한, 사용자원이 적을 야간에 해당 작업을 수행해서 (변경이 없다는 가정하에...)
FACT를 저장해 놓고, 해당 부분을 이용해서, 주간에 작업을 수행하면서 검토합니다.
그렇다면 어떤 단점이 있을까요?
오히려 저장된다는게 단점이 될수 있습니다.
저장되니...변경되는 데이터에 반응이 안됩니다. -_-
또한 메모리의 일정 공간을 점유하고, 리소스를 놓아주지 않습니다.
해당 부분을 잘 고려해서 쓴다면, 유용하게 사용할수 있을 것 같습니다. :)
3. Callback (tag : 관리자외 대부분이 쓰면 좋음 )
그러면 다음으로
Action PluginsCache Plugins- Callback Plugins
- Connection Plugins
- Inventory Plugins
- Lookup Plugins
- Shell Plugins
- Strategy Plugins
- Vars Plugins
- Filters
- Tests
콜백을 알아볼까요?
콜백은 아주 짧게 정의하자면, 플레이북 실행 시에 나오는 내용을 세부적으로 확인할 수 있게 해주는 것입니다.
이를 통해서 debug도 하고, 성능도 점검하고, 내용이 잘 진행되었는지 추후에 확인도 하고 그런 여러가지 목적으로 쓰이는 거죠 :)
콜백으로 쓰일수 있는 아이템들은 어떤게 있을까요?
단순히 로그의 내용을 더 자세하게 보여주는 애들부터, 기록해주는 log_plays, 슬랙으로 전달해주는 slack, jabber까지 다채롭습니다. 추후에는 계속 더 추가되겠죠~!
- actionable - shows only items that need attention
- context_demo - demo callback that adds play/task context
- debug - formated stdout/stderr display
- default - default Ansible screen output
- dense - minimal stdout output
- foreman - Sends events to Foreman
- full_skip - suppreses tasks if all hosts skipped
- hipchat - post task events to hipchat
- jabber - post task events to a jabber server
- json - Ansbile screen output as JSON
- junit - write playbook output to a JUnit file.
- log_plays - write playbook output to log file
- logentries - Sends events to Logentries
- logstash - Sends events to Logstash
- mail - Sends failure events via email
- minimal - minimal Ansible screen output
- null - Don’t display stuff to screen
- oneline - oneline Ansible screen output
- osx_say - oneline Ansible screen output
- profile_roles - adds timing information to roles
- profile_tasks - adds time information to tasks
- selective - only print certain tasks
- skippy - Ansible screen output that ignores skipped status
- slack - Sends play events to a Slack channel
- stderr - Splits output, sending failed tasks to stderr
- syslog_json - sends JSON events to syslog
- timer - Adds time to play stats
- tree - Save host events to files
- unixy - condensed Ansible output
- yaml - yaml-ized Ansible screen output
https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback
기존에 현재 시간을 보는 플레이북을 그대로 사용하겠습니다.
callback_whitelist 설정을 profile_tasks, timer 했을때는?
callback_whitelist 설정을 profile_roles, timer 했을때는?
성능을 테스트할 수 있겠죠?
그렇다면, 엄청 많은 내용을 돌려놓고 나중에 보려면? 어떻게 할까요?
물론 대부분의 셸프로그램은 화면에 출력되는 내용을 표시해 주지만요
그런거 말고 log_plays로도 가능합니다.
log_plays를 그냥 추가합니다.
해당 실행 내용이 '/var/log/ansible/hosts/호스트이름' 에 기록됩니다. :) 자동으로요~!
그리고 현재 화면에 출력되는 (stdout)을 조정할 수 있습니다.
두가지 정도 살펴 볼까요?
dense (조밀한, 촘촘한?) 으로 변경해 보겠습니다.
그리고 실행하면 어떻게 될까요?
화면에 출력되는 내용이 촘촘하게 변경되었죠?
그렇다면 selective는 어떨까요?
휠씬 더 ...-_-; 이건 보이는게 거의 없는 수준이네요..
여튼...화면에 출력되는건 상황에 맞게 조정하여 볼수 있습니다~!!
[ 참고사항 ]
Whitelist라는건 블랙리스트 반대말로 허용하는 리스트 같은 겁니다. :)
위트있게 기억하게 쉽게 callback을 허용하는 리스트라고 적어 둔거네요 ~!!
이래서 개발자들이 좋습니다~!
플러그인에 대해서는 갈 길에 생각보다 머네요~~ 하하하;;;;
저 길의 끝은 어디려나...ㅎㅎㅎㅎㅎㅎ 내일 다시 돌아옵니다 :)
2018년에 보아요~!
0 개의 댓글:
댓글 쓰기