[Ansible] Plugin 살펴 보기 2편 (Callback)

시작하기에 앞서 지난 글에서 redis를 썼었는데요
이걸 왜 쓴다고 하는걸 안 쓴거 같더라고요.

예제를 볼까요~? 이해를 위해서는 예제가 제일 편합니다.

/etc/ansible/ansible.cfg에 fact_caching을 주석으로 없앴습니다.
이렇게 하면 default인 memcache를 사용하게 됩니다.
그러면 어떻게 동작할까요?

두번 실행해 보겠습니다.

대략 10초 후에~!

같은 점과 차이 점이 보이시나요?
아니아니 이렇게 생긴 것도 아닌데...-_-; 금방 다 찾으셨겠죠?

같은 점
Gathering FACT 즉, 인자 값을 또 수집합니다. -_-
redis에 저장했을때는 안 했었죠!!

차이 점
인자 값인 시간이 변경되었습니다.
memcache이기 때문에, playbook이 생성되고, 실행되는 동안에 유지하고, playbook을 다시 실행할때는 FACT를 다시 생성하고 저장합니다.

이런 것들로 비추어봤을때 redis를 쓰면 어떤게 유리할까요?

여러번의 playbook을 반복 실행할때 소요시간을 줄여 줄수 있습니다.
또한, 사용자원이 적을 야간에 해당 작업을 수행해서 (변경이 없다는 가정하에...)
FACT를 저장해 놓고, 해당 부분을 이용해서, 주간에 작업을 수행하면서 검토합니다.

그렇다면 어떤 단점이 있을까요?
오히려 저장된다는게 단점이 될수 있습니다.

저장되니...변경되는 데이터에 반응이 안됩니다. -_-
또한 메모리의 일정 공간을 점유하고, 리소스를 놓아주지 않습니다.

해당 부분을 잘 고려해서 쓴다면, 유용하게 사용할수 있을 것 같습니다. :)

3. Callback (tag : 관리자외 대부분이 쓰면 좋음 )

그러면 다음으로

• Action Plugins
• Cache 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년에 보아요~!

[Continue reading...]

[Ansible] Plugin 살펴 보기 1편 (Action, Cache)

Plugin은 사실 알아도 되고...몰라도 되고...
알면 좋은 정도? 하지만 향후에 진짜 정말 정말 정말 나중에 나만의 코드를? 만들고 싶을때 참조할 만한 정보와 좀 더 효과적으로 앤서블을 사용하고자 할때 필요한 내용들이 들어 있습니다.

그러니...이 말을 반대로 하면 어렵다는거죠 -_-

매번 글을 쓰면 쉬워요.
금방해요.
이정도야 다 그냥 그까이꺼....라고 썼는데 ......차마 이번꺼는 .....그렇게 못 쓰겠네요.
(따라서 인용도 과도하게 많습니다. 하하하;;;;)

플러그인은 현재 (공식적으로) 아래와 같은 애들이 있습니다.
https://docs.ansible.com/ansible/devel/plugins.html

• Action Plugins
• Cache Plugins
• Callback Plugins
• Connection Plugins
• Inventory Plugins
• Lookup Plugins
• Shell Plugins
• Strategy Plugins
• Vars Plugins
• Filters
• Tests

그나마 눈에 들어오는건 CallBack이랑 Strategy네요.
왜냐...면 이전에 했으니까요 :) 하하하하;;;;

하나하나 살펴 보도록 합시다.

1. Action (tag : 거의 개발자 전용)
이건 간단하게 말하자면, 할 행동에 부가적으로 들어가는 것들을 정의하는 것입니다.
이미 쓰이고 있는건 Template을 만들때 쓰이고 있고, 실제로 Backup을 위해서 정의하는 것으로 가장 유명하게 쓰입니다.

이렇게 글로 보면 무슨 말인지 감이 안 오시겠죠 -_-?
저 또한 공홈에 있는 말을 아무리 읽어도 감이 안 오더라고....요

1차적으로 모든 모듈에 대한 내부 일부 코드와 설명이 들어 있는 페이지를 참조합니다.
근데 여긴 코드와 설명 그리고, 간단한 내용만 있어서...역시 부족함이 있더라고요.

그래서 Action plugin을 사용한 실 사례를 찾아봅니다.

