[Ansible] hosts did not meet host_list requirements 메시지 처리하기

Ansible 을 사용할때에 인벤토리 파일에 대해서 가끔 “hosts did not meet host_list requirements, check plugin documentation if this is unexpected” 메시지를 보게 된다. 이 메시지는 ‘ansible -vvv ‘ 처럼 -v 옵션을 주면 보인다.

이 메시지는 인벤토리 파일 형식으로 인한 것으로 ini 형식을때에 주로 나온다. 하지만 인벤토리 파일 형식이 ini 형식임을 ansible 이 인지하지 못해서 벌어지는 일인데, 이는 ansible.cfg 파일에 다음과 같이 함으로써 없앨 수 있다.

한국 직장에 고질병

한국 조직문화의 고질병

한국의 조직의 고질병은 능력있고 성실한 사람에게 보상을 주기는 커녕 일을 더 준다는 것에 있다. 그래서 능력있는 사람은 못 견디고 떠나가고 능력없는 사람은 일도 없고 스트레스도 없으니가 조직에 오래 남을 수 있음. 결국 무능한 사람만 남은 무능한 조직이 된다..

일은 일잘하는사람에게 밀어주고
진급은 술잘마시는 사람에게 시켜주고 …

이것이 한국 직장 병패임.

 

똑똑하고 일 잘하고 회사를 위한 합당한 이의제기를 하는 사람 보다
윗 사람의 말에 절대 반기안들고 YES만 하는 사람이 오래다니죠
사장 옆에는 항상 항상 그런 사람이 있더라구요…

 

대부분의 조직에서 능력있는 사람은 나가고 능력없는 사람만 남는 건 맞는데, 꼭 저렇게 능력있는 사람에게 보상없이 일만 줘서라기보단 더 나은 보상을 받을 수 있는 조직을 찾아 떠나는 거죠. 그럴 능력이 안 되면 마땅히 갈데가 없으니 붙어 있는 거고. 조직마다 줄 수 있는 보상의 한계치가 다르니…

Ansible fingerprint 접속 오류.

서버에 맨 처음 SSH 접속을 시도 하면 다음과 같은 오류가 발생한다.

이를 해결하기 위해서는 다음과 같이 환경변수를 지정해 주면 된다.

혹은 ~/.ansible.cfg 파일에 다음과 같이 지정해도 된다.

 

Ansible Inventory 에 대해

Ansible 에서 Inventory 라고 하면 리모트 서버에 정보 리스트를 말한다. 이를 대부분 파일로 저장해서 보관하는데 이를 Inventory file 이라고 부른다.

Inventory: (특정 건물 내의) 물품 목록, … 의 목록을 만들다.

리모트 서버 접속 목록을 Inventory  라고 보면 된다.

INI vs Yaml

Ansible Inventory 파일의 형식은 INI 와 Yaml 형식 두가지를 지원한다. INI 형식은 대략 다음과 같다.

브랏켓(Bracket, ‘[]’) 감싼 것은 서버의 그룹을 말한다. 그리고 그 그룹내에 접속하고자하는 서버들의 정보를 입력해준다. 간단하게 서버의 이름을 입력해주면 된다.

Yaml 형식은 다음과 같다.

INI 형식과는 조금 색다른 면을 보여준다.  hosts, children 이 보이고 children 아래에 그룹을 정의하고 있다.

뭐가 되었던 인식하기 쉬운것을 선택해서 사용하면 그만이다.

서버명 정규표현

서버명이 숫자 혹은 알파벳순으로 연속적이라면 다음과 같이 사용해 볼 수 있다.

 

Inventory 옵션들

서버들이 기본 설정을 그대로 사용하기도 하지만 변경해서 사용하기도 한다. 예를들어, SSH 접속 기본 포트 22이 아닌 다른 것을 사용할 경우나 로그인 사용자가 다를 경우에 이를 인식시켜줘야 하는데 Ansible 은 Inventory 에서 이를 지원한다.

