$ bin/detect <BUILD_DIR>검출 스크립트를 호출할 때 전달되는 인자 값은, 빌드 디렉터리(BUILD_DIR)이다. 빌드 디렉터리는 어플리케이션 파일들이 위치한 디렉터리로써, 스크립트는 파일들을 검사하여 빌드팩 적용 여부를 결정한다. 배포하는 어플리케이션이 빌드팩에서 지원하는 유형이라면, ‘0’ 종료 값을 리턴한다. 스크립트가 ‘0’을 리턴하면, 검출된 환경의 이름을 사용자에게 출력한다.
검출 스크립트에는 적용 여부를 판단할 수 있는 “기준”이 제시되어야 한다. 아래는 루비 어플리케이션을 검출하는 예를 보여준다. 예제 스크립트는 “Gemfile”을 존재여부를 기준으로하여, Ruby 환경을 검출하고 사용자에게 이를 출력한다.
$ bin/compile <BUILD_DIR> <CACHE_DIR>컴파일 스크립트를 호출할 때 전달되는 인자 값 2개는, 빌드 디렉터리(BUILD_DIR)와 캐시 디렉터리(CACHE_DIR)이다. 캐시 디렉터리는 빌드팩 컴파일 프로세스 동안 다운로드 하는 종속성들을 임시로 저장하는데 사용 할 수 있다. 스크립트 실행 중 사용자에게 컴파일 과정을 출력한다.
컴파일 스크립트는 빌드팩과 어플리케이션이 구동 시 필요로 하는 환경에 따라 다양하게 작성될 수 있다. 아래는 컴파일 스크립트의 간단한 작성 예를 보여준다. 해당 스크립트는 Ruby 어플리케이션을 구동시키기 위한 환경을 구성하므로, BUILD_PATH에 Ruby 인터프리터를 우선 설치하고, 환경설정이나 필요한 바이너리들을 설치하는 등의 내용을 작성한다.
$ bin/release <BUILD_DIR>릴리즈 스크립트를 호출할 때 전달되는 인자 값은, 빌드 디렉터리(BUILD_DIR)이다. 실행방법 정보는 반드시 아래와 같은 포맷의 YAML로 제공해야 한다.
config_vars에는 옵션으로 제공 할 환경변수들을 작성하며, 해당 환경변수들은 어플리케이션이 실행되는 환경에서 정의될 변수들을 의미한다. default_process_types는 실행될 어플리케이션의 유형과 실행시킬 때 사용할 명령행을 작성한다. 현재는 웹 어플리케이션 유형만을 지원한다.
아래는 릴리즈 스크립트에 작성된 응답정보의 예를 보여준다. 해당 응답정보는 Rack 어플리케이션에서 필요한 환경변수와 실행하는 방법을 포함하고 있으며, 개방형 클라우드 플랫폼에 전달된다.
Cloud Foundry의 JAVA-BUILDPACK은 소스에 포함된 Package모듈을 통해 패키지 기능을 지원한다. 패키지는 bundle exec rake 명령어를 통해 수행된다. 인자 값으로 OFFLINE=true를 사용하면, 오프라인 패키지를 생성할 수 있고, VERSION=<VERSION> 인자 값을 사용하면 패키지 이름에 버전 정보를 추가할 수 있다.1\$ bundle installCopied!1\$ bundle exec rake package OFFLINE=true VERSION=2.1Copied!...1\$ Creating build/java-buildpack-offline-2.1.zipCopied!bundle exec rake 명령어는 Rakefile에 정의된 Package모듈을 순서대로 실행하며, 실행 순서는 다음과 같다. 오프라인 패키지를 만드는 경우, 우선 설정파일들에 정의된 의존성들을 모두 다운로드 한다. 이후 cache.yml에 있는 remote_download값을 disables로 만들고, 패키지.zip 파일을 생성한다. 아래는 Rakefile과 Package 모듈의 일부를 보여준다.
Buildpack packager는 Cloud Foundry에서 제공하는 빌드팩 패키지 도구이다. buildpack-packager는 어플리케이션의 종속성이 아니라 빌드팩의 종속성을 캐시하는 것이다. 아래는buildpack-packager를 사용하여, RUBY 빌드팩을 패키지 하는 방법이다.# ruby-buildpack git에서 submodules(compile-extentions)를 fetch 한다.1\$ git submodule update –initCopied!# 최종 빌드팩 종속성들을 다운로드한다.1\$ BUNDLE\_GEMFILE=cf.Gemfile bundleCopied!# buildpack packager를 실행한다.1\$ BUNDLE\_GEMFILE=cf.Gemfile bundle exec buildpack-packager \[uncached | cached \]Copied!Buildpack packager는 실행 시 manifest.yml파일을 확인하므로, 해당 파일을 우선 작성해야 한다. 아래는 manifest.yml 파일의 작성 예를 보여준다.
packager는 manifest.yml의exclude_files에 명시된 파일들을 제외한 빌드팩 디렉터리의 모든 것을 패키지 파일에 추가한다. cached 옵션으로 실행한 경우, manifest.yml에 명시된 종속성들을 다운로드하고 패키지 파일에 포함한다. 즉 cached 옵션은 오프라인 패키지와 동일한 역할을 한다.
저장소는 빌드팩 컴파일 시 다운로드 하는 다양한 종속성들이 존재하는 공간이다. 저장소는 개방형 클라우드 플랫폼이 설치된 환경에 따라, 외부 또는 내부 네트워크 위치에 구성할 수 있다. 빌드팩은 저장소의 위치를 설정 및 변경할 수 있는 방법을 제공하며, 이러한 저장소 설정관련 부분은 빌드팩 소스마다 다르다. 해당 설정방법에 대해서는 4.빌드팩 확장 가이드에서 상세히 다룬다. 단, Build-packager를 사용하는 빌드팩(e.g. ruby)의 경우, 앞서 패키지에서 설명한 manifest.yml 파일의 dependencies:uri 항목에 다운로드 할 저장소 위치 및 라이브러리 정보를 작성한다.
기존의 컴포넌트들은 위에서 설명한 기본 클래스들을 확장하여 구현되었다. 또한 기본 컴포넌트 클래스들은 각각 아래와 같은 초기화 메소드(initialize)를 가지며, Context를 파라미터로 받는다.
Context는 컴포넌트에 의해 사용되는 유틸리티의 모음으로써, Application, Configuration, Droplet 3가지 항목이 있다. 인스턴스가 생성될 때 context인스턴스 변수의 키에 매칭 및 배정된다.
새로 추가하는 컴포넌트 클래스는 빌드팩의 필수 기능인 Detect, Compile, Release 메소드를 구현한다. 확장한 기본 클래스에 따라 Detect 기능은 support? 메소드로 구현한다.
어플리케이션이 WEB-INF 폴더를 가지고 있고, main class가 아닐때 어플리케이션 실행을 위해 사용할 컨테이너로 tomcat이 적용된다.
위 소스코드는 tomcat과 어플리케이션 파일들의 링크를 준비하는 내용이다. 따라서 어플리케이션 파일들은 tomcat classpath에서 사용할 수 있다. 위 소스코드가 실행될 때 작업 디렉터리(working directory)는 다음과 같이 구성된다.
작업디렉터리와 함께 tomcat_instance의 컴파일 메소드를 상세히 설명하면 다음과 같다. 우선 /config/tomcat.yml 을 참고하여 tomcat 바이너리 파일을 다운로드 하고, @droplet.sandbox 디렉터리에 압축을 푼다. 그리고 리소스 폴더(/resources/tomcat/conf)의 파일들을 @droplet.sandbox/conf 로 복사한다. 이후, .app/ 폴더에 @droplet.sandbox/webapps/ROOT의 심볼릭 링크를 만들고, WEB-INF/lib에 추가 라이브러리들의 심볼릭 링크를 만든다. 단, 모든 심볼릭 링크는 상대경로를 사용한다.
위 소스코드에서는 command 메소드를 통해, tomcat의 server.xml에서 참조하는http.port 를 java 시스템변수에 추가하고, tomcat을 시작하는 명령어를 작성한다. ("./bin/catalina.sh run")