(younjin.jeong@gmail.com, 정윤진)

아마 Cloud Foundry 에 관심이 있는 분이라면 bosh.io 를 한번 정도는 방문 했을 것으로 생각된다. 그리고 개인적인 생각인데, OSS Cloud Foundry 를 설치 시도했다가 입을 쩍 벌리고 포기하신 후, 어머 이건 우리가 사용할 수 있는 물건이 아니야 라고 생각했던 분들도 많지 않을까 한다. 사실 이해가 당연히 되는것이, 나도 어디가서 뭐 설치는 정말 많이 해봤다고, 삽질 좀 해봤다고 자부하는데 이거 Cloud Foundry 는 처음 설치를 시도할때 정말 많이 애를 먹었다. 마치 2011년에 오픈스택을 설치하는 느낌. 문서는 버전별로 다르고, 각 문서에 소개된 도구가 다르고, 그 도구별로 또 다른 repository 가 존재하는건 정말 지옥중에 지옥이 아니었을까 한다. 

인터넷에 찾아보면 수많은 OSS CF 설치에 대한 글을 찾아 볼 수 있는데, 이 역시도 굉장히 out date 된 내용들이 많아서 참조하기가 매우 곤란한 경우가 많다. 그리고 거기에 나온 내용을 하나 둘 이렇게 저렇게 따라하다 보면 어느새 랩탑은 너덜너덜 거지꼴을 못면한다. 이 대표적인 이유가 bosh 는 아직 현재까지는 ruby 와 ruby gem 을 사용하여 구현 된 것을 사용해야 하기 때문이다. 

어쨌든 이놈의 bosh 라는 도구가 사용하기 와이리 힘드노 하는 이유를 간략하게 정리해 보자면 아래와 같다. 

• 일단 ruby 기반이다. 뭐 하나 시키면 더럽게 느려서 결과를 볼 때까지 시간이 매우 걸린다. 
• 기본적으로 그 구조를 이해하는 것이 매우 쉽지 않다. 처음 접하면, CF 와 bosh 가 무엇이 다른지도 잘 감이 오질 않는다. 
• YAML 지옥이다. 간단한 환경 설정이나 properties 정도를 적어두는 것이 아니라, 그 배포 대상의 용도에 따라 어마어마한 내용을 살펴야 할 때가 많다. spiff 라는 YAML merge 도구를 사용하다 보면 OSS CF 배포에 사용되는 YAML 은 보통 1800 줄 정도 된다. 
• 문제가 발생할때 까지도 시간이 오래 걸리고, 문제를 확인 하는것도 오래 걸리고, 문제를 고쳐서 잘 돌아가는 것을 확인하는데도 오래 걸린다. 즉, 문제가 생기면 골때리게 시간을 오래 잡아 먹을 가능성이 높다. 

• Bosh 에서 말하는 jobs 는 각 용도별 Virtual Machine 을 일컫는다. 즉, YAML에 jobs: 하위에 consul 이 정의되어 있다면 이것은 consul 을 배포하는 작업이다. 
• Stemcell 이라는 방법을 사용하여 VM 위의 OS 레이어를 추상화 한다. AWS 로 치자면 사전에 패킹된 AMI 를 지정한다고 보면 된다. 따라서 bosh 를 사용함에 이로운 점은 CVE 와 같은 긴급 패치가 발생한 경우 배포한 서비스들에 AMI 를 바꿔치기 하는 방법으로 전체 서비스의 업데이트가 가능하다. 물론, multi-AZ 와 같은 구성은 필수겠다. 
• 보통 bosh micro 라는 VM 을 배포하고 여기를 director 로 연결해서 사용한다. Jumpbox 를 만들면 편리한데, 이는 클라이언트와 디렉터간에 간혹 무거운 파일 전송이 발생하는 경우가 있기 때문이다. 
• bosh 는 매번 배포를 진행할때, 이전에 했던 모든 동작을 다시 반복한다. 물론 전체를 매번 재배포 하는것은 아니지만, manifest 의 설정대로 작업을 진행하며 이미 있는건 검사하고 넘어간다. 이러한 특징 때문에 신규 작업을 위해서 해당 배포는 시간이 엄청나게 오래 걸리는 단점이 있다. 
• 문제를 해결해야 하는 경우가 상당히 자주 발생한다. 그것이 YAML 자체의 문제이건, 중간에 나오는 설정의 문제이건 간에 아무튼 엄청나게 자주 발생한다. 따라서 이러한 문제를 해결하기 위해서는 STDOUT 의 메세지만으로는 턱없이 부족한데, 다음과 같은 것들을 알아두면 좋다.