사례 #1
반복적으로 수행해야 하는 작업이 있는데, 이걸 모듈을 개발하고 모듈의 제한사항인 동적 변수를 읽고 쓰는 부분을 해결하기 위해서, plugin으로 기능을 추가함
http://ndemengel.github.io/2015/01/20/ansible-modules-and-action-plugins/

사례 #2
간단한 모듈+플러그인을 구현하는 예제
https://terryhowe.wordpress.com/2016/05/03/ansible-2-0-modules-and-action-plugins/

사례 #3
네트워크 장비에서는 수시로 일어나는 backup을 action plugin이 이미 구현되어 있는데, 이걸을 확장함. (여러가지의 시행착오가 보이네요..)
https://networklore.com/extending-ansible-action-plugins/

Action plugin 이해를 위해서는 사례#1이 제일 나아 보이네요.

2. Cache (tag : Power-user용)

Cache는 Action에 비하면 아주 쉽습니다.

FACT와 인벤토리 data와 같은 것을 것을 저장하겠다는 거죠.
기본 값은 메모리에 저장하는데, 이것을 활용하거나, 반복적인 작업을 피하기 위해서, 또는 성능향상을 목적으로 따로 저장할 수 있습니다.

저장할수 있는 포맷은 다음과 같은데..

• jsonfile - JSON formatted files.
• memcached - Use memcached DB for cache
• memory - RAM backed, non persistent
• pickle - Pickle formatted files.
• redis - Use Redis DB for cache
• yaml - YAML formatted files.

이를 크게 3개로 구분할 수 있습니다.

1) 영구적으로 저장 안되는거
 - memory : 기본 값

2) 메모리와 유사한 속도 수준으로 저장되며, 오래 가게 할수 있는 것(timeout)
 - memcached
 - redis

3) 디스크에 저장하며, 영구적인 것
 - jsonfile
 - pickle
 - yaml

다른 건 대략 유추가 가능한데, 좀 생소할 수 있는 NoSQL DB인 memcached와 redis에 대해서 간단하게 읽고 넘어가면 좋을 표를 봅시다.

Memcached	REDIS
처리 속도가 빠르다.    - 당연히 데이터가 메모리에만 저장되므로 빠르다. 즉, 속도가 느린 Disk를 거치지 않는다.	처리 속도가 빠르다.    - 당연히 데이터가 메모리+Disk에 저장된다. 그러나, 속도는 Memcached와 큰 차이가 없다.
데이터가 메모리에만 저장된다.    - 당연히 프로세스가 죽거나 장비가 Shutdown되면 데이터가 사라진다.	데이터가 메모리+Disk에 저장된다.    - 프로세스가 죽거나 장비가 Shutdown되더라도 Data의 복구가 가능하다.
만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.    - 이름에서도 느껴지듯이 Cache이다	만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.    - 동일한 기능을 지원한다.
저장소 메모리 재사용    - 만료가 되지 않았더라도  더이상 데이터를 넣을 메모리가 없으면 LRU(Least recently used) 알고리즘에 의해 데이터가 사라진다.	저장소 메모리 재사용 하지 않는다.    - 명시적으로만 데이터를 제거할 수 있다.
문자열만 지원	문자열, Set, Sorted Set, Hash, List등의 다양한 Data Type을 지원.

출처 : http://blog.daum.net/smufu/4

이건 어려운 설명입니다. 궁금해 하시는 분들이 있을까봐
http://blog.leekyoungil.com/?p=200

그리고 추가적으로 NoSQL DB 리스트가 정리된 것도 링크합니다.
LIST OF NOSQL DATABASES [currently >225]


대에에충 어떻게 돌아가는지 확인을 위해서 redis를 한번 써보도록 합시다.

테스트를 위해서는 구성을 변경하고 관련 패키지를 설치해야 합니다.

구성 변경
사실 상은 fact_caching만 변경해 주면, 되나..명시성을 위해서 그냥 다 기입합니다.

그리고 패키지를 설치합니다. 설치 안 하고 그냥 하면 아래와 같이 에러가!!!

패키지들은 다음과 같습니다.
서비스와 소스코드라고 보시면 제일 무난할꺼 같네요.
 - sudo yum install redis
 - sudo systemctl start redis
 - sudo pip install redis

