20 개의 Ansible 인터뷰 질문

이 글은 Arie Bregman 씨의 “20 Ansible Interview Questions” 을 번역한 것입니다.

질문1

Ansible 에서 다음 각각의 컴포넌트에 대해서 이들 사이의 관계를 포함해 설명하시오.

  • Task
  • Module
  • Play
  • Playbook
  • Role

Answer

이 질문은 당신이 Ansible 의 기본적인 컴포넌트에 익숙한지 않한지, 그들이 어떻게 상호작동 하는지를 체크한다. 나는 이것이 우리가 Ansible 로 하고자하는 모든 것에 기본인만큼 매우 중요한 것임을 알았다.

  • Task – 특정 Ansible 모듈(Module) 호출하기
  • Module – 여러분의 호스트나 원격 호스트에서 Ansible 에 의해서 실제 실행되어지는 코드의 묶음. 모듈들은 카테고리로(database, file, network, …) 인덱스되고 task 플러그인처럼 첨조된다.
  • Play – 주어진 호스트에 실행되어질 하나 혹은 그 이상의 Task 들.
  • Playbook – 하나 혹은 그 이상의 Play들. 각각의 Play 들은 같은 호스트 혹은 다른 호스트들에서 실행되어질 수 있다.
  • Role – Ansible Role 은 어떤 기능이나 서비스를 기반으로 자원들을 그룹화 해 쉽게 재사용할 수 있도록 해준다. Role 에서 variables, defaults, files, templates, handlers, tasks 그리고 metadata 를 위한 디렉토리를 가진다. 그리고 Role 을 Playbook 에 지정해서 사용할 수 있다.

더 자세한 Ansible core components 사항은 여기서 확인할 수 있다.

질문2

‘/tmp/new_directory’ 디렉토리를 생성하는 task 를 작성하라.

Answer

매우 기본적인 질문지만 당신이 Ansible 을 어떻게 활용하는지를 알수있게 해준다. 많은 사람들이 Shell 이나 Command 모듈을 사용하는 것으로 이 질문에 답합니다. 이것이 꼭 나쁜것은 아니지만, 제일 좋은 사례는 항상 명시적인 Ansible 모듈을 사용하는 것 입니다. (이 경우에, file 모듈을 사용하는 것이다.)

왜 그런가? 주요한 이유는 가독성(readability) 때문이다. 어떤 액션들은 서로 다른 운영체제에 따라 다르게 실행되지만, Module 은 언제나 같은 것을 사용하고(운영체제에 관계 없이) 어떤 Ansible 사용자라고 할지라도 Task 를 읽다보면 그것이 무엇을 뜻하는지를 알게된다. (특히 긴 쉘 명령어일 경우)

주의: 이것은 Module 이 ‘shell’ 이나 ‘command’ 로 지정한 명령어보다 반드시 좀 더 빠르다는 것을 의미하지 않는다.

디렉토리 생성 Task 는 다음과 같다. 

질문3

다음 Play 결과는 무엇인가?

Answer

작성된 코드가 주어지면 항상 철저히 검토하세요. 만약 여러분의 대답이 “이것은 실폐할 것이다” 라면 맞습니다. 이 코드는 실행한 호스트로부터 수집된 정보의 일부인 ansible_hostname 이라는 Fact를 사용하고 있다. 하지만 이 경우에, Fact 수집을 비활성화(gather_facts: no) 했기 때문에 ansible_hostname 변수는 정의되지 않을 것이며 따라서 결과는 실폐하게 된다.

이 질문의 목적은 Fact 가 무엇인지를 체크하기 위한 것이지만 여러분이 아주 세세한 부분까지 신경을 쓰고 있는지를 체크하는 것이기도 하다.

유사하게 다음과 같은 질문이 있을 수 있다.

  • 활용가능한 모든 Fact 를 나열하는 방법은?
  • 당신만의 Fact 를 지정하는 방법은?

질문4

시스템에 ‘/tmp/mario’ 파일이 존재한다면 모든 시스템에 ‘vim’, ‘zlib’ 설치를 위한 Playbook 을 작성해라.

Answer

이 질문에 답하기 위해서 여러분은 register, conditionals 그리고 loops 에 익숙해져 있어야 한다.

