Tag Archives: 배포

Ansible 시작하기

ansible_logo

머리말

이 글은 Ansible이 설치되어있다고 가정한 상태에서 작성한 글입니다. 아직 설치 전이라면 [Ansible Installation]을 먼저 확인하시어 자신의 OS에 맞게 설치해주시기 바랍니다. 저의 경우에는 CentOS 6환경에서 구동을 하고 있기에 위의 문서를 참고하여 다음과 같은 방법으로 설치를 진행하였습니다.

$ yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ yum install ansible

이 글에서는 Ansible을 시작하기 위한 몇가지 명령에 대해 알아보도록 하겠습니다. 여기서 처음 우리가 하려는것은 Ansible의 강력한 설정/배포/통합 기능이 아닙니다.  이러한 기능은 플레이북의 각각의 섹션에서 다루어지고 있습니다.

이 섹션에서는 초기에 무엇을 해야 하는지를 다룹니다. 이러한 컨셉을 이해한 다음에서는 [Introduction To Ad-Hoc Commands]에서 더 자세한 내용을 다루고 있으므로 읽어보시길 추천해 드립니다. 이후에 플레이북을 통해 가장 관심있는 파트의 내용을 확인하시면 됩니다.

원격 접속 정보

시작하기전에, Ansible이 어떻게 원격지의 서버와 SSH를 통해 통신하는지를 이해하는것이 중요합니다.

기본적으로, Ansible 1.3 혹은 그 이후 버전부터는 네이티브 OpenSSH를 통해서 원격 통신을 하게 됩니다. 이는 ControlPersist (SSH의 퍼포먼스 관련 옵션), Kerberos, 또는 ~/.ssh/config의 Jump Host 를 사용할 수 있습니다. 하지만 Enterprise Linux 6를(RHEL에서 나온 CentOS 포함) 컨트롤 머신으로 사용하게 될 경우 OpenSSH의 버전이 너무 낮아 ControlPersist를 지원하지 않습니다. 이러한 운영체제하에서는 Ansible은 높은 수준의 ‘paramiko’라고 불리는 OpenSSH의 Python 구현체를 대신 사용합니다. 만약 Kerberos가 적용된 SSH 또는 그 이상의 기능을 사용하고 싶다면 Fedora, OS X, 또는 Ubuntu와 같은 최신 버전의 OpenSSH가 적용된 플랫폼을 채택하시기 바랍니다. 또는 가속 모드(Accelerated Mode)를 확인해 보시기 바랍니다.

Ansible 1.2까지는 이 paramiko가 기본적으로 적용되어있습니다. 네이티브 SSH는 -c ssh 옵션을 사용하거나 설정파일에 정의해 줌으로써 명시적으로 사용할 수 있습니다.

가끔 디바이스가 SFTP를 지원하지 않는 경우를 겪을 수 있습니다. 이 경우는 매우 희귀한 경우지만 만약 발생한다면 설정 파일(Configuration file)에서 SCP 모드로 동작하도록 변경할 수 있습니다.

원격 머신과 통신할 때 Ansible은 당신이 기본적으로 SSH 키를 사용하고 있다고 가정하에 동작합니다. SSH키를 사용하는 것이 권장되지만 –ask-pass 옵션을 사용하여 패스워드 인증을 사용하는 것도 가능합니다. 만약 sudo 기능을 사용하고 이때에 비밀번호를 입력할 필요가 있다면 –ask-become-pass 옵션을 이용하여 대응할 수 있습니다.

상식이 될 수 있지만 중요한 부분이라 공유하자면, 관리 시스템은 관리받는 시스템과 가까운곳에 위치하는것이 좋습니다. 만약 Ansible을 클라우드 환경에서 사용한다면 이 머신을 클라우드 안쪽에서 운용할것을 권장합니다. 이렇게 하는것이 바깥의 인터넷 환경에서 사용하는것보다 더 나은 환경을 제공할 수 있습니다.

좀 더 고급 주제로, Ansible은 단순한 방법으로 SSH를 원격 접속하지 않습니다. 전송은 Pluggable Transport를 지원하며 chroot, lxc, jail 컨테이너를 사용하여 관리되는 요소들을 로컬에서 관리합니다. ansible-pull 이라고 불리는 모드를 사용하면 이러한 시스템을 뒤집을 수 있으며 (관리 머신이 Push하는 방식이 아닌) 원격 자원을 필요로 하는 시스템에서 원격 저장소에서 스케쥴링으로 git pull을 동작하도록 할 수 있습니다.