그런 다음에는 테스트를 위한 소스를 작성합니다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

--- - hosts: localhost tasks: - name: 1st fact chk with sleep 2 debug: var: ansible_date_time.time - name: Sleep for a few seconds command: sleep 2 - hosts: localhost tasks: - name: 2nd fact chk with sleep 5 debug: var: ansible_date_time.time - name: Sleep for 5sec command: sleep 5 - hosts: localhost tasks: - name: 3rd fact chck debug: var: ansible_date_time.time

한가지 언급하고 싶은게...timeout값을 조정하면 중간중간에 timeout 시켜서 시간이 바뀌는 것도 확인할 수 있습니다.

자 그러면, 실행해 봅시다.

그리고 일정 시간이 흐른 후에 다시 실행해 봅니다.
여전히 시간 인자 값(ansible_date_time.time)은 그대로 있습니다.
Cache하고 있다는 증거이죠
그리고 또 다른 증거는 gather_fact과정이 생략되어 있다는 것입니다.
(위에 빨간 칸 참조)

그리고 redis로 구성된 NoSQL DB는 다음과 같이 확인이 가능합니다.

1) 직접 DB 접근해서 확인하기
redis-cli
keys ansible*
MGET <key 이름>

2) python 코드로 추출해서 보기

1 2 3 4 5 6 7 8 9 10 11

#!/usr/bin/env python import redis import json r = redis.StrictRedis(host='localhost', port=6379, db=0) key = "ansible_facts" + "localhost" val = r.get(key) data = json.loads(val) print data['ansible_date_time']['time'] # time

JSON으로 저장되어 있는 다시 parsing하는 것입니다.
당장 딱히 필요가 없어서..그냥 테스트로 하드코딩 했습니다. --; 하하하;;;

시간이 바뀐건 'redis-cli flushall'을 통해서 전체 정보를 한번 날려서 그런겁니다.
그렇게 하지 않으면 테스트 기간 동안 (3600초) 계속 정보가 유지되어 테스트가 안됩니다.

추가 정보
FACT에 포함되지 않고, 임의로 지정한 인자 값은 redis로는 cache되지 않는 것 같습니다.
암만 찾아봐도 안되고 아무리 테스트해도 먹질 않네요 -_-

소스 코드는 다음과 같습니다.

[ 넣는 코드 ]

1 2 3 4 5 6 7 8

--- - name: Save facts in redis hosts: localhost gather_facts: yes tasks: - set_fact: redis_var: "cache_it_4_everywhere"

[ FACT는 다시 사용하려고 했던 코드 ]

1 2 3 4 5 6 7

--- - name: Get facts from redis hosts: localhost gather_facts: yes tasks: - debug: var=redis_var

참고사항 : redis에 관련하여 
https://pypi.python.org/pypi/redis
https://redis.io/topics/quickstart
https://ko.wikipedia.org/wiki/%EB%A0%88%EB%94%94%EC%8A%A4




원 제목은 plugin 조금만 살펴 보기 였는데...글이 무슨 고구마 마냥 계속 길어져서...

몇개로 또 쪼개야 할 것 같네요...하하하;;; 이렇게 길게 할 생각 없었는데...;;; 2탄에서 보아요~!

[Continue reading...]

[Ansible] Cache & Async - 성능 개선(Performance-Tuning) 3탄

원래는 크리스마스에 다 마무리 하려고 했는데...
저녁에 좀 쉬자고 한게..다음 날이 되어 버렸네요 -_-

그래서 벌로 오늘 밤에 남아서 작성합니다. ㅠㅠ
나머지 것들이라고 하면 이런 것들이 있습니다.

4. Cache Server 
캐시 서버에 관련된 것은 효과적인 것 1개와 미약한 것 2개가 있습니다.

첫번째는 ....Cent(RHEL)과 같은 애들을 위한 Yum Repository 와 우분투 계열을 위한 apt Repository가 있습니다. 이 정보들은 모두 인터넷에서 긁어 오니...로컬에 캐시 서버를 두고 주기적으로 싱크하자는 개념이죠
당연히 이러면 빨라집니다. :)

