The Twelve-Factor App

 

🔥 The Twelve-Factor App 이라는 문서는 간단하게 설명해 SaaS (Software-as-a-Service) 앱을 어떻게 잘 설계하고 작성할 수 있을지에 대한 방법론입니다.

그리고 이 포스팅은 이 문서에 대한 정리(혹은 약간의 요약)입니다.

그렇지만 원문도 그렇게 길지 않고, 한글로도 제공하고 있으니 일독을 권해드려 봅니다 😇 😇 😇

 

p.s. 혹시 오타나 잘못된 내용이 있다면 말씀해주시면 감사드리겠습니다 😅

 

---

 

TL;DR

견고하고 유지보수가 용이한 SaaS 인 🔥 Twelve-factor app 은 다음과 같이 작동합니다 :

 

1. codebase 와 app 은 1:1 관계, app 과 배포(deploy)는 1:N 관계 - version control system 을 통한 관리
2. app 의 의존성(dependencies)은 명시적으로 선언(declaration)하고, app 간의 의존성은 분리(isolation) 한다.
3. 설정(config) 은 환경변수(environment variables) 로 관리됩니다.
4. 백엔드 서비스(backing services) 들은 app 과 느슨하게 결합되어, code 수정 없이 변경 가능해야 한다.
5. build, release, run 단계는 엄격하게 분리됩니다.
6. app 의 processes 들은 stateless 하며, 서로 아무것도 공유하지 않습니다(share-noting).
7. 완전히 독립적인(self-contained) app 으로 구성되며, port binding 을 통해 HTTP 등을 노출(export) 합니다.
   • app 이 port binding 을 한다는 것은 또다른 app 의 backing service 가 될 수 있음을 의미합니다.
8. 동시성(concurrency) 모델을 활용하여 scale out 등이 용이하도록 설계되어 있습니다
   • stateless 라는 twelve-factor app 의 특징은 이런 부분을 더 용이하게 합니다.
9. processes 들의 빠른 시작과, 종료(graceful shutdown) 를 통해 app 의 robustness, scaling 의 용이함 등을 확보합니다.
10. 개발(dev) 환경과 production 환경을 최대한 유사하게 유지하여, 이 차이에서 나오는 비용을 줄입니다.
11. 로그(logs)는 event streams 로 다뤄지며, app 은 결코 logfile 을 쓰거나 전달, 관리하는 데에 관여해서는 안됩니다.
    • stdout 으로 전달되어 출력되며, 로그를 다루는 도구들에 의해 수집되고 이용될 수 있습니다.
12. 일회성으로 일어나는 admin processes 들은, 개발/배포 환경에서 즉각 실행할 수 있는 방식으로 작성됩니다.

 

---

 

소개

오늘날 많은 소프트웨어들이 web app(or SaaS) 의 형태로 제공됩니다.

그리고 The Twelve-Factor App 은 아래의 특징을 가지는 SaaS 를 만드는 데 사용되는 방법론입니다.

 

• 선언적 형태(declarative formats)의 자동화된 설치를 통해, 새로운 개발자가 프로젝트에 참여할 때 시간과 비용을 아껴준다.
• OS 차이에 따라 달라지는 부분을 명확히 하고, 실행 환경 사이의 이식성을 극대화 한다.
• 현대적인 클라우드 플랫폼에 배포하기에 적합하고, 서버와 시스템의 관리자가 없어도 된다.
• 개발과 상품 사이의 격차를 최소화 하여, 매우 빠른 지속적 배포가 가능하다.
• 도구, 아키텍쳐, 개발 방식의 큰 변경 없이 scale up 을 할 수 있다.

 

The twelve-factor 방법론은 어떤 프로그래밍 언어에도 적용 가능하며, backing services (database, queue, memery cache 등) 의 어떠한 조합에도 적용될 수 있습니다.

 

배경

