Ansible 검색 결과

8개 발견
  1. 미리보기
    2018.11.09 - mr.november11

    [Ansible] Ansible을 활용하여 Linux 로그 주기 설정인 logrotate 설정 변경

  2. 미리보기
    2018.08.31 - mr.november11

    [Ansible] 7. Ansible Playbook을 활용한 Zabbix Agent 자동 설치

  3. 미리보기
    2018.08.25 - mr.november11

    [Ansible] 6 . Ansible Playbook에서 Command line을 통해 입력 받은 변수 사용 방법

  4. 미리보기
    2018.08.22 - mr.november11

    [Ansible] 5 . Ansible 의 멱등성 이해 및 Cron 모듈 예제

  5. 미리보기
    2018.08.22 - mr.november11

    [Ansible] 4 . Ansible Playbook 에서 hosts 인벤토리 파일 지정

  6. 미리보기
    2018.08.22 - mr.november11

    [Ansible] 3 . Ansible Playbook 에서 gather_facts 설정 해제

  7. 미리보기
    2018.08.22 - mr.november11

    [Ansible] 2 . Ansible Playbook 활용 및 예제

  8. 미리보기
    2018.08.11 - mr.november11

    [Ansible] 1. Ansible 개요 및 설치 방법

[Ansible] Ansible을 활용하여 Linux 로그 주기 설정인 logrotate 설정 변경

Logrotate 란

  • Lorotate 는 Linux 서버 내 로그를 관리하는 데몬이다.

  • cron 을 통해 동작하며 logrotate 설정을 활영하여 정해진 시간마다 로그를 백업하거나 삭제한다.

  • logrotate 를 활용하여 로그의 백업 주기(daily, weekly, monthly, yealry) 를 지정할 수 있다.

  • Default 설정인 rotate 4는 최대 로그 파일 개수를 4개로 제한하는 설정이다.

    weekly 설정일 경우 4주를 보관한다는 의미이다.

Logrotate 관련 ansible playbook

  • playbook의 목적은 /etc/logrotate.conf 파일 내 rotate 설정값을 변경하여 주단위로 저장되는 로그의 개수를 최대 24개로 제한한다. 이 경우 해당 서버의 로그는 최대 24주까지 저장된다.

---
- name: Change logrotate
hosts: server
gather_facts: no
become: yes
become_method: sudo
become_user: root
serial: 1
tasks:
  - name: Change log rotate
    lineinfile:
      path: /etc/logrotate.conf
      regexp: '^rotate'
      line: 'rotate 24'
       
       


다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible]7. Ansible Playbook을 활용한 Zabbix Agent 자동 설치

Ansible Playbook을 활용하여 Zabbix Agent 3.4.9 버전을 자동 설치

1. 자동화 관련 Flow

  1. Zabbix Agent 3.4.9 RPM을 원격지로 파일 전송

  2. Zabbix Agent 설치

  3. Zabbix Agent 관련 Config 파일 설정

    zabbix-agentd.conf.j2 파일의 템플릿을 활용하며

    기본적인 Log 옵션 및 Server/Agent 의 정보 입력을 자동화 했다.

  4. Zabbix Agent 서비스 Start

Ansible Server 실행 디렉토리 내에 rpm 파일이 있어야 함

 

2. 관련 Command 및 실행 결과

1) 실행 Command

2) 명령어 매개변수

zabbix_server_ipaddrzabbix server 의 IP Address, 지정 시 zabbix-agentd.conf.j2 내 입력 된다.
target설치 대상, hosts inventory 파일 내 있는 대상이어야 한다.
target_userid원격지 접속 시 사용할 계정, su 를 통해 root 권한 획득이 가능한 계정이어야 한다.

3) 실행 결과

 

 

3. 관련 파일

1) zabbix-agent.yml

2) hosts

 

3) zabbix-agentd.conf.j2

 

 

 

 

 

다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible] 6 . Ansible Playbook에서 Command line을 통해 입력 받은 변수 사용 방법

Ansible의 playbook은 작성 시 일반 프로그래밍 언어와 같은 변수(var)입력 기능을 지원한다.

변수는 대상 서버의 Facts 정보 또는 사용자가 입력한 값을 지정하여 활용할 수 있다.