특히 보안적으로는 DMZ에 캐시서버를 두고 관리하면 보안 측면에서도 좋겠네요.
관련 툴은 여기서 소개하고 있습니다.
yum's reposync or apt-cacher-ng
(https://www.ansible.com/blog/ansible-performance-tuning)

아주아주 크게 보면 KT에서 쓰고 있는 Youtube cache 서버도 같은 맥락이죠
(이 솔루션 C모사 꺼 였는데 지금도 그건가? 모르겠네용 ㅎㅎㅎㅎ )


미약한 것에 대한 첫번째는
apt에 대한 cache_valid_time 입니다.
현재 앤서블에서는 apt만 지원합니다. 음....향후에는 yum도 될 것 같은데 일단은 진행 중입니다. (링크 : Add an option to specifiy cache valid time period to YUM module)

이게 어떤 내용이냐면, apt-get update를 수행시에 특정 task를 cache_valid_time값보다 (그러니까 아직 나는 때가 아니다 라고 나온다면) 수행하지 않는 것인데....테스크마다 혹은 롤마다 다르게 적용할때 쓸모가 있을 수도 있는 것 같습니다....하하하;;

미약한 두번째 것은 fact_caching 즉 FACT에 대한 캐시입니다.
하지만 1.6 이후로 한번 gather한 것은 다시 gather안 하게다는 'SMART'의 등장으로
캐시는 어디다가 써야 하는지 모르겠습니다. (아시는 분 알려주세용;;;)




5. Async 테스크
Async는 쉽게 말하면 background 작업이 가능하게 해줍니다.
아시는 것처럼 forks된 숫자만큼 앤서블은 순서대로 열심히 꿋꿋이 수행해 줍니다.
그런데, 느린 웹이나, 업데이트가 느린 repo라든가 다양한 문제로 IDLE time이 발생한다면? 이 부분은 백그라운드 처리해 주고, 다른 작업부터 수행하는 것을 의미합니다.

예를 한번 보죠
Centos에 epel-release를 삭제하는 구문에

epel-release를 삭제하는 부분에 async 옵션을 넣습니다.
1000초 동안 5초의 인터벌로 체크하는 것입니다.

[ epel-release를 순서대로 지웠을때 ]

[ epel-release를 async로 처리하고 지웠을때 ]

멍때리는 시간을 줄이니 전체 시간도 많이 줄었네요.
음...-_-; 상황에 따라서는 이게 pipelining 보다 효과적일수도...쿨럭;;;;

=======================
번외편 (개인적으로 추천하지 않는 것들)

Ansible-Pull
알려져 있기로는 repo의 업데이트 확인이나, 굳이 중앙에서 관리할 필요 없는 소소한 것들은 클라이언트 단에서 자체적으로 해결 한다는 컨셉인데...
제일 큰 문제는..? 혹은 이슈는..이걸 위해서 앤서블을 모든 클라이언트에 설치해야 한다는거죠 -_- (내가 잘못 이해하고 있나 -_-?)
물론 요구사항에 따라서 repo 업데이트 확인이나 다른 목적으로 유용하게 사용할 수 있을 것처럼 보이나...굳이 앤서블을 써가면서 이걸 해야 하나 싶네요
어짜피 이걸 다시 crontab에 태워야 하는데 말이죠 ;;;

우앙 이로서 일단 퍼포먼스 튜닝은 마무리 합니다 :)
즐거운 연말~~~ 다들 되세요~~

[Continue reading...]

[Ansible] Forks 그리고 Block - 성능 개선(Performance-Tuning) 2탄

(포크왈 : 어 여기에 첩자가 숨어 있는거 같은데...)

1탄에서는 pipelining을 알아봤다면~!
2탄에서는 가장 처음으로 알아볼 것은 Fork 입니다.
네 위의 그림의 그 fork가 맞습니다. 포크~! 진짜 같은 이름입니다.

2. Forks
다만 앤서블에서는 System call 즉, 한개의 자식 프로세스를 만드는 개념과 비슷하게 쓰입니다. 쉽게 얘기하면 한번에 처리할 수 있는 세션으로 이해하시면 될 것 같네요 :)

기본 값은 위와 같이 5개입니다.
지금까지 하는 테스트랩은 forks를 늘려봐야 별로 빠른 것을 체감하기 어렵습니다. -_-
끽해봐야 8 - 10개니까요...