INI 형식에서 다음과 같이 사용할 수 있다.

Yaml 형식에서는 다음과 같이 사용할 수 있다.

이는 서버마다 적용할 수 있고 전체에 한꺼번에 적용할 수 있는데, 서버전체 적용하기 위해서는 다음과 같이 하면 된다. INI 형식은 다음과 같다.

YAML 형식은 다음과 같다.

 

ElasticSearch Multi Instance 설치.

ElasticSearch 도 Tomcat 과 같이 Multi Instance 설치를 지원한다. 이는 ES_HOME의 쉘 환경 변수를 지정함으로써 실현된다. Tomcat 의 경우에는 CATALINA_HOME, CATALINA_BASE 였다. 대신 ElasticSearch 에서는 ES_BASE 가 없다.

ENV 변수

ElasticSearch 에서 사용하는 환경변수는 다음과 같다.

  • ES_HOME: elasticsearch 바이너리 설치 위치.
  • ES_PATH_CONF: elasticsearch 설정파일이 있는 디렉토리 위치.
  • ES_TMPDIR: elasticsearch 임시 디렉토리

위 두 변수를 가지고 MultiInstance 구성을 할 수있다.

ES_HOME 설치

ES_HOME 설치는 elasticsearch 의 바이너리를 압축해제함으로써 끝이 난다.

/opt 디렉토리에 압축을 해제한 후에 심볼릭링크를 걸어준다.

ES_BASE 생성

ES_BASE 는 ElasticSearch 에서 공식적으로 지원하는 변수는 아니다. 하지만 Tomcat 의 CATALINA_BASE 처럼 CATALINA_HOME 을 기반으로 구성되는 Instance 의 위치를 나타내고자 내가 사용하는 변수다.

여기서 ES_BASE 는 /home/systemv/masternode1 으로 하도록 하겠다.

이제 ES_BASE 디렉토리를 생성해 준다.

conf 디렉토리만 복사해 온다.

그리고 conf 디렉토리에서 elasticsearch.yml, jvm.options 파일을 편집해준다.

elasticsearch.yml

주요한 설정은 디렉토리 설정이다.

jvm.options

여기서는 gc 로그 디렉토리 위치를 ‘/home/systemv/masternode1/logs’ 로 변경해준다. 그리고 -Djava.io.tmpdir=${ES_TMPDIR} 로 지정해 준다.

ES_BASE 실행

실행은 다음과 같이 환경변수를 지정함으로써 실행시킬 수 있다.

위와같이 하면 ES_BASE 를 기반으로 ElasticSearch 가 동작하게 된다.

ElasticSearch 의 패키지 하나만 가지고 여러개를 동시에 실행시킬 수 있다는 장점이 있다.

 

AWS 를 국내 기업도 다 하고 있다고???

국내기업과 세계적인 글로벌 기업인 AWS 와 기술력 별 차이가 없다고??? 기술력에 별차이가 없다라….

AWS 의 경우 가상화기술인 Xen 에 많은 기술적인 기여를 하고 있는데, 기술력으로 별차이가 없다는 국내기업은 무엇을 하고 있나? NoSQL 로 유명한 DynamoDB 를 만들었고 MySQL 코어를 수정해 Auroa DB 를 제작.. PostgreSQL 기반으로 RedShift 도 만들었다.

기술력에 별차이가 없다는 국내 기업은 과연 무엇을 만들 수 있나?

AWS, MS가 제공하는 서비스를 제공하고 있다고?? AutoScaling 서비스를 제공하는 업체가 있는가? ALB(Application ELB) 를 제공하고 Web Console 에서 제어가 가능한가?

국내 어디 업체냐? 구경이나 해보자.. 무료 1달 이용권 같은,, 아니 있으면 저렴한 가격 결제해서 사용해 본다.. 거기 어디냐?

기사출처: ‘AWS 서버장애’에…韓클라우드 산업 “자체 글로벌 경쟁력 키워야”

Python – easy_install, pip 설치하는 방법