첫번째 명령

Ansible이 설치되어있다면 이제 기본적인것들을 시작해 보도록 하겠습니다.

당신이 관리하고자 하는 하나 또는 다수의 원격 시스템들을 /etc/ansible/hosts 파일에 작성해줍니다. 당신의 공개키가 이 서버들에 ~/.ssh/authorized_keys로 저장이 되어있어야 합니다.

192.168.122.221
192.168.122.222
192.168.122.223

이것을 Inventory 파일이라고 합니다. [Inventory]에서 좀 더 자세한 내용을 확인할 수 있습니다. 만약 당신의 시스템 셋업 상황에 따라 다른 비밀키를 사용해야 한다면 –private-key 옵션을 사용할 수 있습니다.

이제 모든 노드에 핑을 때려보도록 하겠습니다.

$ ansible all -m ping
192.168.122.221 | success >> {
    "changed": false, 
    "ping": "pong"
}

192.168.122.222 | success >> {
    "changed": false, 
    "ping": "pong"
}

192.168.122.223 | success >> {
    "changed": false, 
    "ping": "pong"
}

SSH를 사용할때와 마찬가지로 이제 Ansible은 당신의 현재 유저네임을 이용하여 각각의 머신들에 접속을 시도할 것입니다. 원격지 접속에 사용할 유저네임의 변경을 원할 경우 -u 파라미터를 사용하시면 됩니다.

# eye로 로그인
$ ansible all -m ping -u eye

# eye로 로그인하지만 sudo를 통해 root로 작업을 수행
$ ansible all -m ping -u eye --sudo

# eye로 로그인하지만 sudo를 통해 batman으로 작업을 수행
$ ansible all -m ping -u eye --sudo --sudo-user batman

# 최신의 Ansible은 sudo 파라미터가 deprecated됨. b 파라미터를 사용하여 root로 sudo 수행
$ ansible all -m ping -u eye -b

# eye로 로그인하지만 batman으로 sudo 수행
$ ansible all -m ping -u eye -b --become-user batman

이러한 sudo 실행에 대한 구현은 Ansible의 설정파일에서 당신이 원할 경우 다른 명령으로 변경할 수 있습니다. 실행시에 함께 추가하고 싶은 플래그(예를 들어 -H)도 설정할 수 있습니다.

이제 당신의 모든 노트들에 대해 실시간 명령을 실행할 수 있습니다.

$ ansible all -a "/bin/echo hello"
192.168.122.221 | success | rc=0 >>
hello

192.168.122.222 | success | rc=0 >>
hello

192.168.122.223 | success | rc=0 >>
hello

호스트 키 확인

Ansible 1.2.1 이후 버전부터는 호스트 키 확인 과정이 디폴트로 활성화 됩니다. 만약 호스트가 새로 설치 되었고 known_hosts 파일에 다른 키가 등록된다면 이 문제가 해결될때까지 에러 메시지가 뜨게 될 것입니다. 만약 호스트가known_hosts파일에 등록되지 않은 시점이라면 이 키를 등록할것인지에 대한 확인 프롬프트가 뜨게 될 것입니다. 당신은 이런것을 원치 않을 것입니다.

당신이 이것에 대해 이해를 하고 있고 이런 확인 과정을 비활성화 하길 원한다면 /etc/ansible/ansible.cfg 또는 ~/.ansible.cfg 파일을 수정하여 해결할 수 있습니다.

[defaults]
host_key_checking = False

또는 다음과 같이 환경 변수를 추가하여 피할 수도 있습니다.

$ export ANSIBLE_HOST_KEY_CHECKING=False

또한 paramiko 모드에서 호스트키 확인 과정이 느리게 동작하는 문제가 있으므로 이 기능을 사용할 때는 ssh로 전환할 것을 추천합니다.

Ansible은 동작할때 몇몇 정보들을 원격 서버의 syslog 에 로깅을 할 것입니다. 만약 이것이 필요없을 경우 “no_log: True” 설정을 추가하여 끌 수 있습니다. 이것은 나중에 다시 설명하도록 하겠습니다.