실무에서는 이와 다르게 제일 앞단에 있는 web server(nginx, apache, IIS, GWS)에 업데이트를 한번에 할때는 fork값을 가능한 만큼 최대한 땡기는게 좋겠죠 :)
이는 앤서버 서버의 성능에 따라 좌우되는 개념이기 때문에 적정 값은 찾기 나름~!

나중에 테스트는 설 이후쯤에 60개에서 100개의 우분투를 올리고 나서 거기에서 테스트 결과를 살펴봐야 겠네요....

3. block
블록이라고 썼다니..레고 블록처럼 모으고 붙이는거 얘기하는건가? 라고 생각하는 분이 있겠죠?




근데 이게 정답입니다. -_-

승용차를 타고 갈때 사람이 타면 사람 무게가 더해지긴 하지만..그래도 다 같이 타는게 더 빠른 시간에 원하는 위치에 도착할 수 있는 것이겠죠?
어짜피 갈꺼면 다 같이 가는게 나은거죠 :)

(승용차급이 안되면 미니버스로~~ ) 

이처럼, 블록단위로 묶어서 워크샵 갈때 처럼 다 같이 모이고 낑겨서 가는 것이
비용적인(속도) 면에서는 효율적인 것 입니다.

이건 테스트가 간단하니 한번 내용을 볼까요?

[ 개별적인 예제 ] 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

--- - hosts: '{{ hosts }}' become: yes gather_facts: no tasks: - name: add user testuser1 user: name: "testuser1" state: present groups: "vagrant" - name: add user testuser2 user: name: "testuser2" state: present groups: "vagrant"

  실행~ 런!

[ 블록으로 묶은 것 ]

1 2 3 4 5 6 7 8 9 10 11 12 13 14

--- - hosts: '{{ hosts }}' become: yes gather_facts: no tasks: - name: add several users user: name: "{{ item.name }}" state: present groups: "{{ item.groups }}" with_items: - { name: 'testuser1', groups: 'vagrant' } - { name: 'testuser2', groups: 'vagrant' }

  실행~ 런!



아주 약간 시간이 단축되었네요. 간단하게 유저를 추가하는 예제니까요.
하지만 대량의 내용을 업데이트할때라면 블록으로 한번에 태워서 보냅시다.
이게 더 빠르거든요 :)

다음에 계쏙~! To be continue~!!

[Continue reading...]

[Ansible] Pipelining - 성능 개선(Performance-Tuning) 1탄

        

이번에 알아볼 내용은 성능 개선 입니다. 뚜둥
로켓처럼 뻥하고 날아가는...수준은 아니지만 느리다고 느끼는 부분을 개선해 볼 겁니다.

사실 원래는 ansible.cfg 깊게 알아보기 (Depp-Dive)를 할려고 생각했는데...
하다보니..이게 성능 개선을 하는게 더 많더라고요 -_-

그래서 걍 선회하여~ 성능 개선으로~ 사실 이거에 다들 관심이 더 많잖나요 :)


(제 속 마음 같다고 생각하신다면, 사실 입니다;;;;;; 휴일이고 크리스마스잖나요..굽신굽신;;)


언제 가장 느린거 같다? 라고 생각이 되시나요?
저는

1. SSH 접속 
이런 얘기 들어보셨나요? ansible계의 괴담 같은 건데요.
python의 Paramiko와 불화로 인해서 paramiko를 버리고 native ssh를 변경하였다.
(아....사실 제가 지금 만들었습니다...-_-; 죄송...) 

각설하고, 왜 기본을 native ssh로 변경하였을까요?
이게 왜 그런가? 하고 추정해 보면요...
앤서블이 가장 좋아하는 것, 즉 커뮤니티에서 가장 선호하는건

 1) 다양한 모든 것을 다 되게 하자.
 2) 있는 그대로를 사용하자

저 2번 때문에, 가능한 기본으로 탑재된 ssh를 쓰고 싶었을텐데..아래의 그림처럼, (저거보다 휠씬 전 버전부터 지원은 됐습니다. ) OpenSSH에서 PersistentControl이 생기고, 이걸 사용하면서 세션을 효과적으로 관리하여 사용할 수 있게 되었죠.