Python 에서는 easy_install, pip 를 설치하는 방법중에 하나가 ‘get-pip.py’ 스크립트를 이용하는 것인데, 다음과 같다.

wget, curl 과 같은 프로그램을 이용할 수 없을 경우에 python 프로그램을 이용할 수도 있다.

python3 의 경우에는 다음과 같다.

python2 의 경우에는 다음과 같다.

 

한줄짜리 python 프로그램으로 get-pip.py 를 다운받고 설치를 해준다. ‘–user’ 는 사용자 홈 디렉토리를 설치 디렉토리로 삼게 한다.

 

[펌,수정]기업이 좋은 직원을 잃는 과정… ㄷㄷㄷㄷㄷㄷ

사원 A 입사 (9월)

사원 B 입사 (12월)

3개월 정도 차이지만 A 는 코딩자체에 흥미도 없고 프로젝트 이해력도 떨어지고 심지어 노력도 안함.

문서 제한일이 다가와서 다들 야근 할 때도 자기가 할 일은 다 하지도 않은 채 자기는 칼퇴주의라며 칼퇴.

결국 그 사람 일 다른 사람이 맡아서 하고 그러다보니 또 다른 팀원은 야근 ㅋ

B 는 코딩을 좋아하고 이해력이 좋음. 빨리 적응했고 그러다보니 출장 관련 업무도 다 함.

잦은 출장을 가게되고 조그마한 파트도 맡아서 진행. 팀장은 믿는다면서 여러 일을 더 맡김ㅋ 일이 나날이 많아짐.

이 친구도 정시퇴근을 초반에 계속 하다가 업무량이 많아지니 야근을 할 수밖에 없게됨..

2년 지났는데 A 는 여전히 일 못하지만 팀장은 그냥 쟤는 원래 못하니까 라고 놔둠.

B 는 업무량 다 못채우면 믿었는데 어떻게 그럴수 있냐며 서운함을 표함 ㅋㅋㅋㅋㅋㅋ

B 에게 조기진급으로 대리를 달아주겠다고 호언장담 하더니 윗선(임원)에서 아직 이르다고 거절먹음ㅋㅋ

연봉자체를 공개하면 안되는데 회사에서 올해는 공평하게도 연봉을 모두 5% 씩 올려주겠다고 공표함ㅋㅋ

B 는 좆같네 하면서 기업 퇴사하고 카카오 감…

A 는 5% 좆같네 하면서 다른 기업 갔다가 적응 못하고 (거긴 못한다고 안봐주나보지 ㅋ) 거기도 퇴사하고 돌아오겠다지만

받아주지 않음 절대 ㅋ

실화입니다. 기업이 좆같은 이유는 인재관리도 좆같이해서 그렇습니다.

http://www.ddanzi.com/free/539055230


실제로 내가 사회생활을 시작하면서 지금까지 거의 한평생을 겪었던 일이다. 나는 컴퓨터를 다루는걸 좋아한다. 다른게 있다면 엔지니어가 됐다는 것 뿐이다.

대학때부터도 그랬고 지금도 그렇지만 Linux 를 다루는걸 좋아라했고 자연스럽게 OpenSource 프로그램들을 주로 다루게 되었다. 그리고 인터넷을 움직이게하는 필수 프로그램들에 대해서도 경험을 쌓게됐다. 심지여 DB 까지 어느정도 다뤘으니까.

이력서를 내놓으면 여기저기서 연락이 온다. 그것도 그냥 오는게 아니라 자주 온다. 그러면서 다음과 같이 말한다.

꼭 찾던 인물이다. 함게 했으면 좋겠다.

그리고 입사를 하면 혼자서 Web Server, Was Server, System Monitoring 까지 하는건 좋다. 그런데 DB 작업(설치, Replica, 업그레이드), WAS Memory leak 분석, 프로그램상의 오류를 디버깅하라고 한다. 서버에서 오류가 났으니 그걸 분석하다보면 결국에는 Java 프로그램상의 오류가 대부분이다.

