안녕하세요? 이번 글은 Bluemix를 이용하여 간단한 클라우드 애플리케이션을 디자인하고 만들어 가는 과정의 마지막 글입니다. 아래와 같은 순서로 진행되었므로 참고 부탁 드립니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

애플리케이션 DevOps 환경 구성

애플리케이션 개발하는 것은 단순히 코드를 작성하는 것에서 끝나는 것이 아니라 일종의 단계를 거쳐 진행되게 됩니다.

  • 코드 작성
  • 빌드
  • 테스트
  • 배포
  • 실행

일종의 S/W Life-Cycle인데 이 개념이 Agile 개발 방법론과 MVC (Minimum Viable Product) + Feedback 반영을 통해 짧아진 개발 시간 그리고 Feedback에 따른 빈번한 코드 및 기능 변경을 따르게 됩니다.

이에 따라 통합 및 배포에 대한 표준화 및 자동화에 대한 요건이 증대되었으며, CI/CD (Continous Integration/Delivery)로 정리되었다고 볼 수 있습니다.

CI (Continuous Integration)

CI (Continuous Integration)는 여러 팀(또는 사람)이 소프트웨어를 개발하면서 서로간 영향을 줄 수 있는 다양한 기술 요소로 구성된 결과물을 지속적으로 통합 하는 것을 말합니다.

여러 사람이 다양한 기술을 적용하는 경우 형상관리 도구를 이용하여 작업하지만, 코드의 문제가 아닌 사용 기술이나 설계 복잡도의 증가로 인해 Build 오류가 발생하거나 Test 실패가 발생하는 경우도 있습니다. 그로 인해 발생할 수 있는 문제를 막으려면 자신이 개발한 코드를 적용하는 모든 개발자들은 자신들이 작성한 코드에 오류가 없는 것을 보장해야 하고, 또 그로 인해 전체적인 Build 오류나 Test 실패가 되지 않아야만 합니다.

보통은 개발, 검증, 운영계 별로 분리된 코드를 가지고 있으며 개발계에서 적용된 코드가 많아지면 많아지고 시간이 지나갈 수록 이를 운영 코드로 안정적으로 적용하는 것이 점점 어려워지게 됩니다. 이런 경우에 CI를 적용하여 언제라도 릴리즈할 수 있을 정도 수준으로 코드를 관리하고 빌드 가능한 상태로 유지합니다.

대표적으로 많이 사용하는 도구로서 Jenkins를 예를 들 수 있습니다.

코드에 대한 통합 및 빌드를 Job으로 생성하여 실행하고, 정해진 스케쥴이나 즉시 요청에 따른 Job을 Queue 기반으로 실행해 줍니다. 기본으로 제공하는 Web UI가 있어 사용자에게 있어서도 친숙하며 각종 Plugin들이 개발되어 있어 다양한 개발환경에 적용하여 사용되기도 합니다.

Jenkins에 대한 자세한 내용은 https://jenkins.io 을 참고 하시기 바랍니다.

CD (Continuous Delivery)

CD (Continuous Delivery)는 소프트웨어 개발 방법 중 하나로서 결과물이 항상 릴리즈 가능한 상태의 높은 신뢰도를 유지하면서 짧은 주기를 가지고 배포하는 것을 말합니다. 짧은 주기로 배포하는 점이 CI (Continuous Integration)와 연결되면 자연스럽게 통합된 코드의 배포로 이어지게 되므로 CD를 CI의 확장으로 여기기도 합니다.

일반적으로 빌드가 완료되면 설치 또는 실행을 위한 일종의 Package가 생성되고 이를 실행 서버 배포하게 됩니다. 전통적인 방식에서는 개발에 관련된 코드 통합와 패키지 배포는 서로 분리된 형태로 서로 다른 기술을 가진 조직 또는 사람들에 의해 수행되던 것인데, CI/CD가 도입된 상태에서는 코드 통합 순간부터 테스트와 빌드가 자동화된 형태가 됩니다. 또한 통합-빌드-테스트-배포와 같은 순차적인 형태가 되므로 이를 단계(stage)화하고 각 단계가 통과하여 최종 프로세스가 완료되는 구성을 갖추게 됩니다. 하나의 흐름으로 진행되는 모습이 물 흐르듯 한다고 해서 이를 파이프라인이라고 표현합니다.