(출처 : https://www.ansible.com/blog/networking-features-in-ansible-2-3)

그래서 이제는 openSSH가 기본으로 지원됩니다.

그리고 좀더 효과적인 기능이 더 지원되게 되는데요..
ssh pipelining이라는 기능을 키게 되면, 일반적으로 앤서블에서는 다음의 3과정을 거쳐서 실행되게 되는데...이것을 1단계로 줄이게 됩니다.

[ 기본 설정 ] 
1) 임시 디렉터리 생성
2) sftp로 실행할 내용 copy (scp로도 변경이 가능하지만 기본은 sftp)
3) 실행

[ pipelining이 켜져 있다면? ]
1) 연결과 실행

이와 같이 ssh의 pipelining을 키게 되면, 디렉터리를 생성하고 파일을 전달하지 않고 ssh자체로 모든 것을 해결합니다.



그런데 pipelining을 켜도 현재 2.4.0, 2.4.1, 2.4.2에서는 제대로 동작을 하지 않습니다. -_-
망...하하하하;;;;

아래의 명령어를 던지고 해당 과정 중에 SFTP가 없어야 하는데 계속 들어가네요..
(심지어 -K로 sudo를 turn on 시켜도 똑같네요..)

테스트 명령어 : ansible '192.168.1.101' -vvv -m shell -a 'echo ok'

관련 버그는 있는데, 해결의 기미가 안보이네요... 어디선가 해결하고 있을까요 -_-?
Pipelining seems to be disabled since Ansible 2.4
 |
 | ---Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user


참고로 몇몇 구 OS는 PersistentControl을 지원하지 않아서 위와 같이 하려면 paramiko를 쓰고 Accelerated Mode로 tuning해야 합니다. 그 외에 sudo를 쓸수 없는 환경이라면 native ssh를 쓸수 없으니 paramiko를 쓰고, 속도를 높이려면 Acc Mode를 써야 겠죠 :)

지금 체감할 만큼 세팅을 할수가 없어서 skip하지만, 다음에 32Gib 노트북에 우분투를 다량을 올려서 테스트하고 올릴 예정입니다. (아마도 설 이후쯤...?)

더 써야 할 내용들이 있는데... 여러 개로 쪼갭니다. 다음 강좌로 쓩~!

[Continue reading...]

[Ansible] 귀중품 보관실 서비스 (vault/볼트)

볼트(vault)는 에니메이션 볼트(Bolt)랑은 다른 단어입니다. ;;;;

사전을 좀 찾아보니 vault라는건...

   - 둥근 지붕, 둥근 천장(모양의 것), 둥근 천장이 있는 장소(복도), 푸른 하늘(the vault of        heaven), 지하(저장)실, (은행 등의)귀중품 보관실, 지하 납골소

그 중에서 귀중품 보관실? 이게 가장 적절한 쓰임의 말이겠네요 :)

그러면 어떤 것들을 귀중품 보관실에 보관하게 될까요


주로 이런 보석이나, 소중한 것들이겠죠?

운영쪽으로 본다면...제일 중요한 것들은 접속 정보 / 아이디 / 암호 같은 것들이겠네요 :)

잘못 해서 이런 정보들이 유출되거나 잘못되면....

이런 곳에 전화하거나..사실 그러기 전에 직장을 잃어버리게 되겠죠 -_-

그렇다고 매번 접속 정보들이나, 필요한 내용들을 다 하나하나 기입하면서 구성 관리하자니....왠지 자동화 툴을 제대로 못 쓰는거 같고...-_-

그래서 절충안으로 쓸수 있는게 ansible-vault 입니다.
그나마 금고에 넣어두면 누군가가 손댈수 없겠죠.

이 금고의 철판의 종류는 AES-256 입니다. 튼튼한 놈이죠 -_-

자 그러면 어떻게 쓸까요? 한번 예시를 볼까요?

[ nginx_remove.yml ]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

--- - name: Remove nginx on the nodes hosts: nodes become: yes tasks: - name: nginx for Ubuntu include_tasks: Ubuntu_nginx_remove.yml when: ansible_distribution == 'Ubuntu' - name: nginx for CentOS include_tasks: CentOS_nginx_remove.yml when: ansible_distribution == 'CentOS' - debug: var=Step_grpVars

