Windows에서 Vagrant, Ansible로 개발환경 구축하기.

지난 번에 포스팅한 '자바 서버 어플리케이션 개발 기반 코드(Boilerplate code) 작성하기'에서 공개한 코드를 테스트하기 위해서는 Couchbase, Redis, MySQL이 설치된 개발환경이 준비되어 있어야 하는데 하나하나 설치하기가 매우 귀찮고 시간이 걸리는 일이다. Vagrant와 배포 자동화 도구인 Ansible을 사용하여 개발환경 운영체제 뿐만 아니라 Couchbase, Redis, MySQL 설치를 자동화해서 개발환경을 손쉽게 구축해보자.

다음과 같은 구성요소를 포함한 개발환경 구축을 목표로 한다.

- Ubuntu 12.04 LTS (Precise Pangolin) 64bits
- Couchbase Server 3.0.1 Community Edition
- Redis 2.8.19 (현재 기준)
- MySQL 5.5.40 (현재 기준)

Vagrant는 https://www.vagrantup.com/downloads.html에서 받아서 설치하면 Oracle VM VIrtualBox까지 한 번에 설치가 된다. Vagrant를 통해서 개발환경 운영체제가 VirtualBox에 가상화되어 설치, 동작하게된다.

https://github.com/lekdw/book-dev-env에 Vagrant와 Ansible 설정파일을 공개해 놓았으니 그대로 이용하자. 실무에서도 배포와 관련된 설정파일은 git과 같은 SCM을 통해 관리하고 공유하면 매우 편리하다. 여기서는 git을 사용하므로 https://msysgit.github.io에서 Windows 콘솔에서 사용할 수 있는 msysgit를 받아서 설치한다. msysgit를 설치하면 따라오는 MinGW와 MSYS는 덤으로 Windows 콘솔에서 ssh 같은 POSIX 도구들을 사용할 수 있다.

적당한 위치에서 콘솔창을 열어 다음과 같이 book-dev-env 프로젝트를 clone 한다.

git clone https://github.com/lekdw/book-dev-env

위의 결과로 다음과 같은 book-dev-env 프로젝트 디렉토리와 설정 파일들이 생성된다.

vagrant 디렉토리는 Vagrantfile 설정파일과 ansible.sh 파일을 포함하는데 ansible.sh 파일은 Vagrant가 Vagrantfile에 지정된 운영체제(Ubuntu) 설치가 완료되면 바로 실행되는 쉘 스크립트이다.

Vagrantfile에서 box 즉, Guest 운영체제는 Ubuntu 12.04 LTS 64bits로 지정하고 내부 네트워크 IP 192.168.33.10를 할당하였다. 운영체제 설치가 완료되면 ansible.sh 쉘 스크립트를 Ubuntu 상에서 실행된다. 참고로 box가 실행되는 Host 운영체제에는 네트워크 IP 192.168.33.1이 할당되어 Guest 운영체제와 네트워크를 이룬다. 이제 vagrant 디렉토리에서 다음과 같은 명령어를 실행하여 설치를 시작한다.

Guest 운영체제 설치가 완료되면 ansible.sh가 실행되어 Ubuntu 패키지 저장소에서 git와 ansible을 설치하고 위에서 언급한 book-dev-env git 프로젝트를 Guest 운영체제에서도 clone하여 최종적으로 ansible.sh의 13라인과 같이 site.yml playbook이 실행된다.

ansigle-playbook -i hosts site.yml

playbook 내에는 couchbase, mysql, redis role을 차례대로 실행하도록 기술되어있고 각각의 role에서는 대상의 설치 및 초기화 task를 수행한다. 모든 설치가 완료되면 다음과 같이 Host 운영체제에서(192.168.33.1) Guest 운영체제(192.168.33.10)에 설치된 각각의 대상이 동작하고 있는지 확인이 가능하다.

Couchbase 접속 확인

MySQL 접속확인

Redis 접속확인

Cocos2d-x에서 게임 라이브 업데이트 기능을 구현하기

요즘 모바일 게임도 PC 게임과 같이 라이브 업데이트 기능을 가지고 있는 경우를 흔히 볼 수 있다. 게임 내에서 사용하는 각종 테이블, 이미지, 사운드, 스크립트 등의 리소스 파일 수정이 필요할 경우 라이브 업데이트 기능을 구현하지 않았다면 이를 수정해서 사용자에게 새로운 빌드를 배포하는데 1주일 정도까지 시간이 걸릴 수 있기 때문에 상용 게임에서 라이브 업데이트 기능은 필수라고 할 수 있다.