이 문서는 실제로 쓰이는 다양한 SaaS 에 대한 경험과 관찰의 결과이며, 특히 아래 3가지 상황에 집중하여 ideal practice 를 제공하고자 합니다.

 

• 시간이 지남에 따른 app 의 유기적인 성장
• app codebase 에서 작업하는 개발자들의 협업
• 소프트웨어가 낡음에 따른 비용 증가 (이를 회피하는 방법)

 

그리고 이 문서의 형식 은 Martin Fowler 의 책, Patterns of Enterprise Application Architecture 와 Refactoring 으로부터 영향을 받았습니다.

 

대상 독자

• as a Service 형태로 실행되는 application 을 만드는 개발자 누구든.
• 그리고, 그런 application 을 배포/관리하는 Ops 엔지니어 누구든.

 

---

 

01 - Codebase

Revision control system 으로 추적되는
하나의 codebase 와, 다양한 배포(deploy)

 

 

• Twelve-factor app 은 version control system (git, mercurial, subversion) 등 에 의해 항상 추적됩니다.
• codebase 는 단일 repo(subversion 처럼) 일 수도, root commit 을 공유하는 repo들의 모음(git 처럼) 일 수도 있습니다.
• codebase 와 app 은 항상 1:1 관계여야 합니다.
  • codebase 가 여러 개라면, 이는 app 이 아니라 분산 system 으로 봐야 합니다.
    • 분산 시스템 내의 각 component 들을 각기 app 으로 취급하며, 각각의 app (component) 들이 12-factor 를 따를 수 있습니다.
  •  여러 개의 app 들이 같은 code 를 공유한다면, 이는 twelve-factor 를 위반하는 것입니다.
    • 이에 대한 해결책은, 공통 code 를 라이브러리화 하고, 해당 라이브러리를 dependency manager 를 통해 포함시키는 것입니다.
• codebase 와 app 은 1:1 관계이지만, app 과 배포(deploy)는 1:N 의 관계입니다.
  
  • 배포 마다 버전이 다를 수는 있지만, codebase 자체는 기본적으로 하나입니다.
    • 예를 들어, 개발자가 stating 환경에 배포하지 않은 commit 이 있거나, staging 에서 production 환경으로 배포되지 않은 commit 이 있을 수 있지만, 이 모든 것들은 하나의 codebase 를 공유하며, 각각을 하나의 app. 에 대한 서로 다른 배포라고 볼 수 있습니다.

 

02 - Dependencies

명시적으로 선언되며, 독립적인 dependencies

 

 

대부분의 프로그래밍 언어들은 라이브러리 배포를 위한 packaging system 을 제공합니다. 이를 통해 설치된 라이브러리들은 system-wide 하게 설치 되기도 하고("site packges"), 특정 app 이 존재하는 디렉토리에 설치되기도 합니다("vendoring" or "bundling").

 

Twelve-factor apps 은 암묵적으로 존재하는 system-wide package 에 결코 의존하지 않습니다. 모든 dependencies declaration manifest 를 통해 명시적으로 선언되어야 합니다. 나아가 dependency isolation 도구를 사용해, 암묵적인 dependency 의 "유출" 을 막습니다. 이렇듯 확실한 dependency specification 은 프로덕션과 개발 양쪽에 동일하게 적용됩니다.

 

dependency declaration 도구 ≠ dependecy isolation 도구

 

예를 들면 아래와 같은 도구들이 있습니다.

• Ruby 의 Bundler
  • 의존성 선언(dependency declaration) ➡️ Gemfile
  • 의존성 분리(dependency isolation) ➡️ bundle exec
• Python
  • 의존성 선언(dependency declaration) ➡️ pip
  • 의존성 분리(dependency isolation) ➡️ Virtualenv

 

명시적 선언의 장점은 새로운 개발자가 쉽게 app. 개발 환경을 설정할 수 있다는 것입니다. 단순히 선언된 라이브러리들을 설치하는 것만으로 개발환경을 설정할 수 있습니다.

 