nginx_remove.yml을 사용하면, 이미 기존에 사용한 것처럼 노드들에 nginx를 삭제할 수 있습니다. 계속 삭제해도 큰 문제가 없으니...이걸 사용하기로 하고요.

여기서 ~!!
일반적으로 'anp nginx_remove.yml -k' 를 사용해서 ssh password를 입력하게 되는데요

이 귀찮음~~ 귀찮음 ssh password (vagrant)를 매번 매번 매번 입력해야 하는 귀찮음을 벗어나게 위해서 해당 값을 파일로 입력해 둡니다.

해당 값은 여러 곳에 아주 많이 자유롭게 넣을수 있지만요
ssh password를 암호화 할 예정이니까, 독립적으로 만들어 둡니다.

따라서 sudo vi '/etc/ansible/group_vars/' 밑에 all이라는 파일을 만들어 아래와 같이 기록해 둡니다.

[ group_vars/all ]

1 2 3 4

--- # file: group_vars/all ansible_ssh_pass: vagrant Step_grpVars: "group_vars_passed"

그리고 나서 해당 파일을 암호화 시킵니다.

잠깐~!!!

암호화 시키기 전에 해야 할게 있습니다. ansible-vault는 작업마다 vault의 암호를 요청합니다. 그러니까 말이죠...ssh pass 입력하기 귀찮다고 vault pass를 입력해야하는 꼴이 되는거죠


   (오랜만에 보는 혹부리 영감이네요 ...)

그래서 vault pass도 파일로 입력을 받겠습니다.

이러기 위해서는 vault pass를 생성하고 pass 자체가 알려지면 안되니까 해당 파일도 암호화해야 하며, vault pass가 어디 있는지 알려줘야 합니다.

우선

ansible-vault create .passfile 

passfile을 만들고 편의를 위해서 환경 설정들이 있는 곳에 옮겨줍니다.
(친구들과 함께 있으라구요 )

  (함께 있을때는...아 이분들 일반인이라..차마 -_-; 뻘소리 못하겠네요..)


만들때 그리고 내부에는 모두 '1234' 라는 내용을 기입해 줍니다.
우리 모두 알수는 없지만 1234입니다 -_-













그리고, valut pass의 위치 변경은 /etc/ansible/ansible.cfg 에서

  # If set, configures the path to the Vault password file as an alternative to
  # specifying --vault-password-file on the command line.
  #vault_password_file = /path/to/vault_password_file
  vault_password_file = /etc/ansible/.passfile

마지막에 있는 것처럼 .passfile이 valut 암호 파일이라고 알려줍니다.


자 이제 vault pass에 대한 설정이 다 되었으니...
해당 설정 값으로 group_vars에 있는 all을 암호화할 차례입니다.




암호화가 끝나고 나면, vagrant로 바로 실행하게 하기 위해서 유저와 그룹 권한을 변경해 줍니다.

이거 전에 변경하면 다 처음부터 해야 합니다. -_-; 한마디로 망합니다.

왜냐하면 순수하게 '1234'는 같다고 해도 AES256에 방식에 따라 다르게 기입하기 때문입니다.

자세하게 알고 싶다면 이걸 클릭..

암호화 된 것은 보고 실행할까요?

이제 실행~!!






[ 참고사항 ]

.passfile은 순환구조로 읽어서 암호화를 했기 때문에 ansible-vault로는 볼수가 없습니다. 정확하게는 ansible.cfg를 수정하고 나서 봐야 하고요


그리고 all 파일의 경우에는 ansible-vault edit 또는 view 등으로 볼수가 있으므로, 추가적으로 암호화 하거나, 유저 권한으로 제한하는게 옳다고 보여지네요.

이렇게 되면 일반 유저는 어쨌든 전혀 볼수가 없을테니까요 :)

그리고 핵심은 유출시에 plain_text가 아니기 때문에 해당 파일을 볼수가 없다는 장점이 있는것이죠. 

또한 윈도우와 같이 다른 환경 설정이 필요한 것이라든가...또는 네트워크 장치등에 대한 정보들을 모두 한번에 group_vars 또는 host_vars 외에 role의 vars로 관리하는 것도 생각해 볼만 하네요. :) 

[Continue reading...]