CI/CD가 구성되면 다음과 같은 시나리오를 구성할 수 있습니다.

  1. 개발자가 소스코드 형상 관리 도구에 코드를 제출
  2. 소스 코드 제출이 이벤트 소스가 되어 해당 저장소에서 코드를 Build 환경으로 다운로드
  3. 다운로드 받은 소스 코드를 바탕으로 Rule에 따른 코드 검증 진행
  4. 소스 코드에 대한 단위 테스트 실행
  5. 소스 코드로 애플리케이션 패키지 생성
  6. 대상 서버에 애플리케이션 패키지 배포

각 단계에 대해서 문제가 발생하는 경우 통합 및 배포는 중지되며 오류에 대한 원인 및 로그가 관리자에게 보고 됩니다. 즉, 개발로부터 운영 단계까지 하나로 이어진 흐름을 일정한 형식으로 그리고 자동화된 형태가 된 것을 DevOps의 기본 구성이라고 말할 수 있습니다.

CI/CD를 통한 DevOps 환경은 개발에 대한 자신감 및 효율성을 향상시키며 일관성 없는 프로세스에서 발생할 수 있는 예상치 못한 위험 요소를 줄일 수 있게 됩니다. 또한, 테스트나 운영 환경에서 전달되는 피드백을 빨리 처리하고 반영하게 되므로 변화에 빠르게 대응 가능한 구조적인 유연함을 갖게 되는 장점이 있습니다.

Bluemix DevOps 서비스

IBM Bluemix에서는 DevOps를 서비스 형태로 제공하고 있으며 생성된 애플리케이션에 대한 코드 관리 및 Build 환경을 Continous Delivery로 구성할 수 있습니다.

또한, GitHub이나 Slack과 같은 3rd party 도구를 비롯한 다양한 open source 도구를 이용하여 DevOps 환경 구성이 가능 합니다.

IBM Garage Method와 연계한 DevOps 툴체인 템플릿도 제공하며, 이 템플릿을 기반으로 보다 손쉽게 DevOps 환경을 구성할 수 있습니다. 또한, 현재 배포된 Cloud Foundry 애플리케이션의 DevOps 환경을 위한 도구를 제공 하고 있습니다.

Bluemix의 DevOps에서는 준비된 다양한 도구를 이용할 수도 있지만 Open Toolchain 형태로 사용자가 필요한 부분도 추가해서 사용할 수 있습니다. 이에 대한 글은 별도 포스팅으로 다루도록 하겠습니다.

Continous Delivery 도구 체인 생성

이번 글에서는 지난 연재 글에서 만들어 보았던 smv-ui-app에 대해 도구 체인을 구성하도록 하겠습니다.

Bluemix 의 애플리케이션 대시 보드 화면 중 개요딜리버리 패널을 보면 현재 애플리케이션에 DevOps Continous Delivery 서비스가 구성되어 있는지 확인할 수 있으며, 만약 구성되어 있지 않은 경우 손쉽게 활성화할 수 있는 버튼을 제공합니다. 패널에서 보이는 사용버튼을 클릭하는 것만으로 바로 활성화 됩니다.

활성화가 진행되면 IBM Bluemix DevOps 화면으로 전환되며 Continuous Delivery 도구 체인을 생성 화면으로 이어집니다.

IBM Bluemix Garage Method의 기본적인 형태로 구성할 수 있도록 다음과 같은 도구와 이를 연계한 도구 체인을 제공합니다.

  • Git 저장소 및 문제 추적
  • Delivery Pipeline
  • Eclipse Orion 웹 IDE

정상적으로 도구 체인이 생성되고나면 사고(THINK)-코드(CODE)-전달(DELIVER)에 대응되는 도구가 구성된 것을 확인할 수 있습니다.

Git 저장소 및 문제 추적

Bluemix에서 제공하는 GIT 저장소와 Issue 추적은 GitLab Community Edition을 기반으로 작성된 것으로서 계정별로 제공됩니다. GitHub에서 처럼 개인 또는 팀을 구성하여 서로 협업하여 소스 코드를 관리할 수 있고 Issue와 wiki도 구성하여 사용할 수 있습니다.