여기서는 간단하게 Playbook 내 대상 host를 Adhoc 커맨드와 같이 특정 서버를 지정하여 실행하는 용도로 변수 기능을 활용할 예정이다.

[ansible-playbook man page] -e, --extra-vars set additional variables as key=value or YAML/JSON, if filename prepend with @

외부 변수 입력은 -e 옵션을 통해 지정 가능하다.

Playbook 내 아래와 같이 {{ input_host }} 변수 값을 지정한다.

명령어 실행 시 "ansible-playbook var.yml -k -i hosts -e "input_host=server2" 로 실행하면,

Playbook 파일 내 hosts 값 변경 없이 아래와 같이 server2에만 Playbook을 실행할 수 있다.

대상 서버를 변경하고 싶다면 Command Line에서 input_host 의 값을 "input_host=server4" 로 변경 후 실행하면 된다.


다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible] 5 . Ansible 의 멱등성 이해 및 Cron 모듈 예제

Ansible의 멱등성 개요

Ansible의 기존 shell script 자동화 방식 대비 가장 큰 장점은 멱등성(idempotence)를 기본 개념으로 제공하는 것이라 생각한다.

멱등성(冪等性, 영어: idempotence) : 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

https://ko.wikipedia.org/wiki/%EB%A9%B1%EB%93%B1%EB%B2%95%EC%B9%99

자동화 솔루션 도입 시 가장 걱정되는 것은 버그나 예외상황에 의한 오동작으로 장애나 설정 오류가 발생하는 것이다.

Shell script를 직접 작성 시에는 모든 작업에 대해 if 문을 통한 상태 체크가 필요하거나 장애 케이스별 영향도 파악을 사전에 모두 완료해야한다.

하지만 ansible 에서 제공하는 모듈 대부분은 멱등성을 기반으로 제작되어 있기 때문에 운용자가 의도하지 않은 상황에서는 불필요한 중복 작업이 수행되지 않게 한다. task 수행 전 해당 모듈과 관련된 상태를 체크하여 문제가 없을 시에만 작업을 실행한다.

Cron 모듈과 멱등성 이해

ansible의 Cron은 Linux 시스템의 cron.d 와 crontab 을 관리하는 모듈이다.

운용자가 특정 계정으로 매분 단위 "ls -alh > /dev/null" 라는 명령어를 수행하고 싶다면,

Bash Shell의 echo로 /var/spool/cron 폴더 내 계정 파일에 crontab 작업을 추가하는 스크립트를 제작하면 된다.

이 경우 동일 명령어가 2번 수행 된다면 동일한 crontab 작업은 중복으로 2개가 추가된다.

 

ansible 의 Cron은 개별 cron job을 name 을 통해 관리한다.

운용자가 A 라는 crontab 작업 추가를 지시할 시 기존 crontab 내 A라는 작업이 있는지 사전에 확인한 후

동일 작업이 없을 경우에만 A job을 추가한다. 동일한 job이 있다면 해당 task를 pass 한다.

  • When crontab jobs are managed: the module includes one line with the description of the crontab entry "#Ansible: <name>" corresponding to the “name” passed to the module, which is used by future ansible/module calls to find/check the state. The “name” parameter should be unique, and changing the “name” value will result in a new cron task being created (or a different one being removed).

 

[Playbook]

"* * * * * ls -alh > /dev/null" crontab job 을 추가하는 playbook

Playbook 실행 시 crontab job 추가 작업이 진행되었기 때문에 changed 상태가 1로 설정된다.

작업 대상인 server2에 아래와 같이 crontab job이 추가된 것을 확인할 수 있다.

server1에서 동일 playbook 을 재실행 시에는 동일한 name으로 기존재 crontab job 이기 때문에 추가 작업이 미수행 되며 changed 상태는 0이 된다.

server2의 crontab 작업에는 변화가 없다.


다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible] 4 . Ansible Playbook 에서 hosts 인벤토리 파일 지정

ansible-playbook 지정 시 Default hosts 파일 경로는 /etc/ansible/hosts 이다.

해당 /etc/ansible/hosts 파일은 /etc/ 폴더 내에 존재하며 root 권한이 있어야만 작성 가능하다.