컨트롤 머신의 기본 로깅을 활성화 하기 위해서는 설정파일[Configuration File]의 “log_path” 설정을 세팅해주면 됩니다. 기업 유저의 경우 Ansible Tower에 흥미가 있을 수도 있겠습니다. Tower는 호스트, 프로젝트, 개별 인벤토리별로 상세한 히스토리를 볼 수 있는 굉장히 강력한 데이터베이스 로깅 기능을 제공합니다. 그래픽을 가진 화면과 REST API 모두를 제공합니다.

참고 : http://docs.ansible.com/ansible/intro_getting_started.html

[iPhone] 앱스토어에 올리기전에 알아두면 좋은 팁

열심히 만든 어플리케이션을 처음으로 앱스토어에 등록하기 위해 아이튠즈 커넥트에 연결하는 그 순간…감격도 잠시 참으로 부족한 설명과 자료들로 인해 업로드가 어렵게 느껴지더군요. 지금이야 물론 당연한 프로세스 같이 느껴지지만 처음 올릴 당시에 제가 느꼈던 어려움을 느끼실 처음 올리시는 분들을 위해 다음의 정보를 기록해 둡니다.

1. 어플리케이션의 충분한 테스트
이건 참…별로 상관없긴 하지만 처음으로 적어봅니다. 일반적으로 모바일 어플리케이션을 개발 경험이 없는 경우에(저도 없었습니다. Windows Mobile개발을 잠깐 해본적은 있지만 차원이 다르더군요) 어려움으로 다가오는 점이 무엇이냐 하면 바로 메모리 관리입니다.

PC환경에 비해 극악적으로 최악의 환경을 제공해 주기 때문에 메모리 관리를 잘해야 하는데요, 다행이도 맥 개발환경에서는 Instruments라는 훌륭한 디버깅 툴을 제공합니다. Leak을 최대한 체크하시기 바랍니다. 실제로 저의 경우에는 제가 테스트할때는 어쩌다 한번 크래시(메모리 부족현상 혹은 처리하지 못한 에러에 의해 어플리케이션이 강제 종료되는 현상)가 일어나곤 했었는데 실제로 업로드를 해보니 해외의 사람들은 어찌 된것인지 10번 실행하면 9의 확률로 크래시가 일어난다고 하더군요.

그래서 한번에 별한개를 엄청나게 받아버려 지는 별이 되는 경험을 한적이 있습니다. 열심히 만들었는데 이런 경험을 겪으면 기운 빠지겠죠. 최대한 충분히 극한의 상황을 겪는 테스트를 해보시기 바랍니다.

2. 프로덕션 코드 상태로 배포
이것은 무슨 말이냐 하면 디버깅을 위해 넣었던 여러가지의 요소들이 있다면 배포시에는 최대한 빼라는 이야기입니다. 특히 NSLog같은 경우에는 시뮬레이터에서는 아무런 문제가 없지만 디바이스에서는 퍼포먼스의 저하를 일으킵니다. [이것]을 참고하셔서 자동으로 Debug모드 이외에는 로깅을 하지 않도록 설정하는 것도 좋은 방법입니다.

3. 57×57 픽셀 사이즈의 아이콘 필수
당연히 이걸 빼먹는 경우는 없겠지만 어플리케이션은 아이콘을 꼭 가져야 합니다. 그리고 앱스토어에 올릴 때 아이콘 파일을 따로 올려야 하냐는 분들이 계신데 그건 아닙니다. 아이콘을 가지고 있는 어플리케이션이면 충분합니다.
아이콘은 사격형 이미지로 만들면 되며 자동으로 라운드 처리가 되며 자동으로 Shine이라는 상단에 빛을 받는듯한 효과를 가지게 됩니다.
사용자 삽입 이미지

위의 그림에서 알 수 있듯이, Shine을 임의로 끌 수 있습니다. 이것은 Info.plist에서 UIPrerenderedIcon이라는 이름의 값을 추가한 다음에 Boolean타입의 값으로 true로 설정하면 사용자가 직접 렌더링 처리를 하였으니 Shine처리를 하지 말라는 말이 됩니다. 실제로 아이콘이 꼭 사각형이 아닌 경우를 많이 볼 수 있는데 이경우에는 Shine을 끈 후에 자신만의 특별한 아이콘 모양을 만들어 주시면 됩니다.