이렇게 일하면서 연봉을 많이 받느냐? DBA 가 있음에도 그 사람은 다음과 같이 당당하게 말한다.

MySQL 설치, Replica, 업그레이드를 해본적이 없어요. Toad 열고 쿼리 작업만 해봤습니다.

한국 SI 산업의 가장큰 병폐가 이런것이다. 경력 13년차를 뽑아놓고 보면 ‘안해봐서 모른다’ 라는 답변하는 하는 사람들이 많다. 하지만 정작 ‘안해봤지만 MySQL 도 DB 니까 대충 이론은 같을 거고 사용법을 익히면 될거 같다’ 라는 말을 하는 인간은 못봤다.

의지를 안가지는 자들 vs 해보겠다는 의지를 보이는 자들

정확하게 저렇게 나뉜다. 많은 프로젝트를 돌아다니다보면 저런 인간들로 다 분류 된다. 자신이 하는 일 외에는 안한다고 하지만 앞서말한 DBA 처럼 자신이 하는 일조차도 자기 스스로가 결정한 영역일 뿐이다.

하지만 해보겠다고 의지를 보이는 자들은 자신이 하는 일에 대한 영역이 산업계에서 요구하는 영역과 일치하는 경우가 많다.

문제는 저렇게 두분류의 사람을 함께 일하게하면 기업들은 결국에는 의지를 가지고 있는 사람에게만 일을 준다. 그렇다고 의지를 안가지는 사람을 자르거나 뭐라하거나 하지도 않는다.  그리고 결정적으로는 둘다 필요한 사람들이라고 하고 대우를 똑같이 한다.

오히려 ‘뭔 불만이 그리 많냐’, ‘너는 일 쉽게 할 수 있지 않냐?’ 이런 답변으로 더 일을 시킬려고 든다.

의지를 가지고 일을 하지 않는 자들이 같은일을 반복하는 것에 최적화된 자들이 변화하는 뭔가에 대응하고 아이디어를 내서 오래된 시스템을 바꾸는 일은 없다. 그냥 월급루팡에 최적화된 프로젝트만 남는거지..

 

systemd –user 사용하기

Systemd 는 기존 리눅스 시스템에서 사용해왔던 init script 를 대체한다. 배포판마다 적용된 버전이 다른데, CentOS에 경우에는 7 버전부터 Ubuntu 의 경우에는 16.04 부터 적용되기 시작했다.

Systemd 는 부팅과정에서 최초로 실행되는 프로세스이며 리눅스 시스템 전체를 움직하게 하는 프로세스이다. 이 프로세스는 또 다른 프로세스들을 제어하는데 이를 위해서 systemd 프로그램을 제공한다.

부팅과정에서 자동으로 데몬들을 실행시키는 것도 systemd 가 하는데 이 프로그램은 데몬에 대한 명세서인 unit 파일을 기반으로 실행을 시켜준다. 이러한 파일들은 전역 시스템 영역에 속한다.

전역 systemd 영역

전역 systemd 영역의 파일들은 다음에 디렉토리를 가진다.

  • CentOS: /usr/lib/systemd
  • Ubuntu: /lib/systemd

한가지 특징이 있는데, CentOS 경우에는 전역 systemd 디렉토리가 한가지이지만 Ubuntu 의 경우에는 /lib/systemd외에 /usr/lib/systemd 도 존재하는데 /usr/lib/systemd 는 user 영역을 위한 것이다.

커스터마이징 전역 systemd 영역

앞서 살펴본 디렉토리는 배포판의 패키지를 설치할 경우에 사용되어진다. 하지만 이것외에 별도에 설치한 데몬 프로그램을 전역 systemd 에 등록하고 싶다면 다음의 디렉토리를 사용한다.

  • /etc/systemd

예를들어 컴파일 설치한 프로그램, 자바 프로그램의 경우에 systemd 에 등록해서 사용하자 한다면 위 디렉토리에 unit 파일을 작성하면 된다.

