Mirantis open stack deployment automation
•Descargar como PPTX, PDF•
0 recomendaciones•787 vistas
How to Mirantis OpenStack provision OS and deploy OpenStack nodes
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Mirantis open stack deployment automation
Similar a Mirantis open stack deployment automation (20)
Último
Último (6)
Mirantis open stack deployment automation
- 2. INDEX Puppet MCollective Fuel Provisioning and Deploying Flow • Nailgun • Astute Review Opinion Next (Provisioning Automation)
- 4. 1. Puppet
- 5. Puppet? • Unix-like 및 Windows 기반 시스템상에서 System configuration을 관리하고 자동화하기 위해 디자인된 Configuration Management 도 구 • Puppet Labs에서 개발을 주도하고 있으며 Ruby로 작성
- 6. The Puppet Advantage • Manifest를 한번만 작성하면 여러 장치에 중복 작업 없이 적용 가능 • 모든 서버가 Manifest를 기준으로 서로 동기화가 가능 • Manifest를 날짜 기준으로 신뢰성 있는 문서로 사용 가능 • 다양한 운영체제, 플랫폼, 명령어 문법 등에 유연 • Manifest는 코드이기 때문에 버전 및 다른 코드 관리 방식이 적용 가 능
- 7. Puppet Language • Manifest는 System Configuration을 표현하기 위해 Puppet의 커스 텀 언어로 작성 • 이 언어는 Resource라고 불리는 유닛을 정의하는데, 이는 각 시스템 의 사용자, 파일, 소프트웨어 패키지등을 기술함 • Puppet은 선언적인 프로그래밍 언어 • Shell이나 Perl 같은 다른 프로그래밍 언어들과 같이 수행 목록을 제 공하지 않고 어떻게 작업이 되어야 하는지(Should-be)를 기술 • Puppet은 현재 서버의 상태를 Manifest와 비교하고 불일치 되는 부 분만 변경
- 8. Puppet Code RESOURCE { NAME ATTRIBUTE => VALUE } Resource Definition
- 10. Puppet Forge
- 12. 2. MCollective
- 13. MCollective? 서버 Orchestration과 Parallel Job Execution 시스템을 위한 프레임워 크 1. 작은 규모의 클러스터부터 큰 규모의 클러스터까지 Interaction 2. 요청을 분산할 때 Broadcast 패러다임을 사용 3. 리모트 에이전트를 콜하기 위한 심플한 CLI 환경을 제공 4. Simple RPC Style 에이전트, 클라이언트 지원 5. 커뮤니티로부터 패키지 및 서비스, 다른 공통 컴포넌트들을 관리할 수 있는 다양한 에이전트 지원
- 15. MCollective Server • MCollective를 통해 컨트롤 될 수 있는 노드를 의미 • 바꿔말해 각각의 노드에 설치되는 MCollective 컴포넌트 • mcollectived라는 MCollective 데몬을 실행 • 여러 에이전트 플러그인들이 설치 됨 • mcollectived 데몬은 3가지 플러그인을 사용 • A connector plugin: 미들웨어와의 연결, 요청을 폴링, 응답 전송 • A security plugin: 요청들에 대한 검증 및 필터링, 응답 인코딩 • Several agent plugins: 요청에 대한 Action 실행
- 17. MCollective Client • 다른 노드들에게 요청을 전송하는 컴포넌트 • Client 컴포넌트에서 사용하는 플러그인 • A connector plugin: 미들웨어와 연결하고 요청을 전송, 응답 수신 • A security plugin: 요청들을 인코딩 • Several agent plugin DDL files: 유효한 요청들을 구성 • Client가 Action들을 요청할 때 Agent들에서 어떤 Arguments들이 필요한지 알아야하는데 Client는 DDL파일을 이용해 유효한 요청을 구성
- 19. Middleware • Server 컴포넌트와 Client 컴포넌트는 직접 커뮤니케이션 하지 않음 • Middleware 시스템은 MCollective에서 지원하지 않음 • 알맞은 Middleware를 선정한 후 그에 맞는 Connector Plugin를 구 현 • Default Middleware: ActiveMQ, RabbitMQ • Connector와 Middleware에서 처리하는 3가지 주요 메세지 • Broadcast requests (client-to-server) • Directed requests (client-to-server) • Replies (server-to-client)
- 20. Middleware
- 21. MCollective CLI
- 22. RPC Agent DDL File Ruby File
- 23. 3. Fuel Provisioning and Deploying Flow
- 24. Fuel Master • Service for network provisioning • Service for installing OS • Service for deploying OpenStack services
- 26. Node Detecting Flow 각 노드들이 PXE(Pre-boot eXecution Environment)부팅을 하게 되 면 1. Fuel Master 노드에 있는 PXE 부트 서버의 Bootstrap 이미지로 부팅 2. Bootstrap 이미지는 Nailgun agent이라는 스크립트를 실행 3. Nailgun-agent.rb 에이전트가 서버의 하드웨어 정보를 수집 4. REST API를 통해 Fuel Master 노드의 Nailgun으로 전송 5. Fuel UI 또는 CLI를 이용해 Nailgun API를 통해 확인 가능
- 27. Nailgun • Fuel에서 가장 중요한 서비스 중 하나 • 시스템의 모든 비즈니스 로직을 가지고 있는 RESTful 어플리케이션 • Python으로 작성 • Environment 구성, 설정, Role, Node Detection, Node Deployment, 디스크 볼륨 설정 등 OpenStack 배포에 필요한 모든 데이터 • 모든 설정 정보 및 노드 정보, 상태 정보를 PostgreSQL에 저장 • Worker(Astute)와는 AMQP를 통해 커뮤니케이션 • Fuel 웹 인터페이스와 CLI 툴을 통해 Nailgun API와 연동
- 29. Provisioning Flow (Next) 사용자가 Environment 설정을 하고 Deploy 버튼을 누르게 되면 1. Nailgun 서비스에 의해 모든 Environment 설정정보가 담긴 JSON Data Structure 생성 2. RabbitMQ에 전송 3. Astute worker가 RabbitMQ를 리스닝하고 있다가 메세지 수신 4. Cobbler와 MCollective를 통해 각 노드에 OS 설치
- 30. Astute • Nailgun의 Worker 역할을 하는 Fuel 컴포넌트 • Provision과 Deploy를 하는 Orchestrator • Provision: Cobbler를 이용해 각 노드들에 OS를 설치 • Deploy: MCollective를 이용해 각 노드들에 OpenStack을 배포
- 31. Deployment Flow
- 32. Deployment Flow 각 노드들에 OS 설치가 끝나면 1. Astute는 MCollective uploadfile 에이전트를 이용해서 각 노드들 의 /etc/astute.yaml에 배포에 필요한 데이터를 푸시 2. Astute는 MCollective puppetsync 에이전트를 이용해서 Puppet modules과 manifests를 동기화 3. 이 에이전트는 마스터 노드의 rsyncd 서버와 연결하고 최신 버전의 Puppet modules와 manifests를 다운로드 하기 위해 rsync 프로세 스를 실행 4. 동기화가 끝나면 Astute는 puppetd 에이전트를 실행시켜 메인 manifests의 site.pp를 통해 실질적인 배포
- 33. During Deploying 배포가 되는 동안 • Astute는 배포가 끝날 때 까지 배포가 종료되었는지의 상태와 Nailgun으로 진행상태를 리포팅하기 위해 에이전트를 폴링 • Puppet 포르세스가 성공이든 실패든 종료가 되면 Astute는 노드로 부터 Summary를 생성하고 Nailgun으로 결과를 리포팅 • 이를 통해 사용자가 Fuel Web 인터페이스와 CLI 툴을 통해 진행상 태와 결과를 모니터링 할 수 있게 되는 것
- 34. 4. Review
- 35. 5. Opinion • MCollective의 경우 추후 특정 기능을 추가한다던지 특정 정보를 추 가를 가져와야할 경우 Agent / Client 개발이 빈번할 것으로 예상 • Puppet의 경우 Daou Cloud만의 설정이 많아 질 것으로 예상되기 때 문에 그에 따른 Custom Puppet 파일(pp)이 필요는 하겠지만 따로 추가적인 라이브러리 파일(rb) 개발은 거의 없을 것으로 예상
- 36. References • Fuel Document (https://docs.fuel-infra.org/fuel-dev/index.html) • Fuel (https://wiki.openstack.org/wiki/Fuel) • Astute (https://github.com/openstack/fuel-astute) • MCollective (https://puppetlabs.com/mcollective) • Puppet 3 Beginner’s Guide
- 37. 감사합니다
Notas del editor
- 사실 개발자가 여기 계신분들을 모시고 서버 프로비저닝 자동화에 대해 발표하는게 쉽지는 않지만 개발자적인 입장에서 조사를 하고 자료를 준비했으니 재미있게 들어주셨으면합니다.
- 이번 세미나때 다룰 주제들입니다. 실질적으로 배포를 하는 녀석은 첫번째에 있는 Puppet이라는 애인데요. 이번 시간에는 Fuel이 어떻게 각노드들에 대해 OpenStack 클라우드 환경을 자동으로 배포해주는 지에 대해 포커스를 맞춰서 진행하려 하기 때문에 Puppet에 심화적인 부분은 일부러 좀 제외했습니다. 세세한 내용까지 다루면 정작 중요한 플로우를 다루기도 전에 지쳐버릴거 같아서요 이번 세미나는 두차례에 나눠서 진행할 예정인데 이번에는 전체적인 아키텍쳐, 그리고 플로우랑 그 플로우중에서도 어떻게 OpenStack 컴포넌트들을 자동으로 배포하는지에 포커스를 맞춰서 진행하려합니다.
- 그다음은 실제로 오픈스택을 구성하게될 Fuel의 아키텍쳐입니다. 지금 보시는 화면이 간략하지만 Fuel에서 OpenStack 노드를 자동으로 구성할 때 사용하는 아키텍쳐입니다. 얼핏보면 웹 UI나 CLI로 시작해 nailgun을 거쳐 AMQP를 거치고 Astute가 무엇인가를 한다음 MCollective를 거쳐 노드로 가는것으로 보입니다. 사실 그 흐름이 맞습니다. 여기서 오늘 우리가 다를 부분은 Nailgun 부분과 AMQP, Astute, Cobbler, MCollective 입니다. 그리고 여기서 Nodes를 제외한 부분은 모두 Fuel Master에서 일어나고 있습니다. 이제 노드를 디텍트 하는 부분 / 각 노드를 프로비저닝하는 부분 / 각 노드에 오픈스택 컴포넌트를 배포하는 부분으로 나누어 살펴보도록 하겠습니다.
- Puppet 은 쉘 스크립트와는 달리 실행하기 전에 해당 내용이 이미 적용 되어 있으면 건너뜁니다. Puppet 자체가 선언적 언어를 지원하고 내부적인 크로스 플랫폼 이슈들은 이를 구현한 루비내에서 처리를 하고 있기 때문에 특정 운영체제에 의존적이지 않습니다.
- Puppet 코드의 간단한 모습입니다 오른쪽의 Resource Definition을 참고하셔서 보시면 되는데요. package, service, file 같은 설정할 자원 타입을 작성하고 그 다음에는 그 작업의 유니크한 이름 그리고 그 안에 그 작업에 의존적인 설정값들을 작성하시면 됩니다. 각 자원 타입별로 Attribute는 정의되어 있습니다. 위에는 가장 기본이되는 Attribute로만 작성이 되어 있는데요 위 코드는 nginx라는 웹 서버를 띄우는 간단한 클래스 파일입니다. Ensure는 각 자원 타입별로 설정값이 좀 다르긴하지만 이 Type이 어떤 상태로 있어야하는지를 나타냅니다. 작성 당시 서버에는 apache라는 WAS가 떠 있었기 때문에 같은 80포트를 사용할 우려가 있어 먼저 apache라는 패키지가 있다면 지우는 작업부터 시작을 합니다. Service 타입을 정의해서 서비스만 내려도 상관은 없습니다. Absent라고 설정하면 해당 패키지는 제거된 상태이여야 된다는 뜻입니다. 아래의 installed는 의미 그대로 인스톨되어야 한다는 말입니다. 저렇게 선언하면 puppet은 ubuntu에서는 apt-get, centos에서는 yum을 이용해 해당 패키지를 설치하고 제거합니다. Require라는 attribute는 해당 작업을 진행하기 전에 필요한 상태입니다. Nginx를 설치하기 전에 apache2가 제거된 상태여야 한다는 뜻입니다. 그 아래 서비스타입을 보시면 nginx서비스를 실행시키는 부분입니다. 해당 서비스는 running 사앹로 있어야 하구 enable값을 실행시키면 부트할때 해당 서비스를 실행시킬것인가 하는 Attribute입니다. 그 아래 file은 파일에 대한 자원 타입을 설정하는 부분이구요. 실제 코드는 이것 보다는 많이 복잡하고 지저분하겠지만 기본 골자는 이런 식으로 선언적으로 되어있습니다.
- Puppet에서 지원해주는 puppet 자원 타입입니다.
- Puppet 에서는 puppet forge라는 저장소가 있는데 이곳에서 다양한 퍼핏 모듈을 검색해볼 수 있습니다.
- Puppet 에서 기본으로 정의하는 리소스 타입 중 두개만 보도록 하겠습니다. 특정 데몬을 스케쥴링해서 돌릴 때 자주 쓰는 크론탭과 서비스에 대한 처리를 하는 서비스인데요. 보시다 싶이 해당 리소스를 사용하는데 필요한 다양한 속성값을 지원하고 있습니다. 앞에서 보신 Type 리스트와 같이 각각의 리소스 타입에 대해 필요한 옵션들을 지원해주고 있고 오른쪽 서비스 같은 경우는 service 명령으로 돌리지 않는 다른 모듈 같은것들을 위해 pattern이라는 옵션을 제공해주고 있는데 내부적으로 ps 명령어를 이용해서 지정한 패턴을 찾는 방식 또한 지원해주고 있습니다. 사실 처음에는 Puppet이 오래 걸릴 줄 알았는데 Puppet 자체가 선언적 언어로 이루어져 있고 대부분 이런 패턴으로 이루어져 있기 때문에 지루하실 것 같아 여기서 끊겠습니다.
- 다음에 진행할 내용은 MCollective입니다. 이 MCollective라는 녀석이 실제로 Fuel Master로부터 받은 요청들을 각각 노드에 뿌려주고 설정을 전달하고 각 노드들에 대해 Puppet을 실행시키는 역할을 합니다.
- MCollective는 작은 규모의 클러스터부터 큰 규모의 클러스터까지 다양하게 사용 가능 요청을 분산할 때 Broadcast를 사용하기 때문에 동시에 여러노드에 작업이 가능 또한 MCollective는 중앙에 데이터베이스를 두고 있지 않기 때문에 데이터 동기화같은 작업이 불필요 MCollective에서 사용하는 자원은 오직 네트워크 뿐 mco 명령어라는 CLI 제공 RPC (Remote Procedure Call, 원격프로시져호출): 별도의 원격 제어를 위해 코딩없이 다른 공간의 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술 각각의 노드들에 요청을 날린다고 하지 않았습니까? 각 요청에 대해 각 노드들이 어떤 액션을 취할지에 대해서는 MCollective의 DDL 파일에 정의가 되어 있습니다. 그렇기 때문이 이 액션자체가 필요할때 개발자가 직접 개발해서 추가할 수 있는 구조인데요. 이것 역서 커뮤니티에서 여러 에이전트를 지원해주고 있습니다.
- MCollective의 간단한 컴포넌트 그림입니다. 액션 요청을 보내는 클라이언트가 있고 액션을 받아 수행하는 다수의 서버, 사실 노드 에이전트라고 봐도 무방합니다. 그리고 그 중간을 이어주는 미들웨어가 있습니다. 이 미들웨어는 MCollective에서 제공해주는건 아니고 MCollective에서 필요한 BroadCast 콜이라던지 Directed 콜, 응답을 할 수 있는 모든 미들웨어가 해당됩니다. 미들웨어와 클라이언트/서버에서 커넥션을 해줄 수 있는 커넥터 플러그인만 개발하면 어떤 것이든 확장가능합니다. MCollective에서는 ActiveMQ와 RabbitMQ를 기본으로 제공해주고 있습니다.
- MCollective CLI 인 MCO 명령어
- RPC Agent 의 모습입니다. Action을 정의하는 DDL 파일과 로직이 담겨져있는 루비파일 한쌍으로 되어있습니다. 향후 MCollective를 통해 원격 노드의 특정 정보가져오거나 특정 액션을 추가할 때 RPC Client 및 Agent를 개발해서 활용할 수 있을 것으로 보입니다. 보이시겠지만 이 부분은 패키지 버전을 체크하는 version이라는 RPC 에이전트입니다. 액션 “get_version”을 요청하면 에이전트는 메타정보에서 버전 데이터를 추출한 후 추출된 정보를 응답값으로 보냄
- 중간 플로우 한번 정리
- 그럼 Fuel Master는 어떤 것들을 가지고 있는지 먼저 살펴보겠습니다. Fuel Master 노드는 오픈스택 노드 구성 및 설정을 자동화해주는 역할을 하는데 이 Fuel Master 노드에는 이를 위해 필요한 데이터를 가지고 있다. 이 정보들을 바탕으로 그리고 앞서 보았던 아키텍쳐를 가지고 OpenStack 노드들을 구성합니다.
- Fuel Master 에서 각 노드들이 어떻게 디텍션되고 OS가 설치되고 오픈스택이 올라가는지 과정을 먼저 보겠습니다.
- 네일건은 Fuel의 핵심 부분 시스템의 모든 비즈니스 로직을 가지고 있는 RESTful 어플리케이션이자 배포를 위해 필요한 데이터를 관리 파이썬으로 작성되어 있으며 언급했다 싶이 OpenStack 노드 구성을 위한 데이터를 가지고 있다. 뒤에 설명하겠지만 각노드들에게 요청을 처리하는 Astute라는 워커거 있는데 AMQP, 여기서는 RabbitMQ를 통해 워커랑 커뮤니케이션함 Fuel 웹 인터페이스와 CLI 툴의 기능은 사실 이 Nailgun이라고 보면 됨.
- 환경과 노드를 구성한 후 Deploy를 하게되면 OS를 먼저 설치하고 그다음 오픈 스택을 배포하는 2가지 과정을 거치는데요 이부분에서는 그 첫번째 OS를 배포하는 플로우를 다루고 있습니다.
- 앞서 이야기했던 MCollective의 Client가 여기에 들어있습니다. Astute가 Nailgun에게 요청을 하달 받으면 Astute가 MCollective Client를 이용해 각 노드에 설치되어 있는 MCollective Server에 뿌려주게되는 구조입니다.
- 각 노드에 보면 /etc/astute.yaml 파일이 있는데 각 노드별 Puppet 모듈 설정및 네트워크, 플러그인 정보가 들어있다.
- Provisioning 부터 Deploying 까지 전체적인 그림을 그려보았습니다. 첫번째 노드 디텍션 단계에서는 각 노드가 PXE 부팅을 하게 되면 그 안에 Nailgun Agent가 설치가 되게 되는데 이 agent는 마스터 노드에 자신이 설치된 노드의 하드웨어 정보를 REST API를 호출해서 올려줍니다. Nailgun은 그렇게 받은 정보를 PostgreSQL에 저장하게 되고 Managed 노드 상태로 바뀌게 됩니다. 두번째 노드 프로비저닝 단계는 다음 시간에 자세히 설명 드리겠습니다만 사용자가 Environment를 구성하고 노드를 구성한 후 Deploy를 누르면 진행되는 두 단계중 OS를 설치하는 단계가 됩니다. Nailgun은 노드 OS 설치에 필요한 데이터를 전송하고 Astute 워커는 Cobbler와 MCollective를 이용해 노드에 OS를 설치합니다. 세번째 오픈스택 배포 단계에서는 OS 설치가 끝나면 Astute는 각노드별 구성 정보를 각 노드의 /etc/astute.yaml 안에 밀어 넣어주게됩니다. 그 다음 Astute는 puppetsync 데몬을 실행시켜 각 노드의 Puppet manifest와 Module를 마스터와 동기화 하고 Puppetd 데몬을 실행시켜 백그라운드로 배포를 시작합니다.
- 마지막 모습이 어떻게 될지는 잘 모르겠지만 이번년도까지 생각을 한다면 Mirantis OpenStack의 구성 위에서 추가 개발 및 커스터마이징이 이루어질 것이기 때문에 MCollective 같은 경우는 개발이 많아 질 것으로 예상됩니다. 특정 노드에서 정보를 추가적으로 가져온다던지 아니면 특정 기능을 실행 시켜야 한다던지에 따라 추가적인 에이전트나 클라이언트 개발이 필요하기 때문입니다. Puppet 같은 경우는 처음에는 굉장히 헤비하게 생각을 했었는데 사실 당분간은 추가개발이 이루어지거나 설정에 대해 커스터마이징이 이루어진다고 해도 Puppet 즉 설정 및 환경들이 선언되어있는 pp파일에 대한 작업은 있겠으나 그 안의 루비 rb 파일까지 개발하거나 건드리는 일은 드물 것이라는 생각입니다.