ansible playbook의 배포와 자유도를 높이기 위해서는 해당 파일에 종속되지 않는 인벤토리(Hosts) 파일이 필요하다.

ansible-playbook 실행 시 -i 옵션으로 작업 대상이 저장된 Inventory 파일의 지정이 가능하다.

/etc/ansible/hosts 파일 내 hosts 정보를 삭제 후 -i 옵션 없이 ansible-playbook를 실행하면 "no hosts matched" 에러가 발생한다.

-i 옵션을 설정 시 이전과 같이 정상적으로 실행되는 것을 확인할 수 있다.


다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible] 3 . Ansible Playbook 에서 gather_facts 설정 해제

ansible 의 playbook을 아래와 같이 ping taks를 추가 후 실행하면 의도하지 않은 [Gathering Facts] 가 추가로 실행 됨을 확인할 수 있다.

Facts 는 원격 대상 시스템의 호스트 네임, CPU, Memory 정보 등을 수집하는 setup 모듈이다.

수집 관련 전체 항목은 ansible -m setup 를 통해 확인 가능하다.

ansible 에서는 playbook 실행 시 default 로 setup 모듈을 실행하여 관련 정보를 사전에 수집한다.

작업 대상 서버가 대규모라면 Gathering Facts 를 사전에 실행하는 시간이 매우 많이 소요될 것이다.

수집된 정보를 playbook 내부에서 사용하지 않는다면 해당 설정을 disable 해주는 것이 좋다.

Playbook 제작 시 초반 hosts 설정 하단에 "gather_facts: no" 옵션을 추가하자.

 

[Playbook]

Playbook 실행 시 [Gathering Facts] 가 사라졌으며 수행 시간도 훨씬 더 단축된 것을 체감할 수 있다.


다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible] 2 . Ansible Playbook 활용 및 예제

2018. 8. 22. 02:34 - mr.november11

[Ansible] 2 . Ansible Playbook 활용 및 예제

https://docs.ansible.com/ansible/2.3/ 내 문서를 Study하며 작성했습니다.

Ansible 은 ADHOC이라는 task 실행 모드를 통해 Inventory 내 서버 대상 원격 명령어 실행을 지원한다.

하지만, Ansible 의 자동화 기능중 가장 필요한 부분은 YAML 언어를 활용한 Playbook이다.

Playbook 구성

Playbook은 YAML 형식으로 작성된다. YALM 문법은 리스트 및 해쉬로 구성되어 있다.

관련 내용은 https://ko.wikipedia.org/wiki/YAML 위키페이지를 한 번 정독하고 Playbook 예제를 따라해본다면 금방 적응할 수 있다.

참고로, YAML에서는 tab을 지원하지 않는다. 매우 불편하다..

Playbook의 목적은 정해진 대상서버(hosts)에 정해진 순서의 작업들(tasks)들을 실행하는 것이다.

ansible 에서 지원하는 다양한 module을 통해 원하는 각 작업(task)을 할 수 있다.

 

Playbook 예제

1) ping

    server2 에 test 라는 유저 계정으로 ping 테스트를 수행하는 playbook

    • hosts는 하나의 서버 또는 그룹을 지정할 수 있다. wilecard(*)와 같은 patten 지정도 가능하다.

    • remote_user는 원격 서버에 접속할 계정명이다.

      playbook 내에 password를 별도로 저장하는 항목이 없는 것으로 봐서 ssh key 설정 후 ansible실행을 일반적인 경우로 생각하는 것 같다.

    • tasks에는 모듈 기반으로 필요한 작업들을 listing 하여 작성할 수 있다.

      playbook 실행은 task 단위로 top->bottom 순으로 실행된다.

      ansible 에서 지원하는 모듈 리스트 및 구체적인 사항은 ansible 공식 document URL을 참고https://docs.ansible.com/ansible/2.3

  1. ansible-playook 명령어를 통해 제작한 playbook을 실행할 수 있다.

    ssh key 설정을 하지 않았다면 -k 옵션을 별도로 지정하면 password 입력을 통해 실행 가능하다.

    개인적인 생각으로 운영자가 개입된 ansible 실행이라면 password 를 입력 후 실행하도록 하는 것이 보안상 좋을 것 같다.

     

 