첫번째 Task 는 ‘stat’ 모듈을 사용해서 각 시스템에 파일이 존재하는 체크한 결과를 ‘register’ 를 사용해서 ‘mario_f’ 변수에 담아두는 것이다. 이렇게 하면 등록한 변수를 어떤 다른 Task 에서도 사용할 수 있다. 이 경우에, 우리는 ‘/tmp/mario’ 파일의 상태를 담았고 다음 Task 에서 만약 파일이 존재한다면 패키지들을 설치하게 된다.

여러분이 본것처럼, 패키지들을 설치하기 위해서 우리는 리스트(list)를 반복할 수 있게해주는 “with_items” 루프를 사용했고 리스트에 아이템마다 module/task 를 실행했다. loop는, 다른 프로그래밍 언어처럼, Ansible 의 기본적인 사항이고 여러분은 Ansible 이 지원하는 다른 타입의 loop 을 알고 있어야 한다.

다른 주목해야할 라인은 ‘become: yes’ 인데, 이것은 Task 를 root 처럼 실행하게 해주기도 하지만 다른 사용자로 실행되도록 사용자를 지정해줄 수 있다(e.g. become: ‘toad’). 패키지 설치는 시스템의 sudo 권한만으로 수행할 수 있기 때문에 이 라인이(become: yes) 이 포함되어 있지 않으면 패키지 리스트 설치 Task 는 실패할 것이다.

다른 주목해야할 라인은 ‘become: yes’ 인데, 이것은 Task 를 root 처럼 실행하게 해주기도 하지만 다른 사용자로 실행되도록 사용자를 지정해줄 수 있다(e.g. become: ‘toad’). 패키지 설치는 시스템의 sudo 권한만으로 수행할 수 있기 때문에 이 라인이(become: yes) 이 포함되어 있지 않으면 패키지 리스트 설치 Task 는 실패할 것이다.

*Bonus: 어떤 Ansible 모듈들은 인자로(argument) 리스트를 받을 수 있다. 이 질문에서, loop 처리는 ‘package’ 모듈에 package_list 변수를 직접 제공함으로써 완벽하게 제거할 수 있었다. 또, 우리는 Ansible 에 정규표현식으로 파일 리스트를 반복하는 ‘with_fileglob’ loop 를 사용함으로써 “stat” 모듈을 완벽하게 제거할 수 있다. 이를 종합하면 다음과 같다.

질문5

controller 그룹을 제외한 모든 서버에 다음의 내용을 가진 ‘/tmp/system_info’ 파일을 배포하는 Playbook 을 작성하라.

<HOSTNAME>과 <OS>는 실행되는 호스트의 실제 데이터로 바뀌어야 한다.

Answer

system_info 파일을 배포하는 Playbook 은 다음과 같다.

system_info.j2 템플릿 내용은 다음과 같다.

Template 사용은 여러분의 Playbook 이나 Role 들을 좀 더 다이나믹하게 해주고 다른 시나리오와 쉽게 적용할 수 있게 해준다. Ansible 은 파일의 동적 템플릿 구성을 위해서 ‘Jinja2(진자2)’ 불리는 강력한 템플릿 엔진을 사용한다. 많은 인기있는 프로젝트와 회사들이 이것을 사용중이고 우리는 시간을 갖지고 미래에 여러분이 그것을 잘 사용할 수 있도록 사용법을 익히는것을 강력히 추천 합니다.

Ansible 을 위한 Jinja 템플릿을 작성할때에 템플릿 최상단에 ‘ansible_managed’ 변수를 추가하는 것이 가장 좋은 사례 입니다. 이 변수는 Ansible 로 생성되거나 관리되는 출력파일을 누구나 읽을수 있는 문자열로 확장 됩니다. 그 다음, 우리는 호스트 이름을 위해서 ansible_hostname 을, OS 배포판을 위해서 ansible_distribution 을 사용했다.

이 질문은 다른 방법으로 구현 될 수 있다는 점에 유의해라. 예를들어, ansible_hostname 을 사용하는 대신 어떤분은 inventory_hostname 을 사용할 것이다. 그들은 같지 않지만, 이 경우에는 둘다 괜찮다.

질문6

어떻게 여러분의 Ansible 기반 프로젝트를 테스트 하는가?

Answer