4. 바이너리 파일 준비
처음에 바이너리를 올리라고 할때 어떻게 올려야 하는 것일지 굉장히 고민했었습니다. Appstore Distribution Provisioning 프로필을 가지고 빌드를 한다음에 나오는 어플리케이션명.app를 올리면 되는데 실제로는 이것이 디렉토리입니다.(맥에서는 하나의 파일같이 보이지만 윈도우에서 보면 디렉토리죠) 이것을 그냥 zip파일로 압축하여 올리면 됩니다. 간단하죠?

5. 512×512 픽셀 사이즈의 아이콘 준비
이 아이콘은 실제로 아이튠즈에서 밖에 쓰이지 않는 아이콘인듯 합니다. 어플리케이션이 57픽셀 사이즈의 아이콘을 등록해서 사용하지만 아이튠즈등에서 보이는 아이콘은 실제로 이것보다 큰 사이즈입니다. 이 아이콘은 512 픽셀짜리 아이콘을 사용하여 보여지게 되는데, 이 512짜리 아이콘은 57아이콘과 거의 같은 모양을 가지고 있어야 하며, JPEG혹은 TIFF 형식의 투명하지 않은 배경을 가진 이미지를 사용하여야 합니다.

마찬가지로 자동으로 모서리가 라운드 처리 됩니다. 참고로 중요한점은 이 아이콘은 어플리케이션을 업로드한 후에도 수시로 변경이 가능합니다. 그러므로 조금 특별한 무언가를 붙이고 싶어도 처음에는 기본 어플리케이션 아이콘과 최대한 같은 모습으로 올린 후에 리뷰를 통과하여 Ready for Sale상태가 되었을때 512 아이콘을 변경하셔도 무관합니다. 여기서 아이콘 변경이란 기존의 아이콘에 Sale, Free등의 플래그를 붙이는 것을 말합니다.

6. 스크린샷 업로드
어플리케이션을 등록할 때 최대 5개의 스크린샷을 업로드 할 수 있습니다. Primary 스크린샷은 필수이며 나머지 4개는 선택적으로 업로드 하시면 됩니다. 상단의 Status Bar는 제거한(320×460)크기의 이미지를 올리기는 권고하고 있지만 실제로는 아무상관이 없는거 같습니다. 이미지를 올릴 때는 5장 모두를 가로로 올리거나 세로로 올리거나 통일 하시길 권합니다. iPhone OS 3.0에 탑재되어있는 앱스토어에서는 무조건 세로로 보여주는 듯 하지만 이전버젼의 앱스토어에서는 가로 세로를 혼용하게 되면 임의로 이미지를 보여주지 않는 등의 문제가 있습니다.

6. Availability Date 설정에 대해
어플리케이션 등록시에는 이 날자가 크게 중요하지 않습니다. 우선 어플리케이션을 등록하는 시점의 일주일 후쯤으로 선택해 둡니다. 이후에 RFS(Ready for Sale)메일이 오게 되는데 어플리케이션이 In Review상태에서 Ready for Sale상태가 될 때 이 날짜를 한번 정할 수 있는 기회가 생깁니다. 이후에 Update시에도 이 날짜를 한번 변경할 수 있게 됩니다. 이때에 정하는 날짜가 Released Date가 되며, 미국 쿠퍼티노 기준시각의 날짜로 변경하시면 됩니다. 좀더 쉽게 말하면 RFS메일을 받는 그 시점에서 한국시각에서 -16시간을 한 날짜로 바로 변경하시면 잠시후에 앱스토어에 등장하게 됩니다. (실제로 5시간정도 소요되니 맘편히 기다립시다)

7. 마지막으로 마음의 여유
첫 어플리케이션을 올리게 되면 하루에 한번씩 새벽에도 잠을 깨서 메일을 확인하게 됩니다. 또한 RFS메일이 잘 오지 않는다고 하여 아이튠즈 커넥트에 계속 접속해보게 됩니다. 첫 어플리케이션을 올리는 개발자 분들 모두가 이 경험을 하게 되지 않을까 생각합니다. 생각보다 리뷰는 비합리적이고 한국인의 마인드로는 이해할 수 없는 느긋한 방향으로 진행됩니다. 등록하신 분들도 이참에 한국인의 마인드???를 버리고 마음편히 기다리시는게 정신건강에 좋을 것 같습니다.^^a