Twelve-factor apps 는 암묵적으로 존재하는 system 도구에도 의존하지 않습니다. 예를 들면 curl 과 같은 것입니다. 대부분의 시스템에 이러한 도구는 존재하지만, 모든 시스템에 존재하는지 보장할 수 없고, 미래에 존재하지 않을 수도 있습니다.

그러니, 만약 application 에 system 도구가 필요하다면, 그 도구를 application 과 통합해야 합니다.

 

03 - Config

환경변수(environment) 로 저장되는 설정(config)

 

 

app 의 설정(config) 은 배포 때마다 달라질 수 있는 모든 부분입니다. 설정에는 다음과 같은 것들이 포함될 수 있습니다.

• 데이터베이스, memchched 등 backing services 들에 대한 리소스 제어
• Amazon S3 나 Twitter 같은 외부 서비스에 대한 credentials
• 배포마다 달라지는 canonical hostname

 

app 은 이러한 설정을 상수(constants) 로 코드에 저장하기도 하는데, 이는 twelve-factor 를 위반하는 것입니다. Twelve-factor 는 code 와 config 사이에 엄격한 분리를 요합니다.

 

application 의 모든 설정(config) 이 분리되어있는 지 확인하는 간단한 테스트는, 어떠한 credential 의 노출 없이, codebase 가 바로 오픈소스가 될 수 있는지를 확인하는 것입니다.

 

다만 이 설정(config)의 정의는 application 내부의 설정을 의미하지는 않습니다. 예를 들어 Rails 의 config/routes.rb 나, Spring 의 코드 모듈 연결 이 어떻게 되는지 등과 같은 것들입니다. 이러한 설정들은 배포에 따라 변경되지 않기 때문에, 코드 내부에 있는 것이 좋습니다.

 

다른 방식으로는 Rails 의 config/database.yml 처럼 revison control 시스템에 등록되지 않은 설정을 이용하는 것입니다. 상수를 쓰는 것보다는 낫지만, 이 역시 너무 설정이 여기저기 분산되어 한 곳에서 확인하고, 관리하기 어려워진다는 문제가 있습니다.

 

그래서, Twelve-factor app 은 설정(config) 을 환경 변수(environment variables) 에 저장합니다.

 

Pros.

• 코드의 변경 없이, 배포마다 쉽게 설정(config) 변경 가능
• 설정 파일과 달리 repo 에 올라갈 가능성도 적음
• 언어나 OS 에 의존하지 않는 표준

 

또 달리, 설정을 배포마다 grouping 하여 여러 개의 설정을 만드는 경우도 있는데, 이는 배포 환경이 늘어날 때마다 새로운 group 의 이름이 필요해 집니다(예를 들면, development, test, production 등등). 이러한 방법은 깔끔하지 않습니다. 반면 환경 변수는 절대 group 으로 묶을 수 없지만, 각 배포마다 독립적으로 관리됩니다.

 

04 - Backing services

backing service를 연결된 리소스로서 취급

 

 

backing servcie 는 app 이 네트워크를 통해 사용하는 서비스를 의미합니다. 예를 들면 아래와 같은 서비스들입니다.

• datastores(ex. MySQL, CouchDB)
• messaging/queueing 시스템(ex. RabbitMQ, Beanstalkd)
• SMTP 서비스 (ex. Postfix)
• caching 시스템(ex. Memcached)

 

통상적으로 backing service 들은 app 을 배포하는 관리자(administrators) 에 의해 관리되지만, 서드 파티들에 의해 제공/관리 되는 서비스들을 이용할 수도 있습니다. 아래와 같은 서비스들이 바로 그러한 것들입니다.

• SMTP 서비스 (ex. Postmark)
• metrics 수집 서비스 (ex. New Relic, Loggly)
• 스토리지 서비스 - binary asset services (ex. Amazon S3)
• API 를 통해 접근가능한 서비스 (ex. Twitter, Google Maps, Last.fm)

 