사용자 systemd 영역

systemd 는 자동으로 데몬으로 실행시켜 준다. 그런데, 이러한 실행은 systemd 라는 전역적인 권한을 가진 상태에서 이루어진다. 그렇다면 사용자가 자신만의 systemd 를 운영할 수 없지않을까 하는 아이디어로 나온것이 사용자 systemd 영역이다.

동작방법은 두가지로 나뉜다.

  • 사용자가 시스템에 로그인을 할때 실행
  • 시스템이 부팅할때에 사용자 systemd 영역도 함께 실행

그리고 사용자 systemd 영역은 사용자 홈디렉토리에 unit 파일을 작성해야 한다. 이 디렉토리는 다음의 위치에 존재한다.

  • ~/.config/systemd/user

사용자 systemd 영역 실행은 다음의 명령어를 사용한다.

  • systemctl –user

사용자 systemd 영역 동작 방법

잠깐 어떻게 이게 가능한지를 설명해 본다. 이 기본적인 동작을 위해서는 PAM 이 실행되어야 하는데 /etc/pam.d/systemd-user 파일이 이 일을 하게 해준다. 이 파일은 대략 다음과 같다.

이 PAM 모듈은 사용자가 로그인을 하게 되면 자동으로 systemd –user 명령을 실행해준다. 그리고 로그아웃을 하게되면 systemd –user 로 실행된 프로세스는 종료된다.

기본 설정

모든 사용자 systemd 영역 파일들은 ~/.config/systemd/user 에 존재하게 된다. 처음 로그인을 할때에 서비스가 실행되길 원한다면 다음과 같이 서비스를 활성화 할 수 있다.

한가지 팁(Tip) 으로, 만일 root 사용자라면 모든 시스템 사용자의 사용자 systemd 영역 서비스를 다음과 같이 할 수 있다.

환경 변수

서비스 데몬들이 실행될때에도 환경 변수들이 필요하다. 예를들어, PATH 같은 것이 대표적이다. 문제는 사용자 systemd 영역 서비스 데몬들은 .bashrc 파일에 정의된 환경변수들을 계승하지 않는다.  이것은 environment.d 디렉토리에 정의하는데 위치는 ~/.config/environment.d/ 이며 여기에 .conf 확장자를 가지는 파일을 작성하는데 INI 형식인 NAME=VAL 식으로 작성한다.