몇몇 인터뷰때 이 질문을 했었는데, 아주 많은 다른 대답을 받았다. 그 답변들 중 몇가지 이다.

  • Manual run: “나는 그냥 그것을 실행시키고 시스템이 원하는 상태에 있는지를 체크한다” – 개인적으로 나는 이런 대답만 하는것을 싫어한다. 나는 이것이 가장 쉬운방법임에 동의하지만 잠재적으로 아주 위험하다. 비록 개발환경에서 새로 작성한 Role 을 테스트한다 할지라도, 이것이 프로덕트 환경에서 같은 결과를 얻는다는 것을 의미하지 않는다.
  • Check mode – yes, check mode 는 실제로 check mode 없이 실행할 경우 무슨일을 했는지 결과를 알려주므로 Ansible 코드를 테스트하기에 좋은 방법이다. 그래서 여러분은 Ansible이 실행되면 여러분이 기대한 행동이 나오는지를 쉽게 볼 수 있다. 하지만 여기서 “그리고 스크립트 어떤가?” 라는 질문이 있다. 보통, 나는 대답으로 “그게 뭔데?” 라는 소리를 들는데, 만일 롤(Roles)과 플레이북(Playbook) 에 스크립트를 사용하지 않는다면 괜찮겠지만, Check Mode 는 스크립나 명령어를 실행할 수 없다는 것을 알아야 한다. 그것을 실행하기 위해서는, “check_mode: no”를 사용하여 특정 Task에 대한 Check Mode 를 비활성화해야 한다.
  • Asserts – 나는 Python처럼 다른 언어를 테스트하는 방법과 비슷한 테스팅 메소드로 Assert 를 좋아하는데 중요한 것은 여러분의 시스템이 Check mode 와 같은 초안이 아닌 Task가 특정 자원을 원하는 상태로 변경했다는 실제 검증처럼 원하는 상태에 도달했는지 확인해준다.