Twelve-factor app 의 code 는 local 서비스와 서드 파티의 서비스를 구분하지 않습니다. app 에게 있어 둘 모두, 설정에 존재하는 URL(혹은 다른 locator)과 credentials 를 통해 연결된 리소스일 뿐입니다. 그렇기 때문에 Twelve-factor app 의 배포는 어떠한 code 의 수정 없이(설정 변경만으로) local 서비스와 서드파티 서비스 사이의 전환이 가능해야 합니다.

 

twelve-factor app 은 이러한 서비스들을 attatched resource 로 취급합니다. 이는 app 과 resource 사이가 느슨하게 결합(loose coupling)되어야 함을 의미합니다.

 

 

05 - Build, release, run

빌드, 실행 단계(stage)의 엄격한 분리

 

 

codebase 는 아래의 3단계로 배포로 전환됩니다 (개발 X)

 

• build stage
  • build 과정을 통해 code repo 를 실행 가능한 형태(excutable bundle)로 변환합니다.
  • build stage 는 dependencies 를 가져와, binaries 와 assets 들을 컴파일 합니다.

• release stage
  • release stage 에서는 build stage 에서 만들어진 build 와 deploy 의 현재 config 를 결합합니다.
  • release 의 결과는 build 와 config 모두 포함하며, 실행 환경에서 바로 실행 가능해야 합니다.

• run stage ("runtime" 이라고 불리는 단계)
  • run stage 에서는 실행 환경에서 app 을 실행(선택된 release 에 해당하는 app 의 processes 집합을 실행)합니다.

 

 

Twelve-factor app 은 이러한 build, release, run stage 를 엄격하게 분리합니다. 예를 들면, run 단계에서 code 를 변경할 수 없다는 점 등이 바로 그것입니다.

 

배포 도구(deployment tools)들은 보통 release 관리 도구도 제공합니다. 주목할 만한 포인트는 rollback 기능에 대한 것입니다. 에를 들어 Capistrano 라는 도구는 쉽게 release 를 저장하고, rollback 할수 있습니다.

 

모든 release 는 unique 한 release ID 를 가집니다(timestamp 나 sequantial number 같은). 또한 release 는 변경은 불가하며 추가만 가능합니다. 변경이 있다는 것은 곧 새로운 release 가 만들어져야 한다는 의미입니다.

 

06 - Processes

하나 이상의 statess 한 프로세스(들)로 실행되는 app

 

 

실행 환경에서 app 은 하나 이상의 processes 들로 실행됩니다. 가장 간단한 예시로는 단일 스크립트 실행 등이 있습니다 (예를 들면, python my_script.py)

 

그리고 twelve-factor app 의 processes 들은 stateless 하며 아무것도 공유하지 않습니다(share-nothing). 유지가 필요한 항목들은 database 와 같이 stateful 한 backing service 에 저장됩니다.

 

짧은 단일 transaction cache 등에는 메모리 공간이나 파일 시스템을 사용해도 됩니다(예를 들면, 대용량 파일을 다운로드하여 이를 처리하고 결과를 database 에 저장). 그러나, twelve-factor app 은 절대 이러한 cached data 나 memory 에 저장되었던 내용이 미래에도 유효할 것이라는 가정을 해서는 안됩니다.

 

django-assetpackager 같은 asset packager 들은 컴파일된 assets 들의 cache 로 filesystem을 사용합니다. Twelve-factor app  은 이러한 컴파일을 runtime 에 하는 것보다 build stage 에 하는 것을 더 권장합니다.

 

마지막으로, web systems 중에는 "sticky sessions" 에 의존하는 것들도 있습니다 - 이는 user 의 session data 를 app 의 process 메모리에 캐싱하고, 같은 유저의 미래 요청 역시 같은 방식으로 이루어 질 것을 가정하고 있습니다.

