System Compleat.

Docker 꿀잼 비디오.

Techs


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


Docker 관련하여 재미있는 비디오가 있어서 발번역 한번 해 보았다. 사실 Docker 만능 주의가 적지 않은 편인데, 내용이 맘에 안드는 분들이 많을지도 모르겠지만, 일단은 재미지니까 보는 것으로. Youtube 에서 제공하는 Caption 도구를 사용했는데 일부 언어에서는 보이지 않는것 같기도. 자막이 안보인다면 아래 Cc 버튼을 클릭하면 되시겠다. 


영어로 볼때는 배꼽을 잡았는데 한글로 보니 감흥이 별로 없는것이 번역 유머가 별로 없는 듯...;; 


아무튼 데이터베이스를 포함 현존하는 서비스의 모든것들 Docker 로 구현 하려는 분들이 간혹 있는데, 부적절한 도구의 사용에 대한 유머 정도로 보고 웃어 넘기면 어떨까 싶다. 





영어 자막 원본 비디오는 여기: https://www.youtube.com/watch?v=PivpCKEiQOQ


서비스 보아 가면서 Docker 사용 합시다. 

클라우드 위의 코드 배포는 Cloud Foundry 로.  :) 


간단한 기승전피 


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




저작자표시 비영리
,

Github, Hugo, Concourse, CF를 사용한 블로그의 CI/CD

Techs


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