Cocos2d-x에는 AssetManager라는 라이브 업데이트에 사용할 수 있는 클래스를 Extension으로 제공한다. 하지만 문서화가 잘 되어있지 않고 라이브 업데이트는 코드가 잘못 동작했을 경우 발생할 수 있는 부작용이 크기 때문에 AssetManager를 분석하여 사용하는 대신에 이해하기 쉽게 간단히 라이브 업데이트 기능을 구현해 보았다.(압축 해제 루틴은 AssetManager 클래스를 그대로 참조하였다.) https://github.com/lekdw/cocos2dx-live-update에 작성한 코드를 공개하였으니 참고하기 바란다.

프로젝트에서 cocos2d 폴더와 Android, iOS 프로젝트 폴더가 생략되었으므로 Cocos2d-x 프로젝트에서 복사하여 사용하도록 한다. Update 폴더에 테스트로 만들어 놓은 업데이트 파일과 버전 파일을 라이브 업데이트를 위한 Http 서버에 복사해 놓은 후 AssetPanel.cpp의 VERSION_FILE_URL에 버전 파일 위치로 변경하고 Win32 프로젝트를 빌드하여 실행하면 다음과 같이 새로운 버전 업데이트 파일을 다운로드하여 압축을 해제하는 것을 확인할 수 있다.



다운로드한 업데이트 파일이 저장되고 압축이 해제되는 위치는 코드 상에서 FileUtils::getInstance()->getWritablePath() + "asset/"이고 번들의 Resources 디렉토리보다 파일 찾기 우선순위가 높기 설정되어 있기 때문에 업데이트된 파일과 버전 파일을 asset 디렉토리에서 읽어들이게 된다. 파일 찾기 우선순위는 AppDelegate.cpp에서 아래과 같은 코드로 변경된다.

AppDelegate.cpp

bool AppDelegate::applicationDidFinishLaunching() {
  (생략)

  // 캐쉬 디렉토리에 에셋 디렉토리가 없으면 생성한다.
  std::string assetPath = FileUtils::getInstance()->getWritablePath() + "asset/";

  if (!FileUtils::getInstance()->isDirectoryExist(assetPath))
    FileUtils::getInstance()->createDirectory(assetPath);

  // 캐쉬 디렉토리의 에셋 디렉토리에서 먼저 리소스 파일을 찾을 수 있도록 설정한다.
  // 요청하는 리소스 파일이 캐쉬 디렉토리의 에셋 디렉토리에 없을 경우는 번들 리소스 디렉토리에서 찾는다.
  std::vector searchPath;
  searchPath.push_back(assetPath);

  for (std::string path : FileUtils::getInstance()->getSearchPaths())
    searchPath.push_back(path);

  FileUtils::getInstance()->setSearchPaths(searchPath);

  (생략)
}

구현된 라이브 업데이트 기능의 실행 플로우를 그려보면 아래와 같다.

파일 다운로드는 Cocos2d-x의 network::HttpClient 클래스를 사용하는데 이 클래스 구현은 파일 다운로드 진행 상황을 알 수가 없다.다운로드 진행 상황을 Polling 방식으로 알 수 있도록 network::HttpClient 클래스가 수정되어 적용되었다.

프로세스 항목 중에서 파일 다운로드와 압축 해제 과정은 별도의 Thread에서 처리되므로 Cocos2d-x Thread가 Block되지 않도록 AssetPanel.cpp에 구현되어있다. 모든 처리가 완료된 후 프로그램을 다시 실행하면 다음과 같이 라이브 업데이트가 적용된 것을 확인할 수 있으며 Android, iOS 모두 동일하게 동작한다.

자바 서버 어플리케이션 개발 기반 코드(Boilerplate code) 작성하기