그렇기 때문에, sticky sessions 를 사용하는 것은 twelve-factor 에 위반되는 것이며, 절대로 사용하거나 의존해서는 안 됩니다. Session state 데이터는 memcached 나 redis 처럼 유효기간 기능을 가지는 datastore 를 이용하는 것이 좋습니다.

 

07 - Port binding

Port Binding 을 통한 서비스 노출(export)

 

 

Web apps 들은 webserver 컨테이너의 내부에서 실행되기도 합니다. 예를 들면 아래와 같은 것들입니다.

• PHP apps ➡️ Apache HTTPD 내부의 모듈로 실행
• Java apps ➡️ Tomcat 내부에서 실행

 

그러나, Twelve-factor app 은 완전히 독립적(completly self-contained) 이며, webserver 의 runtime injection 에 의존하지 않습니다. web app 은 특정 port 를 binding 하여 HTTP 서비스로 노출되며, 이 port 로 들어오는 요청을 기다립니다.

 

port 를 binding 한다는 것은, 하나의 app 이 또다른 app 의 backing service 가 될 수 있다는 것을 의미합니다. 즉, backing app 의 URL 을 config 에 추가하고 이를 리소스로 사용하도록 할 수 있습니다.

 

08 - Concurrency

Process model 을 통한 확장(Scale out)

 

 

모든 computer program 은 실행되면 하나 이상의 processes 들로 표현됩니다.

 

twelve-factor app 에서, processes 들은 일급 시민(a first class citizen) 입니다. twelve-factor app 은 service daemons 들의 실행을 위한 unix process 의 모델로부터 강하게 영향을 받았습니다. 이 모델을 사용하면, 개발자는 작업의 type 에 따라 process type 을 할당하여 여러 종류의 workloads 를 다룰 수 있도록 app 을 설계할 수 있습니다.

• 예를 들어, HTTP 요청은 web process 에 의해 제어되고, 오래 걸리는 작업은 worker process 에 의해 제어되는 식입니다.

 

이 모델은 프로세스의 수평확장(scale out) 에 사용될 때 가장 적합해 보입니다. 아무것도 공유하지 않고, 수평으로 분할할 수 있는 twelve-factor app 프로세스의 특징은 동시성(concurrency) 를 높이기에 적합한 모델(단순하고 안정적임)이라는 것을 보여줍니다.

 

 

Twelve-factor app processes 는 절대 daemonize 되어서는 안되며, 대신에 OS 의 프로세스 관리자(systemd 나, 클라우드 플랫폼의 process manager, Foreman 과 같은 도구) 에 의해서 output steam 을 관리하고, processes 들의 충돌이나, restart, shutdowns 등에 대응해야 합니다.

 

09 - Disposability

빠른 startup 과 graceful shutdown 을 통한
안정성(robustness) 극대화

 

 

Twelve-factor app 의 processes 들은 쉽게 폐기 가능하며, 이는 processes 들이 간단하게 시작되고 정지될 수 있음을 의미합니다. 이러한 특성은 아래의 장점들을 가집니다.

 

Pros.

• 빠르고 탄력성(elastic) 있는 scaling
• code 나 config 의 변경이 있을 경우, 빠른 배포
• production 의 배포의 안정성(robustness) 확보

 

Processes 들은 프로세스 매니저로부터 SIGTERM signal 을 받을 경우, graceful shutdown 을 합니다. 웹 프로세서의 graceful shutdown 은 아래의 과정을 포함합니다.

1. 서비스 port 의 listen 을 중지 (새로운 요청 거절)
2. 현재 처리중인 요청이 끝날때까지 대기
3. 종료

이러한 모델은 HTTP 요청이 짧다(수초 정도)는 전제조건을 깔고 있습니다. long polling 일 경우, 연결이 끊어질 때마다 client 가 재연결 요청을 해야 합니다.

 

