키바나 7.0부터 mobile을 지원한다.. (beta 1)




https://github.com/elastic/kibana/issues/2563


https://github.com/elastic/kibana/pull/29896



이젠 점점 elasticsearch가 무서워진다~

Posted by 김용환 '김용환'





ansible-playbook 커맨드를 실행하기 전에 플레이북을 확인할 수 있는 플래그가 있다.


1. 문법 체크


--syntax-check 플래그는 플레이북 문법이 유효한지 확인하지만 실행하지 않는다.


$ ansible-playbook --syntax-check playbook.yml





2. 호스트 나열하기


--list-hosts 플래그는 플레이북이 실행될 호스트를 출력하지만 플레이북을 실행하지 않는다.


$ ansible-playbook --list-hosts playbook.yml






3. 태스크 나열하기 


--list-tasks 플래그는 플레이북이 실행될 태스크를 출력하지만 플레이북을 실행하지 않는다.


$ ansible-playbook --list-tasks playbook.yml






4. 체크 모드


-C 플래그와 --check 플래그는 앤서블을 체크 모드를 실행한다(때때로 드라이 런(dry-run)이라 한다) 


즉 플레이북의 각 태스크가 호스트 수정 여부를 알려주지만 서버에 어떠한 변경이 발생하지 않는다.



$ ansible-playbook -C playbook.yml

$ ansible-playbook --check playbook.yml



체크 모드를 사용할  때의 어려움 중 하나는 플레이북의 처음 부분이 실행될 때만 플레이북의 뒷 부분이 성공할 수 있다는 점이다.





5. diff (파일 변경을 표시한다)

-D 플래그와 -diff 플래그는 원격 머신에서 변경된 모든 파일의 출력 비교 정보를 표시한다. 


정상적으로 실행되었다면 앤서블이 파일을 변경하는 방법을 표시하기 위해 -D 플래그와 -diff 플래그를 --check와 함께 사용하면 도움이 된다.


$ ansible-playbook -D --check playbook.yml

$ ansible-playbook --diff --check playbook.yml



앤서블이 파일(예시: copy, template, lineinfile과 같은 모듈을 사용)을 수정하면 다음처럼 .diff 포맷의 변경 사항을 표시한다.


-loglevel = "error"

+loglevel = "warning"





Posted by 김용환 '김용환'



앤서블에서 실행할 태스크를 제어할 수 있다.


가끔 앤서블이 플레이북의 모든 태스크를 실행하는 것을 원치 않을 수 있다. 


특히 플레이북을 처음 작성하고 디버깅할 때 더욱 그렇다. 앤서블은 실행할 태스크를 제어할 수 있는 커맨드 라인 옵션을 제공한다.




1) step


--step 플래그는 다음처럼 각 태스크를 실행하기 전에 앤서블 프롬프트를 표시한다.


Perform task: install packages (y/n/c):


태스크를 실행하거나(y) 건너 뛰거나(n) 프롬프트를 표시하지 않고 나머지 플레이북을 계속 실행하도록 앤서블에 알릴 수 있다(c).


$ ansible-playbook --step playbook.yml






2) start-at-task



--start-at-task <태스크 이름> 플래그는 처음부터가 아닌 지정된 태스크에서 플레이북을 실행하기 시작하도록 앤서블에 알려준다. 


태스크 중 하나에 버그가 있어서 태스크 중 하나가 실패해서 실패한 태스크를 수정해 해당 태스크부터 시작해 플레이북을 다시 실행하고 싶을 때 유용할 수 있다.



$ ansible-playbook --start-at-task="install packages" playbook.yml




3) tags



앤서블에서는 하나 이상의 태그를 태스크 또는 플레이에 추가할 수 있다. 예를 들어 foo라는 태그가 붙은 플레이와 bar와 quux라는 태그가 붙은 플레이가 있다.



- hosts: myservers

  tags:

   - foo

  tasks:

   - name: install editors

     apt: name={{ item }}

     with_items:

       - vim

       - emacs

       - nano


   - name: run arbitrary command

     command: /opt/myprog

     tags:

       - bar

       - quux





-t <태그 이름> 플래그와 --tags <태그 이름> 플래그를 사용해 특정 태그를 포함한 플레이와 태스크만 실행하도록 앤서블에 알린다. --skip-tags <태그 이름> 플래그를 사용해 앤서블에 특정 태그를 포함한 플레이와 태스크를 건너 뛰라고 알린다.



태그를 실행하거나 건너뛰기

$ ansible-playbook -t foo,bar playbook.yml

$ ansible-playbook --tags=foo,bar playbook.yml

$ ansible-playbook --skip-tags=baz,quux playbook.yml


Posted by 김용환 '김용환'



프로그래머 열정을 말하다 책을 봤다. 너무 재미있었다.

