openstack G 판 소스 분석

노 바 는 전체 openstack 에서 코드 가 가장 많은 부분 이자 가장 복잡 한 부분 이다.만약 에 이 부분의 코드 와 구조 에 대해 비교적 깊 은 이 해 를 가지 면 전체 openstack 의 프로그램 구조 에 대해 비교적 깊 은 이 해 를 가지 게 되 었 다 고 할 수 있다. 여기 서 절차 별로 관련 된 설명 을 할 것 이다. 이 장 은 먼저 일부 핵심 적 인 개념 에서 말 할 것 이다.
      먼저 openstack 에서 매우 중요 한 기본 개념 인 Server, Manager, Driver 를 몇 개 제시 합 니 다.서버 는 말 그대로 서비스 이다. openstack 의 각종 응용 은 모두 서비스의 형식 으로 드 러 났 다. openstack 에는 주로 두 가지 서비스 가 있 는데 하 나 는 Liux 의 서비스 데 몬 방식 으로 존재 하고 하 나 는 WSGIService 는 WSGI 표준 형식 으로 존재 하 는 웹 서비스 이다.여기 서 토론 하 는 server 는 첫 번 째 형식의 서비스 입 니 다.이 server 의 주요 존재 형 태 는 메시지 큐 의 데 몬 입 니 다. 특정 topic 의 메 시 지 를 받 아들 여 해당 하 는 명령 을 수행 하고 rpc 인 터 페 이 스 를 제공 하 며, sever 는 하나의 topic 에 대응 합 니 다.하나의 server 가 어떤 구체 적 인 기능 을 가 져 야 하 는 지, 즉 대외 적 으로 어떤 서비스 기능 을 제공 할 수 있 는 지, 그 중의 manager 에 의 해 결정 된다. manager 는 말 그대로 관리자 이 고 주로 관리 기능 을 제공 하 며 구체 적 인 조작 은 manager 에서 driver 를 정의 하여 결정 한다. 하나의 driver 는 worker 라 고 볼 수 있 으 며 manager 의 관리 조율 하에(manager 는 다른 관련 모듈 기능 을 호출 하여 driver 와 결합 하여 관련 업 무 를 수행 하여 외부 에 관련 서비스 응용 을 제공 할 수 있 습 니 다.
      우 리 는 nova compute 서 비 스 를 예 로 들 어 실제 코드 에서 위 에서 소개 한 기본 개념 을 깊이 이해 합 니 다. 서비스 가 시 작 될 때 원본 코드 에서 nova master / bin 디 렉 터 리 의 nova compute 파일 을 실행 하여 서비스의 시작 을 실현 합 니 다.

   
   
   
   

    
    
    
    
def main(): 
    
    
    
    
    config.parse_args(sys.argv) 
    
    
    
    
    logging.setup('nova') 
    
    
    
    
    utils.monkey_patch() 
    
    
    
    
 
    
    
    
    
    if not CONF.conductor.use_local: 
    
    
    
    
        block_db_access() 
    
    
    
    
 
    
    
    
    
    server = service.Service.create(binary='nova-compute', 
    
    
    
    
                                    topic=CONF.compute_topic, 
    
    
    
    
                                    db_allowed=False) 
    
    
    
    
    service.serve(server) 
    
    
    
    
    service.wait() 
   
   
   
   

그 중에서 create 함 수 는 하나의 공장 방법 에 해당 합 니 다. python 의 언어 특성 을 이용 하여 출입 하 는 매개 변수 에 따라 하나의 server 대상 을 생 성 했 습 니 다. 그 중에서 binary 는 server 의 이름 으로 이해 할 수 있 습 니 다. topic 는 메시지 대기 열 에서 감청 할 topic 입 니 다. db allowed 는 주로 sever 가 데이터 베 이 스 를 직접 방문 할 수 있 는 지 여 부 를 제한 합 니 다.(g 판 은 주로 conductor 를 통 해 데이터 베 이 스 를 방문 하여 데이터 베 이 스 를 방문 하 는 압력 을 줄인다)그리고 이벤트 let 방식 으로 서비스 데 몬 을 시작 하여 topic 에 대한 요청 을 기다 리 고 있 습 니 다. Manager 는 create 방식 으로 수 동 으로 들 어 갈 수 있 습 니 다. 성명 을 표시 하지 않 으 면 binary 매개 변수의 값 을 분석 하여 Manager 문자열 의 이름 을 얻어 동적 으로 불 러 오 는 방식 으로 해당 하 는 Manager 대상 을 불 러 옵 니 다. nova master / nova / compute 의 값 을 자동 으로 해석 합 니 다.manager. py 의 Compute Manager 대상 입 니 다. 그 중의 driver 도 동적 으로 불 러 오 는 방식 으로 얻 을 수 있 습 니 다. 해당 driver 의 이름 은 openstack 의 설정 프레임 워 크 를 통 해 설정 되 어 있 습 니 다.
    전체적으로 말 하면 이런 프로그램의 실현 방식 은 매우 유연 하고 우아 하 며 쉽게 확장 되 고 수정 된다. 그 중에서 한 관리 자 는 몇 개의 driver 에 대응 할 수 있 지만 절차 중의 주석 에 따라 작가 의 대답 은 하나 이 고 단일 한 원칙 을 실현 하기 위해 서 일 것 이다.
본인 의 수준 이 제한 되 어 있 기 때문에 그 중의 일부 이해 가 제대로 되 지 않 을 수 있 으 니, 여러분 들 이 많이 지적 해 주시 기 바 랍 니 다.
(비고: 고급 메시지 큐, topic, eventlet 등 일부 개념 에 대해 설명 하지 않 습 니 다. 모 르 는 친구 가 있 으 면 인터넷 으로 볼 수 있 습 니 다)