Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

  • Part 1. Getting Started
  • Part II. Complex Installations
  • Part III. Custom Plugins
  • Part IV. Putting It All Together
  •  

    0. 안내

    이글은 처음 MCollective 사용하는 사람을 위하여 어떻게 접급하면 좋을지 Learning Mcollective  책과는 별개로 적습니다.

    Learning MCollective 문서 목차에 따라 정리를 하였습니다.

    샘플코드는 https://github.com/jorhett/learning-mcollective 에서 볼 수 있습니다.

    설치 예제는 CentOS 6.5 에서 진행을 하였습니다.

     

    Puppet Labs 동영상 http://docs.puppetlabs.com/mcollective/screencasts.html

     

    MCollective 처음 사용을 할 때는 vagrant 를 이용하여  먼저 기능 테스팅을 해보는 것이 좋다. vagrant 실행하면 바로 mco 명령으로 각종 테스팅을 할 수 있다.

    Learning Mcollective 의 경우 수동으로 설정하는 것도 설명을 하고 있지만 puppet 에 대해서 지식이 있으면 공부하기가 더 수월하다. configuration management 프로그램을 사용하지 않으면 각종 설정을 변경하고 기억하기가 쉽지 않다.

    초기 테스팅을 할때는 미들웨어, client/server 간의 보안 설정은 하지 않는 것이 편할 것이다. MCollective의 사용방법에 익숙해지고 실서비스에 배포를 할 경우에는 보안 설정에 신경을 써야 한다.

    mcollective-taejoon-public.ppt or http://www.slideshare.net/ssuser2f0173/mcollective-orchestration-tool : mcollective 한글 ppt 자료

    Part 1. Getting Started

    1. Introduction

    Mcollective 는 무엇인가?

    Mcollective 는 병렬 job 실행에 대한 프레임워크를 제공함. 최대한 실시간으로 서버 클러스터를 변경하는데 필요한 조정 작업(command & control)을 하는데 사용을 한다.

    Puppet/Chef/Salt 등과 같은 설정 관리 프로그램은 설정의 일관성을 관리하는데 사용을 하지만 Mcollective 는 보다 빠르게 전체 시스템에 걸쳐 특정 작업 또는 자주 하는 1회성 작업을 조정하는데 사용한다.

     

    Chef, Pupet, Capistrano, Salt 등의 제한점. pssh 같은 병렬 실행 프로그램의 제한점

    • Loops through systems in order, processing a few at a time
    • Simplistic (or overly complex) authentication mechanisms
    • Requires customization for each alternative environment
    • Unable to respond to deviations in response
    • Too easy to overlook fatal error messages output to the screen
    • Doesn’t support or extend existing management tools

     

    Mcollective 는 다른 툴과 다음 부분이 다르다.

    • 마스터 서버가 없는 환경을 제공해서 수천 대 이상의 시스템에서 병렬 작업을 실행할 수 있음
    • 커스터마이징할 수 있는 authentication(인증), authorization (인가) 메카니즘을 제공함
    • 서로 다른 플랫폼, 아키텍쳐, 로컬 환경을 투명하게 처리할 수 있음
    • Returns full data sets as result codes, allowing intelligent response (리턴 코드로 전체 데이터 셋을 제공하여 지능적인 응답을 할 수 있음.)
    • Directs results to a processor that takes action on responses
    • Puppet, Chef 같은 설정 관리 프로그램과 통합을 할 수 있음.

    작동 방식

    Mcollective 은 일관성 있고 반복할 수 있는 있는 결과를  보장하는 진정한 병렬 실행을 위해 만들어 졌다. Mcollective는 명령과 제어를 위해 중앙의 마스터를 사용하지 않기 때문에 중앙 마스터 서버의 리소스 문제를 피하고 있다. 또한 클러이언트에 순차적으로 접근하는 방식이 아니기 때문에 시스템 간의 drift 를 피할 수 있다. (순차적으로 명령을 실행하는 경우 각 시스템간에 실행 시간에 차이가 생김. )

     

    Mcollective 는 클러이언트와 서버간의 요청을 전달하기 위해서 publish/subscribe 미들웨어를 사용한다. Controlled 노드는 mcollectived 라는 서버 애플리케이션을 실행한다. 이 서버는 message topics 에 sbuscribe 되어 있다. 클라이언트는 message topics에 요청을 하는 애플리케이션이다. publish/subscribe 작업은 미들웨어 브로커에 대한 persistent connections 를 통해서 처리가 된다.

     

    mcollectived 서버는 미들웨어 브로커에 등록이 되고 listening 이나 IDLE 상태로 남아 있다. 클라이언트에서 미들웨어에 요청을 보낼 때마다 각 서버는 바로 그리고 독립적으로 요청을 받고 처리를 한다. mcollectived 는 요청에 대해서 확인을 하고 해당 요청을 처리할 agent 에 요청을 전달한다. 해당 agent 는 요청을 처리하고 응답을 보낸다.  Puppet Master 나 Chef 서버처럼 중앙의 리소스에서 정보를 가져오거나 보내지 않으며 사용하는 모든 리소스는 노드의 로컬 자원이다.

     

    이러한 모델에서는 정확히 같은 시간에 몇십대, 몇백대, 몇천 대 이상의 노드에서 명령 실행이 가능하다. publish/subscribe 인프라스트럭쳐를 통해 확장가능하고 빠른 병렬 실행 환경을 만들 수 있다.

     

     

    특 정 노드에만 명령을 실행할 경우에는 어떻게 하는가? Mcollective 는 어떤 노드에서 명령을 실행할지를 지정할 수 있는 방법을 제공한다. hostname, OS, 설치한 패키지, 실행하고 있는 프로세스 등으로 필터를 설정할 수 있다. 자신의 환경에 맞게 직접 agent 를 만들 수도 있다.

    왜 Mcollective를 쓰는가?

    • Mcollective는 분산된 publish/subscribe 미들웨어를 이용하여 중앙 마스터/슬레이브 환경에서 생기는 리소스 문제를 해결한다
    • Mcollective는 hostname, OS 등 일반적으로 많이 사용하는 정보 뿐만 아니라 커스텀 모듈에서 지정할 수 있는 어떤 정보든지 이용을 하여 필터링을 할 수 있다.
    • Mcollective agent는 내부적으로 호스트에 특정한 루틴을 구현하여 서로 다른 OS에 동일한 명령을 내릴 수 있다.
    • Mcollective agent 는 성공, 실패, 특정 리턴 코드,전체 프로세스에서 만든 데이타 타입 등을 레포팅 할 수 있다.
    • Puppet, Chef에 대해서 제어하고, 재사용할 수 있는 agent 가 있다.

    2. Installation

    여기에서는 Mcollective 환경을 구현하지만 세부적인 환경 설정까지 설명을 하지는 않는다.

    기본 설정은 다음과 갈이 구성을 한다.

    • 메시징 브로커 미들웨어로 ActiveMQ 사용
    • clients 와 servers 사이에 데이터 유효성을 확인하기 위해 Pre-Shared Key (PSK) 플러그인 사용
    • A simple Admin User has Totla Control authorization scheme

    요구사항

    OS

    시간 동기화가 동작하고 있어야 함. ntp 이용하여 시간 동기화해서 사용

    Ruby 1.8.7, 1.9.3, 2.0 : Mcollective 는 Ruby 1.8.7 이하의 ruby  에서는 동작하지 않음. http://docs.puppetlabs.com/mcollective/deploy/install.html 문서를 보면 2.0은 공식 지원은 하지 않지만 동작은 한다고 나와 있음.

    Ruby STOMP gem 1.2.10, 1.3.2, or higher : STOMP 는 Simple Text Oriented Messaging Protocol 임.

    5MB 디스크 공간

    256MB 메모리

    git 클라이언트 : 소스로 Mcollective 를 설치하거나 플러그인을 설치할 때만 필요함.

    미들웨어 브로커

    최소 500MB 메모리

    STOMP connector 를 지원하는 ActiveMQ 5.8 또는 이상 버전. http://activemq.apache.org/stomp.html

    STOMP connector 를 지원하는RabbitMQ 3.2 또는 이상 버전. http://www.rabbitmq.com/stomp.html

    디스크 공간은 미들웨어에 따라 다르며 ActiveMQ는 45MB, RabbitMQ는 10MB 필요함.

     

    대부분의 최신 OS에서는 수백대의 Mcollective 서버 연결을 처리할 수 있습니다. 수천의 동시 연결을 처리하도록 브로커를 튜닝하려면 "Large-Scale Broker configurations" 참고.(p118)

    어디에 설치해야 하나?

    CentOS 6.5 또는 Ubuntu 1.310 xi86 이상을 추천함.

    Passoword and Keys

    보안에 대한 부분은 11장 Midlleware Security, 13장 Mcollective Security 에서 자세히 다룸.

    이 책에서는 openssl 로 랜덤하게 패스워드 만드는 것을 설명하고 있음.

    Client password : clients 가 ActiveMQ에 접속해서 서버 호스트에 명령을 내릴 때 필요함.

    Server password : server 에서 ActiveMQ에 접속하여 command channels 에 subscribe 하기 위해서 필요함.

    Pre-Shared Key : 서버와 클라이언트간의 통신을 할 때 통신을 검증하기 위해서 필요함. SSL/TSL 에 대해서는 13장 Mcollective Security 에서 설명을 함.

    보안을 위하여 Client 와 Server password 는 서로 다르게 할 것을 추천함.

    Puppet Labs Repository

    Puppet Lab에서 APT, YUM repo를 제공한다. Puppet Lab repo를 통하여 Mcollective, Puppet, Facter, ActiveMQ 등과 RHEL 5.X 에서 Ruby 1.8.7 과 같은 의존성 있는  패키지를 설치할 수 있다.

    RHEL6, RHEL5, Fedora, Debian 과  Ubuntu 등을 제공한다.

    https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html 참고.

    RHEL6, CentOS6 에서는 다음과 같이 Puppet Lab yum repo를 설정할 수 있다.

    ActiveMQ 설정하기

    Mcollective 에서는 publish/subscribe 미들웨어가 반드시 필요하다. Puppet Labs 에서는 성능, 확장성, 테스팅 등에서 ActiveMQ를 추천하고 있다.

    activemq는 Java 프로그램이기 때문에 사전에 먼저 jdk/jre 를 설치한 후 activemq를 설치한다.

    설정파일 업데이트

    상세한 내용은 p101 "Detailed Configuration Review"에서 설명한다.

    CentOS6 에서는 /etc/activemq/activemq.xml 파일을 편집한다.

    • Enable purging in the broker
      • schedulePeriodForDestinationPurge 을 추가해준다. 오래된 큐를 정리하는데 필요한 옵션이다.

    • Disable producerFlowControl
      • topics, queues 에서 flow control 을 비활성화하고 stale queues 에 대한 가비지 컬렉션을 활성화한다.
      • In topic and queue names, the > character is a wildcard that will match any character until the end of the string. 모든 topic 과 queue 에 대해서 적용할 룰이다.
    • Define logins for clients and servers in simpleAuthenticationPlugin
      • Mcollective servers 와 clients 에서 사용할 사용자 이름, 비밀번호를 지정한다. 여기서 설정한 사용자 이름, 비밀번호는 mcollective 설정에서 동일하게 사용을 해야 한다.

      • groups 는 해당 사용자를 인가(authorization)에 사용하기 위한 그룹에 할당한다.

    • Define permissions for clients and servers in authorizationPlugins
      • 앞에서 생성했던 사용자에 대해서 권한을 설정한다.

    • Transports
      • 오 직 하나의 transport 만 활성화를 해야 한다. 다른 transports 를 삭제하거나 주석처리하고 STOMP transport만 활성화를 한다. nio는 JAVA Non-blocking i/o를 지원하는 것이며 나중에 따로 설명을 한다.

    • Disable the web console : mcollective 에서 ActiveMQ web console 은 필요하지 한다. 보안을 위해서 비활성화를 한다.
    • 여기에서 설정한 activemq 설정파일은 2. Installation2. Installation 내용을 참고

    서비스 시작 및 확인

    ActiveMQ 를 시작하고 ActiveMQ가 TCP port 61613 에서 정상적으로 올라오는지 확인을 한다. 문제가 있으면 로그 파일을 통해서 확인을 한다.

    ActiveMQ web console

    상세 내용은 http://activemq.apache.org/web-console.html 참고.

    ActiveMQ web console 을 활성화한 경우 시스템 상태 등 ActiveMQ의 정보를 볼 수 있다. localhost 를 해당 ip로 바꾸어 접근하면 된다. 기본은 사용자 인증은 가능하지만 비활성화되어 있다.

    http://localhost:8161/admin

    사용자 인증을 이용하려면 ${ACTIVEMQ_HOME}/conf/jetty.xml 에서 authenticate 를 true 로 변경한다. (CentOS6 /etc/activemq/jetty.xml)

    그 러면  ${ACTIVEMQ_HOME}/conf/jetty-realm.properties (CentOS6 /etc/activemq/jetty-realm.properties)에 지정되어 있는 계정과 비밀번호를 이용할 수 있다. 기본은 admin/admin 으로 되어 있다.

    <property name="authenticate" value="false" />

    authenticate 를 true로 변경함.

    <property name="authenticate" value="true" />

    Server 설치하기

    mcollectived 애플리케이션 서버는 clients 에서 요청한 처리를 처리할 모든 노드에 설치해야 한다.

    CentOS6 에서 mcollective를 설치한다. mcollective로 관리할 모든 서버에 설치를 해야 한다.

    /etc/mcollective/server.cfg 파일을 편집한다. plugin.activemq.pool.1.host 는 설정 환경에 맞게 변경하고 plugin.activemq.pool.1.user, plugin.activemq.pool.1.password  도 ActiveMQ에 설정한 것과 동일하게 맞춘다.

    mcollective 를 시작하고 서비스를 확인한다. mcollective 서버가 ActiveMQ 서버의 포트 연결을 확인한다. (server.cfg 파일과 activemq.xml 파일에 지정한 포트)

     

    Client 생성하기

    mcollective-client 설치

    /etc/mcollective/client.cfg 파일을 다음과 같이 설정한다. host, port, user, password 는 실제 설정에 맞추어야 한다.

    /etc/mcollective/client.cfg 파일에 대한 보안을 위하여 다음과 같이 퍼미션을 바꾼다.

    소스로 설치하기

    설명 생략

    설치한 것 테스팅 하기

    미들웨어 호스트를 설정하고 나면 최소 하나의 서버와 하나의 클라이언트가 있으며 설정이 동작하는지 테스팅을 할 수 있다. 

    mcollective client 에서 mco ping 명령을 이용하여 각 노드가 통신을 하는지 확인할 수 있다. ping 은 각 서버 노드가 midlleware 를 통해서 통신을 하고 있는지 확인을 하는 명령어이다.

    문제 찾기

    mco ping 이 제대로 작동하지 않는다면 Passwords, Networking, Connector Names 등을 확인해야 한다.

    자세한 내용은 책 참고.

     

    문태준 추가 - MCollective Vagrant 예제

    vagrant 로 Mcollective 데모를 할 수 있다.

    https://docs.puppetlabs.com/mcollective/deploy/demo.html

    이 사이트에 가면 https://github.com/ripienaar/mcollective-vagrant 로 링크가 되어 있다.

    사전에 virtualbox, vagrant 설치를 하고 난 후 vagrant 에서 mcollective 이미지를 다운받아 실행하면 된다.

    OS는 CentOS 6.3 x86_64 이며 ruby는 1.8.7 이 설치가 되어 있다.

    middleware 는 redis 를 이용하고 있다.

     

    아래는 vagrant 로 설치를 했을 때 기본 사용가능한 mcollective client 예제이다.

    mco 의 경우 mcollective 클라이언트에만 설치를 하면 되지만 지금의 demo에서는 middleware 를 포함 모든 노드에 설치를 하고 있다.

    실제 구현을 할 때는 mcollective 클라이언트는 꼭 필요한 곳에만 설치를 해야 한다. 안 그러면 mcollective 클라이언트가 설치된 곳에서 각종 작업을 할 수 있는 위험이 있다.

    3. Command-line Client

    mcollective 와 상호작용하는 일반적인 방법은 mco cli 클라이언트이며 직접 CLI에서 사용을 하거나 스크립트에서 이용할 수 있다.

    설정파일

    MCollective client 에 대한 글로벌 설정 파일은 /etc/mcollective/client.cfg 이다. 유저별로 자신의 설정 파일을 가질 수 있으며 user 홈 디렉토리의 .mcollective 파일을 이용한다. command line 에서 -c config file 을 지정할 수도 있다. 각 설정 파일은 사용에 필요한 전체 설정을 완전히 담고 있어야 한다. 설정 파일을 지정하면 글로벌 설정 파일은 사용하지 않는다.

    간단한 테스팅을 할 때는 사용자별 설정파일이 필요 없지만 인증을 위해서 SSL key 를 쓸 때는 각 사용자별로 설정을 해야 한다.

    Connector

    클라이언트에서 서버에 요청을 하기 위해서 클라이언트는 두가지 플러그인을 사용한다.

    • connector plugin : 미들웨어에 연결을 하고 topics 에 publish 하기 위해 필요
    • security plugin : to sign (and optionally encrypt) the data payload. clients 와 servers 간에 보안을 위해서 사용을 함.

    이 두가지 connectors 는 전체 환경을 통해서 동일해야 한다.

    위 예제에서는 connector = activemq 를 사용했으며 RabbitMQ 를 사용하거나 middleware connector 를 만들어서 사용할 수 있다.

    securityprovider = psk 를 사용했으며 자세한 내용은 Middleware security, Mcollective security 에서 설명한다.

    Facts

    시스템의 여러가지 정보를 확인하는 방법중의 하나가 facts 이며 서버의 정보를 key/value 쌍으로 제공한다. Puppet Labs 에서 제공하는 facter 프로그램을 통해서 facts 를 가져올 수 있다.

    먼저 /etc/mcollective/server.cfg 를 편집해서 mcollective 에서 facts 정보를 이용할 수 있도록 설정한다.

    이제 cron 을 통해서 주기적으로 facts 정보를 업데이트 하도록 설정을 한다.

    테스팅을 위해서 cron 대신 수작업으로 /etc/mcollective/facts.yaml 파일에 YAML 형식으로 정보를 넣어줄 수도 있다.

    facts.yaml 파일을 생성한 후 MCOLLECTIVED 를 재시작 해 주어야 한다.

    이렇게 한 후 inventory 요청을 보내고 읽을 수 있다.

    awk 를 써서 필요한 정보만 볼 수도 있다.

    얼마나 많은 노드가 동일한 facts 값을 공유하는지 질의를 할 수 있다.

    Inventory

    Mcollective clint 에서 제공하는 기본 명령중 하나는 inventory 이다. 이 명령을 통해서 특정 서버의 설정, collectives, 통계 등을 확인할 수 있다.

    가장 중요한 부분 중의 하나는 해당 호스트에 설치된 agents 와 plugins 이다.

    위의 facer 설명에서 mco inventory 명령을 참고하면 된다.

    Inventory Reports

    inventory 서비스에서 레포트를 만들 수도 있다. Ruby 스크립트를 짜서 몇가지 값을 출력하도록 하고 inventory 명령의 스크립트 인자로 넘겨서 실행을 해보자.

    각 호스트의 hostname, architecture, operating system, OS Release Ver 를 출력하는 예제이다.

    Discovery

    Mcollective client 에서 실행하는 가장 기본적인 작업 중의 하나는 collective 에서 어떤 서버가 사용 가능한지 찾는 작업이다.

    어떻게 client 에서 어떤 서버가 필터에 맞는지 결정을 할까? 답은 서버에 묻기 위해서 client.cfg 에 설정한 mc discovery plugin 을 사용한다는 것이다.

    mc discovery plugin 은 지정한 필터에 맞는 모든 서버에 브로드캐스트 쿼리를 보낸다. 10대 이상의 서버가 응답을 하면, 요청을 브로드캐스트로 보낸다. 10 대 이하의 서버가 응답을 하면 각 서버로 직접 메시지를 보낸다.

    client 설정에서 direct_addressing_threshold 옵션을 조정하여 언제 broadcast 와 direct addressing queries 를 할지 변경할 수 있다. (Figure 3-1 참고)

    Figure 3-1. Direct addressing

     

    mc 에서 사용하는 broadcast discovery 을 사용하지 않는 한가지 방법은 다른 discovery plugin 을 사용하는 것이다. 기본으로 제공하는 다른 discovery 플러그인은 flatfile 과 stdin discovery 플러그인이다. 이 플러그인들은 파일이나 표준 입력을 통해 호스트네임 목록을 사용한다.

    다음과 같이 사용을 할 수 있다.

    • Use the ---nodes filename.
    • Use --disc-method flatfile --discovery-option filename
    • Use -disc-method stdin and send a list of identities on standard input

    이렇게 사용을 하는 경우 broadcast 질의를 사용하지 않고 요청은 직접 각 노드별 특정의 큐로 간다.

    Responses to the request are compared against the list of server ideintified in discovery, so as to know if any nodes failed to respond. (정확한 의미가 이해 안 감)

    mco rpc 는 client applcation 을 사용하지 않고 agent 에 요청을 보내는 방법이다. Part III 에서 배울 것이다.

    ping 과 함께 flatfile discovery 를 사용할 수 있는 유일한 방법은 RPC invocation 을 사용하는 것이다.

    MCollective 에서 사용 가능한 여러 가지 discovery plugins 가 있으며 PuppetDB, Chef, MOngoDB, RiakDB, 그리고 Elastic Search 등이 있다. Part III에서 어떻게 직접 discovery plugin 을 만들 수 있는지 설명할 것이다.

    명령을 제한하기 위해서 자신만의 커스터마이징된 discovery plugins을 만드는 것이 좋은 방법이라고 생각을 할 것이다. 그렇지만 실제로는 그렇지 않다. MCollective 는 일관된 discoveory view 에 의존한다. 명령을 적용할 특정 서버를 제한하기 위해서는 필터링을 살펴보자.

    Filters

    일 반적으로 각 MCollective 명령에서 사용할 대상 서버 목록을 만드는 것은 불필요한 작업이다. 기본 broadcast discovery method 와 필터를 쓰면 더 쉽다. discoveory plugin 에서 사용하는 필터는 어떤 서버에 요청을 보낼지를 제한한다. 필터는 어떤 MCollective 명령에도 적용할 수 있다. mco 에서 제공하는 아무 명령어에 help 를 이용하면 필터 사용법이 나온다.

    각 필터 옵션별로 길고 짧게 쓸 수 있는데 길게 쓰는 경우가 더 이해하고 기억하기 쉽다.

    flatfile discovery plugin 은 오직 identity 필터만 지원을 한다.그래서 사용 가능한 강력한 필터가 있기 때문에 mc discovery plugin 을 추천하고 사용하는 것이다.

    Combination Filters

    combination 필터에는 두가지 타입이 있다. 하나는 Puppet classes 와 facter facts 이다.

    두 번째 타입은 select 필터로 더 강력한 필터 기능을 가지고 있다. select 필터는 Puppet classes, facts 와 복잡한 boolean logic 을 함께 이용하여 검색할 수 있다. and 와 or 를 사용할 수 있는 유일한 필터이다. 또한 부정을 의미하난 not 또는 ! 을 사용할 수 있다.

    마지막 예제는 httpd 또는 nginx Puppet class 이고 is_virtual fact 를 가진 서버만 보여 주고 있다. 이러한 겅색은 오직 select 필터 타입에서만 가능하다.

    Not All Filters Are Available with Every discovery Plugin

     flatfile 이나 stdin discovery method 를 사용하면 오직 identity 필터만 사용할 수 있다. 각  discovery method 에서 어떻게 필터를 이용 가능한지는 문서를 참고해야 한다.

    명령어 라인에서 다른 plugin 을 지정해도 select 필터를 사용하면 mc discovery plugin 을 사용한다.

    Limits

    필터와 상관 없이 얼마나 많은 서버가 동시에 요청을 받을지 또는 동시에 얼마나 많이 처리를 할지 지정할 수 있다.

    얼마나 많은 서버가 요청을 받을지는 –one, --limit, % 옵션이 있다.

    --one 은 랜덤하게 한대의 서버를 지정할 수 있고 --limit 는 고정된 서버 숫자를 지정할 수 있으며 해당 서버를 %로 지정할 수도 있다.

    임의의 15대 서버

    오직 하나의 CentOS서버

    Puppet class로 webserver 를 사용하는 5대의 서버

    Puppet class로 webserver 를 사용하는 33%의 가상 서버

    기 본적으로는 필터에 해당하는 모든 서버에서 동시에 요청을 보낸다. 그렇지만 이것을 제한하려고 하는 경우가 있을 수 있다. 예를 들어 동시에 로드밸런서 서버들을 업데이트 하고 싶지는 않을 것이다. 이럴 때는 배치 작업에서 얼마나 많은 서버가 요청을 받을지, 각 배치 작업 별로 시간 간격을 둘지 설정할 수 있다.

    각 배치 작업별로 10대의 서버에 대해서 sudo package 버전을 체크하며 각 배치 작업 사이에는 20 초를 둔다.

    모든 German 서버의 puppet 버전을 체크하는데 5대씩 30초의 시간 간격을 두고 체크한다.

    name 에 w 를 가진 모든 서버에 대해서 ping 을 체크하며 지연시간이나 배치 작업 없이 체크를 한다.

    Ping 은 매우 로우레벨의 요청이기 때문에 --batch 나 --limit 옵션을 사용하지 않는다.

    Output

    응답을 받을 때의 결과도 변경을 할 수 있다.

    텍스트 대신에 구조화된 정보를 제공한다.

    진행상황을 출력하지 않는다.

    discovery 에 얼마나 시간이 걸리는지, 전체 RPC 통계를 출력한다.

    명령을 보내지만 전체 응답큐를 생략한다. (결과를 출력하지 않는다)

    유용한 옵션 중 하나는 오직 실패한 노드나 성공한 응답만 출력을 하는 경우이다.

    요청을 받을 모든 서버에 대한 응답을 보기

    이 책을 쓴 저자가 책을 쓸 당시에는 몇가지 애플리케이션에서만 display 옵션이 작동을 했다고 한다. 아직든 지원하지 않는 프로그램이 있는 것 같다.

    Classes

    Puppet Class, Chef 에 대해서는 설명 생략.

    Puppet agent 에서는 일반적으로 /var/lib/puppet/state/classes.txt 파일에 적용하는 클래스를 기록한다. MCollective 는 기본값을 알고 있는데 만약 이 부분을 바꾸었다면 MCollective 의 server.cfg 설정에서 이 부분을 바꾸어 주어야 한다.

    Bash Completion

    MCollective 에서는 command-line completion 기능을 제공해서 mco 명령에서 Tab 을 이용하여 명령어를 선택할 수 있다. 그런데 직접 테스팅을 했는데 작동이 안 되었다. 이유는 살펴보지 않았다.

     

     

    4. Web Clients

    Puppet Enterprise 에서 MCollective 를 제어하기 위한 UI를 제공함.

    mcomaster http://mcomaster.org/

    Web UI가 있지만 필요할 것 같지는 않음

    5. Agent and Client Plugins

    MCollective 에서 제어하기 위해 각 노드에 설치하는 소프트웨어는 mcollectived 라고 부르는 대몬이다. mcollectived 는 애플리케이션 서버로서 기능을 하기 때문에 서버로 부른다. 노드에 어떤 제어를 하기 위해서는 agent plugins 를 설치해야 사용을 할 수 있다.

    Connector Plugins

    mcollectived 서비스가 작동하기 위해서는 connector plugin, security plugin 이 필요하다. 두 플러그인에 대해서는 앞에서 설명을 했기 때문에 생략을 함.

    패키지를 통해서 Agensts 설치하기

    Puppet Lab 에서 일반적으로 많이 사용하는 작업에 대해서 각종 agent 를 제공한다. 이미 Puppet Labs yum repo를 설정했다면 yum 으로 바로 설치가 가능하다.

    새로운 agent 를 설치하였으면 mcollectived 를 재시작하여 mcollective 가 agent 를 읽어들이도록 해야 한다. mco inventory 명령을 이용하여 설치한 agent 를 확인할 수 있다.

    mco find 명령을 이용하여 특정한 agent 를 설치한 모든 서버의 목록을 찾을 수 있다.

    agent 설치 작업은 모든 서버에 동일하게 해야 한다. 또한 client 노드에서 agent 에 해당하는 client 패키지를 설치해야 한다.

    소스에서 설치하기

    Copy to Plugins Directory

    생략

    Disabling Agents

    특정 agent 를 비활성화하려면 어떻게 해야 할까?

    첫 번째는 server.cfg 에서 비활성화할 agent 를 지정한다.

    두 번째는 특정 agent 에 대해서 설정 파일을 만드는 방법이다.

    이러한 값을 변경한 경우 mcollectived 를 reload 해 주어야 한다.

    Client Plugins 사용하기

    Client plugins 은 해당하는 agents 에 명령을 보낼 수 있는 애플리케이션이다. 서버에 해당하는 agent 를 설치한 경우에만 유효하다.

    client plugins 을 설치한 후 doc 명령어로 사용 가능한 애플리케이션 목록을 볼 수 있다.

    각 애플리케이션은 mco client 에 subcommands (faces 라고 부름)을 추가하며 각 client plugin 에서 제공하는 명령에 쉽게 접근할 수 있도록 해 준다. (The applications add custom subcommands (called faces) to the mco client, allowing easy access to the commands provided by each client plugin. ) 각 플러그인에 대해서는 help 명령을 통해 문서를 볼 수 있다.

    https://github.com/puppetlabs/mcollective-package-agent package agent 참고.

    help 명령을 통해서 해당 명령에 대한 간단한 syntax 를 볼 수 있지만 input, output 에 대한 상세한 내용은 오직 plugin 문서에서만 볼 수있다.

     

    참고로 puppet 을 설치하지 않으면 client 실행시 여러가지 에러가 났다. 아래에서 node1.example.net 에는 puppet 을 실행하지 않은 경우이다.

     

    플러그인 찾기

    새로운 플러그인이 필요하면 먼저 기존에 만든 agent 가 있는지 확인을 한다. plugin agent와 clients를 찾을 첫번째 위치는 Puppet Labs 이다.

    mcollective plugins 은 다음을 통해서 확인할 수 있다.

    http://projects.puppetlabs.com/projects/mcollective-plugins/wiki

    https://github.com/search?utf8=%E2%9C%93&q=mcollective

    불 행하게도 GitHub에 있는 많은 모듈들은 MCollective 의 예전 버전을 위해서 만들어졌다. 2014년 기준 최근 2년간 플러그인에 대한 요구사항이 매우 많이 바뀌었기 때문에 Learning MCollective 의 저자는 2013년 이후로 업데이트 되지 않은 플러그인은 피할 것을 추천하고 있다.

    mco plugin package 명령으로 플러그인 패키지를 만들 수 있으면 가장 좋다. 서버에는 -agent 패키지를 설치하고 클라이언트에는 -client 패키지를 설치한다. 그러고 나서 새로운 에이전트를 위해서 mcollectived 를 재시작 해야 한다.plugin 에 대한 패키지를 빌드할 수 없으면 소스에서 플거르인을 설치하는 프로세스는 P25 의 "Installing from Source"에 문서가 있다.

    추천하는 플러그인

    Plugin 이름설명
    Puppet Labs Plugins https://github.com/puppetlabs/mcollective-pluginsAgents for mongodb-registration, NRPE, and many others
    mcollective-test https://github.com/ripienaar/mcollective-testA set of helpers to assist in writing unit and integration tests for MCollective agents and applications
    iptables agent https://github.com/puppetlabs/mcollective-iptables-agentPuppet Labs agent for controlling iptables
    Shell Agents (https://github.com/cegeka/mcollective-shell-agent)shell 명령을 날릴 수 있는 에이전트
    PuppetDB Discovery https://github.com/ploubser/mcollective-puppetdb-discoveryDiscovery plugin that uses PuppetDB as the source
    Nadeau's Plugins https://github.com/nadeau/mcollective-pluginsAgents for procfs , lvm , lxc , drbd

    OMRY's Agents https://github.com/omry/mcollective-plugins

    Agents for grep , monit , status files , uptime , reboot ...
    Zcollective https://github.com/scalefactory/zcollectiveConfigure Zabbix using data discovered using MCollective
    Logstash Audit https://github.com/puppetlabs/mcollective-logstash-auditAn audit plugin that produces logs suitable for Logstash

    GitHub에서 매우 많은 플러그인을 찾을 수 있다. https://github.com/search?q=mcollective 를 살펴보자.

    6. Maintenance

    이제 MCollective 는 제대로 작동을 하고 있다. 이제 MCollective를 유지보수하고 디버깅하는 몇가지 작업에 대해 알아보자.

    시간 동기화

    클라이언트, 서버 환경에서 문제가 있는 경우 시간이 맞는지 확인하는 작업이 필요하다. 최신의 NTP 기반의 시간 동기화에서는 1/100 초가 고려할만한 시간 차이이고 대부분의 시스템은 동일한 초를 가져야 한다.

    모든 MCollective 메시지에는 현재의 timestamp 와 얼마나 메시지가 유효한지를 담고 있는 ttl을 포함하여 전송을 한다.

    가장 좋은 것은 Puppet 등의 설정관리 프로그램을 이용하여 모든 노드의 NTP 를 정확하게 설정하는 것이다.

    Sessiong Alive 유지하기

    서버와 미들웨어 간에 방화벽이나 flow-tracking 스위치를 사용하고 있다면 연결을 open 상태로 유지하도록 설정을 해야 한다.

    클 라이언트에서 능동적으로 요청을 하지 않으면 MCollective 의 STOMP 세션은 idle 상태로 있다. MCollective 는 TCP 세션에 대해서 keep-alive 플래그를 설정한다 .그렇지만 많은 OS에서는 대부분의 방화벽에서 세션을 drop 한 이후 첫번째 keep-alive 패캣을 보낸다. 서버는 세션이 끊긴 것을 알지 못한다. 미들웨어도 클라이언트로부터 메시지를 포워딩을 시도할 때까지 알지 못한다.

    STOMP 1.1 에서 도입된 STOMP heartbeat 를 통해서 이러한 문제를 해결하였다. 2장에서 사용할 설정에서는 heartbeat를 사용해서 연결을 살아있도록 유지한다.

    STOMP heartbeat 이전까지는 세션을 살아있도록 유지하기 위해서 주기적으로 방화벽의 세션 타잇아웃 보다 더 짧은 시간동안 updated registration information 을 보내도록 설정해야 했다. 일반적으로 매 10분이면 충분하다.

    기본 registration agent 는 AgentList 이며 서버에 설치한 플러그인 목록을 보낸다. 21장을 참고하여 다른 정보를 보내기 위한 자신만의 registration agent 를 만들 수 있다.

    Activating Changes

    server 나 agent 설정에 변경이 있는 경우에는 mcollectived 를 재시작해야 적용이 된다. 필요한 경우 /var/log/mcollective.log  로그파일을 확인한다.

    서버 통계

    inventory 요청을 보낸 경우 서버에 설치된 agent 목록과 함께 MCollective 에서는 몇가지 통계 정보를 함께 레포팅한다.

    Logging

    server.cfg 에서 설정을 변경하지 않았다면 다음이 로깅과 관련한 기본 설정이다.

    기본 설정에서 mcollectived 는 로그 파일을 디스크에 쓰고 자체 로그 로테이션을 한다. 디스크에 다섯개의 로그파일을 보관하고 크기가 2MB에 달하면 각 로그를 로테이션 한다.

    개인적으로 이 책의 저자는 다음의 설정을 추천하고 있다.

    자세한 내용은 puppet labs 문서를 참고한다.

    https://docs.puppetlabs.com/mcollective/configure/server.html#logging

    https://docs.puppetlabs.com/mcollective/configure/client.html#logging

    서버 모니터링

    MCollective 서버가 살아있는지 체크하는 것은 두가지 방식이 있다. actively , passively

    Active check : 모든 노드에 사용가능한 agent를 호출하여 결과를 확인한다. 간단하게는 mco ping 을 이용할 수 있는데 mco ping 의 경우는 low-level 연결 테스트로 인증이나 인가(권한 부여)가 필요하지 않다. 또는 NRPE  테스트 같은 특정 플러그인을 이용할 수 있다. 19장에서 스크립트를 제공한다.

    Passive check : registration agent topic 을 모니터링하고 있다가 최근에 체크하지 않은 서버를 찾는다. 21장에서는 registration agent를 어떻게 만드는지 설명하고 있다. Nagios를 이용하여 체크하는 예제는 Puppet Labs의 AgentRegistration Monitor 를 참고한다.

    http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentRegistrationMonitor

    7. Configuration Management

    MCollective를 배포하고 유지보수 하기 위해서는 Puppet, Chef 등의 설정 관리 툴을 이용하는 것이 좋다.

    설정 관리 툴의 이점에 대한 설명은 생략..

    Puppet/Chef 를 사용하지 않고 수동으로 설정을 하는 경우에는 책을 보고 필요한 설정을 직접 바꾸어야 한다.

    Puppet

    이 책 저자가 만든 Puppet module로 이 책에서 이야기한 모든 기능을 구현할 수 있다.  각 장마다 Puppet module 에서 어떻게 설정을 하면 되는지 예제가 있다.

    Puppet Forge 에 puppetlabs-mcollective 모듈이 있다. 그렇지만 다음의 이유로 PuppetLabs의 MCollective module을 추천하지 않음. 주로 보안 이슈임.

    • 알려진 user와 passwords를 사용함.
    • client 와 server permissions을 구분하지 않고 있음. 동일한 인증을 사용하면 보안 문제가 생김.
    • client 퍼미션과 broker link 퍼미션을 구분하지 않고 있음
    • Puppet Labs 모듈은 외부 의존성이 있음.

    Puppet 설치하기 (문태준 추가)

    Puppet 설치하는 방법에 대해서 모르는 경우가 있어서 필요성이 있어서 추가함. Puppet 에 대한 자세한 설명은 생략을 함. 아래에서 puppet master 서버의 주소는 node0.example.net 임.

    Puppet Master 설치

    Puppet 설치

    Puppet Module 설치하기

    Using r10k

    이미 r10k를 사용하고 있으면 https://github.com/jorhett/learning-mcollective 에서 파일을 받아 모듈을 설치할 수 있다. 여기에는 hiera 설정과 데이터용 예제 파일이 모두 들어 있다. 자세한 내용은 7. Configuration Management 의 "Using r10k to install Puppet Modules" 참고.

    GitHub 이용하여 설치하기

    지금 예제에서는 /etc/puppet/environments/learning_mcollective/ 디렉토리에 Puppet learning_mcollective environment를 만들어서 사용하는 예제이다.

    r10k를 사용하고 있지 않다면 GitHub에서 모듈을 다운로드 받아 설치할 수 있다.

    내부적으로 자체 forge 를 가지고 있다면 다음은 내부 forge 에 업로드할 수 있도록 적절한 모듈 패키지를 빌드한다.

    또는 modulepath에 직접 모듈을 이동시킬 수 있다.

    아직 Puppet Lab stdlib 모듈을 가지고 있지 않다면 다음과 같이 실행을 한다.

    다음 섹션에서는 manifests 의 site 설정이나 Hiera data 를 정의해야 한다.

    Puppet 이용하여 MCollective 설정하기

    다음의 Puppet manifests 는 기본 MCollective 설정을 하고 초기화를 할 것이다.

    이 모듈에는 이 책에 있는 모든 manifests 와 templates 를 포함하고 있고 ActioPolicy 설정 예제도 함께 들어 있습니다.

    이 Puppet module 은 ActiveMQ와 RabbitMQ 설정을 관리하기 위해 다른 Forge 모듈을 이용하는 경우 더 많은 미들웨어 설정을 위해 확장될 수 있다. 이 책에서는 간단하고 바로 세팅을 하기 위해서 오직 MCollective 클라이언트와 서버에만 촛점을 맞추었다. 미들웨어 설정을 따로 관리하기 원한다면 mcollective::middleware 를  사용하지 않으면 된다.

    간단한 예제로 아래와 같이 당신의 노드를 설정할 수 있다.

    설정에 따라서 오직 mcollective 와 mcollective::server 클래스만 사용할 수 있다. 요청을 하기 원하는 호스트에만 mcollective::client 를 설정해야 한다.

    Hiera Configuration Data

    manifests 파일을 통해서 원하는 파라미터를 설정할 수도 있지만 hiera 를 통해서 모든 설정을 할 수도 있다. 다음은 최소한의 파라미터로 설정을 하는 것이다.

    먼저, site manifest 에 대한 Hiera 에서 class 할당을 활성화한다.

    그러고나서 1차는 hostname이고 그 다음은 common file 에서 데이터를 찾도록 hiera 를 설정한다.

    전체적으로 공유할 수 있는 파라미터를 common file에 둔다. 이런 경우 모든 노드는 server 를 로드할 것이다:

    마지막으로 호스트네임에 따라 특정 classe 를 포함하는 두개의 파일을 만든다.

    HIera

    Hiera is a key/value lookup tool for configuration data, built to let you define Puppet configuration data without repeating yourself.

    If you are not familiar with using Hiera, the best reference can be found at Hiera Overview. In particular, read carefully “Usage with Puppet” for how Puppet modules automatically include Hiera data.

    MCollective Puppet module은 필요에 따라 설정할 수 있는 많은 파라미터가 있다. 이 모듈을 이용하여 보안을 강화한 설정이나 대규모 분산 network of brokers 설정 등도 할 수 있다. 다음과 같은 더 복잡한 작업을 할 수 있다.

    1. clients 가 자신의 로컬 브로커를 가리키도록 함.
    2. 브로커 사이에 site->site 링크 설정
    3. 모든 연결에 SSL 암호화 사용
    4. debug level 로 파일 로깅 설정
    5. 두 사이트에서 package, service, Puppet agent 로드함
    6. site1에만 client 프로그램을 설치함.

    다 음의 Hiera 설정은 런던과 필라델피아 오피스간에 설정을 나누고 있다. 각 사무실은 각자의 ActiveMQ 서버가 있다. 모든 admin은 런던에 있기 때문에 client 패키지는 런던에 설치가 된다. 다른 모든 파라미터는 동일하다.

    이 복잡한 설정을 이해하지 못한다고 걱정하지는 말자. 앞으로 계속 설명을 할 것이다. 이 책에서 계속 MCollective 로 할 수 있는 것들을 설명할 것이고 각 섹션마다 활성화할 수 있는 Puppet/Hiera 파라미터를 포함할 것이다.

    https://github.com/jorhett/learning-mcollective 의 설정 참고.

    Puppet 으로  Facts 공유

    필 터에서 설명을 했는데 관련된 시스템 그룹을 찾는 방법 중의 하나는 facts 이다. MCollective 를 위해 facter facts를 얻는 가장 쉬운 방법은 Puppet 에서 정보를 제공하도록 하는 방법이다. mcollective::facts 을 include 해서 사용하면 된다.

    Puppet manifest 에 다음을 추가하면 된다.

    또는 Hiera 로 다음과 같이 설정을 한다.

    p32에서 수동으로 cron 스크립트로 facts 정보 생성하도록 했다면 이 부분은 삭제를 해야 한다.

    Puppet 으로 Agent  설치하기

    다음은 agent 패키지가 package 레포지토리(yum 등)에서 사용 가능하다는 가정하에 시스템에 agent를 추가하는 예제이다. 정확한 버전을 정의할 수 있지만 이것은 필수는 아니다:

    hiera 에서는 더 쉽다.다음은은 동일한 Hiera 설정이다.

    mcollective::plugin::agents 는 설치할 agent 목록이다. 각 agent 는 dictionary of attributes 를 가져야 한다. 

    또 한 agent 를 위해 의존성에 대한 배열을 정의할 수도 있다. 다음은 MCollective Puppet agent 를 설치하는데 Puppet package 가 설치된 경우에만 작업을 한다. puppet::client class 에서 package 이름에 대한 변수를 찾는다.

    Hiear data 로는 다음과 같이 동일하게 표현할 수 있다:

    client 명령을 실행할 호스트에서는 client 플러그인을 설치해야 한다. 다음은 기본 값으로 client 플러그인을 설치하는 예제이다:

    Hiera 에서는 비어있는 dictionary 로 기본 값을 설정할 수 있다. 다음은 Hiera 예제이며 버전, 의존성을 지정한 경우도 있다.

    I’m sure you’ve noticed by now that Hiera uses plural names (agents and clients) but the declarative policy invocation uses a single name (agent or client). This should be intuitive to remember, since the single name loads a single plugin, whereas the Hiera plural name accepts a list of plugins.

    설치 확인하기

    다음과 같이 puppet client 를 실행한다.

    Puppet을 통해서 서버와 클라이언트가 예상된대로 동작을 하는지 확인을 한다. mco ping 을 실행하여 확인을 해보면 된다.

    미 들웨어에 연결된 모든 서버의 목록과 응답 시간을 볼 수 있다면 성공한 것이다. Puppet 을 통해서 성공적으로 MCollective 를 배포하였다. 제대로 동작을 하지 않으면 p28의 "Troubleshooting"을 참고하여 설정을 확인한다.

    디버깅

    MCollective 와 Puppet을 이용할 때 나타날 수 있는 일반적인 에러에 대해서 설명을 한다.

    Unable to match server with class

    --with-class 필터 옵션을 이용하여 해당 호스트를 찾을 수 없다면 mco inventory hostname 명령을 통해 해당 노드의 인벤토리 정보를 확인한다. 인벤토리에서 host에 대한 classes 목록이 나오지 않으면 mcollectve에서 읽어들이는 classes.txt 파일이 Puppet을 통해 만들어지지 않은 것이다.

    Puppet agent를 실행할 때마다 classes.txt 파일이 업데이트 된다. 기본값은 $statedir/classes.txt 이고 $statedir 기본값은 $vardir/state 이다. MCollective의 기본값은 모든 플랫폼에서 Puppet 에서의 위치와 동일하다.

    그 렇지만 이 변수는 puppet.conf 와 mcollective/server.cfg 에서 변경을 할 수 있다. puppet 을 이용하여 관리하는 노드에서 inventory 요청의 출력에 Puppet classes 를 찾을 수 없다면 다음의 두가지 값을 확인해야 하며 이 부분이 일치하는지 확인해야 한다:

    Puppet 에서 classfile 이 일치한다면 MCollectie 에서는 server.cfg 에서 설정을 바꿀 필요가 없다. 다른 값이 있다면 두 파일에 다음과 같이 명확하게 설정을 해야 한다:

    Unable to match server with fact

    --with-fact 필터 옵션을 이용하여 해당 호스트를 찾을 수 없다면 mco inventory hostname 명령을 통해 해당 노드의 인벤토리 정보를 확인한다. 인벤토리에서 host에 대한 fact 목록이 나오지 않으면 mcollectve에서 읽어들이는 facts.yaml 파일이 facter 나 Puppet을 통해 만들어지지 않은 것이다.

    MCollective 에서 facts에 대해 알기 위해서는 mcollective 의 server.cfg 에 plugin.yaml 파라미터가 설정이 되어 있어야 한다. 이 파일에는 서버의 facts 를 YAML 포맷으로 가지고 있으며 일반적으로 /etc/mcollective/facts.yaml 이다:

    plugin.yaml 파라미터에는 Unix 에서는 colon 으로 구분하여 여러 개의 파일 이름을 포함할 수 있다. (윈도우에서는 semicolon)  mcollective 를 재시작하고나서도 facts가 안 보인다면 대부분의 문제는 YAML 파일의 포맷이다.

    p32 의 "Facts"에서 시스템 facts를 수집하는 기본적인 방법을 설명했고. 좀 더 나은 유연한 방법은 p68 의 "Sharing Facts with Puppet"에서 소개한대로 Puppet 에서 생성한 facts 를 이용하는 것이다. 지정한 파일에 YAML 포맷으로 기록을 한다면 어떤 방법으로든 시스템 facts를 만들어 내는 것은 문제가 이니다.

    해당 파일에 facts를 쓰기 위해 다음과 같이 설정을 했는지 확인한다:

    • YAML 을 생성하는 cron (p32 "Facts")
    • Puppet 모듈에서 facter facts 를 생성(p68 의 "Sharing Facts with Puppet")
    • YAML key/value 쌍을 만드는 다른 스크립트나 프로세스

    Puppet Labs Forge 나 GitHub 등에서 YAML 포맷이 아닌 다른 facts 플러그인을 설치 할 수 있다. (p53 "Finding Community Plugins") 또한 20장을 참고하여 자신만의 facts 플러그인을 만들 수도 있다.

    There is a plugin named mcollective-facter-facts on the Puppet Labs GitHub. This agent can be slow to run, as it invokes Facter for each evaluation. This has been observed to cause problems with nodes going offline randomly. The plugin used here to load facts from a YAML-format text file works much better.

    Unable to match server by hostname

    --with-identity 또는 -i 필터 옵션을 이용하여 해당 호스트를 찾을 수 없다면 먼저 서버에서 mcollectived 가 실행되고 있는지 확인을 한다. 대부분은 이런 이유로 응답에 실패를 한다.

    다음으로는 server 설정에서 설정한 identity 를 확인해야 한다:

    이런 경우, identity 가  server 설정에 하드코딩되어 있지 않으며 해당 노드를 식별하기 위해서 다른 fact를 사용해야 한다.

    노 드에 대한 기본 identity는 hostname 명령의 실행 결과이다. Puppet 을 쓴다면 Puppet 에서는 certname을 이용하여 질의를 하며 certname 을 이용하여 노드 필터를 위한 필터로 사용할 수 있고 identity를 수집할 수 있다.

    MCollective 서버에서 다음 명령을 실행한다:

    MCollective client 를 설치한 노드에서 다음 명령을 실행한다:

    잘못 출력을 한 것이 아니다. 설정 변수 cername 은 Puppet 에 의해서 제공되는 facter fact clientcert 이다. 일치하지 않는 부분이 있지만 그것은 Puppet 이 작동하는 방식이다.

    No, that’s not a misprint. The configuration variable certname is provided by Puppet as facter fact clientcert . No idea why the inconsistency—it’s just how Puppet is.

    이와 같이 노드에 있는 어떤 fact 나 class라도 사용을 할 수 있다. 다음의 예제는 나의 테스트랩에 있는 오직 두대의 CentOS 호스트를 보여준다.

    MCollectiev 노드에서는 다른 이름을 사용하려면 server.cfg 에 identity 를 설정한다:

    configuration management 를 사용하고 있다면 , 해당 configuration management 의 정보에 따라 설정을 할 수 있다. 예를 들면 여기서 puppet template 는 hostname 대신 puppet certification name으로 MCollective node ideinties 를 설정하는 경우이다:

    노드 이름에서 가장 혼란스러운 부분은 node names을 쓰거나 hostname 의 FQDN을 사용하는 것이다. 예를 들면 간단한 이름으로 노드의 호스트네임을 설정할 수도 있고 도메인을 포함할 수도 있다:

    이러한 설정에서 Mcollective identity는 heliotrope 이지만 Puppet certname은 heliotrope.example.net (FQDN)을 사용한다. Redhat 계열에서는 /etc/sysconfig/network 을 변경하여 해결을 할 수 있다. 변경을 하지 않는다고 하더라도 이 차이점을 이해하고 있어야 한다.

    Puppet 과 MCollective 간에 이 차이점이 있다고 하더라도 이 때문에 명확한 문제가 발생하는 것은 아니다. 나의 테스트 셋업에서는 MCollective를 위해서는 짧은 노드 네임(heliotrope) 을 쓰지만 Puppet 에서는 언제나 FQDN(heliotrope.example.net)을 사용한다.

    Puppet 과 MCollectiev 에서 서로 다른 idientities 를 쓴다고 하더라도 전혀 문제가 없다. 오직 자신만의 커스텀 플러그인을 만들 때는 영향을 줄 수 있다. 내 의견으로는 많은 호스트에 유일한 호스트네임을 쓰면, 호스트네임에 도메인네임을 타이핑하는 작업을 줄일 수 있다. 다른 사람은 이에 대해서 다른 의견을 피력하기도 한다.

    Chef

    생략

    8. Controlling Puppet Agent

    이번 장에서는 MCollective 로 다음과 같은 작업을 할 것이다.

    • 필터에서 노드에 적용한 Puppet Classes 사용
    • facts 사용
    • Puppet agent 에 대한 질의, 시작, 정지, 재시작
    • 특수한 커맨드 라인 옵션과 함께 Puppet Agent 실행
    • Puppet resources 를 사용하여 노드의 설정 질의 및 변경하기

    MCollective 를 이용하면 agent, cron 으로 실행하기, Puppet 의 CLI 로 할 수 없는 작업을 새로운 방법을 사용할 수 있다.

    https://github.com/puppetlabs/mcollective-puppet-agent 참고.

    Puppet Agent 설치하기

    첫번째로 할 것은 MCollective Puppet agent를 설치하는 것이다. 이제 Puppet 으로 설치를 해 보자.

    Hiera 를 사용하고 있다면 mcollective::plugin::agents 배열에 Puppet agent 목록을 나열해서 agent를 설치할 수 있다. 이번 예에서는 Puppet client가 설치되어는지 확인하기 위해 Puppet agent 의존성을 설정하고 있다:

    Puppet 상태 체크하기

    MCollective Puppet agent를 설치하고 mcollectived 를 재시작 했으면 관리 노드에 MCollective Puppet client를 설치해야 한다. 먼저 확인을 해야 하는 것은 어떤 시스템에 MCollective Puppet agent를 설치했는지 확인하는 것이다.

    작 은 리소스만 사용을 하기 때문에 이러한 Puppet runs 은 매우 빠를 것이다. 이 책에서 제공하는 MCollective 모듈을 사용하는 최소한의 환경에서는 오직 몇가지 리소스만 쓴다. 프로덕션 환경에서는 몇백에서 몇천가지 리소스를 사용하기 때문에 실행 시간이 덜 길게 걸릴 것이다.

    Puppet 대몬 제어하기

    유지보수하는 동안, 특정 노드의 Puppet agent 를 비활성화하고 싶을 것이다. agent 를 비활성화하면서 다른 사람이 알 수 있도록 메시지를 추가할 수도 있다. (message 부분이 어떻게 보여지는지는 이해가 안 감)

    다시 Puppet agent를 재활성화한다.

    특정 필터에 해당하는 노드에 대해서 Puppet agent 를 활성화, 비활성화하는데 동일한 명령을 사용한다.

    Puppet 실행하기

    MCollective Puppet agent 는 Puppet 실행을 제어하는 강력한 도구를 제공한다. help 명령어를 이용해서 상세한 옵션을 볼 수 있다.

    한 대의 시스템에서 Puppet 을 실행하여 테스팅을 해 볼 수 있다.

    모든 CentOS 의 sudoer 파일을 픽스하기 위해서 Puppet 을 실행하려면 어떻게 하면될까?

    이 때, Puppet 대몬이 활성화되지 않은 호스트에서는 tags 와 noop 옵션만을 넘길 수 있다. 특정한 커맨드 라인 옵션으로 Puppet 을 실행하려면 Puppet daemon 을 주기적으로 cron 을 이용해 실행하거나  MCollective를 이용해서 실행해야 한다. If you leave the service running, you can still use runonce or runall, buy you cannot pass runtime options.

    Puppet 을 로컬 manifests 로 실행을 한다면(Puppet server 없는 환경) 동시에 몇천대의 호스트에서 Puppet을 실행할 수 있을 것이다. 그러나 Puppet server 기반의 환경이라면 동시에 대규모의 호스트에서 Puppet 을 실행하기 힘들 수 있다. 이와 같이 동시에 매우 많은 호스트에서 Puppet 을 실행하는 경우에는 동시에 실행할 호스트 숫자를 제한할 수 있다.

    다음 예제에는 동시에 두대씩 처리해서 모든 서버에서 천천히 Puppet 을 실행하는 예제이다.

    모든 웹서버에 대해서 Puppet 을 실행하며 동시에 다섯 대씩 작업을 한다.

    runall 은 batch 와 비슷하다. 그런데 batch는 sleep time 동안 기다리는데 runall은 다른 노드에서 작업을 시작하기 전에 현재 실행하고 있는 노드의 Puppet 대몬 작업이 실행이 끝나는 것을 기다린다 혹시나 중복되어 실행될 가능성을 줄이려고 한다면 batch 옵션을 이용할 수 있다. ()


    mco puppet --batch 명령어는 적용이 안되었음. 확인 필요함. splay 옵션을 이용하여 puppet 을 실행하는 방법도 있을 것임.

    Puppet Resource Types 변경하기

    MCollective Puppet agent 는 기능이 매우 강력하며 Puppet 의 Resource Abstraction Layer (LAL)에 기반하여 변경을 할 수도 있다. 예를 들어 특정 호스트에서 httpd 서비스가 정지되었다고 확인을 하려면 다음과 같이 할 수 있다.

    필터를 이용하여 이러한 제한을 할 수 있다. 예를 들면 다음과 같이 Puppet 에서 apache를 관리하지 않는 호스트에만 작업을 할 수 있다. (이 예제는 실제 작동하지 않음. 확인 필요.)

    이번 섹션는 Puppet을 이용하여 강력하게 제어할 수 있는 부분을 설명하고 있다. Puppet RAL을 이용하면 Puppet 이 알고 있는 모든 리소스 타입에 대해서 바로 접근을 할 수 있다. 어떻게 이러한 기능을 제한할지는 다음 섹션을 조심해서 읽어봐야 한다.

     

    어떤 리소스를 제어할 수있는지 제한하기

    기본은 MCollective 에서 아무런 리소스도 제어할 수 없다. MCollective agent 에서 기능은 활성화 되어 있지만 비어있는 whitelist 목록을 가지고 있다. whitelist 를 통해서 작업을 제한할 수 있다. 조심해서 사용을 해야 한다.

    다음이 기본 설정이다.

    resource 제어를 원하는 것이 있으면 server.cfg 파일을 편집하여 whitelist 나 blacklist 에 추가할 resource를 지정하면 된다.

    특정 resource 만 허용하는 whitelist

    특정 resource 만 제외하고 다른 모든 것을 허용하는 blacklist

    MCollective 에서는 whitelist 와 blacklist 를 섞어서 함께 사용하는 것은 허용을 하지 않는다.

    Puppet Resources 에 대해 MCollective 블락하기

    MCollective 에서 Puppet 정책에 어긋나게 변경을 하는 것을 막기 위해서 기본은 MCollective 에서 아무런 Puppet 리소스도 제어할 없도록 되어 있다. MCollective 가 Puppet 에서 제어하는 리소스를 변경할 수 있도록 하려면 아래 설정을 활성화해야 한다. (기본값임)

    9. Waking the Chef

    생략

    Part II. Complex Installations

    10. Middleware Configuration

    이번 장에서는 미들웨어 설정에 대하여 자세히 살펴볼 것이다. MCollective 를 배우는 목적이라면 이 장에서 설명하는 것을 모두 이해할 필요는 없다. MCollective가 지금의 환경에서 정상 동작을 하고 요구사항에 맞다면 이번 장을 자세히 읽어야 한다.

    이번 장을 주의깊게 읽어야 하는 이유는 다음과 같다.

    • 미들웨어 브로커에 연결을 하는데 어려움을 겪고 있다
    • 더 많은 호스트를 처리하기 위해 ActiveMQ를 튜닝한다.
    • 원격 site 에 network of brokers 를 구현하고 싶어 한다.
    • master/slave redundancy 를 찾고 있다.

    미들웨어에서 어떠한 설정을 변경하든지, 대부분의 변경 작업은 관리하는 서버의 성장을 어떻게 다룰지와 관련이 있다. 미들웨어 설정을 자세히 이해하는 것이 필수적이다.

    Messaging Brokers

    MCollective 는 클라이언트, 서버, 리스너 간에 메시징 서비를 제공하기 위해서 publish/subscribe 미들웨어를 사용한다. 디자인 측면에서 MCollective는 미들웨어 브로커와 통신하기 위해 connector plugins를 사용하며 이를 통해서 미들웨어와 통신 형태에 대해 유연성을 부여한다. core 설치를 할때는 다음의 미들웨어 플러그인을 지원한다. (그렇지만 다른 기술에 기반하여 자신만의 미들웨어 connector 를 만들 수 있다)

    이 와 같은 미들웨어 기술은 널리 사용되고 있고 개발자 커뮤니티를 통해서 활발하게 지원이 된다. 이러한 것들은 소규모 배포, 대규모 클러스터, 대규모 계층적 배포 등에서 사용할 수 있다. 이러한 기술은 몇천대 이상의 환경에서도 널리 사용되고 있다.

    Apache Apollo 는 ActiveMQ를 대체하기 위한 차세대 메시징 서버이다. Apache Apollo 는 ActiveMQ connector를 이용하여 MCollective에 사용할 수 있다. 그렇지만 이 책을 쓸 당시까지는 클러스터링을 지원하지 않았다.

    유명하고 활발하게 개발되고 있는 오픈 소스 메시지 브로커를 사용하기 때문에 MCollective는 상용 소프트웨어에 묶이지 않는 인프라를 구축할 수 있다. p17의 "Configuring ActriveMQ" 의 activemq.xml 파일의 미들웨어 설정에 대하여 살펴보자.

    Network Security

    다음은 미들웨어 브로커를 설정할 때 보안상 고려해야 할 부분이다.

    Transport Connectors

    사용하지 않는 transport connector 는 비활성화해야 한다. 예를 들어 ActiveMQ 미들웨어에 대한 TLS 암호화를 활성화했다면, 비암호화된 connector 에 대해서는 주석 처리를 한다.

    호스트에 여러 개의 IP 를 가지고 있는 경우, ActiveMQ에서 해당 IP에 대해서 응답을 하려면 0.0.0.0 이나 ::0 을 해당 IP로 변경해야 한다. 모든 서버와 클라이언트는 이 IP에 접근할 수 있어야 한다. 각 IP로 분리하는 것이 필요하다면 반복해서 설정을 하면 된다.

     

    방화벽 설정

    MCollective 는 미들웨어 브로커의 적절한 TCP 포트로 inbound 세션을 연결할 수 있어야 한다. 다음 테이블 목록은 미들웨어 브로커와 관리자 인터페이스에서 사용하는 포트를 명시하고 있다.

    Middleware

    Usage

    TCP Port

    Action

    ActiveMQ

    RMI Port

    1098

    Limit to management hosts

    ActiveMQ

    JMX Console

    1099

    Limit to management hosts

    ActiveMQ

    Web Console and Jolokia

    8161

    Limit to management hosts

    ActiveMQ

    STOMP unencrypted

    61613

    Allow

    ActiveMQ

    STOMP+SSL

    61614

    Allow

    ActiveMQ

    OpenWire unencrypted

    61616

    Limit to brokers

    ActiveMQ

    OpenWire+SSL

    61617

    Limit to brokers

    RabbitMQ

    STOMP unencrypted

    61613

    Allow

    RabbitMQ

    STOMP+SSL

    61614

    Allow

    iptables 를 이용하는 방법은 생략.

    IPv6 Dual-Stack Environments

    생략

    ActiveMQ 설정 구조

    ActiveMQ 설정은 꽤 길며 현재 파일의 위치가 헷갈린다. 시작하기 전에 간단하게 파일의 구조를 살펴보자.

    • There is a single broker element that handles all MCollective configuration.
    • Flow control and,  garbage collection : policyEntry elements 에 정의되어 있다.
    • Users : authenticationUser elements.
    • Access rules : authorizationEntry elements.
    • System resource limits : systemUsage elements.
    • Network connectors for clients : transportConnector elements.
    • Network connectors for other brokers : networkConnector elements.
    • The SSL keyStore and trustStore : sslContext element.

    ActiveMQ 5.8과 5.9에 대한 activemq.xml 예제는 https://github.com/jorhett/learning-mcollective/tree/master/examples 에서 볼 수 있다. 이 예제들은 이 책에서 설명하고 있는 것을 담고 있으며 Puppet module 의 ActiveMQ 템플릿을 통해서 생성한 결과를 담고 있다.

    https://github.com/jorhett/learning-mcollective/blob/master/examples/activemq_59.xml

    자세한 설정 정보 보기

    앞 섹션에서는 다음의 정의에 대해서는 빠져있다.

    Broker Definition

    broker element 는 모든 서버와 클라이언트가 통신을 할 ActiveMQ 자바 애플리케이션을 정의한다.

    brokerName 은 단일 인스턴스에 대해 어떠한 이름이라도 사용할 수 있으며 localhost 값으로도 충분하다. network of brokers 에서는 각 브로커마다 유일한 이름이 필요하다. 이에 대해서는 "ActiveMQ Clusters"에서 설명을 할 것이다.

    networkConnectorStartAsync 는 ActiveMQ가 병렬로 모든 네트워크 커넥션을 활성화할지를 가리킨다. 이 파라미터는 network of brokers 를 가질 경우에만 필요하지만 기본값을 사용하면 된다.

    schedulePeriodForDestinationPurge 에 60,000 milliseconds (60초)를 지정하였는데 ActiveMQ가 매분마다 불필요한 큐(stale queues)를 검색하는 것을 말한다. 이 설정은 policyEntry gcInactiveDestinations 가 활성화되어 있는 큐에 대해서 작동을 한다. 이러한 큐는 놀고 있고 비어있을 때 가비지 컬렉트 된다.  자세한 정보는 http://activemq.apache.org/delete-inactive-destinations.html 참고.

    Topic and Queue Tuning

    MCollective는 producer flow control(http://activemq.apache.org/producer-flow-control.html) 을 사용하지 않을 때 가장 동작을 잘한다. Producer flow control 은 메모리나 디스크 용량이 초과했을 때 producers 를 늦출 때 사용한다. This usually only occurs when you have many applications delivering large volumes of data to a slow processor that works through a queue on its own timeline.

    MCollective 요청은 작고 빠르며 일시적이다. 대부분의 질의에 대한 타임아웃은 10초이다. agent 나 clients 는 일반적으로 대규모 데이터를 보내지는 않으며 client 는 가능한한 빠르게 응답을 받을 것을 예상하고 있다. Mcollective  client 와 server가 flow control 의 overhead 없이 사용할 수 있도록 하는게 좋다.

    > 문자는 어떤 문자를 포함하는 와일드카드이다. 첫번째 문자로 사용을 했기 때문에 모든 토픽과 큐는 이 룰에 연관된다.

    pending subscriber messages  를 위한 vmCursor 값은 MCollective 가 모든 토픽 정보를 메모리에 올려서 빠르고 효율적으로 배포할 수 있도록 해준다. http://activemq.apache.org/message-cursors.html.

    다음 설정에서는 5분 동안 활동하지 않는 큐를 정리한다. (5분안에 새로운 요청이 큐에 들어오지 않으면 큐를 정리하고 메모리를 회복함):

    모든 요청은 응답을 수집하기 위하여 새로운 reply queue 를 생성한다. request timeout(기본은 10초) 이후에 클라이언트는 reploy queue 를 리스닝하는 것을 멈춘다. 가비지 컬렉션이 없으면 ActiveMQ의 메모리가 모두 소모될때까지 reply queue 의 숫자가 증가할 것이다. 이러한 룰을 통해 방치된 reply queues 를 정리한다.

    policyEntry for queues 는 두가지 파라미터를 가지고 있다.:

    • gcInactiveDestinations : 브로커가 정책에 일치하는 큐에 대해 가비이 컬렉션을 하도록 함. (지금 예에서는 모든 큐에 대해서 적용)
    • inactiveTimeoutBeforeGC : 5분동안 idle 상태에 있는 경우 큐를 제거하도록 함.

    매우 많은 reply queues 가 있고 빠르게 정리가 된다면, inactiveTimeoutBeforeGC 값을 기본값이 1분(60000)으로 조정할 수 있다.

    토픽에서 pending queue messages 를 위한 vmQueueCursor 값은 MCollective 가 모든 큐를 메모리에 유지하여 빠르고 효율적으로 배포하도록 설정을 한다. http://activemq.apache.org/message-cursors.html.

    Authentication and Authorization

    미들웨어 인증에서 가장 중요한 부분은 nodes queue 와 agent topics 이다. 이것들은 요청에 응답해야 할 서버들에 메시지를 전달한다.

    To consider the marionette metaphor, these are your strings. node queue 에 대한 메시지는 하나의 노드에만 전달이 된다. agent topc 에 publish 한 메시지는 해당 agent 가 설치된 모든 mcollectived 대문에서 받고 처리가 된다.

    Users and groups

    users 와 할당할 그룹을 정의한다.

    authorizationPlugin 섹션에 정의되는 모든 authorization rules 은 usernames이 아닌 groups 을 사용한다. 원한다면 추가로 usernames와 비밀번호를 만들 수 있지만 이것은 어떤 명령어가 서버에서 실행 가능한지를 제어하는 것은 아니라는 것을 기억해야 한다. 이것은 오직 각 topic이나 queue 에 누가 요청을 보낼 수 있는지를 제어하는 것이다. 일반적으로 middleware authentication 에서 이 세가지 그룹을 이용하도록 하고 authorization rules 를 사용하여 제어하는 것이 가장 좋다. p163 “Authorization” 참고.

    우리의 초기 설정에서는 오직 두 user 만 가지고 있다는 것을 알아챘을 것이다. 우리는 broker user를 포함할 것이며 p113 “ActiveMQ Clusters” 에서 소개할 것이다.

    Topics and queues the clients send to

    첫 번째로 알아야 할 것은 brokers 그룹을 정의하고 여기에 모든 queue 와 topic 에 쓰기 권한을 주는 것이다. (클러스터 설정에서 데이터를 relay 하기 위해 브로커에서만 사용을 함. p113 “ActiveMQ Clusters” 에서 설명할 것임):

    다 음은 clients 에게 MCollective topics 와 queues 에 글로벌하게 읽기, 쓰기 권한을 준다. > 문자는 와일드카드이며 MCollective에 있는 모든 topics 나 queues 에 접근을 허용한다.:

    admin permission 은 클라이언트가 해당 토익이나 큐가 없으면 생성할 수 있도록 허용한다.

    이 예에서 우리의 collective 이름은 mcollective 이고 이것이 기본값이다. 12장에서 여러개의 collectives를 사용하는 것에 대해서 논의할 것이다. 이 때 각 collective의 이름에 대해 마지막 두 라인을 설정해야 한다.  At that time, you’ll need to duplicate the last two lines with each collective’s name.

    Topics and queues the servers read from

    서버 노드에서 MCollective agent topics 에 대해 읽거나 생성하는 것을 허용한다.

    agent topics 은 해당 agent를 가진 여러 노드를 위해 클라이언트에서 요청을 하는 곳이다. 예를 들면 mco puppet runonce 명령은 mcollective.puppet.agent topic 으로 보내질 것이다.:

    여기에서는 서버 노드에서 MCollective node queue 에 대해 읽거나 생성하는 것을 허용한다. MCollective node queue는 단일 MCollective 서버를 위해 명령을 위치하는 곳이다.

    topics 과 queues에서는 명시적으로  write 퍼미션을 사용하지 않는다. 왜냐하면 위의 wildcard client rules 에서 클라이언트가 이러한 큐에 대한 쓰기 권한을 허용하고 있기 때문이다. 서버는 이러한 큐에 대해서는 쓰기권한이 있으면 안된다. The topics and queues don’t use an explicit write permission because the wildcard client rules above them allow clients to write to any of these queues. The servers should not write to these queues.

    Topics and queues the servers write to

    다 음은 서버 노드에서 agent topics을 생성하거나 데이터 제공하는 것을 허용할 것이다. the registration agent (이러한 정보는 서버 연결을 할때 그리고 주기적으로 보내진다. 21장에서 registration 에 대해서 더 자세히 논의할 것이다):

    그러고나서 서버가 해당 정보 수집을 위해서 성성된 큐에 응답하는 것을 허용할 것이다.:

    <authorizationEntry queue="mcollective.reply.>"

    write="servers" admin="clients"

    />

    예 를 들어, filemgr agent 에 명령을 내리고 해당 요청에 할당한 유일한 숫자가 170075 이면 filemgr_170075 로 명명된 reply queue 가 생성될 것이다. 필터에 해당하는 각 서버는 mcollective.reply.filemgr_170075 큐에 응답을 보낼 것이다. client는 큐에서 각 응답을 읽을 수 있다.

    Transport Connectors

    transportConnector element는 서버와 클라이언트가 IP 네터워크를 통해서 미들웨어 브로커와 연결하는 방법을 정의한다.

    모 든 MCollective 메시지는 Streaming Text Oriented Messaging Pro‐tocol (STOMP) 패킷으로 포맷이 된다. 다음 설정은 ActiveMQ’s New I/O (NIO) library 를 사용하는 STOMP 프로토콜을 생성한다.

    NIO 인터페이스는 훨씬 더 좋은 성능을 낸다. NIO 없이 stomp connector 를 쓰는 것은 아주 작은 규모에만 적합하다.

    하나의 인터페이스네 특정한 IP 주소를 사용할 수 있으며 원한다면 TCP port를 변경할 수 있다. 다음 예제에서는 TCP port 6163과 함께 특정 IP4와 IPV6 주소를 보여준다:

    p113 “ActiveMQ Clusters” 에서 다른 ActiveMQ brokers 와 링크하기 위해 어떻게 networkConnector elements 를 사용하는지 배울 것이다.

    11장은 MCollective 노드와 미들웨어 브로커간에 트래픽을 보호하기 위해 어떻게 TLS 암호화를 활성화하는지 배울 것이다.

    Management Interfaces

    ActiveMQ 를 오직 MCollective와 사용을 한다면 ActiveMQ에 대한 관리 콘솔이 꼭 필요한 것은 아니다. MCollective 애플리케이션의 필요성은 일반적으로 작고 임시적이기 때문에 대규모 데이터 스트림이나 긴 질의에 대한 튜닝은 필요가 없다.

    그렇지만 다음 섹션에서 설명을 하는 내용은 ActiveMQ를 구현하면서 문제가 있어서 디버깅을 할 때 유용하다.

    Web Console

    Web Console을 활성화하면 ActiveMQ의 큐와 토픽을 확인할 수 있는 웹 인터페이스를 제공한다. 각 토픽과 큐를 통해서 얼마나 많은 메시지들이 처리가 되는지, 많이 쌓여있는 큐를 확인하 는 등의 작업이 가능하다.

    ActiveMQ box 의 8161 port를 이용하여 콘솔에 접근할 수 있다.http://activemq.example.net:8161/admin

    WebConsole 을 활성화 하려면 ActiveMQ 파일에서 Jetty 부분을 편집하면 된다.

    7장에서 설명한 Puppet module 을 사용하고 있으면 다음과 같이 비밀번호를 이용하여 보안을 강화할 수 있다.

    기본은 Web Console 연경은 암호화가 되어 있지 않다. 이 부분을 사용하려면 conf/jetty.xml 파일에서 SecureConnector element 의 주석을 제거해 준다.

    더 자세한 정보는 http://activemq.apache.org/web-console.html 참고.

    Jolokia API and HawtIO

    생략

    JMX MBean Console

    생략

    Statistics plugin

    생략

    결론

    이번 섹션에서는 초기 셋업시 사용한 기본 설정의 각 튜닝 파라미터에 대해 알아 보았다.

    MCollectie 에서 사용하는 토픽과 큐에 대한 구조를 살펴보았다.

    TransportConnector element 와 왜 Java NIO connector 가 필요한지 설명하였다.

    ActiveMQ 디버깅을 위한 여러가지 관리 인터페이스를 살펴보았다.

    다음 섹션에서는 대규모 환경에서 보안과 안정성을 강화하는 방법을 설명할 것이다.

    ActiveMQ Clusters

    collective 를 수천대 노드로 확장하거나 여러 sites 를 가지고 있다면 다음을 원할 것이다.

    • sites 간에 메시지를 전달하기 위해 network of brokers 구성
    • 사이트에 redundancy 를 제공하기 위해 master/slave 동기화 구성
    • 사이트 간의 트래픽 암호화

    이 모든 옵션을 쓰거나 조합해서 사용할 수 있다.

    Network of Brokers

    network of brokers 구성은 서로 다른 물리적인 지역에 ActiveMQ 서버를 두려고 하고 ActiveMQ 서버들을 단일하고 일관된 메시지 space 로 운영하는 경우 유용하다. 다음은 linkage 를 세팅하기 위해 두개의 ActiveMQ 시스템을 추가할 때 사용한다.

    networkConnector 에 대한 튜닝 옵션은 다음 참고. http://activemq.apache.org/networks-of-brokers.html

    broker user를 brokers group에 두면 받아들이는 ActiveMQ 서버에 모든 토픽과 큐를 쓸 수 있다. replication 이 작동하려면 이러한 작업이 필요하다.

    각 지역에서는 클라이언트가 가까운 미들웨어 브로커로 연결을 하도록 설정할 수 있다. 모든 메시지는 두 지역간에 전송이 될 수 있어서 단일 collective 가 sites 에 걸쳐 정확하게 작동할 수 있도록 할 수 있다. redundancy 를 걱정한다면 클라이언트에서 로컬 사이트가 다운되었을 때 다른 사이트로 fail over 하도록 설정할 수 있다.

    The Puppet Labs site indicates that you will need two connections, one for topics and another for queues, at http://bit.ly/UttA1X. My tests were unable to confirm this—I used these settings successfully with clients and servers on each side.

    이 책에 포함된 Puppet module 에서는 간단하게 hosts Hiera 파라미터에 여러 개의 브로커를 추가하고 broker 비밀번호를 제공해서 간단하게 구성을 할 수 있다.

    브로커에 접속하기 위한 다른 파라미터들은 모두 동일하다.

    클 라이언트나 서버에서 오직 로컬 노드만 사용하도록 제한을 하고 싶을 때도 있다. 각 모듈은 각자의 레이어에서 값을 변경할 수 있다. 두가지 방법이 있다. The easiest is only to inform the brokers of all nodes:

    또는 서버에서는 로컬 로드를 사용하고 브로커와 클라이언트는 모든 노드를 사용하도록 설정할 수도 있다.

    대 규모 환경(2,000-3,000 노드이며, 브로커간의 지연시간에 달려있음)에서 discovery 는 기본값인 2초 보다는 길 수 있다.  5,500 노드를 가진 실환경에서 모든 노드에서 지속적으로 응답을 받는데는 discovery 에 10초가 필요하다는 것을 발견하였다. client app에서 discovery timeout (Part III에서 설명할 것임)을 늘리거나 모든 CLI 명령에서 타이핑하는 것을 피하기 위해 환경 변수를 설정할 수있다.

    $ export MCOLLECTIVE_EXTRA_OPTS="--discovery-timeout 10 --timeout 5"

    Master/Slave Redundancy

    단일 지역에서 빠르게 failover 응답을 하고 싶다면 master/slave cluster 셋업을 원할 수 있다. 이러한 설정에서는 두 브로커에 아래와 같은 동일한 설정을 원할 것이다.

    networkConnector uri 를 신경써서 보자. 처음에 적은 호스트가 master 이며 그 뒤에 적은 모든 호스트네임은 slave 이다.모든 ActiveMQ 브로커에서 동일한 순서로 목록을 가지고 있어야 한다.

    networkConnector 에 대한 튜닝 옵션은 http://activemq.apache.org/networks-of-brokers.html 참고.

    서버와 클라이언트에서 slave 로 fail over 를 하려면 서버와 클라이언트 설정 파일에서 다음 내용을 변경해야 한다.

    이 책에서 제공하는 Puppet module 에서 master/slave 설정을 하려면 다음의 Hiera 파라미터를 설정하면 된다.

    borkers 에 접속하는 모든 다른 파라미터는 동일해야 한다.

    Broker Links 암호화

    site 간에 링크를 SSL/TLS 암호화하고 싶을 것이다. 이렇게 하라면 P129 "Anonymous TLS"의 KEYsTORE 와 p132 의 "CA-Verified TLS Servers" 의 trustStore 를 만들어야 한다.

    그러고나서 적절한 프로토콜을 사용할 수 있도록 site 간에 ActiveMQ 설정을 조정해야 한다.

    Puppet module 에서는 다음과 갈이 Hiera 파라미터를 변경하면 된다.

    결론

    이번 섹션에서는 다중 브로커 사용을 하는 두가지 모델을 살펴보았다.

    • 서로 다른 site 간에 연결을 제공하기 위한 network of brokers
    • 하드웨어 장애를 극복하기 위한 master-slave redundancy

    You can blend both of these options to connect a master/slave pair of brokers to brokers at remote sites.

    대규모 환경에서 브로커 설정하기

    대규모 브로크 설정으로는 두가지 타입이 있다.

    • 단일 broker 를 사용하는 많은 클라이언트
    • 전세계상에 분포되어 있는 많은 사이트 brokers

    동일한 조직에서 두가지 설정을 사용할 수 있다. 각각의 필요성에 대해서 다룰 것이다.

    저 자는 자주 "고성능의 ActiveMQ 설정"에 대한 요청을 본다. 이러한 설정에 대한 기본 권장사항은 있다. 그렇지만 MCollective 환경이 size 나 네트워크 지연시간등이 커짐에 따라 네트워크와 요구사항에 맞게 조정을 해야 한다.

    In my personal time, I race motorcycles on closed courses for fun. Let’s think about tuning using motorcycle (or car) racing as an analogy.

    A street motorcycle/car works on all streets without custom changes because the needs are simple. You only go about half as fast as it can go, and you don’t brake to the limits every time you stop. This is like a basic middleware broker: it can easily handle a few hundred nodes without any tuning.

     

    Once you are trying to run at top speed, maintain the highest corner speed, or brake down from the highest speed without losing control, your demands are much higher. So you have to tune your motorcycle/car to perform at that level.

     

    You can get some basic tuning assistance from anyone, but to run with the very best, you must tune your motorcycle to the conditions at each track you go to. Everything from riding style to corner banking to air temperature will play into the tuning equations. The most successful race teams tune their race bike/car to the specific needs of that specific track on that specific day.

     

    Small sites (street drivers) can use MCollective without any special tuning. Big sites with big demands (racers) need to tune MCollective for the special needs of their own

    racetrack, which will be different than every other racetrack.

     

    This analogy only goes so far—thankfully, you won’t need to retune MCollective every day. As your environment grows, you’ll need to tune MCollective differently for your specific network (track) and for your specific usage (riding style). What works on a different network or to support different applications won’t necessarily work for you.

    이 번 섹션에서는 대규모 클라이언트나 대규모 볼륨 트래픽을 위해서 ActiveMQ 를 튜닝하는 방법에 대해 다룰 것이다. MCollectie 와 관련없이 ActiveMQ에서 튜닝할 파라미터가 많이 있다. 여기에서는 이런 부분에 대해서는 생략을 하고 MCollective 와 연관된 내용만 다룰 것이다.

    MCollective 에서 필요한 부분 이해하기

    Puppet Lab의 문서에서는 미들웨어 규모에 대해 매우 보수적인 권장사항을 가지고 있다.

    http://docs.puppetlabs.com/mcollective/deploy/middleware/activemq.html#settings-for-networks-ofbrokers

    Scale — we recommend a maximum of about 800 MCollective servers per ActiveMQ broker, and multiple brokers let you expand past this.

    이것은 안전한 룰이다. 실제로는 어떠한 환경에 있느냐에 따라 달라진다. 저자는 브로커당 내베에 달하는 sites 에 간여한 적이 있었다. 또한 이 숫자보더 다 낮은 수치를 보이는 sites 도 있었다. 정확한 필요성에 대한 답변을 위해 필요한 것은 이를 해결하기 위해 더 많은 시간을 써야 한다는 것이고 시간에 걸쳐 설정을 변경해야 한다는 것이다.

    먼저, 당신의 네트워크에서 어떤 것이 MCollective 를 빠르게 할 수 있는지 살펴보자.

    • Bigger network pipes , Low-latency links

    아 주 소규모 환경에 MCollective 는 상당한 네트워크 트래픽을 발생시킬 수 있는데 이 경우 대규모 데이터 전송을 하는 agent 를 만들거나 쓰는 것은 당신이라는 것을 알 것이다. 대부분의 요청과 응답은 크기가 매우 작으며 매우 작은 규모의 패킷을 수백개 발생시킬 것이다.

    MCollective 는 브로커간에 network links 에 대한 지연시간에 매우 민감하다. 저자는 가능하다면 star 보다는 mesh 로 모든 networks of brokers를 구현하는게 가장 좋다는 것을 발견하였다. mesh 에서는 전송하기 전에 중앙 라우팅 큐를 거치는 대신에 단일 hop 으로 destination 에 트래픽을 보낼 수 있다.

    https://en.wikipedia.org/wiki/File:NetworkTopology-FullyConnected.png

    https://en.wikipedia.org/wiki/Star_network

    • Dozens of CPU Cores , Gigbabytes of RAM

    ActiveMQ 는 수직적(서버 하드웨어 사양을 업그레이드 하는 것)으로 확장할 수 있는 것으로 보이지는 않는다. ActiveMQ를 좀 더 사양이 좋은 하드웨어 박스로 옮겼지만 성능상의 이점은 없었다. 저자의 경험으로 볼때 OpeStack/KVM 또는 VMware ESX 가상 호스트를 사용을 할 때도 비슷한 스펙의 bare metal 호스트와 동일한 성능을 냈다. 대부분의 환경에서 ActiveMQ 큐가 부하가 걸려서 CPU 활용은 매우 낮은 상태에서 운영이 되었다.

    더 높은 성능을 위해서 ActiveMQ 을 튜닝하는 가장 좋은 방법은 더 많은 메모리를 이용하는 것이다. 기본 설치를 할 경우에 Java 애플리케이션은 512MB 의 제한이 있고 ActiveMQ broker 는 20MB의 램만 사용을 한다. 오늘날 작은 시스템이라고 하더라도 이보다는 훨씬 더 많은 메모리를 가지고 있고 저자는 주로 이 제한보다 4배 또는 8배로 설정해서 사용을 했다. Java는 오직 자신에게 필요한 만큼만 사용을 한다. 저자는 ActiveMQ 5.8이나 5.9에서 치명적인 메모리 leakage 는 보지 못했다.

    • Less collectives with more machines , Localized collectives avoid transit

    5,000 도를 가진 collective 에 질의를 던지면 discovery 하는 동안에 모든 5,000 호스트에 요청을 브로드캐스트할 것이다. 각 호스트는 필터를 읽고 응답을 할지를 결정해야 한다. collectives 를 나누고 대부분의 메시지를 로컬 subcollective 로 보낸다면 cross-site 네트워크 트래픽을 상당히 줄일 수 있다. 12장에서 이에 대해서 설명을 할 것이다.

    기본 튜닝을 위한 추천사항

    고성능의 미들웨어를 설정하기 위해 모든 site 에서 필요한 일반적인 설정에 대해서 설명을 한다.

    • Set org.apache.activemq.UseDedicatedTaskRunner to false in the wrapper configuration file, or use -Dorg.apache.activemq.UseDedicatedTaskRunner=false in the command-line arguments. (무슨 내용인지 이해는 안 감.)
    • 시스템에서 활용 가능한 메모리의 대부분을 Java Max Memory 로 사용할 수 있도록 튜닝을 함. A dedicated broker isn’t doing much else with that memory, is it? 대부분의 플랫폼에서 activemq-wrapper.conf  파일에  설정을 하거나 명령 라인에서 -Xmx512m 옵션을 준다.
    • p101의 “Detailed Configuration Review” 에서 이야기를 한대로 producer flow control 을 비활성화 했는지 확인한다. 유실되는 큐 메시지를 본다면 systemUsage/systemUsage/memoryUsage 를 Java Max Memory 크기의 70%로 설정을 한다. 수천대의 클라이언트를 지원하거나 대규모 reply queues 를 지원하는 broker 에서는 수기가바이트가 되어야 할 것이다.
    • 다 른 네트워크를 많이 가지고 있거나 널리 분산된 sites를 가지고 있는 경우에는 각 지역에 subcollectives를 만든다. p145 “Localizing Traffic”에서 이에 대해 설명을 한다. 필요하다면 전체 collective 에 요청을 할 수도 있지만 이것이 기본은 아니다.  If you have many distinct networks or widely dispersed sites, create subcollectives for each location or region, as discussed in  on page 145. You can still initiate requests to the entire collective when necessary, but it shouldn’t be your default.

    몇천대의 서버 지원하기

    ActiveMQ 브로커에서 몇천의 연결을 처리하려면 노드의 TCP stack을 튜닝해야 한다. 저자와 다른 사람들이 발견혔던 유용한 몇가지 추천사항이 있다. 리눅스가 아닌 시스템에서 적절한 튜닝 지점을 찾아야 할 것이다.

    # More file descriptors == more open TCP connections

    ulimit -Hn 8192

    ulimit -Sn 8192

     

    # Close and reuse finished TCP sessions faster

    /sbin/sysctl -w net.ipv4.tcp_fin_timeout=15

    /sbin/sysctl -w net.ipv4.tcp_tw_reuse=1

     

    # Identify failed TCP links faster

    /sbin/sysctl -w net.ipv4.tcp_keepalive_time=300

    /sbin/sysctl -w net.ipv4.tcp_keepalive_intvl=30

    /sbin/sysctl -w net.ipv4.tcp_keepalive_probes=5

     

    # Allow connection backlog of 2000 connections

    # Required as STOMP clients reconnect quickly

    /sbin/sysctl -w net.core.somaxconn=2000

    /sbin/sysctl -w net.core.netdev_max_backlog=2000

     

    # Increase size of TCP read and write buffers

    /sbin/sysctl -w net.core.rmem_default=256960

    /sbin/sysctl -w net.core.rmem_max=5242880

    /sbin/sysctl -w net.core.wmem_default=256960

    /sbin/sysctl -w net.core.wmem_max=5242880

     

    # Disable timestamps

    /sbin/sysctl -w net.ipv4.tcp_timestamps=0

    각 플랫폼별로 적절한 파일에 저장을 하여 영구적으로 사용을 할 수 있도록 해야 한다. 리눅스에서는 ulimit 변경은 /etc/security/limits.conf 에 저장을 하고 sysctl 변경은 /etc/sysctl.conf 파일이다.

    중 요한 변경 중 하나는 discovery timeout 값을 변경하는 것이다. 2,000-3,000 노드 이상의 큰 규모라면 (브로커간의 지연시간에 의존하는) discovery 는 기본값인 2초보다는 더 걸린다. 5,500 노드를 가진 실환경에서 discovery 가 모든 노드에서 지속적으로 응답을 받으려면 10초가 필요하다는 것을 발견하였다.

    client apps 에서 discovery timeout(Part III에서 논의함) 를 늘릴수 있도록 하거나 모든 CLI 명령에서 타이핑을 하지 않도록 환경 변수를 설정한다.

    $ export MCOLLECTIVE_EXTRA_OPTS="--discovery-timeout 10 --timeout 5"

    클라이언트에게 모든 노드가 로컬이면 timeout for requests 를 동일한 크기로 늘릴 필요는 없다.(question)  Discovery 는 requests timeout 의 두배는 되어야 한다. As you can see, we did not need to extend the timeout for requests to the same length when all nodes were local to the client. Discovery needed to have twice the timeout as the requests themselves.

    글로벌하게 분산된 서버에 대한 고려 사항

    첫 번째로 고려를 할 수 있는 것은 지연시간이 큰 대륙강의 링크인 상황과 같이 글로벌하게 분산된 브로커를 고려한다면, 각 지역별로 다른 collectives 를 사용하여 가능한한 트래픽을 로컬에서 처리하는 방식이 있다. local collectives 로 노드를 분리하고 로컬 collective에 대부분의 메시지를 보내면 cross-site 네트워크 트래픽은 현저히 줄어들 것이다. 12장에서 설명을 한다.

    두번째로 생각할 수 있는 것은 broker links 를 가능하다면 start 설정으로 하거나 modified start 설정으로 하는 것이다. 당신은 클라이언트와 서버 사이에 hops(요청을 처리해야 하는 브로커의 수)을 최소화하기를 원할 것이다. 이렇게 하면 reply 의 지연시간을 줄일 수 있으며 timeout 에 처하는 상황을 줄일 수 있다. (내용은 이해가 안 감..)

    대규모 네트워크에서 timeout는 언제나 피할 수 있는 것이 아니다. 대륙간의 네트워크는 브로커 사이에 높은 지연시간을 만들 수 밖에 없다. 이러한 요청사항에 따라서 처리를 해야 한다:

    • 튜닝 가능한 하나의 옵션은 discovery timeout 이다. 7개의 글로벌 사이트를 가진 실환경에서 모든 노드에서 응답을 받는 discovery 에 5초가 필요했었다.
    • 또 하나의 튜닝 가능한 옵션은 request timeout 이다. 같은 환경에서 최소한의 적절한 request timeout 은 동일한 숫자였다.

    커맨드라인 애플리케이션에서 다음과 같이 환경변수를 설정할 수 있다.

    $ export MCOLLECTIVE_EXTRA_OPTS="--discovery-timeout 5 --timeout 5"

    custom client 애플리케이션에서는 application 자체에서 timeouts을 설정할 수 있으며 Part III 에서 설명을 한다.

    ActiveMQ 5.9.1 로 업그레이드하기

    ActiveMQ 5.8 에 비하면 5.9 가 대량의 SSL/TLS 클라이언트를 처리하는데 훨씬 더 좋았다.

    원 래 ActiveMQ는 작은 숫자의 연결된 노드를 위해 개발이 되었다. ActiveMQ 사용이 많아지면서 기본 connector 는 대규모의 클라이언트를 처리하지 못했다. 새로운 connector 는 Java Non-blocking I/O (NIO) 라이브러리에 기반하여 새로 만들어 졌다. 이 connector 를 Active 5.8 에서도 사용 가능하지만 SSL 연결은 처리를 하지 못했다.

    저자의 경험에 의하면 표준 stomp+ssl connector 는 500 active 연결이 넘으면 실패하기 시작한다. 대부분의 TCP 연결은 되지만 STOMP negotiatin 은 성공을 하지 못한다.

    ActiveMQ 5.9 는 stomp+nio+ssl connect를 제공하며 대규모의 SSL 클라이언트를 처리할 수 있다.

    알려진 문제점 확인하기

    이책을 쓸 당시 다음과 같은 문제점들이 있었음. 자세한 내용은 책 참고.

    • The ActiveMQ connector does not close TCP sessions when it fails to complete an SSL connection
    • ActiveMQ 5.8.0 has only a half-second tolerance for heartbeat failures
    • No more than 500 SSL/TLS connections per broker

    ActiveMQ 5.9.1로 업그레이드를 하면 STOPM+NIO+SSL (https://activemq.apache.org/configuring-transports.html) 를 transport 로 사용할 수 있다.

    결론

    • 가능한한 많은 메모리를 Java engine 에 사용하고 borker 의 크기도 이에 맞춤. 브로커는 오직 필요한 메모리만 사용을 할 것임
    • oepn files 의 숫자를 늘리고 네트워크 연결을 위한 read, write 버퍼를 늘린다. sysctls 이용.
    • 대규모 클러스터나 지역적으로 분산된 사이트에서는 트래픽을 분리하기 위해 여러개의 collectives를 사용함.
    • 수백대 이상의 서버에서 TLS 인증을 사용하려면 SSL-enabled NIO connector를 사용하기 위해 ActiveMQ 5.9.1 로 업그레이드를 한다.
    • 서버와 클라이언트간에 메시지가 전달될 브로커 숫자를 제한하기 위해서는 start 또는 modified start  설정을 사용한다.
    • 설정상의 잘못은 서버나 클라이언트를 작동하지 않게 하기도 하고 연결을 시도하려고 한다. 미들웨어 호스트에서 IP 주소당 열린 커넥션 숫자를 확인하고 잘못 설정된 노드를 찾아내야 한다.
    • 모든 서버가 클라이언트에 응답을 전달하기 위해 필요한 discovery, request timeouts 를 늘여야 한다.

    network of brokers 가 성장함에 따라 최고의 성능을 내기 위해서는 주의깊게 튜닝 작업이 필요하다. 여기서 설명한 튜닝 작업은 MCollective 와 연관이 되는 부분들로 제한이 된다. ActiveMQ connectors 를 튜닝하는 대부분의 문서는 network of borkers 의 성능에 관련이 있다.

    11. Middleware Security

    이번 장에서는 미들웨어 커넥션을 안전하게 하기 위한 두가지 방법을 설명할 것이다. 이 두가지 옵션은 Transparort Layer Security(TLS)를 사용하며 TLS 는 Secure Sockets Layer(SSL)의 강화된 버전이다.

    미 들웨어 보안 옵션은 브로커에 연결하는 부분을 제어한다.  어떠한 큐와 토픽에 대해서 노드가 읽고 쓸 수 있는지는 P103의 "Authentication and Authorization"에서 설명한 authorizationEntry 설정에서 제어를 한다.

    MCollective 는 자체적으로 authorization 시스템을 가지고 있으며 어떤 Mcollectiev 요청이 어떤 서버에 적용할 수 있는지는 p163의 "Authorization"에서 설명을 한다.

    미들웨어 시큐리티는 오직 노드가 브로커에 연결할 수 있는지 없는지, 통신에 암호화를 할 것인지 말것인지를 제어한다.

    TLS 는 pre-arranged symmetric key 를 가지고 암호화해서 트래픽을 보호한다. 이 키는 쌍방간의 트래픽을 암호화 할 때 사용한다. 각 사이드의 TLS 연결은 각 사이드의 X.509 인증서를 통해서 검증을 할  수 있다. 이러한 asymmetric cryptography 은 데이터를 보내기 전에 서로 통신을 하기에 적절한지 를 확인한다.

    은 행 웹사이트에 접근을 할 때 브라우저는 웹사이트가 정말로 은행 사이트인지를 검증하기 위해 암호화 확인을 한다. 브라우저에서 확인할 수 있고 신뢰할 수 있는 authority 에 의해 사인된 은행의 공개 키(X.509 인증서)를 가지고 있는지를 확인한다.

    은 행 웹사이트에서는 일반적으로 현재 쓰고 있는 브라우저에서 당신이 누구인지를 증명하기 위해 인증서를 제공하는 것은 필요로 하지 않지만 이것은 적절한 TLS 설정이다. username 과 비밀번호 대신에 TLS 암호화에 의해서 보호가 되었는지만 의존을 한다.

    TLS 암호화를 하기 원한다면 다음의 설정을 이해하는 것이 필요하다:

    • Anonymous TLS : MCollective 노드와 미들웨어 간에 암호화를 하는 간단한 방법을 제공. 웹 클라이언트가 안전한 웹사이트에 접근할때와 같이 클라이언트가 적절한 TLS 인증서를 가지고 있을 필요는 없다. secure session 이 설정이 되고 end-to-end 암호화를 통해 연결에 사용하는 사용자 이름과 비밀번호를 보호한다. (Figure 11-1).

    Figure 11-1. TLS encryption without client TLS certificates

    • CA-Verified TLS : 암호화된 전송 뿐만 아니라 MCollectiev 노드와 미들웨어 간에 암호화된 인증을 지원한다. 모든 MCollective 노드는 미들웨어에 접근하기 위해 미리 사인된 TLS 인증서를 가지고 있어야 한다. 이러한 설정을 통해서 미들웨어에 대한 보안을 강화한다. (Figure 11-2).

    Figure 11-2. TLS encryption with bidirectional TLS certificate verification

      • CA-Verified TLS 를 활성화 하기 위해서는 두가지 부분이 있다. trusted server 와 trusted clients 이다.

    어떻게 두가지 옵션을 설명하는지 확인을 해보자.

    Anonymous TLS

    장점

    단점

    Puppet Module Setup

    이 책에서 제공하는 Puppet module을 쓴다면 다음과 같이 설정을 하면 된다.

    hiera 를 이용할 경우

    또는 puppet manifests 에서 수정을 할 경우

    수동 설정하기

    테스팅

    CA-Verified TLS Servers

    MCollective 노드와 미들웨어 간에 TLS 키와 인증서로 암호화된 통신을 하는 방법이다.

    장점

    단점

    Setup Paths

    TLS using Puppet CA

    Puppet 모듈을 이용할 경우 다음과 같이 구성을 함.

    또는

    TLS using Another CA

    keyStore 와 trustStore 검증하기

    CA-Verified TLS Clients

    각 클라이언트 요청은 연결을 하기 위해서 자신의 인증서을 가지고 있어야 한다. 가장 일반적인 방법은 각 사용자별로 각자의 인증서를 만드는 것이다. 각 팀별로 인증서를 생성해서 오직 해당 팀만 private key 에 접근 할수 있도록 하는게 좋겠다. 이 방법 외에 다른 방법을 찾을 수도 있을 것이다. 어찌되었든 검증하고자 하는 유일한 entity 별로 TLS 인증서를 만들어야 한다.

    Clients of the Puppet CA

    클라이언트 인증서를 생성하는 방법 중 한가지는 Puppet master 에서 인증서를 생성하여 원하는 시스템으로 복사하는 방법이다. 그렇지만 이렇게 하려면 각 사용자는 Puppet master 에 root 권한이 필요하다.

    Create a Puppet keypair on the client node

    저자는 특정 로그인 사용자에 대하여 다음과 같이 작업을 하는 것이 쉽다는 것을 발견하였다. (해당 사용자의 private key 는 다른 사람에게 노출이 되면 안된다)

    Puppet Master 의 관리자 권한으로 다음과 같이 해당 사용자에 대한 인증서를 사인한다.

    사용자는 다음와 같은 명령을 실행하여 자신만의 key, cert 와 CA를 가질 수 있다.

    이 러한 에러는 적절한 반응이다. --no-daemonize --no-client 옵션은 Puppet 이 실행되는 것을 방지하기 위해서 필요하다. 이러한 옵션을 제공하지 않으면, Puppet aget 는 기본 catalog 로 실행을 하려고 할 것이다. 일반 사용자로 로그인을 했다면 문제를 일으키지는 않겠지만 이러한 상황을 피하는 것이 좋을 것이다.

    Change the client configuration

    클 라이언트가 자신의 키를 쓰도록 하기 위해 개인적인 설정 파일을 만들어야 한다. MCollective 클라이언트에서 찾는 기본 파일 이름은 사용자 홈 디렉토리의 .mcollective 이다. 명령어 라인에서 -c config 옵션을 통해서 다른 설정 파일을 지정할 수도 있다.

    각 사용자의 ~/.mcollective 에 다음을 설정한다.

    만 략 Puppet 으로 관리하는 시스템에 root 권한으로 접근을 할 수 있는 사용자가 있다면 그 사용자는 해당 노드의 Puppet 인증서로 미들웨어에 접근이 가능할 것이다. 왜냐하면 동일한 Puppet CA에 의해서 사인을 한 적절한 인증서 이기 때문이다. 그래서 MCollective 의 authorization 이 매우 중요한 이유이다.

    나는 이것이 보안 문제라고 생각하지 않는다. 어떤 노드가 pupet 환경에 있다면 미들웨어에 접근할 수 있도록 허용하는 것이 맞을 것이다. If users have root access, then the server login to the middleware is visible to them anyway. 그래서 client 패스워드와 permissions 가 다른지를 확인하는 것은 매우 중요한 부분이다.

    Clients Using Another CA

    Change the Client Configuration

    결론

    ActiveMQ 브로커에 연결하는 노드를 안전하게 보호하는 방법은 두가지가 있다.

    • Anonymous TLS 암호화는 암호화된 키를 만들기 위해 오직 서버 인증서만 사용한다. 이것은 웹사이트에서 사용하는 방식이며 구현이 간단한다.
    • CA-Verified TLS 암호화는  쌍방향 authentication 을 제공하는 것으로 동일한 CA 로 사인을 한 각자의 인증서에 따라서 서로를 확인한다. 이경우 모든 서버와 클라이언트를 위해 단일한 키와 인증서로 사인을 하는 것이 필요하다.

    이러한 두가지 방법을 통해 네트워크를 통해서 정보가 스니핑 당하지 않도록 로그인 정보와 MCollective 정보를 보호할 수 있다.

    12. Creating Collectives

    collective 는 요청 트래핑을 그룹으로 묶을 때 사용하는 ActiveMQ topic 과 queue 세트이다. 규모가 작을 때는 단일 collective 를 사용하면 된다. 이 책에 사용했던 것은 기본값인 mcollective 였다.

    다음의 이유로 여러 개의 collective 를 만들기 원할 수 있다.

    • 대규모 클러스터 또는 sites 간에 트래픽을 제한하는데 Collectives 사용
    • client 접근을 제약하기 위해 노드를 그룹으로 묶는데 Collectives 사용

    언제 여러 개의 collective 생성할지 결정하기

    현재의 네트워크에서 여러 개의 collectives를 구현하기 원하는 경우:

    • 천대 이상의 서버를 가지고 있음
    • 지연시간이 긴 여러 지역에서 서버를 운영
    • 여러 지역에서 서버를 운영하고 있고 그 사이에 네트워크 트래픽을 줄이고 싶을 때
    • 로컬 관리자는 로컬 호스트를 관리하도록 허용을 하되 글로벌 팀은 모든 호스트를 관리할 수 있도록 허용할 때

    여러 개의 collectives 를 구성할 필요가 없는 경우:

    • 미 들웨어 셋업에서 fault tolerance를 원하는 경우 : Collectives 는 fault tolerance를 제공하지 않는다. fault tolerance 는 network of brokers 나 master/slave 셋업을 해야 하며 p113 "ActiveMQ Clusters"에서 설명을 했다. Collectives 는 각 사이트의 로컬에 있는 브로커에 트래픽을 제한하는 경우 효율적인 방법이다.
    • authorization 제어에 여러가지 다양한 것을 필요로 하는 경우 : 클라이언트가 서버에 접근하는 것을 제한하기 위해 특정 collectives를 제약할 수 있지만 이것이 일반적인 authorization 메커니즘은 아니다. p163 의 "Authorization"을 이용할 것을 권장한다.
    • 서로 다른 Puppet domains 을 가지고 있는 경우 : Puppet 과 MCollective 는 둘이 함께 작동을 할 수 있지만 Puppet domain 이 같을 필요는 없다. 많은 Puppet domans 에 단일한 MCollective를 쓸 수 있다.

    지금의 목록에서 답변을 찾을 수 없는 경우 collective를 어떻게 만드는지 살펴보자.

    Collectives != Clustering

    먼저 이해해야 할 것은 collectives 는 ActiveMQ 클러스터와는 다르다는 것이다.

    collective 는 네트워크 트래픽을 분리하기 위해 사용하는 ActiveMQ topics 와 queues 의 세트이다. ActiveMQ 클러스터는 토픽과 큐 세트에 fault tolerance 를 제공한다. 단일 ActiveMQ 브로커에 수백개의 collectives 를 운영하는 것은 가능하며 이를 통해서 zero fault tolerance를 제공할 수 있다. 마찬가지로 단일 collective 에 더 강력한 fault tolerance 와 고성능을 위해서 여러 개의 ActiveMQ 브로커를 사용하는 것도 가능하다.

    대부분의 환경에서는 다음과 같은 구성을 한다.

    • A master/slave pair of brokers : 모든 collectives 에 단일 site redundancy 제공  A master/slave pair of brokers that support all collectives for single-site redundancy

    • 각 지역에 하나의 ActiveMQ brokers 를 가진 network of brokers 를 구성하며 모든 collectives를 이 site에서 처리함. A network of brokers with one ActiveMQ broker in each location which hosts all collectives at that site
    • 각 지역에 여러개의 ActiveMQ 브로커를 가진 network of brokers 를 구성 A network of brokers with multiple ActiveMQ brokers in each location
    • 이 세가지 옵션을 조합.

    p113 의 "ActiveMQ Clusters"에서 클러스터 설정에 대한 예제를 보여주었다. 이러한 것들이 다른 점을 깨닫는 것이 중요하다. The collective is a message path configured on top of network of brokers.

    If you are familiar with the OSI model for networking, it is not entirely accurate but easiest to think of clustering as Layer 4 and collectives as Layer 6. This reflects how the collective is an application-specific path that relies on the transport layer.

    정확한 것은 아니지만 클러스터링으로 Layer 4, collectives를 Layer 6으로 생각하면 쉽다. collective는 transport layer 에 의존하는 application-specific 경로이다.

    Traffic 설정

    다음은 client 에서 collectives 를 정의하는 설정이다.

    각 서버에서는 오직 연관된 로컬 collectives를 설정해야 한다.

    collectives 구성에 대한 정보를 조회할 수 있다. collective 구조를 DOT 파일로 보내서 Graphviz, ZGRViewer, 등의 프로그램에서 읽을 수 있다.

    특정 서버가 어느 collectives 에 속해 있는지 조회를 할 수도 있다.

    요청을 보낼 때 target 를 지정하여 요청을 소규모 collective 로 제한할 수도 있다. target 을 저정하지 않으면 , 요청은 client.cfg 파일에 정의된 main_collective 파라미터에 있는 collective 로 보내진다.

    오직 asia collective 에 있는 노드만이 응답을 할 것이다.

    Localizing Traffic

    미 들웨어에서는 리스닝하고 있는 것을 아는 노드에만 트래픽을 보낸다. 이 부분은 topc subsciption 메커니즘이 작동하고 있기 때문이다. 오직 다섯 대의 시스템에서 Puppet plugin 을 로드했으면 (또한 collective.puppet.agent topic 에 가입되어 있음) 오직 다섯 대의 시스템에서만 Puppet client plugin 의 요청을 받을 것이다. 이와같이 해당 collective 의 모든 시스템이 특정 브로커에 연결되면 미들웨어 브로커는 해당 topic 이나 queue 에 가입하지 않은 브로커에게는 collective의 메시지를 복사하지 않을 것이다. 이렇게 해서 sites 간에 트래픽 양을 매우 많이 줄일 수 있다.

    이러한 이점을 위해서, collectives 를 다음과 같이 설계하자:

    • registration 과 다른 글로벌 메시지에 가입한 모든 호스트를 위한 하나의 collective 사용 (예 mcollective)
    • 각 물리적인 지역이나 인프라스트럭쳐 영역에 대해 하나의 collective 추가. 그 이름은 간단하게 국가, 도시 또는 공항 코드 등으로 하기 원할 것이다.

    새로운 collective 이름을 위한 동일한 클라이언트와 서버 로그인을 허용할 수 있도록 미들웨어를 설정하자.

    해당 영역에 대해 서버를 설정한다.

    그러고나서 클라이언트가 모든 로컬 사이트를 가지도록 설정한다.

    이렇게 설정을 하면 관리자는 오직 특정 sites 에만 명령을 보내거나 요청의 타겟에 따라 모든 호스트에 명령을 보낼 수 있다.

    접근 제약하기

    여러 개의 collectives 를 쓰는 또다른 이유는 각 사이트에 대해서 로컬 관리 팀에만 접근을 허용을 하는 경우이다. 이러한 장점을 위해 다음과 같이 collectives 를 설계한다:

    • registration 과 다른 글로벌 메시지에 가입한 모든 호스트를 위한 하나의 collective 사용 (예 mcollective)
    • 구분되는 클라이언트 세트를 통해 관리를 할 각 서버를 위한 하나의 collective 추가
    • 모든 collective 는 접근을 위해 유일한 그룹 이름을 가지도록 함.

    불 행히도 이렇게 설정을 변경하려면 서로 다른 그룹 숫자에 따라 설정이 늘어날 것이다. 각 그룹의 관리자는 유일한 클라이언트 로그인과 유일한 그룹명이 필요하다. 다음의 예에서는 admnistrators 와 delvelopers 를 사용하는 두 그룹 시스템을 보여줄 것이다. delvelopers 는 오직 자신의 collective 에서만 작업을 할 수 있다. 글로벌 관리자는 모든 collective 에서 작업할 수 있는 클라이언트 로그인을 가지고 있다.

    이렇게 하면 메인 클라이언트 로그인은 모든 collectives 에 글로벌하게 접근할 수 있지만 새롭게 만든 로그인은 자신만의 collectives 에만 메시지를 주고 받을 수 있다.

    서버에서는 다음과 같이 제한된 collectives를 설정한다:

    클라이언트에서는 로컬 collective 를 자신의 main (기본) collective로 가진다.

    이렇게 설정을 한 경우 dev 관리자는 dev 시스템에만 요청을 할 수가 있지만 글로벌 관리자 (username 과 password에 client 계정을 가진 관리자)은 모든 호스트에 접근할 수 있다.

    결론

    여 러 개의 collectives 를 가지면 서로 다른 레벨에서 확장성을 처리하는데 도움이 된다. 대부분의 상황에서는 확장성에 문제가 있거나 각 그룹(고객, 개발팀 등)에게 제한된 접근을 허용하는 경우가 아니라면 기본 collective로 충분하다.

    이번 장에서 설명한 기능을 이해하는 것은 좋지만 필요성이 있을 때까지는 여러 개의 collectives 를 쓰는 것을 권장하지 않는다.

    13. Mcollective Security (Clients and Servers)

    MCollective는 매우 짧은 시간에 많은 변경을 할 수 있는 강력한 툴이다. 강력한 기능을 가지고 있기 때문에 해당 프로그램을 잘못 사용할 때의 위험은 커진다. 이번 장에서는 이러한 위험을 줄일 수 있는지, 어떤 사용자가 해당 서버에 대해 작업을 하는 것을 어떻게 제허할 수 있는지 설명할 것이다.

    현재의 상황에서 MCollective 셋텁은 단순한 보안 모델을 사용하고 있다. 이보다는 더 많은 보안 모델을 원할 수 있다. 다음은 다른 보안 플러그인을 사용하려는 이유를 설명한다:

    • Security(authentication) plugin : 현재의 설정은 컨텐츠에 대한 MD5 hash를 만드는 Pre-Shared Key 를 사용한다. 이것을 이용하여 서버는 plain-text 요청이 변경되지 않았다는 것을 확인한다. 이보다 더 강한 암호화 확인을 원할 수 있다.
    • Authorization plugin : 당시은 어떤 요청을 할 수 있거나 없을 수 있다. 특정 클라이언트가 특정 호스트 또는 특정 요청을 할 수 있는지 제한하는 보안 모델을 원할 수 있다.
    • Auditing plugin : 기본 로그 파일은 누가 특정 요청을 했는지에 대해 자세한 정보를 보여주지 않는다. 허용이나 거부된 요청과 누가 그 요청을 했는지 등 더 자세한 로그를 원할 수 있다.

    MCollective 는 보안을 위한 plugin 아키텍쳐를 가지고 있기 때문에 이러한 상황을 개선하기 위해서 유연성을 찾을 수 있다. MCollective 를 위한 보안을 강화하는 방법에 정답은 없다. 대신에 자신의 필요성에 따라서 보안을 강화할 수 있다. 이번 장에서는 보안을 강화하기 위한 옵션들을 살펴볼 것이다.

    이번 장에서는 클라이언트(요청을 보냄)와 서버(요청을 검증함) 사이의 authentication 과 authorization을 살펴볼 것이다. 이 부분은 미들웨어 전송과 관련한 보안에는 영향을 미치지 않는다.

    보안은 플러그인을 통해서 제공이 되기 때문에 각 조직이나 각 collective 는 서로 다른 보안 모델을 사용할 수 있다. 우리는 MCollective 에서 사용 가능한 보안 플러그인을 비교할 것이다.

    MCollective documentation refers to the authentication plugin as the security plugin. I don’t prefer this term, as there are distinct authorization and auditing plugins that are part of most people’s concept of security. I refer to it as the authentication plugin in this section for clarity, but the reader should be aware that the configuration files and Puppet Labs documentation refer to it as the security plugin.

    Authentication 작동 방식

    명령을 collective 로 보낼 때 클라이언트는 요청에 caller identification 을 내장하여 보낸다. 다음과 같이 작동을 한다.

    1. 사용자는 "mco puppet runone" 와 같은 요청을 만든다.
    2. 클라이언트 authentication/security plugin 은 caller 를 설정하고 명령의 메타데이터에 추가한다.
    3. client 는 미들웨어에 요청을 publish 한다.
    4. 서버의 authentication/security plugin은 는 메시지의 digest 를 검증한다.
    5. server authorization plugin 은 caller 가 이 요청에 대해 허가(authorized)가 있는지 검증을 한다.
    6.  서버는 요청을 처리한다.

    우 리가 이미 사용을 하였던 Pre-Shared Key 플러그인은 caller 의 요청에 Unix uid 나 gid를 추가한다.  모든 클라이언트 시스템이 정확히 동일한 uid/gid 매킹을 가지고 있지 않고 local root 도 아니면 이 시나리오에서는 caller 정보는 신뢰를 할 수 없다. 당신이 알 수 있는 것은 오직 클라이언트가 정확한 Pre-Shared Key를 가지고 있다는 사실이다. 이것만으로 당신의 환경에서 충분한가?

    더 세부적인 접근 통제를 위해 SSL, AES 또는 SSHKey security plugins을 원할 수 있다. 이러한 각각의 플러그인은 caller 의 identity 를 검증하기 위한 암호화된 공개키를 사용한다.

    Pre-Shared Key Authentication

    설명 생략

    Figure 13-1. The data is passed in the clear with an MD5 hash of the contents and the Pre-Shared Key

     

    Figure 13-2. The data and a MD5 hash of the contents and the Pre-Shared Key are both encrypted during transit

    Puppet Setup

    SSL Authentication

    SSL security plugin 을 사용하면 각 클라이언트가 보내는 명령에는 유일한 개인키와 공개키가 있어야 한다. 모든 서버는 동일한 공개키와 개인키를 공유할 것이다. 이렇게 하면 각 클라이언트 요청은 암호화가 된다. 이러한 보안 모델에서는 다음과 같이 구성이 된다:

    • 모든 서버는 단일한 public/private keypair 를 공유한다.
    • 각 클라이언트는 서버 public key를 가지고 있어야 한다.
    • 각 클라이언트는 자신의 private key 로 각 요청을 사인해야 한다.
    • 각 서버는 요청을 검증하기 위해서 클라이언트의 public key를 가지고 있어야 한다.

    이러한 설정에서 클라이언트는 다음과 같이 작동을 한다:

    1. Insert a caller field comprised of the client certificate’s filename into the request

    2. Serialize the message body, the message time, and the time-to-live

    3. Insert a hash field containing a cryptographic signature of the serialized data

    Figure 13-3. The data is passed in the clear with a SSL-signed hash of the contents

    서버에서 메시지를 받을 때, 클라이언트의 public key를 이용하여 signature 를 검증하고 메시지가 적절한 caller 에서 왔는지 message time과 time-tolive 가 변경되지 않았는지 확인을 한다.

    이것을 미들웨어의 TLS 암호화와 결합을 하면 암화화된 터널(TLS 에서 제공)과 클라이언트 요청에 대한 암호화 검증을 함께 사용할 수 있다. 이것이 Puppet Lab의 추천 사항이다.

     

    Figure 13-4. The data and a SSL-signed hash of the contents are encrypted by TLS

    Server Configuration

    SSL security 모델을 쓰면 server의 개인키와 공개키는 동일하고 모든 서버에서 공유가 된다. 다음과 같이 서버 keypair 를 만들 수 있다:

    이 파일들을 mcollective 디렉토리로 옮기고 안전하게 보호한다.:

    이 키들을 사용하기 위해서 server.cfg 에 설정된 PSK plugin 설정을 제거하고 다음을 추가한다:

    Puppet 으로 설치하고 동기화하기

    이 책의 Puppet module을 쓰고 있다면 다음 명령어를 통해서 이 키들을 Puppet module 디렉토리로 옮긴다. Puppet 모듈은 자동으로 모든 서버에 해당 키를 배포할 것이다:

    다음의 Hiera 설정은 server.cfg 에서 이에 해당하는 설정을 활성화한다:

    Client Configuration

    각 클라이언트는 자신의 요청을 검증하기 위해 공개키와 개인키가 필요하다. 가장 일반적인 방법은 자신만의 공개키와 개인키를 만들고 절대로 다른 곳에는 공유하지 않는 것이다.

    다 른 방법은 각 팀마다 인증서를 만들고 오직 해당 팀만 개인키에 접근 할 수 있도록 하는 것이다. 중요한 것은 어떤 것을 허가하고 audit 할 것인가 하는 것이다. 그룹키를 공유해서 인증을 사용한다면 어떤 사용자가 요청을 했는지 알 수가 없다.

    개인키는 안전하게 보관을 해야 하고 인가되지 않는 다른 사용자에게 공유가 되면 안된다. 공개키는 모든 MCollective 서버에 배포가 되어야 하며 이 키를 이용하여 요청을 사인할 때 사용한다.

    Create a client identity

    클라이언트 키를 저장할 디렉토리를 먼저 생성하자:

    Trusted TLS connector 를 위해서 이미 Puppet 키를 생성했다면 그것을 다음과 같이 재사용할 수 있다:

    아래는 다른 방법으로 인증서를 생성하는 방법이기 때문에 설명은 생략.

    If you created a new identity with a different CA from “CA-Verified TLS Clients” on page 139, you may have everything except the public key. Create that now using these steps:

    If you don’t have an existing keypair, you can generate a client keypair using Puppet as described in “CA-Verified TLS Clients” on page 139, or you can create a new key‐pair using openssl :

    Create a config file

    각 클라이언트는 유일한 키 세트가 필요하기 때문에 각 keypair 마다 별도의 설정 파일을 만들어야 한다. 오직 한 사용자(개인 데스트탑이나 랩탑)만 사용하는 시스템이라면 다음의 내용을 글로벌 client 설정파일인 /etc/mcollective/client.cfg 에 추가할 수 있다. 그게 아니라면 아래 라인을 각 유저의 개별 클라이언트 설정으로 추가해야 한다.

    클라이언트 설정에 대해서 처음으로 체크하는 파일은 각 사용자의 홈 디렉토리의 .mcollective 이다. 이 파일이 존재하면 글로벌 클라이언트 설정은 무시가 된다. 설정 파일은 전체 내용을 담고 있어야 하고 완전히 필요한 설정이 들어가 있어야 한다.:

    This defies the standard Unix/Linux convention, where dot-program would be a directory containing configuration files specific to the program. A prevailing convention for a directory containing files for MCollective is .mcollective.d. We used this directory when creating the public and private key files earlier.

    SSL 인증을 활성화하기 위해서 securityprovider 라인을 변경해야 한다. psk 나 다른 security connecotr 를 가리키는 설정은 제거를 해야 한다. 클라이언트는 the hash for server 를 암호화하기 때문에 클라이언트 설정에서는 서버의 공유를 한 공개키를 가리키는 설정이 있어야 한다. 변경 사용은 다음과 같다:

    또 다른 방법은 쉘 환경에서 각 사용자에 대한 키 위치에 대해서 지정을 하는 것이다:

    export MCOLLECTIVE_SSL_PRIVATE=/home/user/.mcollective.d/private_keys/user.pem

    export MCOLLECTIVE_SSL_PUBLIC=/home/user/.mcollective.d/public_keys/user.pem

    이 책의 GitHub 레포에서 mcollective::userconfig 라고 된 Puppet class가 있다. 이 모듈을 통해서 자동으로 각각의 user key pairs 를 만든다. 불행히도 이것만으로는 모든 상황을 다를 수는 없으며 http://bit.ly/1ryhxxe 모듈을 살펴보기 바란다.

    Key Synchronization

    SSL 인증을 위해서는 다음과 같이 세가지 동기화 이슈를 처리해야 한다:

    • 모든 서버는 동일한 공개키와 개인키를 가지고 있어야 한다.
    • 모든 서버는 모든 클라이언트의 공개키를 가지고 있어야 한다.
    • 모든 클라이언트는 공유된 서버의 공개키를 가지고 있어야 한다.

    Puppet 모듈은 이러한 세가지동기화 이슈를 처리할 수 있다. 다음과 같이 파일을 위치하면 된다:

    Type

    Puppet server 에서의 경로

    Server Private Key

    modulepath/mcollective/files/ssl/server/private.pem

    Server Public Key

    modulepath/mcollective/files/ssl/server/public.pem

    Client Public Keys

    modulepath/mcollective/files/ssl/clients

    Puppet 모듈을 사용하지 않으면 다음과 같이 하면 된다:

    • The client public keys to each server’s /etc/mcollective/ssl/clients/ folder
    • The server public key to each client as /etc/mcollective/ssl/server/public.pem:

    RSA Authentication AES Encryption

    설명 생략

    Server Configuration

    Client Configuration

    Key Synchronization

    SSHKey Authentication

    설명 생략

    Puppet

    Authorization

    이 번 섹션에서는 authorization(권한 부여)에 대해서 다룬다. authorization 는 어떠한 요청을 MCollective 서버에서 처리하기전에 마지막으로 하는 체크이다. authorization 은 강력하면서도 유연한 MCollective 보안을 제공한다. authorization 은 MCollective 가 제공하는 기능중 가장 사용하지 않고 간과하는 부분이라고 생각을 한다.

    우리가 이전에 작업을 했던 것은 authentication 에 기반하여 누가 요청을 보낼 수 있는지만 제한을 한다. 정확한 비밀번호, pre-shared key, 사인한 인증서가 있는 사람이라면 어느 시스템에 아무 요청이나 할 수 있다. 이것은 제한 없는 강력한 힘을 가지고 있다.

    작은 환경에서는 괜찮다. 그렇지만 여러 팀이 있고 다양한 많은 시스템이 있으며 다양한 agent plugin 을 가지고 있다면 어떤 사용자가 어떤 리소스를 사용할 수 있는지 제한하고 싶을 것이다. authorization 플러그인을 사용하면 특정 사용자, 특정 호스트, 특정 agent 등을 제한할 수 있다.

    authorization 은 authentication 에서 선택한 것에 따라 의존성이 있다. authorization 플러그인은 security (authentication) 플러그인을 통해서 검증한 caller 와 request 정보를 사용하고 해당 요청을 허용할지 말지를 결정한다.

    authorization 정책을 내릴 때 조심해야 한다. You should ensure you have another method to log in to each server to fix any mistake or a safety-net policy that will allow you to regain access.

    한 명 이상의 관리자가 있는 환경에서 배포를 할 때, 모든 서버를 위해 ActionPolicy authorization 플러그인을 배포할 것을 권장한다.  ActionPolicy 는 각 agent 별로 정책 룰을 사용할 수 있다. 그래서 agent 기반으로 허용이나 거부할 수 있는 유연성을 제공한다.

    Rule Format

    ActionPolicy 룰의 포맷은 다음 필드에 따라 탭으로 구분한다:

    필드#이름설명
    1

    Policy

    allow 또는 deny 
    2Caller요청에서 제공한 The caller 문자

    * (always matches)

    One Caller string (discussed in the next section)

    3Action

    An action provided by the agent the policy rule is for

    * (always matches)

    A space-separated list of actions

    4FactsFacts that must be true about the target server

    * (always matches)

    A space-separated list of fact=value pairs (matches if every

    listed fact matches)

    Any valid compound filter string

    5ClassesPuppet classes that apply to the target server

    Absent or * (always matches)

    A space-separated list of class names (matches if every listed

    class is present)

    Any valid compound filter string

    다른 파일 포맷을 사용하는 authorization policy 를 만들어서 자체 영역에 기반하여 authorization을 하는 커스텀 agent 를 만들 수도 있다. 이에 대해서는 Part III에서 다룰 것이다.

    Caller IDs

    어떤 authorization 플러그인을 사용을 하든지 상관없이 요청에서 caller 필드는 사용할 수 있다. 이 필드는 어떤 security provider 플러그인을 사용하는지에 따라 다르게 설정이 된다.

    • PSK security 플러그인 : 클라이언트 애플을 실행하는 user의 uid=uid 를 caller ID로 설정한다.
      • plugin.psk.callertype 에서 gid, user, group 또는 identity 로 변경할 수 있다. uid 와 usernames 은 호스트에 걸쳐서 동일하지 않을 수도 있기 때문에 신뢰할 수 있는 수단은 아니다.
    • TLS security 플러그인 : .pem 확장자 없이 cert=client's public key filename 을 caller ID로 설정한다.
      • 서버는 ssl_client_cert_dir 또는 aes.client_cert_dir 을 검색하여 요청을 검증하기 위한 동일한 이름의 공개키를 찾는다.
    • SSH security 플러그인 : 클라이언트를 실행한 sshkey=username 을 caller ID로 설정한다.
      • 서버는 유저의 authorized_keys를 검색하여 요청을 검증하기 위한 SSH 공개키를 찾는다.

    Defining ActionPolicy with Puppet

    이 책에서 제공한 Puppe 모듈을 통해서 ActivePolicy 모듈을 설치하고 설정할 수 있다. Puppet 에서 정책을 정의하는 방법은 두가지가 있다:

    • Hieara 데이터에서 동적으로 룰 생성
    • 정적인 정책 파일을 배포

    이 두가지를 섞어서 쓸 수도 있다. 어떤 정책은 정적인 파일에 두고 어떤 설정은 Hiera 에 둔다.

    Creating a simple policy in Hiera

    다음은 간단한 ActionPolicy 설정으로 다른 요청은 모두 거부하고 정책을 업데이트 하기 위해 Puppet 실행만 허용을 하는 예제이다. 설정에서 잘못된 것이 발생하지 않도록 하는 좋은 보안장치이다.

    authorization 을 활성화 했지만 default policy 를 명시하지 않으면 allow_unconfigured 를 활성화한 서버에서는 authorization 이 활성화 되며 기본 allow 정책이 활성화된다:

    mcollective 에서 plugin.actionpolicy.allow_unconfigured = 0 이 기본값이며 no 이다. (문태준 추가)

     

    이 러한 Hiera 정의는 기본 정책으로 "deny"를 가지는 한줄의 default_deny.policy 파일을 생성한다. 이러한 기본 policy 는 해당 agent 에 대해서 정책을 정의하지 않는 모든 agent 에 적용이 된다.

    다음에는 두 라인에 걸쳐 puppet.policy 라는 이름의 정책 파일을 만들 것이다: 기본은 deny 이고 사용자가 runonce와 runall 명령을 사용할 수 있도록 허용한다.

    모든 것이 정확히 지정되었을 때, puppet runonce 와 puppet rullall 명령에 대한 요청만 성공할 것이다. 다른 요청은 실패한다:

    Allowing more commands

    위에서 구현을 한대로, 이 정책은 사용자에게 많은 권한을 허용하지 않는다. 이것을 확장해서 좀 더 실제 상황에 맞는 정책을 만들어 보자.

    각 정책에서, default 속성은 각 agent 에 대한 기본 정책을 정의한다. 해당 agent 에 대해 정책 파일에서 지정하지 않는 부분은 여기에서 정의한 내용에 따라 허용 또는 거부당할 수 있다.

    각 룰에는 유일한 title 이 필요하다. title 은 숫자로 시작하며 실행을 할 때 순서를 제어한다. MCollective 모듈은 파일의 title을 해당 룰을 정의하는 곳의 상단에 주석으로 저장한다. 이렇게 해서 정책 파일을 읽고 이해할 수 있도록 돕는다.

    title 다음에 정의할 키/값의 dictionary 가 있다.

    • policy action
    • authentication plugin에서 제공하는 유요한 사용자나 key(certname 등)
    • 허용할 agent actions
    • 룰에 적용 가능한 facts
    • 룰에 적용 가능한 Classes

    여 기에 기초해 각 agent 별로 정책을 만들어보자. 예를 들어 다음의 정책은 대부분의 정책은 허용을 하지만 admins 만 files 또는 Puppet agent 를 disable 하는 것을 허용한다. callerid 는 callertype을 group 으로 설정한 PSK security provider 로 가정을 한다.

    다음은 SSL key 가 jane.doe 인 어떤 개발자에게 development 박스에서 서비스에 접근할 수 있도록 설정을 한다. callerid 는 SSL 또는 AES security provider 라고 가정을 한다:

    특정 룰이 없는 특정 agenet 에 대하여 모든 요청을 허용하거나 거부하려면 간단하게 룰을 정의할 수 있다. 예를 들어 다음은 서버의 패키지에 대하여 어떤 사용자도 제어를 할 수 있도록 설정한다:

    이와 비슷하게 글로벌 기본은 allow 로 설정을 하고 하나의 agent 에 대한 모든 요청은 거부하도록 설정할 수 있다. 예를 들면 다음은 shell command 만 제외하고 모든 것을 허용하는 설정이다.

    Distributing policy files

    Hiera 를 사용하지 않는다면, Puppet 모듈을 이용하여 정책 파일을 배포할 수 있다.

    특 정 agent 에 대한 설정을 수동으로 하려면 정책 파일을 만들어서 Puppet module 의 files/policies/ 디렉토리에 두면 된다. 이 디렉토리에서 예제 정책을 찾을 수 있다. 이 디렉토리는 mcollective::serer class를 통해서 모든 노드에 동기화가 된다.

    각 파일은 기본 정책만 제외하고 agentname.policy 로 이름을 만들어야 하며 .policy 로 파일이름이 끝나야 한다.  기본 정책은 authorization_default_policy class 나 Hiear 파라미터를 통해서 다음과 같이 설정을 한다:

    이렇게 설정을 하면 기본 룰은 default_deny.policy 로 파일 이름이 생긴다.  authorization 을 활성화 했지만 default policy 를 명시하지 않으면 allow_unconfigured 를 활성화한 서버에서는 authorization 이 활성화 되며 기본 allow 정책이 활성화된다

    allow_psk_root.policy_example 은 간단한 기본 정책을 보여준다. (allow_psk_root.policy_example 은 puppet module 의 files/policies/ 에 있는 파일을 말함) 여기서는 클라이언트 시스템의 root를 제외한 다른 사람의 요청은 모두 거부한다. 자신의 데스크탑에서 root 로 될 수 있기 때문에 안전하지는 않지만 기능만을 보여주는 것이다. Puppet module 의 files/policies 디렉토리에 여러가지 다른 예제들이 있다.

    새 로운 정책을 만들었을 때 문제가 생기는 것을 Puppet 으로 고치려면 files/policies/puppet.policy_example 파일의 첫번째 룰을 포함할 것을 추천한다. 여기서는 authorization 셋업을 고치기 위해서 클라이언트에서 Puppet 을 실행하는 것을 허용하는 Puppet 정책을 설정한다. 테스팅을 하고나서 위험이 있다고 생각하면 비활성화한다.

    Defining ActionPolicy Manually

    ActionPolicy agent (http://bit.ly/1rdgJf8) 를 다운로드 받고 p25 "Installing from Source" 의 문서대로 설치를 한다. 그러고나서 각 server.cfg 파일에 다음 내용을 추가한다.

    각 agent 에 대하여 기본 정책 파일과 정책 파일을 만든다.  정책 파일을 각 서버의 /etc/mcollective/policies/ 디릭토리에 설치한다.

    다음은 예제용 service 정책 파일이다:

    각 agent 별로 다르게 정책을 만들 수 있다. 파일 이름은 agentname.policy 이며 동일한 디렉토리에 설치한다. 이 디렉토리는 모든 서버에 동기화가 되어야 한다.

    기본 정책을 활성화하면, 특정 정책을 설정하지 않는 모든 agent 에 적용이 된다. 기본 정책이 없고 allow_unconfigured 가 활성화(기본값임)되어 있으면 해당 agent 에 대한 모든 요청은 거부될 것이다.

    Auditing

    이 시점에 MCollective 는 짧은 시간에 몇천대의 서버에 변경을 할 수 있는 강력한 툴이라는 것을 실감했을 것이다. 각 서버에서 처리된 요청에 대해서 어떻게 로그를 남기는지 확인해야 한다.

    auditing 요청을 위한 자신만의 플러그인을 만들 수도 있다. (20장에서 설명) 그렇지만 MCollective 는 필요에 따라 맞추어서 사용할 수 있는 기본 audit 플러그인이 있다. 기본 audit 플러그인은 각 서버에서 받는 모든 요청 사항, 해당 요청을 허용했는지 거부했는지 등을 디스크의 로그파일에 기록할 수 있다.

    server 설정 파일에서 다음과 같이 활성화를 한다.

    main MCollective 로그와 다르게 이 플러그인은 로그파일 로테이션 기능을 지원하지 않는다. logrotaet 를 설정하거나 이 부분을 다루어야 한다.

    이 책의 Puppet module을 이용한다면 다음과 같이 class 파라미터를 설정하 로그파일과 로그로테이트 스크립트를 설정할 수 있다.

    누가 요청을 보냈는지 남는 로그의 값은 p163 "Authorization"에서 설명을 한대로 어떤 security provider 를 썼는지에 따라서 다르다. 다음은 client identity 가 geode 인 경구의 로그를 보여준다.

    audit 로그은 authentication 이나 authorization 실패에 대한 정보는 담고 있지 않다. 이러한 정보는 mail logfile 인 mcollective.log 에서 DEBUG 로그레벨로 정보를 수집할 수 있다.

    결론

    이번 장에서는 활성화하거나 커스터마이징할 수 있는 세가지 타입의 security plugins 를 설명하였다.

    • Security (authentication) plugin :  PSK, SSL, AES 또는 SSHKey security plugin 을 선택할 수 있으며 요청자에 대한 authentication 을 제공함.

    • Authorization plugin : ActionPolicy plugin 은 사용자가 어떤 요청을 서버에 보낼 수 있는지 제한을 함

    • Auditing plugin : LogFile plugin 을 통해 디스크에 처리한 모든 요청을 상세하게 기록할 수 있음

    MCollective의 플러그인 구조는 자신의 필요성에 따라 MCollective 환경을 설정할 수 있는 유연성을 부여한다.

    14. Challenges of Worldwide Parallelism

    MCollective는 작은 규모의 랩에서 전세계에 걸친 글로벌 엔터프라이즈 기업까지 모든 환경에서 오케스트레이션을 위한 강력한 툴울 제공한다. 저자는 200 이상의 글로벌 사이트를 운영하는 회사, 중앙 site 에서 6,000 대 이상의 서버를 관리하고 몇백개의 원격 데이터 센터를 가진 회사 등을 도왔다고 언급하고 있다. MCollective 의 기능은 병렬적이지 않은 환경에서도 사용할 수 있다.

    MCollective는 기본 설정으로 작은 규모에서 바로 작동을 할 것이다. 대규모 환경에서는 서버와 브로커 설정에서 각종 튜닝 작업이 필요하다. DB서버, 파일 서버, 또는 다른 주요 인프라 서비스와 같이 확장성을 위해서는 튜닝 작업이 필요하다.

    튜닝하기 원하는 설정 옵션에 대하여 알아보자.

    • 미들웨어를 보호하기 위해 적절한 암호화 레벨 선택
    • authentication 과 authorization 을 위해 필요에 맞는 security 플러그인 선택
    • 특정 서버와 agent 에 대한 접근을 제한하기 위해 authorization 정의
    • 여러 sites 나 고가용성을 위해 network of brokers 또는 master/slave redundancy 설정
    • WAN 이나 확장성을 위해서 미들웨어 브로커와 서버를 튜닝하기

    Part III에서는 자신만의 커스텀 플러그인을 만들 수 있고 23장과 22장에서는 자신이 직접 만든 글로벌 인프라의 장점을 찾을 수 있을 것이다.

    시간이 지날 수도록 MCollectie 없이는 지내기 힘들다는 것을 알게 될 것이다.

    Part III. Custom Plugins

    이 번 파트에서는 커스텅 플러그인을 만들고 테스팅하고 사용하는 법을 다룰 것이다. 처음으로 할일은 커스텀 agent 와 client 를 만드는 것이다. 5장에서 이야기를 한대로 agent 는 서버 차원의 기능을 구현하는 것이고 client는 요청을 생성할 수 있다.

    다음을 설명할 것이다:

    • 서버에 적용할 수 있는 새로운 , 커스터마이징된 요청 만들기 (agent 만들기)
    • mco 명령어 라인 대신 스크립트를 이용하여 MCollectie 요청 만들기
    • 서버로부터 registration 정보 수집하기
    • 화면에 출력하는 대신에 MCollective 요청 결과를 다른 프로그램으로 보내기 (리스너 생성)

    15장부터 22장까지는 개발과 연관된 부분으로 필요한 경우 책을 보고 개발 작업을 하면 됨.

    샘플 예제는 https://github.com/jorhett/learning-mcollective/tree/master/examples 에서 볼 수 있음.

    99. Custom Plugins 정리

    15장-22장을 문태준 개인적으로 정리를 한 것임. 실제 예제는 책의 내용을 참고 할 것.

    Learning MCollective에서 Custom Plugins 만드는 방법 정리함.

    https://github.com/jorhett/learning-mcollective/tree/master/examples/thanks 에서 소스 참고하면 됨.

    agent 만들기

    http://docs.puppetlabs.com/mcollective/simplerpc/index.html

    http://docs.puppetlabs.com/mcollective/simplerpc/agents.html

    http://docs.puppetlabs.com/mcollective/simplerpc/agents.html 에서 예제로 나온 echo agent 는 "mco rpc echo echo msg='test'" 로 해서 실행을 할 수 있다.

    mco plugin generate agent 명령을 이용하여 기본 템플릿을 만들 수 있음. 

    thanks.rb, thanks.ddl 을 다음과 같이 편집을 함.

    agent 설치하기. 해당 패키지를 만들기 위해서는 사전에 해당 OS에 맞는 프로그램을 설치해야 하며 CENTOS의 경우  rpm-build rpm을 설치하면 됨. 새로운 agent 를 설치하고 나서는 mcollective 를 재시작 해야 함.

    rpm 으로 설치한 경우 파일이 /usr/libexec/mcollective/mcollective/agent 디렉토리에 복사가 된다. 테스팅을 하는 경우에는 이 디렉토리에서 직접 테스팅을 하고 mcolletive를 재시작한 후 테스팅을 할 수도 있다.

     

    agent 테스팅하기 : Learning MCollective 에서는 인자를 줄때  --person="jack"  로 되어 있지만 --는 없어야 함.

    입력값을 검증하기 때문에 문자와 space만으로 시작한 문자만 허용 가능하도록 되어 있다. person은 지정하지 않은 경우에는 기본값이 나온다.

     위 에서 delicacy 에 대한 값은 /etc/mcollective/server.cfg 나 /etc/mcollective/plugin.d/thanks.cfg 등에서 불러오도록 변경을 할 수도 있음. 이에 대한 부분은 Learning Mcollective 15장 참고.

    person 을 입력하지 않아도 실행은 잘 됨. 이 부분은 다음 두가지와 연관이 있다고 함.

    • "We aren't yet using an application to enforce data input"
    • The DDL provides a default value.

    만약 thanks.ddl 에서 기본값을 제거하면 다음과 같이 나올 것이다.

    외부 스크립트 실행하기

    https://github.com/puppetlabs/marionette-collective/tree/master/ext/action_helpers/python/kwilczynski 예제 참고.

    https://github.com/puppetlabs/marionette-collective/tree/master/ext/action_helpers 에서 python, perl, php 예제 스크립트를 볼 수 있음.

    다른 외부 스크립트를 실행하여 그 결과를 받을 수도 있으며 결과를 JSON 포맷으로 쓸 수 있으면 된다. 이 스크립트를 reply를 JSON hash 로 쓸 수 있으면 된다. resturn code는 책 p187 참고.

    echo.ddl

    echo.rb https://github.com/puppetlabs/marionette-collective/tree/master/ext/action_helpers/python/kwilczynski 파일을 다운로드 받아 py 파일에 실행권한을 주고 실행하도록 하였음.

    실행결과

    아래는 처음 만들었던 thanks.rb 에서 특정 명령을 실행하도록 변경한 것이다.

    다음과 같이 facts 같은 값을 가져올 수 도 있다. agent, class 등도 가져올 수 있다.

    Client Application 만들기

    thanks/agents 에 agent를 만들었다면 thanks/application 디렉토리를 만들고 여기에 thnaks.rb client Applicatoin을 만들면 된다.

    이제 rpm package 로 만들고 rpm을 이용하여 설치를 하면 된다.

    Standalone Client 만들기

    실행하기

     

    세가지 실행 방법 차이. mco rpc 이용, thanks client app 이용, 직접 작성한 스크립트 이용.

    agent 를 만들고 mco rpc 이용하면 따로 스크립트나 client app을 만들지 않아도 실행을 할 수 있다. 그렇지만 자주 사용하는 명령어라면 client app을 만들어서 쓰는 것이 편할 것이고 프로그램에서 이용을 할 것이라면 직접 작성한 스크립트를 만들어서 쓰면 될 것이다.

    Collecting Responses

    MCollective 가 가진 기능 중 유용한 것중의 하나는 클라이언트에서 요청을 보내고 다른 클라이언트나 리스너에서 응답을 하여 처리할 수 있는 부분이다.

    Figure 22-1. A separate listener to process results from requests

    https://github.com/jorhett/learning-mcollective/blob/master/examples/listen/debugger.rb

    위소스를 /usr/libexec/mcollective/mcollective/listener 디렉토리로 복사를 한다. 그러고 나서 특정 큐에서 응답하도록 요청을 보낸다.

    요청보내기

    debugger.rb 실행하기

    이렇게 데이터를 받아서 필요한 다른 처리를 할 수가 있다. DBMS에 집어넣기, 파일로 저장하기, REST API를 이용하는 다른 시스템에 전송 등.

    15. Buillding an Agent

    16. Extending the Agent

    17. Creating a Client Application

    18. Processing Multiple Actions

    19. Making a Standalone Client

    20. Creating Other Plugins

    21. Processing Registration Data

    22. Collectiong Responses

    23. Running Mcollective Without Root

    MCollective 서버를 일반 사용자 계정으로 돌리는 것은 가능하고 또한 추천을 한다. 패키지안에 들어있는 init 스크립트는 이 상황을 처리하지 못할 것이며 일부 agent는 root 권한이 없으면 해당 작업을 할 수 없는 경우도 있다. 그렇지만 다른 사용자 ID로 실행하는 애플리케이션을 관리하는 커스텀 agent를 가지고 있다면 모든 작업이 해당 사용자로 돌아갈 수 있도록 하는 좋은 방법이다.

    특정 사용자용 MCollective 서버를 만드는 것은 쉽다:

    이 러한 mcollectived 서버는 root로 돌아가는 중앙 서버가 있는 동일한 노드에서 별 어려움없이 실행을 할 수 있다. 동일한 노드에서 root 가 아닌 mcollective 서버를 몇십개에서 몇백개 안전하게 만들 수 있다.

    하지만 여기의 예제는 모든 가능한 시나리오를 다룰 수는 없다:

    • 사용자별로 시작을 할 수 있는 스타트업 스크립트를 만들어야 함
    • authentication 에 사용할 사용자별 SSL key(설정한 security provider 에 따라 달라짐)를 가리키는 설정파일은 수동으로 편집를 해야 함.

    이러한 방법을 통해서 각 계정별로 적절한 작업을 할 수 있도록 사용자별로 제한을 할 수 있다.  저자는 가능한한 root 가 아닌 MCollective 대몬을 사용한다.

    24. Downloading the Code

    이 책의 gibhut repo 에서 샘플 :  https://github.com/jorhett/learning-mcollective

    the thanks agent and application : https://github.com/jorhett/learning-mcollective/tree/master/examples/thanks

    the registration agent and processor : https://github.com/jorhett/learning-mcollective/tree/master/examples/registration

    the debugger response collector  : https://github.com/jorhett/learning-mcollective/tree/master/examples/listen

    여기 있는 코드들은 여러 사이트에서 실제 쓰고 있는 것들이다. 문제를 발견한다면 저자의 Github repository에 이슈를 만든다.

    Part IV. Putting It All Together

    25. Use Best Practies

    MCollective 를 어떻게 만들지 추천 사항임.

    Configuratoin Management 를 사용

    Configuratoin Management 를 사용할 것을 추천. 대규모 서버를 관리할 때 설정 관리 프로그램 없이 사용을 하려면 힘듬. 자세한 설명은 생략.

    각 자의 상황에 따라 Puppet, Chef 등을 사용하자. 문제가 생긴 MCollectiev 서버를 설정 관리 프로그램으로 고칠 수 있고 문제가 생긴 설정 관리 agent 를 MCollective 로 고칠 수 있다. 이 두가지 툴을 함께 사용하면 좋다.

    최적의 Discovery 방법을 선택

    Mcollective 가 요구사항에 맞지 않다고 가장 많이 불평을 한 것들은 discovery 에 브로드캐스트를 사용한 것이다. 오래된 MCollective 버전은 오직 mc 브로드캐스트 방법만 지원을 했었다. 서버가 오프라인이면 요청이 새로 생겼어도 discovery 에 응답을 할 수 없고 요청을 처리할 수도 없다.

    MCollective 는 다양한 데이터를 수용하기 위한 discovery 플러그인을 개선하기 위해 노력을 하였다. 일반 파일, PuppetDB, Chef, Foreman, MongoDB, RiakDB, 그리고 Elasticsearch 등에서 서버 목록을 필터링할 수 있는 여러 플러그인들이 있다.

    discovery 플러그인과 관련해서는 당신의 요청에 맞는 적절한 discovery 플러그인을 사용해야 한다.

    collective 에서 모든 노드에 대해 동일한 connector와 동일한 security 플러그인을 사용할 수 있다. 그렇지만 각 요청마다 다른 discovery 플러그인을 사용할 수 있다. 요청에 맞는 적절한 discovery 플러그인을 선택하자.

    간단한 예로, 대부분의 경우 온라인이고 현재 동작중인 노드에만 요청을 하고 싶을 것이다. 샌프란시스코 클러스터의 모든 노드만 apache를 재시작하고 싶다면, 노드가 현재 오프라인인 것은 신경을 쓸 필요 없다. 이때 요청을 처리하기 위해 나는 mc (기본값임) discovery 플러그인을 사용할 것이다:

    그 러나, 클러스터에 있는 모든 노드의 apache를 내리기 원할 경우  오프라인에 있던 어떤 노드가 온라인으로 바뀌자 마다 메시지를 받도록 하고 싶을 것이다. 이럴 경우 다음과 같은 명령으로 사용을 했다. 모든 알려진 서버에 명령을 보내고 정말로 긴 timeout 을 사용한다:

    필요하다면, 응답하지 않는 노드에 대한 정보를 담은 새로운 목록을 만들어서 명령을 다시 실행하도록 래퍼를 만들 수 있다.

    github 에서 discovery 플러그인을 찾을 수 있다.  https://github.com/search?q=mcollective+discovery&ref=cmdform

    Authorize and Audit Each Request

    MCollective 배포시 보안에 대한 부분은 security(authentication), authorization, 그리고 auditing 플러그인에 의지한다. 이들 각각은 필요한 기능을 제공한다:

    • 리소스를 막을 수 이는 적절한 미들웨어 보안 모델 선택. 신뢰하지 않는 네트워크에서 정보를 전송한다면 언제나 암호화를 사용해야 한다. Puppet 을 사용한다면 간단한 설정 변경으로 TLS 암호화를 활성화할 수 있다.
    • security (authentication) 플러그인은 authorization 과 auditing 플러그인에서 검증할 수 있는 caller 정보를 제공한다. authentication 을 빈약하게 하면 보안 문제가 생길 수 있다. A poor choice of authentication mechanisms will reinforce the well-known garbage in, garbage out phenomenon.
    • SSL, AES, SSHKey security 플러그인을 이용한 접근 제어를 사용하자. 이러한 플러그인들은 caller 의 신분을 검증하기 위해 암호화된 공개키를 사용한다.
    • 강 한 authentication을 멈추지 말자. 각 요청에 대해 authentication(권한 제어)를 하지 않으면서 강한 authentication을 쓰는 것은 의미가 없는 일이다. 어떤 사람의 신분증을 확인하고 그 사람이 올수 있는 곳에 당신의 지갑을 두는 것과 비슷하다.
    • authorization 에서 아무것도 넣지 않는 것보다는 명확한 "allow any" 정책이 더 좋다. 이렇게 해야 새로운 authorization 룰을 추가할 때도 룰을 조정하기가 쉽다.
    • 언제나 MCollective 요청을 audit 해야 한다. audit 데이터는 인증로그나 sudo log를 보호하는 것과 같이 백업을 해야 한다.
    • 보안은 플러그인을 통해서 제공을 하기 때문에 각 조직이나 host 의 각 collective는 요구사항에 맞는 서로 다른 보안 모델을 사용할 수 있다.

    MCollective의 보안을 위한 플러그인 구조는 실제 구현을 할 때 유연성을 준다. MCollective의 보안을 강화하는 정답은 없다. 대신에 당신의 필요에 맞게 동작을 하도록 해야 한다.

     

    26. Grow Your Deployment

    이 책의 Puppet 모듈을 통해서 바로 MCollective를 설치하여 조회하고 파일, 패키지, 서비스 등의 변경을 할 수 있다. github 에서 유용한 많은 플러그인을 찾을 수 있다. 그렇지만 가장 가치가 있는 것은 각자의 환경에 필요한 기능을 구현한 플러그인을 만드는 작업이다.

    Consider the Strings Analogy

    각자의 환경에서 적절한 것을 어떻게 찾을지의 질문임.

    어디에서 제어 손잡이를 찾을 수 있을까 : 해당 기능을 제공하는 커스텀 agent 만들기

    더 많은 정보를 원할 때 : 커스텀 agent 를 만들어서 요청에 질의하도록 할 수 있다. 또는 정보를 주기적으로 제공하는 registration 플러그인을 만들어서 리스너가 그 정보를 수집하고 처리하도록 할 수 있다.

    이 슈요청하는 dashboard를 원할 때 : 어떤 애플리케이션 클라이언트 명령을 날릴 수 있다. MCollective::RPC 라이브러리를 포함하는 ruby 스크립트를 실행하는 것은 간단하다. 그렇지만 클라이언트를 통해서 미들웨어 브로커에 적절히 형식화된 요청을 날릴 수 있다.

    이벤트가 발생했을 때 정보를 받기늘 원하는가? : MCollective agent는 클라이언트에서 요청을 기다릴 필요가 없다. 노드에서 이벤트에 응답하는 agent를 만들고 데이터를 클라이언트 리스너에 보낼 수 있다. agent는 간단하고 리스터는 입력에 따라 정해진 작업을 하기 때문에 좀 더 복잡한 프로그램이다. 이렇게 해서 self-healing 인프라를 만들 수 있다.

    기술 지원 활용하기

    MCollective를 계속 사용하면서 지원을 받을 수 있는 방법이다.

    • #mcollective channel on Freenode (http://bit.ly/1nwbxPK) : 오픈소스 MCollectie 에 대한 지원을 받은 있는 IRC 채널임. Puppet Lab 엔지니어, 다른 개발자, MCollectie 사용자 등이 이 채널을 통해 지원을 할 수 있다. 설정 파일과 로그을 Gist 또는 Pastebin 같은 서비스를 이용하여 제공하면 도움이 될 것이다.
    • mcollective-users@googlegroups.com (http://bit.ly/1nwbzHA) : Puppe Lab에서 제공하는 오픈소스 MCollective를 위한 메일링리스트. 복잡한 질문이나 세부적인 것에 대해서 지원을 받을 수 있는 채널이다. Puppet Lab 엔지니어와 다른 MCollective 개발자가 배포와 개발 이슈 등에 대해 논의를 하는 메일링리스트이다.
    • Puppet Enterprise (http://puppetlabs.com/puppet/puppet-enterprise) : Puppet Lab에서 제공하는 상업 제품이 Puppet Enterprise 이며 여기에는 MCollective 와 기술지원이 포함되어 있다. Service-level agreement 에 따라 상업적인 지원이 필요한 경우 가장 좋은 방법이다. 이 책에서 배운 모든 것은 Puppet Enterprise 에도 적용 가능하다. 그렇지만 기본 설정 파일 경로는 /opt/puppet 이다.

    이 책의 저자 또한 IRC 채널, 메일링리스트 등을 통해서 다른 사람을 도울 것이다.

    이 책에서 잘못된 점이 있으면 http://oreilly.com/catalog/errata.csp?isbn=0636920032472 에 제출을 하면 된다.

    블로그 읽기

    다음의 블로그가 유용하다.

    • R.I. Pienaar (MCollective 를 처음 만든 개발자)

    http://www.devco.net/ and https://twitter.com/ripienaar

    •  Richard Clamp (one of the most active committers on MCollective and a helpful voice on #mcollective)

    http://richardc.unixbeard.net/ and https://twitter.com/richardclamp

    • Peter Loubser (the other active committer on MCollective and another helpful voice on #mcollective)

    https://twitter.com/pieterloubser
    • Jo Rhett (이 책의 저자)
    http://www.netconsonance.com/ and https://twitter.com/jorhett

    다음 url에서 MCollective 에 대한 플러그인, 팁 등의 정보를 얻을 수 있다. http://www.netconsonance.com/tag/mcollective

    Take the String Now

    설명 생략.

    A. Tips and Tools

    유용한 명령어 레퍼런스

    mco cli 예제 : http://docs.puppetlabs.com/mcollective/reference/basic/basic_cli_usage.html

    책의 예제에 몇가지 자주 사용하는 명령어를 추가 하였음.

     

    MCollective 서버에 대한 모든 설정 정보 보여주기:

    facts 정보 보기

    Discovery (mc broadcast based discovery plugin, flatfile, stdin discovery plugin)

    필터

    limits (–one, --limit, % 옵션 / batch, batch-sleep 옵션)

    Output

     

    MCollectiev 서버나 목록에서 연결 테스팅하기:

    호스트 서비스에 대한 테스팅 명령 ( nettest agent):

     

    파일을 제어하기 위한 명령어 ( filemgr agent):

    패키지 제어 명령어 (package agent): 책의 예제가 잘못되어 바꾸었음.

    시스템 서비스 제어 명령(service agent):

    Puppet agent 제어 명령:

    기타 : nrpe를 이용하려면 nrpe 를 설치해야 함. process, urltest 등은 별도로 설치가 필요함.

    Puppet Modules 을 설치하기 위해 r10k 사용하기

    r10k 는 Puppet environments 와 모듈을 빠르게 배포할 수 있는 프로그램입니다.현재 r10k는 ruby 1.9.3, 2.0.0, 2.1.0 을 지원합니다. CentOS6 의 경우는 ruby 1.8 이 설치되어 있습니다. https://github.com/puppetlabs/r10k 

    이경우 r10k 의 이전 버전을 설치하면 ruby 1.8 에서도 사용이 가능합니다.

    그래서 CentOS6 에 rvm 을 설치하여 다른 ruby 버전을 이용할 수 있지만 여기서는 CentOS 6 + ruby 1.8 에 r10k 1.5.1 을 설치합니다.

    r10k를 설치하기 위해서는 부가적으로 ruby-devel, gcc 등이 필요할 수 있습니다.

    ruby 1.8 에서 r10k 1.5.1 을 설치후 실행하려고 하면 system_timer 관련 에러가 나오며 gem을 통해서 system_timer 를 설치해주면 됩니다.

    책이나  https://github.com/jorhett/learning-mcollective 에 있는 r10k 파일은 인터넷에 파일이 없다고 나옵니다.

    그래서 위 url에 들어있는 r10k.yaml 이용하되 git@github.com 을 https 로 바꾸어서 r10k를 실행했습니다. 그러면 /etc/puppet//environments/learning_mcollective/ 디렉토리에 puppet module 이 복사가 됩니다.

    이제 /etc/puppet/environments/learning_mcollective/hieradata/ 디렉토리에 가서 hierdata 를 수정해서 사용하면 됩니다.

    PuppetLabs MCollective Module 사용하기

    Puppet Forge 에서 MCollectie 모듈을 제공하지만 다음의 이유로 PuppetLabs의 MCollective module을 추천하지 않음. 주로 보안 이슈임.

    세부 내용 설명 생략

    • 알려진 user와 passwords를 사용함.
    • client 와 server permissions을 구분하지 않고 있음. 동일한 인증을 사용하면 보안 문제가 생김.
    • client 퍼미션과 broker link 퍼미션을 구분하지 않고 있음
    • Puppet Labs 모듈은 외부 의존성이 있음.

    RabbitMQ 이용하여 mcollective 구성하기

    이미 RabbitMQ를 이용하거나 AMQP 지원이 필요하면(예, logstash), MCollective 미들웨어로 ActievMQ대신 RabbitMQ를 사용할 수도 있다.

    RabbitMQ 설치

    http://www.rabbitmq.com/install-rpm.html 정보를 이용하여 설치함. RabbitMQ는 빠르게 발전하고 있으며 최신 버전은 MCollective와 동작을 잘 한다.

    1. 해당 OS에 대한 erlang 설치. CentOS의 경우 epel을 통해서 설치 가능함.
    2. RabbitMQ 설치

    CentOS에서는 다음과 같이 설치를 한다. 버전은 문서를 보고 적절한 것을 선택한다.

     

    STOMP connector 와 management plugins 를 활성화하고 rabbitmq를 시작함.

     

    CLI tool 설치

    새로 설치한 RabbitMQ 브로커에서 CLI 툴을 다운로드 받아 설치함. rabbitmqadmin 에 대한 bash completion 기능을 활성화하고 있음.

     

    Puppet module 에서 RabbitMQ 설정하기

     

    여기서는 hiera 설정을 이용하여 변경을 하였음.

     

    Mcollective를 위한 큐, 토픽 등 설정하기

     

    password은 Mcollectve 에서 사용하기로 한 비밀번호와 동일하게 맞추어야 함.

    아래에서 exchange 에 대한 설정에서 여러 개의 collective 가 있으면 이에 대해서도 함께 설정을 해 주어야 함. 여기서는 mcollectie 하나만 사용하는 것으로 가정하고 진행을 했음.

     

    Using and Exchange with a RabbitMQ Federation

    설명 생략

    B. OS Specifics

    Debina/Ubunt 방화벽 설정하기

    FreeBSD, Mac OS X, Solaris, Windows 등에 대해 설명

    RVM 소개 있음.

    C. 문태준 추가한 내용

    Learning Mcollective 책의 내용을 이용하여 제작한 Puppet module

    https://github.com/jorhett/puppet-mcollective 모듈을 fork 하여 https://github.com/taejoonmoon/puppet-mcollective 에 모듈을 만들었음.

    vagrant 에서 테스팅을 할 경우는 아래와 같이 하면 https://github.com/taejoonmoon/puppet-mcollective 모듈을 이용하여 설치를 함. 기본은 activemq로 되어 있음

    ActiveMQ 이용하여 mcollective 설정하기

    • https://github.com/taejoonmoon/puppet-mcollective 모듈을 이용할 경우 작업해야 할 부분임. activemq 기준임
    • SSL middleware security (Learning Mcollective 127 page)
      • 노드에서 브로커에 접속할 수 있는지, 암호화된 통신을 하는지를 제어함.

      • 현재는 Anonymous TLS 가 아닌 CA-Verified TLS 설정을 하여 암호화된 user/password + Cerfiticate 체크를 함께 하도록 구성을 하였음.

      • CA는 따로 구성하지 않고 Puppet CA를 이용함.

      • CA-Verified TLS Clients 세팅하기 P140

      • Create a Puppet keypair on the client node : mcollective client 를 설치한 해당 user로 명령어 실행함. 아래에서는 mcollective client 에서 Puppet CA를 이용하여 vagrant user 의 인증서를 요청함

      • Puppet CA 에서 해당 user 에 대해서 sign을 함. (Puppet CA 서버에서 인증을 해야 함)

      • Puppet CA 서버에서 /var/lib/puppet/ssl/ca/signed/vagrant.pem 파일을 mcollect client 를 설치한 서버의 /home/vagrant/.puppet/ssl/certs 로 자동 복사를 함. PuppetCA서버에서 해당 파일을 수동으로 복사할 필요는 없음

    • mcollective security ((Learning Mcollective 153 page)
      • Pre-Shared key authentication 은 사용하지 않고 SSL Authentication을 사용함. data 와 SSL-signed hash 가 TLS를 통해 암호화되어 통신을 하도록 구성을 함.

      • 아래에서는 SSL Authentication 설정하는 방법입니다.

      • p154 openssl로 private.pem, public.pem 만들어서 아래 puppet module 에 두면 mcollective 서버의 /etc/mcollective/ssl/server/ 에 복사를 함. 초기에 한번만 하면 됨.

      • Client 설정을 위해서는 client key 에 대한 디렉토리 설정을 client user 의 .mcollective.d 에 함. mcollective/manifests/userconfig.pp 를 통해서 자동으로 설정을 하며 수동으로 하지 않아도 됩니다.

      • client user 의 public_key 는 mcollective 서버의 /etc/mcollective/ssl/clients에 배포가 되어야 하며 puppet 모듈의 /etc/puppet/modules/mcollective/files/ssl/clients/ 디렉토리에 복사를 하면 배포를 할 수 있음.

      • modules/profiles/manifests/mcollective_client.pp 에 해당 user 를 추가해 주면 해당 user 의 home directory 에 .mcollective 파일이 생깁니다. 이제 해당 user 로 mco ping 등 명령어를 테스팅 해 보면 됩니다.

      • 이렇게 작업을 하고 나서는 puppet 을 실행해야 합니다.
      • 이렇게 구성을 한 경우 다음과 같이 설정이 됩니다.
        • 모든 server는 동일한 public, private key를 가짐

        • 모든 server는 모든 client 의 public key를 가짐

        • 모든 client 는 서버의 공유 public ey를 가짐.

    주의사항

    위 에서 만든 vagrant 이미지로 실행을 했을 때 ssl 부문에 문제가 있는 듯 하다. ssl 을 사용하지 않고 security_provider 로 psk 를 사용하면 일단 작동은 한다. 예전에는 작동을 했을 건데 재확인이 필요하다.

    Shell agent

    Agent , Client 플러그인 설치 관련해서는 아래 url 을 참고한다.

    http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/InstalingPlugins

    아래 shell agent 는 "Learning Mcollective"  의 p48 을 참고하여 작업을 했다.

     

    각 node 에서는 mcollective server 가 떠 있어야 한다.

    mco 명령을 실행하는 것은 mcollective client 이다.

    그러므로 별도의 Agent 와 Client 플러그인을 설치할 수 있는데 각 node 에는 agent 를, mcollective client(mco를 실행하는 컴퓨터) 에는 client 프로그램을 설치하면 된다.

    mcollective 를 통하여 shell 명령어를 실행할 수도 있다.

    https://github.com/puppetlabs/mcollective-shell-agent : Ruby 1.9 을 필요로 하기 때문에  vagrant demo 에서는 실행이 안된다.

    "Learning Mcollective" 책의 p54를 보면 https://github.com/cegeka/mcollective-shell-agent 를 소개하고 있다.

    github 에서 소스를 가져와서 rpm 패키지를 만들어서 설치할 수가 있다.

    middleware 에서 작업한다고 가정을 하겠다.

    Mcollective 플러그인은 libdir/mcollective 디렉토리 밑에 설치가 된다. agent plugin 은 agent 디렉토리 밑에, client 프로그램은 application 디렉토리에 밑에 설치가 된다.

    위 에서 생성한 rpm 중 mcollective-shell-command-common 은 middleware, node 에 모두 설치하고 mcollective-shell-command-agent 는 node 에 설치, mcollective-shell-command-client 는 middleware 에 설치를 하면 된다. 아래의 예에서는 shell agent 를 middleware 와 node0에만 설치를 한 경우이다.

     

     

    Labels
    • No labels