게임 서비스를 개발하다보면 비슷한 구조의 서버 어플리케이션 또는 데몬을 여러개 만들어야할 필요가 있다. 서비스 초기에는 몇 개 안되겠지만 시간이 지날수록 관리해야할 수가 기하급수적으로 늘어나 있을 것이다. 어느 회사나 서버 어플리케이션이라면 자주 사용하는 구성요소들이 대게 정해져 있기 때문에 이런 것들의 사용법을 규격화하여 어플리케이션 개발 기반 코드를 작성해 놓으면 일관성 있는 구조의 어플리케이션 개발이 가능하고 유지보수에도 큰 도움이 될 것이다. 우리 회사의 경우 모든 서버 어플리케이션은 환경설정과 로그설정 파일을 기본으로 사용할 수 있어야 하며 Netty(범용 네트워크 라이브러리), Couchbase(NoSQL), Redis(Cache), MySQL(RDBMS), Quartz(Job Scheduler), Sigar(System Infomatioin) 같이 자주 사용되는 것들의 Wrapper를 작성하고 이를 모든 프로젝트에서 공유하여 필요에 따라서 취사선택하여 사용하고 있다. https://github.com/lekdw/book-boilerplate는 간단하게 구현하여 공개한 자바 서버 어플리케이션 개발 기반 코드와 이를 이용한 게임서버 및 테스트 클라이언트 샘플 프로젝트의 소스 저장소이다.

위의 그림은 소스를 얻어와 Eclipse에서 common, gc, gs 프로젝트를 Import하여 Workspace에 추가한 모습이다. common은 어플리케이션 개발 기반 코드와 기타 공유 코드를 포함한다. 이를 공유해서 작성된 어플리케이션이 테스트 게임 클라이언트 gc와 게임서버 gs 프로젝트이다.

common 프로젝트는 다음과 같은 기능을 어플리케이션에 제공한다.

• 어플리케이션 시작 코드 (AppImpl.java) - 기본사용
• 환경설정 (AppConfig.java) - 기본사용
• Netty 범용 네트워크 라이브러리 Wrapper 코드 (AppNettyXXX.java) - 선택사용
• Couchbase NoSQL 클라이언트 라이브러리 Wrapper 코드 (AppCouchbaseXXX.java) - 선택사용
• Hibernate ORM Wrapper 코드 (AppMySQLXXX.java) - 선택사용
• Redis 클라이언트 라이브러리 Wrapper 코드 (AppRedisXXX.java) - 선택사용
• 공유 객체 (common.model 패키지) - 선택사용

common 프로젝트 내 ant 프로젝트 build.xml을 실행하면 소스를 빌드하여 lib 디렉토리 내의 jar 라이브러리 파일들을 하나의 external.jar로 묶어서 gs, gc 프로젝트내 lib 디렉토리에 복사한다. 이에 대한 자세한 설명은 지난 글 자바 코드와 외부 jar 라이브러리를 하나로 합치기를 참조한다. 어플리케이션이 common 프로젝트를 공유해서 작성되면 어플리케이션 시작 코드와 환경설정은 기본으로 사용되며 나머지는 어플리케이션의 기능에 따라서 취사선택이 가능하다.

common.model 패키지 내의 객체들은 common.storage 내의 DAO 코드를 통해서 다루어지게되는 Mapping된 POJO 객체이다. 이에 대한 자세한 설명은 지난 글 클라이언트, 서버 자바 어플리케이션에서 DTO 없이 계층 간 데이터 교환하기를 참조한다.

이제 common 프로젝트를 공유하여 게임서버 gs 프로젝트를 만들어보자. 게임서버는 다음과 같은 기능이 필요하다고 가정하고 어플리케이션 시작 코드를 계승받아 다음과 같이 시작한다.

• Http 서버
• Couchbase 연결
• MySQL 연결
• Redis 연결

App.java

App 클래스는 AppImpl 어플리케이션 시작 코드를 계승하고 AppNettyServerHandler, AppCouchbaseHander, AppMySQLHandler, AppRedisHandler 인터페이스를 구현하기만 하면 어플리케이션은 설정파일을 이용할 수 있고 Couchbase, MySQL, Redis를 사용할 수 있다.

gs 실행 시에는 conf 디렉토리를 classpath에 추가해야하며 conf 디렉토리에는 gameserver.json 환경설정 파일, log4j.properties 로그설정 파일, mysql_01.xml Hibernate 설정 파일이 존재한다. lib 디렉토리에는 위의 common 프로젝트에서 묶어서 복사된 external.jar 파일이 위치하게된다.

gameserver.json

gameserver.json에는 App에서 구현한 인터페이스에 대응하는 설정 내용이 기술되며 작성된 어플리케이션은 기술된 설정대로 초기화되어 동작된다.

위와 같이 기반 코드(Boilerplate Code)를 잘 작성해서 사용한다면 짧은 코드로 복잡한 요구를 만족하는 작업이 가능하며 어플리케이션이 표준화된 형상을 유지할 수 있으므로 유지보수성이 뛰어난 서버 어플리케이션 개발이 가능할 것이다.