2) Ping 테스트 후 User 생성

이전에 생성한 playbook에 novebmer11 라는 신규 user를 생성한다.

user 생성은 원격 서버의 root 권한이 필요하기 때문에 sudo 권한이 필요하다.

[Playbook]

 

위에 작성한 playbook을 실행 시 ping check 는 정상적으로 실행되지만, 신규 user 생성의 경우 root 권한이 없기 때문에 아래와 같이 Permission denied 에러가 발생한다. (아래 Error 메시지를 보면 user 모듈에서는 내부적으로 /sbin/useradd 쉘을 실행하여 신규 유저를 생성함을 알 수 있다.)

fatal: [server2]: FAILED! => {"changed": false, "cmd": "/sbin/useradd -m november11", "msg": "[Errno 13] Permission denied", "rc": 13}

 

위 문제를 해결하기 위해 playbook 을 수정한다.

root 권한이 필요한 user 모듈에 become 을 활용하여 sudo 를 수행하도록 한다.

이전 ansible 버전에서는 sudo_user 를 활용했지만 1.9 버전 부터는 become 모듈로 대체되었다.

ansible-playbook 명령어 실행 또한 sudo 패스워드를 입력할 수 있도록 -K 옵션을 추가로 넣어준다.

playbook 실행 시 아래와 같이 Create User task가 정상적으로 수행된 것을 확인할 수 있다.

신규 유저 생성으로 서버 내 변경이 일어났기 때문에 changed 상태로 기록된다.

대상 서버인 server4 에서 /etc/passwd을 통해 november11 계정이 추가되었음을 확인할 수 있다.

 

다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다

[Ansible] 1. Ansible 개요 및 설치 방법

2018. 8. 11. 16:04 - mr.november11

[Ansible] 1. Ansible 개요 및 설치 방법

개요

Ansible은 인프라 관리 도구로 관리 대상 서버에 Agent 설치 없이 SSH 기반으로 다량의 서버를 운영할 수 있게 해준다.

일반적으로 운영으로 불리는 영역은

  • 패키지 설치
  • kernel, process 등 현황 현황 확인
  • 파일 다운로드
  • script 배포 및 실행

등이 있다.


Ansible 은 AD-HOC 이라 불리는 일회성 원격 명령어 수행을 지원하며,

YAML언어를 활용한 playbook 작업도 지원한다.

Ansible 설치 및 세팅법

1. pip를 사용한 ansible 설치

Ansible 은 python 기반으로 제공되며 pip 명령어 또는 직접 설치를 통해 쉽게 세팅 가능하다.

앞서 말했듯이 별도의 Agent 를 필요로 하지 않기 때문에 관리용 Management 서버 1대만 설정하면 된다.

pip install ansible

RHEL 이나 Cent OS 의 경우 yum 을 통해서도 설치 가능하다.

yum install ansible

2. inventory 설정

Ansible 에서는 관리 대상의 서버 리스트를 inventory라고 부른다.

inventory는 /etc/ansible/hosts 에 저장되며 서버 그룹과 호스트로 구성된다.

host는 /etc/hosts 에 사전에 등록되어 있어야 이름을 통해 해당 IP로 찾아갈 수 있다.

ex) /etc/ansible/hosts 예제

 

3. inventory 내 server 연결 테스트

ansible 은 ping 모듈을 통해 관리 장비와의 ansible 연동 테스트를 제공한다.

ssh 공개키 설정이 되어 있지 않다면 -k 옵션을 사용하여 password를 수동으로 입력해야 한다.

 

ssh 공개키 설정은

ssh-keygen 으로 공개키 생성 후

ssh-copy-id @server2 로 원격 배포가 가능하다.

공개키 세팅 후에는 -u 나 -k 옵션 없이 ansible 의 ping 체크가 가능하다.

 

마지막으로 ansible 의 setup 모듈을 사용하면 해당 장비의 관련 정보를 수집할 수 있다.

  • 관련정보 : OS 버전, NIC, Partition, Process 정보 등

결과 값은 JSON 형식을 통해 제공된다.

ansible -m setup


[참고 사이트]

https://docs.ansible.com/ansible/2.3/

다른 카테고리의 글 목록

Ansible 카테고리의 포스트를 톺아봅니다