전역적인 환경변수 파일은 다음에 위치한다. 이 파일들은 모든 사용자 unit 파일에 영향을 준다.

  • /etc/environment.d/*.conf
  • /usr/lib/environment.d/*.conf
  • /etc/environment

모든 사용자 unit 에 영향을 주는 기본 환경변수인 DefaultEnvironment 는 /etc/systemd/user.conf 도 있다.

기존의 환경 변수들을 추가할 수도 있다. 예를들어, PATH 라는 환경변수는 사용자마다 가장 많이 커스터마이징되는 변수다. 이러한 변수를 systemd 에서 환경변수로 등록하고자 한다면 다음과 같이 해준다.

사용자 systemd 영역에 설정된 변수들을 보고 싶다면 다음과 같이 하면 된다.

사용자 systemd 자동 실행

systemctl –user 사용은 사용자가 로그인을 해야만 실행이되며 사용자 세션이 닫히면, 사용자가 로그아웃을 하면 자동으로 종료 된다. 하지만 사용자의 로그인/로그아웃에 상관없이 서버가 부팅되면 자동으로 실행되고 서버가 종료되어야만 중지되게 하고 싶다면 어떻게 할가?

이것은 로그인 관련된 내용으로 링거링(Lingering) 설정에 영향을 받는다.

ElasticSearch 에 대한 systemd unit 파일 예제.

이제 간단하게 예제하나를 작성해 보자.

전문 검색 엔진인 ElasticSearch 는 자바를 기반으로 작동한다. 그러다보니 반드시 root 로 실행할 필요가 없다. 실제로 대부분 자바기반의 서비스들은 일반 계정으로 실행하는게 대부분이다.

unit 파일에 대해서 먼저 알아둘 필요가 있다. 이 파일들은 대체로 다음에 위치한다.

  • /usr/lib/systemd/systemd: 설치된 패키지에 의해서 제공된 units
  • /etc/systemd/systemd: 시스템 관리자에 의해서 제공된 units

하지만 사용자 systemd 영역을 사용할 것임으로 앞에서 언급한 대로 사용자 홈디렉토리에 관련 디렉토리를 생성해 준다.

자바 프로그램은 자바를 필요로하는데, 설치가 되어 있다고 하더라도 PATH, JAVA_HOME 등의 환경변수를 설정해 줘야 한다. systemd 가 알아차릴 환경변수는 environment.d 에서 작성해야 함으로 java.conf 파일을 다음과 같이 작성해 준다.

이제 elasticsearch.service 를 다음과 같이 작성한다. 이 파일은 ElasticSearch 의 소스가 공개된 GitHub 에서 찾을 수 있다.

Ubuntu 1.604 에서 문제

한가지 문제가 있다. elasticsearch.service 파일을 보면 중간에 리소스를 조정해주는 내용이 나온다.

  • LimitNOFILE=65536
  • LimitNPROC=4096

그런데, 이 설정은 적용되지 않는다. Systemd 에서 시스템 자원 조정을 위한 파일들이 여럿 존재한다.

  1. /etc/systemd/system.conf
  2. /etc/systemd/system/user@1000.service.d/limit.conf – 1000 은 userid 값이다.
  3. .config/systemd/user/elasticsearch.service.d/limits.conf

여기서 3번째는 작동되지 않는다. 1번의 경우에는 전역적으로 모든 사용자에게 적용이 된다.    2번째 경우에는 사용자에게만 적용이 된다.

보통 시스템 리소스는 /etc/security/limits.conf 파일에서 조정하는게 보편적이지만 systemd 는 이처럼 자체적으로 리소스를 제어할 수 있도록 해준다.

systemctl –user 사용법

이제 elasticsearch.service 를 활성화하고 사용법을 익혀보자.

먼저 elasticsearch.service 를 다음과 같이 활성화 해준다.

그리고 서비스 시작/중지는 사용자 계정으로 로그인을 하면 자동으로 시작되며 로그아웃을 하면 중지된다. 하지만 수동으로 시작,중지를 하고 싶다면 다음과 같이 하면 된다.

 

ElasticSearch 시스템 설정

ElasticSearch 를 실행하기 위해서는 기본적으로 리눅스 시스템의 설정을 변경해줄 필요가 있다. 이는 ElasticSearch 문서에도 아주 잘 나와 있다.

Max Open File

리눅스 시스템은 사용자별로 최대 파일 오픈 개수를 제한 하고 있다. 이를 늘려주기 위해서는 /etc/security/limits.conf 파일에서 늘려줄 수 있다.

맨 앞에 문자열은 시스템 계정이며 맨 뒤에 숫자는 오픈가능한 최대치 값이다. ElasticSearch 에서는 65536 값을 권장하고 있다.

파일에 저장하고 계정을 재로그인하면 바로 적용된다.

Memlock 해제.

Memory Lock 에 대해서 무제한으로 해제를 해줘야 한다.

이것 역시 /etc/security/limits.conf 파일에 다음과 같이 설정하면 된다.

Virtual Memory

ElasticSearch 를 문제 없이 운영하기 위해서는 이를 조정해 줄 필요가 있다. 이는 리눅스 커널 파라메터값으로 재부팅 없이 조정이 가능하다.

시스템이 재부팅 되면 이 값을 다시 설정해줘야 함으로 이를 /etc/sysctl.conf 파일에 저장한다.

이렇게 파일에 저장한 후에 다음과 같이 하면 적용된다.

적용하기 위해서는 root 계정이 있어야 한다.