파일은 최대 100MB 및 저장소 용량은 최대 1GB를 사용할 수 있으며 초과되는 경우 저장소 공간 조정에 관한 email을 받게 됩니다.

Git Repo에 대한 상세 내용은 다음 링크를 참고 하시기 바랍니다.

도구 체인 생성과 함께 애플리케이션의 기본 코드에 대한 Git 저장소가 생성되며 표준 유형(Boilerplate)이나 플랫폼 런타임에 대한 기본 템플릿을 바탕으로 Cloud Foundry앱의 코드가 자동으로 생성됩니다. 다만, 애플리케이션을 생성 후 개발이 어느 정도 진행된 상태에서 Bluemix CLI의 cf push 명령으로 배포된 경우는 템플릿과 원본 코드와는 차이가 발생할 수 있습니다. 따라서, Git Repo에 생성된 코드를 local 개발 환경으로 clone 후 원본 코드와 비교하여 Git Repo 기준으로 사용 할 초기 코드를 구성 해야 합니다.

Delivery Pipeline

Delivery Pipeline은 이 애플리케이션의 빌드, 테스트 및 배포에 대한 파이프라인을 구성 합니다.

자동 생성된 Pipeline의 경우 기본으로 Build, Deploy 두 가지 단계 (Stage)로 되어 있으며 각 스테이지 별로 원하는 형태로 구성할 수 있습니다.

환경 구성에서는 해당 스테이지를 시작을 위한 입력을 선택할 수 있습니다.

그리고, 해당 입력에 대한 작업을 구성할 수 있으며

해당 스테이지에 필요한 특정 정보를 추가하고 관리할 수 있습니다.

Eclipse Orion 웹 IDE

마지막으로, Continous Delivery에는 Git Repo와 별도로 Eclipse Orion 웹 IDE를 제공합니다. Git Repo에서도 소스를 수정하고 해당 내용을 제출할 수 있지만, 웹 IDE는 그 보다는 좀 더 소스 코드 편집 기능이 많습니다. 특히 git client가 내장되어 있고 기본으로 애플리케이션의 Git Repo와 연동되어 있습니다.

이 웹 IDE를 이용 할 때 Git Repo와 IDE간 소스 코드 동기화를 하지 않거나 git에 대한 이해 없이 바로 사용하는 경우가 혼란스럽게 느낄 수 있습니만, 이 부분만 주의하면 매우 유용한 도구로 사용할 수 있습니다.

smv-ui-app 업데이트

앞서 글들을 통해서 업데이트 된 smv-ui-app의 내용을 git repository에 적용하고 확인해 보도록 하겠습니다.

먼저 작성해 놓았던 smv-ui-app에 대한 최종 코드는 다음 URL에서 확인 해 볼 수 있습니다.

그리고, git client를 이용하여 smv-ui-app에 대한 git 저장소로부터 소스 코드를 다운로드 받습니다.

git clone https://<USERNAME>@git.ng.bluemix.net/<USERNAME>/smv-ui-app.git

<USERNAME>은 계정마다 생성되는 것으로서 각자 자신에게 맞는 정보를 입력합니다. 그리고, 비밀번호는 Bluemix 로그인 정보가 아니라 다음과 같이 Git Repo의 설정 메뉴로 진입하여 Access Tokens를 설정하고 이를 이용해야 합니다.

아래는 Access Token이 두 개 설정되어 있는 것으로 별도의 이름을 붙여 관리하도록 되어 있습니다. 초기 생성 시 관련 정보는 이후 다시 확인할 수 없으므로 생성과 동시에 별도로 잘 기억(보관)해 두도록 합니다.

git clone이 정상 동작하면 다음과 같습니다.

clone을 했다면 이제 smv-ui-app에 대한 앞서 얻은 최신 코드를 반영합니다. 그대로 덮어 쓰는 것 보다는 diff 도구를 이용하여 어떤 부분이 변경 되었는지 확인하는 것도 좋습니다.