최근 많이 사용하는 블로그 도구 중 하나가 바로 Hugo (http://gohugo.io) 이다. 이전에 "블로그" 라고 하면 기본적으로 호스팅 업체 또는 대형 포털에서 제공하는 블로깅 도구를 사용하거나, 또는 제로보드 기반의 게시판이 달린 간단한 웹의 형태로 구성하는 경우가 많았다고 한다면, 최근 몇년 전 부터는 Static Web Site 를 구성해서 사용하는 것이 일반적이다. Static 웹 사이트는 기본적인 개념으로는 JSP 로 구성된 웹 사이트의 첫 페이지를 html 로 구워서 사용하는 것과 유사한 개념이라고 보면 된다. 즉, 각 Static 웹 사이트 도구가 지원하는 언어를 사용하여 컨텐츠를 만들면 '파일' 기반으로 된 페이지를 슝슝 만들어 주고, 이렇게 만들어진 웹 서비스용 파일들은 Github 가 제공하는 무료 웹 페이지 도구나, 아마존의 S3 + CloudFront 를 사용하거나, 또는 웹 서버를 만들어서 서비스 할 수 있다. 당연하지, 이것들은 public 디렉토리의 html 과 css, js, 그런 파일들 이니까. 


블로그의 제작은 보통 마크다운이라는 도구를 사용한다. 간단한 YAML 비스무리한 문법에 맞추어 컨텐츠를 작성하면 페이지가 슝슝 생긴다. 구성 및 사용 방법에 대해서는 Hugo 의 홈페이지를 참조하면 되겠다. 



조금 살펴보다 보면, 각종 theme 를 지원하는 것을 확인할 수 있다. 사실 default 로 제공되는 것은 약간 그런 어떤 허전한 느낌적인 느낌이 있으므로, 보통은 테마를 적용하는 것을 권고한다. 테마는 다른 사람이 만들어 둔 것을 사용하거나, 아니면 내가 직접 만들어서 사용할 수 도 있다. 사실 말이 블로그지 원한다면 제품 관련 페이지를 만들거나, 내 홈페이지를 만들거나, 뭐 어쨌든 웹으로 만들 수 있는건 다 만들 수 있겠다. 이것은 여담이지만 Static 기반의 서비스라고 해도 AWS의 DynamoDB 나 Kinesis, SQS 와 같은 도구를 JavaScript 로 연동하여 데이터를 수집하거나 게시판을 구현하거나 덧글 시스템을 구현하거나 하는 것들이 가능하다. "에이, 그럼 JavaScript SDK에 Credential을 제공해야 하는데 그것이 어떻게 동작해요" 하시는 분들은 AWS가 제공하는 Playground 에서 한번 원리를 확인해 보시길. Web Identity Federation 이라 불리곤 한다. 링크는 여기. (어머 친절도 하지) http://blogs.aws.amazon.com/security/post/Tx1XTHT1VJ1SQLX/New-Playground-App-to-Explore-Web-Identity-Federation-with-Amazon-Facebook-and-G



어쨌든 오늘 소개할 내용을 간단히 리스트업 하면 아래와 같다. 


- Github 

- Concourse 

- Pivotal Web Services (Signup 하면 60일 무료, 카드 정보 따윈 필요 없음:  https://run.pivotal.io) 



다시 돌아가면, 블로그라는 것이 블로그 만으로 사용되기 보다는 일종의 뉴스 서비스와 같은 형태로 만들수도 있을 것이다. 예를 들어, 일종의 팀 블로그를 운영하려고 할때 보통은 워드프레스로 구성하고 여기에 포스팅을 할 수 있는 사람들을 선정하여 권한을 주고 뭐 그런 일반적인 3 tier 기반의 구성을 생각해 볼 수 있다. 무엇보다 풍부한 테마와 플러그인등을 사용해 S3나 CloudFront 도 연결할 수 있고 디자인도 맘대로 바꿀 수 있을 가능성이 많다. 즉 편리하다. 하지만 블로그의 사용성을 생각했을때, 데이터베이스가 꼭 필요한가, 그리고 그 데이터베이스가 항시 구동해야 하는가 게다가 그럼 그 데이터베이스가 죽으면 어떻게 되는가 등등등 생각만 해도 꼬리에 꼬리를 무는 영어 문제들이 계속 나타난다. 아 그러니까 결국 우리는 그런거 필요 없고, 웹 페이지를 통해 정보만 전달하면 되겠다 하는 목적이 발생할 수 있다. 즉, 협업해야하고, 그렇게 만들어진 컨텐츠가 이상이 없는지 테스트를 해야 하고, 그리고 문제가 없을때 스테이징에 배포를 해서 살펴보고, 그렇게 컨텐츠들이 적당한 시점에 누적 되었을때 프로덕션에 릴리즈를 한다. 


어디서 많이 들어본 과정 아닌가? 그렇다 바로 개발, 테스트, 그리고 배포에 대한 이야기다. 그리고 여기서는 그런 도구를 이를 테면 신문사와 같이 수많은 기자들이 작성한 기사들이 특정 시점, 그러니까 매일 아침 4시라던가 또는 특정 시점 없이 지속적으로 배포와 수정이 발생하는 경우 저렴하게 사용할 수 있는 도구가 되는 것이다. 게다가 매우 빠르지. 



간단하기는 하지만, 우리 Pivotal의 엔지니어링 블로그가 그런 형태의 협업 구조로 동작하고 있다. 

http://engineering.pivotal.io/


그리고 이 블로그는 아래의 Github 에 메인 좌표를 가진다. 

https://github.com/pivotal/blog


Github 에 대해서는 별도의 설명을 하지 않겠다. 중요한것은 이 블로그가 Hugo 기반의 이며, Github 기반에서 동작하고 있고, 스테이징과 프로덕션의 단계를 가진다는 것이다. 


두번째로, PWS 에 대해서 설명을 하자면, Cloud Foundry 의 가장 최신 기능이 적용 되어 있고, AWS의 us-east-1에서 동작중인 Pivotal Made CF 서비스다. 회사 계정으로 가입하면 바로 사용해 볼 수 있으며, 사용 방법 또한 간단하다. 계정 생성 이후 CLI 도구를 사용해 로그인을 마치고 나면 cf 라는 도구를 사용해서 다양한 커맨드를 사용할 수 있는데, 여기에서 cf buildpacks 라는 커맨드를 사용하면 사용가능한 다양한 빌드팩이 나온다. 빌드팩이 무언고 하는 설명따위 집어 치우고 output 을 보면 대충 이게 뭔지 아마 알 수 있을것이다. 


$ cf buildpacks
빌드팩 가져오는 중...

buildpack              위치   사용   잠김    파일 이름
staticfile_buildpack   1      true   false   staticfile_buildpack-cached-v1.3.6.zip
java_buildpack         2      true   false   java-buildpack-offline-v3.6.zip
ruby_buildpack         3      true   false   ruby_buildpack-cached-v1.6.15.zip
nodejs_buildpack       4      true   false   nodejs_buildpack-cached-v1.5.10.zip
go_buildpack           5      true   false   go_buildpack-cached-v1.7.3.zip
python_buildpack       6      true   false   python_buildpack-cached-v1.5.5.zip
php_buildpack          7      true   false   php_buildpack-cached-v4.3.9.zip
liberty_buildpack      8      true   false   liberty_buildpack.zip
binary_buildpack       9      true   false   binary_buildpack-cached-v1.0.1.zip



이들 중, staticfile_buildpack 을 사용하게 되면 이런 static 형태의 웹 사이트를 서비스 할 수 있다. 물론 CDN을 연결해서 사용할 수 도 있겠다. 당연한 이야기지만, 다른 다양한 언어로 개발하게 되면 위에 걸리는 것들 중 하나랑 합쳐져 executable 형태가 되고, 다시 이것은 컨테이너에 쏙 들어가서 다이나믹하게 라우팅 되고 밸런싱 된다. 즉, 헬스 체크 구성 그따위거 필요 없다는 말이고 그냥 cf push 하고 컨테이너가 10개든 1000개든 알아서 서비스에 등록하고 밸런싱 한다는 말. 


그리고 여기에 오늘의 핵심이라고 할 수 있는 Concourse 라는 도구를 사용한다. 사실 아직까지 무언가 엄청난 기능을 넣은 것은 아니지만, 이 도구는 CI/CD 도구로서 지정된 소스, 이를테면 Github 와 같은 소스로 부터 코드를 가져다가, 원하는 테스트를 마구마구 지지고 볶고 돌린 다음 그 다음 동작을 구성하거나 또는 스테이징에 배포하거나 또는 Pivotal Tracker 에 후킹 메세지를 보내거나 또는 다른 Github 레포에 빌드를 올린다거나 뭐 그런 원하는 동작을 Docker 기반으로 수행할 수 있다. 물론 대규모 개발 그룹에서는 이를 워커로 분리해서 사용할 수 도 있고, 개발자는 이런 회사가 가진 테스트 파이프라인에 본인의 코드가 문제없이 통과 할 지의 여부에 대해 로컬에 vagrant 로 구성해서 직접 돌려볼 수 도 있겠다. 



어쨌거나 오늘의 작업은 이런 느낌이다. 


1. Github 의 Pivotal 엔지니어링 블로그를 fork 해서 내 계정으로 당겨온다. 

2. 로컬 랩탑에 Hugo 를 구성한다. - brew 를 사용하면 매우 편리 

3. 로컬 랩탑에 vagrant 를 구성한다. - 로컬에 돌리려면 설치에 머리 싸매지 않아도 됨 

4. PWS 계정을 준비한다. 

5. Concourse 를 사용해 hugo 도구가 이상없이 페이지를 생성하는지 확인하고, 문제가 없다면 PWS 에 배포한다. (스테이징) 



백문이 불여일견, 백견이 불여일행이라. 이런 동작을 직접 구현하려면 아래의 도구에 대한 인식이 필요하겠다. 


1. vagrant 

2. docker 


Hugo 의 설치는 블로그에 매우 잘 설명이 되어 있으므로 넘어간다. git clone 따위 설명하지 않겠다. 

로컬에 Hugo 의 블로그를 구성하고 싶은 위치에 디렉토리를 만들고, github로 부터 가져온다. 직접 테마를 만들고 싶다면 그렇게 해도 된다. 


vagrant 환경 구성이 필요하다. 설치는 아래의 링크를 참조한다. 

https://www.vagrantup.com/docs/installation/ 


vagrant 설치가 완료되면, Concourse 를 사용할 디렉토리를 준비하고 아래의 링크에 소개된 대로 커맨드를 때리면 아주 쉽게 로컬에 준비된다. 만약 서비스의 용도로 설치를 원한다면 Bosh 를 사용할 필요가 있으므로, 이 부분이 궁금하다면 Pivotal 로 연락 주시길. 

https://concourse.ci/vagrant.html



준비 완료 메세지가 나오면, 이제 http://192.168.100.4:8080/ 주소를 사용하여 Concourse 에 접근이 가능하다. 처음 접근하면 뭐 아무것도 없고 썰렁하니 OS 이미지들만 나오는데, 바로 fly 라고 불리는 클라이언트 cli 도구를 다운 받아서 사용하라는 것이다. 이를 다운 받고, 압축을 해제한 후 원하는 디렉토리에 넣고 PATH 구성을 해 주면 되겠다. 여기에서 설명 되는 것 이상으로 Concourse 에 대한 사용법이 궁금하다면 아래 링크의 Tutorial 을 살펴보고 따라하다 보면 어느새 나도 전문가. 


https://github.com/starkandwayne/concourse-tutorial


주소로 접근하면 위와 같은 화면을 볼 수 있다. 현재로서는 아무런 파이프라인이 구성되지 않았기 때문이며, 본인이 사용하는 OS의 이미지를 클릭하여 클라이언트 도구를 다운로드 하면 되겠다. 


클라이언트 도구인 fly 의 PATH 구성을 완료 했다면, 아래의 커맨드를 참조하자. 


# 타겟 지정 
fly -t blog login -c 192.168.100.4:8080 

# 최초 파이프라인 구성 
# 파이프라인 파일에 대한 정보는 아래의 github 링크에서 pipeline 파일들을 참조 하면 되겠다. 
# https://github.com/younjinjeong/pipelines/tree/master/blog 

fly sp -t blog -c pipeline.yml -p yjeong-blog-test.yml -n -l ../../credentials.yml 

# 파이프라인 시작 
fly up -t blog -p yjeong-blog-test.yml 



그러고 나서 다시 192.168.100.4:8080 으로 접근하면 파이프라인이 생성된 것을 확인할 수 있다. 




github 링크의 파일 중 .sh 파일을 보면 git 를 구성하고 이후 hugo 를 설치한 다음 yjeong-blog-git 로 명명된 github 의 블로그 repository 에서 블로그를 가져다가 hugo 를 돌린다. 물론 여기에 Docker 를 직접 만들어 사용하면 각종 설치에 따른 불필요한 시간을 줄일 수 있을 것이다. 그리고 Pipeline repository 를 보면 알겠지만, 약 40여차례에 걸친 개인적 삽질 끝에 구성이 완료 되었음을 확인할 수 있을 것이다. 


추가적으로 위의 커맨드에 보면 credential.yml 파일이 있는데 이는 CloudFoundry 에 코드를 배포하기 위한 인증 정보가 담겨있다. 당연한 말이지만 이런 파일을 github 의 퍼블릭 레포에 올리면 문제가 될 것이므로 별도의 사설 repo 등에서 관리하는 것이 좋겠다. 


다른 파일은 제외하고, pipeline.yaml 파일을 살펴보자. 

https://github.com/younjinjeong/pipelines/blob/master/blog/pipeline.yml


---
resources:
- name: yjeong-blog-git
type: git
source:
uri: https://github.com/younjinjeong/yjeong.cfapps.io/
- name: yjeong-pipelines-git
type: git
source:
uri: https://github.com/younjinjeong/pipelines/
- name: yjeong-blog-staging
type: cf
source:
api: {{cf-api}}
username: {{cf-username}}
password: {{cf-password}}
organization: {{cf-organization}}
space: {{cf-space}}
skip_cert_check: false
jobs:
- name: yjeong-blog-test-app
public: true
serial: true
plan:
- get: yjeong-blog-git
trigger: true
- get: yjeong-pipelines-git
trigger: true
- task: yjeong-blog-test
file: yjeong-pipelines-git/blog/yjeong-blog-test.yml
- put: yjeong-blog-staging
params:
path: yjeong-blog-git/public/
manifest: yjeong-pipelines-git/blog/yjeong_blog_manifest.yml


보면 리소스를 정의하고, Jobs 에서 작업을 지정한다. 원하는 작업이 많을 수록 수많은 task 를 구성할 수 있으며, trigger 옵션은 git에 새로운 commit 이 발생한 경우 별도의 hook 이 없더라도 새롭게 업데이트된 코드를 가져온다. 그리고 중간에 yjeong-blog-staging 이라는 부분을 보면 소스를 별도의 방법으로 참조하고 있는데, 이는 fly 커맨드로 지정된 credential 파일에서 내용을 가져다 사용한다. 그리고 이 파일은 아래와 같이 생겨있다. 


cf-api: CF_ENDPOINT
cf-username: EMAIL
cf-password: PASSWD
cf-organization: ORG
cf-space: SPACE  


그리고 배포를 할때는 반드시 manifest 파일이 있어야 한다. 따라서 cf push 를 통해 이미 배포된 앱이라면 cf create-app-manifest 커맨드를 사용하여 다운로드 받을 수 있다. 


그리고 웹 UI를 통해 확인 할 수 있지만, 코드가 신규로 업데이트 되면 노란색으로 박스가 점멸된다. 테스트가 실패하면 빨강색으로 나오고, 해당 박스를 더블 클릭하면 어떤 작업이 수행 되었는지, 로그가 어떻게 나왔는지에 대해 작업 순서를 모두 확인이 가능하다. 




위의 경우는 "이전에 했던 테스트는 실패했고, 새로운 커밋이 들어와 새로운 테스트가 시작되었다" 라는 의미이다. 그리고 보면 yjeong-blog-staging 부분에 뻘건 한 줄이 가있는 것으로 보아, staging 배포에 실패한 것이다. 이런 경우 대부분은 credential 설정에 문제다. 




yjeong-blog-app-test 를 더블클릭하면 위와 같은 히스토리 화면이 나온다. 또는 현재 테스트가 진행되고 있는 경우라면 거의 실시간으로 테스트 아웃풋을 확인할 수 있다. 이는 Pipeline 에 지정된 Jobs 가 sequencial 하게 하나씩 수행 되었으며, 47번째 테스트는 모두 성공한 모습을 보여주고 있다. 여기에 각 작업 이름의 왼쪽 화살표를 클릭하면 작업의 디테일한 로그를 확인할 수 있다. 



위의 스크린샷은 간단한 테스트가 성공적으로 종료된 이후, PWS 에 성공적으로 블로그가 배포 되었음을 나타낸다. 그리고 이 블로그는 https://yjeong.cfapps.io 의 도메인으로 동작중이다. 



"에이~ 이게 뭐야 너무 간단한거 아니야" 라고 생각하실 수 있겠다. 그렇다. 이 데모를 위해 1일을 투자했다. 으헝 ㅠㅠ 

아래의 주소로 가시면 이것보다는 조금 더 현실세계에서 사용중인 복잡한 구성을 확인하실 수 있다. 


https://www.pivotaltracker.com/n/projects/956238

https://main.bosh-ci.cf-app.com/ 


위는 Bosh.io 프로젝트를 위해 Pivotal Tracker 에서 일을 정의하고, 이것들을 엔지니어들이 구현하여 bosh 용 concourse pipleline 을 구현한 모습니다. 




정리하면, 이런 구성은 만약 수많은 사람이 협업해야 하는 상태에서 Static 블로그, 또는 웹 페이지를 만들때 매우 효율적이다. 추가적으로 이것은 블로그만 하려고 구성한 것이 아니다. 이러한 파이프라인은 실제 개발에서 사용되는 것이며, 각각의 커밋 단위로 스테이징에 배포하는데 사용되는 기술이다. 따라서 각 팀별로 맡고있는 개발작업의 배포는 실제 이런 형태로 구성되고, 이렇게 모인 CI 들을 release 로 만들어 원하는 시점에 배포한다. 그리고 그 배포에 엄청나게 많은 코드가 사용되거나 사람이 무언가 손을 대는 작업은 없고, 자동으로 배포된다. 


한가지 더 언급하고 싶은것은, Docker file 을 원하는 대로 구성하여 Concourse 의 테스트에 사용할 수 있고, 자유도가 높은 스크립트를 사용하여 원하는 테스트 도구를 사용할 수도 있다. 이를테면 C나 Golang, python 등 다양한 언어로 개발된 애플리케이션 중 빌드가 필요한 것은 빌드의 단계를 구성하고, 이후 테스트를 수행하고, 그러고 문제가 없다면 스테이징에 안착시킬 수 있다는 의미다. 




Github 의 복사 붙여넣기 신공의 편의로 인해 무언가 좀 편리하게 포스팅한 느낌. 

다른거 없음. 백문이 불여일행. 


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


저작자표시 비영리
,

Pivotal Labs 에서 일하기

Techs


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


Pivotal 에 입사한지도 이제 두어달 뒤면 일년이 된다. 참 세월이 빠르다 싶기도 하고, 그동안 무엇을 내가 잘했나 잘못했나 하고 뒤돌아 보니 다양한 감상이 생긴다. 아마존 웹 서비스 같은 회사를 왜 그만 두셨어요 하는 분들부터, 피보탈로 옮겼다 하니 역시 라고 말해주는 분들까지 정말로 다양한 피드백이 있었다. 사실 이러한 외부 피드백 보다 스스로 돌이켜 보았을때, 그리고 다른 회사들에서 동일한 시간을 보냈을때 라고 가정했을때 지난 일년동안 했던일, 또는 배웠던 일이 가치가 있었는가 하고 묻는다면 "당연하다" 라고 하고 싶다. 뭐 여러가지 이유가 있겠지만, 그런 이야기는 나중에 소주를 사주는 분들께 따로 들려드리기로 하고... (응?) 


어쨌든 지난 일년간 배운걸 가지고 어디다가 정리를 좀 해보고 싶은데, 이게 기술적으로 너무 단편적인 것들이 많아서 하나씩 올리면 전체를 보기가 힘든것 같다는 생각이 들었다. 그래서 아, 이 전체 일에 대한 플로우를 써 보면 어떨까 하는 생각, 그리고 그것이 소프트웨어 개발자 분들이나 프로덕트 매니징을 하시는 분들께 도움이 되겠다 싶어 이런 서두부터 살짝 긴 장문의 블로그 포스팅을 시작한다. 주제는 제목과 같다. 자, 이제 그럼 본격 시작해 볼까나. 



1. 가장 자주 목격하는 문제. 


대부분의 사업장, 특히 개발이 필요한 사업장에서 다양한 역할을 가진 분들을 만나면, 생각보다 서로 굉장히 다른 의견을 어필하는 것을 목격하곤 한다. 사실 내가 기본적으로 이해하고 있는 "회사"라는 조직은 큰 틀에서 사업부나 경영진에서 어떤 사업을 기획하면, 그것을 개발한 후에 운영의 단계를 가진다고 본다. 그래서 이를테면 이런저런 앱을 만들고 싶어용 하는 요구사항을 개발팀이 받아서 아 그건 이렇게 저렇게 구현해야해 하고 코드를 만들면 운영팀에서 어머 업데이트가 생겼네 하고 개발된 코드를 서비스한다. 최근 여기에 한꼭지 더 들어가는 것이 이제 분석 정도인데, 서비스를 돌려보니 이렇더라 하고 다시 사업부에 이런 내용을 던지면 그 이후의 사이클은 반복된다. 



http://www.supplychain247.com/article/want_to_innovate_your_supply_chain_break_the_rules


당연한 말이겠지만, 이걸 누가 얼마나 더 저렴하게 많이 하는가에 따라 그 기업의 경쟁력이 달라진다고 생각한다. 그리고 기업의 규모가 더 클 수록, 조직에 사람이 더 많을 수록, 그리고 의사 결정 단계가 많을 수록 이 속도는 느려진다. 보통 회사들은 같은 일을 하는 사람들끼리 부서로 묶고, 일을 부서에서 부서로 넘긴다. 기획부서에서 개발부서로 넘기는데, 만약 기획안 중에 개발이 불가능하거나 현재로서는 없는 기술이라고 하는 극단적 상황이 있다고 하자. 그러면 개발팀은 그것을 다시 기획 부서로 돌려보내고, 기획 부서는 그것이 왜 잘못되었거나 개발이 불가능한지 팀간 미팅을 잡는다. 그렇게 미팅을 하고 나면 그 내용을 기획팀에서 공유하고 다시 유사한 기획이 발생하지 않도록 검토 수정한 후에 다시 개발팀으로 보낸다. 그럼에도 불구하고 무언가 지속적인 문제가 발생하거나 한다면 개발팀과 기획팀의 각 장들, 그리고 부서장들간의 추가적인 미팅이 필요하게 된다. 그리고 이런 동작은 비단 기획과 개발 사이의 문제가 아니라 개발과 운영, 운영과 기획, 개발과 분석 등 동일한 서비스를 위한 이해관계에 있는 팀들 모두가 서로 복잡하게 얽힌다. 


이것은 서비스가 시장에 준비되는 속도를 느리게하고 이미 런칭한 서비스라도 고객의 요구를 반영하는 시간이 오래걸리도록 하는 문제이다. 그리고 많은 조직들은 이렇게 말한다. "우리 여태까지 그렇게 하고 있었는데요."



http://customerthink.com/weve-always-done-it-this-way/


이런 문제는 비단 큰 회사의 문제만은 아니다. 시장에서 주목을 받는 스타트업 역시 투자를 받고, 성장하는 과정에서 동일한 문제를 겪게 된다. 보통 처음 사업을 기획하고 서비스를 만들때는 사람이 적다. 두명에서 다섯명, 그렇게 시작한 스타트업은 빠른 의사결정과 개발속도를 가지고 서비스를 시작한다. 주목을 받기 시작하면 서비스에 요구되는 기능이 많아지고 관리할 대상도 많아진다. 더 많은 개발자를 충원하게 되고, 더 많은 운영자를 충원하는 과정에서 처음과 같은 멤버 보다는 기존의 개발 시장에서 일하던 사람들이 조직에 수혈된다. 또는 수혈받은 자금력을 사용해 경쟁관계에 있는 유사 서비스 회사를 인수하거나 하는 과정에서 조직은 순식간에 성장한다. 하지만, 서비스 개선 속도는 오히려 서너명 있을때 보다도 느린것 같다는 말이 나온다. 



이러한 조직과 프로세스의 문제는 곳곳에서 발견된다. 그리고 곳곳에서 해결되지 않는다. 해결되지 않는 가장 궁극적인 이유는, 다양한 경험을 보유한 것으로 보이는 사람들이 결국 모아 두고 보면 다 유사한, 즉 "오래된" 개발 문화에 익숙해져 있고, "오래된" 조직 구성 방법에 의존하고 있으며, "오래된" 조직 및 서비스 노하우를 그대로 사용하기 때문인 경우가 많다. 그리고 이런 이야기를 꺼내면 그래서 너네는 얼마나 잘하는데 라거나 한국에 그런 조직 있으면 나와보라고 하거나 하는 등 거부의 성향을 보인다. 당연하다. 변화가 반가운 사람들은 변화를 많이 겪은 사람들 뿐이다. 그리고 이런 사람들은 많지 않다. 



2. 그럼 어떻게  



https://blog.pivotal.io/labs/labs/design-critique-pivotal-labs



옆사람이 기획을 할 줄 알고 내가 개발을 할 줄 알고 내 오른쪽의 친구는 운영을 한다. 그리고 내 뒤에는 디자이너가 앉아있고, 이렇게 구성된 우리 팀의 주된 일은 로그인 서비스 개발이다. 기본적으로 API 로 다른 서비스와 연동하며, 관리의 편의를 위해 별도의 어드민 페이지가 있다. 업무의 수행, 전달, 확인은 모두 이슈 트래킹 도구를 통해 진행되며 별도의 보고를 위해 파워포인트나 엑셀을 만들지는 않는다. 우리 팀장님은 매주 월요일에 팀장 미팅에 다녀오면 이번주에 해야 할 일들을 이슈 트래커에 차곡차곡 정리한다. 정리가 끝나면 최대 1시간 정도의 팀 미팅을 한다. 이때 우리 팀 끼리만 미팅을 하는 것이 아니라 다른 팀 팀장 또는 서비스 매니징을 담당하는 쪽에서 함께 미팅에 참석한다. 그리고 전체 서비스의 방향과 새로 이슈트래커에 정리된 일들이 어떤 고객의 어떤 요청에 의해 발생한 일들인지 설명한다. 각 일들 별로 어떤 형태가 되어야 제대로 되는 것인지 완료 되었을때의 동작이나 디자인을 명시한다. 그리고 그런 일들의 기술 난이도와 우선 순위에 따라 분류한다. 한시간 정도 이런 미팅을 하고 나면 이번주에 해야할 일들의 윤곽이 잡힌다. 



http://www.stthomas.edu/news/silicon-valley-close/


아침에 출근하면 우리팀 말고도 전체 팀이 모인다. 한층에 모여서, 15분 정도 되는 간편한 미팅을 한다. 보통 스텐드-업 이라고 불리는 이 미팅은, 글로벌에 있는 우리 회사의 모든 팀들이 함께 들어온다. 그리고 누가 오늘 새로 입사했는지, 어제 무슨 큰일이 있었는지, 서비스에 크리티컬하거나 무지하게 궁금한 질문이 있는지 정도의 이야기를 나눈다. 마이크는 한번에 한사람에게 돌아가며, 10분에서 15분을 절대 넘지 않는다. 그렇게 아침 미팅을 하고 나면 다시 10-20분 정도의 팀 미팅을 한다. 이 미팅에서는 1. 팀과 관련된 주요 사건  2. 어제 해결이 안된일  3. 해결이 안된 일이 있다면 왜인지  4. 오늘 해결해야 할 일과 그래서 누구랑 같이 앉아서 일하면 좋은지  를 결정한다. 이 아침에 일어나는 두개의 미팅은 절대 앉아서 하지 않는다. 하나는 넓고 탁 트인 공간에서, 다른 하나는 팀 자리에 와서 작은 화이트 보드 앞에서 한다. 



https://www.glassdoor.com/Photos/Pivotal-Office-Photos-IMG455504.htm


둘이 함께 자리에 앉으면, 어떤 일을 해결 할지 이슈 트래킹 도구에서 선택한다. 선택의 요령은 일단 리스트상 윗쪽에 위치한 일이 프로덕트 매니저가 지정한 우선순위가 높은 일이다. 그리고 일을 해결하기 위한 조건을 살펴보고, 필요한 기술 스택에 대해 옆사람과 이야기 한 후 구현을 시작한다. 오늘 우리 로그인 서비스에 요구된 추가 기능은 트위터와의 Oauth2 연동이다. 기존의 인증 매커니즘에 추가적인 인증 소스를 더하는 것이다. 이 일의 해결을 위해 나는 오늘 로그인에 관련된 데이터 소스에 대한 정보를 다 알고 있는 친구와 짝을 지어 앉았다. 우리는 함께 앉아, Spring Boot 를 사용하여 만들어진 기존의 Facebook 연동과 Google, Amazon 인증 연동 방법을 간단히 살펴보고 Twitter 구현을 시작한다. 기본적으로는 내가 코딩을 하고, 옆에 앉은 친구는 내가 작성하는 코드를 보며 내가 중간에 틀리거나, 내가 구현하는 로직보다 더 좋은 알고리즘이 있다면 조언을 해 준다. 사용할 데이터베이스의 스키마 지정이나 테스트 코드의 추가에도 도움을 준다. 그렇게 새로운 기능을 하는 코드가 작성이 완료되면, 개발 환경에서 간단히 테스트 한다. 테스트에 별 문제가 없어 보이면, 코드 저장소에 업로드 한다. 업로드 된 commit 에는 나와 내 오늘 짝의 이니셜이 기입된다. 업로드 된 코드는 자동으로 회사에서 사용하는 테스트 도구로 전달된다. 그리고 이 테스트 도구는 보안성 검사, 취약성 검사, 서비스에 추가되어도 문제가 없는지 등의 의존성 검사등을 모두 자동으로 수행한다. 그리고 이 테스트 결과가 모두 녹색이라면, 테스트 시스템은 우리가 작성한 코드를 '스테이징'이라고 부르는 환경에 자동으로 배포한다. 



https://github.com/cloudfoundry-community/bosh-init-concourse


이렇게 스테이징 환경에 배포된 코드는 트위터와 로그인 연동이 적용된 상태로 동작한다. 그리고 이슈 트래커에는 특정 기능이 어떤 커밋 로그로 배포 되었는지 나타나며, 프로덕트 매니저는 이렇게 배포된 기능이 정상 동작하는지 바로 스테이징 환경에 접근하여 확인한다. 확인 뒤에 기능이 제대로 동작하며 문제가 없다면 Accept 를, 문제가 있거나 원래 의도와 다르다면 Decline 을 누른다. Accept 를 누르면, 이 커밋된 코드는 다음번 릴리즈에 배포되기 위해 추가 된다. 나와 내 동료는 Accept 가 된 것을 확인하고 잠깐 쉬기 위해 회사에 마련된 탁구대에서 3세트로 한게임 치거나, 비치된 스낵바나 냉장고에서 음료와 스낵을 가져다가 먹으며 이야기를 나눈다. 무엇을 하건간 약 5분에서 15분 정도의 휴식이 끝나고 나면, 다시 자리에 앉아 다른 일을 꺼내어 함께 시작한다.



http://www.wired.com/2013/11/pivotal-one/


코드 리뷰와 같은 과정은 없다. QA팀이 별도로 존재하지 않는다. 구현이 어려운 기능을 놓고 혼자 끙끙 앓고 있지 않는다. 애초에 대부분의 일을 30분 ~ 수시간 단위의 일로 쪼개는 것이 관건이고, 이것이 각각의 스토리로 관리가 된다. 그리고 일이 어렵건 쉽건 항상 함께 코드를 작성한다. 옆사람이 앉아서 세미콜론이 빠졌는지, 콤마가 빠졌는지, 더 좋은 라이브러리가 있는지 함께 앉아 조언해 준다. 그리고 이런 진행할, 진행중, 진행된 일들은 다른 팀의 누가 와서 보더라도 30분 정도만 투자하면 무슨 일이 어떻게 벌어지고 있는지, 이 팀의 개발 속도가 지금 어떤 상황인지 매우 손쉽게 알 수 있다. 즉, 투명하다. 


이런 팀들이 글로벌하게 존재한다. 나와 같은 로그인을 담당하는 팀이 저기 프라하랑 베이징에 두개가 더 있다. 우리는 같은 이슈 트래커를 공유하고, 그래서 우리 회사의 로그인 서비스는 쉬지 않고 개선된다. 퇴근할때 끄는 서버는 없다. 퇴근할때는 데스크탑만 꺼질 뿐이다. 여기서 일하면 보수도 좋다. 그리고 입사할때 인터뷰 자체가 그날 하루의 일정을 다른 엔지니어와 함께 하는 것이다. 내가 이력서에 기입한 내용에 대해 전화로 간단한 확인이 끝나면, 사무실로 면접을 보러 아침에 온다. 그러면 같이 스탠드업을 하고, 팀 미팅을 하고, 그리고 다른 피보탈 직원과 함께 이슈 트래커의 스토리를 해결한다. 그렇게 하루를 보내고 나면, 피보탈의 직원은 해당 면접자에 대한 피드백과 그가 작성한 코드를 기반으로 채용 여부를 결정한다. 당연히 입사한 사람들은 거의 즉시 일에 투입이 될 수 있고, 또 그런 직원들이 만약 다른 회사의 비전 또는 다른 스타트업에서 일을 하려고 할때 그는 이 회사의 경력이 매우 도움이 된다. 다른 회사들은 이 회사에서 일했던 기술자가 자신들의 회사에서도 일을 잘 할 수 있을것이라고 생각한다. 마치 아마존이나 넷플릭스에서 개발을 했던 사람이 그 회사에서 겪은 경험을 살려 새로운 비지니스를 도움 받았던 경험이 많기 때문에, 바로 그렇기 때문에 시장이 안다. 그래서 좋은 사람이 몰린다. 



3. 그래서 어쩌라고 


우리는 종종 불만 섞인 이야기를 많이 하거나, 듣고는 한다. 이래서 우리나라 소프트웨어 기술이 발전이 없다거나, 또 저거 삽질하고 있다거나, 뭔가 잘못된 일에 돈이 사용되고 있다거나 하는 주변의 수많은 이야기들. 그리고 그런 이야기들은 모두 각자 나름대로의 "한국 사람이라면" 이해할 만한 사연이 있다. 그런데, 만약 조직이 변화한다면 어떨까. 내가 하던 일의 방법이 바뀌고, 내가 어제까지는 그냥 내 자리에 앉아 혼자 일해도 되었는데 내일 부터는 다른 사람과 함께 앉아서 일해야 한다면 어떨까. 나의 능력이 과연 이런식으로 일을 하기에 적합할까. 그렇다, 바로 변화에 대한 공포가 조직을 지배하는 경우가 매우 많다. 


사업의 의사 결정권을 가진 사람들이 만약, 어떤 식으로든 조직의 개발 속도가 아마존 닷컴이 11초에 한번 업데이트 되는 속도를 당신네의 회사에서도 사용할 수 있다면 어떻게 하겠는가 라는 질문에 부정적으로 답변하는 사람은 없을 것이다. 이 로직이 가지는 장점이 전달 되면, 나머지는 비용과 시간의 문제일 뿐이다. 그리고 그래서 그렇게 했던 회사들이 어디가 있냐고 묻게 된다. 구글이 그랬고, 페이스북이 그랬고, 트위터가 그랬고, 이베이가 그랬고, 페이팔이 그랬고, 벤츠가 그렇고, 아우디가 그러며, 비엠더블유가 그렇고, 지이가 그런데, 폭스바겐과 포드도 그러고 있고, 컴캐스트도 그렇고, 비자, 제이피모건체이스, 휴매나, 올스테이트 기타 등등 산업도 다양하다. 왜냐! 소프트웨어가 필요하지 않은 산업은 없기 때문이다. 그리고, 그래서, 그렇기 때문에 이 관련 직군에 있다면 다가올 미래의 다양한 기회를 위해 준비를 해야 할 것이다. 사업가들은 이미 알고 있다. 규제와 제제, 자국 산업 보호, 이런것들도 사실 FTA의 영향에 따라 다양한 임팩트가 있을 것이다. 미국 물건 한국에 못파는게 규제때문이라고 하면 그 미국 기업도 미국도 가만히 있지는 않겠지. 


즉, 때는 온다. 따라서 두려워 피하지 말고 준비해야 한다. 그래야 그때 가면 경쟁력을 가질 수 있고, 이것은 준비된 사람과 아닌 사람을 가를 것이다. 

2012년에 아마존 웹 서비스 한번 살펴보라고 권고를 많이 하고 다녔더랬다. 2014년까지도 흥 관심 없어 하셨던 분들이 많다. 2015년에 회사가 전사적으로 아마존 웹 서비스를 사용하기로 했다. 그리고 그 분은... 


소개된 모든것이, 그리고 일하는 방식이, 문화가 정답은 아닐것이다. 다만, 현재 가지고 있는 많은 문제 중 하나는 개발 관련된 조직과 문화에 대한 to-be 가 좋은 모델이 별로 없다는 것이다. 구글이? 페이스북이? 그리고 그들이 자신들의 서비스를 잘 만들도록 구축한 문화를 다른 회사에 전달해 줄리가 없잖은가. 



http://enterpriseitadoption.com/



4. 위에서 설명한 내용들은 아래의 도구들에 기반하고 있다. 


http://pivotal.io/labs - 당연히도 피보탈 랩의 이야기니까. 

http://www.pivotaltracker.com  -  오픈소스 프로젝트는 무료로 사용할 수 있다. 

http://www.cloudfoundry.org   - 오픈소스는 그냥 가져다가 사용할 수 있으나, 운용 및 관리가 쉽지 않을 것이다. - 상용으로 Pivotal Cloud Foundry 가 있다. 호스팅 회사라면 한번 노려봄직 하다.  

http://www.concourse.ci - Docker 기반의 CI/CD 도구. 랩탑에 간단하게 vagrant 로 구성해서 사용할 수 있다. 

https://network.pivotal.io/products/pcfdev  -  랩탑이 맥북 프로에 메모리 만땅 정도 되면, Cloud Foundry 를 로컬에 설치해서 가지고 놀아볼 수 있다. CF의 구조 이해나 동작 방식, 또는 개발에 기여하고 싶다면 사용을 강추한다. vagrant 로 동작한다. 

http://github.com  -  오픈소스 프로젝트에는 이제 거의 당연하다고 해야. 사용법 정도는 기억하고, pull request 를 통해 기여를 하는것도 해 보자. 모든 프로젝트에 코드만 기여하는 것은 아니다. 번역이나 문서등을 한글화 하는 방법도 있으므로 시간이 되면 참여하는 경험을 쌓는 것도 보람진 경험이다. 

http://aws.amazon.com  -  위에 설명된 거의 대부분의 내용과 서비스, 그리고 개발은 이 위에서 돌아간다. 즉, 모르면 안되는 거다. 

http://azure.microsoft.com - AWS와 함께 알아두면 도움이 될 것이라고 생각한다. 

http://12factor.net   -  애플리케이션 개발 방법에 대한 일종의 가이드라인이다. 

http://spring.io   -   Spring 하시는 분들이라면 Spring Cloud 



엔지니어링 블로그들 

http://engineering.netflix.com 

http://engineering.pivotal.io 

http://nerds.airbnb.com 

http://engineering.instagram.com 

http://engineering.facebook.com 




http://www.wired.com/2013/11/pivotal-one/


소프트웨어 공장장


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


저작자표시 비영리
,

애플리케이션 테스트를 AWS Lambda 로

Techs


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


이 내용은 아래의 아마존 웹 서비스 한국 사용자 그룹에 전달 된 내용이므로 아래의 링크를 통해 읽어보실 수 있겠습니다. 

https://blog.awskr.org/running-tests-in-aws-lambda.html 


원문은 Pivotal Engineering 블로그에서 번역했습니당.  (http://engineering.pivotal.io) 

http://engineering.pivotal.io/post/running-tests-in-aws-lambda/ 


다음에는 더 재미진 글로!


 

저작자표시 비영리
,

bosh.io

Techs


(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 줄 정도 된다. 
  • 문제가 발생할때 까지도 시간이 오래 걸리고, 문제를 확인 하는것도 오래 걸리고, 문제를 고쳐서 잘 돌아가는 것을 확인하는데도 오래 걸린다. 즉, 문제가 생기면 골때리게 시간을 오래 잡아 먹을 가능성이 높다. 

(이미치 출처: https://lh3.googleusercontent.com/-FZftK6jFru8/UC1OtbbRb6I/AAAAAAAADqI/D-8bbqzCjug/w640-h400-p-k/mario-yamld.png)



bosh 에 대해 설명해 보자면, 바로 배포 도구다. 어떤 배포 도구냐면, 예를 들어 MySQL 이나 PostgreSQL, Gemfire, Hadoop 과 같은 도구들에 대해서는 잘 알고 있을 것이다. 이러한 도구들을 각 클라우드 서비스에 '설치' 하는 도구를 바로 bosh 라고 할 수 있다. 당연하지만 이 설치에 필요한 설정이 바로 manifest 파일이고, 이는 YAML 을 사용하도록 되어있다. 따라서 설치 하려는 대상이 복잡하면 복잡할 수록, 구성해야 하는 내용이 많으면 많을 수록 YAML 파일의 길이는 안드로메다로 간다. 어쨌든, bosh 는 클라우드 서비스에 뭔가를 설치하려는 경우 사용할 수 있는 설치도구로 보면 된다. 

현재 bosh 의 repository 를 살펴보면 CPI 라고 해서 클라우드 서비스 프로바이더 인터페이스를 bosh-core 와 분리해 놓은 것을 볼 수 있다. 현재로서는 VMWare vSphere, vCloud Air, Amazon Web Services, Azure, OpenStack 을 지원하고 있다. 이전에는 bosh-core 와 CPI 인터페이스가 덩어리로 뭉쳐 있어 새로운 IaaS의 지원 속도가 좀 떨어졌다면 2015년 부터는 이 부분을 좀 개선해서 새로운 클라우드 서비스의 지원이 조금 빨라지고 있는 모양이다. 

개발자 분들이라면 아래의 링크들을 살펴보면 bosh 의 개발이 어떻게 이루어지고 있는지 눈으로 확인하실 수 있겠다. 

Bosh CI on Concurse: https://main.bosh-ci.cf-app.com/ 


일단 어떤 도구인지는 알았으니, 그 사용할때 어떤 점을 알아두면 좋은가 하는건 아래와 같이 대략 정리가 가능하겠다. 

  • 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 의 메세지만으로는 턱없이 부족한데, 다음과 같은 것들을 알아두면 좋다.  

경험상 필요했던 도구들 
  • bosh task [task number] --debug | egrep -i error   특정 bosh 작업에서 어디의 어떤게 문제였는지 빠르게 확인할 수 있다. 보통 ruby 에러 메세지 및 output 이 담겨있으므로 모든 내용을 보는것은 좀 짜증 날때가 많음 
  • 뭔가 더이상 진행되지 않거나 진행되다가 롤백 된다면, 꼭 ngrep host 나 tcpdump 를 사용해 볼 것을 권고한다. 어느 포트에서 어느 포트로 통신이 필요한데 이것이 제대로 되지 않으면, 그러니까 이를테면 NATS bus 와 같은 메세지 통신이 기존 bosh director 와 bosh 의 job 으로 생성된 vm 간에 허용되지 않으면 두 VM 모두 멍때리는 경우가 많다. 덤프 떠 보자. 
  • 구글 검색에서 사실 cloudfoundry.org 의 문서를 참조하는것이 도움이 된다고 말하기 힘들때가 많다. 문제를 해결하는 가장 빠른 방법은 bosh 나 cf-release 디렉토리 내에 있는 코드와 템플릿, 스크립트를 참조하는 것이다. 그렇다. 나는 지금 에러 메세지를 통한 검색 방법 보다 코드를 보면서 문제를 해결하는 것이 빠르다고 말하고 있는것 맞다. 
  • Manifest 파일 안에서 실수하기 좋은 것들이 static ip 설정이나 이에 따른 subnet 할당이다. multi-az 로 배포한다면 이것이 뒤바뀌면 문제가 많다. 
  • AWS 의 Security Groups, Routing Table, VPC 와 같은 설정들은 아무리 본인이 전문가라해도 항상 의심해서 확인에 확인을 거듭하는 것이 좋다. 
  • 한 2일 정도 붙들고 있으면 대략 윤곽이 보인다.

  • 의외로 Ruby 와 Ruby Gem 이 상당히 짜증을 유발한다. 뭔가 여기 저기서 권고하는 도구를 설치하다가 버전이고 뭐고 다 이상하게 되었다는 생각이 든다면, 아래의 doctor 를 써보자. 나름 잘 고쳐줌.  --  

    https://gist.github.com/mislav/4728286/raw/rbenv-doctor.sh  




정리해 보면, 전체적으로는 다음과 같은 과정이다. 

1. bosh 및 bosh micro 클라이언트 설치 
2. bosh director 준비를 위한 stemcell, manifest.yml 파일 준비 
3. bosh micro deploy 를 사용하여 bosh director 준비
4. Cloud Foundry 또는 다른 bosh 를 통해 배포할 manifest 준비 
5. bosh target x.x.x.x 로 로그인 
6. bosh create release 
7. bosh upload release 
8. 배포될 서비스에 필요한 버전의 Stemcell 업로드 : bosh upload stemcell [스템셀링크 또는 스템셀] 
9. 대망의 bosh deploy 


YAML 은 매우 엄격하다. 그리고 spiff 도구를 통해 필요한 YAML 을 합체하다 보면 순서가 뒤죽박죽 합체되어 뭐 하나 찾으려면 골치가 아프다. 막상 배포에 뭐가 잘못 되면, 그 해당 에러와 YAML 의 어느 부분이 문제인지에 대한 상관 관계 확인 또는 매핑이 매우 어렵다. 아울러 이러한 에러에 대한 정보가 아예 없거나 너무 구버전의 정보이거나 아니면 케이스바이케이스로 풀리는 것도 많이 봤다. 따라서 정리하면 현재로서 사용하려면 매일 이것을 업으로 삼고 있는 사람이 아니면 쉽지 않은 것이다. 

그래도 OSS Cloud Foundry 가 매력적인것은 당연하다. 괜히 I 사나 H 사가 가져다가 자사의 IaaS 에 올리고 있는것이 아니다. 클라우드는 결국 애플리케이션의 구동을 위해 필요한 것이며, 이 애플리케이션의 구동을 더욱 쉽게 해 주는 도구이기 때문에. 

Cloud Foundry 의 Product Manager 의 말에 의하면, 조만간 공개될 새로운 버전의 BOSH 는 YAML 이 지옥에서 현실적인 수준으로 바뀐다고 한다. 아울러 Cloud Foundry 에서 서비스 연결을 할때 원하는 "기존의" 서비스를 연계하도록 하는 것이 아니라, 원하면 BOSH 를 통해 "새롭게 배포된" 서비스를 할당할 수 있도록 더욱더 강화할 예정이라고도 한다. 

CF release 211 때 한번 격렬하게 삽질했다가 이번에 밋업 준비하면서 233 release 에 또한번 격렬한 삽질을 하고 보니 이거 지속적으로 한번씩은 해 줘야 감을 유지하겠구나 싶다. ㅎ 

엔터프라이즈라면 OSS 말고 PCF 를 씁니다. 거기에는 OpsManager 라는 매우 편리한 GUI Bosh 가 있거든요. 

아래는 클라우드파운드리 밋업 주소. 

만약 설치 버전이 아니라 경험만 하고 싶은 경우라면 이런 심한 고생 하실 필요가 없습니다 여러분. http://run.pivotal.io 

AWS 에 배포하는 경우라면 반드시! EC2 limit increase 가 필요합니다. 이것은 각 EC2 콘솔의 대시보드에 있으니 미리 미리 늘려두어 어머 하는 당황스러운 사태를 피합시다 그려. 집에 놀고 있는 vSphere 가 있다면 도전! 

클라우드 때문인지 오픈소스가 날이 갈수록 복잡해짐. ㅋ  

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



저작자표시 비영리
,

티스토리툴바