http://www.yes24.com/Product/Goods/6185848



원서는 My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers)  이다. 

https://www.amazon.com/Job-Went-India-Pragmatic-Programmers/dp/0976694018  (2005년에 쓰여진 책이라니!!)





44살의 개발자 아저씨가 보기에 정말 중요한 내용인 것 같다. 다 완벽하고 좋은 말은 아니지만...


개발을 계속 하고 싶고, 프로그래밍하는 것이 즐겁다면 꼭 보면 좋을 것 같다.




책 내용을 간결히 요약한 블로그가 있으니. 참고하길 바란다.


http://jehyunpark.github.io/book/2017/02/12/the-passionate-programmer.html



Posted by 김용환 '김용환'


클라우드 시스템을 관리하는 기술(http://www.hanbit.co.kr/store/books/look.php?p_code=B9686521083)에서 발췌한 자료이다.



Site Reliability 관행

1. 개발자(coder)만 고용한다.

2. 서비스마다 SLA를 둔다.

3. 성능을 측정하고 SLA를 만족하지 못하는 사항을 보고한다.

4. 오류 계산을 활용하고 개시(lauch)들이 반드시 오류 예산을 지키게 한다.

5. 공통의 직원 풀에서 SRE팀과 개발팀에 인원을 공급한다.

6. 여분의 (운영팀의 수용 능력을 넘는) 운영 (OPS) 작업은 개발팀(DEV)로 흘러가게 한다.

7. SRE 운영 부하가 50%를 넘지 않게 한다.

8. 운영팀의 작업의 5%를 개발팀과 공유한다.

9. 호출대기 팀은 한 장소에 적어도 여덟 명으로 구성하거나 여러 장소들 각각에 적어도 여섯 명으로 구성한다.

10. 호출 대기의 한 교대 근무(shift) 기간에 발생하는 사건이 최대 2회를 넘지 않도록 한다.

11. 모든 사건에 대해 사후 분석(postmortem)을 수행한다.

12. 사후 분석이 누군가를 비난하는 기회가 되어서는 안된다. 사람보다는 공정과 기술에 초점을 두어야 한다.


Posted by 김용환 '김용환'





2017년 우버에서 자기들이 사용하는 hoodie를 공유했다.


https://eng.uber.com/hoodie/





이게 개념적으로 kappa 아키텍처 (보통 우리가 쓰는 lamba 아키텍처의 다음 버전, incremtal )으로

HDFS에 metadata, index, data를 Spark 라이브러리로 구현한 오픈 소스(https://github.com/uber/hudi)이다.


스키마 이슈를 풀기 위해 avro를 사용하고 컬럼 기반의 최적화된 성능을 보장하기 위해 parquet를 사용다. 읽을 때는 컬럼 단위로 읽으니 Scan에 최적화된 Parquet, 저장할 때는 스키마 이슈없고 row단위로 저장하는 Avro를 사용한다. 컴파일 병렬화, 쿼리 병렬화, HDFS의 파일 이슈(쿼터)를 해결하기 위해 HDFS 블록 크기로 저장한다.


저장할 때 데이터를 정확히 partition 단위로 저장하고, HDFS 블록 크기만큼 채워서 저장한다. 그런식으로 계속 저장한다. 데이터의 변경은 bloom filter로 미리 저장한 위치를 빨리 찾도록 변경된 데이터를 추가하는 방식을 사용하고 있다. 


compaction은 시간제한이 걸려 있고 몇 분마다 비동기로 진행한다. 이때 compaction과 변경이 걸리면 이슈가 되니 lock을 zookeeper로 걸어 사용한다. 




유투브 발표 자료.








그리고 2018년 7월에 하나의 블로그를 올려놨다.

https://eng.uber.com/uber-big-data-platform/


나름 kappa 아키텍처 기반임에 틀림없다. 





중요한 포인트는 증분 데이터를 append함으로서 최종 값과 증분 값 모두 읽을 수 있다는 점이다. 





Posted by 김용환 '김용환'


스크립트에서 현대 디렉토리를 지정하기 위해 다음과 같은 스크립트를 많이 사용한다. 


my_root=$(cd $(dirname $(readlink $0 || echo $0))/../;/bin/pwd)



그런데 맥에서 이런 에러가 발생했다.


dirname: illegal option -- b




bash에서 $0이 스크립트 경로를 알려주는 것이라 알고 있긴 하지만... 사실 보장하지 않는다.

완벽히 보장하는 bash script를 개발하려면 BASH_SOURCE를 사용하길 바란다.



SCRIPT_PATH=${BASH_SOURCE[0]}

my_root=$(cd $(dirname $(readlink ${SCRIPT_PATH} || echo ${SCRIPT_PATH}))/../;/bin/pwd)




Posted by 김용환 '김용환'


앤서블의 호스트 지정 패턴

플레이북의 host 매개 변수에 보통 단일 호스트 또는 그룹을 지정하는데..

hosts: web

단일 호스트 또는 그룹을 지정하는 대신 패턴을 지정할 수도 있다. 이미 all 패턴을 봤었다. all  패턴은 알려진 모든 호스트들에 대해 플레이를 실행할 것이다.

hosts: all

콜론을 사용해 두 그룹의 합집합을 지정할 수 있다. 다음처럼 모든 dev 머신 및 staging 머신을 지정할 수 있다.

hosts: dev:staging

\콜론과 앰퍼샌드(:&)를 사용하여 교집합을 지정할 수 있다. 예를 들어 staging 환경에서 모든 데이터베이스 서버를 지정하려면 다음처럼 지정할 수 있다.

hosts: staging:&database


표 9-1은 앤서블이 지원하는 패턴을 보여준다. 정규식 패턴은 항상 물결 기호(~)로 시작한다.



액션

사용 예시

모든 호스트

all

모든 호스트

*

합집합

dev:staging

교집합

staging:&database

배제

dev:!queue

와일드카드

*.example.com

번호로 지정한 서버의 범위

web[5:10]

정규식

~web\d+\.example\.(com|org)





앤서블은 여러 패턴 조합을 지원한다. 예를 들면 다음과 같다.

hosts: dev:staging:&database:!queue




또한 호스트의 임의 조합을 예시처럼 지정할 수 있다. $ ansible-playbook -l 'staging:&database' playbook.yml


Posted by 김용환 '김용환'


ansible-vault 커맨드 간단 정리



커맨드

설명

ansible-vault encrypt file.yml

일반 텍스트 파일인 file.yml을 암호화한다

ansible-vault decrypt file.yml


암호화된 file.yml 파일을 해독한다

ansible-vault view file.yml

암호화된 file.yml 파일의 내용을 출력한다

ansible-vault create file.yml

암호화된 새로운 파일 file.yml을 생성한다

ansible-vault edit file.yml

암호화된 파일 file.yml 파일을 수정한다

ansible-vault rekey file.yml

암호화된 파일 file.yml의 암호를 변경한다




앤서블 2.4 버전부터는 커맨드 라인에서 --vault-id를 사용해 볼트 암호 사용을 권장하고 있다.


암호가 ~/password.txt 텍스트 파일에 저장되어 있고 --vault-id 플래그를 사용해 암호 파일의 위치를 ansible-playbook 에게 전달한다.

ansible-playbook --vault-id ~/password.txt secrets.yml


암호화 파일을 해독하려면 --vault-id @prompt 플래그를 사용한다.

ansible-playbook --vault-id @prompt secrets.yml



앤서블 2.4 버전 이전에는 앤서블 실행시 하나의 볼트 암호만 사용할 수 있었었지만 2.4 버전 이후부터 다중 볼트 암호를 사용하여 지원해 --vault-id를 여러 번 제공할 수 있다. 그러나 --vault-id 옵션은 Ansible 2.4 이전 버전을 지원하지 않는다.

여러 볼트 암호가 제공된 경우 기본적으로 앤서블은 커맨드 라인에서 제공된 순서대로 각 볼트 암호를 시도하여 볼트 내용을 해독할 것이다.

예를 들어 특정 파일에 읽은 'dev' 암호를 사용해 'prod' 암호를 입력하라는 메시지를 표시하려면 다음과 같이 사용할 수 있다.

 

ansible-playbook --vault-id dev@dev-password --vault-id prod@prompt secrets.yml



자세한 정보는 https://docs.ansible.com/ansible/latest/user_guide/vault.html에..



Posted by 김용환 '김용환'



sbt test를 실행하다 다음과 같이 종료 에러가 나면.. (Intellij에서는 이상이 없다)



19/01/17 22:16:40 ERROR Utils: uncaught error in thread spark-listener-group-streams, stopping SparkContext

java.lang.InterruptedException

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2014)





build.sbt에 다음 파일을 추가한다.


fork in run := true 


로 수정한다. info 로그를 error로 처리하는 것이 맘에 들지 않지만 .. 작동은 된다.





Intellij와 sbt를 함께 사용하고 있기 떄문에 그럴 수 있는데.


console 커맨드를 사용해 scala 코드를 실행하면 SBT와 동일한 가상 시스템에서 코드가 실행된다. 상황에 따라 System.exit 호출이나 종료되지 않은 스레드와 같이 SBT가 중단될 수 있다. 


테스트 결과 JVM이 종료되면 SBT를 다시 시작해야 하는 상황을 피하기 위해 JVM을 포크하는 fork in run := true를 추가한다.

Posted by 김용환 '김용환'