worker process 의 경우, gracefull shutdown 은 현재 처리 중인 작업을 작업 queue 로 되돌리는 것으로 가능합니다. 예를 들면 다음과 같은 것들입니다.

• RabbitMQ ➡️ worker 가 NACK 을 큐로 보낼 수 있습니다. 
• Beanstalkd ➡️ worker 와의 연결이 끊기면 자동으로 작업을 큐로 되돌립니다.
• Delayed Job 과 같은 lock-based 시스템 ➡️ job record 에서 lock 을 해제해야 합니다.

이러한 모델은 암묵적으로 모든 작업은 재입력 가능하다고 가정하며, 결과를 트랜잭션으로 감싸거나, 요청이 멱등성을 가지도록 함으로써 구현 가능합니다.

 

마지막으로 Processes 들은 하드웨어의 에러로 인한 갑작스런 죽음에도 견고함을 가져야 합니다. 그렇게 잦은 일은 아니지만, 이러한 사태를 대비하기 위해 Beanstalkd 같은 안정적인 queueing backend 의 사용을 권장합니다.

 

Twelve-factor app 은 예기치 못한 non-graceful terminaton 에도 대응하도록 설게됩니다. Crash-only design 으로부터 이러한 컨셉을 가지고 왔습니다.

 

10 - Dev/prod parity

개발, 스테이징, 프로덕션 환경을 가능한 한 비슷하게 유지

 

 

역사적으로, 개발 환경과 production 환경은 아래의 3가지 영역에 걸쳐 차이(gap)를 가집니다.

 

• 시간의 차이
  • 개발자가 작업하는 코드가 production 에 반영되기까지 수 일, 수 개월의 시간이 걸릴 수 있습니다.
• 담당자의 차이
  • 개발자는 code 를 쓰지만, ops 엔지니어가 이를 배포합니다.
• 도구의 차이
  • 개발자는 nginx, sqlite, OS X의 환경을 사용하지만, production 환경은 Apache MySQL, Linux와 같은 환경을 사용합니다.

 

Twelve-factor app 은 개발과 production 사이의 gap 을 줄여, CD(continuous deployment, 지속적 배포) 가 가능하도록 설계되었습니다. 이러한 3가지 차이(gap) 에 대한 대응책은 다음과 같습니다.

 

• 시간의 차이 줄이기
  • 개발자가 작성한 코드를 수 시간, 혹은 수 분 내에 배포합니다.
• 담당자의 차이 줄이기
  • 코드 작성자가 production 의 배포와 모니터링에 깊게 involve 합니다.
• 도구의 차이 줄이기
  • 가능한 한 개발 환경과 production 환경을 유사하게 유지합니다.

 

	Traditional app 😐	Twelve-factor app 😁
배포 간격	몇 주	몇 시간
Code 작성자 vs. Code 배포자	다른 사람	같은 사람
개발 환경 vs. Production 환경	다른 환경	가능한 한 유사한 환경

 

그러나 사용되는 도구의 차이가 생길 수밖에 없을 수도 있습니다. 그래서 이러한 dev/prod 환경의 일치를 위해 여러 adapters 들을 제공하는 라이브러리들도 존재합니다.

 

Type	언어	Library	Adapters
Database	Ruby / Rails	ActiveRecord	MySQL, PostgreSQL, SQLite
Queue	Python / Django	Celery	RabbitMQ, Beanstalkd, Redis
Cache	Ruby / Rails	ActiveSupport::Cache	Memory, filesystem, Memcached

 

그렇지만, adapter 를 사용하여 dev/prod 환경의 차이를 두려고 사용하지 말고, 새로운 종류의 backing services 들을 사용할 경우 포팅이 용이하다는 측면으로 접근해야 합니다.

 