요약하면, 단순하게 여러분이 선택을 설명해야할때 자신감을 가져라.(또, 누군가 이것들을 모두 사용하도록 기대하는 것은 현실적이지 않기 때문에 이 모두를 사용하지 마세요.

질문7

데이터베이스 그룹에(RedHat 으로 가정하고) 모든 서버에 PostgreSQL 설치하고 postgresql.conf.j2 템플릿으로 postgresql.conf 설정을 업데이트하는 Playbook 을 작성하시오.

추가로, 설정 업데이트 task만 실행하기 위해나 방법을 제시하라.(패키지 설치하지 않고..)

Answer

여기에는 놓치지 말아야할 두가지가 있다: handlers 와 tags. 여러분의 Playbook 은 다음과 비슷할 것이다.

보시는 봐와같이, 하나의 파일에 모든 것을 담았지만 더 좋은 해결법은 Roles 를 생성하게 하고 각 섹션들을 그들만의 디렉토리에(vars, handlers, tasks,…) 넣는 것이다. 나중에 Roles에 대한 상세한 질문과 답변을 하겠다.

첫째로 봐야할 것이 ‘Handler’다. Handler는 변화에 따른(보통 task) 트리거 액션을 수행한다. 위에서 본것처럼, 문법은 확실히 단순하다, ‘notify’ 키워드를 사용함으로서 실행을 위한 액션 리스트를 제공할 수 있다. 이것은 설치를 위해 필요한 메인 Task와 PostgreSQL 설정이 무엇인지, Task를 완료하는데 필요한 작은 “sub” 액션이 무엇인지를 명확하게 구분하게 해준다.

두번째로 봐야할 것은 ‘tags’다. 이것은 어떻게 설정 업데이트 부분만 실행하도록 하는지에 대한 질문의 두번째 부분에대한 답변이다. 여러분이 100 task를 가지고 있고 그들중에 아주 오직 작은부분만 실행되길 원있다고 가정하고 애플리케이션 업데이트를 담당하는 네가지 Task 를 가정해보자. tags 가 없다면, 여러분의 playbook 에서 모든것을 실행해야만하지만 tags를 사용하면 특정 tag 로 표시한 tag만 실행할 수 있다.

질문8

다른 값을 가진 여러 장소에서 같은 변수이름을(whoami) 사용한다고 생각해보자.

  • role defaults -> whom:mario
  • extra vars(-e 를 통해서 Ansible CLI 로 전달되는 변수들) -> whom:toad
  • host facts -> whoami:luigi
  • inventory variables(타입과 상관없다) -> whoami:browser

최종적으로 어느것을 사용해야 합니까? 왜?

Answer

정답은 ‘toad’ 다.

Variable precedence 는 변수들이 다른 위치에 있을때에 어떻게 변수들이 서로 오버라이드(override) 하는지에 대한 것이다. 만약 아직 여러분이 그것을 다루어보지 못했다면 어느시점에서 그것을 다룰것인데, 그것을 깨닫기에 유용한 주제다.

질문의 문맥에서, 순서는 extra vars(매번 모든 다른 변수를 오버라이드한다) -> host facts -> inventory variables -> role defaults (제일 약하다)

전체 목록은 위 링크에서 찾을 수 있다. 한가지 주의해야 할것은 Ansible 1.x 와 Ansible 2.x 는 아주 다르다.

질문9

여러분에게 Ansible 모범 사례로 친숙한 것 (적어도) 3가지는?

Answer

  • 여러 파라메터를 사용할때에 YAML dictionary 포맷을 사용하는 것이 더 낫다. 나는 개인적으로 좀 더 읽기 편하다.
  • “항상 태스크 이름을 사용하라”. 여러분이 ‘debug’ 모듈을 사용하는 것처럼 아주 단순한 것일지라도 매번 태스크를 추가할때마다 name 을 사용하는 것으로 얻을 수 있는 이득이 있다. task의 name은 왜 추가되었고 그것이 무엇을 하는지와 같은 어떤 정보를 제공한다. 알려진 버그를 해결할 수 있는 벙법일 수도 있고 길고 지루한 명령일 수도 있으므로 사용자가 playbook을 읽거나 사용할때에 간단하게 무엇을 하는지를 기술한다면 고마워할 것이다.
  • Ansible 코드의 모든 변경은 ansible-lint 로 전달되어야 한다. 이것은 기본적으로 best-practices checker 인 또 다른 비공식 모범 사례다. This is why I consider it as one of the most important best practices to implement as it makes it easier to make sure other best practices are being followed, especially in a shared repository where you have several contributors(역, 모범 사례가 되기 위해서는 task 의 name 을 사용하는 것이 좋다. 여러 컨튜리뷰터들과 저장소를 공유할때에는 이러한 것이 모범 사례가 되게 만드는데 도움을 준다.

이미 언급한 바와같이, 언급된 모든 모범 사례가 공식적인(Ansible 문서) 것이 아니며 여러분이 그것이 왜 모범 사례인지를 설명할 수 있다면(좀 더 정확하게 좋은 연습사례) 그것으로 괜찮다.

질문10

“The inventory file is in <inventory_file_path> and the inventory groups are <inventory_groups>” 내용을 가지는 ‘/tmp/info’ 파일을 모든 호스트에 생성하는 Ansible Ad-Hoc command 를 작성하라

주의: 인벤토리 그룹에 포함된 호스트도 나열해야 한다.

Answer

Ansible 을 실행하는 다른 방법을 아는 것은 시간을 절약해 준다. 그중에 하나가 Ad-Hoc 방법인데, 원격 호스트에 빠르게 무엇이든 실행해준다.

이 경우에, ad-hoc command 는 다음과 같을 것이다.

-m은 모듈 이름을 지정하기 위한 것이다. 우리는 ‘copy’를 사용하지만, 동일한 결과를 얻기 위해서 다른 모듈을 사용할 수도 있다.

-a파일의 내용과 어디에 생성할지를 모듈에 전달하기 위한 아규먼트다.

나는 이것에 친숙해지기 위해, 실전에서 사용할때 충분히 편안함을 느낄수 있도록 ad-hoc command를 여러번 실행해 볼것을 권장한다.

질문11

ansible-pull 은 무엇인가? 어떻게 ansible-playbook 과 다른가?

Answer

우리는 ansible-playbook 을 실행하는 것이 컨트롤 노드로 알려진 호스트에서(우리가 명령을 실행하고 있는 노드) 운영중인 호스트에 어떤 설정을 강제한다는 것을 알고 있다.

ansible-pull 또한 설정을 적용하지만 컨트롤 호스트로부타가 아닌 관리 호스트로부터 실행된다. 이것은 주어진 URL 저장소로부터 설정을 pulling 한다.

이것은 여러분이 접속한 호스트에서 중앙 위치로부터 설정을 강제하는 Reversed Architecture 가 필요할때에 유용할 수 있다.

질문12

여러분은 디렉토리 목록을 가지고 있고 첫째로 발견한 디렉토리를 원격 서버로 복사하는 Task를 작성하기 원한다.

Answer

역주: Ansible 2.7 에서는 없어진듯 보인다. 공식문서에서 검색했지만 나오지 않는다.

질문13

다이나믹 인벤토리는 무엇인가?

새로운 dynamic inventory 스크립트를 작성할 때 어떤 규칙을 따르는것이 중요한가?

Answer

라인을 추가/삭제하거나 수동으로 호스트이름 목록을 업데이트하는 default 혹은 static 인벤토리와 다르게, dynamic inventory 는 클라우드(Cloud)나 LDAP 과 같은 외부 소스로부터 정보를 추출함으로써 생성어된다. 대부분의 이러한 dynamic 저장소 스크립트는 contrib/inventory 디렉토리에서 찾을 수 있다.

새로운 동적 인벤토리를 개발할 때 ‘-list’인수를 사용하여 호출하면 해당 스크립트의 중요한 결과가 JSON 형식에 그룹을 출력한다. 다음과 같이 group:managed_hosts 처럼 할 수 있다.

혹은 다음과 같이 group:dict_of_variables 처럼 할 수 있다.

물론, 두개를 혼합할 수 있다.

dynamic inventory 에 대한 더 많은 정보는 여기서 찾을 수 있다.

질문14

파일의 전체 또는 상대 경로가(-e 와 함께 변수를 전달 함) 주어지면 다음을 수행하십시오.

  1. 현재 작업 디렉토리나 주어진 위치에서 찾아라.
  2. 만일 파일을 찾을 수 있다면, 리모트 호스트 사용자 홈 디렉토리에 그것을 복사하라. 만일 파일을 찾지 못할 경우, run/execution 은 실패로 처리하라.

Answer

질문15

Apache 설치를 위한 롤을 작성하라.

Answer

나는 이 질문이 인터뷰에서 아주 인기 있는 질문이라고 생각한다. 왜냐하면 ‘role’은 Ansible의 핵심 컴포넌트이며 이것은 앞에 질문에서 논의했던 tasks, templates 그리고 variables 와같은 많은 컴포넌트들을 사용하도록 만들기 때문이다.

이 질문에 대한 하나 이상의 답이 있다는 점에 주의해야 한다. 나는 짧지만 포괄적인 답을 제공할 것이다. role 에서 모든 디렉토리를 사용하는 자세한 대답은 아마도 추가 점수를 줄 것이다.

구조부터 시작하자.

이것은 매우 표준적인 구조지만 여러분은 각 디렉토리가 왜, 무엇을 위해 사용되고 이 케이스에서 Apache 설치를 어떻게 구현하는지 익숙해질 필요가 있다.

이것은 매우 표준적인 구조지만 여러분은 각 디렉토리가 왜, 무엇을 위해 사용되고 이 케이스에서 Apache 설치를 어떻게 구현하는지 익숙해질 필요가 있다.

vars 를 시작해보자. vars 는 우리가 role 에서 사용할 모든 변수를 가진다. 무엇이 변수일 수 있나? 만약 우리가 서로다른 운영체제에 이 role 을 사용할것이라면, apache2의 서비스 이름은 변수일 수 있다. Fedora에서, 서비스 이름은 httpd 일 것이지만 Debian 에서는 apache2 로 부른다. 또 다른 변수로 각 운영체제에 패키지를 설치해기 위해 정의한 apache2_packages 일 수도 있다. 어떻게 이것을 구현하는지 보자.

RedHat.yml 살펴보자.

Debian.yml 살펴보자.

이제 Handler 로 가보자. Handler 는 어떤 변화(Change)에 따라 트리거되는 액션이다. 이 경우, 아주 흔한 handler 로 ‘restart service’ 일 수 있다.

이 handler 는 설정에 변경이 있은 후에 apache2 시작을 위해서 사용되어질 수 있다. {{ apache2_service }} 는 RedHat.yml 과 Debian.yml 에 정의되어 있음을 기억해라.

다음으로, 우리는 defaults/main.yml 에서 기본 변수들을 정의할 것이다.

만약 defaults 와 vars 차이에 의문이 든다면 여러분은 default를 모든 타입의 운영체제나 시나리오에 사용하기 위한 공통변수로 생각해야 한다. 반면에, vars 는 특별한 환경/케이스에 사용하기 위해 수정된 변수들이다. 이 경우 운영체제 타입이다.

meta folder 는 role 에서 별도의 행동을 정의하기 위한 장소처럼 행동한다. 일반적으로 대부분 role 의존성을 정의하는데 사용한다. 이것은 role 이 다른 role 에 의존성이 있는 경우인데, 예를들어 자바(Java) 기반 애플리케이션 설치하는데 설치된 자바가 필요한 것이다. 이 예제를 만들어보면 우리는 두개의 role 을 가질것이다.

  1. Java 설치 role
  2. Elasticsearch 설치 role

우리의 play 는 다음과 같을 것이다.

하지만 우리는 다른 사람과 role들을 공유하는 걸 좋아하기 때문에, ElasticSearch role을 사용하고자하는 유저는 ‘Java’ 라는 다른 role 을 의존성을 모를 수 있다. 따라서 meta folder에 다음과 같이 라인을 추가해줘야 한다.

이것은 ‘elasticsearch’ role 을 불러오기 전에 ‘java’ role 을 시도하고 실행할 것이다. 이것은 이전의 play 를 재작성하도록 해준다.

최종적으로, 우리는 몇개의 task들을 정의할 것이다. role의 핵심은, 무엇을 실행시킬 것인지를 정의하는 부분이다. 우리는 목적에 기반한 추가적인 task 를 포함하는 단순한 메인 파일을 가질 것이고 OS 타입에 따라서 그것이 동작할 것이다. 올바른 패키지를 설치하기 위해서, 우리는 각 OS에마다 사용할 이전에 정의했던 변수들을 포함할 것이다.

이제, install-RedHat.yml을 살펴보자.

최종적으로, 이것이 앞에 모든 파일들을 생성한 이후 구조다.

기억해라, 이것은 완전한 해결책이 아니며 당신이 더 장황하고 상세한 답변을 줄수록, 당신은 더 많은 신뢰를 얻을 것이다.예를들어, 설정을 위해 템플릿을 가지는 템플릿 디렉토리을 추가하거나 Apache 설정 Task 추가등이다.

질문16

여러분은 다음의 play 를 가진다.

그리고 여러분은 다음의 command 를 실행한다.

test 변수의 출력값은 무엇인가?

  • test 1 2 3
  • test
  • empty string
  • the variable is not defined

Answer

대답은 ‘test’다.

이것은 속임수이고 여러분이 shell 과 Ansible을 이해하고 있는지를 체크한다. 이 경우에, command는 shell에 의해서 우선 처리 때문에, 인용문의 내용과 백슬래쉬와 빈공백 이후의 모든것은 무시된다.

면접관으로서, 여러분은 대부분의 면접자들이 이것에 올바른 대답을 못것인지 아니면 단순한 추측은 아닌지 알아야 하며 이것이 Ansible에 익숙한지 아닌지를 나타내는 지표는 아니다.

해결책은 전체적으로 ‘-e’ 이후에 내용을 인용하는 것이다.

질문17

오직 task 이름들만 표시하도록 Ansible 실행의 출력 포맷을 어떻게 변경할 것인가?

Answer

해답은 “callback plugin” 이다. 여러분이 알고 있는 것만 바꿀것만 아니라 Ansible 에서 다른 이벤트를 기반으로 여러분이 원하는 모든것을 할 수 있다. 그래서 유사한 질문이 있을 수 있다: “어떻게 파일에 모든 것을 기록할 수 있나?” 그리고 대답은 여전히 callback plugin 일 수 있다.

여기에는 여러분이 callback plugins 에 대해서 알아야할 몇가지 포인트가 있다.

    • Ansible 트리에 몇가지 callback plugins 가 있다.
    • callback plugin을 활성화하기 위해서, ansible.cfg 에 다음과 같은 것을 포함해야 한다.
    • Ansible 실행에 기본 표준 출력을 바꾸기 위해서는, ansible.cfg 를 다음과 같이 바꿔라.
  • 새로운 callback plugin 을 개발할때, 부모 클래스 “CallbackBase” 로부터 상속이 필요하며 다음의 메소드를 오버라이드(override) 해야 한다.
    • v2_runner_on_skipped
    • v2_runner_on_unreachable
    • v2_runner_on_ok
    • v2_runner_on_failed

Callback plugin 은 여러분의 Ansible 실행을 커스터마이징을 위한 좋은 방법이고 여러분이 Ansible 아웃풋(Output)을 소비하는 방법이다.

질문18

다음의 컨텐츠를 포함하는 파일 ‘/tmp/excercise’ 가 있다.

하나의 Task 를 가지고, 다음과 같이 컨텐츠를 바꿔라.

Answer

새로운 컨셉이 아닌, 두개의 아이템을 매번 반복하는 곳에서 약간의 loop 문을 응용한 것이다. (regexp 과 line)

주목할 것은 이 문제를 ‘blockinfile’ 로 해결할 수도 있다.

질문19

문자열을 대문자로 바꾸는 필터를 작성해라.

Answer

우리는 매우 단순한 필터(filter)를 작성했다. 필터를 작성하는 Ansbile 을 마스터할때 자신의 것으로 하고 싶은 좋은 스킬인데, 거기에는 몇가지 이유가 있다.

첫째로, 믿던 안 믿던, 필터는 몇몇 게이스에서 여러분의 playbook 들을 좀 더 읽기편하게 해준다. 특히, 여러분이 아주 긴 명령어를 사용할때 사용자는 무엇을 왜 작성했는지 이해하는데 몇분이 소요된다. ‘hostname_to_ip’ 는 이해하기 아주 쉽다. right?

게다가, Ansible 의 모든 것을 맹목적으로 사용하지 마라. 이런것이 2차면접에서 의미있는 것은 아니다. 다른 사람이 이해하기 쉽고 성능에 영향을 미치지 않지만 어떤 경우에도 이를 고수하지 않을 경우 가능하면 Ansible 을 사용해라.

질문20

마지막 질문은 질문 요약이다. 10개의 지문이 있고 그것이 true 나 false 인지를 정해라.

    1. Module은 Task 의 집합이다.
    2. 특정한 Module 대신에 shell 이나 command 를 사용하는게 낫다.
    3. Host 팻츠(facts)는 play 변수들을 무시한다.
    4. Role 은 vars, meta 그리고 handler 를 포함할 수도 있다.
    5. 다이나믹 인벤토리는 외부 소스로부터 정보룰 추출함으로써 생성된다.
    6. 4칸 보다 2칸의 들여쓰기를 사용하는 것이 좋은 모범 사례다.
    7. 다음의 Task 는 성공적으로 실행될 것이다.
  1. ‘notify’ 는 Handler 를 트리거(Trigger)하는데 사용 된다.
  2. “hosts:all:!controllers” 는 ‘hosts 그룹에 controller 만 실행하라’ 라는 것이다.
  3. 기본 Role 은 role 변수를 무시한다.

Answer

  1. False play 는 Task들의 집합이다. Task 는 특정 모듈(Module)을 실행하는 것이다.
  2. False Shell 이나 Command 를 사용하는 것 좀 더 빠를 수 있지만, 일반적으로 Ansible 사용자를 위해서 더 쉽게 읽을수 있도록 언제나 특정 모듈을 사용하는 것이 좋습니다.
  3. False Play 변수들은 host 팻츠(Facts) 를 무시한다.
  4. True
  5. True OpenStack 과 같은 클라우드나 LDAP 일 수도 있다.
  6. False 이것은 정말 말이 안된다.
  7. Depends playbook 이나 role dl ‘become: yes’ 를 가지고 있다면, 이것은 성공적으로 실행되겠지만 그렇지 않다면 퍼미션때문에 실패할 것이다.
  8. True
  9. False Controller 들을 제외한 모든 hosts 를 대상으로 실행하라는 뜻이다.
  10. False Role 변수들은 role 기본값을 무시한다.

Practice is everything

여러분이 대부분의 질문에 올바르게 대답할 수 있었다면,이것은 Ansible 컨셉과 사용에 여러분이 익숙해 있다는 것을 확실하게 말해준다. 하지만 기억해야한다. 인터뷰 질문에 답하는것만이 아닌 연습만이 최고다.

더 많은 인터뷰 질문들

더 많은 인터뷰 질문이나 Ansible 을 배울때 검토할 주제의 체크리스트는 Github 저장소를 방문해라.

[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 를 다음과 같이 활성화 해준다.

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