smv-ui-app 폴더에서 git status 명령으로 현재 어떤 파일들이 변경, 추가 또는 삭제 되었는지 알 수 있습니다.

smv-ui-app은 수정 및 추가된 부분만 있으므로 git add * 명령으로 추가된 파일을 tracking 하도록 합니다. 그리고 다시 git status 명령을 실행하면 현재 추가된 정보가 나타납니다.

그런데 .eslintrc.yml 파일이 추가되지 않은 것을 볼 수 있습니다. 이 때는 git add .eslintrc.yml 명령으로 파일 직접 명시하여 추가해 줍니다.

모든 준비가 되었다면 이제 git commit -m initial 이란 명령으로 comit을 실행합니다.

현재까지는 local에 있는 git 저장소에 반영된 것이고 이를 원격의 Bluemix Git Repo에 저장하려면 다음 명령을 이용합니다.

git push origin master

이제 Git Repo 웹 대시보드에서 해당 코드가 정말로 원격으로 저장 되었는지 확인 해 볼 수 있습니다.

그리고, 파이프라인에서는 git push로 인해서 Build Stage가 자동으로 시작되어 Deploy Stage까지 이어서 진행되는 것을 확인 해 볼 수 있습니다.

이 상태에서 웹 IDE에서는 코드가 어떻게 변했는지 확인해 본 다면 GitRepo에 업데이트된 내용이 반영되지 않을 것을 볼 수 있습니다. 웹 IDE가 아닌 다른 공간(로컬 PC)에서 수정 되었으므로 Git Repo에서 최신 코드를 웹 IDE의 작업 공간으로 가져와야 합니다.

수신 항목에 윗쪽 화살표 모양의 병합 버튼을 클릭하여 GitRepo에서 가져온 정보를 웹 IDE의 저장소의 활성분기(Active Branch)로 병합합니다.

코드 병합이 잘 되었는지 웹 IDE에서 다시 한 번 확인 해 볼 수 있습니다.

smv-userauth 업데이트

이번에는 smv-userauthsmv-ui-app과 동일한 도구 체인에 등록해 보도록 하겠습니다. 별도의 도구 체인을 생성하는 것도 방법이지만 처음에 의도했던 smv의 아키텍쳐인 마이크로 서비스 아키텍쳐에 대응되는 DevOps 도구 체인의 모습으로 구성하도록 합니다.

smv-ui-app의 도구 체인 화면으로 돌아가서 화면 오른쪽에 보이는 도구 추가 버튼을 눌러 새로운 도구를 추가합니다. 새롭게 추가되는 것은 smv-userauth에 대한 GitRepo 그리고 이에 대응되는 pipeline 두 가지가 됩니다.

우선 GitRepo를 생성합니다. 기존에 smv-userauth에 대한 git 저장소가 있었다면 해당 정보를 입력합니다만, 어짜피 새로운 코드로 업데이트 해야 하는 상황이므로 아예 저장소 새로 생성하도록 합니다.

smv-userauth에 대한 GitRepo가 생성되면 다음과 같이 도구 체인에 도구가 추가된 것을 볼 수 있습니다.

이제 smv-ui-app에서와 동일한 방법으로 GitRepo에 smv-userauth에 대한 최신 코드를 적용합니다.

GitRepo에 코드를 업데이트 했다면 이제는 Pipeline을 생성할 차례입니다. smv-ui-app의 도구 체인 화면으로 돌아가서 다시 도구 추가 버튼을 눌러 Delivery Pipeline을 추가합니다.

Delivery Pipeline을 추가 할 때 앱 보기 메뉴에 앱표시는 체크하지 않는 상태로 만들어 두는게 좋습니다. 체크 상태로 놓아도 상관은 없으나 SMV는 smv-ui-app에서 사용자 UI를 담당하게 되므로 해당 부분을 나타나도록 하여 혼란스럽게 만들 필요는 없습니다.

이제 생성된 Pipeline를 클릭하여 상세 단계를 구성합니다.

빌드 단계배포 단계 두 가지 단계를 구성합니다. 단계 구성에 대한 내용은 앞서 smv-ui-app의 pipeline 정보를 참고할 수 있습니다.