과거에는 개발을 위해 local 에 가벼운 서비스를 띄워 사용하곤 했지만, 오늘날 현대적인 패키지 관리자들 덕분에 production 과 같은 개발환경을 만드는 것이 어렵지 않게 되었습니다. dev/prod 환경의 일치시키는 비용에 비하면, 이러한 서비스들을 설치하는 것은 그다지 큰 비용이 아닙니다.

 

11 - Logs

Logs 를 Event stream 으로서 취급

 

 

로그(Logs) 는 실행중인 app이 어떻게 작동하는지 확인할 수 있게 해 줍니다. 보통은 disk 에 "logfile" 과 같은 형태로 저장되지만, 이는 하나의 방식에 불과합니다.

 

로그는 실행 중인 processes 들과 backing services 들의 output steams 들로부터 수집된 이벤트를 시간 순으로 정렬한 steam 입니다. (로그는 시작과 끝이 있는 것이 아니라, app 실행동안 지속되는 개념이므로)

 

Twelve-factor app 은 결코 output steam 의 전달이나 저장에 절대 관여하지 않습니다. app 은 logfiles 를 관리하거나 쓰려고 해서는 안됩니다. 대신에 실행 중인 process 는 event stream 을 버퍼링 없이, stdout 을 통해 출력합니다.

 

이러한 stream 은 실행 환경에서 수집되며, 보관될 목적지까지 전달됩니다. 이를 위해 Logflex 나 Fluentd 와 같은 오픈소스 log routers 들을 이용할 수 있습니다.

 

app 의 event stream 은 file 로 전달되거나, 터미널에 실시간으로 출력될수 있고, 가장 중요한 것은 Splunk 같은 로그 분석 시스템이나 Hadoop/Hive 와 같은 범용 data warehouse 에 저장될 수 있다는 점입니다. 이러한 시스템은 장기간 동안의 app 의 아래의 예시와 같이, 동작을 추적하고 대응하는 데에 도움을 줄 수 있습니다.

• 과거의 특정 이벤트 찾기
• 트렌드에 대한 거대한 규모의 그래프 (분당 요청의 수 등)
• user-defined heuristics 에 따른 알림 (특정 threshold 를 넘어서는 분당 error 의 양을 알리는 등)

 

12 - Admin processes

Admin / management 작업을
일회성 프로세스(one-off processes)로서 실행

 

 

process formation 은 app 의 보편적인 기능(web request 핸들링 등)을 처리하기 위한 processes 들의 집합입니다. 이와는 별개로, 개발자들은 종종 일회성의 관리나 유지보수 작업이 필요하기도 합니다. 예를 들면 다음과 같은 것들입니다.

• database migration
• 임의의 code 를 실행하거나, 라이브 database 에서 app 의 모델을 찾아보기 위해 콘솔(REPL)을 실행
• app 의 repo 에 커밋된 일회성 스크립트의 실행

 

일회성 admin processes 는, 지속적으로 실행되는 processes 들과 동일한 환경에서 실행되어야 합니다. 또한 이러한 admin processes 들은 release 기반으로 실행되기 때문에 다른 일반 processes 들과 같은 codebase 와 config 를 사용해야 합니다. admin 코드는 동기화 문제를피하기 위해서 application code 와 함께 배포되어야 합니다.

 

모든 process 타입은 같은 dependency isolation 도구(2번째 factor 참고)를 사용해야 합니다.

 

Twelve-factor 는 별도 구성이나 설치 없이 REPL shell 을 제공하는 언어를 선호합니다. 이러한 언어는 간단하게 일회성 scripts 들을 실행할 수 있게 해 주기 때문입니다.

• local 배포 시, 개발자는 app 을 checkout 한 후 scripts 를 실행하는 것으로, admin 프로세스를 실행할 수 있습니다.
• production 배포 시, ssh 나 다른 원격 command 실행 방식을 통해 admin 프로세스를 실행할 수 있습니다.

 

---

 

Ref.

https://12factor.net/

The Twelve-Factor App