OpenStack 기여자라면 대부분의 작업을 DevStack에 의존할 것입니다. DevStack은 기여자들이 개발, 테스트 및 검토에 사용하는 사실상의 플랫폼이며 오랜 기간 동안 사용되어 왔습니다. 이 기사에서는 내가 기여하고 있는 openstack-ansible이라는 프로젝트를 소개하고자 합니다. 지난 몇 달 동안 저는 OpenStack 업스트림 개발을 위해 DevStack의 대안으로 이 프로젝트를 사용해 왔으며 매우 긍정적인 경험을 했습니다.
DevStack의 문제점은 무엇입니까?
openstack-ansible에 대해 알아보기 전에 DevStack의 대안을 찾도록 동기를 부여한 이유에 대해 간략하게 논의하고 싶습니다. 전반적으로 DevStack은 잘 조화된 프로젝트이지만 몇 가지 아키텍처 결정이 저를 괴롭히고 있습니다.
우선 DevStack은 모놀리식 설치 프로그램과 함께 제공됩니다. 설치를 수행하려면 stack.sh를 실행합니다. 그러면 구성한 모든 모듈이 설치됩니다. 나중에 모듈을 추가하거나 제거하려는 경우 유일한 옵션은 unstack.sh를 실행하는 것입니다. 모든 것을 제거한 다음 stack.sh를 다시 실행하십시오. 업데이트된 구성으로. 몇 번은 소스 코드를 모듈에 변경했을 때 부주의하게 모듈이 이상하게 작동하게 만들었습니다. 내가 그런 상황이라면 가장 안전한 방법은 다시 설치하는 것이고 DevStack으로 할 수 있는 유일한 방법은 모든 것을 다시 설치하는 것입니다.
DevStack은 모든 모듈의 개발 설치를 수행하여 프로덕션 배포와 매우 다른 환경을 만듭니다. 제 생각에 적절한 개발 환경은 내가 작업하고 있는 모듈이 개발용으로 설치되어 있고 나머지는 모두 프로덕션용으로 설치되어 있을 것입니다. 이것은 DevStack으로 할 수 없습니다.
DevStack과 함께 사용했던 또 다른 문제는 일관된 상태에서 종속성을 유지하기 위한 끊임없는 싸움입니다. DevStack에서 종속성은 모든 모듈 간에 공유되므로 하나의 모듈에 대한 종속성을 동기화하는 간단한 작업으로 여러 다른 모듈을 업데이트해야 하는 연쇄 반응이 발생할 수 있습니다. 최근 DevStack 릴리스에서는 모듈별 가상 환경을 사용하여 어느 정도 이를 완화할 수 있지만, 그렇게 해도 OS 수준 패키지는 계속 공유됩니다.
openstack-ansible(OSA)이란 무엇입니까?
openstack-ansible 프로젝트는 Ansible을 사용하여 OpenStack을 배포하는 Rackspace 오픈 소스 이니셔티브입니다. os-ansible-deployment라는 이름의 이 프로젝트에 대해 들어본 적이 있을 것입니다. StackForge에서 OpenStack 큰 텐트로 이전하기 전에.
DevStack과 마찬가지로 openstack-ansible은 벤더 패치나 추가 기능 없이 모든 OpenStack 서비스를 git 리포지토리에서 직접 배포합니다. 그러나 가장 큰 차이점은 openstack-ansible이 OpenStack 서비스를 LXCcontainers에 배포하므로 양극에서 호스팅되는 서비스 간에 완전한 OS 수준과 Python 패키지 격리가 있다는 것입니다.
DevStack과 openstack-ansible의 또 다른 차이점은 후자가 프로덕션 배포라는 것입니다. 이를 통해 소수의 노드에서 수백 또는 수천 개의 노드가 있는 대규모 클러스터에 이르는 엔터프라이즈 규모의 프라이빗 클라우드를 배포할 수 있습니다.
다음 다이어그램은 openstack-ansible privatecloud의 구조를 보여줍니다.
이것을 보고 나면 이 프로젝트가 다중 노드 프라이빗 클라우드를 지향한다는 점을 감안할 때 업스트림 개발을 위한 DevStack의 단순성과 어떻게 일치할 수 있는지 생각하면서 머리를 긁적일 것입니다. 절망 하지마! 다음 섹션에서 이에 대해 설명합니다.
OSA 올인원
openstack-ansible 프로젝트 기여자는 일상적인 작업과 게이팅을 위해 단일 노드 배포를 사용합니다. 왜냐하면 그것이 훨씬 더 편리하고 자원 효율적이기 때문입니다. 이 배포 방법을 사용하면 클라우드 서버 또는 가상 머신에 OSA를 설치할 수 있으므로 이 기능을 활용하면 이 프로젝트를 DevStack과 비교할 수 있습니다.
불행히도 OSA의 단일 노드 배포에 대한 호스트 요구 사항은 주로 컨테이너 인프라에서 발생하는 오버헤드로 인해 DevStack보다 높습니다. 사용 가능한 설치를 위해서는 호스트에 16GB의 RAM과 80GB의 디스크 공간이 있어야 합니다. 현재 지원되는 호스트 OS는 Ubuntu14.04뿐입니다.
OSA가 DevStack에 비해 가지고 있는 한 가지 좋은 이점은 컨테이너화된 아키텍처 덕분에 단일 노드 설치에서도 중복 서비스를 배포할 수 있다는 것입니다. 기본 단일 노드 배포에서는 galera, rabbitmq 및 keystone이 이중화로 배포되고 HAProxy가 호스트에 설치되어 로드 밸런싱을 수행합니다.
손을 더럽힐 준비가 되셨습니까? 위에서 언급한 사양을 충족하는 새로운 Ubuntu14.04 서버에 액세스할 수 있는 경우 다음 명령을 사용하여 OSArepository를 복제할 수 있습니다.
# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible
이 디렉토리에 프로젝트를 복제할 필요가 없습니다. 대신 원하는 곳에서 복제할 수 있습니다.
다음으로 단일 노드 구성 파일을 생성합니다. 운 좋게도 프로젝트에는 이를 수행하는 스크립트가 함께 제공됩니다.
# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh
위의 명령이 실행된 후 /etc/openstack_deploy 디렉토리 YAML 형식의 여러 구성 파일로 채워집니다. 특히 관심 있는 파일은 user_secrets.yml입니다. , 설치에 사용될 모든 암호가 포함되어 있습니다. 이 암호는 무작위로 생성되므로 기억하기 어렵습니다. 나는 일반적으로 관리자 비밀번호를 많이 사용하기 때문에 편집합니다. 기본적으로 저는 이것을 변경합니다:
keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdH
이에:
keystone_auth_admin_password: secrete
나머지 암호는 그다지 유용하지 않으므로 그대로 둡니다. 그러나 기억하기 쉬운 암호를 사용해야 한다고 생각되는 모든 암호를 변경할 수 있습니다.
다음으로 호스트에 Ansible을 설치하는 또 다른 스크립트와 사용을 단순화하는 몇 가지 Ansible 추가 기능 및 래퍼 스크립트를 실행합니다.
# scripts/bootstrap-ansible.sh
이 시점에서 호스트는 OSA 설치를 수신할 준비가 되었으며 설치를 수행하는 Ansible 플레이북을 실행합니다.
# scripts/run-playbooks.sh
Rackspace Public Cloud 서버에서 모든 플레이북을 완전히 실행하는 데 약 45분이 걸립니다. Ansible을 사용하여 작업할 때 좋은 점 중 하나는 모든 작업이 멱등적이라는 것입니다. 즉, 문제를 일으키지 않고 플레이북을 여러 번 실행할 수 있습니다. 작업이 이미 수행된 경우 다시 실행해도 아무 작업도 수행되지 않습니다. 이는 모든 것을 먼저 분해할 필요 없이 적절한 구성 파일을 변경하고 플레이북을 다시 실행하여 라이브 시스템을 재구성할 수 있기 때문에 실제로 매우 유용합니다.
openstack-ansible 둘러보기
이 섹션에서는 OSA 단일 노드 구조에 대한 개요를 제공하여 용감한 분들이 모든 것이 어디에 있는지 알 수 있도록 하고자 합니다.
먼저 Horizon 대시보드가 배포되고 호스트의 공용 IP 주소에서 액세스할 수 있어야 합니다. 관리자를 사용할 수 있습니다. 계정, /etc/openstack_deploy/user_secrets.yml에 입력한 비밀번호 file.이 파일을 편집하지 않은 경우 이 파일을 열고 keystone_auth_admin_password를 찾아야 합니다. 어떤 비밀번호가 사용되었는지 알아보기 위한 설정입니다.
위에서 언급했듯이 서버는 모두 LXC 컨테이너에 설치됩니다. 다음 명령은 컨테이너 목록을 보여줍니다.
root@miguel-lxc-server:~# lxc-ls -f
NAME STATE IPV4 IPV6 AUTOSTART
--------------------------------------------------------------------------------------------------------------------------------
aio1_ceilometer_api_container-c8e825de RUNNING 10.0.3.203, 172.29.237.195 - YES (onboot, openstack)
aio1_ceilometer_collector_container-2da3371f RUNNING 10.0.3.10, 172.29.238.178 - YES (onboot, openstack)
aio1_cinder_api_container-88e59c04 RUNNING 10.0.3.125, 172.29.238.106, 172.29.247.183 - YES (onboot, openstack)
aio1_cinder_scheduler_container-69d2bec4 RUNNING 10.0.3.4, 172.29.239.79 - YES (onboot, openstack)
aio1_galera_container-2f36d624 RUNNING 10.0.3.95, 172.29.237.18 - YES (onboot, openstack)
aio1_galera_container-3b8e14d7 RUNNING 10.0.3.18, 172.29.237.166 - YES (onboot, openstack)
aio1_galera_container-618973ae RUNNING 10.0.3.82, 172.29.238.189 - YES (onboot, openstack)
aio1_glance_container-4b41140f RUNNING 10.0.3.21, 172.29.237.77, 172.29.246.233 - YES (onboot, openstack)
aio1_heat_apis_container-40ec9f3e RUNNING 10.0.3.193, 172.29.239.6 - YES (onboot, openstack)
aio1_heat_engine_container-36e270c9 RUNNING 10.0.3.171, 172.29.239.171 - YES (onboot, openstack)
aio1_horizon_container-3497588e RUNNING 10.0.3.33, 172.29.239.114 - YES (onboot, openstack)
aio1_horizon_container-6cac5348 RUNNING 10.0.3.30, 172.29.238.168 - YES (onboot, openstack)
aio1_keystone_container-821e7cf8 RUNNING 10.0.3.38, 172.29.238.105 - YES (onboot, openstack)
aio1_keystone_container-d63c657e RUNNING 10.0.3.69, 172.29.239.208 - YES (onboot, openstack)
aio1_memcached_container-8baf34d5 RUNNING 10.0.3.158, 172.29.237.135 - YES (onboot, openstack)
aio1_neutron_agents_container-21b819b7 RUNNING 10.0.3.233, 172.29.239.130, 172.29.240.182 - YES (onboot, openstack)
aio1_neutron_server_container-b4279bbe RUNNING 10.0.3.52, 172.29.239.216 - YES (onboot, openstack)
aio1_nova_api_metadata_container-79faf41a RUNNING 10.0.3.60, 172.29.239.110 - YES (onboot, openstack)
aio1_nova_api_os_compute_container-fed67563 RUNNING 10.0.3.231, 172.29.239.17 - YES (onboot, openstack)
aio1_nova_cert_container-72f66c56 RUNNING 10.0.3.155, 172.29.237.152 - YES (onboot, openstack)
aio1_nova_conductor_container-7d0f1b0f RUNNING 10.0.3.164, 172.29.239.144 - YES (onboot, openstack)
aio1_nova_console_container-62af2918 RUNNING 10.0.3.106, 172.29.238.236 - YES (onboot, openstack)
aio1_nova_scheduler_container-e6b79b3b RUNNING 10.0.3.250, 172.29.236.153 - YES (onboot, openstack)
aio1_rabbit_mq_container-0e0fe308 RUNNING 10.0.3.86, 172.29.239.93 - YES (onboot, openstack)
aio1_rabbit_mq_container-a4a04124 RUNNING 10.0.3.253, 172.29.237.188 - YES (onboot, openstack)
aio1_rabbit_mq_container-b9c6dce6 RUNNING 10.0.3.22, 172.29.238.111 - YES (onboot, openstack)
aio1_repo_container-6a8377fc RUNNING 10.0.3.102, 172.29.237.47 - YES (onboot, openstack)
aio1_repo_container-b92c563a RUNNING 10.0.3.223, 172.29.239.251 - YES (onboot, openstack)
aio1_rsyslog_container-a6e4f7d4 RUNNING 10.0.3.170, 172.29.237.249 - YES (onboot, openstack)
aio1_swift_proxy_container-9f0130d3 RUNNING 10.0.3.20, 172.29.237.227, 172.29.247.52 - YES (onboot, openstack)
aio1_utility_container-d83fab91 RUNNING 10.0.3.39, 172.29.237.161 - YES (onboot, openstack)
이 목록을 통해 어떤 서비스가 배포되었는지 확인할 수 있습니다. lxc-attach를 사용하여 컨테이너 내부에 들어갈 수 있습니다. 명령. 특히 흥미로운 컨테이너는 유틸리티가 있는 컨테이너입니다. 목록 맨 아래에 있는 이름. 이 컨테이너에 들어가려면 다음 명령을 사용해야 합니다.
# lxc-attach -n aio1_utility_container-d83fab91
유틸리티 컨테이너는 모든 OpenStack 명령줄 클라이언트가 설치되어 있고 openrc을 사용할 준비가 되어 있기 때문에 유용합니다. 관리자 계정에 대한 파일입니다. 다음 예제 세션에서는 openstack 내 배포의 사용자 목록을 쿼리하는 유틸리티:
root@miguel-lxc-server:~# lxc-attach -n aio1_utility_container-d83fab91
root@aio1_utility_container-d83fab91:~# source openrc
root@aio1_utility_container-d83fab91:~# openstack user list
+----------------------------------+--------------------+
| ID | Name |
+----------------------------------+--------------------+
| 2257ddc66d4c41ba8500114944cbb852 | dispersion |
| 22f1824610b34eb2a6cfaba09b8feb93 | ceilometer |
| 271f9bd069b2440ebb27c8f460bb3bcf | neutron |
| 2ecb372f6563410ab8138625c45a72e3 | heat |
| 35a7c9373ff640c4ba768963c1f53f02 | keystone |
| 37041c2377c44f5cb84ffafee5bfed6f | cinder |
| 4b7f43c7c2cc443889cd6b5d90a30e49 | glance |
| 6ee6a4abb7e64b3d801f2653efb9c9ec | swift |
| 9b375e06cb0a481a8ed2f94e28e1cb39 | nova |
| b2b90c7eed704c63bbc8ea0eb23f43c4 | admin |
| bd3eed1e0cf54b93a0d7c6a7849be778 | stack_domain_admin |
+----------------------------------+--------------------+
컨테이너를 종료하고 호스트로 돌아가려면 exit를 입력하세요. 또는 Ctrl-D를 누르십시오.
다음은 Ansible의 또 다른 멋진 기능입니다. 이를 통해 개발 중에 실수로 손상된 서비스와 같은 서비스를 다시 설치할 수 있습니다. 이렇게 하려면 영향을 받는 컨테이너를 파괴하기만 하면 됩니다.
# lxc-stop -n <container-name>
# lxc-destroy -n <container-name>
병든 컨테이너가 파괴된 후 플레이북을 한 번 더 실행하면 모든 것을 처음부터 설치하는 데 걸리는 짧은 시간에 새로운 플레이북을 교체할 수 있습니다.
개발 워크플로
내가 OSA 올인원 배포를 DevStack을 대체하는 방법으로 실제로 사용하는 방법을 알고 싶으실 것입니다. 이 프로세스에는 몇 가지 간단한 단계가 포함됩니다.
-
OSA-AIO 배포
분명히 모든 것은 단일 노드 openstack-ansiblecloud를 배포하는 것으로 시작됩니다. 저는 일반적으로 Rackspace Public Cloud 서버를 호스트로 사용하지만 위에 나열된 사양으로 모든Ubuntu 14.04 호스트를 사용할 수 있습니다.
-
대상 컨테이너에 연결
그런 다음
lxc-attach를 사용하여 작업하려는 서비스를 실행하는 컨테이너 내부로 이동합니다. 내가 위에서 보여준 명령. 중복으로 배포된 서비스에서 작업하려면 먼저 하나의 컨테이너만 활성 상태로 두도록 HAProxy 구성을 편집합니다. 선택한 컨테이너에 문제가 있는 경우 나머지 컨테이너를 백업으로 사용할 수 있습니다. -
대상 서비스 중지
컨테이너에서 내가 작업하려는 서비스의 프로덕션 버전을 실행하고 있습니다. 이 서비스는 나에게 쓸모가 없기 때문에 표준
service <name> stop을 사용하여 중지합니다. 명령. 예를 들어 열 엔진 컨테이너에 있는 경우service heat-engine stop을 실행합니다. . -
클론 개발 버전
이제 대상 서비스를 실행할 준비가 된 컨테이너가 있으므로 작업할 실제 코드를 복제할 수 있습니다. 이를 위해 검토 중인 경우 공식 git 저장소, 사용자 지정 변경 사항이 있는 포크 또는 Gerrit의 패치를 사용할 수 있습니다.
-
종속성 업데이트
개발 버전에는 Ansible 플레이북에 의해 설치된 버전과 다른 종속성 세트가 필요할 수 있으므로 안전을 위해
pip install -r requirements.txt를 실행합니다. 컨테이너에. OSA는 자체 개인 Python 패키지 리포지토리를 생성하기 때문에 필수 버전의 패키지를 사용하지 못할 수 있습니다. 그럴 때no-index = False를 설정합니다. 컨테이너의 /root/.pip/pip.conf 파일을 사용하여 pypi에 대한 액세스를 활성화한 다음 다시 시도하십시오. -
데이터베이스 동기화
OSA와 함께 설치된 원래 버전과 내 개발 버전 사이의 또 다른 가능한 차이점은 데이터베이스 마이그레이션에 있으므로 만일을 대비하여 항상 데이터베이스를 동기화합니다. 이를 수행하는 명령은 서비스마다 약간 다르지만 일반적으로
db_sync를 사용하여 관리 스크립트를 호출해야 합니다. 옵션. 예를 들어 Keystone으로 작업할 때 데이터베이스를 동기화하는 명령은keystone-manage db_sync입니다. -
필요한 경우 원본 구성 파일을 변경합니다.
플레이북은 모든 서비스에 대한 구성 파일을 생성하므로 대부분의 경우 /etc 인스톨러에 의한 디렉토리는 개발을 위해 변경 없이 사용할 수 있습니다. 내 작업과 관련된 사용자 지정 변경을 수행해야 하는 경우 텍스트 편집기를 사용하여 수동으로 변경합니다.
-
수동으로 실행하거나 서비스로 설치 및 실행
마지막으로 개발 버전을 시작할 수 있습니다. 이를 쉽게 수행하려면 Python 애플리케이션을 직접 실행하십시오. 예를 들어 Heat-engine 서비스에서 작업하는 경우
bin/heat-engine을 실행할 수 있습니다. 포그라운드에서 서비스를 시작하기 위해 프로젝트의 루트 디렉토리에서 터미널로 로그아웃합니다. 서비스를 중지하려면 DevStack에서 수행한 것처럼 Ctrl-C를 누르면 됩니다.pdb(명령줄) 또는 pudb(대화형)와 같은 터미널 친화적 디버거는 컨테이너 내부에 설치될 수 있으며 훌륭하게 작동합니다. PyCharm과 같은 더 복잡한 디버거를 사용하려는 경우 호스트에서 컨테이너로 ssh를 통한 원격 디버깅도 가능합니다.
대부분의 서비스에서 수동으로 실행하면 DevStack처럼 편안하게 작동할 수 있습니다. 유일한 예외는 일반적으로 Apache에서 실행되는 Keystone과 같이 Pythonscript를 직접 실행하지 않는 서비스입니다. Apache는 프로덕션에서 사용되지만 개발을 위해 이벤트렛 기반 웹 서버를 실행할 가능성이 있는 Python 애플리케이션을 직접 실행하는 것이 완벽하게 안전합니다. 어떤 이유로든 Apache를 사용하려는 경우 대안은
python setup.py install을 실행하여 개발 버전을 설치하는 것입니다. 그런 다음service apache2 restart를 사용하여 이미 설치된 Apache 서비스를 다시 시작합니다. .python setup.py develop로 설치하여 소스 디렉토리에서 애플리케이션을 실행할 수도 있습니다. 그런 다음 Apache 사이트 구성 파일에 홈 디렉토리를 추가합니다.
OSA-AIO:전문가
DevStack 대신 OSA로 작업하는 것은 대부분 즐거운 경험이었습니다. OSA를 사용하면 Ineed가 서비스 중 하나를 리베이스하고 새 종속성이 필요한 경우 다른 서비스는 자체 컨테이너에서 영향을 받지 않기 때문에 더 이상 종속성 충돌이 없는 것이 좋습니다.
또한 전체 배포를 처음부터 다시 만들 필요가 거의 없다는 것을 알게 되었습니다. 일반적으로 전체 시스템을 OpenStack의 새 릴리스로 업그레이드하려고 할 때 수행하지만 일상적인 작업에서는 로컬 업데이트 또는 수리를 수행하는 것이 쉽다는 것을 알게 되었습니다. 기존 설치에. 컨테이너를 파괴한 다음 나머지 서비스를 건드리지 않고 Ansible에서 재생성하도록 하는 것이 좋습니다.
마지막으로, OSA를 통해 시스템의 어떤 부분을 개발 패키지로 설치할지 선택하고 나머지 OpenStack 클라우드는 프로덕션 용도로 설치 및 구성할 수 있다는 점이 정말 마음에 듭니다.
OSA-AIO:단점
하지만 물론 모든 일이 그렇듯이 OSA와 함께 작업할 때 그다지 좋지 않은 측면도 있기 때문에 그 측면도 함께 말씀드리고 싶습니다.
OSA는 신생 프로젝트이기 때문에 DevStack이 즐기는 커뮤니티의 폭넓은 지원을 받지 못합니다. 이것은 OpenStack의 핵심이 아닌 모듈에서 작업하는 경우 특히 중요합니다. 이 글을 쓰고 있는 현재 OSA는 Keystone, Nova, Neutron, Glance, Cinder, Swift, Heat, Ceilometer 및 Horizon의 배포를 지원합니다. 이 목록에 포함되지 않은 모듈에서 작업하려는 경우 OSA가 그다지 유용하지 않을 수 있습니다. 하지만 한편, 현재 지원하지 않는 모듈에 대한 Ansible 플레이북을 만들고자 한다면 두 팔 벌려 환영받을 것입니다.
일반적으로 한 가지 예외를 제외하고는 모든 모듈에 대해 Ansiblevariables로 노출되는 구성 옵션이 상당히 많습니다. Neutron의 경우 구성이 유연하지 않습니다. 컨테이너 및 VM 간의 네트워크 터널은 항상 Linux Bridge를 사용하도록 구성됩니다. 예를 들어 Open vSwitch로 작업해야 하는 경우 플레이북을 실행한 후 구성을 수동으로 수정해야 하므로 재미가 없습니다. 또한 현재 Neutron 플러그인은 지원되지 않습니다.
결론
openstack-ansible을 사용하는 제 워크플로가 흥미롭고 배우고 사용하기를 바랍니다. Heat 업스트림 기능 및 버그 수정 작업을 할 때 시간을 절약했습니다. 또한 Keystonefederation을 디버깅하고 문제를 해결하기 위해 OSA에 크게 의존했습니다.
OSA 사용에 관심이 있다면 조금 더 검색하는 것이 좋습니다. 그러면 다른 OpenStack 기고자가 OSA를 자신의 OSA에 통합한 방법을 설명하는 더 많은 기사와 블로그 게시물(예:자체 워크플로.