먼저, 단계 추가 버튼을 눌러서 빌드 단계를 생성하도록 합니다. 입력은 GitRepo를 사용하도록 되어 있는 기본 설정을 그대로 이용합니다.

작업은 새로 추가해 주어야 합니다.

기본적인 작업 유형으로 빌드를 선택하여 추가해 줍니다.

빌더 유형은 여러가지를 제공하지만 Node.js Runtime을 사용하는 경우 별도로 구성된 Build를 따로 하지 않으므로 빌더 유형을 단순으로 선택 합니다.

저장 버튼을 눌러 단계 생성을 완료합니다. 그리고 Pipeline 화면에서 다시 단계 추가 버튼을 눌러 배포에 대한 단계를 추가합니다. 이 단계에 앞서 Build 단계가 있으므로 기본으로 설정된 입력 유형이 GIT 저장소 대신 아티팩트 빌드가 설정되어 있는 것을 볼수 있습니다.

마찬가지로 Deploy 단계에 맞는 작업을 추가해 줍니다. 이번엔 작업 유형배치를 선택합니다.

배치 작업에 맞는 설정 화면에서 해당 앱이 배포될 계정과 지역 및 작업 공간 등을 명확하게 설정합니다.

그리고 저장을 눌러 정보를 단계 생성을 완료합니다.

이제 만들어 놓은 각 단계를 확인해 볼 차례입니다. Build 단계입력 기본 설정이 GitRepo에 새로운 코드를 추가하거나 기존 코드를 변경하여 push 이벤트가 발생하면 Build 단계가 실행이므로 이를 이용할 수도 있겠습니다만, 이는 코드 변경에 따른 자동화 빌드/배포 단계이므로, 그보다는 단계 화면 오른쪽 상단의 톱니바퀴 버튼 옆 단계 실행을 클릭하여 해당 단계를 수동으로 실행하는 방법을 이용합니다.

마지막으로 이름으로 인한 혼란을 줄이도록 도구 체인의 이름을 smv-ui-app에서 다른 smv-toolchain이란 이름으로 바꾸도록 합니다.

도구 체인 화면 오른쪽 상단 버튼을 클릭하면 이름 바꾸기 메뉴를 선택 할 수 있습니다.

적당한 이름으로 smv-toolchain을 입력하여 이름 변경을 완료합니다.

그리고, 추가로 이 도구 체인과 연결된 앱이 어떤 것인지 확인 해 볼 수 있습니다. 도구 체인 화면 왼쪽 메뉴 중 연결 항목을 선택하면 아래와 같이 두 가지 앱이 연결 된 것을 볼 수 있습니다.

그리고 이 도구 체인을 대표하는 UI 앱은 smv-ui-app 하나만 보여지는 것을 확인할 수 있습니다.

이렇게 소스 코드의 형상 관리와 Tool chain의 파이프라인으로 구성된 DevOps 환경을 간략하게나마 구성해 보았습니다. Pipeline 이후에 Slack이나 다른 도구를 연결하는 방법도 있으니 나머지 각각의 smv 서비스 들을 추가하면서 각각 자신이 원하는 모습의 DevOps 환경을 구성할 수 있을 것입니다.

연재를 마치며

클라우드 환경에 대한 이해를 시작으로, 애플리케이션 구상 및 요건 분석, 아키텍쳐 설계, 클라우드 서버 환경 및 애플리케이션 개발 환경 준비, 프로토 타입 개발 그리고 DevOps 환경 구성까지 하나의 애플리케이션을 만들어지는 과정을 최대한 보여드리고자 했지만, 좀 더 잘하고 싶은 마음과 따라주지 못한 역량이 겹치면서 여러가지로 아쉬운 결과로 이어져 죄송한 마음이 듭니다. 그럼에도 불구하고 응원해 주시고 연재 또한 마무리 할 수 있게 도와 주신 많은 분들께 감사 말씀 드리며 연재를 마칩니다.

감사합니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

참고

2 개의 댓글"클라우드 애플리케이션 따라해보기 #10
애플리케이션 DevOps 환경 구성"

  1. 박태웅 8월 02, 2017

    너무 깔끔한 정리네요. 고맙습니다!!

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.