public/css/screen.css0000644000175000056700000000454715226251677013371 0ustar0000000000000000body { margin: 0; padding: 0; font-family: Georgia, sans-serif; line-height: 1.5em; font-size: 12pt; } h1, h2, h3 { padding: 0; margin: 0; } h1, h2 { line-height: 1.25em; } header { margin: 0; margin-bottom: 8pt; padding-top: 12pt; padding-bottom: 26pt; border: 1px solid black; color: #fff; background: #000; font-size: 19pt; text-align: center; box-shadow: 0px 2px 12px #888; } header h1 a { background: url(/images/symbol.png) top center no-repeat; color: #FFFFFF; display: block; margin-top: 0.25em; padding-top: 100px; text-decoration: none; } section { padding-top: 16pt; text-align: center; } section h1 { font-size: 19pt; } article { padding-top: 8pt; } article, nav { margin: 0 auto; text-align: justify; } article p a, article li a { text-decoration: none; border-bottom: 1px dashed #444; color: #000; } article p a:hover, article li a:hover { color: #337; } section.concrete { background: #ccc; margin-top: 24pt; padding-top: 24pt; padding-bottom: 32pt; border-top: 8pt solid #aaa; } section.concrete h1 { font-size: 28pt; margin-bottom: 32pt; text-align: center; } section.concrete h2 { margin-top: 12pt; } section.concrete h2 a { text-decoration: none; color: #000; } section.concrete h2 a:hover { border-bottom: 2px dashed #444; color: #337; } section.concrete h3 { color: #333; font-weight: normal; } section#factor h2 { font-size: 28pt; margin-bottom: 12pt; } section#factor h3 { font-size: 17pt; font-weight: normal; color: #555; margin-bottom: 16pt; } nav { margin-top: 16pt; margin-bottom: 48pt; } nav #locales { text-align: center; } nav #locales a { color: #000; } nav #locales span { font-weight: bold; } nav #next { float: right; } nav #prev { float: left; } nav #next a, nav #prev a { display: block; font-size: 19pt; text-decoration: none; color: #000; } code { border: 1px solid #999; background: #eee; padding: 1pt 3pt; } table { padding-left: 32pt; } td, th { padding-right: 12pt; padding-bottom: 4pt; } footer { color: #999; font-size: 10pt; background: #000; padding-top: 24pt; padding-bottom: 16pt; text-align: center; padding-right: 64pt; min-height: 56pt; } footer a { color: #999; } article img { float: right; margin-left: 32pt; } article img.full { float: none; margin-left: 0; } content/fr/port-binding.md0000644000175000056700000000444515226251677014326 0ustar0000000000000000## VII. Associations de ports ### Exportez les services via des associations de ports Les applications web sont parfois exécutées à l'intérieur d'un container de serveur web. Par exemple, les applications PHP peuvent fonctionner comme un module à l'intérieur de [HTTPD, d'Apache](http://httpd.apache.org/), ou bien les applications Java peuvent fonctionner à l'intérieur de [Tomcat](http://tomcat.apache.org/). **Les applications 12 facteurs sont complètement auto-contenues** et ne se basent pas sur l'injection au moment de l'exécution d'un serveur web dans l'environnement d'exécution pour créer les services exposés au web. L'application web **expose HTTP comme un service en l'associant à un port** et écoute les requêtes qui arrivent sur ce port. Dans un environnement de développement local, le développeur visite l'URL d'un service tel que `http://localhost:5000/` pour accéder au service exporté par leur application. Durant le déploiement, une couche de routage gère le routage des requêtes depuis un nom d'hôte qui s'expose au public, vers les processus sur lequel est associé le port. Ceci est typiquement implémenté en utilisant [la déclaration de dépendances](./dependencies) pour ajouter une bibliothèque de serveur web, tel que [Tornado](http://www.tornadoweb.org/) pour Python, [Thin](http://code.macournoyer.com/thin/) pour Ruby, ou [Jetty](http://www.eclipse.org/jetty/) pour Java et autres langages basés sur la JVM. Cela se déroule entièrement dans l'espace utilisateur, c'est-à-dire, dans le code de l'application. Le contrat avec l'environnement d'exécution, c'est l'association de port pour servir les requêtes. HTTP n'est pas le seul service qui peut être exporté à l'aide d'association de ports. Presque tout type de serveur peut fonctionner à travers l'association à un port et l'écoute des requêtes entrantes. Il y a par exemple [ejabberd](http://www.ejabberd.im/) (qui parle [XMPP](http://xmpp.org/)), et [Redis](http://redis.io/) (qui parle le [protocole Redis](http://redis.io/topics/protocol)). Notez également que l'approche par association de port signifie qu'une application peut devenir le [service externe](./backing-services) d'une autre application, en fournissant l'URL de l'application externe dans la configuration de l'application qui la consomme. content/pl/dependencies.md0000644000175000056700000000616515226251677014365 0ustar0000000000000000## II. Dependencies ### Jawnie zadeklaruj i wydziel zależności Większość języków programowania oferuje narzędzia do dystrybucji dodatkowych bibliotek, takie jak [CPAN](http://www.cpan.org/) dla Perla lub [Rubygems](http://rubygems.org/) dla języka Ruby. Biblioteki zainstalowane w ten sposób mogą być dostępne dla całego systemu (określane jako "site packages") lub zakres ich działania może być ograniczony dla pojedynczego projektu lub aplikacji (określane jako "vendoring" lub "bundling"). **Aplikacja 12factor nigdy nie jest zależna od bibliotek zainstalowanych dla całego systemu.** Wszystkie zależności są dokładnie określone przez dokument zawierający ich kompletną listę (*dependency declaration manifest*). Ponadto taka aplikacja korzysta z narzędzia służącego do izolacji tych zależności podczas działania aplikacji. W ten sposób ma się pewność, że np. jakaś biblioteka nie jest przypadkiem jedną z tych zainstalowanych w zewnętrznym środowisku, w którym działa aplikacja. Inaczej podobna sytuacja mogłaby uniemożliwiać poprawne działanie aplikacji w innym środowisku, gdzie takiej biblioteki by brakowało. Pełna i dokładna specyfikacja bibliotek używanych przez aplikację jest identyczna dla zarówno środowiska developerskiego jak i produkcyjnego. Np. [Bundler](https://bundler.io/) dla Ruby'ego używa pliku `Gemfile` dla deklaracji bibliotek z których korzysta aplikacja oraz komendę `bundle exec` do izolacji tych zależności. W Pythonie istnieją dwa oddzielne narzędzia dla tych zadań -- [Pip](http://www.pip-installer.org/en/latest/) jest używany do deklaracji oraz [Virtualenv](http://www.virtualenv.org/en/latest/) do izolacji. Nawet język C posiada narzędzie [Autoconf](http://www.gnu.org/s/autoconf/) do deklaracji zależności, a statyczne wiązania mogą zapewnić izolację zależności. Bez względu na użyte narzędzia, deklaracja i izolacja zależności muszą być zawsze stosowane razem. Użycie tylko jednej z nich nie jest wystarczające by spełnić wymogi 12factor. Jedną z niewątpliwych korzyści deklaracji zależności jest uproszczenie początkowej konfiguracji aplikacji dla developera. Nowy programista może pobrać kod źródłowy z repozytorium. Następnie, posiadając wcześniej skonfigurowane środowisko danego języka i narzędzie do zarządzania jego bibliotekami, jest w stanie zainstalować wszystkie moduły i biblioteki potrzebne dla działania aplikacji przy pomocy jednej komendy. Taką komendą np. dla Ruby'ego/Bundlera jest `bundle install`, a dla Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) jest to `lein deps`. Aplikacje zgodne z 12factor również nie są zależne od systemowych narzędzi. Wśród przykładów można wymienić ImageMagick czy też `curl`. Pomimo, że narzędzia te mogą być dostępne na wielu lub nawet większości systemów, nie ma gwarancji, że będą istniały na wszystkich środowiskach, w których będzie uruchamiana aplikacja w przyszłości lub że ich wersja będzie kompatybilna. Jeśli aplikacja korzysta z jakiegokolwiek systemowego narzędzia, powinno być ono osobno do niej dołączone. content/tr/who.md0000644000175000056700000000024215226251677012534 0ustar0000000000000000Bu belgeyi kim okumalı? ======================= Herhangi bir çalışan uygulama geliştirenler. Bu tür uygulamaları dağıtan ve yöneten Ops mühendisleri. content/fr/intro.md0000644000175000056700000000242415226251677013060 0ustar0000000000000000Introduction ============ À l'époque actuelle, les logiciels sont régulièrement délivrés en tant que services : on les appelle des *applications web* (web apps), ou *logiciels en tant que service* (*software-as-a-service*). L'application 12 facteurs est une méthodologie pour concevoir des logiciels en tant que service qui : * Utilisent des formats déclaratifs pour mettre en oeuvre l'automatisation, pour minimiser le temps et les coûts pour que de nouveaux développeurs rejoignent le projet; * Ont un **contrat propre** avec le système d'exploitation sous-jacent, offrant une **portabilité maximum** entre les environnements d'exécution; * Sont adaptés à des **déploiements** sur des **plateformes cloud** modernes, rendant inutile le besoin de serveurs et de l'administration de systèmes; * **Minimisent la divergence** entre le développement et la production, ce qui permet le *déploiement continu* pour une agilité maximum; * et peuvent **grossir verticalement** sans changement significatif dans les outils, l'architecture ou les pratiques de développement; La méthodologie 12 facteurs peut être appliquée à des applications écrites dans tout langage de programmation, et qui utilisent tout type de services externes (base de données, file, cache mémoire, etc.) content/pt_br/port-binding.md0000644000175000056700000000413615226251677015022 0ustar0000000000000000## VII. Vínculo de Portas ### Exporte serviços via vínculo de portas Apps web as vezes são executadas dentro de container de servidor web. Por exemplo, apps PHP podem rodar como um módulo dentro do [Apache HTTPD](http://httpd.apache.org/), ou apps Java podem rodar dentro do [Tomcat](http://tomcat.apache.org/). **O aplicativo doze-fatores é completamente auto-contido** e não depende de injeções de tempo de execução de um servidor web em um ambiente de execução para criar um serviço que defronte a web. O app web **exporta o HTTP como um serviço através da vínculação a uma porta**, e escuta as requisições que chegam na mesma. Num ambiente de desenvolvimento local, o desenvolvedor visita a URL de um serviço como `http://localhost:5000/` para acessar o serviço exportado pelo seu app. Num deploy, uma camada de roteamento manipula as requisições de rotas vindas de um hostname público para os processos web atrelados às portas. Isso é tipicamente implementado usando [declaração de dependências](./dependencies) para adicionar uma biblioteca de servidor ao app, tal como [Tornado](http://www.tornadoweb.org/) para Python, [Thin](http://code.macournoyer.com/thin/) para Ruby, ou [Jetty](http://www.eclipse.org/jetty/) para Java e outra linguagens baseadas na JVM. Isso acontece completamente no *espaço do usuário*, isso é, dentro do código do app. O contrato com o ambiente de execução é vincular a uma porta para servir requisições. HTTP não é o único serviço que pode ser exportado via vínculo de portas. Quase todos os tipos de software servidores podem rodar via um processo vinculado a uma porta e aguardar as requisições chegar. Exemplos incluem [ejabberd](http://www.ejabberd.im/) (comunicando via [XMPP](http://xmpp.org/)), e [Redis](http://redis.io/) (comunicando via [protocolo Redis](http://redis.io/topics/protocol)). Note que a abordagem de vincular portas significa que um app pode se tornar o [serviço de apoio](./backing-services) para um outro app, provendo a URL do app de apoio como um identificador de recurso na [configuração](./config) para o app consumidor. content/th/config.md0000644000175000056700000001450015226251677013174 0ustar0000000000000000## III. Config ### จัดเก็บการตั้งค่า (config) ไว้ในสิ่งแวดล้อมของระบบ *การตั้งค่า (config)* ของ app เป็นสิ่งที่เปลี่ยนแปลงระหว่าง [deploys](./codebase) (staging, production, developer environments เป็นต้น) รวมทั้ง: * ทรัพยากรที่จัดการกับฐานข้อมูล, Memcached, และ [backing services](./backing-services) อื่นๆ * ข้อมูลประจำตัว (credentials) สำหรับบริการภายนอก อย่างเช่น Amazon S3 หรือ Twitter * ค่า Pre-deploy อย่างเช่น canonical hostname สำหรับ deploy บางครั้ง app เก็บการตั้งค่าเป็นค่าคงทีใน code เป็นการละเมิด twelve-factor ซึ่งต้องการให้ **แยกการตั้งค่าออกจาก code อย่างสมบูรณ์** การตั้งค่าสามารถเปลี่ยนแปลงได้ตาม deploy ที่ไม่อยู่ใน code การทดสอบ litmus เพื่อดูว่า app มีการเอาการตั้งค่าทั้งหมดออกจาก code ถูกต้องหรือไม่ ทำให้ codebase สามารถ open source ได้ตลอดเวลา โดยไม่กระทบกับ credential ใดๆ โปรดทราบว่าการนิยามนี้ของ "การตั้งค่า" **ไม่**รวมการตั้งค่า internal application อย่างเช่น `config/routes.rb` ใน Rails หรือ [code modules เชื่อมต่อกันอย่างไร](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) ใน [Spring](http://spring.io/) ชนิดของการตั้งค่าเหล่านี้ไม่เปลี่ยนแปลงตาม deploy และควรจะอยู่ใน code อีกวิธีการหนึ่งของการตั้งค่าคือการใช้ไฟล์การตั้งค่าซึ่งไม่รวมไว้ใน revision control อย่างเช่น `config/database.yml` ใน Reals ซึ่งเป็นการพัฒนาสำหรับการใช้ค่าคงที่ซึ่งถูกรวมเข้าไปใน code repo แต่ก็ยังมีจุดอ่อนคือมันจะเกิดความผิดพลาดจากการที่รวมค่าการตั้งค่านี้เข้าไปใน repo จะทำให้มีแนวโน้มที่การไฟล์การตั้งค่าจะกระจายอยู่ในที่แตกต่างกันและแตกต่างรูปแบบ ทำให้มันยากที่จะดูแลและจัดการการตั้งค่าทั้งหมดในหนึ่งที่ นอกจากนี้รูปแบบเหล่านี้ยังขึ้นอยู่กับภาษาคอมพิวเตอร์ หรือ เฉพาะ framework. **Twelve-factor app เก็บการตั้งค่าไว้ใน *environment variable*** (เรียกสั้นๆ ว่า *env vars* หรือ *env*) Env vars จะทำให้ง่ายที่จะเปลี่ยนแปลงระหว่าง deloy โดยปราศจากการเปลี่ยนแปลงของ code ใดๆ ไม่เหมือนกับไฟล์การตั้งค่าที่จะมีโอการผิดพลาดที่จะรวมเข้าไปใน code repo ได้ และไม่เหมือนกับไฟล์การตั้งค่าที่กำหนดเองหรือกลไกการตั้งค่าอื่นๆ อย่างเช่น Java System Properties ที่เป็ของภาษาคอมพิวเตอร์ และมาตรฐานของระบบปฏิบัติการ (OS-agnostic) อีกแง่มุมของการจัดการการตั้งค่าคือการจัดกลุ่ม (Grouping) บางครั้งการตั้งค่า app แบบกลุ่ม (batch) ในชื่อของกลุ่ม (เรียกว่า "environment") หลังจาก deploy เฉพาะ อย่างเช่น `development`, `test` และ `production` environment ใน Rails วิธีการนี้ทำให้การขยายไม่เรียบร้อยทำให้มี deploy ของ app ถูกสร้างมากขึ้น, จำเป็นต้องตั้งชื่อของ environment ใหม่ อย่างเช่น `staging` หรือ `qa` เป็นตั้น เมื่อ project โตขึ้น developer อาจจะเพิ่ม environments เฉพาะของตัวเองขึ้นมา เช่น `joes-staging` ผมก็คือมีการตั้งค่าจำนวนมากเกินไปซึ่งทำให้จัดการ deploy ของ app ทำได้ยากมาก ใน twelve-factor app, env vars เป็นรากฐานการควบควมของแต่ล่ะ evn vars อื่นๆ ไม่เคยมีการจัดกลุ่มเป็น "environments" แต่จะจัดการแบบอิสระสำหรับแต่ล่ะ deploy แทน นี่เป็นรูปแบบที่การขยายทำได้อย่างราบรื่นของ app เป็นการขยายโดยธรรมชาติของ deploy มากขึ้นตลอดอายุการทำงานของ app. content/fr/dependencies.md0000644000175000056700000000612315226251677014353 0ustar0000000000000000## II. Dépendances ### Déclarez explicitement et isolez les dépendances La plupart des langages de programmation offrent des systèmes pour créer des paquets à partir de bibliothèques afin de les distribuer, tel que [CPAN](http://www.cpan.org/) pour Perl ou [Rubygems](http://rubygems.org/) pour Ruby. Les bibliothèques installées à travers un système de packaging peuvent être installées à travers tout le système, ou bien limitées au répertoire contenant l'application (que l'on appelle les "vendor" ou "bundles"). **Une application 12 facteurs ne dépend jamais de l'existence implicite de packages au niveau du système**. Elle déclare toutes ses dépendances, complètement et exactement, à travers un manifeste de *déclaration de dépendances*. De plus, elle utilise un outil d'isolation des dépendances durant l'exécution afin d'assurer qu'aucune dépendance implicite ne s'introduise depuis le système environnant. Les spécifications complètes et explicites sont appliquées uniformément en développement comme en production. Par exemple, [Bundler](https://bundler.io/) pour Ruby fournit le format de manifeste `Gemfile` pour la déclaration des dépendances, ainsi que la commande `bundle exec` pour l'isolation des dépendances. En python, il y a deux outils séparés pour ces étapes -- [Pip](http://www.pip-installer.org/en/latest/) est utilisé pour la déclaration et [Virtualenv](http://www.virtualenv.org/en/latest/) pour l'isolation. Même le C dispose d'[Autoconf](http://www.gnu.org/s/autoconf/) pour les déclarations de dépendances, et la liaison statique peut fournir l'isolation des dépendances. Peu importe la chaîne d'outils, la déclaration et l'isolation des dépendances doivent toujours être utilisées ensemble -- seulement l'un ou l'autre ne suffit pas à satisfaire les 12 facteurs. Un des bénéfices de la déclaration explicite des dépendances est que cela simplifie la mise en place pour les développeurs qui découvrent l'application. Les nouveaux développeurs peuvent jeter un œil à la base de code de l'application sur leur machine de développement, en ayant besoin uniquement d'avoir de quoi exécuter le langage ainsi que le gestionnaire de dépendances installé en pré-requis. Ils pourront mettre en place tout ce qui est nécessaire pour faire fonctionner le code de l'application de manière déterministe grâce à une *commande d'assemblage* (commande de build). Par exemple, la commande d'assemblage pour Ruby/Bundler est `bundle install`, alors que pour Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) c'est `lein deps`. Les applications 12 facteurs ne s'appuient pas sur l'existence implicite d'outils système, par exemple ImageMagick ou `curl`. Bien que ces outils puissent exister sur beaucoup voire la plupart des systèmes d'exploitation, il n'y a pas de garantie qu'ils existeront sur tous les systèmes où l'application sera exécutée à l'avenir, ou si la version disponible sur un système futur sera compatible avec l'application. Si l'application dépend d'un outil système, cet outil doit être distribué avec l'application. content/pl/port-binding.md0000644000175000056700000000443015226251677014324 0ustar0000000000000000## VII. Przydzielanie portów ### Udostępniaj usługi przez przydzielanie portów Zdarza się, że aplikacje internetowe uruchamiane są w ramach serwera web. Napisane w PHP np. działają jako moduł [Apache HTTPD](http://httpd.apache.org/), natomiast aplikacje w Javie mogą być uruchomiane wewnątrz serwera aplikacji, np. [Tomcat](http://tomcat.apache.org/). **Aplikacja 12factor nie posiada zewnętrznych zależności** co czyni ją niezależną wobec innych modułów znajdujących się na serwerze. Aplikacja internetowa **udostępniać będzie np. HTTP w formie usługi przez przydzielenie portu**. Umożliwia jej to obsługę zapytań przychodzących do wybranego portu. Aby skorzystać z usługi udostępnionej przez aplikację, developer może otworzyć adres URL jak np. `http://localhost:5000/`. W przypadku aplikacji wdrożonej w środowisku produkcyjnym zapytania do udostępnionej publicznie nazwy hosta są obsługiwane przez warstwę nawigacji. Kierowane są one później do procesu sieciowego udostępnionego na danym porcie. Kwestię obsługi takich zapytań można rozwiązać dodając bibliotekę webservera jako kolejną [zewnętrzną zależność](./dependencies), jak np. [Tornado](http://www.tornadoweb.org/) w Pythonie, [Thin](http://code.macournoyer.com/thin/) w Ruby, lub [Jetty](http://www.eclipse.org/jetty/) dla Javy i innych języków opierających się na JVM. Obsługa zapytania jest całkowicie oprogramowana przez kod aplikacji, natomiast kontraktem ze środowiskiem wykonawczym jest przydzielenie portu w celu obsłużenia tego zapytania. HTTP nie jest jedyną usługą, którą możną eksportować przez przydzielenie portu. Niemal każdy rodzaj oprogramowania serwerowego może być uruchomiony przez przydzielenie portu na którym jest uruchomiony proces i oczekiwać na przychodzące zapytania. Do przykładów należą [ejabberd](http://www.ejabberd.im/) (komunikujący się przez [XMPP](http://xmpp.org/)), oraz [Redis](http://redis.io/) (komunikujący się przez [Redis protocol](http://redis.io/topics/protocol)). Warto również zauważyć, że przez przydzielnie portu aplikacja może pełnić funkcję [usługi wspierającej](./backing-services) dla innej aplikacji przez udostępnienie swojego adresu URL jako adres zasobu w [konfiguracji](./config) tejże aplikacji. content/en/admin-processes.md0000644000175000056700000000406715226251677015021 0ustar0000000000000000## XII. Admin processes ### Run admin/management tasks as one-off processes The [process formation](./concurrency) is the array of processes that are used to do the app's regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as: * Running database migrations (e.g. `manage.py migrate` in Django, `rake db:migrate` in Rails). * Running a console (also known as a [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) shell) to run arbitrary code or inspect the app's models against the live database. Most languages provide a REPL by running the interpreter without any arguments (e.g. `python` or `perl`) or in some cases have a separate command (e.g. `irb` for Ruby, `rails console` for Rails). * Running one-time scripts committed into the app's repo (e.g. `php scripts/fix_bad_records.php`). One-off admin processes should be run in an identical environment as the regular [long-running processes](./processes) of the app. They run against a [release](./build-release-run), using the same [codebase](./codebase) and [config](./config) as any process run against that release. Admin code must ship with application code to avoid synchronization issues. The same [dependency isolation](./dependencies) techniques should be used on all process types. For example, if the Ruby web process uses the command `bundle exec thin start`, then a database migration should use `bundle exec rake db:migrate`. Likewise, a Python program using Virtualenv should use the vendored `bin/python` for running both the Tornado webserver and any `manage.py` admin processes. Twelve-factor strongly favors languages which provide a REPL shell out of the box, and which make it easy to run one-off scripts. In a local deploy, developers invoke one-off admin processes by a direct shell command inside the app's checkout directory. In a production deploy, developers can use ssh or other remote command execution mechanism provided by that deploy's execution environment to run such a process. content/en/dependencies.md0000644000175000056700000000477615226251677014362 0ustar0000000000000000## II. Dependencies ### Explicitly declare and isolate dependencies Most programming languages offer a packaging system for distributing support libraries, such as [CPAN](http://www.cpan.org/) for Perl or [Rubygems](http://rubygems.org/) for Ruby. Libraries installed through a packaging system can be installed system-wide (known as "site packages") or scoped into the directory containing the app (known as "vendoring" or "bundling"). **A twelve-factor app never relies on implicit existence of system-wide packages.** It declares all dependencies, completely and exactly, via a *dependency declaration* manifest. Furthermore, it uses a *dependency isolation* tool during execution to ensure that no implicit dependencies "leak in" from the surrounding system. The full and explicit dependency specification is applied uniformly to both production and development. For example, [Bundler](https://bundler.io/) for Ruby offers the `Gemfile` manifest format for dependency declaration and `bundle exec` for dependency isolation. In Python there are two separate tools for these steps -- [Pip](http://www.pip-installer.org/en/latest/) is used for declaration and [Virtualenv](http://www.virtualenv.org/en/latest/) for isolation. Even C has [Autoconf](http://www.gnu.org/s/autoconf/) for dependency declaration, and static linking can provide dependency isolation. No matter what the toolchain, dependency declaration and isolation must always be used together -- only one or the other is not sufficient to satisfy twelve-factor. One benefit of explicit dependency declaration is that it simplifies setup for developers new to the app. The new developer can check out the app's codebase onto their development machine, requiring only the language runtime and dependency manager installed as prerequisites. They will be able to set up everything needed to run the app's code with a deterministic *build command*. For example, the build command for Ruby/Bundler is `bundle install`, while for Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) it is `lein deps`. Twelve-factor apps also do not rely on the implicit existence of any system tools. Examples include shelling out to ImageMagick or `curl`. While these tools may exist on many or even most systems, there is no guarantee that they will exist on all systems where the app may run in the future, or whether the version found on a future system will be compatible with the app. If the app needs to shell out to a system tool, that tool should be vendored into the app. content/en/disposability.md0000644000175000056700000000525615226251677014605 0ustar0000000000000000## IX. Disposability ### Maximize robustness with fast startup and graceful shutdown **The twelve-factor app's [processes](./processes) are *disposable*, meaning they can be started or stopped at a moment's notice.** This facilitates fast elastic scaling, rapid deployment of [code](./codebase) or [config](./config) changes, and robustness of production deploys. Processes should strive to **minimize startup time**. Ideally, a process takes a few seconds from the time the launch command is executed until the process is up and ready to receive requests or jobs. Short startup time provides more agility for the [release](./build-release-run) process and scaling up; and it aids robustness, because the process manager can more easily move processes to new physical machines when warranted. Processes **shut down gracefully when they receive a [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** signal from the process manager. For a web process, graceful shutdown is achieved by ceasing to listen on the service port (thereby refusing any new requests), allowing any current requests to finish, and then exiting. Implicit in this model is that HTTP requests are short (no more than a few seconds), or in the case of long polling, the client should seamlessly attempt to reconnect when the connection is lost. For a worker process, graceful shutdown is achieved by returning the current job to the work queue. For example, on [RabbitMQ](http://www.rabbitmq.com/) the worker can send a [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); on [Beanstalkd](https://beanstalkd.github.io), the job is returned to the queue automatically whenever a worker disconnects. Lock-based systems such as [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) need to be sure to release their lock on the job record. Implicit in this model is that all jobs are [reentrant](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), which typically is achieved by wrapping the results in a transaction, or making the operation [idempotent](http://en.wikipedia.org/wiki/Idempotence). Processes should also be **robust against sudden death**, in the case of a failure in the underlying hardware. While this is a much less common occurrence than a graceful shutdown with `SIGTERM`, it can still happen. A recommended approach is use of a robust queueing backend, such as Beanstalkd, that returns jobs to the queue when clients disconnect or time out. Either way, a twelve-factor app is architected to handle unexpected, non-graceful terminations. [Crash-only design](http://lwn.net/Articles/191059/) takes this concept to its [logical conclusion](http://docs.couchdb.org/en/latest/intro/overview.html). content/it/logs.md0000644000175000056700000000477015226251677012704 0ustar0000000000000000## XI. Log ### Tratta i log come stream di eventi I *log* offrono una maggiore chiarezza riguardo un comportamento di un'app in esecuzione. In ambienti basati su server, questi sono tendenzialmente scritti su un file su disco (logfile). A ogni modo, è solo un formato. Un log può essere definito infatti come uno [stream](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) di eventi aggregati e ordinati cronologicamente. Tali eventi vengono presi da tutti i vari output stream presenti di tutti i processi attivi, oltre che dai vari backing service. Nella loro forma grezza, i log si presentano come un file di testo con un evento per ogni linea (con le dovute eccezioni). Non hanno un inizio o una fine ben definiti, ma un continuo di informazioni fin quando l'applicazione è al lavoro. **Un'applicazione twelve-factor non dovrebbe preoccuparsi di lavorare con il proprio output stream.** Non dovrebbe lavorare o comunque gestire i vari logfile. Dovrebbe, invece, fare in modo che ogni processo si occupi di scrivere il proprio stream di eventi su "`stdout`". Durante lo sviluppo in locale, quindi, lo sviluppatore potrà visionare lo stream in modo completo direttamente dal terminale, per capire meglio il comportamento della sua applicazione. In staging o in produzione, invece, ogni stream viene "preso" dall'ambiente di esecuzione ed elaborato insieme a tutti gli altri stream dell'applicazione, quindi indirizzato verso una o più "destinazioni" finali per la visualizzazione e archiviazione a lungo termine. Queste "destinazioni" non sono visibili o configurabili, ma vengono gestite totalmente dall'ambiente di esecuzione. Per questi scopi esistono strumenti come [Logplex](https://github.com/heroku/logplex) e [Fluentd](https://github.com/fluent/fluentd)). Uno stream di eventi di un'applicazione può essere quindi indirizzato verso un file, o visionato in tempo reale su un terminale. Ancora, lo stream può essere inviato a un sistema di analisi e indicizzazione di log, come [Splunk](http://www.splunk.com/), oppure a un sistema di memorizzazione general-purpose come [Hadoop/Hive](http://hive.apache.org/). Questi sistemi hanno ottimi tool per effettuare un lavoro di analisi del comportamento dell'applicazione, come per esempio: * Ricerca di specifici eventi nel passato; * Grafici per rappresentare dei trend (es. richieste per minuto); * Attivazione di alert specifici in base a regole definite dall'utente (es. alert avverte l'amministratore se il rate di eventi al minuto sale oltre una certa soglia); content/ru/config.md0000644000175000056700000001463415226251677013217 0ustar0000000000000000## III. Конфигурация ### Сохраняйте конфигурацию в среде выполнения *Конфигурация* приложения -- это всё, что может меняться между [развёртываниями](./codebase) (среда разработки, промежуточное и рабочее развёртывание). Это включает в себя: * Идентификаторы подключения к ресурсам типа базы данных, кэш-памяти и другим [сторонним службам](./backing-services) * Регистрационные данные для подключения к внешним сервисам, например, к Amazon S3 или Twitter * Значения зависимые от среды развёртывания такие, как каноническое имя хоста Иногда приложения хранят конфигурации как константы в коде. Это нарушение методологии двенадцати факторов, которая требует **строгого разделения конфигурации и кода**. Конфигурация может существенно различаться между развёртываниями, код не должен различаться. Лакмусовой бумажкой того, правильно ли разделены конфигурация и код приложения, является факт того, что кодовая база приложения может быть в любой момент открыта в свободный доступ без компрометации каких-либо приватных данных. Обратите внимание, что это определение "конфигурации" **не** включает внутренние конфигурации приложения, например такие как 'config/routes.rb' в Rails, или того как [основные модули будут связаны](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) в [Spring](http://spring.io/). Этот тип конфигурации не меняется между развёртываниями и поэтому лучше всего держать его в коде. Другим подходом к конфигурации является использование конфигурационных файлов, которые не сохраняются в систему контроля версия, например 'config/database.yml' в Rails. Это огромное улучшение перед использованием констант, которые сохраняются в коде, но по-прежнему и у этого метода есть недостатки: легко по ошибке сохранить конфигурационный файл в репозиторий; существует тенденция когда конфигурационные файлы разбросаны в разных местах и в разных форматах, из за этого становится трудно просматривать и управлять всеми настройками в одном месте. Кроме того форматы этих файлов, как правило, специфичны для конкретного языка или фреймворка. **Приложение двенадцати факторов хранит конфигурацию в *переменных окружения*** (часто сокращается до *env vars* или *env*). Переменные окружения легко изменить между развёртываниями, не изменяя код; в отличие от файлов конфигурации, менее вероятно случайно сохранить их в репозиторий кода; и в отличие от пользовательских конфигурационных файлов или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и операционной системы стандартом. Другим подходом к управлению конфигурациями является группировка. Иногда приложения группируют конфигурации в именованные группы (часто называемые "окружениями") названые по названию конкретного развёртывания, например как `development`, `test` и `production` окружения в Rails. Этот метод не является достаточно масштабируемым: чем больше различных развёртываний приложения создаётся, тем больше новых имён окружений необходимо, например `staging` и `qa`. При дальнейшем росте проекта, разработчики могут добавлять свои собственные специальные окружения, такие как `joes-staging`, в результате происходит комбинаторный взрыв конфигураций, который делает управление развёртываниями приложения очень хрупким. В приложении двенадцати факторов переменные окружения являются не связанными между собой средствами управления, где каждая переменная окружения полностью независима от других. Они никогда не группируются вместе в "окружения", а вместо этого управляются независимо для каждого развёртывания. Эта модель которая масштабируется постепенно вместе с естественным появлением большего количества развёртываний приложения за время его жизни. views/layout.erb0000644000175000056700000000361015226251677012464 0ustar0000000000000000 The Twelve-Factor App <%= I18n.t(:translation) %> <% if ENV['GOOGLE_TAG_MANAGER_ACCOUNT'] %> <% end %>

The Twelve-Factor App

<%= yield %> web.rb0000644000175000056700000000377115226251677010432 0ustar0000000000000000require 'sinatra' require 'maruku' require 'i18n' require 'rack/ssl-enforcer' configure do # For Development use only! set :host_authorization, { permitted_hosts: [] } use Rack::SslEnforcer if ENV['FORCE_SSL'] I18n.enforce_available_locales = true I18n.load_path += Dir[File.join(settings.root, 'locales', '*.yml')] # I18n.available_locales = Dir[File.join(settings.root, 'locales', '*.yml')].map { |f| File.basename(f, '.yml').to_sym } # I18n.available_locales = [:en, :pt] I18n.backend.load_translations I18n.default_locale = :en end before do I18n.locale = I18n.default_locale end before '/:locale/*' do locale = params[:locale].to_sym if locale != I18n.default_locale && I18n.available_locales.include?(locale) I18n.locale = locale request.path_info = '/' + params[:splat][0] end end get '/' do erb :home end TOC = %w(codebase dependencies config backing-services build-release-run processes port-binding concurrency disposability dev-prod-parity logs admin-processes) get '/:factor' do |factor| halt 404 unless TOC.include?(factor) @factor = factor erb :factor end helpers do def render_markdown(file) markdown = File.read("content/#{I18n.locale}/#{file}.md", :encoding => 'utf-8') Maruku.new(markdown).to_html rescue Errno::ENOENT puts "No content for #{I18n.locale}/#{file}, skipping" end def render_prev(factor) idx = TOC.index(factor) return if idx == 0 "« Previous" end def render_next(factor) idx = TOC.index(factor) return if idx == TOC.size-1 "Next »" end def render_locales(factor) I18n.available_locales.map {|locale| if locale == I18n.locale "#{I18n.t(:language)}" else path_prefix = locale == I18n.default_locale ? "" : "/#{locale}" "#{I18n.t(:language, :locale => locale)}" end }.join(" | ") end end not_found do "Page not found" end content/en/who.md0000644000175000056700000000026215226251677012513 0ustar0000000000000000Who should read this document? ============================== Any developer building applications which run as a service. Ops engineers who deploy or manage such applications. content/it/dev-prod-parity.md0000644000175000056700000001121515226251677014756 0ustar0000000000000000## X. Parità tra Sviluppo e Produzione ### Mantieni lo sviluppo, staging e produzione simili il più possibile Storicamente, ci sono sempre state differenze sostanziali tra gli ambienti di sviluppo (lo sviluppatore che effettua delle modifiche live a un [deployment](./codebase) in locale) e quello di produzione (un deployment in esecuzione raggiungibile dagli utenti finali). Differenze (o gap) che si possono raggruppare in tre categorie: * **Tempo:** uno sviluppatore può lavorare sul codice per giorni, settimane o mesi prima di poter andare in produzione; * **Personale**: gli sviluppatori scrivono il codice, gli ops effettuano il deployment; * **Strumenti**: gli sviluppatori potrebbero usare uno stack quale Nginx, SQLite e OS X, mentre in produzione per il deployment verrebbero installati Apache, MySQL e Linux. **Un'applicazione twelve-factor è progettata per il [rilascio continuo](http://avc.com/2011/02/continuous-deployment/), tenendo così queste differenze al minimo possibile.** A proposito di queste tre tipologie di differenze appena viste: * Rendi la differenze temporali minime: cerca di scrivere (o far scrivere) del codice da rilasciare nel giro di poche ore, se non minuti; * Rendi le differenze a livello di personale minime: fai in modo che gli sviluppatori siano coinvolti anche nella fase di deploy, per permettere loro di osservare il comportamento di ciò che hanno scritto anche in produzione; * Rendi le differenze a livello di strumenti minime: mantieni gli ambienti di lavoro il più simile possibile; Riassumendo tutto in una tabella:
App Tradizionale App Twelve-factor
Tempo tra i Deployment Settimane Ore
Sviluppatori e Ops Sono diversi Sono gli stessi
Sviluppo e Produzione Divergenti Il più simili possibile
I [backing service](./backing-services), come il database dell'applicazione o la cache, sono una delle aree in cui la parità degli ambienti è molto importante. Molti linguaggi offrono delle librerie che facilitano l'accesso a questi servizi, tra cui anche degli adattatori per questi tipi di servizi. Eccone alcuni:
Tipologia Linguaggio Libreria Adattatore
Database Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Code Python/Django Celery RabbitMQ, Beanstalkd, Redis
Cache Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached
Gli sviluppatori, inoltre, trovano utile usare dei servizi "leggeri" in fase di sviluppo, passando quindi a qualcosa di più serio e robusto in produzione. Per esempio, usando SQLite localmente e PostgreSQL in produzione. Ancora, un sistema di cache in locale in fase di sviluppo e Memcached in produzione. **Lo sviluppatore twelve-factor "resiste" a questa necessità**, anche se gli adapter ci sono e funzionano in modo tale da astrarre in modo sufficiente tutte le differenze nella gestione. Nulla impedisce, infatti, a qualche altra incompatibilità di uscire allo scoperto quando meno ce lo si aspetta, soprattutto se in ambiente di sviluppo funziona tutto e poi, magari, in produzione i test non vengono superati. Il costo di questa differenza può risultare abbastanza alto, soprattutto in situazioni in cui si effettua il rilascio continuo. Rispetto al passato, usare dei sistemi "light" in locale è una prassi poco convincente. Si pensi al fatto che alcuni servizi moderni come Memcached o PostgreSQL si possono installare e usare senza difficoltà tramite alcuni sistemi di packaging come [Homebrew](http://mxcl.github.com/homebrew/) e [apt-get](https://help.ubuntu.com/community/AptGet/Howto). In alternativa, esistono anche alcuni tool di provisioning come [Chef](http://www.opscode.com/chef/) e [Puppet](http://docs.puppetlabs.com/), che combinati con sistemi di ambienti virtuali come [Vagrant](http://vagrantup.com/) permettono agli sviluppatori di riprodurre in locale delle macchine molto simili, se non identiche, a quelle in produzione. Ne risente quindi positivamente il costo di deployment. Tutto questo, sia chiaro, non rende gli adapter meno utili: grazie ad essi infatti il porting verso nuovi servizi, in un secondo momento, rimane un processo indolore. Nonostante questo, comunque, rimane scontato che sarebbe buona norma usare uno stesso backing service su tutti i deployment di un'applicazione. content/zh_cn/concurrency.md0000644000175000056700000000440515226251677014752 0ustar0000000000000000## VIII. 并发 ### 通过进程模型进行扩展 任何计算机程序，一旦启动，就会生成一个或多个进程。互联网应用采用多种进程运行方式。例如，PHP 进程作为 Apache 的子进程存在，随请求按需启动。Java 进程则采取了相反的方式，在程序启动之初 JVM 就提供了一个超级进程储备了大量的系统资源(CPU 和内存)，并通过多线程实现内部的并发管理。上述 2 个例子中，进程是开发人员可以操作的最小单位。 ![扩展表现为运行中的进程，工作多样性表现为进程类型。](/images/process-types.png) **在 12-factor 应用中，进程是一等公民。**12-Factor 应用的进程主要借鉴于 [unix 守护进程模型](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/) 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的 *进程类型* 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。 这并不包括个别较为特殊的进程，例如通过虚拟机的线程处理并发的内部运算，或是使用诸如 [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), [Node.js](http://nodejs.org/) 的异步/事件触发模型。但一台独立的虚拟机的扩展有瓶颈（垂直扩展），所以应用程序必须可以在多台物理机器间跨进程工作。 上述进程模型会在系统急需扩展时大放异彩。 [12-Factor 应用的进程所具备的无共享，水平分区的特性](./processes) 意味着添加并发会变得简单而稳妥。这些进程的类型以及每个类型中进程的数量就被称作 *进程构成* 。 12-Factor 应用的进程 [不需要守护进程](http://dustin.github.com/2010/02/28/running-processes.html) 或是写入 PID 文件。相反的，应该借助操作系统的进程管理器(例如 [systemd](https://www.freedesktop.org/wiki/Software/systemd/) ，分布式的进程管理云平台，或是类似 [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) 的工具)，来管理 [输出流](./logs) ，响应崩溃的进程，以及处理用户触发的重启和关闭超级进程的请求。 content/de/dev-prod-parity.md0000644000175000056700000001115415226251677014734 0ustar0000000000000000##X. Dev-Prod-Vergleichbarkeit ### Entwicklung, Staging und Produktion so ähnlich wie möglich halten Historisch gibt es große Lücken zwischen Entwicklung (wo ein Entwickler live an einem lokalen [Deploy](./codebase) der App Änderungen macht) und Produktion (ein laufender Deploy der App, auf den Endbenutzer zugreifen). Diese Lücken zeigen sich auf drei Gebieten: * **Die Zeit-Lücke** Ein Entwickler arbeitet an Code der Tage, Wochen oder sogar Monate braucht um in Produktion zu gehen. * **Die Personal-Lücke**: Entwickler schreiben Code, Operatoren deployen ihn. * **Die Werkzeug-Lücke**: Entwickler nutzen vielleicht einen Stack wie Nginx, SQLite und OS X - die Produktion nutzt Apache, MySQL und Linux. **Die Zwölf-Faktor-App ist ausgelegt auf [Continuous Deployment](http://avc.com/2011/02/continuous-deployment/) indem sie die Lücke zwischen Entwicklung und Produktion klein hält.** Mit Blick auf die oben beschriebenen drei Lücken: * Die Zeit-Lücke klein halten: Ein Entwickler kann Code schreiben, der Stunden oder sogar Minuten später deployed wird. * Die Personal-Lücke klein halten: Entwickler die Code schreiben sind intensiv am Deployment und der Überwachung des Verhaltens auf Produktion beteiligt. * Die Werkzeug-Lücke klein halten: Entwicklung und Produktion so ähnlich wie möglich halten. Das Gesagte in einer Tabelle:
Traditionelle App Zwölf-Faktor-App
Zeit zwischen Deployments Wochen Stunden
Code-Autoren und Code-Deployer Andere Menschen Dieselben Menschen
Entwicklungs- und Produktions-Umgebung Unterschiedlich So ähnlich wie möglich
Im Bereich der [unterstützenden Dienste](./backing-services) wie der Datenbank der App, dem Queue-System oder dem Cache ist die Dev-Prod-Vergleichbarkeit wichtig. Viele Sprachen bieten Bibliotheken, die den Zugriff auf die unterstützenden Dienste vereinfachen und ebenso *Adapter* für unterschiedliche Arten von Diensten.
Art Sprache Bibliothek Adapter
Datenbank Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Queue Python/Django Celery RabbitMQ, Beanstalkd, Redis
Cache Ruby/Rails ActiveSupport::Cache Speicher, Dateisystem, Memcached
Für Entwickler ist es sehr elegant, einen leichtgewichtigen unterstützenden Dienst in der lokalen Umgebung zu benutzen, während ein ernst zu nehmender und robuster unterstützender Dienst in Produktion verwendet wird. So kann man SQLite lokal und PostgreSQL in Produktion benutzen; oder zum Cachen den lokalen Speicher in Entwicklung und Memcached in Produktion. **Der Zwölf-Faktor-Entwickler widersteht dem Drang, verschiedene unterstützende Dienste in Entwicklung und Produktion zu verwenden**, selbst wenn Adapter über alle Unterschiede hinweg abstrahieren. Unterschiede zwischen den unterstützenden Diensten verursachen kleinste Inkompatiblitäten, und Code, der in Entwicklung oder Staging funktioniert und Tests besteht, scheitert in Produktion. Diese Reibungskosten und die dann notwendige Dämpfung des Continuous Deployment sind sehr hoch, wenn man sie über die Lebensdauer einer App aggregiert. Leichtgewichtige lokale Dienste überzeugen weniger als früher. Moderne unterstützende Dienste wie Memcached, PostgreSQL und RabbitMQ sind dank moderner Paketierungs-Systeme wie [Homebrew](http://mxcl.github.com/homebrew/) und [apt-get](https://help.ubuntu.com/community/AptGet/Howto) nicht schwierig zu installieren und zu starten. Auch deklarative Installationssysteme wie [Chef](http://www.opscode.com/chef/) oder [Puppet](http://docs.puppetlabs.com/) in Kombination mit leichtgewichtigen virtuellen Umgebungen wie [Vagrant](http://vagrantup.com/) setzen Entwickler in den Stand, lokale Umgebungen ans Laufen zu bringen, die nahe an Produktionsumgebungen herankommen. Die Installations- und Betriebskosten dieser Systeme sind gering verglichen mit dem Nutzen der Dev-Prod-Vergleichbarkeit und einem Continuous Deployment. Adapter für unterschiedliche unterstützende Dienste sind weiterhin von Nutzen, weil sie das Portieren auf andere unterstützende Dienste schmerzlos machen. Aber alle Deploys der App (Entwicklungsumgebungen, Staging, Produktion) sollten denselben Typ und dieselbe Version eines jeden unterstützenden Dienstes benutzen. content/ru/logs.md0000644000175000056700000001074615226251677012716 0ustar0000000000000000## XI. Журналирование (Logs) ### Рассматривайте журнал как поток событий *Журналирование* обеспечивает наглядное представление поведения работающего приложения. Обычно в серверной среде журнал записывается в файл на диске ("logfile"), но это только один из форматов вывода. Журнал -- это [поток](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. Журнал в своём сыром виде обычно представлен текстовым форматом с одним событием на строчку (хотя трассировки исключений могут занимать несколько строк). Журнал не имеет фиксированного начала и конца, поток сообщений непрерывен, пока работает приложение. **Приложение двенадцати факторов никогда не занимается маршрутизацией и хранением своего потока вывода.** Приложение не должно записывать журнал в файл и управлять файлами журналов. Вместо этого каждый выполняющийся процесс записывает свой поток событий без буферизации в стандартный вывод `stdout`. Во время локальной разработки разработчик имеет возможность просматривать этот поток в терминале, чтобы наблюдать за поведением приложения. При промежуточном и рабочем развёртывании поток вывода каждого процесса будет захвачен средой выполнения, собран вместе со всеми другими потоками вывода приложения и перенаправлен к одному или нескольким конечным пунктам назначения для просмотра и долгосрочной архивации. Эти конечные пункты архивации не являются видимыми для приложения и настраиваемыми приложением, вместо этого они полностью управляются средой выполнения. Маршрутизаторы журналов с открытым исходным кодом (например, [Logplex](https://github.com/heroku/logplex) и [Fluentd](https://github.com/fluent/fluentd)) могут быть использованы для этой цели. Поток событий приложения может быть перенаправлен в файл или просматриваться в терминале в режиме реального времени. Наиболее значимым является то, что поток событий может быть направлен в систему индексирования и анализа журналов, такую как [Splunk](http://www.splunk.com/), или систему хранения данных общего назначения, такую как [Hadoop/Hive](http://hive.apache.org/). Эти системы обладают большими возможностями и гибкостью для досконального анализа поведения приложение в течении времени, что включает в себя: * Поиск конкретных событий в прошлом. * Крупномасштабные графики трендов (например, запросов в минуту). * Активные оповещения согласно эвристическим правилам, определяемых пользователем (например, оповещение, когда количество ошибок в минуту превышает определённый порог). content/zh_cn/intro.md0000644000175000056700000000152215226251677013550 0ustar0000000000000000简介 ============ 如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论： * 使用**标准化**流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。 * 和操作系统之间尽可能的**划清界限**，在各个系统中提供**最大的可移植性**。 * 适合**部署**在现代的**云计算平台**，从而在服务器和系统管理方面节省资源。 * 将开发环境和生产环境的**差异降至最低**，并使用**持续交付**实施敏捷开发。 * 可以在工具、架构和开发流程不发生明显变化的前提下实现**扩展**。 这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。 content/ja/port-binding.md0000644000175000056700000000541115226251677014303 0ustar0000000000000000## VII. ポートバインディング ### ポートバインディングを通してサービスを公開する WebアプリケーションはWebサーバーコンテナの内部で実行されることがある。例えば、PHPアプリケーションは[Apache HTTPD](http://httpd.apache.org/)内部のモジュールとして実行されるかもしれないし、Javaアプリケーションは[Tomcat](http://tomcat.apache.org/)の内部で実行されるかもしれない。 **Twelve-Factor Appは完全に自己完結** し、Webに公開されるサービスを作成するために、コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない。Webアプリケーションは **ポートにバインドすることでHTTPをサービスとして公開し、** そのポートにリクエストが来るのを待つ。 ローカルの開発環境では、開発者はアプリケーションによって公開されたサービスにアクセスするために、`http://localhost:5000/`のようなサービスのURLにアクセスする。本番環境ではルーティング層が、外向きのホスト名からポートにバインドされたWebプロセスへとリクエストをルーティングする。 これは一般に、[依存関係宣言](./dependencies)を使ってWebサーバーライブラリをアプリケーションに追加することで実装される。Webサーバーライブラリの例として、Pythonにおける[Tornado](http://www.tornadoweb.org/)、Rubyにおける[Thin](http://code.macournoyer.com/thin/)、Javaやその他のJVMベースの言語における[Jetty](http://www.eclipse.org/jetty/)などがある。これは *ユーザー空間* すなわちアプリケーションのコード内で完結する。リクエストを処理するための実行環境との契約は、ポートをバインドすることである。 ポートバインディングによって公開されるサービスはHTTPだけではない。ほぼすべてのサーバーソフトウェアは、ポートをバインドするプロセスを用いて動作し、リクエストが来るのを待つ。例として、[ejabberd](http://www.ejabberd.im/)（[XMPP](http://xmpp.org/)を話す）や [Redis](http://redis.io/)（[Redisプロトコル](http://redis.io/topics/protocol)を話す）などがある。 ここで注目すべきは、ポートバインディングの方法によって、あるアプリケーションが他のアプリケーションにとっての[バックエンドサービス](./backing-services)になれる点である。バックエンドアプリケーションへのURLを提供し、利用するアプリケーションの[設定](./config)にリソースハンドルとして格納すればよい。 content/th/background.md0000644000175000056700000000566215226251677014057 0ustar0000000000000000ประวัติ ========== ผู้มีส่วนร่วมของเอกสารนี้ได้มีส่วนเกี่ยวข้องโดยตรงกับการพัฒนาและการใช้งานแอพพลิเคชันจำนวนมาก และเกี่ยวข้องทางอ้อมสำหรับการพัฒนา การดำเนินงาน และการขยายขนาดของแอพพลิเคชันจำนวมมหาศาลผ่านงานของเราที่แพลตฟอร์ม Heroku เอกสารนี้สังเคราะห์จากประสบการณ์และการสังเกตทั้งหมดของพวกเราบนแอพพลิเคชัน software-as-a-service ที่หลากหลายจำนวนมาก เป็นสามเหลียมของแนวทางปฏิบัตในอุดมคติสำหรับการพัฒนาแอพพลิเคชัน ให้ความสนใจเป็นพิเศษกับพลวัตของการเจริญเติบโตของแอพพลิเคชันในช่วงเวลาหนึ่ง พลวัตของการมีส่วนร่วมระหว่างนักพัฒนาที่ทำงานกับ codebase ของแอพพลิเคชัน และหลีกเลี่ยงการใช้จ่ายของซอฟต์แวร์. แรงจูงใจของเราเพื่อสร้างความตระหนักของปัญหาระบบบางอย่างที่เราเห็นในการพัฒนาแอพพลิเคชันสมัยใหม่ เพื่อให้คำศัพย์ที่ใช้ร่วมกันสำหรับการพูดคุยเกี่ยวกับปัญหาเหล่านี้ และนำเสนอแนวทางแก้ไขแนวกว้างสำหรับปัญหาเหล่านี้พร้อมกับคำศัพท์ที่ใช้ประกอบกัน รูปแบบนี้ได้รับแรงบันดาลใจจากหนังสือของ Martin Fowler *Patterns of Enterprise Application Architecture* และ *Refactoring*. content/zh_cn/dev-prod-parity.md0000644000175000056700000000761215226251677015451 0ustar0000000000000000## X. 开发环境与线上环境等价 ### 尽可能的保持开发，预发布，线上环境相同 从以往经验来看，开发环境（即开发人员的本地 [部署](./codebase)）和线上环境（外部用户访问的真实部署）之间存在着很多差异。这些差异表现在以下三个方面： * **时间差异：** 开发人员正在编写的代码可能需要几天，几周，甚至几个月才会上线。 * **人员差异：** 开发人员编写代码，运维人员部署代码。 * **工具差异：** 开发人员或许使用 Nginx，SQLite，OS X，而线上环境使用 Apache，MySQL 以及 Linux。 **12-Factor 应用想要做到 [持续部署](http://avc.com/2011/02/continuous-deployment/) 就必须缩小本地与线上差异。** 再回头看上面所描述的三个差异: * 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。 * 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。 * 缩小工具差异：尽量保证开发环境以及线上环境的一致性。 将上述总结变为一个表格如下：
传统应用 12-Factor 应用
每次部署间隔 数周 几小时
开发人员 vs 运维人员 不同的人 相同的人
开发环境 vs 线上环境 不同 尽量接近
[后端服务](./backing-services) 是保持开发与线上等价的重要部分，例如数据库，队列系统，以及缓存。许多语言都提供了简化获取后端服务的类库，例如不同类型服务的 *适配器* 。下列表格提供了一些例子。
类型 语言 类库 适配器
数据库 Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
队列 Python/Django Celery RabbitMQ, Beanstalkd, Redis
缓存 Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached
开发人员有时会觉得在本地环境中使用轻量的后端服务具有很强的吸引力，而那些更重量级的健壮的后端服务应该使用在生产环境。例如，本地使用 SQLite 线上使用 PostgreSQL；又如本地缓存在进程内存中而线上存入 Memcached。 **12-Factor 应用的开发人员应该反对在不同环境间使用不同的后端服务** ，即使适配器已经可以几乎消除使用上的差异。这是因为，不同的后端服务意味着会突然出现的不兼容，从而导致测试、预发布都正常的代码在线上出现问题。这些错误会给持续部署带来阻力。从应用程序的生命周期来看，消除这种阻力需要花费很大的代价。 与此同时，轻量的本地服务也不像以前那样引人注目。借助于[Homebrew](http://mxcl.github.com/homebrew/)，[apt-get](https://help.ubuntu.com/community/AptGet/Howto)等现代的打包系统，诸如Memcached、PostgreSQL、RabbitMQ 等后端服务的安装与运行也并不复杂。此外，使用类似 [Chef](http://www.opscode.com/chef/) 和 [Puppet](http://docs.puppetlabs.com/) 的声明式配置工具，结合像 [Vagrant](http://vagrantup.com/) 这样轻量的虚拟环境就可以使得开发人员的本地环境与线上环境无限接近。与同步环境和持续部署所带来的益处相比，安装这些系统显然是值得的。 不同后端服务的适配器仍然是有用的，因为它们可以使移植后端服务变得简单。但应用的所有部署，这其中包括开发、预发布以及线上环境，都应该使用同一个后端服务的相同版本。 public/images/symbol.png0000644000175000056700000000370515226251677014063 0ustar0000000000000000PNG  IHDR(J< pHYs  wIDATh[e󔙦2#J(5ВAHF*n. ,ˆB+$" 0zQAif5k03/ֻ?3?3{ -bfˎ; 1QeVgkWW K2?&y d7IsCkCLƗee<3_ˎF[O6,`ljQIi}HڸOhm <1 y#ƄŲ0<5v. !2u%'ɸ9lʌ xR^YGJ#Sى?+G6?q5/r_$,NV6M8>Sk A76YķJLy=bwޜ]gwi)^ZC>tnDJbLX3z:ί%8d3'G^z9~W+h8A=^^zz^Ϻ'QҰ%+XƙDt++֨_قTo>}jR'S?@9ۉIG~,)Fpi:}+"CPò[ꫫ$鍨\UOZc2%PnVKDv+HIbթ$^s_ |(v).8~sBX$xԬsݘ_>_R1%"љ]la 8G9grTQy$9qF\wxQ_2i7̋Xi;C dVo䉛ӊ+|VkeV1׉9\~{#2_Zu&>_c)$/192/[/ǿy>c h 1RQm_8d'O ëacD>sL"9.3iy M ~G>s gnJ}ÇFe T?7}s_Oj̃sWBݸ=]zkЊDuh}U2;J$Ndޓn~8 c/ 3y3e~܎꾟PQщ 6Gܓ86Z ]`sw5Z2{djG՘gLqrvoWlتEu}Ena _,rE+2s[kźX_-3ܡ^#Zc+[/:-{8$? oz='QBFV/:^'l,zVTlWdGSy4oR_ZPUY dˌ:Io9}o2 Resources can be attached to and detached from deploys at will. For example, if the app's database is misbehaving due to a hardware issue, the app's administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached -- all without any code changes. content/en/codebase.md0000644000175000056700000000340415226251677013464 0ustar0000000000000000## I. Codebase ### One codebase tracked in revision control, many deploys A twelve-factor app is always tracked in a version control system, such as [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), or [Subversion](http://subversion.apache.org/). A copy of the revision tracking database is known as a *code repository*, often shortened to *code repo* or just *repo*. A *codebase* is any single repo (in a centralized revision control system like Subversion), or any set of repos who share a root commit (in a decentralized revision control system like Git). ![One codebase maps to many deploys](/images/codebase-deploys.png) There is always a one-to-one correlation between the codebase and the app: * If there are multiple codebases, it's not an app -- it's a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor. * Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the [dependency manager](./dependencies). There is only one codebase per app, but there will be many deploys of the app. A *deploy* is a running instance of the app. This is typically a production site, and one or more staging sites. Additionally, every developer has a copy of the app running in their local development environment, each of which also qualifies as a deploy. The codebase is the same across all deploys, although different versions may be active in each deploy. For example, a developer has some commits not yet deployed to staging; staging has some commits not yet deployed to production. But they all share the same codebase, thus making them identifiable as different deploys of the same app. content/pt_br/dev-prod-parity.md0000644000175000056700000001141615226251677015453 0ustar0000000000000000## X. Paridade entre desenvolvimento e produção ### Mantenha o desenvolvimento, homologação e produção o mais similares possível Historicamente, houveram lacunas substanciais entre desenvolvimento (um desenvolvedor editando código num [deploy](./codebase) local do app) e produção (um deploy acessado pelos usuários finais). Essas lacunas se manifestam em três áreas: * **A lacuna do tempo:** Um desenvolvedor pode trabalhar em código que demora dias, semanas ou até meses para ir para produção. * **A lacuna de pessoal:** Desenvolvedores escrevem código, engenheiros de operação fazem o deploy dele. * **A lacuna de ferramentas:** Desenvolvedores podem estar usando um conjunto como Nginx, SQLite, e OS X, enquanto o app em produção usa Apache, MySQL, e Linux. **O App doze-fatores é projetado para [implantação contínua](http://avc.com/2011/02/continuous-deployment/) deixando a lacuna entre desenvolvimento e produção pequena.** Olhando às três lacunas descritas acima: * Diminua a lacuna de tempo: um desenvolvedor pode escrever código e ter o deploy feito em horas ou até mesmo minutos depois. * Diminua a lacuna de pessoal: desenvolvedores que escrevem código estão proximamente envolvidos em realizar o deploy e acompanhar seu comportamento em produção. * Diminua a lacuna de ferramentas: mantenha desenvolvimento e produção o mais similares possível. Resumindo o acima em uma tabela:
App tradicional App doze-fatores
Tempo entre deploys Semanas Horas
Autores de código vs deployers Pessoas diferentes Mesmas pessoas
Ambientes de desenvolvimento vs produção Divergente O mais similar possível
[Serviços de apoio](./backing-services), como o banco de dados do app, sistema de filas, ou cache, são uma área onde paridade entre desenvolvimento e produção é importante. Muitas linguagens oferecem diferentes bibliotecas que simplificam o acesso ao serviço de apoio, incluindo *adaptadores* para os diferentes tipos de serviços. Alguns exemplos na tabela abaixo.
Tipo Linguagem Biblioteca Adaptadores
Banco de dados Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Fila Python/Django Celery RabbitMQ, Beanstalkd, Redis
Cache Ruby/Rails ActiveSupport::Cache Memory, sistema de arquivos, Memcached
Desenvolvedores as vezes vem uma grande vantagem em usar um serviço de apoio leve em seus ambientes, enquanto um serviço de apoio mais sério e robusto seria usado em produção. Por exemplo, usando SQLite localmente e PostgreSQL em produção; ou memória de processo local para caching em desenvolvimento e Memcached em produção. **O desenvolvedor doze-fatores resiste a tentação de usar diferentes serviços de apoio entre desenvolvimento e produção**, mesmo quando adaptadores teoricamente abstraem as diferenças dos serviços de apoio. Diferenças entre serviços de apoio significam que pequenas incompatibilidades aparecerão, fazendo com que código que funcionava e passava em desenvolvimento ou homologação, falhe em produção. Tais tipos de erros criam fricção que desincentivam deploy contínuo. O custo dessa fricção e do subsequente decaimento de deploy contínuo é extremamente alto quando considerado que vai acumular no tempo de vida da aplicação. Serviços locais leves são menos tentadores que já foram um dia. Serviços de apoio modernos tais como Memcached, PostgreSQL, e RabbitMQ não são difíceis de instalar e rodam graças a sistemas modernos de empacotamento tais como [Homebrew](http://mxcl.github.com/homebrew/) e [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Alternativamente, ferramentas de provisionamento declarativo tais como [Chef](http://www.opscode.com/chef/) e [Puppet](http://docs.puppetlabs.com/) combinado com ambientes virtuais leves como [Vagrant](http://vagrantup.com/) permitem desenvolvedores rodar ambientes locais que são bem próximos dos ambientes de produção. O custo de instalar e usar esses sistemas é baixo comparado ao benefício de ter a paridade entre desenvolvimento, produção e deploy contínuo. Adaptadores para diferentes serviços de apoio ainda são úteis, pois eles fazem a portabilidade para novos serviços de apoio relativamente tranquilas. Mas todos os deploys do app (ambientes de desenvolvimento, homologação, produção) devem usar o mesmo tipo e versão de cada serviço de apoio. content/ru/port-binding.md0000644000175000056700000000666015226251677014346 0ustar0000000000000000## VII. Привязка портов (Port binding) ### Экспортируйте сервисы через привязку портов Иногда веб-приложения запускают внутри контейнера веб-сервера. Например, PHP-приложение может быть запущено как модуль внутри [Apache HTTPD](http://httpd.apache.org/), или Java-приложение может быть запущено внутри [Tomcat](http://tomcat.apache.org/). **Приложение двенадцати факторов является полностью самодостаточным** и не полагается на инъекцию веб-сервера во время выполнения для того, чтобы создать веб-сервис. Веб-приложение **экспортирует HTTP-сервис путём привязки к порту** и прослушивает запросы, поступающих на этот порт. Во время локальной разработки разработчик переходит по URL-адресу вида `http://localhost:5000/`, чтобы получить доступ к сервису, предоставляемым его приложением. При развёртывании слой маршрутизации обрабатывает запросы к общедоступному хосту и перенаправляет их к привязанному к порту веб приложению. Это обычно реализуется с помощью [объявления зависимости](./dependencies) для добавления библиотеки веб-сервера к приложению такой, как [Tornado](http://www.tornadoweb.org/) в Python, [Thin](http://code.macournoyer.com/thin/) в Ruby, и [Jetty](http://www.eclipse.org/jetty/) в Java и других языках на основе JVM. Это происходит полностью в *пространстве пользователя*, то есть в коде приложения. Контрактом со средой исполнения является привязка приложения к порту для обработки запросов. HTTP -- это не единственный сервис, который может быть экспортирован посредством привязки порта. Почти любой тип серверного ПО может быть запущен как процесс, привязанный к порту и ожидающий входящих запросов. Примеры этого включают [ejabberd](http://www.ejabberd.im/) (предоставляет [XMPP протокол](http://xmpp.org/)) и [Redis](http://redis.io/) (предоставляет [Redis протокол](http://redis.io/topics/protocol)). Также обратите внимание, что подход привязки к порту означает, что одно приложение может выступать [сторонней службой](./backing-services) для другого приложения путём предоставления URL-адреса стороннего приложения как идентификатор ресурса в конфигурации потребляющего приложения. content/th/toc.md0000644000175000056700000000415515226251677012521 0ustar0000000000000000The Twelve Factors ================== ## [I. Codebase](./codebase) ### มีเพียง codebase เดียวที่ติดตามด้วย version control, มีหลาย deploy ## [II. Dependencies](./dependencies) ### มีการประกาศและแยกการอ้างอิง (dependency) ทั้งหมดอย่างชัดเจน ## [III. Config](./config) ### จัดเก็บการตั้งค่า (config) ไว้ในสิ่งแวดล้อมของระบบ ## [IV. Backing services](./backing-services) ### จัดการกับบริการสนับสนุน (backing service) ให้เป็นทรัพยากรที่แนบมา ## [V. Build, release, run](./build-release-run) ### แยกขั้นตอนของการ build และ run อย่างเคร่งครัด ## [VI. Processes](./processes) ### รันแอพพลิเคชันเป็นหนึ่งหรือมากกว่าให้เป็น stateless processes ## [VII. Port binding](./port-binding) ### นำออกบริการด้วยการเชื่อมโยง port ## [VIII. Concurrency](./concurrency) ### ขยายออกของแอพพลิเคชันด้วยรูปแบบ process ## [IX. Disposability](./disposability) ### เพิ่มความแข็งแกร่งด้วยการเริ่มต้นระบบอย่างรวดเร็วและปิดระบบอย่างนุ่มนวล ## [X. Dev/prod parity](./dev-prod-parity) ### รักษา development, staging และ production ให้มีความใกล้เคียงกันที่สุด ## [XI. Logs](./logs) ### จัดการ logs ให้เป็นแบบ event stream ## [XII. Admin processes](./admin-processes) ### รันงานของผู้ดูแลระบบ/การจัดการให้เป็นกระบวนการแบบครั้งเดียว content/zh_cn/codebase.md0000644000175000056700000000354515226251677014171 0ustar0000000000000000## I. 基准代码 ### 一份基准代码（*Codebase*），多份部署（*deploy*） 12-Factor应用(译者注：应该是说一个使用本文概念来设计的应用，下同)通常会使用版本控制系统加以管理，如[Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [Subversion](http://subversion.apache.org/)。一份用来跟踪代码所有修订版本的数据库被称作 *代码库*（code repository, code repo, repo）。 在类似 SVN 这样的集中式版本控制系统中，*基准代码* 就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中，*基准代码* 则是指最上游的那份代码库。 ![一份代码库对应多份部署](/images/codebase-deploys.png) 基准代码和应用之间总是保持一一对应的关系： * 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor 进行开发。 * 多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库，然后使用 [依赖管理](./dependencies) 策略去加载它们。 尽管每个应用只对应一份基准代码，但可以同时存在多份部署。每份 *部署* 相当于运行了一个应用的实例。通常会有一个生产环境，一个或多个预发布环境。此外，每个开发人员都会在自己本地环境运行一个应用实例，这些都相当于一份部署。 所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。 locales/zh_cn.yml0000644000175000056700000000034415226251677012567 0ustar0000000000000000zh_cn: # Name of language listed in locales menu language: 简体中文 (zh_cn) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: （简体中文） content/pt_br/backing-services.md0000644000175000056700000000544315226251677015647 0ustar0000000000000000## IV. Serviços de Apoio ### Trate serviços de apoio como recursos anexados Um *serviço de apoio* é qualquer serviço que o app consuma via rede como parte de sua operação normal. Exemplos incluem armazenamentos de dados (como [MySQL](http://dev.mysql.com/) ou [CouchDB](http://couchdb.apache.org/)), sistemas de mensagens/filas (tais como [RabbitMQ](http://www.rabbitmq.com/) ou [Beanstalkd](https://beanstalkd.github.io)), serviços SMTP para emails externos (tais como [Postfix](http://www.postfix.org/)), e sistemas de cache (tais como [Memcached](http://memcached.org/)). Serviços de apoio como o banco de dados são tradicionalmente gerenciados pelos mesmos administradores de sistema do servidor de deploy de tempo de execução do app. Adicionalmente à esses serviços localmente gerenciados, o app pode ter serviços providos e gerenciados por terceiros. Exemplos incluem serviços SMTP (tais como [Postmark](http://postmarkapp.com/)), serviços de colheita de métricas (tais como [New Relic](http://newrelic.com/) ou [Loggly](http://www.loggly.com/)), serviços de ativos binários (tais como [Amazon S3](http://aws.amazon.com/s3/)), e até serviços de consumidores acessíveis via API (tais como [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), ou [Last.fm](http://www.last.fm/api)). **O código para um app doze-fatores não faz distinção entre serviços locais e de terceiros.** Para o app, ambos são recursos anexados, acessíveis via uma URL ou outro localizador/credenciais na [config](./config). Um [deploy](./codebase) do app doze-fatores deve ser capaz de trocar um banco de dados MySQL por um gerenciado por terceiros (tais como [Amazon RDS](http://aws.amazon.com/rds/)) sem realizar quaisquer mudanças no código do app. Da mesma forma, um servidor local SMTP poderia ser trocado por um serviço de terceiros (tais como Postmark) sem as mudanças em código. Em ambos os casos, apenas o identificador de recurso precisa mudar. Cada serviço de apoio distinto é um *recurso*. Por exemplo, um banco MySQL é um recurso; dois bancos MySQL (usados para sharding na camada da aplicação) qualificam como dois recursos distintos. O app doze-fatores trata tais bancos como *recursos anexados*, o que indica seu baixo acoplamento ao deploy que ele está anexado. Um deploy de produção anexado a quatro serviços de apoio. Recursos podem ser anexados e desanexados a deploys à vontade. Por exemplo, se o banco de dados do app não está funcionando corretamente devido a um problema de hardware, o administrador do app pode subir um novo servidor de banco de dados restaurado de um backup recente. O atual banco de produção pode ser desanexado, e o novo banco anexado -- tudo sem nenhuma mudança no código. content/uk/port-binding.md0000644000175000056700000000646615226251677014343 0ustar0000000000000000## VII. Прив'язка портів ### Експортуйте сервіси за допомогою прив'язки портів (port binding) Веб-застосунки іноді запускаються всередині контейнера веб-сервера. Наприклад, PHP-застосунок може бути запущений як модуль всередині [Apache HTTPD](http://httpd.apache.org/) або Java-застосунок може бути запущений всередині [Tomcat](http://tomcat.apache.org/). **Застосунок дванадцяти факторів є повністю автономним** і в процесі виконання, щоб створити веб-сервіс, доступний через web, не покладається на ін'єкцію веб-сервера в середовище виконання. Веб-застосунок **експортує HTTP-сервіс шляхом прив'язки до порту** і прослуховує запити, що надходять на цей порт. У локальному development середовищі розробник відвідує URL-адресу вигляду `http://localhost:5000/` для доступу до сервісу, що експортується застосунком. При розгортанні рівень маршрутизації обробляє запити до загальнодоступного хосту і перенаправляє їх до порту, до якого прив'язано веб-процес. Як правило, це реалізується за допомогою [оголошення залежностей] (./dependencies) шляхом додавання бібліотеки веб-сервера до застосунку, наприклад, [Tornado](http://www.tornadoweb.org/) для Python, [Thin](http://code.macournoyer.com/thin/) для Ruby або [Jetty](http://www.eclipse.org/jetty/) для Java та інших мов на основі JVM. Це відбувається повністю в *просторі користувача*, тобто в коді застосунку. Прив'язка до порту для обробки запитів є "угодою" із середовищем виконання. HTTP — не єдиний сервіс, який може бути експортований шляхом прив'язки до порту. Майже будь-який вид серверного програмного забезпечення може бути запущений, прив'язаний до порту і може очікувати вхідні запити. Прикладами є [ejabberd](http://www.ejabberd.im/) (використовує [XMPP](http://xmpp.org/)) і [Redis](http://redis.io/) (використовує [протокол Redis](http://redis.io/topics/protocol)). Також зверніть увагу, що підхід прив'язки до портів означає, що застосунок може виступати як [стороння служба](./backing-services) для іншого застосунку, надаючи свою URL-адресу як ресурс в [конфігурації](./config) застосунку-споживача.content/fr/config.md0000644000175000056700000001002415226251677013165 0ustar0000000000000000## III. Configuration ### Stockez la configuration dans l'environnement La *configuration* d'une application est tout ce qui est susceptible de varier entre des [déploiements](./codebase) (validation, production, environnement de développement, etc.). Cela inclut : * Les ressources gérées par la base de données, Memcached, ou tout autre [service de stockage](./backing-services) * Les identifiants pour des services externes, tel qu'Amazon S3 ou Twitter * Les valeurs spécifiques au déploiement, tel que son nom d'hôte canonique Les applications stockent parfois la configuration avec des constantes dans le code. C'est une violation des 12 facteurs, qui requiert une **stricte séparation de la configuration et du code**. La configuration peut varier substantiellement à travers les déploiements, alors que ce n'est pas le cas du code. Un bon moyen de tester si une application a correctement séparé son code, c'est de se demander si l'application pourrait être rendue open-source à tout instant, sans compromettre d'identifiants. Notez que cette définition de "configuration" n'inclut **pas** la configuration interne de l'application, tel que `config/routes.rb` avec Rails, ou comment [les modules du noyau sont connectés (en)](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) dans [Spring](http://spring.io/). Ce type de configuration ne varie pas à travers les déploiements, et est ainsi mieux réalisé dans le code. Une autre approche de la configuration, c'est d'utiliser des fichiers de configuration qui ne sont pas inclus dans le système de contrôle de version, par exemple `config/database.yml` de Rails. C'est une amélioration considérable par rapport à l'utilisation de constantes qui sont versionnées dans le dépôt de code, mais a toujours des faiblesses : il est facile d'ajouter par inadvertance un fichier de configuration dans le dépôt. Il y a une tendance à ce que les fichiers de configuration soient dispersés à différents endroits et dans différents formats, rendant ainsi difficile de voir et gérer la configuration à un unique endroit. De plus, ces formats ont tendance à être spécifiques à un langage ou un framework. **Les applications 12 facteurs stockent la configuration dans des *variables d'environnement*** (souvent raccourcies en *variables d'env*, ou *env*). Les variables d'environnement sont faciles à changer entre des déploiements sans changer le moindre code ; contrairement aux fichiers de configuration, il y a peu de chance pour qu'elles soient ajoutées au dépôt de code accidentellement ; et contrairement aux fichiers de configuration personnalisés, ou tout autre mécanisme de configuration comme les propriétés système Java, ce sont des standards agnostiques du langage ou du système d'exploitation. Un autre aspect de la gestion de configuration est le groupage. Parfois, les applications regroupent la configuration dans des groupes nommés (souvent appelés les "environnements"), nommés ainsi d'après des déploiements spécifiques, comme les environnements `development`, `test`, et `production` de Rails. Cette méthode ne permet pas de grossir proprement : lorsque l'on ajoute de nouveaux déploiement à l'application, de nouveaux noms d'environnement sont nécessaires, comme `validation` ou `qa`. Quand le projet grossit encore plus, les développeurs vont avoir tendance à ajouter leurs propres environnements particuliers, comme `joes-validation`, ce qui entraîne une explosion combinatoire de la configuration qui rend la gestion des déploiements de l'application très fragile. Dans une application 12 facteurs, les variables d'environnement permettent un contrôle granulaire, chacune complètement orthogonale aux autres variables d'environnement. Elles ne sont jamais groupées ensemble en "environnements", mais sont plutôt gérées indépendamment pour chaque déploiement. C'est un modèle qui permet de grossir verticalement en souplesse, lorsque l'application grossit naturellement en un plus grand nombre de déploiements au cours de sa vie. content/ko/background.md0000644000175000056700000000253715226251677014053 0ustar0000000000000000배경 ========== 이 문서에 기여한 사람들은 수백개 앱의 개발과 배포에 직접 참여했으며, [Heroku](http://www.heroku.com/) 플랫폼을 통해서 방대한 앱의 개발, 운영, 확장을 간접적으로 관찰했다. 이 문서는 실제로 쓰이는 다양한 SaaS 앱에 대한 경험과 관찰을 종합한 결과물이다. 특히 시간이 지나면서 앱이 유기적으로 성장하는 부분, 앱 코드베이스에서 작업하는 개발자들 간의 협업, [시간이 지나면서 망가지는 소프트웨어 유지비용을 줄이는 법](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/)에 집중하여 이상적인 앱 개발 방법을 찾고자 했다. 이 문서는 우리가 최신 애플리케이션 개발에서 만났던 몇가지 시스템적인 문제에 대한 인지도를 높이고, 이 문제들을 가지고 논의 하는데 필요한 공통의 어휘를 제공하며, 이 문제들에 대한 넓은 개념의 해결책과 용어를 제공하기 위해 작성 했다. 형식은 Martin Fowler의 책, *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)*과 *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*에서 영감을 받았다.content/ko/toc.md0000644000175000056700000000246115226251677012515 0ustar0000000000000000The Twelve Factors ================== ## [I. 코드베이스](./codebase) ### 버전 관리되는 하나의 코드베이스와 다양한 배포 ## [II. 종속성](./dependencies) ### 명시적으로 선언되고 분리된 종속성 ## [III. 설정](./config) ### 환경(environment)에 저장된 설정 ## [IV. 백엔드 서비스](./backing-services) ### 백엔드 서비스를 연결된 리소스로 취급 ## [V. 빌드, 릴리즈, 실행](./build-release-run) ### 철저하게 분리된 빌드와 실행 단계 ## [VI. 프로세스](./processes) ### 애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행 ## [VII. 포트 바인딩](./port-binding) ### 포트 바인딩을 사용해서 서비스를 공개함 ## [VIII. 동시성(Concurrency)](./concurrency) ### 프로세스 모델을 사용한 확장 ## [IX. 폐기 가능(Disposability)](./disposability) ### 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화 ## [X. 개발/프로덕션환경 일치](./dev-prod-parity) ### 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지 ## [XI. 로그](./logs) ### 로그를 이벤트 스트림으로 취급 ## [XII. Admin 프로세스](./admin-processes) ### admin/maintenance 작업을 일회성 프로세스로 실행 content/pt_br/build-release-run.md0000644000175000056700000000552715226251677015752 0ustar0000000000000000## V. Construa, lance, execute ### Separe estritamente os estágios de construção e execução Uma [base de código](./codebase) é transformada num deploy (de não-desenvolvimento) através de três estágios: * O *estágio de construção* é uma transformação que converte um repositório de código em um pacote executável conhecido como *construção*. Usando uma versão do código de um commit especificado pelo processo de desenvolvimento, o estágio de construção obtém e fornece [dependências](./dependencies) e compila binários e ativos. * O *estágio de lançamento* pega a construção produzida pelo estágio de construção e a combina com a atual [configuração](./config) do deploy. O *lançamento* resultante contém tanto a construção quanto a configuração e está pronta para execução imediata no ambiente de execução. * O *estágio de execução* roda o app no ambiente de execução, através do início de alguns dos [processos](./processes) do app com um determinado lançamento. ![Código vira uma construção, que é combinada com a configuração para se criar um lançamento.](/images/release.png) **O app doze-fatores usa separação estrita entre os estágios de construção, lançamento e execução.** Por exemplo, é impossível alterar código em tempo de execução, já que não há meios de se propagar tais mudanças de volta ao estágio de construção. Ferramentas para deploy tipicamente oferecem ferramentas de gestão de lançamento, mais notadamente a habilidade de se reverter à um lançamento prévio. Por exemplo, a ferramenta de deploy [Capistrano](https://github.com/capistrano/capistrano/wiki) armazena lançamentos em um subdiretório chamado `releases`, onde o lançamento atual é um link simbólico para o diretório de lançamento atual. Seu comando `rollback` torna fácil reverter para um lançamento prévio. Cada lançamento deve sempre ter um identificador de lançamento único, tal qual o timestamp do lançamento (como `2011-04-06-20:32:17`) ou um número incremental (como `v100`). Lançamentos são livro-razões onde apenas se acrescenta informações, ou seja, uma vez criado o lançamento não pode ser alterado. Qualquer mudança deve gerar um novo lançamento. Construções são iniciadas pelos desenvolvedores do app sempre que novos códigos entram no deploy. A execução de um executável, todavia, pode acontecer automaticamente em casos como o reinício do servidor, ou um processo travado sendo reiniciado pelo gerenciador de processos. Assim, no estágio de execução deve haver quanto menos partes móveis quanto possível, já que problemas que previnem um app de rodar pode causá-lo a travar no meio da noite quando não há desenvolvedores por perto. O estágio de construção pode ser mais complexo, já que os erros estão sempre à vista do desenvolvedor que está cuidando do deploy. content/pt_br/disposability.md0000644000175000056700000000575015226251677015310 0ustar0000000000000000## IX. Descartabilidade ### Maximize robustez com inicialização rápida e desligamento gracioso **Os [processos](./processos) de um app doze-fatores são *descartáveis*, significando que podem ser iniciados ou parados a qualquer momento.** Isso facilita o escalonamento elástico, rápido deploy de [código](./codebase) ou mudanças de [configuração](./config), e robustez de deploys de produção. Processos devem empenhar-se em **minimizar o tempo de inicialização**. Idealmente, um processo leva alguns segundos do tempo que o comando de inicialização é executado até o ponto que ele estará pronto para receber requisições ou tarefas. Períodos curtos de inicialização provém mais agilidade para o processo de [release](./build-release-run) e de escalonamento; e ele adiciona robustez, pois o gestor de processos pode mais facilmente mover processos para outras máquinas físicas quando necessário. Processos **desligam-se graciosamente quando recebem um sinal [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** do seu gestor de processos. Para um processo web, desligamento gracioso é alcançado quando cessa de escutar à porta de serviço (consequentemente recusando quaisquer requisições novas), permitindo qualquer requisição em andamento terminar, e então desligando. Implícito neste modelo é que as requisições HTTP são curtas (não mais que alguns poucos segundos), ou no caso de um longo _polling_, o cliente deve ser capaz de transparentemente tentar se reconectar quando a conexão for perdida. Para um processo de trabalho (worker), desligamento gracioso é alcançado retornando a tarefa atual para fila de trabalho. Por exemplo, no [RabbitMQ](http://www.rabbitmq.com/) o trabalhador pode enviar um [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); no [Beanstalkd](https://beanstalkd.github.io), a tarefa é retornada para a fila automaticamente sempre que um trabalhador se desconecta. Sistemas baseados em trava como o [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) precisam se certificar de soltar a trava no registro da tarefa. Implícito neste modelo é que todas as tarefas são [reentrantes](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), o que tipicamente é atingindo envolvendo os resultados numa transação, ou tornando a operação [idempotente](http://en.wikipedia.org/wiki/Idempotence). Processos também devem ser **robustos contra morte súbida**, no caso de uma falha de hardware. Ao passo que isso é muito menos comum que um desligamento via `SIGTERM`, isso ainda pode acontecer. Uma abordagem recomendada é usar um backend de filas robusto, como o Beanstalkd, que retorna tarefas à fila quando clientes desconectam ou esgotam o tempo de resposta. De qualquer forma, um app doze-fatores é arquitetado para lidar com terminações não esperadas e não graciosas. [Crash-only design](http://lwn.net/Articles/191059/) leva este conceito à sua [conclusão lógica](http://docs.couchdb.org/en/latest/intro/overview.html). content/pt_br/who.md0000644000175000056700000000033215226251677013215 0ustar0000000000000000Quem deve ler este documento? ============================= Qualquer desenvolvedor que esta construindo aplicações que rodam como serviço. Engenheiros de Operações que implantam ou administram tais aplicações. content/th/logs.md0000644000175000056700000001041315226251677012672 0ustar0000000000000000## XI. Logs ### จัดการ logs ให้เป็นแบบ event stream *Logs* จะทำให้เห็นได้ว่า app ทำงานอย่างไร ในสภาพแวดล้อม server-based โดยทั่วไปจะเขียนเป็นไฟล์บนดิสก์ (ใน "logfile") แต่นี่เป็นเพียง output format เท่านั้น Logs เป็น [stream](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) ของการรวบรวม, time-ordered events ที่รวมรวมจาก output stream ของ process ทั้งหมดที่ทำงานอยู่และ backing service, Log ในรูปแบบเดิมโดยปรกติเป็นรูปแบบข้อความด้วยหนึ่ง event ต่อบรรทัด (แม้กระทั้ง backtrace จาก exception ที่มีหลายบรรทัด) Log ไม่มีจุดเริ่มต้นหรือสิ้นสุดที่แน่นอน แต่มีการไหลอย่างต่อเนื่องตราบใดที่ app ทำงานอยู่ **Twelve-factor app ไม่เคยกังวลกับการกำหนดเส้นทางหรือการจัดเก็บสตรีมข้อมูลขาออก** ไม่ควรพยายามเขียนหรือจัดการ logfile แทนที่, แต่ล่ะ process ที่ทำงานจะเขียน event stream ไม่มีการบัฟเฟอร์ ด้วย `stdout` ในระหว่าง local development, developer จะดูสตรีมนี้ในเบื้องหลังของ terminal เพื่อสังเกตุพฤติกรรมของ app ใน staging หรือ production deploy แต่ละสตรีมของ process จะตรวจจับโดยสภาพแวดล้อมการดำเนินงาน รวบรวมเข้าด้วยกันกับสตรีมอื่นๆ จาก app และเชื่อมเส้นทางไปที่จุดหมายปลายทางสุดท้ายที่ใช้ดูและเก็บถาวรในระยะยาว จุดหมายที่เก็บถาวรเหล่านี้ไม่สามารถมองเห็นหรือกำหนดค่าโดย app และแทนจะได้รับการจัดการอย่างสมบูรณ์โดยสภาพแวดล้อมการดำเนินงาน, Open-source log routers (เช่น [Logplex](https://github.com/heroku/logplex) และ [Fluentd](https://github.com/fluent/fluentd)) มีไว้เพื่อการนี้ สตรีมเหตุการณ์สำหรับ app สามารถกำหนดเส้นทางไปที่ไฟล์ หรือดูได้ผ่านเรียลไทม์ใน terminal สตรีมสามารถส่งไป log indexing และระบบวิเคราะห์ เช่น [Splunk](http://www.splunk.com/) หรือ ระบบคลังข้อมูลทั่วไป เช่น [Hadoop/Hive](http://hive.apache.org/) ระบบเหล่านี้มีพลังมากและยืดหยุ่นในการตรวจสอบพฤติกรรมของ app ในช่วงเวลาหนึ่ง, รวมทั้ง: * ค้นหาเหตุการณ์เฉพาะที่ผ่านมา * กราฟขนาดใหญ่สำหรับแสดงแนวโน้ม (เช่น จำนวน request ต่อนาที) * การแจ้งเตือนแบบแอคทีฟตามการวิเคราะห์พฤติกรรมที่ผู้ใช้ระบุ (เช่น การแจ้งเตือนเมื่อจำนวน error ต่อนาทีเกินเกณฑ์ที่กำหนด) content/zh_cn/disposability.md0000644000175000056700000000470015226251677015275 0ustar0000000000000000## IX. 易处理 ### 快速启动和优雅终止可最大化健壮性 **12-Factor 应用的 [进程](./processes) 是 *易处理（disposable）*的，意思是说它们可以瞬间开启或停止。** 这有利于快速、弹性的伸缩应用，迅速部署变化的 [代码](./codebase) 或 [配置](./config) ，稳健的部署应用。 进程应当追求 **最小启动时间** 。 理想状态下，进程从敲下命令到真正启动并等待请求的时间应该只需很短的时间。更少的启动时间提供了更敏捷的 [发布](./build-release-run) 以及扩展过程，此外还增加了健壮性，因为进程管理器可以在授权情形下容易的将进程搬到新的物理机器上。 进程 **一旦接收 [终止信号（`SIGTERM`）](http://en.wikipedia.org/wiki/SIGTERM) 就会优雅的终止** 。就网络进程而言，优雅终止是指停止监听服务的端口，即拒绝所有新的请求，并继续执行当前已接收的请求，然后退出。此类型的进程所隐含的要求是HTTP请求大多都很短(不会超过几秒钟)，而在长时间轮询中，客户端在丢失连接后应该马上尝试重连。 对于 worker 进程来说，优雅终止是指将当前任务退回队列。例如，[RabbitMQ](http://www.rabbitmq.com/) 中，worker 可以发送一个[`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack)信号。 [Beanstalkd](https://beanstalkd.github.io) 中，任务终止并退回队列会在worker断开时自动触发。有锁机制的系统诸如 [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) 则需要确定释放了系统资源。此类型的进程所隐含的要求是，任务都应该 [可重复执行](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29) ， 这主要由将结果包装进事务或是使重复操作 [幂等](http://en.wikipedia.org/wiki/Idempotence) 来实现。 进程还应当**在面对突然死亡时保持健壮**，例如底层硬件故障。虽然这种情况比起优雅终止来说少之又少，但终究有可能发生。一种推荐的方式是使用一个健壮的后端队列，例如 [Beanstalkd](https://beanstalkd.github.io) ，它可以在客户端断开或超时后自动退回任务。无论如何，12-Factor 应用都应该可以设计能够应对意外的、不优雅的终结。[Crash-only design](http://lwn.net/Articles/191059/) 将这种概念转化为 [合乎逻辑的理论](http://couchdb.apache.org/docs/overview.html)。 content/it/who.md0000644000175000056700000000032715226251677012527 0ustar0000000000000000A chi è destinato questo documento? ============================== A ogni sviluppatore che costruisca applicazioni SaaS (Software As a Service), e a ogni ops che effettui il deploy e gestisca queste applicazioni. content/ko/config.md0000644000175000056700000000716315226251677013201 0ustar0000000000000000## III. 설정 ### 환경(environment)에 저장된 설정 애플리케이션의 *설정*은 [배포](./codebase) (스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다. * 데이터베이스, memcached 등 [백엔드 서비스](./backing-services)들의 리소스 핸들 * Amazon S3 이나 트위터 등의 외부 서비스 인증 정보 * 배포된 호스트의 정규화된 호스트 이름(canonical hostname)처럼 각 배포마다 달라지는 값 애플리케이션은 종종 설정을 상수로 코드에 저장합니다. 이것은 Twelve-Factor를 위반하며, Twelve-Factor는 **설정을 코드에서 엄격하게 분리하는 것**을 요구합니다. 설정은 배치마다 크게 다르지만, 코드는 그렇지 않습니다. 애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 테스트는 어떠한 인증정보도 유출시키지 않고 코드베이스가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다. 이 "설정"의 정의는 애플리케이션 내부 설정을 *포함하지 않는다는 점*에 유의해야 합니다. Rails의 `config/routes.rb`이나 [Spring](http://spring.io/)의 ["어떻게 코드 모듈이 연결되는 가](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html)과 같은 설정들은 배치 사이에서 변하지 않기 때문에 코드의 내부에 있는 것이 가장 좋습니다. 설정에 대한 또 다른 접근방식은 Rails의 `config/database.yaml`처럼 버전 관리 시스템에 등록되지 않은 설정 파일을 이용하는 것입니다. 이 방법은 코드 저장소에 등록된 상수를 사용하는 것에 비하면 매우 큰 발전이지만, 설정 파일이 여러 위치에 여러 포맷으로 흝어지고 모든 설정을 한 곳에서 확인하고 관리하기 어렵게 만드는 경향이 있습니다. 게다가, 이러한 형식들은 언어와 프레임워크을 따라가는 경향이 있습니다. **Twelve-Factor App은 설정을 *환경 변수*** (envvars나 env라고도 불림)에 저장합니다. 환경 변수는 코드 변경 없이 쉽게 배포 때마다 쉽게 변경할 수 있습니다. 설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다. 또한, 커스텀 설정 파일이나 Java System Property와 같은 다른 설정 매커니즘과 달리 언어나 OS에 의존하지 않는 표준입니다. 설정 관리의 다른 측면은 그룹핑입니다. 종종 애플리케이션은 설정을 명명된 그룹("environments"라고도 함)으로 구성하기도 합니다. 해당 그룹은 Rails의 'development', 'test', 'production' environments처럼, 배포의 이름을 따서 명명됩니다. 이 방법은 깔끔하게 확장하기 어렵습니다. 응용 프로그램의 배포가 증가함에 따라, 'staging'이라던가 'qa'같은 새로운 그룹의 이름이 필요하게 됩니다. 프로젝트가 성장함에 따라, 개발자은 자기 자신의 그룹를 추가하게 됩니다. 결과적으로 설정이 각 그룹의 조합으로 폭발하게 되고, 애플리케이션의 배포를 불안정하게 만듭니다. Twelve-Factor App에서 환경 변수는 매우 정교한 관리이며, 각각의 환경변수는 서로 직교합니다. 환경 변수는 "environments"로 절대 그룹으로 묶이지 않지만, 대신 각 배포마다 독립적으로 관리됩니다. 이 모델은 애플리케이션의 수명주기를 거치는 동안 더 많은 배포로 원활하게 확장해 나갈 수 있습니다. content/ja/background.md0000644000175000056700000000321615226251677014027 0ustar0000000000000000背景 ========== このドキュメントへの寄稿者は、何百ものアプリケーションの開発とデプロイに直接関わり、[Heroku](http://www.heroku.com/)プラットフォーム上での仕事を通して、何百何千ものアプリケーションの開発・運用・スケールに間接的に立ち会った。 このドキュメントは、多種多様なSaaSアプリケーション開発現場での私たちの経験と観察をすべてまとめたものである。これは、アプリケーション開発における理想的なプラクティスを見出すための三角測量である。特に、アプリケーションが時間と共に有機的に成長する力学、アプリケーションのコードベースに取り組む開発者間のコラボレーションの力学、そして[ソフトウェア腐敗によるコストの回避](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/)に注目している。 私たちの動機は、私たちがモダンなアプリケーション開発で見てきたある種のシステム的な問題への関心を高めること、この問題を議論するための共通の語彙を提供すること、そしてこの問題に対する広い概念的な解決策と専門用語を提供することである。フォーマットはMartin Fowlerの書籍、*[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* および *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)* に着想を得ている。 content/ru/who.md0000644000175000056700000000047615226251677012546 0ustar0000000000000000Кому следует читать этот документ? ============================== Разработчикам, которые создают SaaS-приложения. Ops инженерам, выполняющим развёртывание и управление такими приложениями. content/uk/processes.md0000644000175000056700000001071315226251677013743 0ustar0000000000000000## VI. Процеси ### Запускайте застосунок як один або декілька процесів без збереження внутрішньго стану (stateless) Застосунок запускається в середовищі виконання у вигляді одного або декількох *процесів*. У найпростішому випадку код є окремим скриптом, середовище виконання — ноутбук розробника зі встановленим середовищем виконання мови програмування, а процес запускається за допомогою командного рядка (наприклад, `python my_script.py`). В іншому випадку, це може бути production-розгортання складного застосунку, яке може використовувати багато [типів процесів, кожен з яких запущений у необхідній кількості екземплярів](./concurrency). **Процеси застосунку дванадцяти факторів не зберігають внутрішній стан (stateless) і [не розділяють ресурси](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Будь-які дані, що підлягають збереженню, мають зберігатися в [сторонній службі](./backing-services) зі збереженням внутрішнього стану (stateful) (як правило, в базі даних). Пам'ять та файлова система процесу можуть бути використані як короткостроковий кеш. Наприклад, завантаження, обробка і збереження великого файлу в базі даних. Застосунок дванадцяти факторів ніколи не припускає, що щось, закешоване в пам'яті або на диску, буде доступне при наступному запиті — за наявності багатьох запущених процесів різних типів є велика ймовірність, що наступний запит буде оброблений іншим процесом. Навіть при роботі тільки одного процесу перезапуск (викликаний розгортанням, змінами конфігурації або переміщенням процесу в інше фізичне місце розташування середовищем виконання), як правило, призведе до знищення всіх локальних (у пам'яті і файловій системі) станів. Пакувальники ресурсів (наприклад, [Jammit](http://documentcloud.github.com/jammit/) або [django-compressor](http://django-compressor.readthedocs.org/)) використовують файлову систему як кеш для скомпільованих ресурсів. Застосунок дванадцяти факторів надає перевагу здійсненню такої компіляції під час [етапу збірки](./build-release-run), наприклад, як в [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html), а не під час виконання. Деякі веб-системи покладаються на ["липкі сесії"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) — тобто кешують дані сесії користувача в пам'яті процесу застосунку і очікують, що наступні запити від того ж самого користувача будуть спрямовані до того ж самого процесу. Липкі сесії є порушенням дванадцяти факторів і їх ніколи не слід використовувати та покладатися на них. Дані сесії користувача є хорошим кандидатом для сховища даних, яке надає функцію обмеження терміну зберігання, наприклад, [Memcached](http://memcached.org/) або [Redis](http://redis.io/).locales/tr.yml0000644000175000056700000000033115226251677012107 0ustar0000000000000000tr: # Name of language listed in locales menu language: Turkish (tr) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "Türkçe çeviri" content/ja/admin-processes.md0000644000175000056700000000576115226251677015013 0ustar0000000000000000## XII. 管理プロセス ### 管理タスクを1回限りのプロセスとして実行する [プロセスフォーメーション](./concurrency)は、アプリケーションが実行されたときにアプリケーションの通常の役割（Webリクエストの処理など）に使われるプロセス群である。それとは別に、開発者はしばしばアプリケーションのために1回限りの管理・メンテナンス用のタスクを実行したくなる。例えば： * データベースのマイグレーションを実行する。（例：Djangoにおける `manage.py migrate` やRailsにおける `rake db:migrate`） * 任意のコードを実行したり、生のデータベースに対してアプリケーションのモデルを調査したりするために、コンソール（[REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)シェルとも言われる）を実行する。多くの言語ではインタプリタを引数なしで実行する（例：`python` や `perl`）ことでREPLを利用できるが、別のコマンドを用意している場合もある（例：Rubyでの `irb` や Railsでの `rails console`）。 * アプリケーションのリポジトリにコミットされた1回限りのスクリプトを実行する（例：`php scripts/fix_bad_records.php`）。 1回限りの管理プロセスは、アプリケーションの通常の[長時間実行されるプロセス](./processes)と全く同じ環境で実行されるべきである。これらのプロセスは、ある[リリース](./build-release-run)に対して実行され、そのリリースに対して実行されるすべてのプロセスと同じ[コードベース](./codebase)と[設定](./config)を使う。管理用のコードは、同期の問題を避けるためにアプリケーションコードと一緒にデプロイされるべきである。 同じ[依存関係分離](./dependencies)技術をすべてのプロセスタイプに利用するべきである。例えば、もしRubyのWebプロセスがコマンド `bundle exec thin start` を使うのであれば、データベースのマイグレーションには `bundle exec rake db:migrate` を使うべきである。同様に、Virtualenvを使っているPythonプログラムは、仮想環境内の `bin/python` をTornado Webサーバーとすべての `manage.py` 管理プロセスの両方で利用するべきである。 Twelve-Factorは細かい設定なしですぐに使えるREPLシェルを提供する言語を強く好む。1回限りのスクリプトを実行するのが簡単になるからである。ローカルデプロイでは、開発者は1回限りの管理プロセスを、アプリケーションをチェックアウトしたディレクトリの中でシェルコマンドで直接起動する。本番デプロイでは、開発者はSSHやデプロイの実行環境が提供する他のリモートコマンド実行方法を使ってそのようなプロセスを実行する。 content/ja/logs.md0000644000175000056700000000625215226251677012657 0ustar0000000000000000## XI. ログ ### ログをイベントストリームとして扱う *ログ* は実行中のアプリケーションの挙動を可視化する。サーバーベースの環境では、ログは一般的にディスク上のファイル（“ログファイル”）に書き込まれる。しかしこれは出力フォーマットの一つに過ぎない。 ログは、すべての実行中のプロセスとバックエンドサービスの出力ストリームから収集されたイベントが、集約されて時刻順に並べられた[ストリーム](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/)である。生の状態のログは、通常1行が1つのイベントを表すテキストフォーマットである（例外のバックトレースは複数行に渡る場合もあるが）。ログには固定の始まりと終わりはなく、アプリケーションが稼動している限り流れ続ける。 **Twelve-Factor Appはアプリケーションの出力ストリームの送り先やストレージについて一切関知しない。** アプリケーションはログファイルに書き込んだり管理しようとするべきではない。代わりに、それぞれの実行中のプロセスはイベントストリームを`stdout`（標準出力）にバッファリングせずに書きだす。ローカルでの開発中、開発者はこのストリームをターミナルのフォアグラウンドで見ることで、アプリケーションの挙動を観察する。 ステージングや本番のデプロイでは、それぞれのプロセスのストリームは実行環境に捕らえられ、アプリケーションからの他のすべてのストリームと一緒に並べられ、表示や長期アーカイブのために1つもしくは複数の最終目的地に送られる。これらの保存のための目的地は、アプリケーションからは見ることも設定することもできず、代わりに実行環境によって完全に管理される。[Logplex](https://github.com/heroku/logplex) や [Fluentd](https://github.com/fluent/fluentd) などのオープンソースのログルーターがこの目的に利用できる。 アプリケーションのイベントストリームは、ファイルに送られたり、ターミナルでtailを使ってリアルタイムに見られたりする。最も重要な用途として、ストリームは、[Splunk](http://www.splunk.com/)などのログインデックス・解析システムや、[Hadoop/Hive](http://hive.apache.org/)などの汎用データウェアハウスシステムに送られることもある。これらのシステムは、長期に渡ってアプリケーションの挙動を確認するための大きな力と柔軟性をもたらし、次のようなことができるようになる。 * 過去の特定のイベントを見つける。 * 大きなスケールの傾向をグラフ化する。（1分あたりのリクエスト数など） * ユーザー定義のヒューリスティクスに基づいて素早くアラートを出す。（1分あたりのエラー数がある閾値を超えた場合にアラートを出すなど） content/ko/who.md0000644000175000056700000000032315226251677012520 0ustar0000000000000000이 문서의 대상 ============================== 서비스로 동작하는 애플리케이션을 개발하는 모든 개발자. 그런 애플리케이션을 배포하고 관리하는 인프라 엔지니어. content/zh_cn/config.md0000644000175000056700000000541715226251677013671 0ustar0000000000000000## III. 配置 ### 在环境中存储配置 通常，应用的 *配置* 在不同 [部署](./codebase) (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括： * 数据库，Memcached，以及其他 [后端服务](./backing-services) 的配置 * 第三方服务的证书，如 Amazon S3、Twitter 等 * 每份部署特有的配置，如域名等 有些应用在代码中使用常量保存配置，这与 12-Factor 所要求的**代码和配置严格分离**显然大相径庭。配置文件在各部署间存在大幅差异，代码却完全一致。 判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。 需要指出的是，这里定义的"配置"并**不**包括应用的内部配置，比如 Rails 的 `config/routes.rb`，或是使用 [Spring](http://spring.io/) 时 [代码模块间的依赖注入关系](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) 。这类配置在不同部署间不存在差异，所以应该写入代码。 另外一个解决方法是使用配置文件，但不把它们纳入版本控制系统，就像 Rails 的 `config/database.yml` 。这相对于在代码中使用常量已经是长足进步，但仍然有缺点：总是会不小心将配置文件签入了代码库；配置文件的可能会分散在不同的目录，并有着不同的格式，这让找出一个地方来统一管理所有配置变的不太现实。更糟的是，这些格式通常是语言或框架特定的。 **12-Factor推荐将应用的配置存储于 *环境变量* 中**（ *env vars*, *env* ）。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。 配置管理的另一个方面是分组。有时应用会将配置按照特定部署进行分组（或叫做“环境”），例如Rails中的 `development`,`test`, 和 `production` 环境。这种方法无法轻易扩展：更多部署意味着更多新的环境，例如 `staging` 或 `qa` 。 随着项目的不断深入，开发人员可能还会添加他们自己的环境，比如 `joes-staging` ，这将导致各种配置组合的激增，从而给管理部署增加了很多不确定因素。 12-Factor 应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每个部署之中。当应用程序不断扩展，需要更多种类的部署时，这种配置管理方式能够做到平滑过渡。 locales/ko.yml0000644000175000056700000000032415226251677012075 0ustar0000000000000000ko: # Name of language listed in locales menu language: 한국어 (ko) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: (한국어) content/de/config.md0000644000175000056700000000662315226251677013160 0ustar0000000000000000## III. Konfiguration ### Die Konfiguration in Umgebungsvariablen ablegen Die *Konfiguration* einer App ist alles, was sich wahrscheinlich zwischen den [Deploys](./codebase) ändern wird (Staging, Produktion, Entwicklungsumgebungen, usw.). Dies umfasst: * Resource-Handles für Datenbanken, Memcached und andere [unterstützende Dienste](./backing-services) * Credentials für externe Dienste wie Amazon S3 oder Twitter * Direkt vom Deploy abhängige Werte wie der kanonische Hostname für den Deploy Manchmal speichern Apps die Konfiguration als Konstanten im Code. Dies ist eine Verletzung der zwölf Faktoren. Sie fordern **strikte Trennung der Konfiguration vom Code**. Die Konfiguration ändert sich deutlich von Deploy zu Deploy, ganz im Gegensatz zu Code. Ein Lackmustest, ob eine App die Konfiguration vollständig ausgelagert hat, ist, wenn die Codebase jederzeit als Open Source veröffentlicht werden könnte, ohne Credentials preiszugeben. Es sei darauf hingewiesen, dass diese Definition von "Konfiguration" die interne Anwendungskonfiguration **nicht einschließt**, wie `config/routes.rb` in Rails oder wie Code-Module [mit Spring verdrahtet sind](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html). Diese Art von Konfiguration ändert sich nicht von Deploy zu Deploy und gehört daher zum Code. Als Konfiguration könnte man auch Dateien verwenden, die nicht ins Versionsmanagement eingecheckt sind wie `config/database.yml` in Rails. Dies ist eine deutliche Verbesserung gegenüber der Verwendung von Konstanten, die ins Versionsmanagement eingecheckt sind, hat aber Schwächen. Es ist relativ einfach, versehentlich eine Konfigurationsdatei ins Repo einzuchecken. Zusätzlich gibt es Tendenzen, Konfigurationsdateien an verschiedenen Orten und in verschiedenen Formaten zu streuen. Das macht es schwer die Konfiguration von einem Punkt aus zu managen. Desweiteren sind diese Formate oft sprach- oder plattformspezifisch. **Die Zwölf-Faktor-App speichert die Konfiguration in *Umgebungsvariablen*** (kurz auch *env vars* oder *env*). Umgebungsvariablen von Deploy zu Deploy zu ändern ist einfach; im Gegensatz zu Konfigurationsdateien ist es unwahrscheinlich, dass sie versehentlich ins Code Repository eingecheckt werden und im Gegensatz zu speziellen Konfigurationsdateien oder anderen Konfigurationsmechanismen wie den Java Properties sind sie Sprach- und Betriebssystemunabhängig. Ein anderer Aspekt des Konfigurationsmanagements ist die Gruppierung. Manchmal sammeln Apps die Konfiguration in benamten Gruppen (oft "Umgebungen" genannt), benannt nach bestimmten Deploys wie zum Beispiel die Umgebungen `development`, `test` und `production` in Rails. Diese Methode skaliert nicht sauber: Je mehr Deploys einer App es gibt, desto mehr Umgebungsnamen werden benötigt, wie zum Beispiel `staging` oder `qa`. Wenn das Projekt noch weiter wächst, könnten Entwickler ihre eigenen speziellen Umgebungen wie `joes-staging` hinzufügen. Am Ende explodiert die Konfiguration kombinatorisch und die Verwaltung der Deploys wird fehleranfällig. In einer Zwölf-Faktor-App sind Umgebungsvariablen granulare Stellschrauben und vollständig orthogonal zueinander. Sie werden nie als "Umgebungen" zusammengefasst, sondern können für jeden Deploy unabhängig verwaltet werden. Dieses Modell skaliert reibungslos aufwärts, wenn die App sich natürlicherweise über ihre Lebenszeit hinweg auf mehr Deploys ausdehnt. content/es/codebase.md0000644000175000056700000000432715226251677013476 0ustar0000000000000000## I. Código base (Codebase) ### Un código base sobre el que hacer el control de versiones y multiples despliegues Una aplicación "twelve-factor" se gestiona siempre con un sistema de control de versiones, como [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), o [Subversion](http://subversion.apache.org/). A la copia de la base de datos de seguimiento de versiones se le conoce como un *repositorio de código*, a menudo abreviado como *repo de código* o simplemente *repo*. El *código base* es cualquier repositorio (en un sistema de control de versiones centralizado como Subversion), o cualquier conjunto de repositorios que comparten un commit raíz (en un sistema de control de versiones descentralizado como Git). ![El código base se usa en muchos despliegues](/images/codebase-deploys.png) Siempre hay una relación uno a uno entre el código base y la aplicación: * Si hay multiples códigos base, no es una aplicación -- es un sistema distribuido. Cada componente en un sistema distribuido es una aplicación, y cada uno, individualmente, puede cumplir los requisitos de una aplicación "twelve-factor". * Compartir código en varias aplicaciones se considera una violación de la metodología "twelve factor". La solución en este caso es separar el código compartido en librerías que pueden estar enlazadas mediante un [gestor de dependencias](./dependencies). El código base de la aplicación es único, sin embargo, puede haber tantos despliegues de la aplicación como sean necesarios. Un *despliegue* es una instancia de la aplicación que está en ejecución. Normalmente, se ejecuta en un entorno de producción, y uno o varios entornos de pruebas. Además, cada desarrollador tiene una instancia en su propio entorno de desarrollo, los cuales se consideran también como despliegues. El código base es el mismo en todos los despliegues, aunque pueden ser diferentes versiones en cada despliegue. Por ejemplo, un desarrollador tiene algunos commits sin desplegar en preproducción; preproducción tiene algunos commits que no están desplegados en producción. Pero todos ellos comparten el mismo código base, de este modo todos son identificables como diferentes despliegues de la misma aplicación. content/it/codebase.md0000644000175000056700000000371015226251677013476 0ustar0000000000000000## I. Codebase ### Una sola codebase sotto controllo di versione, tanti deploy Un'app conforme alla metodologia twelve-factor è sempre sotto un sistema di controllo di versione, sia essa [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), o [Subversion](http://subversion.apache.org/). Una copia della codebase è detta *code repository*, oppure più in breve *code repo* o *repo*. Una *codebase* è quindi un singolo repository (in un sistema centralizzato come Subversion), oppure un set di repo che condividono una root commit (in un sistema di controllo decentralizzato come Git). ![Una codebase, N deployment](/images/codebase-deploys.png) C'è sempre una relazione uno-ad-uno tra codebase e applicazione: * Se ci sono più codebase, non si parla più di applicazione ma di sistema distribuito. Ogni componente in un sistema distribuito è un'applicazione, e ognuna di queste applicazioni può individualmente aderire alla metodologia twelve-factor. * Se più applicazioni condividono lo stesso codice si ha una violazione del twelve-factor. La soluzione è, ovviamente, quella di sistemare il codice in modo adeguato, in modo tale da essere incluso eventualmente dove necessario tramite un [dependency manager](./dependencies). Quindi: una sola codebase per applicazione, ma ci saranno comunque tanti deployment della stessa app. Per *deploy* si intende un'istanza dell'applicazione. Può essere il software in produzione, oppure una delle varie istanze in staging. Ancora, un deploy può essere la copia posseduta dal singolo sviluppatore nel suo ambiente locale. La codebase rimane comunque sempre la stessa su tutti i deployment, anche se potrebbero essere attive diverse versioni nello stesso istante. Si pensi per esempio a uno sviluppatore che possiede dei commit in più che non ha ancora mandato in staging. Nonostante questo, comunque, rimane la condivisione della stessa codebase, nonostante la possibilità di avere più deploy della stessa app. content/it/port-binding.md0000644000175000056700000000416515226251677014332 0ustar0000000000000000## VII. Binding delle Porte ### Esporta i servizi tramite binding delle porte Normalmente, le applicazioni web sono qualcosa di eseguito all'interno di un server web, che fa da contenitore. Per esempio, le applicazioni PHP possono venire eseguite come modulo all'interno di [Apache HTTPD](http://httpd.apache.org/), così come un'applicazione Java viene eseguita in [Tomcat](http://tomcat.apache.org/). **L'applicazione twelve-factor** è completamente self-contained (contenuta in se stessa) e non si affida a un altro servizio (come appunto un webserver) nell'ambiente di esecuzione. La web app **esporta HTTP come un servizio effettuando un binding specifico a una porta**, rimanendo in ascolto su tale porta per le richieste in entrata. In un ambiente di sviluppo locale, lo sviluppatore accede al servizio tramite un URL come `http://localhost:5000/`. In fase di deployment, invece, un layer di routing gestisce le richieste da un hostname pubblico alla specifica porta desiderata. Tale funzionalità viene, frequentemente, implementata tramite [dichiarazione delle opportune dipendenze](./dependencies), aggiungendo una libreria webserver all'applicazionecome [Tornado](http://www.tornadoweb.org/) per Python, [Thin](http://code.macournoyer.com/thin/) per Ruby, o [Jetty](http://www.eclipse.org/jetty/) per Java e altri linguaggi basati su JVM. L'evento, nella sua interezza, "ha luogo" nello spazio dell'utente, nel codice dell'applicazione. HTTP non è l'unico servizio che può essere esportato tramite port binding. In realtà quasi ogni tipo di software può essere eseguito tramite uno specifico binding tra processo e porta dedicata. Alcuni esempi includono [ejabberd](http://www.ejabberd.im/) (a tal proposito, leggere su [XMPP](http://xmpp.org/)), e [Redis](http://redis.io/) (a proposito del [protoccolo Redis](http://redis.io/topics/protocol)). Nota inoltre che usare il binding delle porte permette a un'applicazione di diventare il backing service di un'altra applicazione, tramite un URL dedicato o comunque come una risorsa la cui configurazione si può gestire tramite appositi file di [config](./config) dell'app consumer del servizio. content/th/processes.md0000644000175000056700000001053615226251677013742 0ustar0000000000000000## VI. Processes ### รันแอพพลิเคชันเป็นหนึ่งหรือมากกว่าให้เป็น stateless processes App ทำงานในสภาพแวดล้อมการดำเนินงานด้วยหนึ่งหรือมากกว่า *processes* ในกรณีที่ง่ายที่สุดคือ code คือ stand-alone script, สภาพแวดล้อมการดำเนินงานคือเครื่องคอมพิวเตอร์อง developer ที่ติดตั้ง language runtime และวิธีการคือเปิด app ด้วยคำสั่ง (ตัวอย่างเช่น `python my_script.py`) ในอีกด้านหนึ่ง app ที่ซับซ้อนที่ deploy บน production ใช้หลาย [process types, instantiated into zero or more running processes](./concurrency) **Twelve-factor processes เป็น stateless และ [share-nothing](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** ข้อมูลใดๆที่จำเป็นต้องเก็บแบบถาวรจำเป็นต้องเก็บไว้ใน stateful [backing service](./backing-services) โดยปรกติจะเป็นฐานข้อมูล พื้นที่หน่วยความจำหรือระบบไฟล์ของ process สามารถใช้เป็นช่วงสั้นๆ ได้, single-transaction cache. ตัวอย่างเช่น, การดาวน์โหลดไฟล์ขนาดใหญ่, ดำเนินงานกับไฟล์นั้น และเก็บผลลัพธ์ของการดำเนินงานไว้ในฐานข้อมูล twelve-factor app ไม่เคยสมมติว่ามีอะไรแคชในหน่วยความจำหรือบน disk จะพร้อมใช้งานใน request หรือ job ในอนาคต -- มีหลาย process ทำงานมีโอกาสสูงมากที่ในอนาคต request จะทำงานบน process ที่แตกต่างกัน แม้ว่าทำงาน process เดียว เมื่อมีการ restart (trigger โดย code deploy, config change หรือเปลี่ยนสภาพแวดล้อมการทำงาน) จะลบสภานะของ app ทั้งหมดอย่างสมบูรณ์ (เช่น หน่วยความจำ และระบบไฟล์) Asset packagers อย่างเช่น [django-assetpackager](http://code.google.com/p/django-assetpackager/) ใช้ระบบไฟล์เป็นแคชของการ compiled asset. Twelve-factor app ชอบที่จะทำ compiling เช่นนี้ในระหว่าง [ขั้นตอนการ build](/build-release-run) Asset packagers อย่างเช่น [Jammit](http://documentcloud.github.com/jammit/) และ [Rails asset pipeline](http://ryanbigg.com/guides/asset_pipeline.html) สามารถตั้งค่าให้ pacakge asset ระหว่างขั้นตอนการ build ได้ บางระบบเว็บขึ้นอยู่กับ ["sticky sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- นั้นคือ, ทำการแคชขอมูล user session ในหน่วยความจำของ app สำหรับดำเนินการในอนาคตจากผู้เยี่ยมชมเดียวกันที่เชื่อมโยงกับ process เดียวกัน, Sticky session เป็นการละเมิด twelve-factor และไม่ควรใช้หรือพึ่งพา, ข้อมูลสถานะ Session เป็นสิ่งที่เหมาะสมอย่างมากสำหรับที่เก็บข้อมูลที่มีการหมดเวลา (time-expireation) อย่างเช่น [Memcached](http://memcached.org/) หรือ [Redis](http://redis.io/) content/zh_cn/admin-processes.md0000644000175000056700000000352415226251677015515 0ustar0000000000000000## XII. 管理进程 ### 后台管理任务当作一次性进程运行 [进程构成](./concurrency)（process formation）是指用来处理应用的常规业务（比如处理 web 请求）的一组进程。与此不同，开发人员经常希望执行一些管理或维护应用的一次性任务，例如： * 运行数据移植（Django 中的 `manage.py migrate`, Rails 中的 `rake db:migrate`）。 * 运行一个控制台（也被称为 [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) shell），来执行一些代码或是针对线上数据库做一些检查。大多数语言都通过解释器提供了一个 REPL 工具（`python` 或 `perl`） ，或是其他命令（Ruby 使用 `irb`, Rails 使用 `rails console`）。 * 运行一些提交到代码仓库的一次性脚本。 一次性管理进程应该和正常的 [常驻进程](./processes) 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的 [代码](./codebase) 和 [配置](./config) ，基于某个 [发布版本](./build-release-run) 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。 所有进程类型应该使用同样的 [依赖隔离](./dependencies) 技术。例如，如果Ruby的web进程使用了命令 `bundle exec thin start` ，那么数据库移植应使用 `bundle exec rake db:migrate` 。同样的，如果一个 Python 程序使用了 Virtualenv，则需要在运行 Tornado Web 服务器和任何 `manage.py` 管理进程时引入 `bin/python` 。 12-factor 尤其青睐那些提供了 REPL shell 的语言，因为那会让运行一次性脚本变得简单。在本地部署中，开发人员直接在命令行使用 shell 命令调用一次性管理进程。在线上部署中，开发人员依旧可以使用ssh或是运行环境提供的其他机制来运行这样的进程。 locales/pl.yml0000644000175000056700000000033115226251677012075 0ustar0000000000000000pl: # Name of language listed in locales menu language: "Polski (pl)" # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "- edycja polska" content/de/disposability.md0000644000175000056700000000553215226251677014570 0ustar0000000000000000## IX. Einweggebrauch ### Robuster mit schnellem Start und problemlosen Stopp **Die Prozesse einer Zwölf-Faktor-App können *weggeworfen* werden, sie können also schnell gestartet und gestoppt werden.** Dies erleichtert schnelles elastisches Skalieren, schnelles Deployment von [Code](./codebase) oder [Konfigurationsänderungen](./config) und macht Produktionsdeployments robuster. Prozesse sollten **möglichst geringe Startup-Zeiten** haben. Idealerweise braucht ein Prozess wenige Sekunden vom Startkommando bis der Prozess läuft und Requests oder Jobs entgegennehmen kann. Eine kurze Startup-Zeit gibt dem [Release-Prozess](./build-release-run) und der Skalierung mehr Agilität; sie hilft der Robustheit, weil ein Prozessmanager bei Bedarf einfacher Prozesse auf neue physikalische Maschinen verschieben kann. Prozesse **fahren ohne Schwierigkeiten herunter, wenn sie ein [SIGTERM-Signal](http://en.wikipedia.org/wiki/SIGTERM)** vom Prozessmanager bekommen. Für einen Web-Prozess kann ein problemloses Herunterfahren erreicht werden, indem er aufhört an seinem Service-Port zu lauschen (und damit alle neuen Requests ablehnt), die laufenden Requests zuende bearbeitet und sich dann beendet. Diesem Modell eigen ist, dass HTTP-Requests kurz sind (höchstens ein paar Sekunden) oder im Falle von Long-Polling, der Client sich nahtlos neu verbindet, wenn die Verbindung verloren geht. Für einen Worker-Prozess wird ein problemloser Stopp erreicht, indem er seinen laufenden Job an die Workqueue zurück gibt. Zum Beispiel kann bei [RabbitMQ](http://www.rabbitmq.com/) ein Worker einen [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); bei [Beanstalkd](https://beanstalkd.github.io) wird der Job automatisch an die Queue zurückgegeben, wenn ein Worker die Verbindung beendet. Lock-basierte Systeme wie [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) sollten sicherstellen, dass ihr Lock im Job-Record freigegeben wird. Diesem Modell eigen ist, dass alle Jobs [reentrant](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29) sind, was üblicherweise erreicht wird indem man die Ergebnisse in eine Transaktion einpackt oder den Vorgang [idempotent](https://de.wikipedia.org/wiki/Idempotenz) gestaltet. Prozesse sollte auch **robust gegen plötzlichen Tod** sein - falls die zugrundeliegende Hardware versagt. Auch wenn dies viel seltener ist als ein reguläres Herunterfahren mit `SIGTERM`, so kommt es dennoch vor. Wir empfehlen ein robustes Queue-Backend wie Beanstalkd, das Jobs an die Queue zurückgibt falls Clients die Verbindung beenden oder nicht mehr antworten. Wie auch immer ist eine Zwölf-Faktor-App darauf ausgelegt mit unerwarteten, irregulären Stopps umgehen zu können. [Crash-only design](http://lwn.net/Articles/191059/) führt dieses Konzept zu seinem [logischen Schluss](http://docs.couchdb.org/en/latest/intro/overview.html). content/fr/toc.md0000644000175000056700000000247115226251677012514 0ustar0000000000000000Les 12 facteurs ================== ## [I. Base de code](./codebase) ### Une base de code suivie avec un système de contrôle de version, plusieurs déploiements ## [II. Dépendances](./dependencies) ### Déclarez explicitement et isolez les dépendances ## [III. Configuration](./config) ### Stockez la configuration dans l'environnement ## [IV. Services externes](./backing-services) ### Traitez les services externes comme des ressources attachées ## [V. Build, release, run](./build-release-run) ### Séparez strictement les étapes d'assemblage et d'exécution ## [VI. Processus](./processes) ### Exécutez l'application comme un ou plusieurs processus sans état ## [VII. Associations de ports](./port-binding) ### Exportez les services via des associations de ports ## [VIII. Concurrence](./concurrency) ### Grossissez à l'aide du modèle de processus ## [IX. Jetable](./disposability) ### Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux ## [X. Parité dev/prod](./dev-prod-parity) ### Gardez le développement, la validation et la production aussi proches que possible ## [XI. Logs](./logs) ### Traitez les logs comme des flux d'évènements ## [XII. Processus d'administration](./admin-processes) ### Lancez les processus d'administration et de maintenance comme des one-off-processes content/ko/build-release-run.md0000644000175000056700000000560515226251677015252 0ustar0000000000000000## V. 빌드, 릴리즈, 실행 ### 철저하게 분리된 빌드와 실행 단계 [코드베이스](./codebase)는 3 단계를 거쳐 (개발용이 아닌) 배포로 변환됩니다. * *빌드 단계*는 코드 저장소를 *빌드*라는 실행 가능한 번들로 변환시키는 단계입니다. 빌드 단계에서는 커밋된 코드 중 배포 프로세스에서 지정된 버전을 사용하며, [종속성](./dependencies)을 가져와 바이너리와 에셋들을 컴파일합니다. * *릴리즈 단계*에서는 빌드 단계에서 만들어진 빌드와 배포의 현재 [설정](./config)을 결합 합니다. 완성된 *릴리즈*는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있도록 준비됩니다. * *실행 단계*(런타임이라고도 하는)에서는 선택된 릴리즈에 대한 애플리케이션 [프로세스](./processes)의 집합을 시작하여, 애플리케이션을 실행 환경에서 돌아가도록 합니다. ![코드 베이스는 빌드가 되고, 빌드는 설정과 조합되어 릴리즈가 됩니다.](/images/release.png) **Twelve-Factor App은 빌드, 릴리즈, 실행 단계를 엄격하게 서로 분리합니다.** 예를 들어, 실행 단계에서 코드를 변경할 수는 없습니다. 변경을 실행 단계보다 앞에 있는 빌드 단계로 전달할 수 있는 방법이 없기 때문입니다. 배포 도구는 일반적으로 릴리즈 관리 도구를 제공합니다. 특히 주목할만한 점은 이전 릴리즈로 되돌릴 수 있는 롤백 기능입니다. 예를 들어, [Capistrano](https://github.com/capistrano/capistrano/wiki)는 배포 툴은 릴리즈를 `releases`라는 하위 디렉토리에 저장시키고, 현재 릴리즈는 현재 릴리즈 디렉토리로 심볼릭 링크로 연결합니다. 이 툴의 `rollback` 명령어는 이전 버전으로 쉽고 빠르게 이전 릴리즈로 롤백할 수 있도록 해줍니다. 모든 릴리즈는 항상 유니크한 릴리즈 아이디를 지녀야 합니다. 예를 들어, 릴리즈의 타임 스템프(예: 2011-04-06-20:32:17)나 증가하는 번호(예: v100, v101)가 있습니다. 릴리즈는 추가만 될 수 있으며, 한번 만들어진 릴리즈는 변경될 수 없습니다. 모든 변경은 새로운 릴리즈를 만들어야 합니다. 빌드는 새로운 코드가 배포 될 때마다 개발자에 의해 시작됩니다. 반면, 실행 단계는 서버가 재부팅되거나 충돌이 발생한 프로세스가 프로세스 매니저에 의해 재시작 되었을 때 자동으로 실행될 수 있습니다. 따라서 대응할 수 있는 개발자가 없는 한밤중에 문제가 발생하는 것을 방지하기 위해, 실행 단계는 최대한 변화가 적어야합니다. 빌드 단계는 좀 더 복잡해져도 괜찮습니다. 항상 배포를 진행하고 있는 개발자의 눈 앞에서 에러가 발생하기 때문입니다. locales/es.yml0000644000175000056700000000037015226251677012074 0ustar0000000000000000es: # Name of language listed in locales menu language: Español (es) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: (Traducción de la versión original en Inglés) public/images/process-types.png0000644000175000056700000005117415226251677015401 0ustar0000000000000000PNG  IHDR pHYs   IDATx Ź Q!.x 67 D+1%ƐT (/(KA4$EDA6Aۧk3s3o=7UUu-oݻDM`E@D@Ddt5BD@D@I@IAW^5BD@D#[!oX$f3!?,PKD@D bi0 !C r" " %@ iP-S&@ F'8#i;" "$A0R{G5WD@D@ ҐBNQ"A׋Mxp T" " E$+:L+> .'" "$hP|ˉDD 6 |NtnHE@D@ O N): PxAD@D X$} ҭ1e:N" " 9A#LdʠtA^%@ TAׅWebiL."  P ̲50zPN4)"  !W (*"  P uZ"ի2x." "%6H`tŧW YE@DH* [J{UP&|2)]D@D * QWeiL." y$P)WW e)ãD@D >* p+0 4u]TE@D@* a_Q#]VHM CЏtA6'VݻwoNR*"" "wp{\ L7i0@NERUB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D odRB@)z:VD@D o[I*H"&P^CфS! qwk`ݻwwA*1R 3!B_@NȐ5`4BPKJ~tp2!2F@U[ɭJh E]H>bXT?NA@cʚ8E70ҥo>~hϟo-[ 嘾e0Aq@=Q_EBnOcx8Zɫl /KsG~ŋQF׻5D+]"%MEI_uוq`l<2Fih|q7‰+(A|Ԁl!_0'?IEL`"Pl2H&r%4iƜtI6*vi֬*( EI_uׅ!A:z-\~TӚ_@1 ) ؔCbnbB-I2H%9,jď R\=$ TâF@ oc(I2H%9,jď R\=$ TâF@ oc(I2H%9,jď R\=$ TâF@Db AA쀬P{Ⱦ\ tP njz]z -$2U|`\CyW@{HB5XnĚ)Sg}k|e(v]ȯ Q*m.~ ҉@\ܹdӫW//W7vȩ6 |)jP~EA1cٱcYtiҤY`gO3kӧ9S<=nRnݺ-Z$%]wu6FJ̙Ym3 T1}ܹQFv}uWXʖ@ KƦ7 qjAt<}Or"Gyi۶Yb6mپ}S/'Np}?7;v:wũSicԼf֬Y^x>(Ν{fРAfʕ:͏ Do@+#D W:u2͛77>ҥwlϟ1K/5*E]~ :3h<۷1bg}̸q̶mۼ#G-ND ԃ(z'ap>G46C΀ة9>p5DLjHys( v :WI'֝uY?@o6>k\"t:ngDcD7ӧ@j i\ K߆-N\A &A`Sl!өҗsW@#ze9WTD@Dr DrDXn§BӸDŮ Drc'fC^Acq D@D@*@TwH7k:cd7B@5XE@D De2:.D@D D2e|`JGAj~j0Mq ${>[a|$_e_!G剀B`˖-LQ\L *ϫvD'MA VZ%*YH_Y"PPQ$ =}(9~rl2zMU%޳^ H ֍U9lKT_|B@/ˉ@Ήy5@[sq׿u0_,1T\"AŗQH_H+ސf!hnۂ$y[oUF)Hɏsvnx` E Jl?iDV7~Žq <蠃=QMXyGĩ x֜} :["3Hp;%%Ĺ/o  |nռ:S%QF>Ƒd/Uη$= ]-'ɔ.&ѕi%[{rd_HGs/'5SnFx&1"!ABOG@ܺ :η؝d]"EWo~=*i?ȇkFMF<-&%DI 75]w<>2+(5ʧwӷS  BVE#`Ű,H֐p5qz d54#![!;~ʮBaZCQ$" !_>@cDgbP剀T2 8:O?7@p,(fǥl)tqʼn+(" "P"1HXzLBéۘ8(}9䡆(ꡆ(nHO ;$64ג<AC@6| &C 06oj "M ϱM 0m*TD@DIoj# _D@D#Asћt@LD2e|'ct|Sн]<剀T2 PgU}Er]Rcy︨lkZΝ;ڵkxlgaK/@@*KaԆJ2F۷7Æ 3UUUFIxiʔ)fĉf>Kp%9( Lٱ2pz /Vek%AH(9878ҥy)"c/۴1]v?~i֬iDdDbpA|e6 b]?ľ|u Ose˖;454;0_԰?UE"1H ttǚn/rӤ Fc5 8VZQ(> ~Wy2EzHJrtInTZ;; ##C ߂EUZQ&կ_pN.:(CPDE ; ct<|Ёﵛ;l"DH+R;=}X;FK *vlExn7ISPD@D De'2p}(YD@DBDbn ^!! ABB@/ˉĀ@T5xhapE"'" "s!9^+!K!}]" " M cs"r3&nBohxu\$ !ȓ "'" "Q>ۡXG*P]ۜUDQ$6iIZD@DDe'a$Hc^~HM v©;" "ip@{9tt ҋ@)ڵzEy뮻 }כ͛.(Qep)o>_H{ ag 䫃NIA¸tҋ@ѯkW_+|B ߌ ̆HŇ+w,қVB~ad5l,< yˉ1cmx㍄N(wa֐  ݟ 'CZ@4TA1*?p@ӽ{w~=T_<>h86uT/aӣG|tvN>dӫW//;x,e/?yd/{t7oziXwavܙȟ|M /ӥ:0K/5>K/ypIN*@Ǿi(ko*И4l >|*nBPdpa !/CuJj:uH.]xJ̟?[bu4[n5t]tM:3f<۷1bg}̸q f#GX$>`;3DRԃ!)z_`X BCr;ېh_d;"p a 栎n_0}g)R/^l.rI:] GJ RZwʥA1ҹ꟦R) . HGd[˴v% pekU@g#]!'" q!ՔFE(r" " 1' P+$L@!נ.>''" "s9O4tM = @&T>wHnk!߄4!ε!|JP`6?@v> |y 9;r" " G u!ͷPr.gY %7wv%+RaHxgDwd2|n7qByDNJ`ƍEO@d_':g)K[u?}y"Ph;m[l1pR 1H|׏_ylLu3^ONḀ̊)G tlw~uu &wܪ@\Q@oݥ0" ~?d> p0f ! !_B>́\D -ո\fW>93WT"# ݆}4 SC9H2U8>`A=1|9' l2swQBCӚ7puN\A@F3 a=ȗ\ }"[ΉX Pߚ:I8ƻ).~p׻jAtmr X D]2k/ {u´7*6)P80%q<mr[7d$kMUxǎq^dT] 7 ߭R2HB yW_8wΕ\ =p&dt!8u8L%Y)%r,4oƎr p4|6?D9E2NK[tn&D y3߮٧–|1" *y-QsW(W:dȓ xk!S`B@ 9pa}cȒu">-8R%q34)d\IrHoW7 eRbٝ&)u*!]J4etyf֗H\LUB &+pA  ]^zԧdGޕ8"'"PfLIy1k- ~." " %D  d${0]BP! IDAT[P{jˠ4@F6|> )dn}cr" " "P'aIn'_TdC`@j`_ ǽn Ld3 Aj'Sv02|G."ηm͙|Xu +'" " YHyB#d/#[F2(wHن| BTE@D@ʗ@J\ti>_'i_qzg:|C C ` _ND@D 3H]^0|]_t |[NAt}! V" " H/L濾RXǻ qv$dw]4:ǐ3 s!}!%`NӋ@t|4+7 ~0^01hyTA8LIw#'߂U|&3J~(m _ѭ .c}#U}O÷gCU~Y/9>ew9e2dA>#r[A@E3X>'䃹HfG~xZ! ;l&<ú>~F^@R;r;HUQ.:0$w,_r 0{b7`L;d ꄬo@C|7XWd f?YyD眆܌*X홷ɺle?4 Y?-4j/Ok\oTyL4Q\ n ]9E8 C 3r?UqYTFx!)%92Տto^n}57=z0& Q~6olΝkyc' 2¿ #3k,oFr|o 1'+urt. /܂U}rMt堿"/ހ|c2&*d❍usPf/ (tɌ=ڴico$Ô<0^{fŊw%Ae837E]d fׯŋQFMD5Hn.(O׉dd|Q=?rt4uv)I] F4v?~iԨQUnٲ?4Wv:_ ֍x!1.gI74<x&J%$F,qA,jH$TTiYЏ.5V q:>F$sSD@D De^QAP2H|?!W beHǗ;n-Aw0/^lוl|%RUD@D@D@Nt@ D2ei|';C@D@*@l8 AM<" "PtTc@E(RE*NtZ"Eel[oe^oʜtIކnV##^ S@J.kE3Hԛ.kz_Wy_|aJ>ƩP=HOh)}R zD3v_~ehJcԊd O5} ԁݻ{|p hmذ0͛_oziN>dsw;whO?mN;4s%$ʭQb}s̆/{k.s]wy|{9idžk/bN'OOi2(J' LJ@$ xy7sL zyKg9s$8%C ڞիqg;ＤJXNaδO>SNL2nݺ-Z$鯻:s{؄c<[FU~De1k-۶m=6m4}v3x`_ČX´kqO?ݻ95k%Ϡ5n5ҭ6kٲl֭v۵kv^{~{"~ӫY|y"-옥*q}/Q$})η*Oǰ4h`.ӰaCo 6iӦ^W^yn믿!>9G׬YݪyWt{qZun2e- p~WͯҨQ7؏=ڛfec<qbE淨8}p Iǎ Թsg/Nv|Mo /tG3{lOu '$:\+ȑ# "*مKPf֬Y^xs5 2\{Ǽa-;2P8zf= _ لc:ud7oMu5{L1b_qƙm۶A :5J?製`:s7|XO6oa?^zٺua$E]`(;3o߾,]qt \0B W/Qwʫ].x~ DE8bd`uY§{gݜC!W)1U|5V'?=>1X*(D5eE_U@ A*QD@D N"YC4\L}J%J=/Hk wԡ:DD@DB DrzuPPԕ@TzuP]GNlj@ Av";" "+ ^n!'"P2H|7?!|uPOHS>vW8u1n J9܌޾+LO>IV1P\ Sv=_lS٤RŐAȅ'3+Oc#E!g-nQ؆ RV2˖-f]xqj;ZT"p-[*x')I,@1 eI&7nV]] )4rK0exeʎs<~zswۨ4x7SOS*Db8 VtN?5Zp ˕W^m.G~FN7ɓo~t% *ȇS:_R1Ym?aG]qm܎{M6nKxƍ[xsn7X 0,֕s7 2ڷooo:(S~}7)>ȼKb &t@ddncԸ]ny aYVuN;tXeG6>C[ K )v85^ֵ@{jHe,#j%3Z(1"$|j!{C8 s<["K֡qACE.FG0 9 $e R$rmB9;:ݕSG$ɔ]&TT #ۨD@D 8MV2b_4roպd@$ gw^29HjȂ~,er&R`ۑ2G͐W" " B CS[MTȘ" "P" $5JD@D"CB/O;*zU@I $g==}ĝ@Ti(y vgB4D՞DN )i~ϻ֥FdER"" " B@w$29[Ύ,_z-o/TrUl/ W Ŀ֢gCٗ{(YG^~R8] qZ,6U\@i˖sH\yG⿇ssi[j6{OѦ鯐@dpLseYXhސߣ Rʥ'ś g0Y;ƀwDo@2.W+HZs8hO`++~ d-M01tTA ! fY_(l$eW@iNN._iԹ>p⍠fｋ|MuA4up n5rq1U$޽{>}֭[-[[֭[ڵk͒%K̔)Sr}Y0<_ʝnBذNG &[qao}[M6߉>0?=pRQ.(4wH25A}HC: swz_D_M`ӦM[o5f "ӯDb=o c,3m4<#F0{UwL:~fǎyv-E5HNfl 9-H3>-̃L̂!?/uW\ ҭ(cmPf̣>":veZ3w\7"Lc(a@9y̿Q5J(A#u`o &rൠ2=\ ဴpؽ9r9d:$omCᤩ+B(P;rp^ܲu%Ht%cpT2H2~;xEo̙f…?o<ϧ_Hcǚ^x\s5L4Ɍ?/irJs嗛K1cIxʉfÖ0a8qm;kp]d檫 ;^ʳuV7W_}o-Zdn$?Ӹ-+%UHT2H2~;xѤ1cٱcgD4ib,Xӧ{7gΜDgӽ6i>daKVO>SNL2ݏnݺ-Z*suי>،5*;^KR{|; C=%lY(eR RP#4m۶5+V0ӦM3۷o766mԷkpO?+wOk֬Q ?E6ldݺuЭ]ݏύzaNf剴㕪D!O}k_LTcre(([UUUށ{iР LÆ &Mz^y%9^uO~هe-n[5Qzѣ)VvR+ٵj\[_3KزRQm*j~ _j@Nѐt4jtػ;_:NQ^X?fٞEt-YC/Yfyx~s= 4p/츌e/e˖y!C\͛n\lzRQ\x'`X`k:u2͛7t1 Ӎ1>ޓq۶m33rH/Q/>[w˖\.RuVû):>Iǀ:WR>ڲe7 S7xc.fl Q ,zw.ZePQЎۅ' B40x< ~G* p]즛nraLpſ6:r003Cç( 7x" "P:dJg,5X:/" C@tB-XA" "P:dJg,5X:/" C@tB-XA\t?:93̌96n)71;Ip`plOU)֒=vI2Hu6g4Q.=n~-x:ށY?,)?_?Vϭ~iWp &f޼yAE2Huq6{(1J{Y|7]fh)9ٲ 1mnx WCۮrT4-Am?Q}R~ž1x.7NlfϽyʔ)&"rg]fj8ZmafN?tsG؆}]o+Vu!U1q:$(r+As6#kPUg|ى9hOgC1#VGh.s+"vGs͈ s2F>5!?Cwq A2F Jj'Rd>Ni#~hg0Y;ƀ8 yqZ LAj70Tk'j.);-pPH3Hׇ"열<ՊƟc :A[\~j! 'T c% )ED@Dd X5 @\`-0e R1i.(} aZEs2HECD@D,4D+BG0Jc!|rNU-Vh0|Cnt@ N XUT0Js!@K;g!(8Px$TqS" "P$T:&" E%z^dF ْ*%'x/wYNLxMdҢQ@ lCY !8I.OteL ED@D@ Mo= `E{oɐJ'" B4)#s /??;%9=C0Yqndd& iIDATZ(QD@bJ?G;}q1(ݔ]h2(" "ׅh8%p R =>uj[ʆ R6WD@Mjng\ R6WD@I5tSr] R6WD@C`J#): eK)Z+" OFiZbW}" " ) m)H)" "Pl2H&D@D@RAJEJbA*6q'" " RJ,RZx'ݾ|wuL?IջlNٻ󑯶2,#RHK^[C(6 A~ Jsm' 3|)*x B_N NLbs Ar`+/BcJߩwF1'  Dk$OUOϽCr78|<&_ 8zA4! RAd%AS52CP{2d&ӗ;!l"H/{[AC 4"USt K8= N]}Um !X mM/_}_VgqigS=*TBtNp,l'4"%-N;q8¹YÍu贃g+8uG> D;z"!BkXTe8l۱ԯ9ױ~F:: Y5X!_2R ݃߮Ύn FdzVI;a[gˀչF!>ܟcOXAQW w %>Ï/bxb [E"?b/JضCށۼϲz>71kzͪ8ޮ8~dS6?uGݩ ]F2en6 :icމ'}69npwKp]n>̃ g9(-~ZչZoD@Dd =^~4J380*5;JYKʔ Rp 붖i]HP&"P4|`ECI *GX2!;2(5SD@* R'" eB@LEsP ]HZCܷ9Աv90r! T.#U~ eڍț oA藣7n(>& T`*\|AW5dOwF?d:ʒiRRdJj8*1%\=^ã| _i_IHM!|i!? @@fLY_ tCr`3!|P>*r6{ѐnFY7  d.cF9Iaܗ1|N8!3/04n@2յ'1Z $DĠ NS ]d7s1F>ךw|/0ܝΦYFw6>5w"Mݸpl[]zNZb{r~N=> ߯Nۼ}U8\tR㏋]޽0<߀Y&?ߨͼ-!|f- sDFPHSȣ~S煾4p {HՎ8:}<$U_йF!'X9qf;M6q۫9A'B\|;#l=SNTslt/;tB@\ zTսv }|1nةA?i!|8#L޺m[k厼y߮8mo!_ {r[ gsji::^8NFGo/=26wùyۼ|)ז[2ʛW!?}/U[zuyP?.Tiq|^﷫Ӯun?YAwdNaqͅ"}}9F=BzX.W=Cte}cM/* MJlޮ@à]\|l'^GP /,&tge\yx ve1 >E  +ʵƈUxF'E]\ A{A:ng6yh sӭ9oI^'H/Ƚww77W!K1b\[{O%fU& lr38~ !/8;愗9D r-^0. s UVM'|d_@~9d`1pu#Ÿ?k.TT`"_,$KB~!p*ɺ@ LI{ |IdYߠ@' #߷ -$|M!Ax<#Gwœ:9s ;6N?#l/=|=ԧs~#t +( 193Ƃ)y0ndTezoy?II}{#>+M/ʼp'A8hs]ПM>[G9/zQb̐Fc}p Vțr`3qe8 @.ܗ1_XEWg!ȯij҇K\h]F>Y6iBM jv$Cz˩/>-WAE{ٔkV3!Uuc(ې 4p߅$8!F?y2qwfPcl(\e)Sv? {_oz Z P-%0aKsЦ#!k Sv*_ZCpj_1 5/x1L\tN$hc;4ƈnQ5}&AJX C@8Uv^}OI~$~x.؇L|<& 3Kx+* ݥ՞>Hn]y—y DWjb!ri(=C*1QD@D db9HD@bI@)îN@ C IENDB`content/de/processes.md0000644000175000056700000000466515226251677013725 0ustar0000000000000000## VI. Prozesse ### Die App als einen oder mehrere Prozesse ausführen Die App wird als ein oder mehrere *Prozesse* ausgeführt. Im einfachsten Fall ist der Code ein Stand-alone-Skript, die Ausführungsumgebung ist der lokale Laptop eines Entwicklers mit einer installierten Laufzeitumgebung einer Sprache, und der Prozess wird von der Kommandozeile gestartet (zum Beispiel `python my_script.py`). Am anderen Ende des Spektrums kann eine hochentwickelte App viele [Prozesstypen benutzen, die in keinen oder mehreren Prozessen laufen](./concurrency). **Zwölf-Faktor-Apps sind zustandslos und [Shared Nothing](https://de.wikipedia.org/wiki/Shared_Nothing_Architecture).** Alle Daten werden in [unterstützenden Diensten](./backing-services) gespeichert, normalerweise einer Datenbank. Der RAM oder das Dateisystem des Prozesses kann als kurzfristiger Cache für die Dauer einer Transaktion verwendet werden. Zum Beispiel kann ein Prozess eine Datei herunterladen, sie verarbeiten und die Ergebnisse in einer Datenbank speichern. Die Zwölf-Faktor-App geht nie davon aus, dass irgendetwas aus dem RAM oder im Dateisystem zwischengespeichertes für einen künftigen Request oder Job verfügbar sein wird. Es ist gut möglich, das ein künftiger Request von einem anderen Prozess bedient wird. Selbst wenn nur ein Prozess läuft, wird ein Neustart (verursacht durch Code Deployment, Konfigurationsänderung oder der Verlagerung der Ausführungsumgebung auf einen anderen physikalischen Ort) den gesamten lokalen Zustand (RAM und Dateisystem) löschen. Asset-Paketierer (wie [Jammit](http://documentcloud.github.com/jammit/) oder [django-compressor](http://django-compressor.readthedocs.org/)) benutzen das Dateisystem als Cache für kompilierte Assets. Eine Zwölf-Faktor-App wie die [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html) würde diese Art von Kompilation eher in der [Build-Phase](./build-release-run) erledigen anstatt zur Laufzeit. Manche Web-Systeme verlassen sich auf ["Sticky Sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- sie cachen Benutzer-Session-Daten im RAM des App-Prozesses und erwarten, dass künftige Requests desselben Benutzers zum selben Prozess geschickt werden. Sticky Sessions sind eine Verletzung der zwölf Faktoren und eine guter Kandidat für einen Datenspeicher, der ein zeitabhängiges Löschen anbietet, wie [Memcached](http://memcached.org/) oder [Redis](http://redis.io/). content/pl/codebase.md0000644000175000056700000000416515226251677013502 0ustar0000000000000000## I. Codebase ### Jedno źródło kodu śledzone systemem kontroli wersji, wiele wdrożeń Aplikacja 12factor zawsze jest zarządzana w systemie kontroli wersji takim jak [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), czy [Subversion](http://subversion.apache.org/). Miejsce, w którym trzymany i rewizjonowany jest kod nazywane jest *repozytorium kodu źródłowego*, często skracane do samego *code repo*, albo po prostu *repo*. *Codebase* (baza kodu) jest więc niczym innym jak pojedynczym repo (w przypadku zcentralizowanego systemu kontroli wersji jak Subversion), albo zestawem repozytoriów, które współdzielą tzw. root commit. (w przypadku zdecentralizowanego systemu jak Git). ![Jeden codebase, wiele wdrożeń](/images/codebase-deploys.png) Aplikacja powinna zawsze odzwierciedlać bazowy kod: * Jeśli istnieje wiele źródeł, z których pobierany jest kod, nie można mówić o aplikacji, a systemie rozproszonym. Każdy komponent w systemie rozproszonym będzie wtedy aplikacją i każdy z osobna może spełniać wszystkie zasady 12factor. * Jeśli wiele aplikacji dzieli ten sam kod, mamy do czynienia z naruszeniem 12factor. Wyjściem z tej sytuacji może być wyizolowanie współdzielonego kodu do bibliotek, które będą dodane do aplikacji przez tzw. [dependency manager](./dependencies). Aplikacja może posiadać tylko jeden codebase, jednocześnie mając wiele wdrożeń. *Deploy* (z ang. wdrożenie) jest działającą instancją aplikacji. Zazwyczaj mówi się o wersji produkcyjnej i jednej lub więcej przedprodukcyjnych. Ponadto każdy developer pracujący nad aplikacją posiada jej kopię działającą w swoim lokalnym środowisku developerskim, co również kwalifikuje się jako osobne wdrożenie. Codebase jest taki sam dla wszystkich wdrożeń aplikacji, jednak poszczególne wdrożenia aplikacji mogą korzystać z jego różnych wersji. Dla przykładu, developer pracujący nad aplikacją może nanieść zmiany, które nie znajdą się jeszcze w wersji produkcyjnej. Obie wersje dzielą jednak ten sam codebase, przez co kwalifikują się jako osobne wdrożenia tej samej aplikacji. content/ru/backing-services.md0000644000175000056700000001143215226251677015162 0ustar0000000000000000## IV. Сторонние службы (Backing Services) ### Считайте сторонние службы (backing services) подключаемыми ресурсами *Сторонняя служба*-- это любая служба, которая доступна приложению по сети и необходима как часть его нормальной работы. Например, хранилища данных (например, [MySQL](http://dev.mysql.com/) и [CouchDB](http://couchdb.apache.org/)), системы очередей сообщений (например, [RabbitMQ](http://www.rabbitmq.com/) и [Beanstalkd](https://beanstalkd.github.io)), службы SMTP для исходящей электронной почты (например, [Postfix](http://www.postfix.org/)) и кэширующие системы (например, [Memcached](http://memcached.org/)). Традиционно, сторонние службы, такие как базы данных, поддерживаются тем же самым системным администратором, который разворачивает приложение. Помимо локальных сервисов приложение может использовать сервисы, предоставленные и управляемые третьей стороной. Примеры включают в себя SMTP сервисы (например [Postmark](http://postmarkapp.com/)), сервисы сбора метрик (такие как [New Relic](http://newrelic.com/) и [Loggly](http://www.loggly.com/)), хранилища бинарных данных (например, [Amazon S3](http://aws.amazon.com/s3/)), а также использование API различных сервисов (таких как [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/) и [Last.fm](http://www.last.fm/api)). **Код приложения двенадцати факторов не делает различий между локальными и сторонними сервисами.** Для приложения каждый из них является подключаемым ресурсом, доступным по URL-адресу или по другой паре расположение/учётные данные, хранящимися в [конфигурации](./config). Каждое [развёртывание](./codebase) приложения двенадцати факторов должно иметь возможность заменить локальную базу данных MySQL на любую управляемую третьей стороной (например [Amazon RDS](http://aws.amazon.com/rds/)) без каких либо изменений кода приложения. Аналогичным образом, локальный SMTP сервер может быть заменён сторонним (например Postmark) без изменения кода. В обоих случаях необходимо изменить только идентификатор ресурса в конфигурации. Каждая различная сторонняя служба является *ресурсом*. Например, база данных MySQL является ресурсом, две базы данных MySQL (используются для фрагментации на уровне приложения) квалифицируются как два отдельных ресурса. Приложение двенадцати факторов считает эти базы данных *подключёнными ресурсами*, что указывает на их слабое связывание с развёртыванием, в котором они подключены. Рабочее развёртывание приложения, подключённого к 4 сторонним сервисам. Ресурсы можно по необходимости подключать к развёртыванию и отключать от развёртывания. Например, если база данных приложения функционирует некорректно из-за аппаратных проблем, администратор может запустить новый сервер базы данных, восстановленный из последней резервной копии. Текущая рабочая база данных может быть отключена, а новая база данных подключена -- всё это без каких-либо изменений кода. content/th/backing-services.md0000644000175000056700000001220515226251677015146 0ustar0000000000000000## IV. Backing services ### จัดการกับบริการสนับสนุน (backing service) ให้เป็นทรัพยากรที่แนบมา *บริการสนับสนุน (backing service)** เป็นบริการใดๆ ที่ app ใช้บริการผ่านระบบเครือข่ายซึ่งเป็นส่วนหนึ่งของการดำเนินงาน (operation) ตัวอย่างเช่น รวมที่เก็บข้อมูล (datastore) (เช่น [MySQL](http://dev.mysql.com/) หรือ [CouchDB](http://couchdb.apache.org/)), ระบบ messaging/queueing (เช่น [RabbitMQ](http://www.rabbitmq.com/) หรือ [Beanstalkd](https://beanstalkd.github.io)), บริการ SMTP สำหรับส่งอีเมล์ออก (เช่น [Postfix](http://www.postfix.org/)), และระบบ caching (เช่น [Memcached](http://memcached.org/)) บริการสนับสนุนอย่างเช่นฐานข้อมูลเป็นการจัดการแบบดั่งเดิมด้วยผู้จัการระบบเดียวกันกับ app ที่ทำงานหลังจาก deploy เพิ่มเติมจากบริการจัดการภายใน, app อาจจะมีบริการที่ให้บริการและจัดการโดยบริการภายนอก (third parties) ตัวอย่างเช่น รวมบริการ SMTP (เช่น [Postmark](http://postmarkapp.com/)), บริการ metrics-gathering (เช่น [New Relic](http://newrelic.com/) หรือ [Loggly](http://www.loggly.com/)), บริการ binary asset (เช่น [Amazon S3](http://aws.amazon.com/s3/)), และแม้แต่บริการ API-accessible consumer (เช่น [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), หรือ [Last.fm](http://www.last.fm/api)). **code สำหรับ twelve-factor app จะไม่มีความแตกต่างระหว่างบริการภายใน (local) และบริการภายนอก (third party)** ใน app ทั้งสองบริการจะเป็นทรัพยากรที่แนบอยู่ใน app และเข้าถึงได้ด้วย URL หรือที่เก็บ locator/credentials อื่นๆใน [การตั้งค่า](./config). [deploy](./codebase) ของ twelve-factor app ควรจะส่ามารถสลับสับเปลี่ยนฐานข้อมูล MySQL ใน app ด้วยบริการภายนอก (เช่น [Amazon RDS](http://aws.amazon.com/rds/)) โดยไม่ต้องเปลี่ยน code ของ app เหมือนกับ SMTP ภายใน app ควรสามารถสลับสับเปลี่ยนด้วยบริการ SMTP ภายนอกได้ (เช่น Postmark) โดยไม่ต้องเปลี่ยน code ในทั้งสองกรณีทรัพยากรจัดการด้วยการตั้งค่าที่จะต้องเปลี่ยนเท่านั้น สิ่งที่แตกต่างกันของบริการสนับสนุนคือ *ทรัพยากร* ตัวอย่างเช่น ฐานข้อมูล MySQL เป็นทรัพยากร; ฐานข้อมูล MySQL 2 ฐานข้อมูล (ใช้สำหรับ sharding ใน application layer) มีคุณสมบัติเป็นทรัพยากรที่แตกต่างกัน 2 แหล่ง, twelve-factor app จักการฐานข้อมูลเป็น *ทรัพยากรแนบ (attached resouces)* ซึ่งเป็นการระบุ loose coupling กับ deploy ที่ทรัพยากรเหล่านี้แนบใช้งาน A production deploy attached to four backing services. ทรัพยากรสามารถแนบและถอดออกจาก deploy ได้ ตัวอย่างเช่น ถ้าฐานข้อมูลของ app ทำงานผิดปรกติเนื่องจากปัญหาของฮาร์ดแวร์ ผู้ดูแลระบบของ app อาจจะ spin up เซิร์ฟเวอร์ฐานข้อมูลขึ้นมาใหม่จากการข้อมูลที่สำรองล่าสุด ฐานข้อมูลของ production ปัจจุบันควรจะถอดออกและแนบด้วยฐานข้อมูลใหม่ -- ทั้งหมดนี้ไม่มีการเปลี่ยนแปลง code locales/it.yml0000644000175000056700000000041515226251677012101 0ustar0000000000000000it: # Name of language listed in locales menu language: Italiano (it) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: (Questo testo è una traduzione della versione originale in inglese.) content/en/build-release-run.md0000644000175000056700000000467615226251677015252 0ustar0000000000000000## V. Build, release, run ### Strictly separate build and run stages A [codebase](./codebase) is transformed into a (non-development) deploy through three stages: * The *build stage* is a transform which converts a code repo into an executable bundle known as a *build*. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors [dependencies](./dependencies) and compiles binaries and assets. * The *release stage* takes the build produced by the build stage and combines it with the deploy's current [config](./config). The resulting *release* contains both the build and the config and is ready for immediate execution in the execution environment. * The *run stage* (also known as "runtime") runs the app in the execution environment, by launching some set of the app's [processes](./processes) against a selected release. ![Code becomes a build, which is combined with config to create a release.](/images/release.png) **The twelve-factor app uses strict separation between the build, release, and run stages.** For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. Deployment tools typically offer release management tools, most notably the ability to roll back to a previous release. For example, the [Capistrano](https://github.com/capistrano/capistrano/wiki) deployment tool stores releases in a subdirectory named `releases`, where the current release is a symlink to the current release directory. Its `rollback` command makes it easy to quickly roll back to a previous release. Every release should always have a unique release ID, such as a timestamp of the release (such as `2011-04-06-20:32:17`) or an incrementing number (such as `v100`). Releases are an append-only ledger and a release cannot be mutated once it is created. Any change must create a new release. Builds are initiated by the app's developers whenever new code is deployed. Runtime execution, by contrast, can happen automatically in cases such as a server reboot, or a crashed process being restarted by the process manager. Therefore, the run stage should be kept to as few moving parts as possible, since problems that prevent an app from running can cause it to break in the middle of the night when no developers are on hand. The build stage can be more complex, since errors are always in the foreground for a developer who is driving the deploy. content/en/concurrency.md0000644000175000056700000000507215226251677014254 0ustar0000000000000000## VIII. Concurrency ### Scale out via the process model Any computer program, once run, is represented by one or more processes. Web apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume. Java processes take the opposite approach, with the JVM providing one massive uberprocess that reserves a large block of system resources (CPU and memory) on startup, with concurrency managed internally via threads. In both cases, the running process(es) are only minimally visible to the developers of the app. ![Scale is expressed as running processes, workload diversity is expressed as process types.](/images/process-types.png) **In the twelve-factor app, processes are a first class citizen.** Processes in the twelve-factor app take strong cues from [the unix process model for running service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to a *process type*. For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process. This does not exclude individual processes from handling their own internal multiplexing, via threads inside the runtime VM, or the async/evented model found in tools such as [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), or [Node.js](http://nodejs.org/). But an individual VM can only grow so large (vertical scale), so the application must also be able to span multiple processes running on multiple physical machines. The process model truly shines when it comes time to scale out. The [share-nothing, horizontally partitionable nature of twelve-factor app processes](./processes) means that adding more concurrency is a simple and reliable operation. The array of process types and number of processes of each type is known as the *process formation*. Twelve-factor app processes [should never daemonize](http://dustin.github.com/2010/02/28/running-processes.html) or write PID files. Instead, rely on the operating system's process manager (such as [systemd](https://www.freedesktop.org/wiki/Software/systemd/), a distributed process manager on a cloud platform, or a tool like [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) in development) to manage [output streams](./logs), respond to crashed processes, and handle user-initiated restarts and shutdowns. content/ja/toc.md0000644000175000056700000000271215226251677012475 0ustar0000000000000000The Twelve Factors ================== ## [I. コードベース](./codebase) ### バージョン管理されている1つのコードベースと複数のデプロイ ## [II. 依存関係](./dependencies) ### 依存関係を明示的に宣言し分離する ## [III. 設定](./config) ### 設定を環境変数に格納する ## [IV. バックエンドサービス](./backing-services) ### バックエンドサービスをアタッチされたリソースとして扱う ## [V. ビルド、リリース、実行](./build-release-run) ### ビルド、リリース、実行の3つのステージを厳密に分離する ## [VI. プロセス](./processes) ### アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する ## [VII. ポートバインディング](./port-binding) ### ポートバインディングを通してサービスを公開する ## [VIII. 並行性](./concurrency) ### プロセスモデルによってスケールアウトする ## [IX. 廃棄容易性](./disposability) ### 高速な起動とグレースフルシャットダウンで堅牢性を最大化する ## [X. 開発/本番一致](./dev-prod-parity) ### 開発、ステージング、本番環境をできるだけ一致させた状態を保つ ## [XI. ログ](./logs) ### ログをイベントストリームとして扱う ## [XII. 管理プロセス](./admin-processes) ### 管理タスクを1回限りのプロセスとして実行する content/ko/intro.md0000644000175000056700000000217115226251677013061 0ustar0000000000000000머리말 ============ 최근 소프트웨어를 서비스 형태로 제공하는게 일반화 되면서, 웹앱 혹은 SaaS(Software As A Service)라고 부르게 되었다. Twelve-Factor app은 아래 특징을 가진 SaaS 앱을 만들기 위한 방법론이다. * 설정 자동화를 위한 **절차(declarative)** 를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다. * OS에 따라 **달라지는 부분을 명확히**하고, 실행 환경 사이의 **이식성을 극대화** 한다. * 최근 등장한 **클라우드 플랫폼** **배포에** 적합하고, 서버와 시스템의 관리가 필요없게 된다. * 개발 환경과 운영 환경의 **차이를 최소화**하고 민첩성을 극대화하기 위해 **지속적인 배포**가 가능하다. * 툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 **확장(scale up)** 할 수 있다. Twelve-Factor 방법론은 어떤 프로그래밍 언어로 작성된 앱에도 적용할 수 있고 백엔드 서비스(데이터베이스, 큐, 메모리 캐시 등)와 다양한 조합으로 사용할 수 있다.public/12factor.epub0000644000175000056700000031361415226251677013104 0ustar0000000000000000PK D@oa,mimetypeapplication/epub+zipPK D@META-INF/container.xml]A0E4w@PˀLC[X''x)9& rhp]3\L8[hJ"0lGZkj<%fhSÂ"`L5&+Sˌx(.r5ȝPK D@#clstylesheet.cssuK0 = RA E{ .6NcHbTܝ Y?+Nvx(a.\(zݪe;D3Nk8w0PW߲*WS QԀ㤕/_ul1]̙Haʉn:>}&a2t,өL2JooښQ=KPK D@`=X title_page.xhtmluMO@q0n{4ѤjlS=",q ]K]hxfwhrk8pkʺQ\eu^VE[pxu& Pi3ۣ|^=QuA7 c\ 9:0-SXNsjNb4u Ӧ"]V_Zؓfm`O hhiCt}W tjܒ+ã+~[ULt(8hxpMyPK D@4Zk$ content.opfn } vdc,*zZrDۨ6flܤo?QWK"`xJΛVqA%<[>o$NJWXhNS(ºQET NRL/ׄM.ё,F/ye "x`4);Ae{Q.yRpr; u;.QRF&]'X$&# h,w q (&ώl[98m8c4.N y.dkac_M Ie6͂RDe2ڣ_:AxмyIzh)ihgCRh30}4CC)%E[pCڶLY c°\>C;'-lQGxhu-M߆[6$D_C̣1y'.\މI6\ (_(YbƷf|fƷrssˇ?_PK D@Ho) toc.ncx]o +slNuT"-r7a 1 I__pTkcsy^'Dz{j.E ")\3xJ9DQ4F*ZW0<y8jgFFI03,@lp B3S(ḥEO3L2|K,΃(qĶl;!J篲w#ԸXЯ$ѻ[SfL]TwyK$T5;쨗뜁{a7UVZLV 8Myb*wEy~+"9-ԊP[\K}3̇_ZImj?T#?ơ88 =Iq : /b/Џspp[8C83&̝ ~09~Suzբ6b3 }49fWJzK:;.R* 2.ȽNDL?E{~t1+Y\FE'H%YT+KәkM7m x< ք:xƞZr*GT;k|PKcC@sBL|Rimages/img2.pnguP\6,`q  x܂[,$8!@B w }unխܺUșsfzzfO<&)|D^A4 ꨠåe$<2PkݣS{@D 1 >Spv-^[r,qrq#&΢a]$H w@X$#'y0ShSR7= :ȯ}ڲP_RX:?}d^Te_Jd9ĕ) O@+$x=BBQ&YSa@ 2@8V.)-K n*9j/`o!`L*i35#[G ޫͲk"d?9ڑcF "" "͖+y ;UuF6:@E ƋH=V#Y .QgmQt?F}b3_)BdM,S"p)/v"@JwQcn!D(xj=sZ*3>a #*T_0AB[%3X ZFS+#%8$Vo1 cM%JiIQU:*wIqe J `/r>`d@{o!͐pdsn@ #2³ZT׽jh[s. ЦQYME\a>&Ҟ:ayrOnyuwӁIL}VY6>qTՙ{rɏz/J0F"% u"+N[$ y,=;a X^t-Ttl\v%;x՚=10%.GT{[62E&w݉Iw}xweG%X"HǨD4悫N=_s)BUl[ݷZ9i'ŅT_pR9L> 8}!TS|*LUsh`am\ۨ}Y?:{Iy:*T8ʖ xRR &Km=B|[dT7&gԡPrJG }nO1fi25?Yl/Qæջ[E}3 **Pj-\KרL^`l\͍+zvQeZku_ [GQb#y)o%\<5DWҙB Og=S]Mg>foU։D͆ #hb9v&Nھ 6LSY]Ia;dcXU9aoyL}!K NB<1-EY6MF~ڗox mdզy;R>2ζ~+$,Zc{e7rc3s{u -xYxAmBsy<6.S|܎*c [BZjÆqt\T. Ȟϧyw~8^:"-h|[쏾itQh='f˜jU~-Ϙq "VV7|P3, .Un$XB50ݑ*{MǬRh1{VZM Aa3CtjΗQ0h;MZK)ԋxFh?ҡx/Pw"V[vq 䥛0L?Ap OPS@d˽F"-j2VfJYRW0V`陇XBZ%PBN%dH! EZ.!>_Ҙ|MmI1_b~l+D!chM>*p#}'w,{Zr{4F%\}s`Vtyy2 p|=xr, tum*ΡU ?gƤ2vV9 w ;,D=ދbl)6h`0׭~+ >h|mO^1iYU'IAm019};##{Z]^ gGȗha~a?VDRۛS@Mb\C("ɱ!N!^y%d;+6r:IFA~γ/!Py{TNm4>Sřb3_# 5$.#YdâjGɥu[ >v7A> nhQ.>Đfw9NǾk_ƒge7aps tS暱>5r;{˭hJϸYoc"ͫ8bu 㒭_*PHT:k<0/и4-Bv9%|1X Kz ^gXBKedЇ/n\D}~ ^QCd>hË S˽xr{0VT{rA0w4 `f_ގBviTFDCΒ\/[;$y=ޚ:RP˒ R Rm"]#vQY$WKPs)^ر qxAq놇OƋ `Ab#NV{78,'T1n,o_l&GWu-J pd&T)S$t7a|Շg7)N3ӌMZ#!O!mp%&bQ,ܤGكMo uu$J wO/ (µ&σ?՘ wgiPFZ@'G@17L!KbF@"o#`tōLZFޞ״EWٜfh񁢣S Ȩd}acS GYzܟG5¾jk.6%5=\-V-3hܷјsY`aaKQ!wGiSP`gN>k~sOVHSw,z<s(iăA4 veHKU,K$M@;NzgAPtQFLUP \*^_g$^7ӎ>PΠ*ަ t/DG[]Ƶ'8\x}=զ|$OmYxVSza+bÅ"ZTSMօZ +ʵXː:=)K-ƭ)x8ݒaHA纋$%[[|YM.vUL7e_du,\P` S ;R`mOkB6YBtV3vAJ`\G> aX>_B6@%LИCM[{":[mkC;GH[QrQlX?Ol:inr =mG |QTᚎ?,-%MύQt~qJ TR;Iau!|*t38[ WQ Əޝ4Z˱}6 ̺caec IH8˱n3p_(I+jV;G02&N9OhˬSXּ˃p(Ϳ-qlݔ5bg?=U̡]֌C'G6̷CxmQV|WM1inJ`^waRt_>ʛz78{ƴ/+D/6a bPX6_RҊ5rAp,dRbyK|:CJzYxuR\ʱmmg=;v{ܾ46rE&Vޜd:Bnd5BhJrؽۜ#uY[DOF #ھyσ꟪9@'f =0 8&{icbvĥ0qщ8A٤n" Y?2nSc%RF:f+f/&:V<,Z➀'%f1u ZLR H峡tV4g$Kqˈb8[>XhkYv轥b%˃GܨkԜIپ["?]{ӱ$ht_J;W=*pAʓPFAd+FL5 c%͍nRZ^G`zRECүįsԆkvC8|Oƕ{;(7qƍUU:B1PغҷO#͖HDDCqFC7[EǕ49fqXb;NdTRb}KI2`8֥ZKRy1AnS@M\؄/JO q.mR1IQKbNA G(u;wW* Mu qk]X/"$C s@=)`L߂|j;ҜHVTT!ſxu] Ll~S)DPɀQׇ}9 8gt}M|.e~RR,s{l@Ũ!qA',rf|&6^'~M?gYZ=xA;3*# 1~hlVKB SX rcj} ]kq|uJ`?-ry)0Dw@v^ݓ⪖t|c'u:Wy8mNNP30B)'Ù&;&6pzp'O5#V hAzy{ 6tMoRLnTcJ<)񮞖>L*\L5 +kK'm^:Jb1q &J pDAhUЮ<=}uxy扛2j Z헵-=5hWXRjY;U(T&͒$2RV-9rݟl'v(qӒ4ma2"\E*j I ZXO`/мQd$? {9ğ31Gv7أV&7^E푼z}2> U9|7Ijg?P湵QY\)>5* ,W_*WS [g?\Pn^oi\ 'm\kv7gӚS/ctC}.x-TTt[&ߦA*QӇ\}JyX1:989F{hI (+/1l.(+}ێpO#>auc^Oa~Ld5+ѦQ<쨉O^|l+MW㇠'" w)IsI1"5Xg}.Qn]jp]By?ʕ;a)T59¸G7"b~rFu3ӫ3ل83hݟ7Qo8oBބoMzC:HI/꘧[c'ydOAzFzl!3&+;Mws zy9ӳ@C~p!xOO< \;kժDiAgUv2JKz!:r̰p}u3j#w_V;Фs8uڗK3NvqTLt\qkeU~9 S|/xn.EN9b6~uH|6?̺j\-8cb(!I|1 uwjvzQyy{Fzf3grAK>>5oynӵ XXP yk6Vw>teD׵2ۆ;PKG3.1n.jd+c)DVY9v$lj4ry N@"Q7,y&dA rĉ ( /!2<^PglWZq199*zcj83+O{hEC ܘrx6LIw QϛďkdᄬPSyK2e5 t2I\G c$NxP%qd]Z)dSzG+=wzVM$ 9Vp(xҒMjlAfy-f%y¹,CB];EOPN0a&9*% wi5Jávܯ@vĂE<\Uo;ގ3eJcR[Мs%`(NFPH@7jPdqF1kA,DzfeZw##+q|2˰ .QQ?&F K|X {_vq7OΣH!;%jV؞UҝcHYl;l[/K'X|"Se$U\!< %)q: yǔgOK>5&pk+!924'Oџ\õ͊K$dA5dޓ"who0rkh%'%\2ZY@DPbQcidl6^cw: (}PgZxcPS؟]ŷj o|4^92wB,H#Jf>"1#Uy[w}CIP['B3v{l{h[r-.2'.۩K-~{V&%Y_w$ˤZ`5ywX; {RK>rPAbǕHDP.A39(q(e]"3D$ˈ:+c ɥw҃ztO9O?4{e9M!?`~hSN 3pE`I1MSw|\MZiy}0|#ݿJۏ'oa"YFG17)6AYbs/]i.)ñ0s+SӒf-m;u[ 4*E誘^VTf'i?s#U/)>cܳ~L#MpsUkLݎ_7=M:;+tWKCW,j:SymHygFFwly)f2˭e ,?s=Hf{#ݚ?ojRXFǓQgNɔ)Ҙ d_f?xޚ."~3v Bk-0j1u8l߻SѲ5MJ%&(?Uo{Su΄=A-בE!+=8{ܱ>oNHzn#T%YZ?ڲlzM$Ok9"`>չX4e_"%ʞ8ݶwS>\s{۪2&",/`P3O@>;Q||fʬ /,?cq״U|eKMkrQ:m:h@mTH +_o62Zq8_KϡR<ȫxޭдFw0v r߷:,4t?7\r"-tȫ0@8 C*{֥;Aoiav_XFVyɏL PVsҭT:Lќ>-7sѼE.9Sw (kA$kG->AtA:/:+с~Nmng+?@}Ѐ },IHȬrS T,YB y h(X F[Y`yN%޾{qSSU{+g?[- {6xy%]y1QUL"50h\=M(mt/ȌdO(F~`)5L!Šu^o*jxŽ uxR2?Y,^Z6z8k~B]QH4Ǫ_]: 8̤<8Cc"Y = hþ!C\3c¢7HߝŜL-aLSI(F`3?3BrwZ(c.jd-;P?r*'N]& ?A*sOfV\'i.SNT{p3A89bj#_xtń{K xYBl'%H@JGxTl.YS~|;ɐ^^ #+Y$ż7PoԽif9[ ȺPZ+*ӓ9R sx]puN [BٹPۄhA"jAY3)|<8;כ=%&`;ʽǨ+ ' *P |<;CϳL|3.֎|K?D6&wҚ_j|*%{ ԟ+;HG0z!i x&NZ]5_+N;XVw%OUםP3`6J +'Hf<6 e^\`7?*wo.QB/?*%N̕oZEg+ϯ!{籆8ǕDi]9kb_/w O|9#^N9fԓ\=dr1[RvzP\ӻkpW,qdcKI≋Š'JpzrȭuDfH^;>ܠe]Ý HVkK$T\w/$ynCZ)y3ZI8iIrv曼|?M*k o ^JS7u9.qfKM}T)bˣ#;ME{;0sY[P,1(x! t8HUgt/bo kxI@2Gq{|#66.^2/MF ^O;G.9~U4+Fn~hLr@ Y=Kh;15/]W6 1wDIM''s,N :`_nuoM篹 ȣpʩM%=Z>׫ǐ*u1JҸ\nw9`;\U~Etl 0phs)*бfiEY\֡N:v)VQ>z޾#1lrwxG6bը 7npH1y3O 1y_@-;\x:hz5e|E3^6 {[CГ#@ ,Нa6@TskO$@W=W΀4]z1]dI[cE/rcs1(:ق6]Xjh2[Q.^{ &D?=n"8 AuёTҁX9#%)P 2D8ZO`}.i\M'EWO“F2`hTw&=e -H;@fAAj+zwG'$Ȅ5F;Zv;+Ź '"|rWvN+{Wo-g,7rNVcwZc 23~!r,Y!'> ?$6d[M z-~M)m(*ۿm휻}`T{ӽW|,5/hcQ-gkR0[p41j4UYе* ægo(ڵX-EyFyԆc`l1o*V':h-s)s {,:}δ\jw,4V n֝Jdfʩ<)٭jה\R_ru*C<FZv|lW'^SeM-|Ѱ<1~ Uب۫mbGݔ:ƾ?ܾv yfV|6eN;D}8?EV2RUН"hz%]XakJɴk  *&D+r)v\Y5󨳉7ahX [@%I8J|`YkߵN#,|g[Rl )>oINXd@/'p-Sstt%ª_vЉgz,)Gw9LMd=Wk@z$=* ն#1eM!;IL:Pn; "-! mNn"~҉#_={aO @r- QӉ$O6љeHFMʇdkr:?cx-A-|asiNiWo{jsV\X˻G`pɉ ޟ&󏦚>utJr*E%cX0;V) ^N zK0=ӝ^*KHӲ)'fx$|vSH0K>~q[ )&M,Е Cuj@R?̿0G$1k=p6S$‚A]ވ`|ǠhʱbkCӺ1fE@7M IG\x-¥ +]ᱧ@OJfT>Ε*ŋOz{C"m*uȵ߷p(PH_ l5F8@ Zz6XI.|߈|˛rhDn'1+nkeHdvS PhzcQJ덂Zb#UC]-q1e8 -[&($!J%׏ x"*SM- {~yB0ݿ2wQ4卞{dssz =#ppZ)ҼŌ(O,O ;eD`s0VE%}*} }"@협m hDr%`hU%=02 ]CQ/r뚦Xi4H+t2 U[@f"{U"[^o?xڙP7+0=EyIIIHY'me!Ɵ pDkq\ܰ۩M}񆯶$?TN+ ~f3J reA Ѓq!\,Q=[nVlv8!1ot{InPݍ+4:$B&%q5#xOxsӇS^P+{wKvI:@CCYhFuXtC/\o6d bRdDzeWpb trp1#zl5RvTPtk V~HN+wDn݃ ) z*]bXɛXGR}ި%J |~~DI<؉Eab\=COBf7ltZ,mgU^" O~'{8[ތӥ2HF mN\(*G'oo]w{0iUN՟: ٬t4ե %k:K)htbqo=r,Oe ް+mLUKoM4VzqڌZ/!?h/7s@+>%B_E7+٬8-S~]ܰ[zVᢇwG2W@0d7DPSs /8[ 8;[?B#au1nz2NB67ޅGUxBG7'@6M~wRx.v2. .u 훁t^j< !s)![&tU/]4.VFvp*!쀼  9b˟6 N)mp=h:;F_R-TD}*`6<) ֶ#/&C8}ˇ&x̄T2(oCfCx|y>pwKp]n>̃ g9(-~ZչZoD@Dd =^~4J380*5;JYKʔ Rp 붖i]HP&"P4|`ECI *GX2!;2(5SD@* R'" eB@LEsP ]HZCܷ9Աv90r! T.#U~ eڍț oA藣7n(>& T`*\|AW5dOwF?d:ʒiRRdJj8*1%\=^ã| _i_IHM!|i!? @@fLY_ tCr`3!|P>*r6{ѐnFY7  d.cF9Iaܗ1|N8!3/04n@2յ'1Z $DĠ NS ]d7s1F>ךw|/0ܝΦYFw6>5w"Mݸpl[]zNZb{r~N=> ߯Nۼ}U8\tR㏋]޽0<߀Y&?ߨͼ-!|f- sDFPHSȣ~S煾4p {HՎ8:}<$U_йF!'X9qf;M6q۫9A'B\|;#l=SNTslt/;tB@\ zTսv }|1nةA?i!|8#L޺m[k厼y߮8mo!_ {r[ gsji::^8NFGo/=26wùyۼ|)ז[2ʛW!?}/U[zuyP?.Tiq|^﷫Ӯun?YAwdNaqͅ"}}9F=BzX.W=Cte}cM/* MJlޮ@à]\|l'^GP /,&tge\yx ve1 >E  +ʵƈUxF'E]\ A{A:ng6yh sӭ9oI^'H/Ƚww77W!K1b\[{O%fU& lr38~ !/8;愗9D r-^0. s UVM'|d_@~9d`1pu#Ÿ?k.TT`"_,$KB~!p*ɺ@ LI{ |IdYߠ@' #߷ -$|M!Ax<#Gwœ:9s ;6N?#l/=|=ԧs~#t +( 193Ƃ)y0ndTezoy?II}{#>+M/ʼp'A8hs]ПM>[G9/zQb̐Fc}p Vțr`3qe8 @.ܗ1_XEWg!ȯij҇K\h]F>Y6iBM jv$Cz˩/>-WAE{ٔkV3!Uuc(ې 4p߅$8!F?y2qwfPcl(\e)Sv? {_oz Z P-%0aKsЦ#!k Sv*_ZCpj_1 5/x1L\tN$hc;4ƈnQ5}&AJX C@8Uv^}OI~$~x.؇L|<& 3Kx+* ݥ՞>Hn]y—y DWjb!ri(=C*1QD@D db9HD@bI@)îN@ C IENDB`PKcC@dLn68images/img1.pngm{TT]6 C 9CCH)5t CwwI %Rt ҡ ߌ}Z늮Žώ{X= rRfR<<^^#}t} Q1nd3kH]|p8ZsXuPPΟ GC@7B ?t}{d RdlZ-miD\r"Ny֙9=((︷Sq9 [0av]'@5PeW'^mxDp,!6y'byN\Xe7'ˑУmfHBz{0;r. ivRg0Z&5Yr~ozVs{Fͬ;T)t !' eK\!a=OOxX=Q?jdşWWܡ9@%OimlU8Ö/׭W4|0IpN+g"p_Fv}% GŴLVo[sZjWB_c],RȣB_PN(}LZLX<- ~Ut[8<WiQtkٽ Dwf} kc|~*lTJ|Z)J@%J1r !Kb&6+EB=siq/Uo"E S˼!UQw(UwRn6\P4Yl+/z<1cL3vA;跲=C.7˭ $ R.mIeb?~#'d Fvxt/ptZ̲}L~˔jM*vNjۺyO30#@EsvV@ԩ?!f`J+]r ,fV@E]:k8(ei=y&Ь茏p 4q#]8 CL~hf;Lπ@/e7V89_XE(},;HlvU9~q&׀T'ۥxW 7-3')tRi|,#ч#J5pm)Ԯ ADw{1 j(߅ݘ8د"x~ӨF7.tRߖ5=f_fshߗBtRIP Y^d9O/=8~ĚSwmM_tYZ667X'Nҡ%٢U[i?%~GPQVhc .Bmu;R51甑~^XIKoBƷm^ˏŒ nHbd2d nSu\:P=eOpG#QIΚS57ߺdN}QtNv,R߶DCU A,az'!ce %Ҏi135OWO)*-$E;j3t!al.խmOĐubpj%82@.s,-jďSmf?޾lKwY)} O;,jnJGV"jPMA=h} G -gl|"<٘=HƿNJ=`D&`seWR]]RM&_§YOڈYW|(H#!4^r1G4Qy4:d:kjV_8m;ĀsGÖ!bE%'*B"3Juxa  ?mMr"٬DZT$È Uy(,@h l%6 ΰ?)`鸉?h@Us>O^>|[Pm\gʟm2کgz#$bǬwekuRĬ xS|x:9 r~䞲sܴ}۝eW-mY`l&]VDiCG4֭W%&dq9*~WNOS&6'{wj.AdW-XYSbAYcs;z d  }Vy{e_3Ԗ+%MJ@wT!1Yu QEpG*eBEgyhD\O#pǘb5c[N}T'R1x drNcNC8 #üǝN]V_F ưo.XvT < aXA/'ԫ)ФUvW?д,ɿ^I$}$̵?}/yA*E(!ptuТ#7ݻ@/tjuD;ٰtp ^V&<ٗ2(Ԃ ϔddeD:RG_5j>.=MkXq&z!GS(c^,=DP2stukpإ -)5#),pph3{t9Q_HJ{,Ts lW,XB89ԍREFUkεCA ,4|FƴI >J`cϘV@/`H(9Is4DM1 QcMO<.o!:Ky*-B}V!rDuvvqHKlͣ])RD"vwi?n`Z٫CP =.G>XHdt2nCߍГ ?4K4lM9QT<%Xr]"x?c8(p @fՈ_v,ٌ5s8j6k 9U&SXsԑ"#^BqNΦ\6Ȥ>4 07D6o@EW>#M'yk!`m @QPH$X%?D[W򘧦5CB]Jk !.s + Hw}NdOƹ0 iư1 (ݐ^HT!f蒨\qXBA¦/N شtueًdf-)2EZ?okqtZ]#|W9*: s5Hlk0 amJ6H9)ilu9+:I^7IegHI4~t!¹-bG#_Ib~鵊goةi,EM7uVES[M|/o'b&83`׫j2ejY\Fa0:cm!&A]IKjV(E-Ѧ!@=ש8Kvl{\B }< $x#U5\z"CFnjfex{,1KI\ѹUH>S/\?5C"N^"YU:+f?WU$:S/ Xs_8RwDGDz_>"]4Yxѯ'$ t,MFϟ̈: VS4Ow,z\S%Ms`.$ӭۜj+* g7G]7Xadftџߝ9լEyP!)C2EF<( C0=15b#=ˇ]sƀ(IiH'FKcx L9Q9&2+0]sFu;dfcV**-3[ ZP ͤ+{׊JZش7i=yƆ"i,AvY(&ߠCȈ9// =Peuko'KJ *r oR& _5|l"؈3弁c! s(2"n $tS|^'S&L CS⒈)^2|'69W u?G,5:8* ZGFٌ098nˣ#M-z Pv/ޛlWrJ1z!|Oɂd- @O&k00~7#cCE?eۑA scTZ@Q)7q#Gn8$w(1WkM$+\n|SůC]ٴ85 0Ɨ!('S|/IF#YW?BU :-U闌D,7x^r[RʊK5 :nXA^nf rrz!Rn~5˪-`ȌX9s"x7uL}'iEZ,}2jX8_EwD$\_TWxPG~4}vH{A[OD 4}AX20q"ښ:1Uu/m=[{ / LZgjIJ"f'ΛIwDA#8la_*s3Ko A_r``4ͺOU57o"PtK]*a  fٍI O*Ad+ NUy6yj:Sԕ6V2_z}.BV2+XxbzJf }Fz:ng8&HKQ)qSe3gD^1ڮ`Bnn:>0BQyGñ?!]\% Z..ă%}$^ƤW9-D?Tԁx q/>P2MkMu2R䉓5NWQ_+*uiZ|9RuO~tc%O(9Yro3|3vǟgP 4(wMX': B愁 x52_eSVZ1gSWEwƾ5̅dU:>yTjd*?mF>؝-~׏+Z*"@qTc-E&_% SZ' QD Y!ҫꙦ-iD‰YʄDJ9ʭl.7BMx&pwDI0|qU%ny|Zj }Y]ѐy/W} Fȝ$r5m5yN㭔lwh)7yġ $:#廩RTJ]C+f.ic`A5F+)EgzpRtK @l~( $ܓa~pS'~D:RG^1_5R+nX5~;>XN"ݱʥ>b Uzj5 بf?W"Jn-(} #J ]$v&V܆IIӼ= PUNF86Kߥv?SPa5RH ew0a8jh[D ^o:dTI dYQf!H! +q:#kfNtƵO,fUjߊѽHճ'ϐiۃᰱ^3~ޫdU:͔i%VP]ݣ$ɂl> jpD/Bo"IM iL7G8NC-&M>/r5gbGS\kKN\)ޑKmPp%H !C6$XkY^WTD.*j51^$EWXhdjei%&1ȀgI>01E8gn[7k>#tk9 U&﹠0KR?XSY誊W;DjWgU{LE&_Q+ێ'$  IR3Xr8&dO}oFV1xSG2t'a]4FSmWɏZ&kNՙ#w֔ZD'{1f8&5s 2ukӅۮ!Ľa}S4Fup[kj E=0fխRwY|nGagnc/w<D^(#V}܆- hxSf,ه^c.) Xܪ~6-kvZt;iF?^EGF 5Fe?jeLv\)>p;ušbm B?)DMUG9RaTm?t (&48;b(I+nn Bʩ H>H<-)~k;[cSܮ6UU[M*aN>0P[:}V!6'xbn#4D!]RҠB*[a^poλ40$gtG0#sO0{yކ,gS>QVDUjeٍ tw3` K=f3ִ21 /_xDBa7)z'=fvl_A++Z)$#R-UI[nk/8gq^~qW[$>D2+#m>KFmib]o-)T \ʲ P$;? s;j' j- HoIZc 73kn T_E_nߙ˝Rwz4 jFݮuh:A# թg~jo.W}sӫf I}ۅL(ҩ{_z8*q8by 'qWVԩqZ@ 1d|+ι6q\g]IiPH*+B!s?E$|\(TỸpeN8 %+}9C׏ dwb돕^℅wgrSB͂Iו!Đ &Y8t| բN1x&x_jhdDVN )_`]FIäT \8ʤEKqB^}c5[;{^蟐m,=cp j PϢ"~tR-@skyrį7J% PhusRaLq'+iܪ<ۡrw l=\o)SI%Jm^2kP+6_ĥJY߃޻k춯ӴTyB"X4>Q{gk fG[orK0tp5[O}d$.EyPJ͛bR4ҝ bIg< b&3 S SA=7y8hO"\Zw5 )+ln {" ًG\-͞Ovrup8"B5: *L{V4c7XFɼY]],^WC^ߵES"Z'a%)#]ndJhi]PKH6x[G)!lزYTo crՇitl6A2n^33E)82b1Nj̕;L]ޯ2N >q_$~QK,] ~B-iVv>|GlgmYT5^Yp4c X0xJ@Qȩ*wq- :4:q K/y;bxJI3~1 l47֋9'q"uizxj;*;fոo7bh0}i~mu#h1a4{(qe湲4r".q4"YkUW ;﫚p.!iMϷO|:__).RQF4n]GIвү+'1Mld-X%Ls]Gn: ܯv  ~Q4XMS.2mxy߀{dnOD|bRw$u":͸/Z̚RadsW|Z^dF.BCt1:L'`XEm)> "x4U(X] s_ WGUrK}.;btȵA]#D_PjS&=p=dE[v^W$$ڏcih[XeƤƕG4[sg.9/p+',S+. џ4/S%k?|·:}A=&>g8lL.REy< vHzoe.lC:epVv+mw~I4LQ%%yk 8gNJ5L==" SS>N_SZƔ!&ݰV5#"I?$j99%,01Tk+z/*]"YaDuԉ:-! L/r[#XerCf2P;~廉Pp 5щEF1}Wf8n(3 uƀ.z0+UrgVZ-DQ'XjP˞jN} \Ո~D/e_^Ť@GE%m Rq: v>yo?C*3Xt' O'uwtȩL$]! 3EL]&dJlK&ZW-A#A" xkʗ [7DZ[ kA \ҜAqUUr8<؈\{ow˿iʃ w.VG٣L|o]067΀7;6vt;UO̽iZ]Ɇ/-"v i't[IvYSV`׎ ƺ_o@Mujɕ͉ 1"yN㸋Ş6G*TSvg)"[rw}qS{4KT`E킀 e֕V&T>Xco_r͹IP?=t9nZl?PKcC@ێ ia;cimages/img0.pngw<>Wlj{WծڭZ{SZ3Zj EmEQ36b槯#99'}羯:'HqppHu]O6to^-_Ppqr 888:Lqw \ݿb"[DIuj)GrU(敢0{{"-B$B$;W ~[ #,rA//> *S۳C}ԞP 0> e8@2\!(weˈ{ǀA^!+"w˻BR2]Ei)GR.p_֏*>#=fC7b s./wcY^PJ6__V%8vtP>}t دRP!#W  {@ǵ\KӂCABFXߩug ļ̠duy*oܠ03f޻'6<*.P ~brz#}?2QY-oNH&V}Oeo&etѝi٫cR6"# K /]^]:ȇcU8e?)VeKyhO;e:LQZj]Iw<[R z=\۹^Z\V/B$Y/Ɔ ׳%}ޒkrP\|e KqlFy{6j%^oP):l3 = R& JbTօ#Q wp:F#쏁)jϕ Olu4uZ_BUjoE]%[G e1SNW~ mTVRO+CEhV4z/O*x# {}*xSiZ8>Um.p.EТEPSq́S4{0OTrKT3B`kB S"jIVL"+ccUt򻵶T$^P)S47yo"z&QJE]9e{̓ 4vC) 9_߼@iaP<\J^3%vgs춚|uki?9^MpEQ$7oI2XVc]/9gFk_ gj=A3}B0wvuxY9rXGPSmjJ2 ٗxpJQ]ԬHogm+^s]-50wzJp;hӳ7XE)m,)CNF1\UcQu0VRbtTa"a61x2ώڷj/}֪sI>mjT]\@CDxIQџUu`I3">{I#KuEK&v-/`# <pcS2%kK=ye;ӳ?Z%r@Θ݃8wv$ b*^]{̘G5 V@4KX*Ր3d^;a NPv}0U0pCW@2Ey0Gta%VPMVJZjntɇJ~`sX믟L:@- D Mdl#0,Y}@ܠ1LLU<Vd" -lMFy!)_"Gfef'z(N>FϓkQ7FT䙎N I2ia{mԈ"+4Τ \x[kSJ$Yܤmx޶w=jzz l%dvm : 'WvQ(A1:-$WKxH-8g{&*ϣdqh׌ bKWGm:FR ;xL#ǴiPI>$aT#Ԋb& ,JQɬHR<"ņ _Ș&ݬD[z*p3FY)6Y5˧U'Q-G ?$3/oqbzZ1%=\VqљO+eQWPgժw`Nu>& 6#=٢|ej7C7Sk(n}MiR{{IAz|Ϙo ٪EK-ͯ:j(e?n'g {6@k:f!YiO3߫m+rȗ8&We1%/#n?[QYͬ LT[? i])Gw$ŭxDɲϽ# ǹmF`6 xAjAd_L<,kĸUz5l4+fOwo]ocsJ6t7dr2ʤL VYԷ}xDYcy޳(/b~dˣS\y``Yz*_vaL FQ۪[9AI_4#pBSIihj]չu2 YcogM__W<7 NG-yߙn/4~bZqz߸IH𷖬րpbEKI$*ť~o٢3*Z_d)JXS\~m=nfzR$.zyC୏)d:֪c}'.sJ(:܊P7SU-C TNJ nca@}Gei2F븵YѸH'qL7M\P+ Btf{@21+H4JꏮMF {12/F^FȾ7Drtן1W`q4Tusi`n}}0 Y2"pc 6b%"Cߺd버Q⨫Hj ycx@5ΙYB(vD4J?! ֘%\df2.cO 3ۍɆ _Y)+ubRpjBT1r 3< m <XT B=kN!t0߲_FԐ֠z̗ >N)A2LYAt.l$  M /4#H JAiY,kx}@^_GO 8PDur3#X05I?ɺjh~rHXGlyc I$ f9TcMxˢU6ID0ֈ(|fZGKoM_tޏUofo;;Q7Xnxr_ O!OL Y< ǩp ZHq:@Mk)42F|ߜ!F>wI32-*.t̰ot乵I'#5 3S{4p5^Y eN^<Ʉhb)K=" F ~qVĘ@H : > B5= (oBZOJy #~2ߨ4y\m3e+A6cw;OG6@ RGL+p|vi_V!@ :c,nr-ZU@ \͙Y'x^_d0QǟV,#2fh;b%xI3ԿT= 뺃Tϟs׬>)0޹PyJ RwWeڴM4)r{%bwMEMs[z/?TCZN?c[xBu.U@7k{)2wz P}PlJqE9stpYK?z\J{~pAV#A[f[6`_Ѹf|_E,6i7l'QR)/Gu`Qi 1[M7=8s|'tS"7h*x8"O!o6g; ]̠l rp=ĥ(ྋ!""*) }o2*PٻQ7$Eՠ-'!{e2{BўQU9.u<$@PX eo-V&9xt$"c ޑHNyj_Enh*D 8y)ǵ_J2Cg\WR~tkL~=P;s^Fq˞Lp3.sY?`|KaM2LAo Y , gHp-PgeW$ᤊ+V\zh-At=I=1p+9GBS5?z_LHB m#~0o>s8 >/?Kq0 gDԝ_x5h1*FByަw-?F2<^ W Md i-g ۙZSG"9c*)q!q&f+e"=g>(/%9}Vek/;\[χyïGwmg|Ha:Aׇl/ eATPg,x/.C*;xaK{4P3,.3M/^Pwg kwЮ}q#X^X}51Nde?6oXmC_hUm|) _Q>,&09s'nYߌYuKYZPiௗYm~LoE+=" #j_N`\" gl\Fӄ#wLz"A}0mVk 4Sÿ|\n  .jc3y4I76^E,E;+%v9KV?פQ[pq-ґ}jeSo* {X=J6'W8\`ɝ,GӚҐ#Iv@l ^ʰgsa}LyX kt|/i[]Gzo7{C|bЉ,F]0{鐒/ۋYY:J|^E77D4>lй_P3is1YW(tml wVȻғ Tqԋ\).& faÉ `L1Ej% p11}h;"|Y5pcxO#i\g+N뙺{.MȰ"!;OGudV'/gG@yf(7)#EY!mӹ?! \1}A5=5)?HJ2p ZZmD:P_핰TiS,5N8P&<Gܚ4 ۂ>ў)xII9e]"I ;_{ܨ4-)S\20/FӛngP K?3n pd9?lKv9bGYQh9HPy<-%gOMwv]_GZ"#&'_ym'2.>(]aY>sGBpO8ϴ޽ ~q$R ZOwG?usTs-\n9~v$hOI1,+/gFH҆F*j8L; EЀe~`&F7x$_Qd6۸WtɎܐ3v J6>ghC \#Ԛ UHd/(E:t43ҀfCD,dߚ+Y pܪnؗE~ 5B9vFF/;rُEiLT a/i0Y`NҋbE%/Pob~Xԙ-,>.T3|jpwjcEEY&'+#N nO(!V`YhrƓHiӋ(r_^x_*qvΕژ1ƾV(/lN N3)dgwzټOf@j&[*,}1on~V2UKg+Sᣥ%#ecWby+RNE s -a>=3mW!dm/裗9(֪5k"aEA^6+?dft!Zyi8Wb9촓)׍{wᩥW3q|xnTy5*/y9EUGĂ4ׂ(!#x}xAc4S6GQOEMpX!JʵOL>x D : _'\hiK )"/*K҆?%yil`ݻSֱޙˉMǥY&~^̕{@?Տ'(/,Uetػz[u1<oh?P ''Wp&{ނD.-sOlE+r˾u=7"B|4LuNea5[p苦^- 5oF@tEZ~+ s0SJ~sr[elOsa2͏ids &x tW\=DD!-P;^Hh 6. ZZv,7](?[#d~q+ٿz(s[ȲglkPQ ^Bd[R7"P0qCqX#K_Ah _iJ!'\K߃ݙ#I{r(sϷ7ɿgAA7FݪH# F؄ =k'KwF1jc&SRp\h}EU>}v;yYSq;KXQLYTl;2I<-1  r/O =E,>l.wy[Wf46nE-lG;.Q2D)SǟM.Y%ڇ{4N92\nb,E>M=tif2Z/3 o ei7Jt3ÔΌO4K޴Ml$C.v2Co9GcBsDT׎跺,%)kܿc("@]j^*JV^>Ɣg1KSސ0STucusLrE/f#6hʳ3x o F&Ӱ /bEqW-MәMHfo},ͼ3oyځq+/c55Ox܇rNĂ 7~ߨ $w[Oi<6Ɠe6Iړ Z^"2졤4K{Yޯf]" " p֏T54H&k󞊵m&FN~|T]odHge݅Uu,4 "oRrRUG{:"ƃ+˝fv]\41M{D?_yuEK;Rw=}4v jbk[3<hy\`M,7\ҵ9yBqCۛ2Ĭ`n )"7>Gl蝍gvtہ#|{M=KOyBMÌ62*mՔ!@.nUDɠ(nEH|/U  swĜ<ЪR<F{2ɬͶFsHՍ)e{L)3_uN>|S--#'+ 2 bK. s6 泑G!4A!9@.q΋璕 o8k4/ ݹW*|O͹qD+*@Ðː_R7K<%p<1O/V; RnbsU[@@WkwL8 VKW<2ɽ=>1͊TUI>5&^FRyB26ݟ!v 4tl]W>\z"Ka|ZPK 5.ozT/Ŭ`uq^Gy&a7ۿS%mX$?ڬt,]eIAc^`*$E*B#E[B^-v~CIPcVn?PoC!19*?Q̀AOrJ 7cj7<) 2q$Goc(>iCsLy&㡅&$cZ-Xmcܛ`k5KF>u#k}R7S/=F]UG.A |C [BVwxmK\mavާQb3~+O\6r % mv/m]r{϶/t)/'Ԗ-z$m6yr8ܚ:4E paH)ӉdH/)\M\~JKhtPZG r‡Vܯ07_BQX >񴯯m08\llNN:䨞2}Ъ7wL"͂{>K~C`&:9|:ĸq-7ߌͱ2-Jy}+4)/rtTrj47&*aP}q2,iZE , кya$ȠTK]p}3B$"h AucQ+)6y!13Z;Ǫ]:q3#g%+щ {̳-M^ip7CYES#0jii'hk$oˡXn$lg.Xiqs'FƢYo,.{oJ%VU; <=8E*ޜD,{3zs+1p@9&wpX6v{5g1PL۠Ǔ0#dS _į뭣5~G]zo0ıKD"){!7{ oQ>Q ~+E*2Zwtx^KD8gFp% !?3PQTEaLpyK ӃdO[9_ -Z] u3m4R&᳾n[/?gGX^Shvwk5dz*7':o @O]X&VVR?8lV6R=~BHMmMɳ)EW**͍?"65 .q75_a 2W |2扢K!/~DYu丟[U=՘5TF'z-4:! FGeBWȅT-7i<`/S'ERHׂMyuaKs&b=(&s⾉.vX~j' mnN6߮bF0fy5ޣ.@+eGb*^ ߂#f˔7/A$)_w+J_X+|׮~яR-=3. =ȼYZinx:z6Qt[S~)ax&}mSf5Zqcsjau}]`7&c-8\:Z_ aQ9xXL7p)-!_V9\ngBEruc\7o%SYR \*`TAfNHaD9ߛp:U4Zt)B RU?ߖ{S=JYX[[::})˂)\lW>Ɂ|?M_QOmMgX;&_o ܽz~!11om"&Ey}wa<% Z| ljVhϭQVo֞{McY Emu?:B0f=?"@_{Q,wד{t?D*HsA>ns`>R7p/q\i,>!@J!+D@?]: 1Ct},lN?hy/$9uG se2ɞlq5ޒ5?spV,]BZ((ǐ0V]ةPt)gy"6ޤsh.ؘ\|STM2v6ܣ"tA+M[u4aBEt7j]$|΁{N[fCA%'ty kfIIQ;|4iAo ۇ ) Ȭ){CcHkqkcѪ7䎻^t׎ K Pd*⮒|jH!IG: Oj%H\3uMmUbX]O!?AXc ǭ*OU]ȼ2 䈦M?:deUd̜|!!n^ L9ICM3A3H{߱ZZ2!o: pZh]\ omj6K=d% dA&& ,)w!rKTU0L?e(HE@o\@T<(ڨK's2郺7ڱF9=B.eMT1E?UjNWZ\ꩵb:*ܩ2T(A"s/ |vcCG18(6WR,膃k$X' *i|K۴gd m-=#Xp.2{Mz Rc>ea 0/ YGa"f֞/ā\)t 9̸8ռɆ>ݩGuP\  oI߫6ʖKz-d M 0 YFuL(/xuotL6e C2 5zFm7vG(P6o9d fsz (@}}nq4\0f%ZimZSAPliMU\I%b0{vҽ?4-s a'~rCi3["?BɆX ;Xc}4vc?|%򞥰)%ͽ=//>á`'~=3aXxvXvT"U Ob{A\Ty8UL3|zt-˸Bؿ/ODC,gߜ@ḳdkxCYfx@y:8Q>I "-'T145:XPXƚt!q>2tn]X})+$Δ L7<]d [_.飉A^om7̬/桵ת] ?Iճw@oרG՛p|R^R/ A6-|XkmFEAH+{"Tͨ+CP*_32YOg!z(]O+oe̞^%fY_(pe ^Kj|7X/MD]XoȬ眤ҴSްߌvv2zMv2T'㢍!)wa0{;ݮewjQQl}(z'rm_y Bb˷hG?L&G޴sYQt&0W7쓗օD#?'N\җEDKĕtݐp{Zw1 Ҳ{8!ܣ鲁XXIdr! s̢67cy׵mN)\jŴQ bb)omj5~T5l[06y,KYa|ފ_I {v:c& ϒtl3kI5.f5VJ# w[6S}/6rYrkj3`Uێ;_E؈J)6 |/憀Sޖ ]O%V!"*va֯7$B6@<-zn 6WP) :w'ѼFSB^犧Vy`- G&D+2yS<Ә~ܺt|b]%QˤŲ!^AQ4- m!x-}Tn=5FƵi1`ZvokI#~>_{qz1yw0+5G{?KZX۰k9qˆ#N=zwUWrVu^PVY@My*G/~tJnF`ɄȝXt ơ@9D(tե#n?ɯ-[B'3q-(7^ծZ&S V8Ftb yWoiACe5UWSUnĿ⭧/EnܲYF~{ A+ !8-M#Lf7slCxq٩{vۤ]!|7o/$˕;[oݽ^3]{R٥v!,86۲a s@K"PJ(>ܬ k[uKgY8bse7Q]訒QQ=ԁvjp*ǣAMp+e g< *Y^L'/Hюc?w ι1߱}|qD&W߸bW=2+z.{x-wUɻ]#xR٘bwݷ ;^wM®qѵ(Ϳ$EU@~Зo %|Yyz疫O>;[I$F?& B^zG|zmkz3u>aI;yH[ *`Drl/֬xgYZv\VdwaåS5cI H>и)/"41E0fd~^mpP'X#s6yL*TX3hQ"2|hђ[{cmK URn譁HE4qE4'揾YelWFv` Oy%d*̈́/  {2ɀ)VvlxzD_~k$(]/\z*J6n3cƫj>Y~UTϙr;$b- A\ݮ6 1ǖ`W "(>56f߫|:hg![{+?M&S`c} zL*ුkȲE{$‚c0 Xg)g*Mqu߇4 L_@hDkޖt>wY R/IW%Zx<:ȩr6æfi%Й'Mq4Qf 1 f풣Te,ϩD,sfnn"ܷ:C0Q}J2w͜]ł^y3-0J! C>FǞVmMnSBUm1X6.@(ш !0hmѳB5LÅ<3\>G?h"U Wo)S$@0:KjFo؛5m /^{CDָn5  PQ۪ՈLB"ŠJ&M>tAli&ωT2+:=n ?ǥVB=BE䱏zE[v߈U# JȰ }c(4VN ss1BAR@۹὜Y9K-';nrv][Y C-R^CZ*ʢM^6JFTD)F9xeR)hkSĊ>Hoȋg ҞdG*o;o6c{f Wߓ*)Ic/kOf8%`!ӲP^)A) M'd X@_GN)w](mTY䥉ցݮ]+07k;9.>nVhܶ`u˺]s% Aե\!ĵM2@?$h&XzՎN[WϏKTd֥EG(Du`.p΃YOZ?lzj|Lʩ5^;"^Q׽#O| OXFGEcw7&u`c_7+^I~篘 m6W~q |o%J?{b3pǪAŬ.Gj/L&9q^>Y*U-"CƑ )js[u{UH6,| MZ#!` #Sv4KwN_K'&3nqiWԃ2L㩕tc*MDN&/Rq_*y@{wynFRd^N0ZI{5"Br,%Ai7;xa^- hGx$ oE}iۙ"}zXINC] 2;}$2RŠK~Tqj- O[Q'M _X(pK8+NZu{ 9\\sgMJa8_@Q&jjgh jXL&zY7 ɔ>صWK 5I _MGgl̝c!w+Ě]°8?+o>1Noӎ ؽ{ f&1I0O$ezx?΃ tj-*:"$Gӣ)G{Wd*9HoT]&y\RO5xP,!*Xȿ6mp `zL]oܷڡٺhfn0cky30=~YT ,OݚϲyA+ mv0h}=StFPyZVocVzV=fр#զg2YֆLa Oя=Spg.bh䄖M ؼm#GG9.eH7䧤j$o-E@5!v={=vS]gيr!{(ר/zO~%O|VݑjW+ ghjB$4-G@\؅so\bLy)[E`e\P\:wF}@5$sFWײh:̎>KOKR;:*@eּE|j-el1fIM8ש+.@A%Iރ6vݜם=ɯ%ANg.?"[rnBaYe213. KnLf.K` Iɿ}땋qo%LL, Pi 0BIȠ*M Rq]"H1?ڹ_jMvs L-t `$`BE涣4ۦ 4s8X{=9Ռ`W` 0͙  o*4RvT`q\ܟiz>k]0dܛ7ڤ5Ba"lW0mde<]7G]PhЖ Hh~?Rn tv7s]gR'lO#)0شTP3^,]"M)جu{j#ӠFURjbwH9Y_%d/}h\NvB@S(<7D|nmq_/Lwy~;Oݚװ`E0(Oqv5c @(r`?9757Y o6dΝWhC"*DLT(/_:k"Z{Qs ]3ac9- SzAvhi[єv7q FK6β  AB9 ּjG岜S>[n?XzFfH7_pB?O`\Bv_$,@De(ijoY&RAyϸ^?\-ݧڮ;K?t]wXʭh/ZgY 6>; p#^",0QK䭴ِOk>fy4?Љol]igT@qm#f&~K[ByESJ /;a<{-B2;-c:wE۫CUN׷fPrw)=M=yijo *jF{F)+vvQM؈떇X"HUcQ eF 6וXAB `{,B IX7X%ՄtD:H0kF%MyScl dDʟ d %m% "C )qSw&EmZ-Sr֜p ~.bӶw|Fj(bx8s-ss,:E8 皧u'nUHY%v0NxmUr{lK$ѡ]HL\|KH@/ k|eRsrhOjad xAN'vQWqS0>"P{(6!myZ^Jy ؁krnA_Q PM)ˉ M)1Ŋc}$AWٱkכJY{>ZK;6_zkք =hqÊ_O\ LwsOumG~?Ê{7~ZC`rp#jcAEPIWV{^9ɽPkiI?|[URMx /`2jwaKTS RD.*כnm_v*[0jv!Տ7޼*gHr럴WvafH$+Ɨ'ԵSLvP]܌/lS S]MA Es))/ZŴ XN-ǜ W{Ys& l=dR{͉wۛuci4va3)i_C?x$l Nh\$H+bimvG?3<} ,6H~a\Oq}_4R%_0u)(i S":"{YzV*kSS3)V0\Ӹ-?2WWZL+OߩzN)\{ִ^/iv8{%xi{I ^2u`Yd4`̏{;w6o)|]& \k٭[L2i+$S)gA`nAnC$_cy~ξt>ุ=P[X7+gosm3$,gN-ePK D@^41^)fcover-image.pngwPk˂X`J/J{EtB' @ҥwP{ yw~߿{̗qf]n0]-=+G+qkfYR^0wˇ^Np4+~3/m(z< Pc'P/($**?//0YH@\4// !7[^~qqc-xpwK/8?GP!]-_"<ܥs .}X8 elFCa6z.0^( p grᦇ@8塼CMK+{m) G[­` ?"?Jb""rJWa g_{_an0k%7ݲp-| B"{_Zk_徼bx_ @\|ƇAV1-Խte ׵|~_3 wki4_ Q99q?F#gUbuZn=$_T]ꮾS]Hv=ANGߛ'QM62۝%))/F&ZˌڕJ֭Gdggyܸԙ.rϞbkmghrwWts122_z$!|||.-,NJ/L0ۯol"Žzu \y?ag{rvNNd 2:iJ4ij奥S*<<ď,H0.\(R㼒Du--j .ڎͩ_-at _6 336ӔM\@}E 1 Xt T?irn>MT] ܬ 9 Ս>1k=Q9ލO<@l߸2~3v.HJJFkKK̖۵1-$Ĭmm988Ͷm@ N..Rfkp.º]jHn$G aNNN骖p/4)T.Yɹ,J5AYYyO4ZZZ6foLbݗCCC?W r!a䳰Lq暜Ũ43%tTvM]_=d {YՍ CL@Wl}XU#AAA~^qEqѪœs|99cY j:5ƞ[..Ms&aijt@9Tlf(z(L+pBo>IF(+Lfxmzۮ_!X,zkI廥`amb-% m 2Gic(:rg::4&[I4ЖP(soYVVy{IZU7ZBB"!! g^.MNNV(6,h˫T6 `-sIX116y9Tm )B@Ό @ }?aF 502oa݋oZ[[`LJ 㽣{%r/_~$qmHhO쬊|˯3^v*J]qZZGA\3\c^qNJJL89^6Zӓ kI(2(;;9Iы=d;cjYix?۫ߋ3p zdaU|<вP  8T9յQɑ/CB[Leee_?1{-E2JKwtˉ 0qFlҍ KINL&*!޻'񆉉IqXZ_$=GLj`300]I>)b4HS\{p 33Ve~Bڲz[咷HHHHQblj*p6q r̊? jjEG,|X\qa-(FW};X A6F4dfR8=1>E;%srr(JP@EEEh31VƓ}Jn_X7L$z݁YzُgH˪*OҖogoڪ>yhgݻ_BMvk (Da} ms!dcOYxp f`ʓm2 (rsHK'w]d_hVV^nQ2%;Qo~嚯[2@uD2B`g e8ğFkwʂ{\]c%_\3m[p"Gye%%;ĹO>(wк}No׮]Bű rrf}T.PոVob!f,>~X,m $'%ϤϻXt~6詧A˽qa@%tuU9üg'Ӎ@# i_ uy3330gsT̒E?hV̸ {02ߠ@))U|}}W5zċWFqm_,Tv300`mU>@(>}$#PRUmPӕ,91b E_fE 6EMA!8@bGϯ&ưPaϓ㴬;ݰ".Z:1p@]EqZ|IsS`Q$|z4-6PSu/[5| *D}ww2k'N {Wj@+TAViǷoPh/_119^b^!F d+JasssMW ӗ}嵀L mrk$ 789/YJJ:/7×q7c,;M^5mhq|%?;[KVu̾ `6OnZO9:8X^~KneeE;Eq0. =4xPddßΞr lksaD4zRynq1o[#jH m-B~ XHr6cOv+"""WwLqỲt|%Vk<$q;2`~Ȗ5?Ï]|? AMe)<1$ V-=R 6RLZ_b'''oShS0g&"H!׷¤,X0pæa _5 +Z) yԤmRºR]]]xgAF޽nkk8;>G#3809,F9Ĭxp5kj#Aʶuq\'! n2bPK\ZҲp8E<憙i;yU7Uv`o p'y_:ڒ6k/CS@. !cem k!NwQzK=[NR)hB\h6:e@]hO7=@No^R%H=\xKU M0=<!0l#f(;_b@7tTqdF;2f\P}t*Ŗh~58.mD zL%K Hk{k(&Vlog0iErZ.!EwʖE۷oM@y=>eq?䌢E4oB)v`iI qI):Txպռu7sĝo9hl\ 7t%ȏs0bv~^2$> ֎xo=2x; Z*:M5QGW μ?(K߶;.RiL%i0n4&A@ ]]u=;9/Jd 11 !7U`bfE4D@kܵ {R[']`>Wi\=K&ﭿa` zys֋X=.!!{w_o/rZF7\SN+Uu/L-@G93qꪌ6~QR>Ձh\b՘:G\\0.}.)oM,+k٫Z Q6$2667sEC|[ǫ&]' 45.T22ׯ\6'CNڤV+P 2l ‰"\W(S̓L ~};i w_`4wTTx@md ̮}mJa_AI+4%pj4-"$* ZSiU6@eB97YYYncݤ@=8 2K~~;׌0+,Ά@& +( P;"ئܒyG͸?x}#ӜG/׷Zb9TyHIIv>VƅD#H`P]LMgua@;XY!aڽKuvBcwvMjs:L4TR\|\% ~mD-;i,SYU8,2=ٳg@gYկio[=I_SL߳p=it|U<%%2v Ӽ!h>XCИ=oL+07??xGGL1/e\Wu8azJyu,2Wv۠`7wB :ڧ)0kpYII֏Ouonc\]]1_m `b.P6YYS5knff&kW9BfzzINz꤈nq꒫`Cک2o O&gT<  `inCU %{n; V7Ob+M7&CLBM&o[N^L>Z.zScdIy"2瑽by8lE_-(.2&OIZZ2$`{S|=ߩ2ph_LxMTZzuD%9LvxN>/| " z290u}b✶JjSS:P({r?S쑙=kІ8+'`H}⟿ȡH]_\pj%Gd^YXz@+7ή%wt&u0%%%Bт ?,r8=k vX "ԞwHKy)\<6Ngjl v6q7=,hjQ]YZV0?7HՕx|%R]6::Z 8j Z0kԮ\أGRE㡕& }+Mzhs\pun* QM`f{s寿qӱ.]@R³ig=Hs[%Eqgqp|m m0NyDa.A$KQP %dZeu Oݐ<\*Zv KKw0D4?T(ݻmuX6̏Ka^qz,M\akt b&xGNN}x!_v'ѭ^:tU9j}Ҧ#K~Q9uuh×@4֞U̪t+VjiQ4^x?'wNҡ^BBBppHHy*7 !Dc5ΎvW8wz,LMӹʁ͘M2$ @"OyW&eB4vkFDLd $aNC| @xg\囑ѽ;wԉ GVEkvv7-y&r*p SX'.ɛ\]VDy}5iy&!+5htU]C_$pʕ+lllsBwwwG} jq|Vf;My0r e1: ZVXᱻb%!11Wbu__]}ɻZ(bVޖN%H,* V8RiY箔E\xå96X);SP x2tݑzqV P-plzx1ׯ5R o.щ&0\8<[lV#3ʹk*4 Toz+9;r[Oc>Ōb,;8p923@^6g|9M1}v}I-qt_Nѝo% 愅uTÒlW$ŶH`$,lc\,SwI,G%&#`4bu34t F=KDf*0FWUURrP_?adF@ZLо(bW c2;!hqKsVo .TMA |nɮ!k|R_="32ֹA4e,fD5h4ۻ*jSU6BmF׃>LKDAvvWX2f^.b\ >? =pǦ>$\0K֜oGHG+D[a?gd44WpE|mAaqƪX%楏(RGΞ1 gdj: Ҭ‹7]sjhzw'BQ\5!XFHK=AC n_YR7ũF<TJ(0Tq]35 5c]([U)=_0/EHX]-- rw.(W ?]3*g02<gQoN4Sก4kes#^#Հ@qNˡub@ـz Hq@{n"?xzA3CWIqNfE)R]h:r$=QQ[[[,v Pى4+tJ ?+ZZ꺵sYA>-ʂ]3Įo8N5=88HDbˀ+O -D#`ƦXEħ,FJ-_QQs_զ 8p8 S\TPh+>#!3UMN䟉rC__kjO4K KKYK7o]20z^+rF^`;=<<ʹa8W} M;o=K%Πl;oMr3Fv5GGJQ_a-ONz/w BLJvvCxxD,a3| 5 4lw,+K] 4%+tl^iUT WΠ35 V}ʓV2VW&ZNR+t_ *f`t~W}_`xn'1@ &C<{Hak9B^3YiwyǾtiPLZ^N(qiوgsݤo2 $F5K\U3i{8t쿂,091X͠Zfd[vG+vr_#!r`<.ٞ+ʃdW,XJW ^zpY +u##'Wwm.aoO@Ǩdl xdYV]X_:4#whY  SRxȏuUN6o=+йş|-ed0zo>b:7":v&=Qu\mס+U{y3B΃?H_"9621I86:32"؝0"Yƛa}OeMq \jJumm`|JFYߙ7 x:jqyPMzFTI1VuY\|:1(#r\i* ;e e~.qpőΦ{1UgpŘvn `:O+Sd#=p[&߾˜4. c]NnHhէw?).pQWWȓ#dWm8UYA=]$,Ř}5LfcJn~|g;^`7NV K;بBRyȓg jφ<0t¿tv#y#f֠^˨ywGcA1W"/-OmNnʂLے!t*M7g6w=N{>62'᷑3Qjg~nBhl=]I%(lj^Th*HC_;$pD4־?0{?TJ_7G*2UJLԏ-F|~R}D% ,]-~16RKAM`>Ds ^Wrxj ;gH X*fݿ#j/6igeK Lvi֟Ā +żɝ4}߬ChY^p2s}x$cR5<X`?=JACXV[0ҾtIϵ随'_c!wQȵ#-􏅴m n{Dݧ3s1s4BxxU.e-|RBBO|7HN\fkFycwunо +@a d1d/DB$y[o<[.·3@S⼰A]MUbPqboxđg eviy: ^:@]:J{kPd[p>qʈʮӅyYt'Ee˥^~Gl/3qxRx6<WKqyL6W2eY/*YCxGnq<|4ګ7`f q:UW'o^]woX[o0гW>yd9^X9&n>m坴+Gӓt 4~dmW OCiR׍W &PΔ O<̷>V?-zk|cYi MsJ$''8IE̝WH}bY;Y_ -OyD*qBd,LcQg;f*Z(_* U*s?0)Z*OxY31.;WT_/erHH2<ِ)CTR%k9W/QYK u>n8rSi'4ҵm\GPh$ ׷CjSyw> xЛ:q Rr;{+n?G9xՄ8)1REkٕxN!EX5O!Nf둎Ukov+7֗*N|Z~2W៵|B{ߎjm&NFlz4z +Qҗm~hX!?iQAy+c }R=DƝ"όm\+ηf)MI.;Uxo%߷uc:q͓uxݚ!Xdmݿ|Ukx u% sd?[ϔkv2dKeFEˤXGHjKꋎ5ºgf&x-7 =ru bqD:WNg""eeeUtJ{f,'[m+U+ Zh 68[5_-[pDAq~Dm}Xz^:|k=|w&?lo[W6Qmr3T*```фv8U_|TqŽSi|S&K SJ-?I}oGDb{ Pikgkf8*Iؼ]Xx^hBrΠD>mb{J䮾MZ%YִDEcl;;M:<Ӫb;Lc2to1KWOy\nLI;nGnyڭ4M-5ã5C O<>?' k~Wp:K렁l3W砋07fkTقq:K>/'r%w:YȾ]A0!8IYUUUhljyV/!ӞQNe[KHqcصljll}Xh{**۳OW)1@:Q*jq<+YyP~̛>Ak \y2]e[6'3;~p%g(0U̔{+d:g;qb,[<:U]5;tj;OИw[rAhlnJYm@6u`c݆Z{O挨LƧw=z/L`_e.U4,tkGfMw^/?? /Hu1۞&[oKopIs JAkmа_C)/Tw ) Uacl7 M'xX [OWktlNJ*{\{ՎX;6m9%CH7 $=8_̩WSm Ξ~]>G=J>}*@T)f~ qd7Bt#`c̿j<@}*(*(Rf-^#%D HPBEE4!, &%NI(!{?y<\3g(?pq,FI&̝%|=*-ֆi&ly}G *`@h.uQYn^ ʂbHoej gp@_*Cђb5/S,37U, `U47HE ̈Ɔ}X'U@UL |kp\&p$]pu§:G5/ɤ*!>=X5F(m$^.+n㴃X8v|m/w +Pz[c;K2j|wtD RBD-M4ym{ycKi C1?z (*m:ӻ8PݻK&o1|kTFk.<ْ4rNAŝ:deے"{E QDkxOjʊnoh(l-Λh=ʑTPΓ# V!sU5ҤleeW>o(1Q"99w7ҞQ}Y#&yZ#G퍠'|̏s|ү5!'ALo-2i8+E^KgQI~D{8O]XM}ԆhyfTZ_$q|M^ C>+t[6@GUu/06Y# K).E'%5UeesBgDؖرC10wEHODۼ3*XsŏmQatA% _t'N[@V[RQ - f5~ߐ|g.4] f'^T`P0t0'^&݃vCsPw\|>+"}2H&(E:ZPwGꑔB-8vD\ڎ?X9_Ze梾qO] k=k-֯$Y J,yVǙ]:zC?S1艳ؿu5 y~?^_|80e文WƩ5jl{] /;_޺z^/@F ֘3]z0V^Gԭ\vv]5OSpc>>׬ԹGҖx?b~ TvCxv'`E:)Ym)htO$$fQZ/qcY>&}vV6;5x{ycl^@K2hE {F8~fĦD8IbHeERW:+Y -44M՞}m:9i Ԝml솬Ζ仛50ٗ{=Ғ β ]ʟ ql .>x*=֟I&.b[LWBXj:nͰs!ΙOss3ßu/hHhԤ<ڊ4?#(؅qo'#:[hbTFNwG3lZa=eg )jl=#,8U1Q}sP5Xj+ ز;c rp_e]1LClZ-v]֊6Z0Ye߱2c)L:#ta;7n;Z*# ;u9o&fT8Ƶs Fڭٻz^j K3tjv !Le~TAsy˒@3΂[%JJ3ۄGS]jx/VQ7s%s*/+;lx3%/ҩQ}M-/C#W"b(s.嗏OzJ>z?XF๨rբ݁ͲUH`[WvM_C.u1f%Aao4ZKb&2)WqMy}3o"~{ CPv_>v&K3FLH!xc`la`H/:UFY)]uSar!R]kd:Gh3qv+2\r廭~ToԱ{S.-~;>h% 1_LaaM]ܰ~,J̍^keʃ-ٰG~\.:(`.T]SPG4HzY(\s-Zky=UsB(.ha=mH:b#Y+Ax~0d;2QLz6ߌ[~5fnwQ}Vے_q{3\lUDo7VkòDUHDS{`ЍupD| < kJJ%vaSY5vCVԉqi1Kd]JKx_ǫ(T-u(7찓5tbMe m*GB0#ȸgfAU@)OUM]6zW`w}0z#6#Py,9  > >"ךY3 &Hw<[WB(][y^xPϿIxgR! &g}btUrCrr_Re^z7"`zOمS^_V9a?M)jv,_b2;ܵ:UO{cu_r?&@}kVM+;L` XFr.]E6uhݻMFŞTnGEy8dFJqor}콺4qk9]nAhPSZȜF:c1W_4MJwĮ t~F, d*utS+ڹ$n7{+/'Uo uG:@AF\h'j[ fa&K;cܵf=5 +Nǚ&e&ߍNPdi?|JoP> yc7X/d+ԤJk:D.3(ur )xvW$kq8pSLu qJ=m.w̄2?wG &QA7{ ha-{I Ihw)7]Wj;tc/"n: p8c>[H,|f/VܶH8{+rfEUG44r9' y*mF]u _vo0 vsA<^}# xwP۩1TWm<)[jG|4vyἲjT;P3K;H`faNAt<#נXM͗o'w@Axn|G;ujl5e˜]!n )uVW-l NVk ooWJ!Co{R:pWQdt,Ül:oj.zy7 ?/GJom厛 CBRqeII5=KxTp+Nf:O5]GuN*:][mi. USUֹՇȐQx8?q+ҏء4%$?ҋJ ZM/ #1{JW KN٠tg_,ݭ P @DDۤlVuz`rZ5FDmfd_?801tr:Rmuu !&TϪB4,ή2ҕ)͉m[1=9x|%e9HnI3R֨)-Lu?Ui.\ < ףM@|Ӻ{F2dt5:2urY0/Ennxއ%Ht2 WIʏ0Mp빨_nGAͼ /_q #ORyTCl2 5,&QƟ(Y;;7K YQ`@O&wR{1m~g& O{FBJ x% #?+HVw4a$}6Q:5l _:^mνgw:(6o!Q;T{] % R='l=zx<^ do%3MB&pH:$0-SP+ ~}:k2jJev +iq E44!--.9 5no~tB@&nbU= >_Ȅ@99>xQ0fxKXZ',|#ڦOoyhs IlfBl|X}E}$bvաYm}R9]W){! d Y(FȗӮZٷ@*#9 i6Yvp{Y%'oWRV}JgԱMvIw#O!r`7S:ꝏFb h׃y4ulc8xAÁT ޸IN˞1PoTL(ҭv: Y[2^T0͕apЍFB=HJGyIguJt6!{A Z_ Z8nrrE$)_:1$z89r)?j\2Wda4Gfh^u b֠/[s)`UO k`~:48ֿ-0ǤBaw:Q+-Bl-J0L1F~OΤ:;aaѶJժ@6ltr.1T ҒH:Vydw,}̐r#!UC=ԟǐH%o8mC%j[黥n4x}HOoHo,{/ݜaps6 "Ɵ9O8d/dl<@k{x2(믭yq87v:t8kQ؏D?؋Ђ>B>lMxyP#{R/g WPK D@3 ch2.xhtmlUr6+(ԩLb;g&*+(E9䠡}\}l4ye:[/3@SYa}~nV~@?y,x}S[GX˲5}S}ºC|drɀ!(C Ld_NxGPA澀+q'<ʴtv_g> } : PePS82 +PrYy52W&wxR*ma\b'0`20`-q0(ͪݼУ>aUDۂ t/?'N>`U5?tU甠tn7 xGvP]LA&)5PVl61vHN; #M >_Z}C =iU>8,N -2!58"ÈeX%;УW-j1ga xN/TF'eGuxl.[Id8_reh]DS#U<>ݡ4h$73/YYSR-)7WZsG{cvC3Qa*lk:ZgeWEA%fGz4PG]OyT| @ZwBm:?Kt&Kʁ~5l4'd'х!=w"fHuOWvnor8!Ƕ.PwN9D(Hy{!9ܱ sӡ<,vt#m|PuٸΥϕ狃.~7`$_ {Rm WmE.`rkF ն E(hz:\eVo(~E$WmJH֐n?b 1n}K009!&-u7d?Ghw5}Xһ耈k9%=&`-ꉂ2sN|ACXkVՀvlF߸-NȷRD+CEi]PΆJdQUAC@^jN(2JKYi4|# l7  .d"m"cJI(bLDoC3`ܮj/Yv1ɽƩϑۧ,oo^RoeRL&Qit1t`.q P`ՒMoFu}^(?KNÂӬ@rO @U_Of8Vt+SL餀H- +!X$M9?kK;:W69;B>$$ zG^&ߘgPK D@^0F ch4.xhtmluWMs6W:͌$ɥeeR'OL#D.ED d-@HH۷oūV9\2\M~Z>Y۷ k1ϯՇb~Qo?NĤ {Y~>nS>7y NWxEmIVx4-onnښZmEZzlE㨾p0/pj>#=6ስ|1gBU:LYhhFf5-0YޱHB12gE|m_XP,* B` ՖA+v̞Ȉ:m^~*:g _wmGn ӹX5LE-^gw%F @F%\KOSR USaՉ,'S%E_QjAH}4/!xwυubWG/f)_`6Ukc}0%QI ;nJ~ NwۖjѸfp7 r"BZ2;ղ7 a9+ f*r;nmbr:F AY:}4naKA|`{.R:QZ p2!Ե1=k)E+a10 Z6*4촴-*|aDG(?0ʨ z.S=G,35%#БCn(2T.-zD&`{9d80hT\G;: WYCglU6hIn,>3z?>Vh(m ~d-Zq4qswx:ą?)Xs٩X9>(P'5=K%%BVAnɀ%g=c(Ȁ!v`z{pBxr4J5VX%kGdmeF؟'ƭ4q'|Gsw-q)zbS]!&}% z}-k+eT>NӐ[ja%>O4;)>[s9!C@}ɍ8SF+F 7P.JqI~kձȞgf6\PSŤKDZy:l0v"sacP\_xJ8|dPrbca$%ϔfS?j#Nch?>&f8 i@pA279,2%{/bCU&Au{$c:+0}CT$Z?$RO4⽏`Sv2oe*h'M˳PK D@MG ch5.xhtmluVn6}WLzi/r6@:N/8S_!ue]mjj齔CcV749TB7s14ꟗG(ٿ=?C_Wiz_-aLKQ\K6M4W6yZ}:;QQ8}9$ΟLe[^Dvv.fR-77uD[ $6Vx9|wioPEZkGBd.^w6mbFXV Z]:+o 5 [hMy>gfXO|f) ?g VUiej";*t6[bƁހp6%+4̑(x|geEP9gY*YC,ׯϠ k:ye,o5*mmk_2e[Nί =ֵ[Zq ۈwa0#fZ`4/YZyN!b\3K:0 )%6XZV☋R(aɁ h XI&ȼ N{CJ'uCHcZ`j(WF'Q@@{c -sF%#F/<:eKkjEwdRW=qC/O1ΊAΡoZd`4M9<#>ǣ ˜ݢ?p ԬiH ̄:Cf)WVzЮ~&zޖazG9d G 1a812'p O?-[Z )i6DYEO }J2}t`< <Ӑ5dL?:φb}.hhv,$W.Q^)Jv9=xM!R֣YS}Tn/^=CxbL6~ 9}0]R,6<vF}Y5N\;9mRWh{-@n. sPK]ug173FGau<6t59<,o2_PK D@ s ch6.xhtmlVM6WLuh`mٛmd7AmnqEX"oHvdK7oxеg5b>Ħ6e⫻_ozw^}sKŤ,xz[wwO?t^~)hBop8LOm僸0֡.!F1/;Y򈶬jZ^>n+rܲ?YE͎Ǜeñe0i}AF/s{ ߯I*lj^9x2Ԗ}-hGю`'A)!jѯ^Fk$)8eƺk&XRX3yϭ;6 ܷHqv6˜,~0Z7L V)}4XxD꜊a@ "\!~jjJ3؃!%1>xP 3nP#*]+hu}1izg+*h6}DsϦ΋:@^cF򞃟.J`sO%BAt΍r:WzYQNTpA[vT ISxSĎꢄfAimt&PRGLҁG Iw¥q D 6{HTcz{~M'v%صj0U#]{q#;e`[@M})] k` UBw%l RmXB5cb%A{wpIij,A:U!Rb\?ǚmS8pFU3+Ө9aL qT,'׈[X(Yw^AUV~ٙWX>jA1 ?Zj7FحB; C"R-Dn6P: +ڕVWuCٶ=V(4O[k/i/JR`};kXFu$Dָ80Dhf{j]:b1,]HcDUpc R^̓G2jtDSG=?0"TR,X=邖{ݝ,+n9sި* t=Yޣ%$D)=ZaMk4݈$h*7ngו8qc"1nxcuk4}nfx槂PbVE[Y`JW \zc,-) 1 rP;9hMr2ũ/=D'BDV!|=A,NL F oJ5,O5c eCg;4 M 2{iMA3=y-zfPTY[:u-DJMD&) sƹS-w@ƾ?g?BPK D@j ch8.xhtml}Umo6_qӗ--,bKR$Ev)lHd D=w*?>v輲f 4V*_gէo͛?Ϫq}uٲ(?+]V7װWEqqAֆ(xdՊ\Q~wuzz<- IA/WW9l P+ø"])2:ܭ3FE y}aq| E|weP1%9dtJW@u=-=j/J,dm.@пnSX{!xaP#6C@ x%`蠱&e:2]qm թ} ŅA^4-eUm@Aol׈EPK5ME˝h oP1z$zʲ\A Acbk8#߱ $P Mea 4E!;4q(T&FEk>:L"u:2MPs8pEdh& CG0Њ]]Q7@Fhx@mE8]*g|p7c aGi:PfY O0AD-ACKZ¦%v@òER 8'?VGmG?ZX6ͅZWi85qR2"F_#'aFxP\LEvĦFx鉹 床P!4@O"6wzE]Qƞ^M}ĦW_͛PK D@!kD ch9.xhtmlVM6 WtwƶtlgdliI{%bM*I#Uio=@AWО}γ䇌v;V?ffrcÛw7<]Wh:ۏeUOy~8&(ө8B dlw#ٲ*'hxnB74˻g3*ϛyp!xjxE>TԞ)[RW^sl;#m h| wGU7G||*) TTڔcD{ݨ}KbWrl)W8<^ I 4.Rw=UӽP5_4lϨJELk㊝N!r-pI5ӵTixѪ-J肷ʘSV;Kk'> eRJ}WIg¹V}`Jtɫ=`L%k9"Y,fSaPݏDIӐ-r 칉R9(@|+FX[:hK}Ot T_a 0ik}szB+PZ)#<)u݂P\FK_rp[Bzd1Q- ɊֈD5y&$ŒѼ*^985PT-5O=P2~ZvC="A i uzA&(a֥W׉Irm1v2Yn`GQr-|![B eJ)p Uɾ7d*L%[N}h&|B*Yz ;B(kqeTUb< Ń:Z1]^DYAwTxor|b-q='Iw UK`gY.gPK D@!A8 ch10.xhtmlVv6+}OR7iƩ(/"W"*`PIَ^l bggf\8ֆv<~ȈmJmً7]*bWo/(gy~oV7oi>ջ*?J|.e `+󳳳>"eU_.uh\Pkmtyh< 3*8+B(v g1O=2֮$kɰWOIYԻuF8 Q6Se֫7;ly3]0I0I0 `i E\.WS<32yRMmƻr \/ˡË?'TbҚ\ 5 ծfquQ<[CrZU:t!ȡ/ BvB^5:9܆<4RvaG v-"l;nOEʵf OmOj5 uʘyG(F>P`+QwӃQ-*k E+6j6G :`C şnfx圽.vPSm!iG w$=>Ou$Q]6(Fm'?d8Y{g*`AOSuA#ŠJT:Tl頼WT<jELbő$';(p͝Zd<)&Wm$dC5/eJ/82:Dp <5G+oӦvQa$ca|WދO*# U(QGuct$"wFJEzZޝ$} ,z>4. RIP< 7gzcU&urO2Ѱ ƅ8 >h^2x҉<%9@@˽|T'"{^xi`VB&ˋ_yz|.A0jfWLH.Ԑ7$FW( ň(Aun jLCĄ Ym=Lڃb7QЉO y|r[>PK D@ ch11.xhtmlWMs6W4:4c'NıIzȕXH}YbK"۷cŚW\ ƿ ,/_fGLM~t5(}y{뫫,]of7l|e>Ġ >ϲf3޼[f#Ay\b11ׯEYIR~4jA>e`?dt):=YNa&%t˃jZn%Ȏ "yQXuFFTք2ּwō'G?a5",Ι=) /6"ɠO:T8;XnW܊Gx7A|C״. ËZ%Ln['e.{P&!B b¼Zzr   x8wUd|wݾ6DD*!ܩ9rs ݂|ǟ\cl[BW\A#z|o  e 6a[JvkI'fmuӑRUi#C^]zcƕA nuB+ ʔOC TEӌaNI r+O5|,niA+l\!}p8 i ZE۩-K5?LM^bBT]$)`zLzG(הziK&&^v;yK%{ʭ+:>,I>3w-npmHk|xK@ {0hyhj<>:Ա~}*=U0&AztB/Z-Kc߁\U+&P,{ddY-DVV j4rgkC:M%E {&.ɨ-c^ v9МLbdTVN.= g](A `FR#4Y$^i6A4A鑖Fe}P X83o޼j:&eElKWi\g^lvwF۷ʊofC_??&Ż?Vjc_8tPЕtᜂ!_t:505s~*K˥Ohש90[Eh T .OiP hGerڷa^KY$պ9lz29IFINzYp/D}ga4Q԰Ÿ0ٜU**`Fi`>6*>RD4DIZF I J. %!f;e}0;\ܻH4g$U g3LmjDhЂo\GP^,N,qC01l;}y[rK[0~PS!H{/㦛N3!6_T \+d(g_PK D@NǞ ch13.xhtmluVMs6WlyiPys8 s̫2CWYX=c SՃdN>\*](1hU[nET!,TX8 ,|}o)JM'^j|H[1Cҁ".j wcq):hu?tTA[ 2U#4րqK{.ao!3ёkWpN5ظ65D)PjYGcrZ-x}5TЛeѭYajUS>!8y5"wVu,1a(u瓡WLufGvJp/ =NB6g^*=Xw6s&{/5ZI`Zqf :ݣ CiD2Jʼn;bz(e NXعo77X42UJը$ Z 듸?.S9Q<1B>T^w1:F͞Һs5UlR_=W!㔳uOǔ=Z,MM%JRBٴj\yˌmch7.xhtmlPK D@j 6rch8.xhtmlPK D@!kD `vch9.xhtmlPK D@!A8 {ch10.xhtmlPK D@ +ch11.xhtmlPK D@ܽ: *ch12.xhtmlPK D@NǞ Rch13.xhtmlPK^content/de/toc.md0000644000175000056700000000226315226251677012474 0ustar0000000000000000Die zwölf Faktoren ================== ## [I. Codebase](./codebase) ### Eine im Versionsmanagementsystem verwaltete Codebase, viele Deployments ## [II. Abhängigkeiten](./dependencies) ### Abhängigkeiten explizit deklarieren und isolieren ## [III. Konfiguration](./config) ### Die Konfiguration in Umgebungsvariablen ablegen ## [IV. Unterstützende Dienste](./backing-services) ### Unterstützende Dienste als angehängte Ressourcen behandeln ## [V. Build, release, run](./build-release-run) ### Build- und Run-Phase strikt trennen ## [VI. Prozesse](./processes) ### Die App als einen oder mehrere Prozesse ausführen ## [VII. Bindung an Ports](./port-binding) ### Dienste durch das Binden von Ports exportieren ## [VIII. Nebenläufigkeit](./concurrency) ### Mit dem Prozess-Modell skalieren ## [IX. Einweggebrauch](./disposability) ### Robuster mit schnellem Start und problemlosen Stopp ## [X. Dev-Prod-Vergleichbarkeit ](./dev-prod-parity) ### Entwicklung, Staging und Produktion so ähnlich wie möglich halten ## [XI. Logs](./logs) ### Logs als Strom von Ereignissen behandeln ## [XII. Admin-Prozesse](./admin-processes) ### Admin/Management-Aufgaben als einmalige Vorgänge behandeln content/zh_cn/logs.md0000644000175000056700000000361215226251677013363 0ustar0000000000000000## XI. 日志 ### 把日志当作事件流 *日志* 使得应用程序运行的动作变得透明。在基于服务器的环境中，日志通常被写在硬盘的一个文件里，但这只是一种输出格式。 日志应该是 [事件流](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) 的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。日志没有确定开始和结束，但随着应用在运行会持续的增加。 **12-factor应用本身从不考虑存储自己的输出流。** 不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（`stdout`）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。 在预发布或线上部署中，每个进程的输出流由运行环境截获，并将其他输出流整理在一起，然后一并发送给一个或多个最终的处理程序，用于查看或是长期存档。这些存档路径对于应用来说不可见也不可配置，而是完全交给程序的运行环境管理。类似 [Logplex](https://github.com/heroku/logplex) 和 [Fluentd](https://github.com/fluent/fluentd) 的开源工具可以达到这个目的。 这些事件流可以输出至文件，或者在终端实时观察。最重要的，输出流可以发送到 [Splunk](http://www.splunk.com/) 这样的日志索引及分析系统，或 [Hadoop/Hive](http://hive.apache.org/) 这样的通用数据存储系统。这些系统为查看应用的历史活动提供了强大而灵活的功能，包括： * 找出过去一段时间特殊的事件。 * 图形化一个大规模的趋势，比如每分钟的请求量。 * 根据用户定义的条件实时触发警报，比如每分钟的报错超过某个警戒线。 content/it/background.md0000644000175000056700000000275315226251677014056 0ustar0000000000000000Background ========== Chi ha scritto questo documento è stato coinvolto direttamente nella realizzazione e nel deployment di centinaia di applicazioni, e ha indirettamente assistito allo sviluppo, le operazioni e lo scaling di centinaia (o migliaia) di app tramite il proprio lavoro sulla piattaforma [Heroku](http://www.heroku.com/). Questo documento riassume tutta quella che è stata la nostra esperienza, basata sull'osservazione di un grande numero di applicazioni SaaS. Si tratta di una "triangolazione" di pratiche di sviluppo ideali (con una particolare attenzione alla crescita organica dell'app nel tempo), la collaborazione dinamica nel corso del tempo tra gli sviluppatori sulla codebase e la necessità di evitare i costi di [software erosion](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). La nostra motivazione è di far crescere la consapevolezza intorno ad alcuni problemi sistemici che abbiamo scoperto nello sviluppo di applicazioni moderne, cercando di fornire un vocabolario condiviso per la discussione di tali problemi. Oltre, ovviamente, a offrire delle soluzioni concettuali a queste situazioni (senza però tralasciare il fattore tecnologia). Questo format si rifà ai libri di Martin Fowler *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* e *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/th/admin-processes.md0000644000175000056700000000755015226251677015032 0ustar0000000000000000## XII. Admin processes ### รันงานของผู้ดูแลระบบ/การจัดการให้เป็นกระบวนการแบบครั้งเดียว [process formation](./concurrency) เป็นอาร์เรย์ของ process ที่ใช้ในการทำธุรกิจปรกติของ app (เช่นการจัดการ reqeust ของเว็บ) ขณะทำงาน developer มักต้องการทำการดูแลหรือบำรุงรักษาเพียงคนเดียวสำหรับ app เช่น: * รันการย้ายข้อมูลฐานข้อมูล (เช่น `manage.py migrate` ใน Django, `rake db:migrate` ใน Rails) * รันคอนโซล (เป็นที่รู้จักในชื่อ [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) shell) เพื่อรัน code แบบทันทีทันใดหรือตรวจสอบโมเดลของ app ที่ติดต่อกับฐานข้อมูลทันที ภาษาคอมพิวเตอร์ส่วนใหญ่มี REPL โดยการรัน interpreter โดยไม่ต้องมี argument ใดๆ (เช่น `python` หรือ `perl`) หรือในบางกรณีมีการแยกคำสั่ง (เช่น `irb` สำหรับ Ruby, `rails console` สำหรับ Rails) * รันสคริปต์ครั้งเดียวที่ commit ไปที่ repo ของ app (เช่น `php scripts/fix_bad_records.php`) การดูแล process ครั้งเดียวควรจะทำงานในสภาพแวดล้อมที่เหมือนกับทั้วไป [long-running processes](./processes) สำหรับ app ซึ่งทำงานกับ [release](./build-release-run) ใช้ [codebase](./codebase) and [การตั้งค่า](./config) เดียวกันกับ process ใดๆที่ทำงานกับ release ผู้ดูแลระบบของ code จำเป็นต้อง ship ด้วย application code เพื่อหลีกเลี่ยงปัญหาการประสาน (synchronization) เทคนิค [dependency isolation](./dependencies) เดียวกันควรจะใช้กับชนิดของ process ทั้งหมด ตัวอย่างเช่น ถ้า Ruby web process ใช้คำสั่ง `bundle exec thin start` ดังนั้นการย้ายข้อมูลฐานข้อมูลควรจะใช้คำสั่ง `bundle exec rake db:migrate` ในทำนองเดียวกันกับ Python program ใช้ Virtualenv ควรจะใช้คำสั่ง `bin/python` สำหรับทำงานทั้ง Tornado webserver และการดูแลระบบ process `manage.py` ใดๆ Twelve-factor ชื่นชอบภาษาคอมพิวเตอร์ที่มี PERL shell out of the box เป็นอย่างมาก และซึ่งทำให้ง่ายสำหรับรันสคริปต์ครั้งเดียว ใน local deploy, developer ใช้กระบวนการดูแลระบบครั้งเดียวโดยใช้คำสั่ง shell ข้างใน app ใน production deploy, developer สามารถใช้ ssh หรือคำสั่งรีโมทอื่นที่กลไกกำทำงานโดยสภาพแวดล้อมการดำเนินงานของ deploy เพื่อรัน process content/es/who.md0000644000175000056700000000035215226251677012520 0ustar0000000000000000¿Quién debería leer este documento? =================================== Cualquier desarrollador que construya aplicaciones y las ejecute como un servicio. Ingenieros de operaciones que desplieguen y gestionen dichas aplicaciones. content/it/processes.md0000644000175000056700000000472215226251677013743 0ustar0000000000000000## VI. Processi ### Esegui l'applicazione come uno o più processi stateless L'app viene eseguita nell'ambiente di esecuzione come uno o più *processi*. Nel caso più semplice, il codice non è che uno script stand-alone, l'ambiente di esecuzione è il laptop dello sviluppatore e il processo viene lanciato tramite linea di comando (per esempio, `python my_script.py`). Tuttavia, il deployment in produzione di un'app sofisticata potrebbe usare più [tipologie di processo, istanziate in zero o più processi](./concurrency). ***I processi twelve-factor sono stateless (senza stato) e [share-nothing](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Tutti i dati che devono persistere devono essere memorizzati in un [backing service](./backing-services), come per esempio un database. Lo spazio di memoria o il filesystem di un processo possono essere visti come una "singola transazione" breve. Come il download di un file, le successive operazioni su di esso e infine la memorizzazione del risultato sul database. Un'app twelve-factor non assume mai che qualsiasi cosa messa in cache sarà poi disponibile successivamente -- con tanti processi in esecuzione, le possibilità che una certa richiesta venga servita da un altro processo sono molto alte. Comunque, anche nel caso in cui si usi un singolo processo in esecuzione, un riavvio (dovuto a deployment di codice, cambio di file di configurazione e così via) resetterà lo stato in cui si trova il sistema. I packager di asset (come [Jammit](http://documentcloud.github.com/jammit/) o [django-compressor](http://django-compressor.readthedocs.org/)) usano il filesystem come cache per gli asset compilati. Un'app twelve-factor vuole questa compilazione durante la [fase di build](./build-release-run), così come [l'asset pipeline di Rails](http://guides.rubyonrails.org/asset_pipeline.html), e non a runtime. Alcuni sistemi web si basano inoltre sulle cosiddette ["sticky sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- che consistono nel mettere in cache i dati di sessione dell'utente presenti nella memoria del processo, aspettandosi future richieste identiche dallo stesso visitatore, venendo quindi reindirizzati allo stesso processo. Le sticky session sono una palese violazione della metodologia twelve-factor. I dati di sessione sono un ottimo candidato per quei sistemi di datastore che offrono la feature di scadenza, come [Memcached](http://memcached.org/) o [Redis](http://redis.io/). content/ko/port-binding.md0000644000175000056700000000446415226251677014331 0ustar0000000000000000## VII. 포트 바인딩 ### 포트 바인딩을 사용해서 서비스를 공개함 웹앱은 웹서버 컨테이너 내부에서 실행되기도 합니다. 예를 들어, PHP 앱은 [Apache HTTPD](http://httpd.apache.org/)의 모듈로 실행될 수도 있고, Java 앱은 [Tomcat](http://tomcat.apache.org/) 내부에서 실행될 수도 있습니다. **Twelve-Factor 앱은 완전히 독립적**이며 웹서버가 웹 서비스를 만들기 위해 처리하는 실행환경에 대한 런타임 인젝션에 의존하지 않습니다. Twelve-Factor 웹 앱은 **포트를 바인딩하여 HTTP 서비스로 공개되며** 그 포트로 들어오는 요청을 기다립니다. 로컬 개발 환경에서는 `http://localhost:5000`과 같은 주소를 통해 개발자가 애플리케이션 서비스에 접근할 수 있습니다. 배포에서는 라우팅 레이어가 외부에 공개된 호스트명으로 들어온 요청을 포트에 바인딩된 웹 프로세스에 전달 합니다. 이는 일반적으로 [종속선 선언](./dependencies)에 웹서버 라이브러리를 추가함으로써 구현됩니다. 예를 들어, 파이썬의 [Tornado](http://www.tornadoweb.org/)나 루비의 [Thin](http://code.macournoyer.com/thin/)이나 자바와 JVM 기반 언어들을 위한 [Jetty](http://www.eclipse.org/jetty/)가 있습니다. 이것들은 전적으로 *유저 스페이스* 즉, 애플리케이션의 코드 내에서 처리됩니다. 실행 환경과의 규약은 요청을 처리하기 위해 포트를 바인딩하는 것입니다. 포트 바인딩에 의해 공개되는 서비스는 HTTP 뿐만이 아닙니다. 거의 모든 종류의 서버 소프트웨어는 포트를 바인딩하고 요청이 들어오길 기다리는 프로세스를 통해 실행될 수 있습니다. 예를 들면, [ejabberd](http://www.ejabberd.im/) ([XMPP](http://xmpp.org/)을 따름)나 [Redis](http://redis.io/) ([Redis protocol](http://redis.io/topics/protocol)을 따름) 등이 있습니다. 포트 바인딩을 사용한다는 것은 하나의 앱이 다른 앱을 위한 백엔드 서비스가 될 수 있다는 것을 의미한다는 점에 주목합시다. 백엔드 앱의 URL을 사용할 앱의 [설정](./config)의 리소스 핸들로 추가하는 방식으로 앱이 다른 앱을 백엔드 서비스로 사용할 수 있습니다. content/tr/dependencies.md0000644000175000056700000000535715226251677014401 0ustar0000000000000000## II. Bağımlıklar ### Bağımlıkları açık bir şekilde açıklama ve ayırma Çoğu programlama dili destek kitaplıklarını dağıtmak için bir paketleme sistemi sunar, Perl için [CPAN](http://www.cpan.org/), Ruby için [Rubygems](http://rubygems.org/). Bir paketleme sistemi aracılığıyla yüklenen kütüphaneler, sistem genelinde ("site paketleri" olarak bilinir) yüklenebilir veya uygulamanın bulunduğu dizine ("sağlayıcı" veya "paketleme" olarak bilinir) dahil edilebilir. **On iki faktör bir uygulama asla sistem çapında paketlerin gizli var olmasına dayanmaz.** Bir *bağımlılık bildirimi* ile tüm bağımlılıkları tamamen ve eksiksiz olarak bildirir. Üstelik bağımlılıkların çevredeki sistemden sızmamasını sağlamak için yürütme sırasında bir *bağımlılık yalıtım* aracı kullanılır. Tam ve açık bağımlılık belirtimi hem üretim hem de geliştirme için eşit olarak uygulanmaktadır. Örneğin, Ruby için [Bundler](https://bundler.io/), bağımlılık bildirimi için `Gemfile` manifest formatını ve bağımlılık yalıtımı için `bundle exec`'i önerir. Python'da bu adımlar için iki ayrı araç bulunur: [Pip](http://www.pip-installer.org/en/latest/), bildirimde ve [Virtualenv'de](http://www.virtualenv.org/en/latest/) yalıtımda kullanılır. C bile bağımlılık bildirimi için [Autoconf'a](http://www.gnu.org/s/autoconf/) sahiptir ve bağımlılık yalıtımı statik link ile sağlanır. Ne olursa olsun birbiriyle uyumlu çalışan yazılım uygulaması, bağımlılık bildirimi ve bağımlılık yalıtımı birlikte kullanılmalıdır, sadece herhangi birinin olması on iki faktör için yeterli değildir. Açık bağımlılık bildiriminin bir faydası da uygulamaya yeni olan geliştiriciler için kurulumu kolaylaştırır. Yeni geliştirici geliştirme aracında uygulamanın kod tabanını kontrol edebilir, ön koşul olarak dil çalıştırma platformu ve bağımlılık yöneticisinin yüklenmiş olmasını ister. Rastgele olmayan *derleme komutları* ile birlikte uygulama kodunun çalışması için ihtiyaç duyulan her şeyi yükleyebilecekler. Örneğin, Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) için `lein deps` iken, Ruby/Bundler için `bundle install`'dir. On iki faktör uygulamaları ayrıca herhangi bir sistem aracının kapalı olmasına güvenmez. Örnekler `ImageMagick` yada `curl` kullanımını içerir. Bu araçlar çoğu sistemde var olabilse de, uygulamanın gelecekte çalışabileceği sistemlerde bu araçların var olup olmayacağının veya bu araçların sürümlerinin uygulamayla uyumlu olup olmayacağının garantisi yoktur. Uygulamanın bir sistem aracına geçirilmesi gerekiyorsa, o aracın uygulamayı sağlaması gerekiyor. content/uk/build-release-run.md0000644000175000056700000001040315226251677015250 0ustar0000000000000000## V. Збірка, реліз, виконання ### Суворо відокремлюйте етапи збірки та виконання [Кодова база](./codebase) перетворюється в розгортання (крім розгортання для розробки) у три етапи: * *Етап збірки* — це трансформація, яка перетворює код в репозиторії у пакунок, що може бути запущений, і який називається *збірка*. Використовуючи версію коду за вказаним у процесі розгортання коммітом, етап збірки завантажує [залежності](./dependencies) та компілює бінарні файли і ресурси (assets). * *Етап релізу* приймає збірку, отриману на етапі збірки, і об'єднує її з поточною [конфігурацією](./config) розгортання. Отриманий *реліз* містить збірку і конфігурацію і готовий до негайного запуску в середовищі виконання. * *Етап виконання* (також відомий як "runtime") запускає застосунок у середовищі виконання, увімкнувши деякий набір [процесів](./processes) застосунку з певного релізу. ![Код стає збіркою, яка поєднується з конфігурацією для створення релізу.](/images/release.png) **Застосунок дванадцяти факторів дотримується суворого відокремлення етапів збірки, релізу і виконання.** Наприклад, не можна вносити зміни в код під час етапу виконання, оскільки немає способу поширити ці зміни назад на етап збірки. Інструменти розгортання, як правило, надають засоби керування релізами, які дають можливість відкату до попередньої версії. Наприклад, інструмент розгортання [Capistrano](https://github.com/capistrano/capistrano/wiki) зберігає релізи в підкаталог з назвою `releases`, де поточний реліз є символічним посиланням на каталог поточного релізу. Команда Capistrano `rollback` дає можливість швидко виконати відкат до попередньої версії. Кожен реліз повинен завжди мати унікальний ідентифікатор, наприклад, мітку часу релізу (наприклад, `2011-04-06-20:32:17`) або номер, що зростає (наприклад, `v100`). Релізи можуть тільки додаватися, неможливо змінити реліз після його створення. Будь-які зміни мають створювати новий реліз. Збірка ініцюється розробником застосунку щоразу при розгортанні нового коду. Запуск етапу виконання, навпаки, може відбуватися автоматично в таких випадках, як перезавантаження сервера або перезапуск процесу, шо впав, менеджером процесів. Таким чином, етап виконання має бути максимально технічно простим, бо проблеми, які заважають застосунку запуститися, можуть призвести до його зупинки посеред ночі, коли розробників немає на місці. Етап збірки може бути більш складним, бо можливі помилки завжди видимі розробнику, який запустив процес розгортання.content/ru/codebase.md0000644000175000056700000001005415226251677013507 0ustar0000000000000000## I. Кодовая база ### Одна кодовая база, отслеживаемая в системе контроля версий, -- множество развёртываний Приложение двенадцати факторов всегда отслеживается в системе контроля версий, такой как [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) или [Subversion](http://subversion.apache.org/). Копия базы данных отслеживаемых версий называется *репозиторием кода (code repository)*, что часто сокращается до *code repo* или просто до *репозиторий (repo)* *Кодовая база* -- это один репозиторий (в централизованных системах контроля версий, как Subversion) или множество репозиториев, имеющих общие начальные коммиты (в децентрализованных системах контроля версий, как Git). ![Одна кодовая база -- множество развёртываний](/images/codebase-deploys.png) Всегда есть однозначное соответствие между кодовой базой и приложением: * Если есть несколько кодовых баз, то это не приложение — это распределённая система. Каждый компонент в распределённой системе является приложением и каждый компонент может индивидуально соответствовать двенадцати факторам. * Факт того, что несколько приложений совместно используют тот же самый код, является нарушением двенадцати факторов. Решением в данной ситуации является выделение общего кода в библиотеки, которые могут быть подключены через [менеджер зависимостей](./dependencies). Существует только одна кодовая база для каждого приложения, но может быть множество развёртываний одного и того же приложения. *Развёрнутым приложением (deploy)* является запущенный экземпляр приложения. Как правило, это рабочее развёртывание сайта и одно или несколько промежуточных развёртываний сайта. Кроме того каждый разработчик имеет копию приложения, запущенного в его локальном окружении разработки, каждая из которых также квалифицируется как развёрнутое приложение (deploy). Кодовая база обязана быть единой для всех развёртываний, однако разные версии одной кодовой базы могут выполняться в каждом из развёртываний. Например разработчик может иметь некоторые изменения которые ещё не добавлены в промежуточное развёртывание; промежуточное развёртывание может иметь некоторые изменения, которые ещё не добавлены в рабочее развёртывание. Однако, все эти развёртывания используют одну и ту же кодовую базу, таким образом можно их идентифицировать как разные развёртывания одного и того же приложения. content/tr/concurrency.md0000644000175000056700000000602615226251677014277 0ustar0000000000000000## VIII. Eş Zamanlılık ### Süreç modeli yardımıyla dağıtıklaştırma Herhangi bir bilgisayar programı bir kere çalıştığı zaman bir veya daha fazla süreç tarafından temsil edilir. Web uygulamaları çeşitli süreç çalışma formlarını alır. Örneğin, Php süreçleri Apache'nin çocuk süreçleri olarak çalışır, istek üzerine talep hacmine tarafından ihtiyaç duyulduğunda başlatılır. Java süreçleri, karşıt yaklaşımı benimser; JVM, başlangıçta çok sayıda sistem kaynağı (CPU ve bellek) ayıran büyük bir uber işlemi sağlar ve eşzamanlılık iş parçacıkları aracılığıyla dahili olarak yönetilir. Her iki durumda, çalışan süreçler, uygulamanın geliştiricilerine yalnızca minimum düzeyde görünürdür. ![Ölçek, çalışan süreçler olarak ifade edilir, iş yükü çeşitliliği, süreç tipi olarak tanımlanır.](/images/process-types.png) **On iki faktör uygulamasında, süreçler birinci sınıf üyelerdir.** On iki faktör uygulamasındaki süreçler [arka planda çalışan servis programları için olan unix süreç modelinden](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/) güçlü ipuçları alır. Bu modeli kullanarak geliştirici uygulamasını her bir tip işe bir *süreç tipi* atayarak, ayrı iş yüklerini kontrol etmek için uygulamasını planlayabilir. Örneğin, HTTP istekleri web süreçleri tarafından işlenir ve uzun çalışan arkaplan görevleri, işçi süreçler tarafından işlenir. Bu, bireysel süreçlerin kendi dahili çoklu işlemelerini içermiyor değil, çalışma zamanı içindeki iş parçacıkları aracılığıyla VM, veya [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), [Node.js](http://nodejs.org/) gibi araçlarda bulunan asenkron model. Fakat bireysel VM yalnızca çok aşırı büyüyebilir (dikey ölçekte), bu yüzden uygulama aynı zamanda çoklu fiziksel makinelerde çalışan çoklu süreçleri içerebilmelidir. Bu süreç modeli, konu ölçeklendirme zamanına geldiğinde gerçekten çok başarılıdır. Paylaşımsız, yatay olarak bölümlenebilir bir doğası olan on iki faktör uygulama süreçleri, daha fazla eş zamanlılık eklemenin kolay ve güvenilir bir işlem olduğu anlamına gelir. Süreç tipleri dizisi ve her bir tipin süreçlerinin numarası *süreç oluşumu* olarak bilinir. On iki faktör uygulama süreçleri [asla arka planda çalışmamalı](http://dustin.github.com/2010/02/28/running-processes.html) ya da PID dosyalarını yazmamalıdır. Bunun yerine, [çıktı akışlarını](./logs) kontrol etmek, çökmüş süreçlere cevap vermek, kullanıcı başlatımlı tekrar başlatma ve kapatmaları işlemek için işletim sistemlerinin süreç yöneticisine( [systemd](https://www.freedesktop.org/wiki/Software/systemd/) gibi bulut platformunda yayınlanmış süreç yöneticisi veya geliştirme sürecinde [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)'e benzer araçlar ) dayanır. content/de/background.md0000644000175000056700000000265415226251677014032 0ustar0000000000000000Hintergrund ========== Die Mitwirkenden an diesem Dokument waren direkt beteiligt an der Entwicklung und dem Deployment von hunderten von Apps und wurden Zeugen bei der Entwicklung, beim Betrieb und der Skalierung von hunderttausenden von Apps im Rahmen unserer Arbeit an der [Heroku](http://www.heroku.com/)-Plattform. Dieses Dokument ist eine Synthese all unserer Erfahrungen und der Beobachtungen einer großen Bandbreite von Software-As-A-Service Apps. Es ist eine Bestimmung der idealen Praktiken bei der App-Entwicklung mit besonderem Augenmerk auf die Dynamik des organischen Wachstums einer App über die Zeit, die Dynamik der Zusammenarbeit zwischen den Entwicklern die an einer Codebase zusammenarbeiten und der [Vermeidung der Kosten von Software-Erosion](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). Unsere Motivation ist, das Bewusstsein zu schärfen für systembedingte Probleme in der aktuellen Applikationsentwicklung, ein gemeinsames Vokabular zur Diskussion dieser Probleme zu liefern und ein Lösungsportfolio zu diesen Problemen mit einer zugehörigen Terminologie anzubieten. Das Format ist angelehnt an Martin Fowlers Bücher *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* und *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/de/dependencies.md0000644000175000056700000000536615226251677014344 0ustar0000000000000000## II. Abhängigkeiten ### Abhängigkeiten explizit deklarieren und isolieren Die meisten Programmiersprachen bieten ein System an, um unterstützende Bibliotheken zu verbreiten, wie [CPAN](http://www.cpan.org/) für Perl oder [Rubygems](http://rubygems.org/) für Ruby. Aus einem Paketsystem stammende Bibliotheken können systemweit installiert werden (auch "Site Packages" genannt) oder in ein Verzeichnis der App beschränkt werden (genannt "vendoring" oder "bundling" - deutsch auch "mitliefern"). **Eine Zwölf-Faktor-App verlässt sich nie auf die Existenz von systemweiten Paketen.** Sie deklariert alle Abhängigkeiten vollständig und korrekt über eine *Abhängigkeitsdeklaration*. Weiter benutzt sie zur Laufzeit ein Werkzeug zur *Isolation von Abhängigkeiten* um sicherzustellen, dass keine impliziten Abhängigkeiten aus dem umgebenden System "hereinsickern". Die vollständige und explizite Spezifikation der Abhängigkeiten wird gleichermaßen in Produktion und Entwicklung angewandt. So bietet zum Beispiel [Bundler](https://bundler.io/) für Ruby das Format `Gemfile` zur Abhängigkeitsdeklaration und `bundle exec` zur Isolation von Abhängigkeiten. In Python gibt es für diese Schritte zwei unterschiedliche Werkzeuge -- [Pip](http://www.pip-installer.org/en/latest/) für die Deklaration und [Virtualenv](http://www.virtualenv.org/en/latest/) für die Isolation. Selbst C hat [Autoconf](http://www.gnu.org/s/autoconf/) zur Deklaration der Abhängigkeiten, und statisches Linken kann für Isolation sorgen. Unabhängig von den Werkzeugen müssen Abhängigkeitsdeklaration und Isolation immer zusammen benutzt werden -- eines alleine genügt für die zwölf Faktoren nicht. Ein Nutzen der expliziten Abhängigkeitsdeklaration ist das einfachere Aufsetzen der App für neue Entwickler. Neue Entwickler können die Codebase der App auf ihre Entwicklungsmaschine auschecken und brauchen dazu nur eine Sprach-Runtime und eine Abhängigkeitsverwaltung. Um die App zum Laufen zu bringen wird lediglich ein deterministisches *Build-Kommando* benötigt. So ist zum Beispiel das Build-Kommando für Ruby/Bundler `bundle install` und für Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) ist es `lein deps`. Zwölf-Faktor-Apps verlassen sich auch nicht auf die implizite Existenz irgendwelcher Systemwerkzeuge. Beispiele dafür sind Shell-Aufrufe von ImageMagick oder `curl`. Auch wenn diese Werkzeuge auf vielen und sogar den meisten Systemen vorhanden sind, gibt es keine Garantie, dass sie auf allen Systemen vorhanden sind, auf denen die App in Zukunft laufen wird, oder dass die Werkzeug-Version die in Zukunft auf einem System vorhanden sein wird, kompatibel ist. Wenn die App per Shell auf ein Systemwerkzeug zugreift, sollte die App das Werkzeug mitliefern. content/es/backing-services.md0000644000175000056700000000600715226251677015145 0ustar0000000000000000## IV. Backing services ### Tratar a los "backing services" como recursos conectables Un *backing service* es cualquier recurso que la aplicación puede consumir a través de la red como parte de su funcionamiento habitual. Entre otros ejemplos, podemos encontrar bases de datos (como [MySQL](http://dev.mysql.com/) o [CouchDB](http://couchdb.apache.org/)), los sistemas de mensajería y de colas (como [RabbitMQ](http://www.rabbitmq.com/) o [Beanstalkd](https://beanstalkd.github.io)), los servicios SMTP de email (como [Postfix](http://www.postfix.org/)), y los sistemas de cache (como [Memcached](http://memcached.org/)). Tradicionalmente, los "backing services" (como las bases de datos) han sido gestionadas por los mismos administradores de sistemas que despliegan la aplicacion en producción. Además de esos servicios gestionados localmente, las aplicaciones también pueden usar servicios proporcionados y gestionados por terceros, como por ejemplo los servicios SMTP ([Postmark](http://postmarkapp.com/)), los servicios de recopilación de métricas (como [New Relic](http://newrelic.com/) o [Loggly](http://www.loggly.com/)), los servicios de activos binarios (como [Amazon S3](http://aws.amazon.com/s3/)), e incluso servicios que se consumen accediendo a ellos mediante un API (como [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), o [Last.fm](http://www.last.fm/api)). **El código de una aplicación "twelve-factor" no hace distinciones entre servicios locales y de terceros.** Para la aplicación, ambos son recursos conectados, accedidos mediante una URL u otro localizador o credencial almacenado en la [config](./config). Un [despliegue](./codebase) de una aplicación "twelve-factor" debería ser capaz de reemplazar una base de datos local MySQL por una gestionada por un tercero (como [Amazon RDS](http://aws.amazon.com/rds/)) sin ningún cambio en el código de la aplicación. Igualmente, un servidor SMTP local se podría cambiar por un servicio de terceros (como Postmark) sin modificaciones en el código. En ambos casos, solo el manejador del recurso necesita cambiar en la configuración. Cada "backing service" distinto es un *recurso*. Por ejemplo, una base de datos MySQL es un recurso; dos bases de datos MySQL (usadas para "sharding" en la capa de aplicación) les convierte en dos recursos distintos. Una aplicación "twelve factor" trata esas bases de datos como *recursos conectados*, lo que demuestra su bajo acoplamiento al despliegue al que se unen. Un despliegue en producción conectado a cuatro backing services. Los recursos se pueden conectar y desconectar a voluntad. Por ejemplo, si la base de datos funciona mal debido a un problema en el hardware, el administrador de la aplicación puede cambiar a un nuevo servidor de bases de datos que haya sido restaurado de un backup reciente. La base de datos actual de producción se puede desconectar, y conectar una nueva base de datos sin tener que cambiar nada en el código. content/it/build-release-run.md0000644000175000056700000000520315226251677015247 0ustar0000000000000000## V. Build, release, esecuzione ### Separare in modo netto lo stadio di build dall'esecuzione Una [codebase](./codebase) viene "trasformata" in deployment attraverso tre fasi: * la fase di *build*, che converte il codice del repo in una build "eseguibile". Usando una certa versione del codice, a una specifica commit, nella fase di build vengono compilati i binari con gli asset appropriati includendo anche le eventuali dipendenze; * la fase di *release* prende la build prodotta nella fase precedente e la combina con l'attuale insieme di impostazioni di configurazione del deployment specifico. La *release* risultante contiene sia la build che le impostazioni; * la fase di *esecuzione* (conosciuta anche come "runtime") vede l'applicazione in esecuzione nell'ambiente di destinazione, attraverso l'avvio di processi della release scelta; ![Il codice diventa build, che combinata con le impostazioni diventa release.](/images/release.png) **Un'app twelve-factor definisce una separazione netta tra build, release ed esecuzione.** Per esempio, è impossibile effettuare dei cambiamenti del codice a runtime, dato che non c'è modo di propagare queste modifiche all'"indietro", verso la fase di build. I tool di deployment offrono tipicamente dei tool di gestione delle release, in particolare alcuni dedicati a un rollback verso una release precedente. Per esempio, [Capistrano](https://github.com/capistrano/capistrano/wiki) memorizza le varie release in una sotto-directory chiamata `releases`, in cui la release attuale non è che un symlink verso la directory della release attuale. Il comando di rollback permette di tornare indietro a una certa release velocemente. Ogni release dovrebbe inoltre possedere un ID univoco di rilascio, come per esempio un timestamp (es. `2011-04-06-20:32:17`) o un numero incrementale (es. `v100`). In un certo senso, la creazione di una release è una procedura "a senso unico" e una certa release non può essere modificata dopo la sua creazione. Qualsiasi cambiamento deve quindi prevedere una nuova release. Una fase di build è sempre avviata da uno sviluppatore, non appena il codice viene modificato. Al contrario, l'esecuzione può essere anche gestita in modo automatico (si pensi al riavvio del server oppure a un crash con successivo riavvio del processo). A ogni modo, una volta in esecuzione, la regola aurea è di evitare il più possibile (se non del tutto) modifiche che potrebbero rompere qualche equilibrio. Magari nel bel mezzo della notte, quando non c'è nessuno disponibile. La fase di build può essere sicuramente più "faticosa", comunque, visto che possono verificarsi degli errori da risolvere prima di proseguire. content/ru/intro.md0000644000175000056700000000416515226251677013103 0ustar0000000000000000Введение ============ В наши дни программное обеспечение обычно распространяется в виде сервисов, называемых *веб-приложения* (web apps) или *software-as-a-service* (SaaS). Приложение двенадцати факторов — это методология для создания SaaS-приложений, которые: * Используют **декларативный** формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключённых к проекту; * Имеют **соглашение** с операционной системой, предполагающее **максимальную переносимость** между средами выполнения; * Подходят для **развёртывания** на современных **облачных платформах**, устраняя необходимость в серверах и системном администрировании; * **Сводят к минимуму расхождения** между средой разработки и средой выполнения, что позволяет использовать **непрерывное развёртывание** (continuous deployment) для максимальной гибкости; * И могут **масштабироваться** без существенных изменений в инструментах, архитектуре и практике разработки. Методология двенадцати факторов может быть применена для приложений, написанных на любом языке программирования и использующих любые комбинации сторонних служб (backing services) (базы данных, очереди сообщений, кэш-памяти, и т.д.). locales/pt_br.yml0000644000175000056700000000034715226251677012577 0ustar0000000000000000pt_br: # Name of language listed in locales menu language: Brazilian Portuguese (pt_br) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "(traduzido)" content/ko/disposability.md0000644000175000056700000000664715226251677014621 0ustar0000000000000000## IX. 폐기 가능(Disposability) ### 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화 **Twelve-Factor App의 [프로세스](./processes)는 *간단하게 폐기 가능*합니다. 즉, 프로세스는 바로 시작하거나 종료될 수 있습니다.** 이러한 속성은 신축성 있는 확장과 [코드](./codebase)나 [설정](./config)의 변화를 빠르게 배포하는 것을 쉽게 하며, production 배포를 안정성 있게 해줍니다. 프로세스는 **시작 시간을 최소화**하도록 노력해야합니다. 이상적으로, 프로세스는 실행 커맨드가 실행된 뒤 몇 초만에 요청이나 작업을 받을 수 있도록 준비 됩니다. 짧은 실행 시간은 [릴리즈](./build-release-run) 작업과 확장(scale up)이 더 민첩하게 이루어질 수 있게 합니다. 또한 프로세스 매니저가 필요에 따라 쉽게 프로세스를 새로운 머신으로 프로세스를 옮길 수 있기 때문에 안정성도 높아집니다. 프로세스는 프로세스 매니저로부터 **[SIGTERM](http://en.wikipedia.org/wiki/SIGTERM) 신호를 받았을 때 그레이스풀 셧다운(graceful shutdown)을 합니다.** 웹프로세스의 그레이스풀 셧다운 과정에서는 서비스 포트의 수신을 중지하고(그럼으로써 새로운 요청을 거절함), 현재 처리 중인 요청이 끝나길 기다린 뒤에 프로세스가 종료 되게 됩니다. 이 모델은 암묵적으로 HTTP 요청이 짧다는 가정(기껏해야 몇 초)을 깔고 있습니다. long polling의 경우에는 클라이언트가 연결이 끊긴 시점에 바로 다시 연결을 시도해야 합니다. worker 프로세스의 경우, 그레이스풀 셧다운은 현재 처리중인 작업을 작업 큐로 되돌리는 방법으로 구현됩니다. 예를 들어, [RabbitMQ](http://www.rabbitmq.com/)에서는 worker는 [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack)을 메시지큐로 보낼 수 있습니다. [Beanstalkd](https://beanstalkd.github.io)에서는 woker와의 연결이 끊기면 때 자동으로 작업을 큐로 되돌립니다. [Delayed Job](https://github.com/collectiveidea/delayed_job#readme)와 같은 Lock-based 시스템들은 작업 레코드에 걸어놨던 lock을 확실하게 풀어놓을 필요가 있습니다. 이 모델은 암묵적으로 모든 작업은 [재입력 가능(reentrant)](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29)하다고 가정합니다. 이는 보통, 결과를 트랜잭션으로 감싸거나 요청을 [멱등(idempotent)](http://en.wikipedia.org/wiki/Idempotence)하게 함으로써 구현될 수 있습니다. 프로세스는 하드웨어 에러에 의한 **갑작스러운 죽음에도 견고해야합니다.** 이러한 사태는 `SIGTERM`에 의한 그레이스풀 셧다운에 비하면 드문 일이지만, 그럼에도 발생할 수 있습니다. 이런 일에 대한 대책으로 Beanstalkd와 같은 견고한 큐잉 백엔드를 사용하는 것을 권장합니다. 이러한 백엔드는 클라이언트가 접속이 끊기거나, 타임 아웃이 발생했을 때, 작업을 큐로 되돌립니다. Twelve-Factor App은 예기치 못한, 우아하지 않은 종료도 처리할 수 있도록 설계됩니다. [Crash-only design](http://lwn.net/Articles/191059/)에서는 [논리적인 결론](http://docs.couchdb.org/en/latest/intro/overview.html)으로 이러한 컨셉을 가져왔습니다. content/pl/processes.md0000644000175000056700000000533515226251677013743 0ustar0000000000000000## VI. Procesy ### Uruchamiaj aplikację jako jeden lub więcej bezstanowych procesów Aplikacja jest uruchamiana w środowisku wykonawczym w postaci jednego lub kilku *procesów*. W najprostszym przypadku kod aplikacji jest samodzielnym skryptem, środowiskiem wykonawczym jest laptop developera z wsparciem dla języka programowania, a proces jest uruchamiany za pomocą linii komend (na przykład `python my_script.py`). Innym razem wdrożenie produkcyjne mocno rozwiniętej aplikacji może wymagać wiele [różnych rodzajów procesów](./concurrency). **Wg zasad 12factor, procesy są bezstanowe i [nie-współdzielące](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Jakiekolwiek dane wymagające zapisu musza być zmagazynowane w "trwałej" [usłudze wspierającej](./backing-services), najczęściej będącą bazą danych. Przestrzeń adresowa lub system plików procesu mogą być używane jako tymczasowy cache dla pojedynczych operacji. Przykładem jest pobieranie dużych plików, działanie na nich, a następnie zapisywanie wyników operacji w bazie danych. Aplikacja dwunastu aspektów nigdy nie zakłada, że jakiś fragment informacji zapisany w pamięci lub dysku będzie dostępny w przyszłości podczas jakiegokolwiek zapytania -- wraz z wieloma aktywnymi procesami rośnie szansa, że przyszłe zapytanie zostanie obsłużone przez zupełnie inny proces. Nawet w przypadku pojedynczego procesu, restart (spowodowany przez deployment kodu, zmianę konfiguracji lub relokacja procesu do innej fizycznej lokalizacji wykonana przez środowisko wykonawcze) zazwyczaj usunie wszystkie dane z lokalnego stanu aplikacji (system plików, pamięć podręczna). Narzędzie do pakowania plików, z których korzysta aplikacja (takie jak [Jammit](http://documentcloud.github.com/jammit/) lub [django-compressor](http://django-compressor.readthedocs.org/)) używają systemu plików jako cache dla skompilowanych zasobów. Wg 12factor taka kompilacja powinna mieć miejsce podczas [etapu budowy aplikacji](./build-release-run), jak to się dzieje np. w [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html). Niektóre systemy sieciowe polegają na tzw. ["sticky sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- oznacza to, że sesja użytkownika jest zapisywana tymczasowo w pamięci procesu aplikacji, zakładając, że kolejne zapytania dotyczące użytkownika będą kierowane do tego samego procesu. "Sticky sessions" są złamaniem zasad aplikacji 12factor i nigdy nie powinny być używane jako źródło informacji. Dane sesji nadają się bardziej do zapisu w magazynie oferującym wygasanie danych w czasie, jak np. [Memcached](http://memcached.org/) czy [Redis](http://redis.io/). content/tr/intro.md0000644000175000056700000000167515226251677013105 0ustar0000000000000000Giriş ========== Modern çağda yazılımlar yaygın olarak servis olarak sunulur;*web uygulamaları* ya da *yazılım hizmetleri*. On iki faktörlü uygulama, aşağıdaki gibi bir yazılım hizmeti oluşturmak için bir yöntemdir: * Projeye katılan yeni geliştiriciler için zaman ve maliyeti en aza indirmek için ayar otomasyonu için **bildirim** biçimleri kullanılır; * Çalışma ortamları arasında maksimum taşınabilirlik sunan temel işletim sistemi ile **şifresiz sözleşmesi** vardır * Sunucu ve sistem yönetimine olan ihtiyacı ortadan kaldıran modern **bulut platformlarına kurulum** için uygundur; * İşlem, mimari veya geliştirme uygulamalarında önemli değişiklikler olmaksızın **ölçek büyültülebilir**. On iki faktör uygulaması herhangi bir programlama dili ile yazılmış uygulamalara uygulanabilir ve destek servislerinin herhangi bir kombinasyonu kullanılabilir (Veritabanı, kuyruk, önbellek vb.). .ruby-version0000644000175000056700000000000615226251677011761 0ustar00000000000000003.1.2 content/pl/dev-prod-parity.md0000644000175000056700000001230615226251677014757 0ustar0000000000000000## X. Jednolitość środowisk ### Utrzymuj środowisko developerskie, stagingowe i produkcyjne tak podobne jak tylko możliwe Z doświadczenia wiadomo, że od zawsze istniały różnice pomiędzy środowiskiem developerskim (developer pracujący nad swoją lokalną wersją [kodu](./codebase) aplikacji) a produkcyjnym (działająca aplikacja dostępna dla użytkowników. Ze względu na ich charakter, możemy wymienić trzy rodzaje różnic: * **Różnica czasowa:** Developer może pracować nad kodem przez dni, tygodnie, miesiące zanim ostatecznie pojawi się on w wersji produkcyjnej. * **Różnica odpowiedzialności**: Developer tworzy kod aplikacji, natomiast kto inny wdraża go do na produkcję. * **Różnica narzędzi**: Developer może używać narzędzi takich jak Nginx, SQLite i systemu OS X, natomiast wersja produkcyjna będzie opierać się na Apache, MySQL i systemie Linux. **Aplikacja 12factor jest zaprojektowana tak by można ją było [bez przerwy wdrażać na produkcję](http://avc.com/2011/02/continuous-deployment/) minimalizując różnice pomiędzy środowiskami.** Mając na uwadze powyższe różnice, można sobie z nimi radzić na różne sposoby: * Zmniejsz czas deploymentu: czas wdrożenia kodu napisanego przez developera powinien być mierzony w godzinach, a nawet w minutach. * Przenieś odpowiedzialność: developer piszący kod powinien być zaangażowany we wdrożenia aplikacji na produkcję. * Stosuj ten sam zestaw narzędzi: utrzymuj wszystkie środowiska w których działa aplikacja tak podobne jak to możliwe. Podsumowując w formie tabeli:
Tradycyjna aplikacja Aplikacja 12factor
Czas pomiędzy wdrożeniami Tygodnie Godziny
Tworzenie kodu vs wdrażanie kodu Różne osoby Te same osoby
Środowisko developerskie vs produkcyjne Mocno różniące się Jak najbardziej zbliżone
Zachowanie podobieństw między wdrożeniami jest ważne w przypadku [usług wspierających](./backing-services) takich jak baza danych aplikacji, system kolejkowania czy też cache. Wiele języków oferuje biblioteki, które upraszczają korzystanie z usług wspierających w tym *adaptery* do usług różnego typu. Kilka przykładów w tabeli poniżej:
Typ Język Biblioteka Adaptery
Baza danych Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Kolejka Python/Django Celery RabbitMQ, Beanstalkd, Redis
Cache Ruby/Rails ActiveSupport::Cache Pamięć, system plików, Memcached
Czasami zdarza się, że developerzy w swoim lokalnym środowisku wolą korzystać z "lżejszych" wersji różnych usług, na produkcji natomiast używając bardziej zaawansowanych narzędzi. Przykładem takiej sytuacji jest używanie lokalnie SQLite, a PostgreSQL na produkcji. Podobnie wygląda też użycie na środowisku developerskim do cachowania pamięci, zamiast Memcached znajdującego się na produkcji. **Developer postępujący zgodnie zasadami 12factor opiera się pokusie używania usług różniących się pomiędzy środowiskami**, nawet wtedy, gdy adaptery teoretycznie ukrywają różnice w implementacji pod warstwą abstrakcji. Z powodu różnic pomiędzy usługami wspierającymi mogą pojawić się niezgodności, powodując, że kod, który działał i był testowany lokalnie lub na stagingu, przestanie funkcjonować na produkcji. Pojawianie się tego typu błędów negatywnie wpływa na proces ciągłego wdrażania aplikacji. Czas stracony na wykrywaniu takich błędów i konsekwentnych awariach podczas wdrażania aplikacji może sporo kosztować, zwłaszcza gdy podobne problemy będą się z czasem gromadzić. Lekkie wersje usług w obecnych czasach nie są już tak atrakcyjne jak kiedyś. Nowoczesne usługi takie jak Memcached, PostgreSQL oraz RabbitMQ nie są trudne do instalacji w lokalnym środowisku, dzięki narzędziom jak [Homebrew](http://mxcl.github.com/homebrew/) i [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Innym rozwiązaniem są narzędzia do deklaratywnego [provisioningu](https://en.wikipedia.org/wiki/Provisioning) takie jak [Chef](http://www.opscode.com/chef/) czy [Puppet](http://docs.puppetlabs.com/) połączone z lekkimi środowiskami wirtualnymi jak np. [Vagrant](http://vagrantup.com/). Pozwala ono developerom na uruchamianie lokalnych środowisk, które są bardzo zbliżone do produkcyjnych. Koszt instalacji i używania takich rozwiązań jest stosunkowo niski, biorąc pod uwagę korzyści płynące z utrzymywania jednolitych środowisk i procesu ciągłego wdrażania aplikacji. Adaptery dla różnych usług wspierających są wciąż użyteczne, gdyż dzięki nim zmiana usługi jest relatywnie łatwa. Należy jednak pamiętać, że wszystkie wdrożenia aplikacji (środowiska developerskie, stagingowe, produkcyjne) powinny używać tych samych typów i wersji usług wspierających. content/pt_br/config.md0000644000175000056700000000705615226251677013677 0ustar0000000000000000## III. Configurações ### Armazene as configurações no ambiente A *configuração* de uma aplicação é tudo o que é provável variar entre [deploys](./codebase) (homologação, produção, ambientes de desenvolvimento, etc). Isto inclui: * Recursos para a base de dados, Memcached, e outros [serviços de apoio](./backing-services) * Credenciais para serviços externos como Amazon S3 ou Twitter * Valores por deploy como o nome canônico do host para o deploy Aplicações às vezes armazenam as configurações no código como constantes. Isto é uma violação da doze-fatores, a qual exige uma **estrita separação entre configuração e código**. Configuração varia substancialmente entre deploys, código não. A prova de fogo para saber se uma aplicação tem todas as configurações corretamente consignadas fora do código é saber se a base de código poderia ter seu código aberto ao público a qualquer momento, sem comprometer as credenciais. Note que esta definição de "configuração" **não** inclui configuração interna da aplicação, como `config/routes.rb` em Rails, ou como [módulos de códigos são conectados](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) em [Spring](http://spring.io/). Este tipo de configuração não varia entre deploys, e por isso é melhor que seja feito no código. Outra abordagem para configuração é o uso de arquivos de configuração que não são versionados no controle de versão, como `config/database.yml` em Rails. Isto é uma grande melhoria sobre o uso de constantes que são versionadas no repositório do código, mas ainda tem pontos fracos: é fácil de colocar por engano um arquivo de configuração no repositório; há uma tendência para que os arquivos de configuração sejam espelhados em diferentes lugares e diferentes formatos, tornando-se difícil de ver e gerenciar todas as configurações em um só lugar. Além disso estes formatos tendem a ser específicos da linguagem ou framework. **A aplicação doze-fatores armazena configuração em *variáveis de ambiente*** (muitas vezes abreviadas para *env vars* ou *env*). Env vars são fáceis de mudar entre deploys sem alterar qualquer código; ao contrário de arquivos de configuração, há pouca chance de serem colocados acidentalmente no repositório do código; e ao contrário dos arquivos de configuração personalizados, ou outros mecanismos de configuração como Propriedades do Sistema Java, eles são por padrão agnósticos a linguagem e ao SO. Outro aspecto do gerenciamento de configuração é o agrupamento. Às vezes, as aplicações incluem a configuração em grupos nomeados (muitas vezes chamados de ambientes) que remetem a deploys específicos, tais como os ambientes `development`, `test`, e `production` em Rails. Este método não escala de forma limpa: quanto mais deploys da aplicação são criados, novos nomes de ambiente são necessários, tais como `staging` ou `qa`. A medida que o projeto cresce ainda mais, desenvolvedores podem adicionar seus próprios ambientes especiais como `joes-staging`, resultando em uma explosão combinatória de configurações que torna o gerenciamento de deploys da aplicação muito frágil. Em uma aplicação doze-fatores, env vars são controles granulares, cada um totalmente ortogonal às outras env vars. Elas nunca são agrupadas como "environments", mas em vez disso são gerenciadas independentemente para cada deploy. Este é um modelo que escala sem problemas à medida que o app naturalmente se expande em muitos deploys durante seu ciclo de vida. content/pt_br/toc.md0000644000175000056700000000232415226251677013210 0ustar0000000000000000Os Doze Fatores =============== ## [I. Base de Código](./codebase) ### Uma base de código com rastreamento utilizando controle de revisão, muitos deploys ## [II. Dependências](./dependencies) ### Declare e isole as dependências ## [III. Configurações](./config) ### Armazene as configurações no ambiente ## [IV. Serviços de Apoio](./backing-services) ### Trate os serviços de apoio, como recursos ligados ## [V. Build, release, run](./build-release-run) ### Separe estritamente os builds e execute em estágios ## [VI. Processos](./processes) ### Execute a aplicação como um ou mais processos que não armazenam estado ## [VII. Vínculo de porta](./port-binding) ### Exporte serviços por ligação de porta ## [VIII. Concorrência](./concurrency) ### Dimensione por um modelo de processo ## [IX. Descartabilidade](./disposability) ### Maximizar a robustez com inicialização e desligamento rápido ## [X. Dev/prod semelhantes](./dev-prod-parity) ### Mantenha o desenvolvimento, teste, produção o mais semelhante possível ## [XI. Logs](./logs) ### Trate logs como fluxo de eventos ## [XII. Processos de Admin](./admin-processes) ### Executar tarefas de administração/gerenciamento como processos pontuais content/de/logs.md0000644000175000056700000000455015226251677012654 0ustar0000000000000000## XI. Logs ### Logs als Strom von Ereignissen behandeln *Logs* machen das Verhalten einer laufenden App sichtbar. In Server-basierten Umgebungen werden sie üblicherweise in eine Datei auf der Platte geschrieben (eine Logdatei) - das ist aber nur ein Ausgabeformat. Logs sind der [Stream](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) von aggregierten, nach Zeit sortierten Ereignissen und zusammengefasst aus den Output Streams aller laufenden Prozesse und unterstützenden Dienste. Logs in ihrer rohen Form sind üblicherweise ein Textformat mit einem Ereignis pro Zeile (obwohl Backtraces von Exceptions über mehrere Zeilen gehen können) **Eine Zwölf-Faktor-App kümmert sich nie um das Routing oder die Speicherung ihres Output Streams.** Sie sollte nicht versuchen, in Logdateien zu schreiben oder diese zu verwalten. Statt dessen schreibt jeder laufende Prozess seinen Stream von Ereignissen ungepuffert auf `stdout`. Bei einem lokalen Deployment sichtet ein Entwickler diesen Stream im Vordergrund seines Terminals um das Verhalten der App zu beobachten. Auf Staging- oder Produktionsdeploys werden die Streams aller Prozesse von der Laufzeitumgebung erfasst, mit allen anderen Streams der App zusammengefasst und zu einem oder mehreren Zielen geleitet, zur Ansicht oder langzeitigen Archivierung. Diese Archivierungsziele sind für die App weder sichtbar noch konfigurierbar - sie werden vollständig von der Laufzeitumgebung aus verwaltet. Open-Source Log Router (wie [Logplex](https://github.com/heroku/logplex) und [Fluentd](https://github.com/fluent/fluentd)) stehen dafür zur Verfügung. Der Stream von Ereignissen für eine App kann in eine Datei geleitet werden oder mit einem Echtzeit-Tail in einem Terminal beobachtet werden. Sehr bedeutsam ist es, das der Stream in ein Log-Indexierungs- und Analyse-System wie [Splunk](http://www.splunk.com/) oder in ein allgemein verwendbares Data-Warehouse-System wie [Hadoop/Hive](http://hive.apache.org/) gelenkt werden kann. Mit diesem System kann das Verhalten einer App leistungsfähig und flexibel beobachtet werden. Dies schließt ein: * Bestimmte Ereignisse in der Vergangenheit zu finden * Umfangreiche graphische Darstellungen (wie Requests pro Minute) * Aktives Alarmieren aufgrund benutzerdefinierter Heuristiken (wie ein Alarm wenn die Anzahl von Fehlern pro Minute eine gewisse Grenze überschreitet) content/en/dev-prod-parity.md0000644000175000056700000001065715226251677014755 0ustar0000000000000000## X. Dev/prod parity ### Keep development, staging, and production as similar as possible Historically, there have been substantial gaps between development (a developer making live edits to a local [deploy](./codebase) of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas: * **The time gap**: A developer may work on code that takes days, weeks, or even months to go into production. * **The personnel gap**: Developers write code, ops engineers deploy it. * **The tools gap**: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux. **The twelve-factor app is designed for [continuous deployment](http://avc.com/2011/02/continuous-deployment/) by keeping the gap between development and production small.** Looking at the three gaps described above: * Make the time gap small: a developer may write code and have it deployed hours or even just minutes later. * Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production. * Make the tools gap small: keep development and production as similar as possible. Summarizing the above into a table:
Traditional app Twelve-factor app
Time between deploys Weeks Hours
Code authors vs code deployers Different people Same people
Dev vs production environments Divergent As similar as possible
[Backing services](./backing-services), such as the app's database, queueing system, or cache, is one area where dev/prod parity is important. Many languages offer libraries which simplify access to the backing service, including *adapters* to different types of services. Some examples are in the table below.
Type Language Library Adapters
Database Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Queue Python/Django Celery RabbitMQ, Beanstalkd, Redis
Cache Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached
Developers sometimes find great appeal in using a lightweight backing service in their local environments, while a more serious and robust backing service will be used in production. For example, using SQLite locally and PostgreSQL in production; or local process memory for caching in development and Memcached in production. **The twelve-factor developer resists the urge to use different backing services between development and production**, even when adapters theoretically abstract away any differences in backing services. Differences between backing services mean that tiny incompatibilities crop up, causing code that worked and passed tests in development or staging to fail in production. These types of errors create friction that disincentivizes continuous deployment. The cost of this friction and the subsequent dampening of continuous deployment is extremely high when considered in aggregate over the lifetime of an application. Lightweight local services are less compelling than they once were. Modern backing services such as Memcached, PostgreSQL, and RabbitMQ are not difficult to install and run thanks to modern packaging systems, such as [Homebrew](http://mxcl.github.com/homebrew/) and [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Alternatively, declarative provisioning tools such as [Chef](http://www.opscode.com/chef/) and [Puppet](http://docs.puppetlabs.com/) combined with light-weight virtual environments such as [Docker](https://www.docker.com/) and [Vagrant](http://vagrantup.com/) allow developers to run local environments which closely approximate production environments. The cost of installing and using these systems is low compared to the benefit of dev/prod parity and continuous deployment. Adapters to different backing services are still useful, because they make porting to new backing services relatively painless. But all deploys of the app (developer environments, staging, production) should be using the same type and version of each of the backing services. content/es/port-binding.md0000644000175000056700000000443115226251677014321 0ustar0000000000000000## VII. Asignación de puertos ### Publicar servicios mediante asignación de puertos Las aplicaciones web se ejecutan a menudo mediante contenedores web. Por ejemplo, las aplicaciones de PHP se suelen ejecutar como módulos del [HTTPD de Apache](http://httpd.apache.org/), y las aplicaciones Java en [Tomcat](http://tomcat.apache.org/). **Las aplicaciones "twelve factor" son completamente auto-contenidas** y no dependen de un servidor web en ejecución para crear un servicio web público. Una aplicación web **usa HTTP como un servicio al que se le asigna un puerto**, y escucha las peticiones que recibe por dicho puerto. En los entornos de desarrollo, los desarrolladores usan una URL del servicio (por ejemplo `http://localhost:5000/`), para acceder al servicio que ofrece la aplicación. En la fase de despliegue, existe una capa de enrutamiento que se encarga de que las peticiones que llegan a una dirección pública se redirijan hacia el proceso web que tiene asignado su puerto correspondiente. Esto se implementa, normalmente, usando una [declaración de dependencias](./dependencies) donde se incluyen librerías de las aplicaciones web, como [Tornado](http://www.tornadoweb.org/) para Python, [Thin](http://code.macournoyer.com/thin/) para Ruby, o [Jetty](http://www.eclipse.org/jetty/) para Java y otros lenguajes basados en la Máquina Virtual de Java (JVM). Esto ocurre totalmente en el *entorno del usuario*, es decir, dentro del código de la aplicación. El contrato con el entorno de ejecución obliga al puerto a servir las peticiones. HTTP no es el único servicio que usa asignación de puertos. La verdad, es que cualquier servicio puede ejecutarse mediante un proceso al que se le asigna un puerto y queda a la espera de peticiones. Entre otros ejemplos podemos encontrar [ejabberd](http://www.ejabberd.im/) (que usa [XMPP](http://xmpp.org/)), y [Redis](http://redis.io/) (que usa [el protocolo Redis](http://redis.io/topics/protocol)). También es cierto que la aproximación de asignación de puertos ofrece la posibilidad de que una aplicación pueda llegar a ser un ["backing service"](./backing-services) para otra aplicación, usando la URL de la aplicación correspondiente como un recurso declarado en la [configuración](./config) de la aplicación que consume este "backing service". content/it/toc.md0000644000175000056700000000231115226251677012512 0ustar0000000000000000I "Dodici Fattori" ================== ## [I. Codebase](./codebase) ### Una sola codebase sotto controllo di versione, tanti deployment ## [II. Dipendenze](./dependencies) ### Dipendenze dichiarate e isolate ## [III. Configurazione](./config) ### Memorizza le informazioni di configurazione nell'ambiente ## [IV. Backing Service](./backing-services) ### Tratta i backing service come "risorse" ## [V. Build, release, esecuzione](./build-release-run) ### Separare in modo netto lo stadio di build dall'esecuzione ## [VI. Processi](./processes) ### Esegui l'applicazione come uno o più processi stateless ## [VII. Binding delle Porte](./port-binding) ### Esporta i servizi tramite binding delle porte ## [VIII. Concorrenza](./concurrency) ### Scalare attraverso il process model ## [IX. Rilasciabilità](./disposability) ### Massimizzare la robustezza con avvii veloci e chiusure non brusche ## [X. Parità tra Sviluppo e Produzione](./dev-prod-parity) ### Mantieni lo sviluppo, staging e produzione simili il più possibile ## [XI. Log](./logs) ### Tratta i log come stream di eventi ## [XII. Processi di Amministrazione](./admin-processes) ### Esegui i task di amministrazione/management come processi una tantum content/th/codebase.md0000644000175000056700000000656315226251677013506 0ustar0000000000000000## I. Codebase ### มีเพียง codebase เดียวที่ติดตามด้วย version control, มีหลาย deploy Twelve-factor app สามารถติดตามได้เสมอด้วย version control เช่น [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), หรือ [Subversion](http://subversion.apache.org/) สำเนาของฐานข้อมูลติดตาม version เรียกว่า *code repository* หรือเรียกสั้นๆว่า *code repo* หรือเรียกเพียงแค่ *repo* *codebase* เป็น repo เดียวใดๆ (ในระบบ version control ที่มีศูนย์กลางอย่างเช่น Subversion) หรือเป็นเซตของ repo ซึ่งแบ่งปัน root commit (ในระบบ version control ที่ไม่มีศูนย์กลางอย่างเช่น Git) ![One codebase maps to many deploys](/images/codebase-deploys.png) มีความสัมพันธ์แบบ หนี่ง-ต่อ-หนึ่ง เสมอ ระหว่าง codebase และ app: * ถ้ามีหลาย codebase, จะไม่เป็น app -- จะเป็นระบบกระจาย (distributed system) แต่ละคอมโพแนนท์ในระบบกระจายเป็น app, และแต่ล่ะคอมโพแนนท์จะปฏิบัติตาม twelve-factor * ถ้ามีหลาย app ที่ใช้งาน code เดียวกันจะเป็นการละเมิด twelve-factor วิธีแก้ปัญหาในที่นี้คือเอา code ที่ใช้ร่วมกันทำเป็น libraries ซึ่งสามารถเข้ากับ factor [dependency manager](./dependencies) มีเพียงหนึ่ง codebase ต่อ app แต่มีหลาย deploy หรือการนำไปใช้งานของ app, หนึ่ง *deploy* จะรัน instance ของ app นี่เป็น production site และมีหนึ่งหรือมากว่า staging site เพิ่มเติม, developer ทุกคนจะมีสำเนาเดียวของ app ที่ทำงานอยู่บนสิ่งแวดล้อมพัฒนาในเครื่องของตนเอง ซึ่งจัดได้ว่าเป็น deploy ด้วยเช่นกัน Codebase จะเหมือนกันตลอดทั้ง deploy ทั้งหมด แม้ว่า version จะแตกต่างกันอาจจะทำงานในแต่ล่ะ deploy ตัวอย่างเช่น developer มีบาง commit ที่ยังไม่ได้ deploy ไปยัง staging ซึ่ง staging จะมีบาง commit ที่ยังไม่ได้ deploy ไปยัง production แต่ทั้งหมดจะใช้ codebase เดียวกัน ดังนั้นจะต้องทำให้ระบุตัวตนได้ว่าเป็น deploy ที่แตกต่างกันของ app เดียวกัน views/factor.erb0000644000175000056700000000051415226251677012425 0ustar0000000000000000
<%= render_markdown(@factor) %>
content/fr/dev-prod-parity.md0000644000175000056700000001263215226251677014755 0ustar0000000000000000## X. Parité dev/prod ### Gardez le développement, la validation et la production aussi proches que possible Historiquement, il y a eu un fossé conséquent entre le développement (un développeur qui fait des modifications sur un [déploiement](./codebase) local de l'application) et la production (un déploiement de l'application accessible aux utilisateurs finaux). Ce fossé se manifeste de trois manières : * **Le fossé temporel** : un développeur peut travailler sur du code qui peut prendre des jours, des semaines ou des mois avant d'aller en production * **Le fossé des personnes** : les développeurs écrivent le code, et d'autres personnes le déploient. * **Le fossé des outils** : les développeurs peuvent utiliser une pile comme Nginx, SQLite, et OS X, alors que le déploiement de production utilise Apache, MySQL, et Linux. **Les applications 12 facteurs sont conçues pour le [déploiement continu (en)](http://avc.com/2011/02/continuous-deployment/) en gardant un fossé étroit entre le développement et la production.** Si l'on regarde les trois fossés décrits plus haut : * Réduire le fossé temporel : un développeur peut écrire du code et le déployer quelques heures ou même juste quelques minutes plus tard. * Réduire le fossé des personnes : les personnes qui écrivent le code sont impliquées dans son déploiement et pour surveiller son comportement en production. * Réduire le fossé des outils : réduire, autant que possible, les différences entre le développement et la production. Si l'on résume cela en un tableau :
Application traditionnelle Application 12 facteurs
Temps entre les déploiements Semaines Heures
Auteurs du code et ceux qui le déploient Des personnes différentes Les mêmes personnes
L'environnement de développement et celui de production Divergents Aussi similaires que possible
[Les services externes](./backing-services), tels que la base de données, la file de messages, ou le cache sont des éléments importants de la parité développement/production. La plupart des langages fournissent des bibliothèques qui simplifient l'accès à ces services externes, en fournissant des adaptateurs pour différents types de services. Voici quelques exemples dans le tableau ci-dessous.
Type Langage Librairie Adaptateurs
Base de données Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
File de messages Python/Django Celery RabbitMQ, Beanstalkd, Redis
Cache Ruby/Rails ActiveSupport::Cache Mémoire, système de fichiers, Memcached
Les développeurs trouvent parfois agréable d'utiliser des services externes légers dans leur environnement local, alors qu'un service externe plus sérieux et robuste est utilisé en production. Par exemple, utiliser SQLite en local, et PostgreSQL en production; ou bien, durant le développement, mettre les données en cache dans la mémoire des processus locaux, et utiliser Memcached en production. **Les développeurs des applications 12 facteurs résistent au besoin d'utiliser des services externes différents entre le développement local et la production**, même lorsque les adaptateurs permettent d'abstraire en théorie beaucoup de différences entre les services externes. Les différences entre les services externes signifient que de petites incompatibilités surviennent, ce qui va faire que du code qui fonctionnait et qui passait les tests durant le développement ou la validation ne fonctionnera pas en production. Ce type d'erreurs crée de la friction en défaveur du déploiement continu. Le coût de cette friction et son impact négatif sur le déploiement continu est extrêmement élevé lorsqu'il est cumulé sur toute la vie de l'application. Les services locaux légers sont moins attirants aujourd'hui qu'ils ne l'étaient autrefois. Les services externes modernes tels que Memcached, PostgreSQL, et RabbitMQ ne sont pas difficiles à installer et à faire fonctionner grâce aux systèmes de paquets modernes comme [Homebrew](http://mxcl.github.com/homebrew/) et [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Autre possibilité, des outils de provisionnement comme [Chef](http://www.opscode.com/chef/) et [Puppet](http://docs.puppetlabs.com/), combinés à des environnements virtuels légers comme [Docker](https://www.docker.com/) et [Vagrant](http://vagrantup.com/) permettent aux développeurs de faire fonctionner des environnements locaux qui reproduisent de très près les environnements de production. Le coût d'installation et d'utilisation de ces systèmes est faible comparé aux bénéfices d'une bonne parité développement/production et du déploiement continu. Les adaptateurs à ces différents systèmes externes sont malgré tout utiles, car ils rendent le portage vers de nouveaux services externes relativement indolores. Mais tous les déploiements de l'application (environnement de développement, validation, production) devraient utiliser le même type et la même version de chacun de ces services externes. content/pt_br/dependencies.md0000644000175000056700000000573015226251677015055 0ustar0000000000000000## II. Dependências ### Declare e isole explicitamente as dependências A maioria das linguagens de programação oferecem um sistema de pacotes para a distribuição de bibliotecas de apoio, como o [CPAN](http://www.cpan.org/) para Perl ou [Rubygems](http://rubygems.org/) para Ruby. Bibliotecas instaladas por meio de um sistema de pacotes podem ser instaladas em todo o sistema (conhecidas como "site packages") ou com escopo dentro do diretório contendo a aplicação (conhecidas como "vendoring" ou "building"). **Uma aplicação doze-fatores nunca confia na existência implícita de pacotes em todo o sistema.** Ela declara todas as dependências, completa e exatamente, por meio de um manifesto de *declaração de dependência*. Além disso, ela usa uma ferramenta de *isolamento de dependência* durante a execução para garantir que não há dependências implícitas "vazamento" a partir do sistema circundante. A completa e explícita especificação de dependências é aplicada de maneira uniforme tanto para produção quanto para desenvolvimento. Por exemplo, [Bundler](https://bundler.io/) para Ruby oferece o formato de manifesto `Gemfile` para declaração de dependência e `bundle exec` para isolamento das mesmas. Em Python existem duas ferramentas separadas para estas etapas -- [Pip](http://www.pip-installer.org/en/latest/) é utilizado para declaração e [Virtualenv](http://www.virtualenv.org/en/latest/) para isolamento. Mesmo C tem [Autoconf](http://www.gnu.org/s/autoconf/) para declaração de dependência, e vinculação estática pode fornecer o isolamento. Não importa qual o conjunto de ferramentas, declaração de dependência e isolamento devem ser sempre usados juntos -- apenas um ou o outro não é suficiente para satisfazer doze-fatores. Um dos beneficios da declaração de dependência explícita é que simplifica a configuração da aplicação para novos desenvolvedores. O novo desenvolvedor pode verificar a base de código do aplicativo em sua máquina de desenvolvimento, exigindo apenas runtime da linguagem e gerenciador de dependência instalado como pré-requisitos. Eles serão capazes de configurar tudo o que é necessário para rodar o código da aplicação com um determinístico *comando de build*. Por exemplo, o comando de build para Ruby/Bundler é `bundle install`, enquanto que para Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) é `lein deps`. Aplicações doze-fatores também não contam com a existência implícita de todas as ferramentas do sistema. Exemplos incluem executar algum comando externo como do ImageMagick ou `curl`. Embora possam existir essas ferramentas em muitos ou mesmo na maioria dos sistemas, não há garantia de que eles vão existir em todos os sistemas em que a aplicação pode rodar no futuro, ou se a versão encontrada em um futuro sistema será compatível com a aplicação. Se a aplicação precisa executar alguma ferramenta do sistema, essa ferramenta deve ser vendorizada na aplicação. content/th/dependencies.md0000644000175000056700000001154115226251677014357 0ustar0000000000000000## II. Dependencies ### มีการประกาศและแยกการอ้างอิง (dependency) ทั้งหมดอย่างชัดเจน ภาษาโปรแกรมส่วนใหญ่จะมีระบบ packaging สำหรับรองรับ library ต่างๆ อย่างเช่น [CPAN](http://www.cpan.org/) สำหรับ Perl หรือ [Rubygems](http://rubygems.org/) สำหรับ Ruby, Library จะถูกติดตั้งผ่านทางระบบ packaging สามารถติดตั้ง system-wide (เรียกว่า "site packages") หรือกำหนดขอบเขตเป็นไดเรกทรอรีที่มี app (เรียกว่า "vendoring" หรือ "bundling") **twelve-factor app ไม่ขึ้นอยู่กับ implicit existence of system-wide packages.** โดยประกาศการอ้างอิงทั้งหมด อย่างครบถ้วน และอย่างแน่นอน ด้วย *dependency declaration* manifest นอกจากนี้ใช้เครื่องมือ *dependency isolation* ระหว่างทำงานเพื่อให้แน่ใจว่าไม่มีการอ้างอิงแบบปริยาย "รั่ว (leak in)" จากระบบรอบๆ, รายละเอียดการอ้างอิงที่ครบถ้วนและชัดเจนใช้รูปแบบเดียวกันทั้ง production และ development ตัวอย่างเช่น [Bundler](https://bundler.io/) สำหรับ Ruby มีรูปบบ `Gemfile` manifest สำหรับประการการอ้างอิง และ `bundle exec` สำหรับแยกการอ้างอิง ใน Python มีเครื่องมือ 2 ตัวสำหรับแต่ละขั้นตอน -- [Pip](http://www.pip-installer.org/en/latest/) ใช้สำหรับประกาศอ้างอิง และ [Virtualenv](http://www.virtualenv.org/en/latest/) สำหรับแยกการอ้างอิง แม้อย่าง C มี [Autoconf](http://www.gnu.org/s/autoconf/) สำหรับประการการอ้างอิง และ static linking สามารถทำแยกการอ้างอิงได้ ไม่ว่าจะใช้เครื่องมืออะไรก็ตามแต่การประการศและแยกการอ้างอิงจำเป็นเสมอที่ใช้ร่วมกัน -- ถ้ามีเพียงหนึ่งหรืออื่นๆ ไม่เพียงพอที่ตรงตาม twelve-factor ประโยชน์อย่างหนึ่งของการประกาศการอ้างอิงที่ชัดเจนคือลดความยุ่งยากในการติดตั้งสำหรับ developer ใหม่สำหรับ app, developer ใหม่สามารถ check out codebase ของ app มายังเครื่องที่ใช้ development ต้องการเพียงแค่ติดตั้ง language runtime และ dependency manager เป็นข้อกำหนดเบื้องต้น พวกเขาจะสามามารถติดตั้งทุกสิ่งที่ต้องการเพื่อจะรัน code ของ app ด้วย *build command* ตัวอย่างเช่น ใช้ build command สำหรับ Ruby/Bundler คือ `bundle install` ขณะที่ Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) คือ `lein deps` Twelve-factor app ยังคงไม่ขึ้นอยู่กับเครื่องมือที่มีอยู่แล้ว ตัวอย่างเช่นใช้ shell out ไปยัง ImageMagick หรือ `curl` ขณะที่เครื่องมือเหล่านี้อาจจะมีอยู่บนระบบส่วนใหญ่แล้ว ซึ่งจะไม่รับประกันว่าจะมีอยู่บนเครื่องทั้งหมดซึ่ง app จะทำงานในอนาคต หรือ version ที่หาเจอในเครื่องที่จะไปทำงานในอนาคตจะเข้ากันได้กับ app ถ้า app จำเป็น shell out ใช้เครื่องมือของเครื่อง ที่เครื่องมืออาจจะ vendord ให้ app locales/ja.yml0000644000175000056700000000033315226251677012056 0ustar0000000000000000ja: # Name of language listed in locales menu language: 日本語 (ja) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: （日本語訳） content/fr/logs.md0000644000175000056700000000521715226251677012674 0ustar0000000000000000## XI. Logs ### Traitez les logs comme des flux d'évènements Les *logs* fournissent de la visibilité au comportement de l'application qui s'exécute. Dans des environnements de type serveur, ils sont généralement écrits dans un fichier, sur le disque (dans un fichier de log). Mais c'est simplement un format de sortie. Les logs sont des [flux (en)](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) d'agrégats d'évènements, ordonnés dans le temps, collectés à travers les flux de sortie de tous les processus et services externes qui tournent. Les logs, dans leur forme brute, sont au format texte avec un événement par ligne (bien que les traces d'exécutions puissent s'étaler sur plusieurs lignes). Les logs n'ont pas de début ou de fin fixe, mais se remplissent en continu tant que l'application est en marche. **Une application 12 facteurs ne s'inquiète jamais du routage ou du stockage de ses flux de sortie.** Elle ne devrait pas tenter d'écrire ou de gérer les fichiers de logs. À la place, chaque processus qui tourne écrit ses flux d'événements, sans tampon, vers `stdout`, la sortie standard ; en phase de développement local, les développeurs pourront voir ce flux dans leur terminal et observer le comportement de l'application. Dans les déploiements de validation ou de production, les flux de chaque processus seront capturés par leur environnement d'exécution, assemblés avec les autres flux de l'application, et routés vers une ou plusieurs destinations pour un visionnage et un archivage de longue durée. Le lieu d'archivage n'est pas visible et ne peut être configuré par l'application : ils sont complètements gérés par l'environnement d'exécution. Des routeurs opensource de logs, (tel que [Logplex](https://github.com/heroku/logplex) et [Fluentd](https://github.com/fluent/fluentd)) existent pour cela. Le flux d'événements d'une application peut être routé dans un fichier, ou surveillé en temps réel (avec tail) dans un terminal. Plus pertinent, les flux peuvent être envoyés vers un outil d'indexation et d'archivage des logs tel que [Splunk](http://www.splunk.com/), ou bien dans un entrepôt de données générique comme [Hadoop/Hive](http://hive.apache.org/). Ces systèmes sont très puissants et flexibles pour inspecter le comportement de l'application au cours du temps, ce qui inclut : * Trouver un événement spécifique dans le passé * Faire des graphiques à grande échelle des tendances (comme le nombre de requêtes par minutes) * Lever des alertes, à partir d'heuristiques définies par l'utilisateur (comme alerter dès que la quantité d'erreurs par minutes dépasse un certain seuil) content/ja/disposability.md0000644000175000056700000000724315226251677014573 0ustar0000000000000000## IX. 廃棄容易性 ### 高速な起動とグレースフルシャットダウンで堅牢性を最大化する **Twelve-Factor Appの [プロセス](./processes) は *廃棄容易* である、すなわち即座に起動・終了することができる。** この性質が、素早く柔軟なスケールと、[コード](./codebase) や [設定](./config) に対する変更の素早いデプロイを容易にし、本番デプロイの堅牢性を高める。 プロセスは、 **起動時間を最小化する** よう努力するべきである。理想的には、1つのプロセスは、起動コマンドが実行されてから数秒間でリクエストやジョブを受け取れるようになるべきである。起動時間が短いと、[リリース](./build-release-run)作業やスケールアップのアジリティが高くなる。さらに、プロセスマネージャーが必要に応じてプロセスを新しい物理マシンに簡単に移動できるようになるため、堅牢性も高くなる。 プロセスは、プロセスマネージャーから **[SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)シグナルを受け取ったときに、グレースフルにシャットダウンする。** Webプロセスの場合、グレースフルシャットダウンは、サービスポートのリッスンを中止し（従って新しいリクエストを拒み）、処理中のリクエストが終了するまで待ち、シャットダウンすることで実現される。このモデルでは暗黙的にHTTPリクエストが短い（せいぜい数秒）ことを仮定している。ロングポーリングの場合、クライアントはコネクションが失われたときに途切れなく再接続を試みるべきである。 ワーカープロセスの場合、グレースフルシャットダウンは、処理中のジョブをワーカーキューに戻すことで実現される。例えば、[RabbitMQ](http://www.rabbitmq.com/)ではワーカーは[`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack)を送ることができる。[Beanstalkd](https://beanstalkd.github.io)では、ワーカーの接続が失われるとジョブは自動的にキューに戻る。[Delayed Job](https://github.com/collectiveidea/delayed_job#readme)などのロックをベースにしたシステムでは、ジョブレコードのロックを確実に解放する必要がある。このモデルでは、暗黙的にすべてのジョブが[再入可能](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29)であることを仮定している。再入可能性は一般的に、結果をトランザクションで包んだり、処理を[べき等](http://en.wikipedia.org/wiki/Idempotence)にすることで実現される。 また、下層のハードウェアの障害に関して言えば、プロセスは **突然の死に対して堅牢** であるべきである。このような事態が起こることは、`SIGTERM`によるグレースフルシャットダウンに比べればずっと少ないが、それでも起こりうる。この対策として推奨される方法は、Beanstalkdなどの堅牢なキューイングバックエンドを使い、クライアントの接続が切断されたり、タイムアウトしたときにジョブをキューに戻せるようにすることである。どちらにしても、Twelve-Factor Appは予期しないグレースフルでない停止をうまく処理できるよう設計される。[「クラッシュオンリー」設計](http://lwn.net/Articles/191059/)はこのコンセプトをその[論理的帰結](http://docs.couchdb.org/en/latest/intro/overview.html)に導く。 content/uk/codebase.md0000644000175000056700000000710515226251677013503 0ustar0000000000000000## I. Кодова база ### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань Застосунок дванадцяти факторів завжди відслідковуються в системі контролю версій, такій як [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) або [Subversion](http://subversion.apache.org/). Копія бази даних відстеження ревізій називається *репозиторій коду (code repository)*, що часто скорочується до *code repo* або просто *repo*. *Кодова база* — це один репозиторій (в централізованих системах контролю версій, як Subversion), або декілька репозиторіїв, які мають спільний початковий комміт (в децентралізованих системах контролю версій, як Git). ![Одна кодова база — багатьо розгортань](/images/codebase-deploys.png) Завжди існує однозначна відповідність між кодовою базою і застосунком: * За наявності кількох баз коду, це не застосунок, це — розподілена система. Кожен компонент в розподіленій системі є застосунком, і кожен з них може окремо дотримуватися дванадцяти факторів. * Кілька різних застосунків, що спільно використовують загальну базу коду, є порушенням дванадцяти факторів. Рішенням в даній ситуації є виділення загального коду в бібліотеки, які можуть бути підключені через [менеджер залежностей](./dependencies). Існує тільки одна кодова база для кожного застосунку, але може бути багато розгортань одного і того самого застосунку. *Розгортанням (deploy)* є запущений екземпляр застосунку. Це, як правило, production-сайт і один або більше staging-сайтів (проміжних розгортань). Крім того, розробник має копію застосунку, запущеного в його локальному середовищі розробки. Кожну з таких копій також можна кваліфікувати як розгортання (deploy). Кодова база має бути єдина для всіх розгортань, хоча в кожному розгортанні можуть бути активні різні її версії. Наприклад, розробник може мати деякі зміни у коді, які ще не додані в staging-розгортання; staging-розгортання може мати деякі зміни, які ще не додані в production-розгортання. Але всі вони використовують одну і ту саму кодову базу, таким чином можна їх ідентифікувати як різні розгортання одного і того ж застосунку.content/ko/dev-prod-parity.md0000644000175000056700000001231115226251677014751 0ustar0000000000000000## X. dev/prod 일치 ### development, staging, production 환경을 최대한 비슷하게 유지 역사적으로, 개발 환경(애플리케이션의 개발자가 직접 수정하는 로컬의 [배포](./codebase))과 production 환경(최종 사용자가 접근하게 되는 실행 중인 배포) 사이에는 큰 차이가 있었습니다. 이러한 차이는 3가지 영역에 걸처 나타납니다. * **시간의 차이**: 개발자가 작업한 코드는 production에 반영되기까지 며칠, 몇주, 때로는 몇개월이 걸릴 수 있습니다. * **담당자의 차이**: 개발자가 작성한 코드를 시스템 엔지니어가 배포합니다. * **툴의 차이**: production 배포는 아파치, MySQL, 리눅스를 사용하는데, 개발자는 Nginx, SQLite, OS X를 사용할 수 있습니다. **Twelve Factor App은 개발 환경과 production 환경의 차이를 작게 유지하여 [지속적인 배포](http://avc.com/2011/02/continuous-deployment/)가 가능하도록 디자인 되었습니다.** 위에서 언급한 3가지 차이에 대한 대응책은 아래와 같습니다. * 시간의 차이을 최소화: 개발자가 작성한 코드는 몇 시간, 심지어 몇 분 후에 배포됩니다. * 담당자의 차이를 최소화: 코드를 작성한 개발자들이 배포와 production에서의 모니터링에 깊게 관여합니다. * 툴의 차이를 최소화: 개발과 production 환경을 최대한 비슷하게 유지합니다. 위의 내용을 표로 요약하면 아래와 같습니다.
전통적인 애플리케이션 Twelve-Factor App
배포 간의 간격 몇 주 몇 시간
코드 작성자와 코드 배포자 다른 사람 같은 사람
개발 환경과 production 환경 불일치함 최대한 유사함
데이터베이스, 큐잉 시스템, 캐시와 같은 [백엔드 서비스](./backing-services)는 dev/prod 일치가 중요한 영역 중 하나 입니다. 많은 언어들은 다른 종류의 서비스에 대한 *어댑터*를 포함하고 간단하게 백엔드 서비스에 접근할 수 있는 라이브러리들을 제공합니다. 아래의 표에 몇가지 예가 나와있습니다.
종류 언어 라이브러리 어댑터
데이터 베이스 Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
큐(Queue) Python/Django Celery RabbitMQ, Beanstalkd, Redis
캐쉬 Ruby/Rails ActiveSupport::Cache 메모리, 파일시스템, Memcached
production 환경에서는 더 본격적이고 강력한 백엔드 서비스가 사용됨에도 불구하고, 개발자는 자신의 로컬 개발 환경에서는 가벼운 백엔드 서비스를 사용하는 것에 큰 매력을 느낄 수도 있습니다. 예를 들어, 로컬에서는 SQLite를 사용하고 production에서는 PostgreSQL을 사용한다던가, 개발 중에는 로컬 프로세스의 메모리를 캐싱용으로 사용하고 production에서는 Memcached를 사용하는 경우가 있습니다. **Twelve-Factor 개발자는 개발 환경과 production 환경에서 다른 백엔드 서비스를 쓰고 싶은 충동에 저항합니다.** 이론적으로는 어댑터가 백엔드 서비스 간의 차이를 추상화해준다고 해도, 백엔드 서비스 간의 약간의 불일치가 개발 환경과 스테이징 환경에서는 동작하고 테스트에 통과된 코드가 production 환경에서 오류를 일으킬 수 있기 때문입니다. 이런 종류의 오류는 지속적인 배포를 방해합니다. 애플리케이션의 생명 주기 전체를 보았을 때, 이러한 방해와 지속적인 배포의 둔화가 발생시키는 손해는 엄청나게 큽니다. 가벼운 로컬 서비스는 예전처럼 필수적인 것은 아닙니다. Memcache, PostgreSQL, RabbitMQ와 같은 현대적인 백엔드 서비스들은 [Homebrew](http://mxcl.github.com/homebrew/)나 [apt-get](https://help.ubuntu.com/community/AptGet/Howto)와 같은 현대적인 패키징 시스템 덕분에 설치하고 실행하는데 아무런 어려움도 없습니다. 혹은 [Chef](http://www.opscode.com/chef/) and [Puppet](http://docs.puppetlabs.com/)와 같은 선언적 provisioning 툴과 [Vagrant](http://vagrantup.com/)등의 가벼운 가상 환경을 결합하여 로컬 환경을 production 환경과 매우 유사하게 구성할 수 있습니다. dev/prod 일치와 지속적인 배포의 이점에 비하면 이러한 시스템을 설치하고 사용하는 비용은 낮습니다. 여러 백엔드 서비스에 접근할 수 있는 어댑터는 여전히 유용합니다. 새로운 백엔드 서비스를 사용하도록 포팅하는 작업의 고통을 낮춰주기 때문입니다. 하지만, 모든 애플리케이션의 배포들(개발자 환경, 스테이징, production)은 같은 종류, 같은 버전의 백엔드 서비스를 이용해야합니다. content/pl/toc.md0000644000175000056700000000234615226251677012521 0ustar0000000000000000The Twelve Factors ================== ## [I. Codebase](./codebase) ### Jedno źródło kodu śledzone systemem kontroli wersji, wiele wdrożeń ## [II. Zależności](./dependencies) ### Jawnie zadeklaruj i wydziel zależności ## [III. Konfiguracja](./config) ### Przechowuj konfigurację w środowisku ## [IV. Usługi wspierające](./backing-services) ### Traktuj usługi wspierające jako przydzielone zasoby ## [V. Buduj, publikuj, uruchamiaj](./build-release-run) ### Oddzielaj etap budowania od uruchamiania ## [VI. Procesy](./processes) ### Uruchamiaj aplikację jako jeden lub więcej bezstanowych procesów ## [VII. Przydzielanie portów](./port-binding) ### Udostępniaj usługi przez przydzielanie portów ## [VIII. Współbieżność](./concurrency) ### Skaluj przez odpowiednio dobrane procesy ## [IX. Zbywalność](./disposability) ### Zwiększ elastyczność pozwalając na szybkie uruchamianie i zatrzymywanie aplikacji ## [X. Jednolitość środowisk](./dev-prod-parity) ### Utrzymuj konfigurację środowisk jak najbardziej zbliżoną do siebie ## [XI. Logi](./logs) ### Traktuj logi jako strumień zdarzeń ## [XII. Zarządzanie aplikacją](./admin-processes) ### Uruchamiaj zadania administracyjne jako jednorazowe procesy content/zh_cn/toc.md0000644000175000056700000000171615226251677013207 0ustar000000000000000012-factors ================== ## [I. 基准代码](./codebase) ### 一份基准代码，多份部署 ## [II. 依赖](./dependencies) ### 显式声明依赖关系 ## [III. 配置](./config) ### 在环境中存储配置 ## [IV. 后端服务](./backing-services) ### 把后端服务当作附加资源 ## [V. 构建，发布，运行](./build-release-run) ### 严格分离构建和运行 ## [VI. 进程](./processes) ### 以一个或多个无状态进程运行应用 ## [VII. 端口绑定](./port-binding) ### 通过端口绑定提供服务 ## [VIII. 并发](./concurrency) ### 通过进程模型进行扩展 ## [IX. 易处理](./disposability) ### 快速启动和优雅终止可最大化健壮性 ## [X. 开发环境与线上环境等价](./dev-prod-parity) ### 尽可能的保持开发，预发布，线上环境相同 ## [XI. 日志](./logs) ### 把日志当作事件流 ## [XII. 管理进程](./admin-processes) ### 后台管理任务当作一次性进程运行 content/pl/who.md0000644000175000056700000000033615226251677012526 0ustar0000000000000000Dla kogo przeznaczony jest ten dokument? ============================== Dla każdego developera tworzącego aplikacje, które działają jako usługa. Dla każdego Dev-opsa, który wdraża i zarządza takimi aplikacjami. content/tr/background.md0000644000175000056700000000304215226251677014057 0ustar0000000000000000Arkaplan ========== Bu belgeye katkıda bulunan kişiler, yüzlerce uygulamanın geliştirilmesi ve dağıtılmasında doğrudan yer almış, ve dolaylı olarak Heroku platformundaki üzerinde çalıştığımız yüz binlerce uygulamanın geliştirilmesi, çalıştırılması ve ölçeklendirilmesine tanık olmuştur. Bu belge, çok çeşitli yazılım servislerinin, yabancı ortamdaki deneyim ve gözlemlerini birleştirir. Bu uygulama geliştirimindeki uygun, ideal uygulamalarda bir üçgenleştirme vardır; uygulamanın zamanla olan doğal gelişmesinin, büyümesinin temel etmenlerine dikkat etmek, uygulamanın kod tabanında çalışan yazılımcıların arasındaki işbirliğinin önemli noktaları ve yazılım erozyonunun getirdiği ücretten kaçmak. Bizim motivasyonumuz, modern uygulama geliştirmesinde gördüğümüz bazı sistemik problemlerin farkındalığını arttırmak, terimlerle birlikte geniş kavramsal çözüm setleri sağlamak ve bu problemleri tartışmak için ortak bir kelime sunmakdır. Martin Fowler'ın kitabları *Patterns of Enterprise Application Architecture* ve *Refactoring'den* ilham alınmıştır. views/home.erb0000644000175000056700000000044215226251677012077 0ustar0000000000000000
<%= render_markdown('intro') %>
<%= render_markdown('background') %>
<%= render_markdown('who') %>
<%= render_markdown('toc') %>
content/es/background.md0000644000175000056700000000303115226251677014037 0ustar0000000000000000Contexto ======== Los colaboradores de este documento han estado involucrados directamente en el desarrollo y despliegue de cientos de aplicaciones, y han sido testigos indirectos del desarrollo, las operaciones y el escalado de cientos de miles de aplicaciones mediante nuestro trabajo en la plataforma [Heroku](http://www.heroku.com/). Este documento sintetiza toda nuestra experiencia y observaciones en una amplia variedad de aplicaciones SaaS. Es la triangulación entre practicas ideales para el desarrollo de aplicaciones, prestando especial atención a las dinámicas del crecimiento natural de una aplicación a lo largo del tiempo, las dinámicas de colaboración entre desarrolladores que trabajan en el código base de las aplicaciones y [evitando el coste de la entropía del software](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). Nuestra motivación es mejorar la concienciación sobre algunos problemas sistémicos que hemos observado en el desarrollo de las aplicaciones modernas, aportar un vocabulario común que sirva para discutir sobre estos problemas, y ofrecer un conjunto de soluciones conceptualmente robustas para esos problemas acompañados de su correspondiente terminología. El formato está inspirado en los libros de Martin Fowler *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* y *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/pt_br/concurrency.md0000644000175000056700000000554415226251677014764 0ustar0000000000000000## VIII. Concorrência ### Escale através do processo modelo Qualquer programa de computador, uma vez executado, está representado por um ou mais processos. Aplicações web têm tomado uma variedade de formas de processo de execução. Por exemplo, processos PHP rodam como processos filhos do Apache, iniciados sob demanda conforme necessário por volume de requisições. Processos Java tomam o caminho inverso, com a JVM proporcionando um processo uber maciço que reserva um grande bloco de recursos do sistema (CPU e memória) na inicialização, com concorrência gerenciada internamente via threads. Em ambos os casos, o(s) processo(os) em execução são apenas minimamente visível para os desenvolvedores da aplicação. ![Escala é expressado como processos em execução, a diversidade da carga de trabalho é expressada como tipos de processo.](/images/process-types.png) **Na aplicação doze-fatores, processos são cidadãos de primeira classe.** Processos na aplicação doze-fatores utilizam fortes sugestões do modelo de processos UNIX para execução de serviços daemon, o desenvolvedor pode arquitetar a aplicação dele para lidar com diversas cargas de trabalho, atribuindo a cada tipo de trabalho a um *tipo de processo*. Por exemplo, solicitações HTTP podem ser manipuladas para um processo web, e tarefas background de longa duração podem ser manipuladas por um processo trabalhador. Isto não exclui processos individuais da manipulação de sua própria multiplexação interna, por threads dentro do runtime da VM, ou o modelo async/evented encontrado em ferramentas como [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), ou [Node.js](http://nodejs.org/). Mas uma VM individual pode aumentar (escala vertical), de modo que a aplicação deve ser capaz de abranger processos em execução em várias máquinas físicas. O modelo de processo realmente brilha quando chega a hora de escalar. O [compartilhar-nada, natureza horizontal particionada de um processo da aplicação doze-fatores](./processes) significa que a adição de mais simultaneidade é uma operação simples e de confiança. A matriz de tipos de processo e número de processos de cada tipo é conhecida como o *processo de formação*. Processos de uma app doze-fatores [nunca deveriam daemonizar](http://dustin.github.com/2010/02/28/running-processes.html) ou escrever arquivos PID. Em vez disso, confiar no gerente de processo do sistema operacional (como [systemd](https://www.freedesktop.org/wiki/Software/systemd/), um gerenciador de processos distribuídos em uma plataforma de nuvem, ou uma ferramenta como [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) em desenvolvimento) para gerenciar [fluxos de saída](./logs), responder a processos travados, e lidar com reinícios e desligamentos iniciados pelo usuário. content/uk/background.md0000644000175000056700000000433615226251677014060 0ustar0000000000000000Передумови ========== Люди, що працювали над цим документом, брали безпосередню участь в розробці і розгортанні сотень застосунків, і мимоволі стали свідками розвитку, експлуатації та масштабування сотень тисяч застосунків під час нашої роботи над платформою [Heroku](http://www.heroku.com/). В цьому документі узагальнюється весь наш досвід використання і спостереження за найрізноманітнішими SaaS-застосунками "в дикій природі". Документ об'єднує ідеальні практики розробки застосунків, особлива увага приділяється динаміці органічного росту застосунку з плином часу, взаємодії між розробниками, які працюють над кодом застосунку, та [уникненню витрат при ерозії програмного забезпечення](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). Наша мета полягає в тому, щоб підвищити обізнаність про деякі системні проблеми, які ми бачили в практиці розробки сучасних застосунків, а також в тому, щоб сформулювати спільні загальні поняття для обговорення цих проблем, і запропонувати набір загальних концептуальних рішень цих проблем з супутньою термінологією. Формат навіяний книгами Мартіна Фаулера (Martin Fowler) *[Patterns of Enterprise Application Architecture](https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* та *[Refactoring](https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*.content/de/admin-processes.md0000644000175000056700000000457215226251677015010 0ustar0000000000000000## XII. Admin-Prozesse ### Admin/Management-Aufgaben als einmalige Vorgänge behandeln Die [Prozess-Formation](./concurrency) ist das Bündel von Prozessen zur Erledigung der üblichen Aufgaben einer App (wie die Abarbeitung von Web-Requests) während sie läuft. Daneben möchten Entwickler oft einmalige Administrativ- oder Wartungsaufgaben an der App erledigen, wie zum Beispiel: * Datenbank-Migrationen starten (z.B. `manage.py migrate` in Django, `rake db:migrate` in Rails) * Eine Konsole starten (auch bekannt als [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) Shell) um beliebigen Code zu starten oder die Modelle der App gegen die Live-Datenbank zu prüfen. Die meisten Sprachen stellen eine REPL zur Verfügung, wenn man den Interpreter ohne Argumente startet (z.B. `python` oder `perl`) oder in manchen Fällen mit einem anderen Kommando (z.B. `irb` für Ruby, `rails console` für Rails). * Einmalig auszuführende Skripte aus dem Repo der App starten (z.B. `php scripts/fix_bad_records.php`). Einmalige Administrationsprozesse sollten in einer Umgebung laufen, die identisch ist zu der Umgebung der üblichen [langlaufenden Prozesse](./processes). Sie laufen gegen einen [Release](./build-release-run) und benutzen dieselbe [Codebase](./codebase) und [Konfiguration](./config) wie jeder Prozess, der gegen einen Release läuft. Administrationscode wird mit dem App-Code ausgeliefert um Synchronisationsprobleme zu vermeiden. Dieselben Techniken zur [Isolation von Abhängigkeiten](./dependencies) sollten für alle Prozessarten verwendet werden. Wenn zum Beispiel ein Ruby-Web-Prozess das Kommando `bundle exec thin start` verwendet, dann sollte eine Datenbankmigration `bundle exec rake db:migrate` verwenden. Wenn ein Python-Programm Virtualenv nutzt, sollte es sein mitgeliefertes `bin/python` sowohl zum Start des Tornado Webservers als auch für alle `manage.py` Admin-Prozesse verwenden. Die Zwölf Faktoren bevorzugen Sprachen, die eine REPL Shell direkt mitbringen. Das erleichtert das Starten von einmal auszuführenden Skripten. In einem lokalen Deploy rufen Entwickler einmal auszuführende Admin-Prozesse direkt über ein Shell-Kommando im Checkout-Verzeichnis der App auf. In einem Produktions-Deploy können Entwickler ssh oder andere Kommando-Fernsteuerungs-Mechanismen benutzen, die die Ausführungsumgebung dieses Deploys für das Starten eines solchen Prozesses bereitstellt. content/fr/background.md0000644000175000056700000000317315226251677014046 0ustar0000000000000000Contexte ========== Les contributeurs de ce document ont été directement impliqués dans le développement et le déploiement de centaines d'applications, et ont vu, indirectement, le développement, la gestion et le grossissement de centaines de milliers d'applications via le travail fait sur la plateforme [Heroku](http://www.heroku.com/). Ce document fait la synthèse de toutes nos expériences et observations sur une large variété d'applications software-as-a-service. C'est la triangulation de pratiques idéales pour le développement d'applications, en portant un soin tout particulier aux dynamiques de la croissance organique d'une application au cours du temps, les dynamiques de la collaboration entre les développeurs qui travaillent sur le code de l'application, en [évitant le coût de la lente détérioration du logiciel dans un environnement qui évolue (en)](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). Notre motivation est de faire prendre conscience de certains problèmes systémiques que nous avons rencontrés dans le développement d'applications modernes, afin de fournir un vocabulaire partagé pour discuter ces problèmes, et pour offrir un ensemble de solutions conceptuelles générales à ces problèmes, ainsi que la terminologie correspondante. Le format est inspiré par celui des livres de Martin Fowler *[Patterns of Enterprise Application Architecture (en)](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* et *[Refactoring (en)](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/uk/who.md0000644000175000056700000000045215226251677012531 0ustar0000000000000000Кому слід читати цей документ? ============================== Розробникам, які створюють SaaS-застосунки. Ops-інженерам, які виконують розгортання і керування такими застосунками.locales/ru.yml0000644000175000056700000000035415226251677012115 0ustar0000000000000000ru: # Name of language listed in locales menu language: Русский (ru) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: (Русский перевод)content/es/dev-prod-parity.md0000644000175000056700000001250615226251677014755 0ustar0000000000000000## X. Igualdad entre desarrollo y producción ### Mantener desarrollo, preproducción y producción tan parecidos como sea posible Históricamente, han existido dos tipos de entorno muy diferenciados: desarrollo (donde un desarrollador puede editar en vivo en un [despliegue](./codebase) local de la aplicación) y producción (un despliegue en el que la aplicación está en ejecución disponible para que lo usen los usuarios). Estas diferencias se pueden clasificar en tres tipos: * **Diferencias de tiempo**: Un desarrollador puede estar trabajando en un código durante días, semanas o incluso meses antes de que llegue a producción. * **Diferencias de personal**: Los desarrolladores escriben el código y los ingenieros de operaciones lo despliegan. * **Diferencias de herramientas**: Los desarrolladores pueden usar una pila como Nginx, SQLite y OS X, mientras que en producción se usa Apache, MySQL y Linux. ** Las aplicaciones "twelve-factor" están diseñadas para hacer [despliegues continuos](http://avc.com/2011/02/continuous-deployment/) que reducen las diferencias entre los entornos de desarrollo y producción.** Teniendo en cuenta las tres diferencias descritas anteriormente: * Reducir las diferencias de tiempo: Un desarrollador puede escribir código y tenerlo desplegado en tan solo unas horas, o incluso, minutos más tarde. * Reducir las diferencias de personal: Los desarrolladores que escriben el código están muy involucrados en el despliegue y observan su comportamiento en producción. * Reducir las diferencias de herramientas: tratar de hacer que desarrollo y producción sean tan parecidos como sea posible. Resumiendo lo anterior en una tabla:
Aplicaciones tradicionales Aplicaciones "twelve-factor"
Tiempo entre despliegues Semanas Horas
Desarrolladores vs Ingenieros de operaciones Diferentes personas Mismas personas
Entorno de desarrollo vs entorno de producción Divergentes Lo más parecidos posibles
Los ["backing services"](./backing-services), como la base de datos de la aplicación, el sistema de colas, o la caché, es donde la igualdad en los entornos de desarrollo y producción es importante. Muchos lenguajes ofrecen librerías en las que se simplifica el acceso a los servicios de respaldo, incluidos *adaptadores* para diferentes tipos de servicios. Se pueden observar algunos ejemplos en la siguiente tabla.
Tipo Lenguaje Librería Adaptador
Base de datos Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Colas Python/Django Celery RabbitMQ, Beanstalkd, Redis
Caché Ruby/Rails ActiveSupport::Cache Memoria, sistema de ficheros, Memcached
Los desarrolladores, a veces, caen en la tentación de usar "backing services" ligeros en sus entornos de desarrollo, mientras que en producción se usan los más serios y robustos. Por ejemplo, se usa SQLite en desarrollo y PostgreSQL en producción; o memoria local para la caché en desarrollo y Memcached en producción. **Un desarrollador "twelve-factor" no cae en la tentación de usar diferentes "backing services" en desarrollo y producción**, incluso cuando los adaptadores teóricamente abstractos están lejos de cualquier diferencia en "backing services". Las diferencias entre los servicios de respaldo tienen que ver con las pequeñas incompatibilidades que surgen de la nada, causando que el código que funciona y pasa los tests en desarrollo o en preproducción, falle en producción. Este tipo de errores provocan conflictos que desincentivan la filosofía del despliegue continuo. El coste de estos conflictos y el enfriamiento subsiguiente del despliegue continuo es extremadamente alto cuando se hace balance del total de tiempo de vida de una aplicación. Los servicios ligeros locales son menos atractivos que antes. Los "backing services" modernos como Memcached, PostgreSQL, y RabbitMQ no son difíciles de instalar y ejecutar gracias a los sistemas de gestión de paquetes modernos, como [Homebrew](http://mxcl.github.com/homebrew/) y [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Al mismo tiempo, las herramientas de gestión de la configuración como [Chef](http://www.opscode.com/chef/) y [Puppet](http://docs.puppetlabs.com/) combinadas con entornos virtuales ligeros como [Docker](https://www.docker.com/) o [Vagrant](http://vagrantup.com/) permiten a los desarrolladores ejecutar entornos locales que son muy parecidos a los entornos de producción. El coste de instalar y usar estos sistemas es bajo comparado con el beneficio que se puede obtener de la paridad entre desarrollo y producción y del despliegue continuo. Los adaptadores de los "backing services" todavía son de gran utilidad, porque hacen que cambiar de unos a otros sea un trámite relativamente poco doloroso. No obstante, todos los despliegues de una aplicación (en entornos de desarrollo, preproducción y producción) deberían usar el mismo tipo y versión de cada uno de los "backing services". content/ko/logs.md0000644000175000056700000000510515226251677012672 0ustar0000000000000000## XI. 로그 ### 로그를 이벤트 스트림으로 취급 *로그*는 실행 중인 app의 동작을 확인할 수 있는 수단입니다. 서버 기반 환경에서 로그는 보통 디스크에 파일(로그 파일)로 저장됩니다. 하지만, 이것은 출력 포맷 중 하나에 불과합니다. 로그는 모든 실행중인 프로세스와 백그라운드 서비스의 아웃풋 스트림으로부터 수집된 이벤트가 시간 순서로 정렬된 [스트림](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/)입니다. 가공되지 않는 로그는 보통, 하나의 이벤트가 하나의 라인으로 기록된 텍스트 포맷입니다.(예외(exception)에 의한 backtrace는 여러 라인에 걸쳐 있을 수도 있습니다.) 로그는 고정된 시작과 끝이 있는 것이 아니라, app이 실행되는 동안 계속 흐르는 흐름입니다. **Twelve-Factor App은 아웃풋 스트림의 전달이나 저장에 절대 관여하지 않습니다.** app은 로그 파일을 작성하거나, 관리하려고 해서는 안됩니다. 대신, 각 프로세스는 이벤트 스트림을 버퍼링 없이 `stdout`에 출력합니다. 로컬 개발환경에서 작업 중인 개발자는 app의 동작을 관찰하기 원하면 각자의 터미널에 출력되는 이 스트림을 볼 수 있습니다. 스테이징이나 production 배포에서는 각 프로세스의 스트림은 실행 환경에 의해서 수집된 후, 앱의 다른 모든 스트림과 병합되어 열람하거나 보관하기 위한 하나 이상의 최종 목적지로 전달됩니다. 이러한 목적지들은 앱이 열람하거나 설정할 수 없지만, 대신 실행 환경에 의해서 완벽하게 관리됩니다. 이를 위해 오픈 소스 로그 라우터를 사용할 수 있습니다.(예: ([Logplex](https://github.com/heroku/logplex), [Fluentd](https://github.com/fluent/fluentd))) 앱의 이벤트 스트림은 파일로 보내지거나 터미널에서 실시간으로 보여질 수 있습니다. 가장 중요한 점은 스트림은 [Splunk](http://www.splunk.com/)같은 로그 분석 시스템과 [Hadoop/Hive](http://hive.apache.org/)같은 범용 데이터 보관소에 보내질 수 있다는 점입니다. 이러한 시스템은 장기간에 걸쳐 앱의 동작을 조사할 수 있는 강력함과 유연성을 가지게 됩니다. * 과거의 특정 이벤트를 찾기 * 트렌드에 대한 거대한 규모의 그래프 (예: 분당 요청 수) * 유저가 정의한 휴리스틱에 따른 알림 (예: 분당 오류 수가 임계 값을 넘는 경우 알림을 발생시킴) content/pt_br/intro.md0000644000175000056700000000216215226251677013556 0ustar0000000000000000Introdução ============ Na era moderna, software é comumente entregue como um serviço: denominados *web apps*, ou *software-como-serviço*. A aplicação doze-fatores é uma metodologia para construir softwares-como-serviço que: * Usam formatos **declarativos** para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto; * Tem um **contrato claro** com o sistema operacional que o suporta, oferecendo **portabilidade máxima** entre ambientes que o executem; * São adequados para **implantação** em modernas **plataformas em nuvem**, evitando a necessidade por servidores e administração do sistema; * **Minimizam a divergência** entre desenvolvimento e produção, permitindo a **implantação contínua** para máxima agilidade; * E podem **escalar** sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento. A metodologia doze-fatores pode ser aplicada a aplicações escritas em qualquer linguagem de programação, e que utilizem qualquer combinação de serviços de suportes (banco de dados, filas, cache de memória, etc).content/tr/logs.md0000644000175000056700000000501115226251677012702 0ustar0000000000000000## XI. Günlükler ### Günlüklere olay akışı gibi davranma *Günlükler* çalışan bir uygulamanın davranışının görünür olmasını sağlar. Sunucu tabanlı ortamlarda genellikle diskteki bir dosyaya yazılırlar("logfile"); ama bu sadece çıktı formatındadır. Günlükler, bütün çalışan süreçler ve destek servislerinin çıktı akışlarından kümelenmiş, zaman sıralı olayların [akışıdır](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/). Günlükler ilk formda her bir satır için bir olay olacak şekilde yazı formatındadır(Bununla birlikte istisnalardaki geri dönüşleri birden fazla satırda ölçebilir). Günlükler başta ve sonda düzeltilmemiş ama akış, uygulama işlediği sürece devam eder. **On iki faktör uygulaması çıkış akışlarının depolaması veya yönlendirilmesiyle ilgilenmez.** Günlük dosyalarını yazma ve yönetme yapmamalıdır. Bunun yerine, her çalışan süreç kendi olay akışını tamponlamadan `stdout`'a yazar. Yerel geliştirme süresince, geliştirici uygulamanın davranışını gözlemlemek için terminallerinin önplanında bu akışı inceleyecekler. Evreleme ve ürün dağıtımlarında herbir sürecin akışı çalışma ortamı tarafından yakalanmış diğer uygulamadaki, diğer bütün akışlarla birlikte sıralanmış, görüntüleme ve uzun dönem arşivleme için bir veya daha fazla son hedeflerine yönlendirilmiş olacaklar. Bu arşivsel hedefler uygulama tarafından görülebilir veya yapılandırılabilir değildir, bunun yerine tamamen çalışma ortamı tarafından yönetilirler. Açık kaynak günlük yönlendiricileri ([Logplex](https://github.com/heroku/logplex) ve [Fluentd](https://github.com/fluent/fluentd) gibi) bu amaç için erişilebilirdir. Bir uygulama için olay akışı dosyaya yönlendirilebilir veya terminalden gerçek zamanlı kuyruklama aracılığla izlenebilir. En önemlisi, akış [Splunk](http://www.splunk.com/) gibi günlük numaralandırma ve analiz sistemine veya [Hadoop/Hive](http://hive.apache.org/) gibi genel amaçlı veri depolama sistemine gönderilebilir. Bu sistemler uygulamanın zamanla olan davranışlarında iç gözlem yapmak için büyük güç ve esnekliğe izin verir. Bunları içerir: * Geçmişteki özel olayları bulmak. * Eğilimlerin geniş aralıklı grafikleri(her bir dakika için olan istekler gibi). * Kullanıcı tanımlı kestirme yollara göre aktif uyarma(Bir dakikadaki hataların niceliği belirli bir alt sınırı geçtiği zaman olan uyarı gibi). content/uk/backing-services.md0000644000175000056700000001077115226251677015160 0ustar0000000000000000## IV. Сторонні служби ### Вважайте сторонні служби (backing services) підключеними ресурсами *Стороння служба* — це будь-яка служба, яка доступна застосунку по мережі і необхідна для його нормальної роботи: бази даних (наприклад, [MySQL](http://dev.mysql.com/) або [CouchDB](http://couchdb.apache.org/)), системи черг повідомлень (наприклад, [RabbitMQ](http://www.rabbitmq.com/) або [Beanstalkd](https://beanstalkd.github.io)), служби SMTP для вихідної пошти (наприклад, [Postfix](http://www.postfix.org/)), системи кешування (наприклад, [Memcached](http://memcached.org/)) тощо. Допоміжні служби, такі як бази даних, традиційно управляються тими ж системними адміністраторами, які розгортають застосунок. Окрім локальних служб, застосунок може також використовувати служби, що надаються і керуються третіми сторонами: SMTP-сервіси (наприклад, [Postmark](http://postmarkapp.com/)), сервіси збору метрик (наприклад, [New Relic](http://newrelic.com/) або [Loggly](http://www.loggly.com/)), сховища бінарних даних (наприклад, [Amazon S3](http://aws.amazon.com/s3/)), а також різні сервіси, що надають доступ через API (наприклад, [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), або [Last.fm](http://www.last.fm/api)). **Код застосунку дванадцяти факторів не бачить жодних відмінностей між локальними і сторонніми сервісами.** Для застосунку кожен з них є підключеним ресурсом, доступним за URL-адресою або іншими даними, що зберігаються в [конфігурації](./config). [Розгортання](./codebase) застосунку дванадцяти факторів повинно мати можливість, наприклад, замінити локальну базу даних MySQL на будь-яку керовану третьою стороною (наприклад, [Amazon RDS](http://aws.amazon.com/rds/)) без жодних змін в коді застосунку. Крім того, локальний сервер SMTP може бути замінений на сторонній SMTP-сервіс (наприклад, Postmark) без зміни коду. В обох випадках необхідно змінити лише налаштування відповідного ресурсу в конфігурації застосунку. Кожна окрема стороння служба є *ресурсом*. Наприклад, база даних MySQL є ресурсом; дві бази даних MySQL (що використовуються для шардінгу на рівні застосунку) кваліфікуються як два різних ресурси. Застосунок дванадцяти факторів сприймає ці бази даних як *підключені ресурси*, що вказує на їхній слабкий зв'язок з розгортанням, в якому вони підключені. production-розгортання, в якому підключені чотири сторонні служби Ресурси за необхідності можуть бути підключені та відключені до розгортання застосунку. Наприклад, якщо база даних застосунку функціонує некорекно у зв'язку з апаратними проблемами, адміністратор може запустити новий сервер бази даних, відновленої з останньої резервної копії. Поточна база даних може бути відключена, а нова база даних підключена — все це без будь-яких змін коду. public/images/attached-resources.png0000644000175000056700000015517315226251677016352 0ustar0000000000000000PNG  IHDRh pHYs   IDATx  N !jSQQQQQmEŋJ\*kTQ *%*%AԪДU;>;{sv>}3wfgLLLLLLDA+f 4&`&`&`&`&`&P"정ȁp3LLLLLL00000(vJ@&`&`&`&`&`&` ;h%r 00000sLLLLLJ9n A9`&`&`&`&`&`%BZ7LLLLL000000!`Da&`&`&`&`&`v| @V"000000;h>LLLLLLDA+f 4&`&`&`&`&`&P"정ȁp3LLLLLL00000(vJ@&`&`&`&`&`&` ;h%r 00000sLLLLLJ9n A9`&`&`&`&`&`%BZ7LLLLL000000!`Da&`&`&`&`&`v| @V"000000;h>LLLLLLDA+f @vUՑo݈6(t-6u5%K?yq&u598/ IVvU:.SL Pt'4uݐS#˵=V[ճe#o!9I;i%gB ֗ViGMLJGJY&`&t̻#svaAr 3-sqhD 9X?  3|jO֥3F z 9I'PH՚ c/Y?HoX`pM60ГH @%7v ІA| ??ě*XpNAZL2N%AkAFGݐ LL@#hEU @ ,Cx)c’ؖA| Qu3YؖO2UhF^|/܄FKP ib&`&PvЊk10v%~Z G46 ^ANByX_ie5:S,uR=a{uW !tѨhXpl3sHk!}f&`&;hy@r0h94ZTB2w ©yA| >$aA##Aq:RQn:)T*zlj2_u8!Z'~"AH%a `- @'"`_5W"/A%M!} ?.#gQoU4UA~U>1k "*TشuD˰ g%~X^D;!9+uFHi䰑o30H tFta"\MU Q5Z% cq9V/p4-FG[_S,S['s3ieXb8[:.u{n-Esqy m&`&`AY&`& Щ>>B"}Oh?"7!n@hj`ԝDOHx hK#d4QOeǠ*)rD\`A'2Gp*']-׹ q꺡F @@/ @DD+ øNViGM p/}9t_۠&}>iN~ uBr6]W!HSj9e `ޕ ML x l&`&`E+ۖc3I/ݻ<(Ou9lT6* 7'42zqׅe2uEq]&`&БAHGb&`&`L@v15 UzP65J*æwizd4m@߲>:"OIC\F^>PtoiH6EHLLA+Ƙ @[ɥ/vZ^i!ѳYu$gLG!-'nO΋?q9.#jٙWh$_,LJ>iHqo -E7"GԤQo4iyM_;ŸҶC•*\ɷ #M/ϱD~E8U#|k./9#jz /GH/!&>1k#dsh60hKvڒe&`%JN# ꠪H2md^ur7B#R:=NF&ĭƠ9S;FEԱzhjt quS4+ިKD|2g|3:}{[5$Qu~ sSڳ{d:>&g:%z ld;uQҁ >;h[00r ߧVпІC$ Z]>)k=YN!MImI2a[rN^#8s.G10 8iсQRN!ezG먨NTo t"zdJE,H$ȫ"=!.a⡑3{ @a=MLPv %&`&1 )tTDorvXq Kx= ћd덝ni2,wQ~W!|xPCGYm`+OzWɖ@$kQA`dVOs>|@>zB:~6IU>^ ,=2F],}>a;&#=8@rf5|+l&`&P0Ŧॼ @G#>;?gѭi:>@ DZA\L:,ymć8nb ;q^P#1c"ţq: pp젎8˾nA,_߂ ,@2uX4բlQQHS&=NA-КЮ(>NKYiJV63VFl=HNVw:aw3|0ALrKML+KTІ][/:7ƤWMɸ($#'B_lZDƅq&A\{?PiۊD]br!ALw^Eh2ڠ8?}AF 9ՔIfO~trCm1ci&Ъ젵*^Lʆ[.Dh=4D=ej#;xa%dmB},D#+*MщGR\vuf..K3brB%/]/!r}4 ]Q.Ox N>8vE=r-e] CkPΚ yD<>ߖP>h6 " ?iUp @"`cO 4Ru:wC7 9\h@h70֑':>EZ~#s38ɉAW!MGSx-}lOh?"dr"C~ڀ'B'lrk$'ln|,4vtcFۓͧCнHrWGx,.mވ"9iwuKH~m'%-&Gİ-B60N@@/vw. @~izSeP{ɪ hYcY vīRsٶNcF@SAun(7tJ5erN4Qńb_ֵFڧ+ahc/L#hwGgGh >NJjdM6ԑL:8|.wLLC{F5bKۘ@\iiǪFbGF6R92r?:)F>EWXHHPEr:?D{5Ƈ+WmTL(-!9[yD\mk^jsΊ2+:\t @Y @+*#3h8R(>Da nqVZ `8Z8TڒHHОfE#BTyHtt7Ml7c} zF?~K(FqF*4]R("֏ҟ(l\L4"a30v'@'AӁD G}Gݐ:SʚHӘL: cnkITrP /Bc+͍}tF]d&9ve7Y˳u:|{ŹD"cD֗C0 @Vb1@@t~}+ xh QC}QRO"FҴuP#af&ІiCޔ tFX` 6y_7%qhS;FЈډNd30pIh7*փ+d3]H _D?C-К]]D;h>4{$T $uwu}MFN:lGf&ж젵-oo:# iu&:hzҫ'?àw%n*c!!JA)ڄ|-c30 p{k"M#"'Lb䘝-DJ=BUF?B6撖C}"ST&G/Zt=<袏4@3 KyeH# ][55HUwF[Uhl&`GZMt o -@/B62CBоh:W& ёqz^M:/ql9>n齵Vq|.02~`J8*ʿ7 tا=]R'~H6 <&`-#`e @@ }w4:r ЍhoGWdl74t @,@c%|$=G]kJTt7J#B{,jJQd Y]~Mea=KbJIg6q >.ph&<+4o1/e&` pS@ε*=qC<^@?u%^B@P/8/ T^.Bc)Sf&`yZTG>&(Tr]DZH/ ?4+c# 6ӷlgZWW 4f&`1nzoki$$;nyA );erz+ @5}0V>he)4DZH~l$m-ӑ%u[Il/d@3 tz10JF*\C,Ҩ~kG;Њ,>`c{)çGzr4NAײ*W*40 Ҏ@<^H#SACrWiGLXQhP_Fhzc4ڤ 6F#\A$!%h} ldۚ1Qt=ڨ3L x#&`HP rݐ_F/0h dùJxR"43/B ꀞzL''"uLg&` 5FS/@۱ h&C٬'-HDZO@h|-wW&bG,=ӨbG冓"Ci]Ah3B#hY8:nw?@F&uΧ\ߐSs)/Z|Ey?DMBTWj֨갨jcdơfZFOdg+m=NyeP#h G˃`z-іQ092z 5 )4$Gv3AhuGў1?O IKu摷9ڋ:I_K\N_@\wn'O tjv:Λ p<ԯ} iz./#X.hMQHOM[q8qkr)/ 67B#9٬HU'?ʠAZ *c;!D( sujf[!hYIYwQy{}H m0MiH_~Ӎ`G4yGTfvD?&7;8uzЃ^l⋐bV",|mыIHFHO" uuo,̾hr ';Vm}9A};h G˃28T']DЀ<\CH\\Wc=i׃QMƚ]( >kr`:Cg(:,ul&`7אFCo~~t] 4 Evutj:4G%ӻws|䜱 t!둓x cMHy60(+\ނ8BFp`q}Hq=B=z,j+P;H|mH L #*jh#WYu]3eP#QEg@Z7E\F!xB&_ =D|=FzaM7ezI;vgHY5lZO{Թ Ax!-MMuv pt]4 s7ֵݍ}"= ?W!ۑPEw''tx FgRiDk6(;L:6ݸRxB L75Yg]3!{*)P7Vq$ sH䜱^H_* vSlΙIل\tc @%jcCr؏ظ1=`;mEއ#_F]@- 䜽"6HcmB-hyˮ@n,ʑG&'nZ[PU7nB=ND2}~ uo"'9=K`$w1ZmL^5au `R'#}MFV8=Vއ0c9F"=%TT|j:CڷCU೉Ry$&'qË!!jZ2br1چg"uѹ@O9ʋMy*d}LW2y:ͨT˱Umm3(S\45mqnLYvAO+fAH6dy;ؽVG o'QQAƲ&< mbṔODb.60Ob{9+I\_uQ(md$fDZٟia)ͪM$wyGEߏ™,'n-Ws*EW&gGPZFUYj(LeZ7LIhjwQ-#+t)tִFMQ\B2g"])c}Y#h"M{|^!_mCxEgZ QmV&`&` p͜Gt\]54 E=P&S[u:"{kՄmjllpI=p}p#Gz%G.298}%Xߜtn'+!0x^~LqYY*.?bWGZJtm&`I@7!9hУ\nZLN+ i HAѸ D4ݩ휱Jc6 B膪]600f:k^uXN=ӵXLkH\rx).ƶ5+DS%6 (Eˤ{աHC9::vfh El T7N_'͏q)..ؽQh.r6QM8${gBzmV"2臞Ŧ33n)t X(7et?te3)PLL 'uK*q}V_Oh4їańStzͶ? ߣMI遤Q3<A#w;:."=P[6RFҹ#68U/y$w^c*SL\eU9&*̵_sќHsͯЊlWU X7MO }3郑.'iף1zLF44Kt,O|c4F ]4.j$&l i*}z:Aa*H;j%Ox!L y\87뺇BĠkt4 =̹kW.C/ӦڵAE8&d0 U"ݳsc).S[8T\q}(^׌QfC+>i6Bzp1fHBh\Vc#]uAzgH#f P 큞EC_F هH٧\\dRSHv BޛdEQ7Luy'"}C7Z%7)vКr]aO4!)B%fL=vkD6~șDWh-fjh T[(6BuKQsMH(J_Zs36"𵄇ɉh$G@95A s33_ދďGָ=҅HeI(62q:B(SVUeTR=8nW8MEsF9k(E%uP/g'`T 5v>8a-Oѹ/Gm+? BObLG 9k,ֵpJn4:*=@;F63qgϒe9?EEc#+At&˿KXv0'Ѩ{†%$A_;hey#oGUT,B[DXcFs2kmD~xICQO-K9N(˕Mu D7cC/"ɤ/{`L|1Z ~FݲHJ4h'Drԁ{驧7q(R#Ȟf=uO.8 Z< Ҏ@J4{Zm> u:{&c?o&= cWieCvAh8aùyYW*UѕLOXlZ ?ARI놨G?ӔI_#fr.!8]McI@ 1Ӎ84B,~2iU*|A+67 yl'Eskҽi$㖏1~PG[/c,ͦP49'WE?kwZ1ԇfz=o-F@ [t\=Z}&ϠFϑ:Z1[FxZU"mO]\ơM,8HXDݲ,t';c_Z&/F]_Q>?MDr~=$GCDh^ ]-LVKd ~-Jg&`&`S }(K# 9aUe^&rBGl D3| ˪C\aUyei,܎Zڕ:XN%yz@5B hxhǵ(;ed.{g%ʁz З MLLvGc4$'&&EߞB?CH) q9|M/vrhbى<';ID:Li#s\PUSoDa^蔅q-mB)z 5H:/c)HN 4i=M'S#r Lg&`&`E{O 6۝^=]rr39i² i';/]Hv2Qq 4M`2U`"磴) kMNڏM[4Dױ[LVCn^Lg&`&`mM{>/9j6YM97睉Bc=4{ը).%$vM['&9Ї;hPrb}~ULޟR~lSHڄP^S?z_DcQƠ XiLLJY=kM&Rbݿ5f~sYQggI*vp;&E8)=tB).ǮqAF۩@Re! R[>!QSHg300"k> z[%gb<{~29uo yݥCc %=LO2 rNK,}j. FjtmH؏4tNE|*X,4Do)]jm-''إLM !:m٩%= D7VD1g뻜P3MꚳMwJ^K#c:r0Qz Kzkk&IO6GKrt5WOjơyAGRq$K!wre@pPik_k}aQ鋋{r\tK\jh %2#^M,9?3IAя+7s&k+/L;OCuix&`3YƪtaaNMM:h _Az4 EQ&`IjmVhŶR>_tsLJ=B!~^ZsN[j;هužHyiyR틷QBұ3WM<L3At-y-E $i:/4F4vz>$2fyj_/O.7-mztQOy60 4zO;g%p\" YKLʂ:ԪȫMRꯨRԇǺSIugj(ߣx H3 ^~%z8AL vBhbu9j4u(v`Eqt4~X:ا UDve:,LIJˑ,ǜHU1hW@hzC@B: +eAy!y%4o63s4itKͷS`$`yv5>.AYumxPEj51B @y0Mz`306#@顳6Ml!*p7Lz|> 5Km6u'N*9c=z_l{1quY5Qs.>TiPmCit X#=A7,_G>nG)iwQ:v#l#14nl*uP5/T`ꞀFHb 1ꜳ 5:>Kuw n30v!5H}<ָ\'A~HP>RKj NA.)+ ]aWG[e$+ަl0HE:+PH)B1R]٨ i4'HS6 @P 旯e_ tz8v5.7:Hw.EDt7۫Ue&`Km=嵐'oV'9LZTPЗkFun(Q2 {Giٖx +7f[?cYVSPl=.-FFADQK׿uT8du.p-a[ꨡqdᙢq)L~ABl %9rTu4,xn "mS hC;/;dc8lVE18 Er,,SF"0!:*"9g6ywF 9k3wWGgLJ&9."em5]uP}LdS,t(j8k@(q|z΁HPȁV|5pw=M[;d(6&<= %٘osޞ9(VC뺦{W##麢&B1q]Cػ5_)Ӟ @ rkƣn9Y R7:$Ds5  &)95TLmTh[FLe}JRG7f:@FI9GUNht :Ioo[gk?Gz-˴5o G!r41fucE600h6r-ɍ ʧLjODpǀՁ!~'M#K =a71sC#p%aMt*cvG3Q\XNE:Cv΀ak{zs5$ћ0 `؇9S(k<~X -t=tOh300fqя^l 6z!n 8zإ 6_ LL &A259 x7)wkTm/vQ#jՉ]JZ#f}Pe16zY׻r?z?^H@m&Ю8wр;P0ANڸ28ahV麦iFز߃t4q0fD#Xת600(@F5֤nJ N@c⇠df<uDnQ'IӐ.iYGw?zuFyzh}Wӗ@{`ۚՑ>T筭@p=m'qtҢ# ;nKzZ ^g]LLL o5%D8K}PMrvv EҡQ'9pi=ۨ_cEmڨ|)f|IA Qu){ITǹBkt-#h t5g<<_00ȏ@6-|Rwv١kq9ɜl$6C:J9ӨAlő\!~OHd6^|13-;͎ @3 rqumcUșT6s0cLA5^U_3?H ~sB~>Rl&`&`&7lZp:AAZ;n9gIj4e3m82$Ff29ђLg\e@GlQV(ʶNK9I{kKAF٦$4dED!bgB2Ye6LLrШ:/uČKDS./M7֠KJEрn2X~H?Q dynK:~:$3!<'@ &ȪNi$F!S=D HΙ|׵=LLL +|n,WVgm ڝ Í:)h\au ]ђmD$֡W7YwH`78iQz$nFzuSx鯗_7f&`&` :BOx; vL9hhk8u_+:XS$Y9BwE5o%D^ _q.ȢɉsVw`\1kdi$mu+PS5z%Dy'Fy?"o> R>EQv;LLw-\7 usJuOuz]֮Xw>Y܄lΙ: vbb[XӄiC{r֎D[UySw,~7X!9ik4VMr4GU'HR 4"ђEOBnXOo8@zMSwG>fhw-y b;}XĂl\HٹHڊ64pNϐEy˪(,PG\?q]NCyC#gAO^=veo!+ @L _m 3z&>7gثb+QVF4GN:#=d&Tohl$iBtp4nT l "b;~[B;W$ꜩ;dKshp=@$oǬ5f&`&`iy9hLj,r 18 {h0R`B/BOI֛H/fDخ|h5qmx9(9fK8h:㽜j>q"FlF}]d`D֡JڙANڄD3t-kr$ey#S7bۄ*HAG^F :LL 0qsi\Lxl֋QTeձ|[Kh+cU[!9 k8ıYBѦ>߃Ԧ,|(%+&Pͭd44e+)0[8quIr%`u3eSg*yuޤ-*ӹ3+Jߒ{+ @'"н9ME7AH\փBiPu'/kB[0S 6F@/PScS֠P芒ik4rvƱ;h uLY~FHFӺ5:trTɬψb>^J Z:i'h{gmN۔&LOwT!8}nE600NFYZȈK5 $n.Fqoyg}Nu.!#NOlCvd"zHBP[b6@Qâ*笥 ۦJg@sWWMu 8?52Ѩ?% IrJ&֝6iw8 Eka}D"{: iT8j +e}#&`&`n,E3nrn *P$'IeChQ-FsS'&?Ů&.[-._ڧ}gݘ?+iQR=R e6Pَ5j?mDZBڌ6v,4ehk$)&Ne:t-(^JZk pl ޏ'1 3/}9Z{~;(:rO&>3D~ t<qsR[=ҝacQ##Gm(T)R%hqVGqoMau ҹ}U.OVZTڔl[H/A6%t G@#gsn!CJ$9v45r>IӻfF_ URQ|' t\Ky׸/Nn\rö^W;Kk_/SVjZIY5U#mwV:6!@4mמkoHS5QOךd pp {9"?tSBK^V/^C00&VNJQf%F6yPߨ;n±cq əJ̥Ni{|vNw\vboDr݌!uȷ\)S{tL$,S :'vª{GlIM>Mwd9 F&gFa3h#_$כmw9 u(Detx;h-=Pݪnz @#{ u2nׇoQ֑}291J<"Dמ8axVq5ҕ8x{R~R],9})AϐFi/d}ױ̗m&`&PV~Gz˖__E4ef&`&ИdiJn!G59r2{StnӎENjq\gWrҒD· c=Us(R'F^F =T7um&`&.&v4. ,[~hA<{j&Pn*R]_Nrؔ~#ըnA݃J94JGr|3>Zh%>G?f_qOf&`%$T0\otW[Q~߱~$GEM?Tx%d~VHnx4բ7ЯPrmEoOЌp]VGm4h3\*nNzg+k4-|? qzf9Moupg9i;3s, WG4Y #f֭N 60hMD+ߑkN lkD{,^nyocHHhDVFz]ZY.7LXDͪ5NUn(ޏU>{ ^U~&c^ߏ4,px&CI'm,ys?D$_u7;,7hU% @kF<l(bLrdrSV?ҦLcW <{?"(B].fzuS7:A+ƚ $֥xDb~,/:r'8<';|v36|gώd]r ": m&`& `ֻk~;A˗Qe+'/ q\꽉>@C;h%@0V"s F;"D #aoRq;1'v>:i79`:j2aI"k960(*3ǢX3C{c,"6d`]6=L-`T/ƅA+ǣ6 4>H4`n* ҔEu~Gf5ϣPˇ6!a㝓甜4{5eQa=(y˝K s/Fͻ660h)lue3D_FFQ:%[^zd(gɲV6 5h n|S Fc~J\B,h?Bmc/Sw\Xk46餍"!Σy SbB۟CWt<ꃖPS nLLuD>MtK L\?*jq)v&am/;dn @2:h.Ğ&#M;rUW'ޞCFF=sM` ii"NNsBF&'m(94}:T=48}l碦NB2uf^Q|-\wTd30pYL='p(|oGL'kR8N-_Um+4eJ>8n @ pW*;l9cÑ~G%EZ]4"q8{#W>V4HT=(Sx5z-qǝH\D!Q!MAz] A++f&`!`P;<q(Qdl)SFl*5^,:ſ{6;(r x:?s"i]46JEOG%.{H#fPFc=}(;qM5ӻAFζ%4ƱH-]E^PSd30<A8G5=RNeUv=2=TcIOиtցwLy}td ͏j &xJ!^>CBɖmQoOt2z}ݏv@;)54R@t>zbwc.RuQ3Y\?Q憐@4{Q29iHvz+Q@B!9jnR\MԕS86?f&`&CxOLlt)JLC#]hҫ݊K>T+%3.V{ ]{9iN9b@m&:ipG{NZ6{rEovhi]$GCvaZrҎFG*f&`&3 wOLL|@ѪhO5b czQKMBj-HhfN'mCfQlH#з!4Fm&`&`=@Z@$MCO'.6@(MHNlhkFMJ+M4!''djŌ~rmv~ rH>USLLzI N L]@>D:ڛ ;B$_$я >ר݂iHPLRN>7馄W Ďh${ =#WLLA螤 @Yسh '"4K|FaO}v%N@`{c&'p~OmBۛ.L#j]^{}җ#䰙 s8|M-N${#}>Eݎ dhzr| &!FcNFy31(=[0(g\l)i\fA݀4L鏨g &P).vҨ AWȖ …Hb&oM7f&`&Aç/yD9*?NC#=/J/N]f#jd.*V& F@|/.j}9"_",Q?unF c;vS M}vIyg6?}עH_9=Bف600n$P pa-Mev*k;mئHZaƢlބ^H6GP&.Qއ J*J I&PqNiӍD=xXBݏJٖ}k'y-$.FR_7@Zh GLLJڝY! P E ]5YCڱwd.榠`"$6d^K"LN\C&` \Mh21zK_ӅӨ-aIuZ T,כ99WvFF=/L#g }HNG霘3%r'#dLLH4$dM=N,=>ؤA_oÇHo$6^692S!YQY*flt访Ls?z~19m 9hH?Oר.yߍ37j IӬpҔA;[c N#g۠H#H"aΈ'3.LLHЉdIwd VYd ~0=34- ydp~P0vĢ%~%tai39VhL ?VCOOG'kG%3Iv(DRI\lE;iZ DB:>.ғ&C(#uCO}E'LLJ"P~jF`D*_屽% EthMᷲ|(\l*!GeraNq]3=.,7M&GXG|.5ҽ-(@_/F]()}N?=^$՜4&6,'mknI;)?C(_ΗBHHPILLJ!P,0z2XTNJ(B3 NH84hoq GCOu$4 Fz$+Q(QBVDfUOmy* =J.lki'H>tې^hCZ# ѝH7,f&`&P&L#Rz7LL JG*Y4Wyqyt :]d 9jW!@tZ<)!Lm?>~<f̥' 6MVF2*IBB۴sޢH4ka䭈~N t@6tnIftR2yOmF)2D[2kRp T/xLl>?Ex)韣H^J>BS){zR~%MwLh@]` GE4և2wgTq:Hi${%ǥٞfOe @ TZƧghM7 9i齙/#;ge.@h,`S]Hbǣ_.GJc>̣$']pN9w6kMQm'w-gq&y&6CS9ǐQq @ ԕ= pOqm}PDUb?΢ޮ3Xl FzEpN0LzF£x|$tZ%EBΙ29gB,<67%yN@`(I0•H;H7HUU m&PO'N8n+ʨ7@/&`B }Q2΅M:z4$+$P4@#8i0h$MFdBz/FWudA5l3`Xsɺrp @BQs͏6ȇ ˨=# MZȜ4=IܞF{i';h\ѓ*{vkiB t:?0^ƈn$u-VrevbD tTf 6(eLfz}i>bTsL@W!|N q~G=9fzQ>C!$)4b@j]گ&}B!zN`'&KD:kvRN t=T; 1e)v=hwvV&:Oʷ A Nn3@ HF 3#@`{obtMNڵlwqKu=~z`5Lf ]XHO8aN:ή!̦eLɺ@y.Z[t\֊VTQ =qZ P1݆ 8(/Q?rH ZNRϑ̎{9gMHU{G 6il:gGS)neߘN]08)#e^IyiA;h)MX:mNAOd'-K'H@ơ(=хb:)nBv 赎y*Ai8.6HKRl7=t};KVFYo2_gCە: @q1IsIͻ׍]k\E\_tCty5 !@`_#v9MbLT$O77g{ΤV~t Fc 4zYL`c.%W`;$]x4їoGh]4_HIIwL@}P 0.۴l>+l6?F6CV迱F!9mY4LG)~V$փ5WF?zt-c:Fvzw @gI;Obh_At*h]9Ӊhwf&׎`_T}qyb4 6E/mP/Jo8+i]Af5Om]i{maxLNkM(뉕9LS#qug_1< (SQG&ͦu8)\RB#h%Ǧl-p47b )KN$${.z(+6GzG:_'&'f.qNm5RU( i_~)oAg$/ҍU +\&VST zGwh&P@wtjs2U: GMhs#leiG#9]ׁ&-t]f#o 7`i3!dz&E,h_ڿ۲Bݬy5"]i}?4Zȳ@]`?L9rX);*GBC]d;33Cxʺc# r@8F0= zE>"}q}Qv҅Fm}j H< zO4Q{'m&`@0f#v4WiI>Z>@jw#F tѝj}ʳ O}Gղ! u#Dz,4 5EI8#ƴb LVt{iS?w ~F?F! _jKΙI9bS_vb"@`9"vҴth;D7M^9#(e$鳕o3hJx,/&O}AZ|K8y[5da;sshś#LG(yjt @9\H'>2WP4mֈ.E0*5ʋZg8n&P7vs)=1.E?Y"_΢Sq @ɁknKЩnC`Bk( ^*@Ԝ(C^ኖh8UٕLL %[Q v -M#iA# zTIja2w=C: M4 rtA5 rҎRy٥L猺"9_ϴV`Z/C90(3Щ2w 60`ZһN-IE=DZ.X^ K gtf&POob? I|tҴX!*cϺGgc"Hi " @g lIOc/uv#'ͤrζ%($Jzf&P_ қ*rAF[=$J큮Co긂BF_%=B $? IDATjB@\#ݾ){osQ%gm ͏1oa!Fϫm&`UD6Hݑ4cI GFc"}Hm!n30"Z^\fJGCH.^%"juF6(wZӝQ4y,d84.Iӻdȹ4)h3ѕQ%rң~ LLAU2n![/.N.t{w9FF}9er'[<'MTfYOu(hrgit]h_t,wl&`&Ps*@"}S:8r)R?#$nL[Yvu3hsi @`.^Z#}!{M@os@zW-wULLfAU1' h0%.N&?z!yi[!q_ۍQ{ @ `aбXԄAߛgs<cNxLjX^Z\B#El'HSi얐/)It76sLFdNf,FҮA4N튮C'ɻv(HLiLL*yP%L t_0"?cBI;CZ6F>$;TjN T3.dcGQDPu8c^! QC")w Q60ZEqדl& D;RTt#rEQ[Y#*~#53!#'-Gw=ǚnSo=Xqh(:i_$L@!mVD%i'']Xɢ?=_IwGOWNMcD?k!if&P'Ju8hEt -Tp$2 TwN`Qu2${YMCNjvӟB]LיFl&`uF s6b4IS[G=ۃ"cESh30%$V3NwEC&GFBil ktLw(7b[V,H#vh8ۀFZYvMQl:g8n&P8FeM7o8 Ό] &_ړ܍D5¶1ҍ960yG8{/47Y7r{jv0(uδCa;g"Qƺ~IR[6ڙBΙ ף96vc3z'@z'-IFґfdsghrYV雄::{XL@0 yI8x4P%p-I_巙 @E(A sp0q! zWi (ۓuoLfC)IOI:iTtQ1 \~ i҅Q|\Ј>& , IH4nKݑF@ǣISsh <ǥLLtA KP#¬#6ʏ!9n33h&K]:Iu2khhACkXZ?6h@=@E-"u)!á GI)NK!Qw i}J7w" @E贃/ =9 F&aWB `=:j@rʔV\,4qg&6ٟʓ1 MLW]vM|/ v3 D!/u":_6wy#F_LrAۡhS4IR8'  DX̸sJ+†,ݛTéh nOtL l ÒJ]9i&`EHTl:m1ffi;+7'i#]֣^޿ Y\_0^ewؗ. E*[@ p>q)͙<=LE!Qd('OTWVHtd CZjUetRі'5m&P4<2i0mLG60(+;夅 ӇFϞEk" EA:760][RkE"j+\C9,$@Y KG%Cz{9 @Juh 32ݐ%z6x5:[%G#m&`&czA˷/m,T!BMQ>B t90K ƀ> wLJ"17\L:ҍIHGdH8tɎGk&`=CbkuϣY6m/@7"]0Ӷk{ @s!tBrҦ&ys ܺZVIﲯD? Y0vUK5!k#NrϤx09}f uq?F)8q/EmFA`ѝd؝mR<:Cɜ/S-i3=d840"qNZvs2PO <cڕY0V5u+=Oj-r^G}-ݍ7H澂@0Lm;QΐL@N^̟Fy}=/5֟cۄ60VKu<10J%3&L6=\DcL9 @wsI2MhUc"I9;&ӣ/ mHLL{x{8{*&PئL]}nԈb; ML; p:]LS#{r|)o+҇fϢ˴f&`N#hݎ4"FRL3ѓFD;g1Mz!|L[Oض[/y*]Lb 60#C @e"&5sS)ܚ ݥ @84[=6'l&`&#vO*&Ӭ}9e^e,Lxkzܑ@ȗ oML'Ǟi@؅Y)9\G  @%ţrn[A[ 9g]흯2}Вʜg&`"`\$ݏ T'1m}~Z_xl`;W70.'N{ǭ64UnXHd=׈| t;h]A}@C_*щYDi?mL@)NmyH+2Y3ʱnmh*1:lLL$~$|nlKcKXէo/750.!1N_q?b;V߳89Nۥ2K E,oEg30ZYq3*>F}2B=6 ! @ A4:74$s.Es3 Ti}2:1K[&GNض9B/604?itnhUK`L|(.^u Ta3}#="zmVG}|5/ֻk60hAk M6p0%-nv"* %zz@_fLoV #DףrnF9;:z_# @젵Dž&P3aIZ҅>?LL{Mƹңy(8ݎ$GDg'k|60O8\)\<݈~΅šZ8/ K݁Ŧ5=yѶFۥ(H*asb=#Vڷ*p @]VW [8bq&`&QqN:Llc8^Ch=h(\@WȡFq&`GZs/ @;Jtҽ}n_=$UB}szOmt?" 1;hu&`&`&` dN8jLjqGO‚Fe)Dfן].Ff&`K#!LLLL dnLևCeP)zi@(Ǯ?Zi$l&`<֌000hMJ_#i`8Xrm@6Er# @+vZ!qF-D9G3tRZP'~HB~H+Le!ȜBL 4xOLL'i~iCg9i T;hճ<pғC5Z-+/j@#Ǫm3-Mwj)lBrBNLL@靱I3ǒ|'MLuNr#="jȤx:^zYM\pѠ| @pNnO1x{SInK#!60hEZ+$I0}9bzzPWNJ0]8 iz><600茓FaLF 7 `''!LSΘNZ)ӉL|4'@S$L B" ՇLˠG,S<aUhB//e3qx MC(Al&`&`舓9gg^v&b0:$`WzO.2'L;$ )с,SBzfbˉ*)9&݉M|m&`&`yp>S"ە){>(B 4֌‘ I7! @ 3&afYMh'79cuo֨[{z @r!9x1]d܆&a=3 2|%˨[{d&کWOf&`5pH$ǡ#&l:(8)I&g+h]-k5m&`&`(}@Qd)(l&`1 J$ɩ]);i ǹW i=mFԀyT][L10Z'PIkoO8zf{\n&P?Ϻ%.b'LH.ې"(V!X-ЈLŬ=u)f&`uM·^EM." :;hx8i2ֈ.oD|BwSfUBk1f&`uE㤞:AuRy Nu@V+ЅL'9yʝUX}X=s(7[ILnFE $@V@gFQJ.jہFN5z"Z>Ylc<'ML& 9Yhm~&/ OZ\#s G$n+I&`&P8R.A~c k60:&`W~'==Szf"R!}/-)vLjN,C H.AKa&Yv:KyC=@Q#𢛀 8iЙƠb30'M@cA(v ;h52{pQBy\?6𤻑?Iރw=)08iwxT{jEꕀz]]Ca.Fu$kO`Bf>fQ==? Th,3GSb0%`FWl/p?g Ǔ/pytE>%v&`&Pwp梓XUѡhV86(s @ V+D39H뽴`M &`&`ȎQ{ ʱtZ @-( 8ڝK?(BIusFDh&z:HzhPr,*ή>LL pm#8~F8pys`RL xWJ%'6GͻN,vBQGlr4E?䵐. ,HQx_YFې>-绠e\`&`&`&`~0dw+siSb6mZ}'sM&o,Ofry$w,@|!ɲF,fVg3000&vк ' ݙia#wzJ#=KLSh>ɚrʗ[-.¼>\Ǵ! yiЦܡizc/Dܟ @5@Mk)g8P{Skdi9029G Yg!̒5隅fdIGǠ`3000 #`Vgg%p&.8n} {J&$GLwf3 T2zyCGC#AzOje8pa>r$ȅ2ŕW 6ڄ$) IDATKzUi4LLLK dOc":R[:A*ɔV~,\sbp~T:-"sgve90'f5A )2N2N4jޠғLH8R0,(p,(LLOs΃*Y(J$l,NP}iu3R'0lCẘҒl&`&`&PpR`B (ԍZ79Aֿ0ZDnuANy\;f]NZ#LLLL{dhk4 ArHzpX̒LM;ZۙdJ3ymJZYq30008 r-ЦY|aWB:)6? rU V:~_J*ĢVP׸b!UhjON42t:2MCeS:C0;hF&`&`&`&ptݶ)5fq9&9)ބʫ?5rq SIvI 5Hak3 A++ @by #I$yԜfY Xp ִM-`ƺzAz#WzL.)[ IZx\h&`&`&`K z]mF]QGFR_44=(c0Z@Z/zY8pݖ|L$MLOfAk&`&`&`&2'|_4Qo C3VF0Owb,5l0 Ѧ BLYj$`>׻LLLBpQcѡH#5m< 5 #&B[Fۤ e}ES(\Kx<}iL c0000\d/B.5WMHwr?VX? 5Hq IhEZ#T-LLLzѹō(sі\D'!;g&c3Ѻ<4/2hDM]S:"`VLLL 9c.Gz,5VNYJJӬhf P4+Ϣh;iyQ:Z^T000 ps12EFkr;Y#X ѥ,Hdц>+sAE500Y40rbӨF\Cz\"^ade[fCvp{MLLzLY8HrΦ Euof&KOvNA400 s<'ۀFNcl9^ T<?"п&T6;h~mCi5^BXz/?+ 倥?m~ke=IOvh; A m&`&`&tn=yiӞO DdWANZŮ~l):mkmUp tLGNdc7Mӓfaf&,͓䪀*XI8r#Z+FQ?"$|<1.Six+L>G 5D㻖zt!!Bx!dac/#w`e& nf%H"Te/҇J9:WCϳ!S&,gLf lܓetd>kF Ѻh68o8Oeپ5 ǠVli&PoґoR.OkD*G/]#BMQ9fFZ:J⛜L>hYҁ އFR9^D}h3ʷO4.ң? }^]6郙d2Er4_EH_hVTyb4x BSQh]|}k<_U6ǐy)ZA+^\`&Х5sA49jjY\~Y*SZu+tikuÜ,T)K.ʳ@;733'[wDs:mhBvN m4賣]ǁQn" :iD6[_mlQ!K[/_۞̫̪}rK(59k릠`raCHTբB V9YBQʫ:g#3=9),Q:!лNӋi&`uAR,dauA86ۏz'r׈L:EcF$ @ Dn30۱(l=0爌 &`&`&`CZ ω I'p]NzI1?RZCYHW/O@=^CEh>v]f{.Fz/CF]H?CCzD7/Dϣ"OݳS$FbsZ>\LLZ_[0(H (LBzU@Qc9G22Ky?|5*er>9<}_?ӡG4}BT"1h_N?VF޻5&:箑I}A'rIʵ.lbHRq&`&`O`_/ @F`_/"gRPDJNwTKWx^ۚ}mU] 9B|YYk$yIY\3V#iLTԈڳ06 bl5!+pLL Au%00@ Y(OiP/KK$CYHW/*?x r80iԫ=b;Nd F/ B}mwy⚖mrHN.?Rգ}/9`‹BB!I}E`&"#7g30!:Lp{Fa:d0oWy}(Q޺(JwWt4: 퍃w-z}B?ŶV`Ik$.+D6޹{ CP) Ii 2_;?H,(8i {3/R_54-T"C/E齈.JN\ܔ@/f&`&PC 5QqO%O2ϠSW]{43*LWT`9j'""DeWԦ$VM@MBq_;EOj?^}MT[oP:_}6\Z\P.j~p"}$D89,~wmD|ft:ڲP#d岹:z/&i"kGFeώ4i00*'z !9AkK]__&O轊z**s}\'/j~C8mjfH|v\xmT6vh\Z<}ہzC:4tiaҾW\ޑxM;ǂ~]F[Y6Il1Џ'ٰ%ltOΏ]9 EcmLӝ#h #;~A:;KSبpzI, [Gt29h,\/aQk"\i꽸#Fuv5_H2KI,8XEdyХn&c2Mvt_c6h$$O=ʴ$cDnN\k&4A ͅ_%:F/&v>uH:^f3;feZvj@ZˆYҚ[[BThg7%0}1kėfhwF`G`T|VLt_tqC$  I^Hj4}54CNfVLI!cs/9" @V+ f?d ǎ,S-n~pЇ:#FEU:_=Z5%9SD:'.s?&.ӋԬZQ-'uh7?$/o2wmR[4 `nԛZeЧv|/r!!M(G!j_@TO tYd:uǙGJ&hjBvr gFi?@ڋ: @ XP⑦]<0/w4MA?Dtx%^v0kWCP< 7q.Ԙuj~CmEk2իt{ɴ<wRg.:![L6kAж(7 Fi_42(GUD'2߫Q 5j/jh4RI(g5Wy|拤o@j/NQ8I @Vk?~t.twwH*29,`mqeCΆ1=2?Z|{hYc> Xk:0# <+/f:"Я`9<ńhVSi*߶[ij;;;@FJ6}DbsPsfJ[-;PBMT=Zd'-F GwD$Y&]S ,3(v`tq4v FCCNSXl>FףFQ?^:lE]َ%u{^O~%ԗ߸,׍?Q\wqi١\,Ѫ)<3}N#Lq?|=AzytEZbmI둜,}J77.G_+(GeHԟ.=C_6kO~K=NH7HC:}į ݁Eڙ9OGgU;:mMe{9ٰơx;]WǮvјlb:Hζ`30˘ QU6 P/>$aΨ׼1^mB֪ ]䜄?6Y1 uIm@4 Ϣ)9^I !=N\~eQ*P&gh,ZbQ?sVqHҳ&50'ѺV'6YNX.[8NFk42߄"z hH3ПLLLL'"@2{I~'9 LE%-#s$ R`v|g @g xLLL*eY7<' uR6t2B<8g-Mf%V2Bw`&`&`&`=NlQ5I߂RE­T.#}6wE݉EH}w`!H=~8i^NI 7@b?TFnG5j!=c;AϣޑI-IoIuFRbH~iR(s}){n~:l7gt֢lGMcc-]LLLLlLf.WOrx@UF ~wQʎC\גrR-BUY2Y@V?8; s3).;:_[mrH}:*=0?GirB#9J&f&`&`&`&PQ^\e7GO!7HK q [y;?~)8@ݺ8,,Tp, ?.Gd4uD eVҚWM_2RZ|QU!ݖ}>+9ZA# L@LLLL: ll'B΅> '^ȹ#PPb+t"r5#GhTN 8p1+DQ<8pLG5r3|? :i$+Hr^Nh"*;;j&f&`&`&`&P]lރEUIyOFzzL&0CHNkeWϢdTmnp,GM77u 0000"!^-#8=-4eߠr" <}_00_ui7P"((^jTl#"zNiD!;~ЧЁ҄E &P ;hs[c &#])p!S}Ԅ{+#_tzB< o OGzoHwgo(Su,~ ZRZh-SM둖˗:ۢL6Ҳa_.5U:jw]`HQv zy}͋zԻ]Y[8m>B&egSoW({v!z)SFL4lz)26U3A`jہrBd'G1oQyHЊq8N.N>@i8!Lw@ ݁ۦq=t:Z*_i|uB^uzKpD'9]3hy= )?DN n{5;g/F:jmwuLL xW뤹Ǽ뎻$Ǧ;;ŹqEm@Sشsƙw+_݂QͩNQ69!>DkR\, CS+/g!6S(o"li qhB`ފ[|=*YK'8g)hsT,'uo(M m/5̗ECעbvƽFe\$:hX86%qwJ0̠[PϬ-@ہG28fFPȸ{c7^?q [eu>i>ӵͩŸSC9:1 ~{+Vz3j|&oakh̔$ p^٤]Ä>V!݃yɣpZ {V5QaH{Xĵ &zO~ ?uP*Ʃ(h7VZa'P |ImGvbOމhyU?J,iʗl(@ q\:,NѰqnLzNoF{J{c?˽qe6d4_B7 } ݇PN.Cۇ]d'v/PN/9gdH d˾mg@VLL]5Wax޹mSamsW2C|sfIDvm8|K@$p6q#l?̰Gksz vRvu#=LxBô{P@pCsEghɉF9?`8=AõX;gѫѠSCqO/Ӣ|dm#1asLm1.]i. $06c]N 6K9Q4l^0~F-N#p#EBmEqFqjY;`H`CRFm"* ~^s#|o+4}V;IZ8uŞC$E:1 A'^?5F=JyZ3+e®ѨZ& H@L`ԆybwFMqq^L|8o+yTc][W(&?B746]؄(O5jo^} pֶfk2).[@wG_&][iHr^S_L<ז{3,䠵QMxkm?\.4[yⱮяF$ ~IH'`+d6.Gq66Ҳ[@DcM1ey-yJަ,vit ;P6axʊR#$!EGj =x= f[ԍCwNJ9-`69LmbqtGyNľZ҄^B{QdГKJ?\48| FUmƗ=eh%ו4ˣ_֨M B73UW~IHQi柟]Bgvl+~( qQkqv PQR OW[qsqS6j$N<<<$!s|7+l%ӱsmѿBy0>nT[8c0}6O&6t ]RG(n3YyRi+}.qރ.Cj^o4 ?Keq,ڃނ^j#v:Fe\$ uclzrJ )!Qm ϡ8cGKYX ODy_l-?"}ڱ'q%kh࿩<8Z_C[ѯ+hd]$dPaik۠hs|%rv3yY#Ƣm(4?P1ѧ>Mֹn-el`e8k@S(]MR66^NL{[f䝤+Lo@qY۸v%?&vYλ/CUyoN6(\'~?c$;FgfDN/8@Aۍrt/(.@%> qt %L~Yͦ3a%ZOp?7V3uKW^3fQ{$Q_DOEy0KBF;h"*̠^(z}k#vrvt9g<_/(c6Ϊ1 ۫ѫ Ѕ(gƑ܇>8&jM;Z`CL՘'h>G7'h>EuuUMr¤Yi;uq72yqR^S%a( H@O@mx3A[/ɻlB'ofH$tui~I@$  H9$  H@$  H` c$  H@J@m\$  H@%$  H@$  X۹$  H@$ %:hK,I@$  H@+s H@$  H@KtЖX$  H@$0V:hco$  H@-0& H@$  H`tƊ%  H@$  ,A[baL$  H@X 蠍K@$  H@X"˜$  H@$ A+~;$  HgN;J/[S?J ,Ӕ$  Hnbz۶m7|=" ӝiMSɞdNS$  {U̒~#|L{a7{?5ä7:h=Xd( H@@w4Ѯ֨NBtފށvvsj ,Ӕ$  H;ؠe4w=FGA6(7kh tހi1~2zB@' 4%  H@69A ]=bds݊>=qm`w3AסKG e: ԓ",Ӕ$  H_>VȟZc"^F/FqG9eqIhA$  H@c&>坤NScp9ubB6&`e+PiwVcTc~3kwbʖZڙJ@$4'j3 u?iaw/' {6M^8dIef+cB[N@m9S$  Hp.` y1.]rRV;Fz iC~'ESbloA}99$0P4H@$ naH^7u##uh HIw"~6a }VlPZ3$  H`ȉ 4Z8l $oœ%:b㈤Σ8[Q؅()(eqrSw mh}5 ںy$  H@8!{QHOwT8q%0Vqr]=J;8c6:D,& !!mD$  tN[8iy*&SIENDB`content/fr/admin-processes.md0000644000175000056700000000515315226251677015023 0ustar0000000000000000## XII. Processus d'administration ### Lancez les processus d'administration et de maintenance comme des one-off-processes La [formation de processus](./concurrency) est la liste des processus qui sont utilisés pour le fonctionnement normal de l'application (comme gérer les requêtes web) lorsqu'elle tourne. Les développeurs vont souvent vouloir effectuer des tâches occasionnelles d'administration ou de maintenance, comme : * Lancer les migrations de base de données (par ex. `manage.py migrate` avec Django, `rake db:migrate` avec Rails). * Lancer une console (également appelée terminal [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) pour exécuter du code arbitraire ou inspecter les modèles de l'application dans la base de données. La plupart des langages fournissent un terminal REPL en lançant l'interpréteur sans arguments (par exemple `python` ou `perl`), ou dans certains cas à l'aide d'une commande dédiée (par ex. `irb` pour Ruby, `rails console` pour Rails). * Exécuter des scripts ponctuels inclus dans le dépôt de code (par ex. `php scripts/fix_bad_records.php`). Les processus ponctuels d'administration devraient être lancés dans un environnement identique à ceux des [processus standards](./processes) de l'application. Ils s'exécutent sur une [release](./build-release-run), en utilisant la même [base de code](./codebase) et [configuration](./config) que tout processus qui tourne pour cette release. Le code d'administration doit être livré avec le code de l'application afin d'éviter les problèmes de synchronisation. La même technique d'[isolation de dépendances](./dependencies) doit être utilisée sur tous les types de processus. Par exemple, si le processus web de Ruby utilise la commande `bundle exec thin start`, alors une migration de base de données devrait être faite via `bundle exec rake db:migrate`. De la même manière, un programme Python qui utilise Virtualenv devrait utiliser la commande incluse `bin/python` pour lancer à la fois le serveur web Tornado et tout processus administrateur `manage.py`. Les applications 12 facteurs préfèrent les langages qui fournissent un terminal REPL prêt à l'emploi, et qui facilitent l'exécution de scripts ponctuels. Dans un déploiement local, les développeurs invoquent les processus ponctuels d'administration depuis le terminal, par une commande directement dans le répertoire où se trouve l'application. Dans un déploiement de production, les développeurs peuvent utiliser ssh ou d'autres mécanismes d'exécution de commandes fournis par l'environnement d'exécution de ce déploiement pour exécuter un tel processus. content/fr/concurrency.md0000644000175000056700000000634215226251677014262 0ustar0000000000000000## VIII. Concurrence ### Grossissez à l'aide du modèle de processus Tout programme informatique, lorsqu'il s'exécute, est représenté par un ou plusieurs processus. Les applications web ont adopté différentes approches d'exécution de processus. Par exemple, les processus PHP s'exécutent comme des processus fils d'Apache, démarrés à la demande lorsque c'est requis par le volume de requêtes. Les processus Java ont adopté l'approche inverse, avec une machine virtuelle qui fournit un super-processus massif qui réserve un gros bloc de ressources système (processeur et mémoire) au démarrage, et la concurrence est gérée en interne à l'aide de threads. Dans les deux cas, les processus qui tournent sont à peine visibles aux développeurs de l'application. ![La scalabilité est exprimée par des processus qui s'exécutent, la diversité de la charge de travail est exprimée par les types de processus](/images/process-types.png) **Dans une application 12 facteurs, les processus sont des élèves modèles**. Les processus dans une application 12 facteurs s'inspirent fortement du [modèle de processus unix pour faire fonctionner les daemon (en)](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). En utilisant ce modèle, les développeurs peuvent structurer l'application pour gérer différents types de charge en assignant chaque type de travail à un *type de processus*. Par exemple, les requêtes HTTP peuvent être gérées par un processus web, et les tâches d'arrière-plan ayant une longue durée d'exécution peuvent être des processus dits "worker". Chaque processus peut malgré tout et individuellement, gérer son propre multiplexage interne, avec des threads à l'intérieur de la machine virtuelle d'exécution, ou à l'aide du modèle d'évènements asynchrones que l'on retrouve dans des outils comme [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), ou [Node.js](http://nodejs.org/). Mais une machine virtuelle a individuellement une taille limitée (grandissement vertical), donc l'application doit également pouvoir déclencher plusieurs processus qui tournent sur plusieurs machines physiques. Le modèle de processus prend de l'envergure dès qu'il est question de grossir. La [nature sans partage, avec une partition horizontale des processus des applications 12 facteurs](./processes) signifie qu'ajouter plus de concurrence est une opération simple et fiable. La liste des types de processus et du nombre de processus de chaque type est appelée *formation de processus*. Les processus des applications 12 facteurs ne devraient [jamais être des daemons (en)](http://dustin.github.com/2010/02/28/running-processes.html) ou écrire des fichiers PID. À la place, utilisez le gestionnaire de processus du système d'exploitation (tel que [systemd](https://www.freedesktop.org/wiki/Software/systemd/), un gestionnaire de processus distribué sur une plateforme cloud, ou un outil comme [Foreman (en)](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) durant le développement) pour gérer les [flux de sortie](./logs), répondre à un processus qui plante, et gérer les redémarrages et les arrêts initiés par les utilisateurs. content/it/disposability.md0000644000175000056700000000575115226251677014617 0ustar0000000000000000## IX. Rilasciabilità ### Massimizzare la robustezza con avvii veloci e shutdown graduali **I [processi](./processes) di un'applicazione twelve-factor sono *rilasciabili*, cioè possono essere avviati o fermati senza problemi al momento del bisogno.** Questa caratteristica ovviamente facilita le procedure di scaling, deploy rapido della [codebase](./codebase) o cambi dei file di [configurazione](./config). I processi dovrebbero inoltre ambire a **minimizzare i tempi di avvio**. Idealmente, un processo impiega pochi secondi dal tempo di lancio al momento in cui tutto è pronto per ricevere nuove richieste. Dei tempi brevi di avvio inoltre forniscono una maggiore agilità in fase di [release](./build-release-run); il tutto a vantaggio della robustezza dell'applicazione, dato che il process manager può così muoversi agevolmente verso un'altra macchina fisica, se necessario. I processi dovrebbero inoltre **terminare in modo tutt'altro che brusco, quindi graduale, in caso di ricezione di un segnale [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** dal process manager. Per un'applicazione web, la giusta terminazione di un processo viene ottenuta quando si cessa innanzitutto di ascoltare sulla porta dedicata del servizio (evitando quindi di ricevere altre richieste), permettendo poi di terminare le richieste esistenti e infine di concludere la fase di terminazione in modo definitivo. Per un processo worker, invece, la fase di terminazione più adatta vede il ritorno del job corrente alla coda. Per esempio, su [RabbitMQ](http://www.rabbitmq.com/) il worker può inviare un [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); su [Beanstalkd](https://beanstalkd.github.io), il job viene automaticamente rimandato in coda nel caso in cui il worker si disconnette. I sistemi basati su lock come [Delayed 部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 -- 整个过程都不需要修改代码。 locales/th.yml0000644000175000056700000000036515226251677012104 0ustar0000000000000000th: # Name of language listed in locales menu language: ภาษาไทย (th) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "แปลภาษาไทย" README.md0000644000175000056700000000313615226251677010602 0ustar0000000000000000# Introduction This is a sample 12factor application that can be deployed on Kubernetes using Epinio. The 12factor application is a simple ruby web app with pages which explain about the 12 factors/principles to be followed while developing your cloud-native application. Note: This is the simplest ruby web app with no complexities. For a more complicated ruby app, you can go to [Ruby App](https://github.com/epinio/example-rails) # Deploy ## Step 1 - Create a cluster ```bash bash> k3d cluster create epinio -p 80:80 -p 443:443 ``` ## Step 2 - Download epinio cli Find the artifact that matches your OS and architecture by visiting the latest release here: https://github.com/epinio/epinio/releases You need to download that binary and put it in your PATH. Something like this should work on Linux (replace the link with right one for your binary): ```bash # Download the binary bash> wget https://github.com/epinio/epinio/releases/download/v0.7.1/epinio-linux-x86_64 # Make the binary executable bash> chmod +x epinio-linux-x86_64 # Put epinio in your PATH bash> mv epinio-linux-x86_64 /usr/bin/epinio # Enable epinio autocompletion bash> epinio completion bash > comp bash> source comp ``` ## Step 3 - Install epinio Follow the Epinio installation guide [here](https://docs.epinio.io/installation). ## Step 4 - Clone 12factor repo ```bash git clone https://github.com/epinio/example-12factor.git cd example-12factor ``` ## Step 5 - Push 12factor app ```bash epinio push -n app1 ``` ## Step 6 - Visit website You will recieve a URL at the end of the `push` process. Use that url to access your 12factor app. content/es/processes.md0000644000175000056700000000567515226251677013746 0ustar0000000000000000## VI. Procesos ### Ejecutar la aplicación como uno o más procesos sin estado La aplicación se ejecuta como uno o más *procesos* en el entorno de ejecución. El caso más sencillo que podemos plantear es que el código es un script independiente, el entorno de ejecución es un portátil de un desarrollador, el compilador o interprete correspondiente del lenguaje está instalado, y el proceso se lanza mediante la linea de mandatos (por ejemplo, `python my_script.py`). Por otro lado podemos encontrar el caso de un despliegue en producción de una aplicación compleja que puede usar muchos [tipos de procesos, instanciados como cero o más procesos en ejecución](./concurrency). **Los procesos "twelve-factor" no tienen estado y son "[share-nothing](http://en.wikipedia.org/wiki/Shared_nothing_architecture)".** Cualquier información que necesite persistencia se debe almacenar en un ['backing service'](./backing-services) con estado, habitualmente una base de datos. Tanto el espacio de memoria de un proceso como el sistema de ficheros se pueden usar como si fueran una cache temporal para hacer transacciones. Por ejemplo, descargar un fichero de gran tamaño, realizar alguna operación sobre él, y almacenar sus resultados en una base de datos. Las aplicaciones "twelve-factor" nunca dan por hecho que cualquier cosa cacheada en memoria o en el disco vaya a estar disponible al realizar una petición al ejecutar diferentes procesos. Con muchos procesos de cada tipo ejecutándose al mismo tiempo, existe una gran probabilidad de que otro proceso distinto sirva una petición en el futuro. Incluso cuando solo está corriendo un solo proceso, un reinicio (provocado por el despliegue de código, un cambio de configuración o un cambio de contexto del proceso) normalmente elimina todo el estado local (e.g. memoria y sistema de ficheros). Los compresores de estáticos (como [Jammit](http://documentcloud.github.com/jammit/) o [django-compressor](http://django-compressor.readthedocs.org/)) usan el sistema de ficheros como una cache para ficheros compilados. En las aplicaciones "twelve-factor" es preferible realizar esta compilación durante la [fase de construcción](./build-release-run), como con el [asset pipeline de Rails](http://guides.rubyonrails.org/asset_pipeline.html), en lugar de hacerlo en tiempo de ejecución. Algunos sistemas webs dependen de ["sticky sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence), esto quiere decir que cachean la información de la sesión de usuario en la memoria del proceso de la aplicación y esperan peticiones futuras del mismo visitante para redirigirle al mismo proceso. Las "sticky sessions" son una violación de "twelve-factor" y no deberían usarse nunca ni depender de ellas. La información del estado de la sesión es un candidato perfecto para almacenes de información que ofrecen mecanismos de tiempo de expiración, como [Memcached](http://memcached.org/) o [Redis](http://redis.io/). content/it/intro.md0000644000175000056700000000231115226251677013060 0ustar0000000000000000Introduzione ============ Nell'era moderna, il software viene fornito sempre più di frequente come servizio (delivered as a service): si parla di *web app* o *software as a service* (SaaS). La **twelve-factor app** è una metodologia di sviluppo orientata alla costruzione di applicazioni software-as-a-service che: * Seguono un formato **dichiarativo** per l'automazione della configurazione, minimizzando tempi e costi di ingresso per ogni sviluppatore che si aggiunge al progetto; * **Si interfacciano in modo pulito** con il sistema operativo sottostante, in modo tale da offrire la **massima portabilità** sui vari ambienti di esecuzione; * Sono **adatti allo sviluppo** sulle più recenti **cloud platform**, ovviando alla necessità di server e amministrazioni di sistema; * **Minimizzano la divergenza** tra sviluppo e produzione, permettendo il **contiuous deployment** per una massima "agilità"; * Possono **scalare significativamente** senza troppi cambiamenti ai tool, all'architettura e al processo di sviluppo; La metodologia twelve-factor può essere applicata a ogni software, scritto in qualsiasi linguaggio di programmazione, che fa uso di una serie di servizi come database, code, cache e così via. content/ko/concurrency.md0000644000175000056700000000630115226251677014257 0ustar0000000000000000## VIII. 동시성(Concurrency) ### 프로세스 모델을 통한 확장 모든 컴퓨터 프로그램은 실행되면 하나 이상의 프로세스로 표현됩니다. 웹 애플리케이션은 다양한 프로세스 실행 형태를 취해왔습니다. 예를 들어, PHP 프로세스는 Apache의 자식 프로세스로 실행되며, request의 양에 따라 필요한 만큼 시작됩니다. 자바 프로세스들은 반대 방향에서의 접근법을 취합니다. JVM은, 시작될 때 큰 시스템 리소스(CPU와 메모리) 블록을 예약하는 하나의 거대한 부모 프로세스를 제공하고, 내부 쓰레드를 통해 동시성(concurrency)을 관리합니다. 두 경우 모두 실행되는 프로세스는 애플리케이션 개발자에게 최소한으로 노출됩니다. ![Scale는 실행되는 프로세스의 갯수로 표현되고, Workload Diversity는 프로세스의 타입으로 표현됩니다. ](/images/process-types.png) **Twelve-Factor App에서 프로세스들은 일급 시민입니다.** Twelve-Factor App에서의 프로세스는 [서비스 데몬들을 실행하기 위한 유닉스 프로세스 모델](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)에서 큰 힌트를 얻었습니다. 이 모델을 사용하면 개발자는 애플리케이션의 작업을 적절한 *프로세스 타입*에 할당함으로서 다양한 작업 부하를 처리할 수 있도록 설계할 수 있습니다. 예를 들어, HTTP 요청은 웹 프로세스가 처리하며, 시간이 오래 걸리는 백그라운드 작업은 worker 프로세스가 처리하도록 할 수 있습니다. 이는 런타임 VM 내부의 쓰레드나 [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), [Node.js](http://nodejs.org/)에서 구성된 것 처럼 async/evented 모델처럼 개별 프로세스가 내부적으로 동시에 처리하는 것을 금지하는 것은 아닙니다. 하지만 개별 VM이 너무 커질 수 있습니다.(수직 확장) 따라서 애플리케이션은 여러개의 물리적인 머신에서 돌아가는 여러개의 프로세스로 넓게 퍼질 수 있어야만 합니다. 프로세스 모델이 진정으로 빛나는 것은 수평적으로 확장하는 경우입니다. [아무것도 공유하지 않고, 수평으로 분할할 수 있는 Twelve-Factor App 프로세스의 성질](./processes)은 동시성을 높이는 것은 간단하고 안정적인 작업이라는 것을 의미 합니다. 프로세스의 타입과 각 타입별 프로세스의 갯수의 배치를 *프로세스 포메이션*이라고 합니다. Twelve-Factor App 프로세스는 [절대 데몬화해서는 안되며](http://dustin.github.com/2010/02/28/running-processes.html) PID 파일을 작성해서는 안됩니다. 대신, OS의 프로세스 관리자(예: [systemd](https://www.freedesktop.org/wiki/Software/systemd/))나 클라우드 플랫폼의 분산 프로세스 매니저, 혹은 [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) 같은 툴에 의존하여 [아웃풋 스트림](./logs)을 관리하고, 충돌이 발생한 프로세스에 대응하고, 재시작과 종료를 처리해야 합니다. content/pl/disposability.md0000644000175000056700000000572115226251677014613 0ustar0000000000000000## IX. Zbywalność ### Zwiększ elastyczność aplikacji przez szybki start i bezproblemowe zamknięcie **[Procesy](./processes) aplikacji 12factor są *jednorazowe*, znaczy to, że mogą być wystartowane lub zatrzymane w dowolnym momencie.** Ułatwia to elastyczne skalowanie i szybkie wdrożenia [kodu](./codebase), zmianę [konfiguracji](./config) oraz zapewnia większą stabilność przy wdrożeniu na produkcję. Procesy powinny dążyć do **minimalizowania czasu swojego rozruchu**. W idealnej sytuacji proces powinien potrzebować kilku sekund na to aby wystartować i być gotowym na przyjmowanie zapytań. Dzięki krótkiemu czasowi startu można szybciej wykonywać kolejne [wdrożenia](./build-release-run) oraz łatwiej skalować aplikację. Zwiększa to również zdolności aplikacji do radzenia sobie z problemami, ponieważ `process manager` może bezproblemowo przenieść je na nową maszynę fizyczną, gdy zajdzie taka potrzeba. Procesy **zamykają się gdy otrzymają sygnał [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** od managera procesów. Dla procesów sieciowych poprawne zamknięcie polega na zakończeniu nasłuchiwania na porcie usługi (skutkiem czego jest odrzucanie nowych zapytań), zakończenie obecnych, a ostatecznie zaprzestaniu działania. Wynika z tego, że zapytania HTTP są krótkie (trwają nie więcej niż kilka sekund), lub w przypadku `long pollingu` i utraty połączenia klient powinien bezproblemowo spróbować połączyć się ponownie. Dla procesów roboczych poprawnym zamknięciem jest zwrot obecnie wykonywanego zadania do kolejki. Dla przykładu w [RabbitMQ](http://www.rabbitmq.com/) działający proces może wysłać wiadomość [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); w [Beanstalkd](https://beanstalkd.github.io), zadanie jest zwracane do kolejki automatycznie, gdy tylko proces się rozłączy. Systemy bazujące na blokadach zasobów jak [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) muszą upewnić się, że odblokowały zajmowany wcześniej zasób. W tym modelu ważne jest to, że wszystkie zadania są [wielobieżne](http://pl.wikipedia.org/wiki/Wielobieżność), co zazwyczaj jest osiągane przez zebranie wyników w transakcję lub uczynienie operacji [idempotentną](http://pl.wikipedia.org/wiki/Idempotentno%C5%9B%C4%87). Architektura aplikacji 12factor jest również zaprojektowana by działające procesy zostały poprawnie **zakończone w razie awarii** sprzętu. Podczas gdy taka sytuacja jest o wiele rzadsza niż otrzymanie sygnału `SIGTERM`, wciąż może mieć miejsce. Zalecanym podejściem w takich przypadkach jest stosowanie serwerowego systemu kolejkowania zadań, jak Beanstalkd, który zwróci zadanie do kolejki, gdy klient się rozłączy, bądź minie maksymalny czas obsługi pojedynczego zapytania. Architektura ["crash-only"](http://lwn.net/Articles/191059/) jest więc rozwinięciem takiego [konceptu](http://docs.couchdb.org/en/latest/intro/overview.html). content/tr/processes.md0000644000175000056700000000517215226251677013754 0ustar0000000000000000## VI. Süreç ### Uygulamayı bir veya daha fazla bağımsız süreç olarak çalıştırma Uygulama bir veya birden fazla *süreç* olarak çalıştırma ortamında çalıştırılır. En basit senaryoda, kod bağımsız bir betiktir, çalışma ortamı, dil çalışma zamanı yüklenmiş, geliştiricilerin yerel laptopudur ve süreç komut satırı aracılığıyla başlatılır (Örneğin, `python my_script.py`). Diğeri spekturumun sonunda, çok yönlü uygulamanın ürün dağıtımı birden fazla [süreç tipi kullanabilir, sıfır veya daha fazla çalışan süreci somutlaştırabilir](./concurrency). **On iki faktör süreçleri durumsuz ve [paylaşımsızdır](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Devamlılığa ihtiyaç duyan herhangi bir veri kapsamlı [destek servisinde](./backing-services) saklanmalıdır, genel olarak bir veri tabananında. Süreçlerin bellek uzayı ve dosya sistemi, kısa tek işlemli önbellek olarak kullanılabilir. Örneğin, büyük bir dosya indirirken, çalıştırırken, işlem sonuçlarını veri tabanında saklarken. On iki faktör uygulaması, bellek veya önbellekteki depolanmış hiçbir şeyin gelecekteki istek veya işlerde erişilebilir olacağını hiçbir zaman varsaymaz, çalışan her bir tipin bir çok süreciyle birlikte, gelecek isteğin farklı süreç tarafından sunulma şansı yüksektir. Sadece bir süreç çalıştırıldığında bile, tekrar başlatma (kod dağıtımı, yapılandırma değişikliği veya çalışma ortamı sürecin farklı fiziksel adrese tekrar yerleştirimi tarafından tetiklenir) genellikle bütün yerel (bellek ve dosya sistemi v.b gibi) durumları temizler. Varlık paketleyicileri ( [Jammit](http://documentcloud.github.com/jammit/) veya [django-compressor](http://django-compressor.readthedocs.org/) gibi), derlenmiş varlıklar için önbellek olarak dosya sistemi kullanılır. On iki faktör uygulaması [derleme aşaması](./build-release-run) boyunca, [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html) gibi, bu derlemeyi yapmayı tercih eder, çalışma zamanında yapmaktansa. Bazı web sistemleri ["sticky sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) dayanır, bu, kullanıcı oturum verisini uygulama sürecinin belleğinde saklar ve aynı sürece yönlendirilecek olan gelecek istekleri aynı ziyaretçiden bekler. Sticky sessions on iki faktörü ihlal eder ve asla kullanılmamalıdır veya buna güvenmemelidir. Oturum durum verisi [Memcached](http://memcached.org/) veya [Redis](http://redis.io/) gibi bitiş süresi öneren veri deposu için iyi bir adaydır. content/uk/logs.md0000644000175000056700000001033615226251677012702 0ustar0000000000000000## XI. Журналювання ### Сприймайте журналювання (logs) як потоки подій *Журналювання* забезпечує наочне уявлення про поведінку запущеного застосунку. Зазвичай у серверних середовищах журнали записуються у файл на диску ("logfile"), але це лише один з форматів виведення. Журнал — це [потік](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) агрегованих, впорядкованих за часом подій, зібраних з потоків виведення всіх запущених процесів і сторонніх сервісів. Журнал в сирому вигляді, як правило, має текстовий формат з однією подією на кожен рядок (хоча трасування винятків можуть займати кілька рядків). Журнали не мають фіксованого початку і кінця, потік безперервний поки працює застосунок. **Застосунок дванадцяти факторів ніколи не займається маршрутизацію і зберіганням свого потоку виведення.** Застосунок не повинен записувати журнал у файл або керувати файлами журналів. Замість цього кожен запущений процес записує свій потік подій без буферизації в стандартне виведення `stdout`. В development середовищі розробник має можливість переглядати цей потік в терміналі, щоб спостерігати за поведінкою застосунку. В staging та production розгортаннях потік виведення кожного процесу перехоплюється середовищем виконання, збирається разом з усіма іншими потоками виведення застосунку і спрямовується до одного або кількох кінцевих пунктів призначення для перегляду і довгострокового архівування. Ці кінцеві пункти призначення не видимі для застосунку і не налаштовуються ним, вони керуються середовищем виконання. Для цього можуть бути використані маршрутизатори журналів з відкритим вихідним кодом (наприклад, [Logplex](https://github.com/heroku/logplex) та [Fluentd](https://github.com/fluent/fluentd)). Потік подій застосунку може бути направлений у файл або переглянутий у терміналі в режимі реального часу. Найважливішим є те, що потік може бути направлений у систему індексування і аналізу журналів, таку як [Splunk](http://www.splunk.com/), або систему зберігання даних загального призначення, таку як [Hadoop/Hive](http://hive.apache.org/). Ці системи мають широкі можливості і гнучкість для детального аналізу поведінки застосунку протягом тривалого часу, в тому числі: * Виявлення конкретних подій у минулому; * Побудова графіків трендів (наприклад, кількість запитів за хвилину); * Активне оповіщення відповідно до визначених користувачем евристичних правил (наприклад, попередження, коли кількість помилок за хвилину перевищує певний поріг). content/zh_cn/processes.md0000644000175000056700000000413415226251677014425 0ustar0000000000000000## VI. 进程 ### 以一个或多个无状态进程运行应用 运行环境中，应用程序通常是以一个和多个 *进程* 运行的。 最简单的场景中，代码是一个独立的脚本，运行环境是开发人员自己的笔记本电脑，进程由一条命令行（例如`python my_script.py`）。另外一个极端情况是，复杂的应用可能会使用很多 [进程类型](./concurrency) ，也就是零个或多个进程实例。 **12-Factor 应用的进程必须无状态且 [无共享](http://en.wikipedia.org/wiki/Shared_nothing_architecture) 。** 任何需要持久化的数据都要存储在 [后端服务](./backing-services) 内，比如数据库。 内存区域或磁盘空间可以作为进程在做某种事务型操作时的缓存，例如下载一个很大的文件，对其操作并将结果写入数据库的过程。12-Factor应用根本不用考虑这些缓存的内容是不是可以保留给之后的请求来使用，这是因为应用启动了多种类型的进程，将来的请求多半会由其他进程来服务。即使在只有一个进程的情形下，先前保存的数据（内存或文件系统中）也会因为重启（如代码部署、配置更改、或运行环境将进程调度至另一个物理区域执行）而丢失。 源文件打包工具（[Jammit](http://documentcloud.github.com/jammit/), [django-compressor](http://django-compressor.readthedocs.org/)） 使用文件系统来缓存编译过的源文件。12-Factor 应用更倾向于在 [构建步骤](./build-release-run) 做此动作——正如 [Rails资源管道](http://guides.rubyonrails.org/asset_pipeline.html) ，而不是在运行阶段。 一些互联网系统依赖于 “[粘性 session ](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence)”， 这是指将用户 session 中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程。粘性 session 是 12-Factor 极力反对的。Session 中的数据应该保存在诸如 [Memcached](http://memcached.org/) 或 [Redis](http://redis.io/) 这样的带有过期时间的缓存中。 content/es/admin-processes.md0000644000175000056700000000511415226251677015020 0ustar0000000000000000## XII. Administración de procesos ### Ejecutar las tareas de gestión/administración como procesos que solo se ejecutan una vez El [juego de procesos](./concurrency) es el conjunto de procesos que se usa para hacer las tareas habituales de la aplicación (como procesar las peticiones web). Por otro lado, es frecuente que los desarrolladores quieran ejecutar procesos de administración o mantenimiento una sola vez, como por ejemplo: * Ejecutar migraciones de las bases de datos (e.g. `manage.py migrate` de Django, `rake db:migrate` de Rails). * Ejecutar una consola (también conocidas como [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) para ejecutar código arbitrario o inspeccionar los modelos de la aplicación en una base de datos con datos reales. La mayoría de los lenguajes proporcionan un interprete del tipo REPL si se ejecuta el mismo mandato sin ningún argumento (e.g. `python` o `perl`) pero en algunos casos tienen un mandato distinto (e.g. `irb` en Ruby, `rails console` en Rails). * Ejecutar scripts incluidos en el repositorio de la aplicación (e.g. `php scripts/fix_bad_records.php`). Los procesos de este tipo deberían ejecutarse en un entorno idéntico al que se usa normalmente en los [procesos](./processes) habituales de la aplicación. Estos procesos se ejecutan en una [distribución](./build-release-run) concreta, usando el mismo [código base](./codebase) y la misma [configuración](./config) que cualquier otro proceso que ejecuta esa distribución. El código de administración se debe enviar con el código de la aplicación para evitar problemas de sincronización. Se deberían usar las mismas técnicas de [aislamiento de dependencias](./dependencies) en todos los tipos de procesos. Por ejemplo, si un proceso web Ruby usa el mandato `bundle exec thin start`, entonces una migración de la base de datos debería usar `bundle exec rake db:migrate`. De la misma manera, un programa Python que usa Virtualenv debería usar `bin/python` para ejecutar tanto el servidor web Tornado como cualquier proceso de administración `manage.py`. "Twelve-factor" recomienda encarecidamente lenguajes que proporcionan una consola del tipo REPL, ya que facilitan las tareas relacionadas con la ejecución de scripts que solo han de usarse una vez. En un despliegue local, se invocarán los procesos de administración con un mandato directo en la consola dentro del directorio de la aplicación. En un despliegue de producción, se puede usar ssh u otro mecanismo de ejecución de mandatos remoto proporcionado por el entorno de ejecución del despliegue para ejecutar dichos procesos. content/fr/disposability.md0000644000175000056700000000627415226251677014613 0ustar0000000000000000## IX. Jetable ### Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux **Les [processus](./processes) des applications 12 facteurs sont *jetables*, c'est-à-dire qu'ils peuvent être démarrés ou stoppés en un instant.** Cela simplifie un rapide grossissement vertical, le déploiement rapide du [code](./codebase) ou de changements dans la [configuration](./config), ainsi que la robustesse des déploiements de production. Les processus doivent viser à **minimiser le temps de démarrage**. Idéalement, un processus prend quelques secondes entre le moment où une commande le lance et celui où il est en marche et prêt à recevoir des requêtes ou du travail. Un court temps de démarrage rend les processus de [release](./build-release-run) et de scalabilité verticale plus agiles; il aide également à la robustesse, car les gestionnaires de processus peuvent plus facilement déplacer des processus vers de nouvelles machines physiques lorsque c'est nécessaire. Les processus **s'éteignent gracieusement lorsqu'ils reçoivent un signal [SIGTERM (fr)](https://fr.wikipedia.org/wiki/SIGTERM)** du gestionnaire de processus. Pour un processus web, s'éteindre en douceur se fait en arrêtant d'écouter sur le port de service (refusant, par la même occasion, toute nouvelle requête), en permettant à la requête courante de se terminer, et en quittant ensuite. Ce qui est implicite dans ce modèle, c'est que les requêtes sont courtes (pas plus de quelques secondes), ou dans le cas de longues requêtes, les clients doivent pouvoir tenter de se reconnecter sans problème lorsque la connection est perdue. Pour un processus de worker, s'éteindre gracieusement est réalisé en renvoyant le travail en cours dans la file de travaux. Par exemple, avec [RabbitMQ](http://www.rabbitmq.com/) le worker peut envoyer un message [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); avec [Beanstalkd](https://beanstalkd.github.io), le travail est renvoyé dans la file automatiquement dès qu'un worker se déconnecte. Les systèmes basés sur des verrous, comme [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) doivent s'assurer de supprimer le verrou de leur travail en cours. Il est implicite dans ce modèle que toutes les tâches sont [réentrantes (fr)](http://fr.wikipedia.org/wiki/R%C3%A9entrance), ce qui est réalisé en englobant les résultats dans une transaction, ou en rendant l'opération [idempotente (fr)](http://fr.wikipedia.org/wiki/Idempotence). Les processus doivent également être **robustes face aux morts subites**, dans le cas d'une panne du hardware sous-jacent. Bien que ce soit bien moins courant qu'un arrêt gracieux avec `SIGTERM`, cela peut arriver malgré tout. L'approche recommandée est l'utilisation d'un backend robuste de files de messages, tel que Beanstalkd, capable de renvoyer les tâches dans la file lorsqu'un client se déconnecte ou ne répond plus. Dans les deux cas, une application 12 facteurs est structurée pour gérer des fins inattendues et non-gracieuses. Le [design crash-only (en)](http://lwn.net/Articles/191059/) amène ce concept à sa [conclusion logique (en)](http://docs.couchdb.org/en/latest/intro/overview.html). content/pl/config.md0000644000175000056700000000667715226251677013214 0ustar0000000000000000## III. Konfiguracja ### Przechowuj konfigurację w środowisku *Konfiguracja* to jedyny element, który może się różnić pomiędzy [wdrożeniami](./codebase) aplikacji (staging, produkcja, środowisko developerskie, etc). W jej skład wchodzą: * Ustawienia połączeń do baz danych, Memcached, i innych [usług wspierających](./backing-services) * Dane uwierzytelniające zewnętrznych usług takich jak Amazon S3 czy Twitter * Wartości różne dla każdego wdrożenia, jak np. kanoniczna nazwa hosta Aplikacja czasem przechowuje konfigurację jako stałe wartości w kodzie źródłowym. Niestety jest to złamanie zasady 12factor wg której konfiguracja jest **ściśle oddzielona od kodu aplikacji**. Dowodem na to, czy aplikacja posiada swoją konfigurację oddzieloną od kodu jest to, czy można ją udostępnić na zasadach open source bez równoczesnego udostępniania np. danych uwierzytelniających. Należy pamiętać, że definicja "konfiguracji" **nie** dotyczy wewnętrznych ustawień aplikacji takich jak np. plik `config/routes.rb` w Railsach lub to jak [są połączone moduły kodu](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) w [Springu](http://spring.io/). Konfiguracja tego typu nie zmienia się pomiędzy wdrożeniami co sprawia, że najbardziej odpowiednim miejscem do jej przechowywania jest kod aplikacji. Innym podejściem do konfiguacji jest korzystanie z plików, które nie znajdują się w repozytorium i nie są wersjonowane, jak np. `config/database.yml` w Railsach. Jest to duże usprawnienie względem używania stałych wartości, które są zapisywane w repozytorium. Minusem tego rozwiązania jest możliwość przypadkowego umieszczenia pliku konfiguracyjnego w repo. Ponadto można spotkać się z tendencją do rozrzucania takich plików w różnych katalogach i różnych formatach, co czyni je trudnymi do znalezienia i zarządzania z jednego miejsca. **Aplikacja 12factor przechowuje konfigurację w *zmiennych środowiskowych*** (czasem nazywane z języka angielskiego *env vars* lub *env*). W tej sytuacji można łatwo modyfikować zmienne środowiskowe pomiędzy wdrożeniami bez zmiany kodu aplikacji. W odróżnieniu do plików konfiguracyjnych istnieje mała szansa by zostały umieszczone przypadkowo w repozytorium. Ich kolejną zaletą jest to, że nie są powiązane z językiem programowania, frameworkiem, jak np. Java System Properties, czy też systemem operacyjnym. Kolejnym zagadnieniem zarządzania konfiguracją jest jej grupowanie. Czasem aplikacje gromadzą konfigurację w grupach (czasem nazywane "środowiskami") nazywanych od nazwy wdrożenia, takie jak `development`, `test`, czy `produkcja` w Railsach. Ten sposób organizacji jest niestety nieskalowalny. Im więcej różnych wdrożeń, tym większa potrzeba nazw, jak np. `staging` czy `qa`. Wraz z rozwojem projektu programiści mogą dodawać swoje specjalne konfiguracje, jak `staging-józefa`. Efektem tego mogą być niezliczone kombinacje nazw plików konfiguracyjnych, co utrudniać będzie zarządzanie wdrożonymi aplikacji. W aplikacji 12factor zmienne środowiskowe służą do precyzyjnej kontroli poszczególnych ustawień, posiadając różne, nie mylące się ze sobą nazwy. Nigdy nie są zgrupowane w "środowiskach", tylko niezależnie ustawiane dla każdego wdrożenia. Taki model konfiguracji skaluje się bez problemu, nawet jeśli aplikacja będzie potrzebowała w przyszłości więcej zróżnicowanych wdrożeń. content/tr/codebase.md0000644000175000056700000000342015226251677013505 0ustar0000000000000000## I. Kod Tabanı ### Bir çok dağıtım kod tabanı gözden geçirme kontrolünde izlenmeli On iki faktör bir uygulama her zaman [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/) veya [Subversion](http://subversion.apache.org/) gibi bir sürüm takip sistemiyle izlenir. VEritabanının gözden geçirme sisteminin bir kopyası *kod deposu* olarak bilinir. *kod repo* ya da sadece *repo* olarak kısaltılır. Bir *kod tabanı* herhangi tek bir depo(Subversion gibi merkezi gözden geçirme kontrol sistemi) ya da kök işleyicini paylaşan bir takım repodur(Git gibi merkezi olmayan gözden geçirme kontrol sistemi). ![Bir kod tabanı bir çok dağıtımla eşlenir](/images/codebase-deploys.png) Kod tabanı ve uygulama arasında bire-bir ilişki her zaman vardır: * Eğer birden fazla kod tabanı varsa bu bir uygulama değil, dağıtık sistemdir. Dağıtık sistemdeki her bileşen bir uygulamadır ve her biri on iki faktörle bireysel olarak uyumlu olmalıdır. * Aynı kodu paylaşan birden fazla uygulama, on iki faktörü ihlal eder. Burada çözüm, paylaşılan kodun [bağımlılık yöneticisi](./dependencies) aracılığıyla dahil edilebilecek kütüphanelere dönüştürülmesidir. Uygulamanın sadece bir kod tabanı vardır fakat birden fazla dağıtımı olacaktır. Bir *dağıtım*, uygulamanın çalışan bir örneğidir. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır ve bunların her biri aynı zamanda dağıtım olarak nitelendirilirler. Sürümler her bir dağıtımda etkin olabilir fakat kod temeli tüm dağıtımlarda aynıdır. Örneğin, geliştiricilerin henüz uygulamaya eklenmemiş commitleri olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod tabanı aynıdır. Procfile0000644000175000056700000000006115226251677011003 0ustar0000000000000000web: bundle exec ruby web.rb -p $PORT -o 0.0.0.0 content/ru/processes.md0000644000175000056700000001102215226251677013744 0ustar0000000000000000## VI. Процессы ### Запускайте приложение как один или несколько процессов, не сохраняющих внутреннее состояние (stateless) Приложение выполняется в среде выполнения как один или несколько *процессов*. В простейшем случае код является независимым скриптом, среда выполнения -- ноутбуком разработчика с установленной средой исполнения языка, а процесс запускается из командной строки (например, как `python my_script.py`). Другой крайний вариант -- это рабочее развёртывание сложного приложения, которое может использовать много [типов процессов, каждый из которых запущен в необходимом количестве экземпляров](./concurrency). **Процессы приложения двенадцати факторов не сохраняют внутреннее состояние (stateless) и [не имеют разделяемых данных (share-nothing)](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Любые данные, которые требуется сохранить, должны быть сохранены в хранящей состояние [сторонней службе](./backing-services), обычно, в базе данных. Память и файловая система процесса может быть использована в качестве временного кэша для одной транзакции. Например, загрузка, обработка и сохранение большого файла в базе данных. Приложение двенадцати факторов не предполагает, что что-либо закэшированное в памяти или на диске будет доступно следующим запросам или задачам -- с большим количеством разноплановых процессов высока вероятность, что следующий запрос будет обработан другим процессом. Даже с одним запущенным процессом перезапуск (вызванный развёртыванием, изменением конфигураций или переносом процесса на другое физическое устройство) приведёт к уничтожению всех локальных (памяти, файловой системы) состояний. Упаковщики ресурсов (asset) (например, [Jammit](http://documentcloud.github.com/jammit/) или [django-compressor](http://django-compressor.readthedocs.org/)) используют файловую систему как кэш для скомпилированных ресурсов. Приложение двенадцати факторов предпочитает делать данную компиляцию во время [этапа сборки](./build-release-run), например, как в [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html), а не во время выполнения. Некоторые веб-системы полагаются на ["липкие сессии"] (http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- то есть кэшируют данные пользовательских сессии в памяти процесса приложения и ожидают того, что последующие запросы того же пользователя будут перенаправлены к тому же процессу. Липкие сессии являются нарушением двенадцати факторов и их никогда не следует использовать или полагаться на них. Данные пользовательской сессии являются хорошими кандидатами для хранилища данных, которое предоставляет функцию ограничения времени хранения, например, [Memcached](http://memcached.org/) и [Redis](http://redis.io/). content/th/port-binding.md0000644000175000056700000000546315226251677014333 0ustar0000000000000000## VII. Port binding ### นำออกบริการด้วยการเชื่อมโยง port เว็บแอพ (Web App) บางครั้งทำงานข้างใน webserver container. ตัวอย่างเช่น PHP app จะทำงานเป็นโมดูลข้างใน [Apache HTTPD](http://httpd.apache.org/) หรือ Java app จะทำงานข้างใน [Tomcat](http://tomcat.apache.org/) เป็นต้น **Twelve-factor app เป็น self-contained โดยสมบูรณ์** และไม่ขึ้นอยู่กับ runtime injection ของ webserver เข้ามายังสภาพแวดล้อมการดำเนินงานเพิ่อสร้าง web-facing service. เว็บแอพ **นำออก HTTP เป็นบริการโดยเชื่อมโยงกับ port** และคอยตรวจสอบ request ที่เข้ามาจาก port นั้น นี้เป็นการทำงานปรกติโดยใช้ [ประกาศการอ้างอิง](./dependencies) เพื่อเพิ่ม webserver library ของ app, เช่น [Tornado](http://www.tornadoweb.org/) สำหรับ Python, [Thin](http://code.macournoyer.com/thin/) สำหรับ Ruby หรือ [Jetty](http://www.eclipse.org/jetty/) สำหรับ Java และภาษา JVM-based อื่นๆ เกิดขึ้นใน *user space* นั้นคือภายใน code ของ app ซึ่งสัญญากับสภาพแวดล้อมการดำเนินงานที่เชื่อมโยงกับ port เพื่อบริการ request ที่เข้ามา HTTP ไม่เป็นเพียง service ที่สามารถนำออกโดยการเชื่อมโยง port, server software เกือบทุกชนิดสามารถทำงานผ่านการเชื่อมโยง process ไปยัง port และรอ request ที่เข้ามา, ตัวอย่างรวมทั้ง ejabberd](http://www.ejabberd.im/) (speaking [XMPP](http://xmpp.org/)), และ [Redis](http://redis.io/) (speaking the [Redis protocol](http://redis.io/topics/protocol)) หมายเหตุ, วิธีการเชื่อมโยง port หมายความว่า app จะกลายเป็น [backing service](./backing-services) สำหรับ app อื่นๆ โดยการให้ URL กับ backing app เป็นตัวจัดการทรัพยากรใน [การตั้งค่า](./config) สำหรับใช้งาน app content/pl/admin-processes.md0000644000175000056700000000442315226251677015026 0ustar0000000000000000## XII. Zarządzanie aplikacją ### Uruchamiaj zadania administracyjne jako jednorazowe procesy [Formacja](./concurrency) jest zestawem procesów używanych przez aplikację podczas jej działania (np. obsługi zapytań z sieci). Do często wykonywanych zadań administracyjnych należą: * Wykonanie migracji bazy danych (np. `manage.py migrate` w Django, `rake db:migrate` w Railsach). * Uruchomienie konsoli (znanej również jako powłoka [REPL](http://pl.wikipedia.org/wiki/REPL)) by wykonać fragment kodu lub podejrzeć modele działającej bazy danych. Większość środowisk języków programowania udostępnia REPL poprzez wywołanie interpretera bez dodatkowych argumentów (np. `python` lub `perl`). W innych przypadkach przeznaczone są do tego osobne polecenia (np. `irb` w Ruby, `rails console` w Railsach). * Wykonywanie pojedynczych skryptów znajdujących się w repozytorium kodu aplikacji (np. `php scripts/fix_bad_records.php`). Pojedyncze zadania powinny być uruchamiane w identycznym środowisku jak [długoterminowe procesy](./processes) aplikacji. Działają w ramach tego samego [wdrożenia](./build-release-run), używając tego samego [kodu](./codebase) i [konfiguracji](./config) jak każdy inny działający proces. Kod zadania administracyjnego musi zostać dołączony do kodu aplikacji by uniknąć problemów z synchronizacją. Te same techniki [izolacji zależności](./dependencies) powinny być używane dla wszystkich typów procesów. Dla przykładu, jeśli proces sieciowy Ruby używa polecenia `bundle exec thin start`, wtedy do migracji bazy danych powinno się użyć `bundle exec rake db:migrate`. Podobnie program napisany w Pythonie używający Virtualenv powinien używać dołączonego `bin/python` by uruchomić zarówno webserver Tornado lub `manage.py` do procesów zarządzania. Aplikacja 12factor zaleca używanie języków programowania, które udostępniają powłokę REPL oraz takich w których można łatwo uruchomić pojedynczy skrypt. W środowisku lokalnym developerzy uruchamiają zadania zarządzające aplikacją poprzez bezpośrednie wywołanie polecenia w konsoli w katalogu roboczym aplikacji. We wdrożeniu produkcyjnym, developer może użyć ssh lub innego mechanizmu służącego do zdalnego wykonywania poleceń, by uruchomić ten sam proces. content/pt_br/background.md0000644000175000056700000000273615226251677014551 0ustar0000000000000000Experiência =========== Os contribuidores deste documento estão diretamente envolvidos no desenvolvimento e implantação de centenas de aplicações, e indiretamente testemunhando o desenvolvimento, operação e escalada de centenas de milhares de aplicações através de seu trabalho na plataforma [Heroku](http://www.heroku.com/). Este documento sintetiza toda nossa experiência e observação em uma variedade de aplicações que operam como software-como-serviço. Isto é a triangulação de práticas ideais ao desenvolvimento de software, com uma atenção particular a respeito das dinâmicas de crescimento orgânico de uma aplicação ao longo do tempo, a dinâmica de colaboração entre desenvolvedores trabalhando em uma base de código, e evitando os [custos de erosão de software](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/) Nossa motivação é aumentar a consciência de alguns problemas sistêmicos que temos visto no desenvolvimento de aplicações modernas, prover um vocabulário comum para discussão destes, e oferecer um amplo conjunto de soluções conceituais para esses problemas com a terminologia que os acompanha. O formato é inspirado nos livros de Martin Fowler *[Padrões de Arquitetura de Aplicações Enterprise](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* e *[Refatorando](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/tr/admin-processes.md0000644000175000056700000000457515226251677015050 0ustar0000000000000000## XII. Yönetici Süreci ### Yönetici/yönetim görevlerini tek seferlik işlem olarak çalıştırma [Süreç oluşumu](./concurrency) uygulama çalışırken uygulamanın sıradan işlerini (web isteklerini idare etmek gibi) yapmakta kullanılan süreçlerin bir dizisidir. Ayrı olarak, geliştiriciler çoğunlukla uygulamanın bir kereye mahsus yönetimsel veya bakım görevlerini yapmayı dileyecekler, şunun gibi: * Veri tabanı göçü çalıştırmak (Django'da `manage.py migrate`, Rails'de `rake db:migrate`). * Konsolu ([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) kabuğu olarakta bilinir), rastgele kodu çalıştırmak veya canlı veritabanına karşılık uygulamanın modellerini denetlemek için çalıştırmak. Çoğu dil hiç bir arguman olmadan (`python` veya `perl`), yorumlayıcı veya bazı durumlarda ayrı komutlarla (Ruby için `irb`, Rails için `rails console`) çalıştırarak bir REPL sağlar. * Uygulamanın deposuna commit'lenmiş betikleri çalıştırmak (`php scripts/fix_bad_records.php`). Bir kerelik yönetici süreçleri uygulamanın sıradan [uzun çalışan süreçleri](./processes) gibi aynı ortamlarda çalışmalıdır. Onlar herhangi bir sürecin çalıştığı gibi [sürüme](./build-release-run) karşı aynı [kod tabanı](./codebase) ve [yapılandırmayı](./config) kullanarak çalışır. Yönetici uygulama kodunu senkronizasyon sorunundan kaçınmak için yüklemelidir. Aynı [bağımlılık yalıtımı](./dependencies) teknikleri bütün süreç yönetiminde kullanılmalıdır. Örneğin, eğer Ruby web süreçleri `bundle exec thin start` komutunu kullanıyorsa, veri tabanı göçü `bundle exec rake db:migrate` komutu kullanmalıdır. Aynı durumda, Virtualenv kullanan bir Python programı, Tornado web sunucusu ve herhangi bir `manage.py` yönetici süreçlerinin ikisini de çalıştırabilmek için `bin/python` kullanmalıdır. On iki faktör, REPL kabuğunu kural dışı sağlayan ve tek seferlik betikleri çalıştırmayı kolaylaştıran dilleri fazlasıyla destekler. Yerel dağıtımda, geliştiriciler uygulamanın kontrol dizinindeki açık kabuk komutuyla tek seferlik yönetici süreçlerini çalıştırır. Ürün dağıtımında, geliştiriciler bu gibi bir süreci çalıştırmak için ssh veya dağıtımın çalışma ortamı tarafından sağlanan diğer uzak komut çalıştırma mekanizmasını kullanabilir. content/tr/toc.md0000644000175000056700000000243415226251677012531 0ustar0000000000000000On İki Faktör ============= ## [I. Kod Tabanı](./codebase) ### Bir çok dağıtım kod tabanı gözden geçirme kontrolünde izleme ## [II. Bağımlıklar](./dependencies) ### Bağımlıkları açık bir şekilde açıklama ve ayırma ## [III. Yapılandırma](./config) ### Ortamda yapılandırma depolama ## [IV. Destek servisi](./backing-services) ### Destek servislerine ekli kaynak olarak davranma ## [V. Derleme, Sürüm, Çalıştırma](./build-release-run) ### Derleme ve çalıştırma aşamalarını tam olarak ayırma ## [VI. Süreç](./processes) ### Uygulamayı bir veya daha fazla bağımsız süreç olarak çalıştırma ## [VII. Port Bağlama](./port-binding) ### Port bağlama yolu üzerinden dışarı aktarma ## [VIII. Eş Zamanlılık](./concurrency) ### Süreç modeli yardımıyla dağıtıklaştırma ## [IX. Kullanıma Hazır Olma Durumu](./disposability) ### Hızlı başlangıç ve otomatik zararsız kapama ile sağlamlığı üst düzeye çıkarma ## [X.Geliştirme/Üretim Eşitliği](./dev-prod-parity) ### Gelişim, evreleme ve üretimi olabildikçe benzer tutma ## [XI. Günlükler](./logs) ### Günlüklere olay akışı gibi davranma ## [XII. Yönetici Süreci](./admin-processes) ### Yönetici/yönetim görevlerini tek seferlik işlem olarak çalıştırma content/zh_cn/background.md0000644000175000056700000000217715226251677014543 0ustar0000000000000000背景 ========== 本文的贡献者参与过数以百计的应用程序的开发和部署，并通过 [Heroku](http://www.heroku.com/) 平台间接见证了数十万应用程序的开发，运作以及扩展的过程。 本文综合了我们关于 SaaS 应用几乎所有的经验和智慧，是开发此类应用的理想实践标准，并特别关注于应用程序如何保持良性成长，开发者之间如何进行有效的代码协作，以及如何 [避免软件污染](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/) 。 我们的初衷是分享在现代软件开发过程中发现的一些系统性问题，并加深对这些问题的认识。我们提供了讨论这些问题时所需的共享词汇，同时使用相关术语给出一套针对这些问题的广义解决方案。本文格式的灵感来自于 Martin Fowler 的书籍： *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* ， *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)* 。 content/de/concurrency.md0000644000175000056700000000545415226251677014246 0ustar0000000000000000## VIII. Nebenläufigkeit ### Mit dem Prozess-Modell skalieren Jedes Computerprogramm wird, wenn es läuft, repräsentiert durch einen oder mehrere Prozesse. Webapps nutzen verschiedenste Arten der Prozess-Ausführung. Zum Beispiel laufen PHP-Prozesse als Kind-Prozesse von Apache und werden nach Bedarf gestartet, wenn Requests kommen. Java-Prozesse gehen anders vor: die JVM stellt einen massiven Über-Prozess zur Verfügung der große Mengen an Systemressourcen (Speicher und CPU) reserviert und die Nebenläufigkeit wird intern über Threads verwaltet. In beiden Fällen sind die laufenden Prozesse für die Entwickler der App nur minimal zu sehen. ![Die Skalierung wird dargestellt als laufende Prozesse, die Diversität der Workload wird dargestellt als Prozesstypen.](/images/process-types.png) **In der Zwölf-Faktor-App sind Prozesse First Class Citizens.** Die Prozesse der Zwölf-Faktor-App orientieren sich am [Unix-Prozess-Modell für Service Daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Mit diesem Model können Entwickler ihre App für die Bearbeitung verschiedenster Aufgaben konzipieren in dem sie jeder Aufgabe einen *Prozesstyp* zuweisen. Zum Beispiel können HTTP-Requests durch einen Web-Prozess bedient werden und langlaufende Hintergrundarbeiten durch einen Worker-Prozess. Dies hindert die einzelnen Prozesse nicht daran, ihr internes Multiplexing zu verwalten, mittels Threads in der Laufzeit-VM oder mit dem Async/Event-Modell von Werkzeugen wie [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) oder [Node.js](http://nodejs.org/). Aber eine einzelne VM ist in der Größe dadurch beschränkt (vertikale Skalierung), dass eine App noch in der Lage sein muss, mehrere Prozesse auf mehreren physikalischen Maschinen zu starten. Das Prozess-Modell glänzt besonders, wenn es um Skalierung geht. Die [Share-Nothing, horizontal teilbare Art und Weise der Prozesse der Zwölf-Faktor-App](./processes) hat zur Folge, dass weitere Nebenläufigkeit einfach und zuverlässig hinzugefügt werden kann. Das Bündel von Prozesstypen und die Zahl der Prozesse wird auch *Prozess-Formation* genannt. Die Prozesse einer Zwölf-Faktor-App [sollten nie als Daemons laufen](http://dustin.github.com/2010/02/28/running-processes.html) oder PID-Dateien schreiben. Stattdessen sollen sie sich auf den Prozessmanager des Betriebssystems verlassen (wie [systemd](https://www.freedesktop.org/wiki/Software/systemd/), den verteilten Prozessmanager einer Cloud-Plattform oder ein Werkzeug wie [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) während der Entwicklung) um [Output-Streams](./logs) zu verwalten, auf abgestürzte Prozesse zu reagieren und mit von Benutzern angestoßenen Restarts und Shutdowns umzugehen. content/es/dependencies.md0000644000175000056700000000614215226251677014354 0ustar0000000000000000## II. Dependencias ### Declarar y aislar explícitamente las dependencias La mayoría de los lenguajes de programación tienen un sistema de gestión de paquetes para distribuir sus librerías, como [CPAN](http://www.cpan.org/) en Perl o [Rubygems](http://rubygems.org/) en Ruby. Las librerías instaladas a través de estos sistemas se pueden instalar en el sistema (también conocido como "site packages") o limitarse al directorio que contiene la aplicación (también conocido como "vendoring" o "bundling"). **Una aplicación "twelve-factor" no depende nunca de la existencia explícita de paquetes instalados en el sistema.** Declara todas sus dependencias, completamente y explícitamente, mediante un manifiesto de *declaración de dependencias*. Además, usa herramientas de *aislamiento de dependencias* durante la ejecución para asegurar que las dependencias, implícitamente, no afectan al resto del sistema. La especificación de dependencias completa y explícita se aplica de la misma manera tanto en producción como en desarrollo. Por ejemplo, la [Bundler](https://bundler.io/) de Ruby tiene el formato de su manifiesto `Gemfile` para declarar sus dependencias y `bundle exec` para aislar sus dependencias. En Python existen dos herramientas independientes para estas tareas -- [Pip](http://www.pip-installer.org/en/latest/) se usa para la declaración de dependencias y [Virtualenv](http://www.virtualenv.org/en/latest/) para el aislamiento. Incluso C tiene [Autoconf](http://www.gnu.org/s/autoconf/) para la declaración de sus dependencias, y el enlace estático proporciona aislamiento de sus dependencias. No importa qué conjunto de herramientas se use, la declaración y el aislamiento de dependencias se deben usar siempre juntas, usar solo una o la otra no es suficiente para satisfacer las condiciones de "twelve-factor". Uno de los beneficios de la declaración explícita de dependencias es que simplifica la configuración para los nuevos desarrolladores de la aplicación. Cualquier desarrollador que se incorpore al equipo debe poder probar el código base de la aplicación en su máquina de desarrollo. Tan solo debe tener instalados el entorno de ejecución del lenguaje y el gestor de dependencias como prerequisitos. Lo cual permitirá configurar todo lo necesario para ejecutar el código de la aplicación con un *mandato para construir*. Por ejemplo, el mandato para construir en Ruby/Bundler es `bundle install`, mientras que en Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) es `lein deps`. Las aplicaciones "Twelve-factor" tampoco dependen de la existencia de ninguna herramienta en el sistema. Por ejemplo, ejecutar mandatos como `ImageMagick` o `curl`. Aunque estas herramientas pueden existir en muchos, o incluso en la mayoría de los sistemas, no existen garantías de que vayan a existir en todos los sistemas donde la aplicación pueda ser ejecutada en un futuro, ni de que las versiones futuras de un sistema vayan a ser compatibles con la aplicación. Si la aplicación necesita ejecutar una herramienta del sistema, dicha herramienta debería estar incluida dentro de la aplicación. content/fr/processes.md0000644000175000056700000000576615226251677013747 0ustar0000000000000000## VI. Processus ### Exécutez l'application comme un ou plusieurs processus sans état L'application est exécutée dans l'environnement d'exécution comme un ou plusieurs *processus*. Dans la situation la plus simple, le code est un script indépendant, l'environnement d'exécution est l'ordinateur portable du développeur sur lequel est installé de quoi exécuter le langage, et le processus est lancé depuis la ligne de commande. (par exemple, `python mon_script.py`). De l'autre côté du spectre, un déploiement de production d'une application sophistiquée peut utiliser plusieurs [types de processus, instanciés dans zéro ou plus processus en fonctionnement](./concurrency). **Les processus 12 facteurs sont sans état et ne partagent [rien (en)](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Toute donnée qui doit être persistée doit être stockée dans un [service externe](./backing-services) stateful, typiquement une base de données. L'espace mémoire ou le système de fichier du processus peut être utilisé comme cache momentané pour des transactions uniques. Par exemple, télécharger un gros fichier, effectuer une opération dessus, puis stocker le résultat de l'opération dans la base de données. Les applications 12 facteurs ne supposent jamais que quelque chose ayant été mis en cache en mémoire ou sur le disque sera disponible dans une future requête ou job — avec plusieurs processus de chaque type qui s'exécutent, il y a de grandes chances qu'une future requête soit effectuée par un processus différent. Même lorsque l'on fait tourner seulement un processus, un redémarrage (déclenché par le déploiement du code, un changement de configuration, ou l'environnement d'exécution qui déplace le processus vers un lieu physique différent) va généralement balayer toutes les modifications locales (c'est-à-dire en mémoire et sur le disque). Des outils de création de paquets de ressources (ou "asset packagers") (tel que [Jammit](http://documentcloud.github.com/jammit/) ou [django-compressor](http://django-compressor.readthedocs.org/)) utilisent le système de fichier comme cache pour les ressources compilées. Une application 12 facteurs préfère faire cette compilation durant l'[étape d'assemblage](./build-release-run), comme avec le [pipeline des ressources de Rails](http://guides.rubyonrails.org/asset_pipeline.html), plutôt que durant l'exécution. Certains systèmes web s'appuient sur des ["sessions persistantes" (en)](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- c'est-à-dire, mettre en cache les données de session utilisateur dans le processus de l'application et attendre que les requêtes futures du même visiteur seront routées dans le même processus. Les sessions persistantes sont une violation des 12 facteurs, qu'il ne faudrait jamais utiliser. Les états de session sont de bons candidats pour un datastore qui offre des dates d'expiration, comme [Memcached](http://memcached.org/) ou [Redis](http://redis.io/). content/pl/background.md0000644000175000056700000000250415226251677014047 0ustar0000000000000000Background ========== Kontrybutorzy tego dokumentu byli bezpośrednio zaangażowani w tworzenie i wdrażanie setek aplikacji i pośrednio byli świadkami produkcji, działania i skalowania setek tysięcy aplikacji dzięki naszej pracy na platformie [Heroku](http://www.heroku.com/). Ten dokument jest podsumowaniem całego naszego doświadczenia i obserwacji szerokiej gamy aplikacji SaaS. Jest on połączeniem idealnych praktyk developmentu, zwracania szczególnej uwagi na naturalny rozrost aplikacji w czasie, dynamiki współpracy developerów pracujących nad jednym codebase'm, oraz [unikania kosztów gnijącego oprogramowania](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). Naszym celem jest podniesienie poziomu świadomości o podstawowych problemach, które dostrzegliśmy przy tworzeniu nowoczesnych aplikacji, zapewnienie wspólnego słownictwa do rozmowy o tych problemach oraz zaoferowanie ogólnych rozwiązań dla tych problemów wraz z towarzyszącą terminologią. Format dokumentu jest inspirowany książkami Martina Fowlera *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* oraz *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/zh_cn/build-release-run.md0000644000175000056700000000416615226251677015743 0ustar0000000000000000## V. 构建，发布，运行 ### 严格分离构建和运行 [基准代码](./codebase) 转化为一份部署(非开发环境)需要以下三个阶段： * *构建阶段* 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 [依赖项](./dependencies)，编译成二进制文件和资源文件。 * *发布阶段* 会将构建的结果和当前部署所需 [配置](./config) 相结合，并能够立刻在运行环境中投入使用。 * *运行阶段* （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序 [进程](./processes)。 ![代码被构建，然后和配置结合成为发布版本](/images/release.png) **12-factor 应用严格区分构建，发布，运行这三个步骤。** 举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。 部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如， [Capistrano](https://github.com/capistrano/capistrano/wiki) 将所有发布版本都存储在一个叫 `releases` 的子目录中，当前的在线版本只需映射至对应的目录即可。该工具的 `rollback` 命令可以很容易地实现回退版本的功能。 每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（`2011-04-06-20:32:17`），亦或是一个增长的数字（`v100`）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。 新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。 locales/uk.yml0000644000175000056700000000040115226251677012077 0ustar0000000000000000uk: # Name of language listed in locales menu language: "Українська (uk)" # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "(Переклад українською)" content/en/config.md0000644000175000056700000000575215226251677013174 0ustar0000000000000000## III. Config ### Store config in the environment An app's *config* is everything that is likely to vary between [deploys](./codebase) (staging, production, developer environments, etc). This includes: * Resource handles to the database, Memcached, and other [backing services](./backing-services) * Credentials to external services such as Amazon S3 or Twitter * Per-deploy values such as the canonical hostname for the deploy Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires **strict separation of config from code**. Config varies substantially across deploys, code does not. A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials. Note that this definition of "config" does **not** include internal application config, such as `config/routes.rb` in Rails, or how [code modules are connected](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) in [Spring](http://spring.io/). This type of config does not vary between deploys, and so is best done in the code. Another approach to config is the use of config files which are not checked into revision control, such as `config/database.yml` in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it's easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific. **The twelve-factor app stores config in *environment variables*** (often shortened to *env vars* or *env*). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard. Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called "environments") named after specific deploys, such as the `development`, `test`, and `production` environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as `staging` or `qa`. As the project grows further, developers may add their own special environments like `joes-staging`, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle. In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as "environments", but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime. content/en/intro.md0000644000175000056700000000174615226251677013061 0ustar0000000000000000Introduction ============ In the modern era, software is commonly delivered as a service: called *web apps*, or *software-as-a-service*. The twelve-factor app is a methodology for building software-as-a-service apps that: * Use **declarative** formats for setup automation, to minimize time and cost for new developers joining the project; * Have a **clean contract** with the underlying operating system, offering **maximum portability** between execution environments; * Are suitable for **deployment** on modern **cloud platforms**, obviating the need for servers and systems administration; * **Minimize divergence** between development and production, enabling **continuous deployment** for maximum agility; * And can **scale up** without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). content/it/config.md0000644000175000056700000000653615226251677013207 0ustar0000000000000000## III. Configurazione ### Memorizza le informazioni di configurazione nell'ambiente La "configurazione" di un'applicazione è tutto quello che può variare da un [deployment](./codebase) all'altro (staging, production, ambienti di sviluppo). Ad esempio: * Valori da usare per connettersi a un database, Memcached, oppure altri [backing service](./backing-services); * Credenziali per servizi esterni, come Amazon S3 o Twitter; * Valori eventualmente definiti per i singoli deployment, come l'hostname; Molto spesso, queste informazioni vengono memorizzate come costanti nel codice: la cosa viola la metodologia twelve-factor, che richiede una **separazione ben definita delle impostazioni di configurazione dal codice**. Le impostazioni possono infatti variare da un deployment all'altro: il codice, invece, no. Il codice dell'applicazione, infatti, potrebbe essere reso open-source in ogni momento: un buon motivo per separare le due cose. Nota che comunque la definizione di "configurazione" **non** include eventuali configurazione interne dell'applicazione, come `config/routes.rb` in Rails, o come [i moduli di codice sono connessi](http://static.springsource.org/spring/docs/2.5.x/reference/beans.html) in [Spring](http://www.springsource.org/). Questo tipo di configurazione non varia da deployment a deployment: come giusto che sia, quindi, rimane nel codice. Un ottimo approccio al "rispetto" di questo principio consiste nell'usare dei file di configurazione non coinvolti dal version control, come per esempio `config/database.yml` in Rails. Stiamo parlando di un miglioramento enorme rispetto all'uso di costanti nel codice, ma c'è da dire la cosa ha il suo lato negativo: basta poco per sbagliarsi e includere nel repo il file di configurazione che, invece, non dovrebbe essere lì. C'è una certa tendenza, infatti, a non avere tutti i file di configurazione necessari nello stesso posto. Inoltre, i vari formati tendono a essere collegati a un certo linguaggio/framework. **L'applicazione che rispetta la metodologia twelve-factor memorizza tutte le impostazioni in *variabili d'ambiente*** (spesso dette *env vars* o *env*). Le variabili d'ambiente sono molto semplici da cambiare di deployment in deployment senza dover toccare il codice direttamente. Inoltre, a differenza dei file di configurazione classici, c'è una probabilità molto bassa di venire inclusi nel repo. Infine, questi file sono indipendenti sia dal linguaggio che dal sistema operativo utilizzato. Un altro aspetto del config management è il raggruppamento. A volte, infatti, alcune applicazioni prevedono la memorizzazione delle impostazioni in gruppi (chiamati spesso "ambienti") dal nome ben preciso: "development", "test" e "production", per esempio. Questo metodo non scala correttamente, se ci pensi: potrebbero essere necessari nuovi ambienti, come "staging" e "qa". Oppure, i vari sviluppatori potrebbero aver bisogno di creare i propri ambienti "speciali", come "joes-staging" e così via. Il risultato? Una quantità di combinazioni ingestibile e disordinata. In una buona twelve-factor app, le variabili di ambiente sono controllate in modo più "granulare", in modo totalmente ortogonale alle altre. Non sono mai raggruppate e classificate sotto "ambienti" specifici, ma vengono gestite in modo totalmente indipendente per ogni deployment. Il prodotto finale ne risente positivamente in termini di scalabilità.LICENSE0000644000175000056700000000204015226251677010321 0ustar0000000000000000Copyright (c) 2012 Adam Wiggins Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. content/ru/toc.md0000644000175000056700000000443615226251677012536 0ustar0000000000000000Двенадцать факторов ================== ## [I. Кодовая база](./codebase) ### Одна кодовая база, отслеживаемая в системе контроля версий, -- множество развёртываний ## [II. Зависимости](./dependencies) ### Явно объявляйте и изолируйте зависимости ## [III. Конфигурация](./config) ### Сохраняйте конфигурацию в среде выполнения ## [IV. Сторонние службы (Backing Services)](./backing-services) ### Считайте сторонние службы (backing services) подключаемыми ресурсами ## [V. Сборка, релиз, выполнение](./build-release-run) ### Строго разделяйте стадии сборки и выполнения ## [VI. Процессы](./processes) ### Запускайте приложение как один или несколько процессов не сохраняющих внутреннее состояние (stateless) ## [VII. Привязка портов (Port binding)](./port-binding) ### Экспортируйте сервисы через привязку портов ## [VIII. Параллелизм](./concurrency) ### Масштабируйте приложение с помощью процессов ## [IX. Утилизируемость (Disposability)](./disposability) ### Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы ## [X. Паритет разработки/работы приложения](./dev-prod-parity) ### Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими ## [XI. Журналирование (Logs)](./logs) ### Рассматривайте журнал как поток событий ## [XII. Задачи администрирования](./admin-processes) ### Выполняйте задачи администрирования/управления с помощью разовых процессов content/en/toc.md0000644000175000056700000000206615226251677012507 0ustar0000000000000000The Twelve Factors ================== ## [I. Codebase](./codebase) ### One codebase tracked in revision control, many deploys ## [II. Dependencies](./dependencies) ### Explicitly declare and isolate dependencies ## [III. Config](./config) ### Store config in the environment ## [IV. Backing services](./backing-services) ### Treat backing services as attached resources ## [V. Build, release, run](./build-release-run) ### Strictly separate build and run stages ## [VI. Processes](./processes) ### Execute the app as one or more stateless processes ## [VII. Port binding](./port-binding) ### Export services via port binding ## [VIII. Concurrency](./concurrency) ### Scale out via the process model ## [IX. Disposability](./disposability) ### Maximize robustness with fast startup and graceful shutdown ## [X. Dev/prod parity](./dev-prod-parity) ### Keep development, staging, and production as similar as possible ## [XI. Logs](./logs) ### Treat logs as event streams ## [XII. Admin processes](./admin-processes) ### Run admin/management tasks as one-off processes content/es/config.md0000644000175000056700000000740315226251677013174 0ustar0000000000000000## III. Configuración ### Guardar la configuración en el entorno La configuración de una aplicación es todo lo que puede variar entre [despliegues](./codebase) (entornos de preproducción, producción, desarrollo, etc), lo cual incluye: * Recursos que manejan la base de datos, Memcached, y otros ["backing services"](./backing-services) * Credenciales para servicios externos tales como Amazon S3 o Twitter * Valores de despliegue como por ejemplo el nombre canónico del equipo para el despliegue A veces las aplicaciones guardan configuraciones como constantes en el código, lo que conduce a una violación de la metodología "twelve-factor", que requiere una **estricta separación de la configuración y el código**. La configuración varía sustancialmente en cada despliegue, el código no. La prueba de fuego para saber si una aplicación tiene toda su configuración correctamente separada del código es comprobar que el código base puede convertirse en código abierto en cualquier momento, sin comprometer las credenciales. Hay que resaltar que la definición de "configuración" **no** incluye las configuraciones internas de la aplicación, como `config/routes.rb` en Rails, o como [se conectan los módulos](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) en [Spring](http://spring.io/). Este tipo de configuraciones no varían entre despliegues, y es por eso que están mejor en el código. Otra estrategia de configuración es el uso de ficheros de configuración que no se guardan en el control de versiones, como ocurre con el `config/database.yml` de Rails. Esto supone una gran mejora con respecto a las constantes que se guardan en el repositorio, aunque todavía tiene ciertas debilidades: es fácil guardar un fichero de configuración en el repo por error; se tiende a desperdigar los ficheros de configuración en diferentes sitios y con distintos formatos, siendo más difícil la tarea de ver y gestionar toda la configuración en un solo sitio. Además, el formato tiende a ser específico del lenguaje o del framework. **Las aplicaciones "twelve-factor" almacenan la configuración en *variables de entorno*** (abreviadas normalmente como *env vars* o *env*). Las variables de entorno se modifican fácilmente entre despliegues sin realizar cambios en el código; a diferencia de los ficheros de configuración, en los que existe una pequeña posibilidad de que se guarden en el repositorio de código accidentalmente; y a diferencia de los ficheros de configuración personalizados u otros mecanismos de configuración, como los System Properties de Java, son un estándar independiente del lenguaje y del sistema operativo. Otro aspecto de la gestión de la configuración es la clasificación. A veces, las aplicaciones clasifican las configuraciones en grupos identificados (a menudo llamados "entornos" o "environments") identificando después despliegues específicos, como ocurre en Rails con los entornos `development`, `test`, y `production`. Este método no escala de una manera limpia: según se van creando despliegues de la aplicación, se van necesitando nuevos entornos, tales como `staging` o `qa`. Según va creciendo el proyecto, los desarrolladores van añadiendo sus propios entornos especiales como `joes-staging`, resultando en una explosión de combinaciones de configuraciones que hacen muy frágil la gestión de despliegues de la aplicación. En una aplicación "twelve-factor", las variables de entorno son controles granulares, cada una de ellas completamente ortogonales a las otras. Nunca se agrupan juntas como "entornos", pero en su lugar se gestionan independientemente para cada despliegue. Este es un modelo que escala con facilidad según la aplicación se amplía, naturalmente, en más despliegues a lo largo de su vida. content/fr/who.md0000644000175000056700000000034015226251677012515 0ustar0000000000000000Qui devrait lire ce document ? ============================== Tout développeur qui construit des applications qui fonctionnent en tant que service, ainsi que les personnes qui déploient et gèrent de telles applications. content/ru/concurrency.md0000644000175000056700000001237715226251677014306 0ustar0000000000000000## VIII. Параллелизм ### Масштабируйте приложение с помощью процессов Любая компьютерная программа после запуска представляет собой один или несколько работающих процессов. Исторически веб-приложения принимали различные формы выполнения процессов. К примеру, PHP-процессы выполнятся как дочерние процессы Apache и запускаются по требованию в необходимом для обслуживания поступивших запросов количестве. Java-процессы используют противоположный подход, JVM представляет собой один монолитный мета-процесс, который резервирует большой объём системных ресурсов (процессор и память) при запуске и управляет параллельностью внутри себя с помощью нитей исполнения (threads). В обоих случаях запущенные процессы лишь минимально видны для разработчика приложения. ![Масштабирование выражается в количестве запущенных процессов, различие рабочей нагрузки выражается в типах процессов.](/images/process-types.png) **В приложении двенадцати факторов процессы являются сущностями первого класса.** Процессы в приложении двенадцати факторов взяли сильные стороны из [модели процессов Unix для запуска демонов](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). С помощью этой модели разработчик может спроектировать своё приложение таким образом, что для обработки различной рабочей нагрузки необходимо назначить каждому типу работы своего *типа процесса*. Например, HTTP-запросы могут быть обработаны веб-процессом, а длительные фоновые задачи обработаны рабочим процессом. Это не исключает возможность использования внутреннего мультиплексирования для индивидуальных процессов через потоки выполнения виртуальной машины или асинхронные/событийные модели в инструментах таких, как [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) и [Node.js](http://nodejs.org/). Но каждая индивидуальная виртуальная машина может масштабироваться только ограничено (вертикальное масштабирование), поэтому приложение должно иметь возможность быть запущенным как несколько процессов на различных физических машинах. Модель, построенная на процессах, действительно сияет, когда приходит время масштабирования. [Отсутствие разделяемых данных и горизонтальное разделение процессов приложения двенадцати факторов](./processes) означает, что добавление большего параллелизма является простой и надёжной операцией. Массив процессов различного типа и количество процессов каждого типа называются *формированием процессов (process formation)*. Процессы приложения двенадцати факторов [никогда не должны демонизироваться](http://dustin.github.com/2010/02/28/running-processes.html) и записывать PID файлы. Вместо этого они должны полагаться на менеджер процессов операционной системы (например, [systemd](https://www.freedesktop.org/wiki/Software/systemd/), распределённый менеджер процессов на облачной платформе, или инструмент как [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) в процессе разработки) для управления [потоком вывода](./logs), реагирования на падения процесса и обработки инициированных пользователем перезагрузки или завершения работы. content/zh_cn/who.md0000644000175000056700000000022115226251677013205 0ustar0000000000000000读者应该是哪些人？ ============================== 任何 SaaS 应用的开发人员。部署和管理此类应用的运维工程师。 content/es/build-release-run.md0000644000175000056700000000625515226251677015252 0ustar0000000000000000## V. Construir, distribuir, ejecutar ### Separar completamente la etapa de construcción de la etapa de ejecución El [código base](./codebase) se transforma en un despliegue (que no es de desarrollo) al completar las siguientes tres etapas: * La *etapa de construcción* es una transformación que convierte un repositorio de código en un paquete ejecutable llamado *construcción* (una "build"). En la etapa de construcción se traen todas las [dependencias](./dependencies) y se compilan los binarios y las herramientas usando una versión concreta del código correspondiente a un commit especificado por el proceso de despliegue. * En la *fase de distribución* se usa la construcción creada en la fase de construcción y se combina con la [configuración](./config) del despliegue actual. Por tanto, la *distribución* resultante contiene tanto la construcción como la configuración y está lista para ejecutarse inmediatamente en el entorno de ejecución. * La *fase de ejecución* (también conocida como "runtime") ejecuta la aplicación en el entorno de ejecución, lanzando un conjunto de [procesos](./processes) de una distribución concreta de la aplicación. ![El código se convierte en una construcción, que se combina con la configuración para crear una distribución.](/images/release.png) **Las aplicaciones "twelve-factor" hacen una separación completa de las fases de construcción, de distribución y de ejecución.** Por ejemplo, es imposible hacer cambios en el código en la fase de ejecución, porque no hay una manera de propagar dichos cambios a la fase de construcción. Las herramientas de despliegue ofrecen, normalmente, herramientas de gestión de distribuciones (releases). La capacidad de volver a una versión anterior es especialmente útil. Por ejemplo, la herramienta de despliegues [Capistrano](https://github.com/capistrano/capistrano/wiki) almacena distribuciones en un subdirectorio llamado `releases`, donde la distribución actual es un enlace simbólico al directorio de la distribución actual. Su mandato `rollback` hace fácil y rápidamente el trabajo de volver a la versión anterior. Cada distribución debería tener siempre un identificador único de distribución, como por ejemplo una marca de tiempo (timestamp) de la distribución (`2011-04-06-20:32:17`) o un número incremental (como `v100`). Las distribuciones son como un libro de contabilidad, al que solo se le pueden agregar registros y no pueden ser modificados una vez son creados. Cualquier cambio debe crear una nueva distribución. Cada vez que un desarrollador despliega código nuevo se crea una construcción nueva de la aplicación. La fase de ejecución, en cambio, puede suceder automáticamente, por ejemplo, cuando se reinicia un servidor, o cuando un proceso termina inesperadamente siendo reiniciado por el gestor de procesos. Por tanto, la fase de ejecución debería mantenerse lo más estática posible, ya que evita que una aplicación en ejecución pueda causar una interrupción inesperada, en mitad de la noche, cuando no hay desarrolladores a mano. La fase de construcción puede ser más compleja, ya que los errores siempre están en la mente de un desarrollador que dirige un despliegue. content/it/admin-processes.md0000644000175000056700000000462415226251677015032 0ustar0000000000000000## XII. Processi di Amministrazione ### Esegui i task di amministrazione come processi una tantum La "[process formation](./concurrency)" è l'array dei processi che vengono usati durante le normali operazioni dell'applicazione (per esempio, la gestione delle richieste web). Non è tutto, però: ci sono dei task che lo sviluppatore può voler eseguire, una volta ogni tanto. Per esempio: * Esecuzione delle migration del database (esempi: `manage.py migrate` in Django, `rake db:migrate` in Rails). * Esecuzione di una console (una [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) shell) in modo tale da avviare del codice arbitrariamente o analizzare alcuni aspetti dell'applicazione specifici. Molti linguaggi prevedono una REPL, in genere avviando l'interprete senza opzioni e argomenti aggiuntivi (esempi: `python` o `perl`) o in alcuni casi eseguibile con un comando separato (esempi: `irb` per Ruby, `rails console` per Rails). * Esecuzione one-time di alcuni script specifici (esempio: `php scripts/fix_bad_records.php`). Tali processi dovrebbero essere avviati in un ambiente identico a quello in cui [lavorano gli altri](./processes) nel contesto dell'applicazione. Dovrebbero essere eseguiti quindi su una specifica [release](./build-release-run), partendo dalla stessa [codebase](./codebase) e impostazioni di [configurazione](./config). Il codice per l'amministrazione dovrebbe inoltre essere incluso nel codice dell'applicazione, in modo tale da evitare qualsiasi problema di sincronizzazione. La stessa tecnica di [isolamento delle dipendenze](./dependencies) dovrebbe poter essere usata allo stesso modo su tutti i processi. Per esempio, se il processo web di Ruby può usare il comando `bundle exec thin start`, una migration del database dovrebbe poter usare `bundle exec rake db:migrate` senza problemi. Allo stesso modo, un programma Python che usa Virtualenv dovrebbe usare il `bin/python` per eseguire sia i server Tornado che processi di amministrazione. La metodologia twelve-factor favorisce molto tutti quei linguaggi che offrono una shell REPL out of the box, rendendo quindi semplice l'esecuzione di script una tantum. In un deployment locale, gli sviluppatori possono invocare questi processi speciali tramite un semplice comando diretto. In un ambiente di produzione, invece, gli sviluppatori possono raggiungere lo stesso obiettivo tramite SSH o un qualsiasi altro sistema di esecuzione di comandi remoto. content/pl/logs.md0000644000175000056700000000473215226251677012701 0ustar0000000000000000## XI. Logi ### Traktuj logi jako strumień zdarzeń *Logi* zapewniają wgląd w zachowanie działającej aplikacji. W środowiskach korzystających z serwera zazwyczaj są zapisywane na dysku (plik "logfile"); jednak jest to tylko wybrany format zapisu. Logi są listą zaagregowanych i uporządkowanych w czasie [zdarzeń](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) zebranych ze strumieni wyjściowych wszystkich uruchomionych procesów i usług wspierających. Logi w swojej pierwotnej formie występują zazwyczaj w formacie tekstowym, gdzie jedno zdarzenie zajmuje jedną linię w pliku (wyjątkiem jest jednak [backtrace](https://en.wikipedia.org/wiki/Stack_trace), który może zajmować wiele linii). Logi nie mają określonego początku ani końca, napływają nieustannie podczas działania aplikacji. **Aplikacja 12factor nie odpowiada za przekierowywanie i zapis swojego strumienia wyjściowego.** Nie powinna też zapisywać czy zarządzać plikami logów. Zamiast tego, każdy działający proces zapisuje swój niebuforowany strumień zdarzeń do `stdout`. Podczas pracy w lokalnym środowisku developer może obserwować zachowanie aplikacji przeglądając strumień w oknie terminala We wdrożeniu stagingowym czy produkcyjnym, każdy strumień procesów zostanie przechwycony przez środowisko wykonawcze, dołączony do pozostałych i skierowany do jednego lub wielu miejsc w celu przeglądania i długoterminowego zapisu. Miejsca zapisu nie są widoczne ani konfigurowane przez aplikację - w całości zarządza nimi środowisko wykonawcze. W tym celu można skorzystać z narzędzi do obsługi logów (takich jak [Logplex](https://github.com/heroku/logplex) lub [Fluentd](https://github.com/fluent/fluentd)) dostępnych na licencji open-source. Strumień zdarzeń aplikacji może być skierowany do pliku lub obserwowany w czasie rzeczywistym przy pomocy komendy `tail` w terminalu. Przeważnie strumień jest wysyłany do systemu indeksowania i analizowania jak np. [Splunk](http://www.splunk.com/), albo do systemu magazynowania danych jak [Hadoop/Hive](http://hive.apache.org/). Wymienione systemy oferują duże możliwości i elastyczność obserwacji i badania zachowań aplikacji w czasie, w tym: * Wyszukiwanie konkretnych zdarzeń z przeszłości. * Wizualizację masowych statystyk (np. zapytania na minutę). * Wysyłanie powiadomień na podstawie wcześniej zdefiniowanych heurystyk (np. o tym, że liczba błędów przekroczyła dozwoloną wartość). content/tr/build-release-run.md0000644000175000056700000000555115226251677015266 0ustar0000000000000000## V. Derleme, Sürüm, Çalıştırma ### Derleme ve çalıştırma aşamalarını tam olarak ayırma Bir [kod tabanı](./codebase) üç aşamada dağıtıma dönüşebilir: * *Derleme aşaması* kod deposunun *derleme* olarak bilinen çalıştırılabilir pakette çeviren bir dönüşümdür.Dağıtım süreci tarafından belirlenen bir commit'deki kodun versiyonunu kullanırken, derleme aşaması sağlayıcı [bağımlılıkları](./dependencies) getirir ve binary'leri derler. * *Sürüm aşaması*, derleme aşaması tarafından üretilmiş derlemeyi alır ve dağıtımı şu anki [yapılandırmasıyla](./config) birleştirir. Son durumda oluşan *sürüm* derleme ve yapılandırmanın ikisinide içerir ve çalışma ortamındaki doğrudan çalıştırma için hazırdır. * *Çalıştırma evresi* (aynı zamanda "runtime" olarak bilinir) seçili sürümün karşılığındaki uygulamanın [süreçlerini](./processes) bazı setlerini başlatarak, çalıştırma ortamındaki uygulamayı çalıştırır. ![Kod, sürüm oluşturmak için yapılandırmayla birleşmiş derlemeye dönüşür.](/images/release.png) **On iki faktör uygulamaları derleme,sürüm ve çalıştırma aşamaları arasında mutlak ayırmayı kullanır.** Örneğin, koddaki değişiklikleri derleme aşamasına geri döndürmenin bir yolu olmadığı için çalışma zamanında kodda değişiklik yapmak imkansızdır. Dağıtım araçları genel olarak sürüm yönetim araçlarını önerir, en dikkat çekeni bir önceki sürüme geri dönme yeteneğidir. Örneğin, [Capistrano](https://github.com/capistrano/capistrano/wiki) dağıtım aracı sürümleri, şu anki sürümün şimdiki sürüm dizinine bir sembolik link olduğu, `releases` adlı alt dizinde depolar. `rollback` komutu, bir önceki sürüme hızlı geri dönüşü kolaylaştırır. Her sürüm her zaman sürümlerin zaman damgası gibi (`2011-04-06-20:32:17` gibi) özel sürüm ID'sine veya artış numarasına (`v100` gibi) sahip olmalıdır. Sürümler yalnızca eklemeli bir defterdir ve bir kere oluşturulduğu zaman dönüştürülemez. Herhangi bir değişiklik yeni bir sürüm oluşturmalıdır. Derlemeler, herhangi bir zamanda yeni kod dağıtıldığında uygulama geliştiricileri tarafından başlatılır. Çalışma zamanı yürütmesi, kontras tarafından, sunucu tekrar çalıştırılması veya çökmüş süreçlerin süreç yöneticisi tarafından tekrar başlatılması gibi durumlarda otomatik olarak olabilir. Bunun sonucunda, çalıştırma evresi, gecenin bir yarısında çalışan geliştiriciler yokken uygulamanın çalışmasını engelleyen problemler uygulamanın bozulmasına yol açabildiği için, olabildiği kadar az sayıda hareketli bölüm olarak tutulmalıdır. Derleme evresinde, hatalar dağıtımı çalıştıran geliştiriciler için her zaman ön planda olduğu için daha fazla karış olabilir. content/uk/admin-processes.md0000644000175000056700000000736215226251677015037 0ustar0000000000000000## XII. Задачі адміністрування ### Виконуйте задачі адміністрування/керування за допомогою разових процесів [Формація процесів](./concurrency) є певним набором процесів, які необхідні для виконання регулярних задач застосунку (наприклад, обробка веб-запитів). Разом з тим, розробникам часто необхідно виконувати разові адміністративні задачі для обслуговування застосунку, такі як: * Запуск міграції бази даних (наприклад, `manage.py migrate` в Django, `rake db:migrate` в Rails). * Запуск консолі ([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) для виконання довільного коду або перевірки моделі застосунку на діючій базі даних. Більшість мов надають REPL шляхом запуску інтерпретатора без будь-яких аргументів (наприклад, `python` або `perl`) або в деяких випадках мають окрему команду (наприклад, `irb` для Ruby, `rails console` для Rails). * Запуск разових скриптів, збережених в репозиторії застосунку (наприклад, `php scripts/fix_bad_records.php`). Разові процеси адміністрування слід запускати в такому ж середовищі, в якому запущені регулярні [тривалі процеси](./processes) застосунку. Вони запускаються на базі [релізу](./build-release-run), використовуючи ту ж [кодову базу](./codebase) і [конфігурацію](./config), як і будь-який інший процес на базі цього релізу. Для уникнення проблем з синхронізацією код адміністрування має поставлятися з кодом застосунку. Для всіх типів процесів мають використовуватися однакові методи [ізоляції залежностей](./dependencies). Наприклад, якщо веб-процес Ruby використовує команду `bundle exec thin start`, то для міграції бази даних слід використовувати `bundle exec rake db:migrate`. Аналогічно, для програми на Python з Virtualenv слід використовувати `bin/python` як для запуску веб-сервера Tornado, так і для запуску будь-яких `manage.py` процесів адміністрування. Методологія дванадцяти факторів надає перевагу мовам, які мають REPL "з коробки", і які дозволяють легко запускати разові скрипти. У локальному development середовищі розробник може запустити процес адміністрування за допомогою консольної команди всередині директорії застосунку. У production середовищі для запуску такого процесу розробники можуть використовувати ssh або інший механізм віддаленого виконання команд, що надається середовищем виконання.locales/en.yml0000644000175000056700000000031115226251677012062 0ustar0000000000000000en: # Name of language listed in locales menu language: English (en) # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "" Gemfile.lock0000644000175000056700000000227115226251677011544 0ustar0000000000000000GEM remote: http://rubygems.org/ specs: base64 (0.3.0) concurrent-ruby (1.3.5) daemons (1.4.1) eventmachine (1.2.7) i18n (1.14.7) concurrent-ruby (~> 1.0) logger (1.7.0) maruku (0.7.3) mustermann (3.0.3) ruby2_keywords (~> 0.0.1) nio4r (2.7.4) ostruct (0.6.2) puma (6.6.0) nio4r (~> 2.0) rack (3.1.16) rack-protection (4.1.1) base64 (>= 0.1.0) logger (>= 1.6.0) rack (>= 3.0.0, < 4) rack-session (2.1.1) base64 (>= 0.1.0) rack (>= 3.0.0) rack-ssl-enforcer (0.2.9) rackup (2.2.1) rack (>= 3) rexml (3.4.1) ruby2_keywords (0.0.5) sinatra (4.1.1) logger (>= 1.6.0) mustermann (~> 3.0) rack (>= 3.0.0, < 4) rack-protection (= 4.1.1) rack-session (>= 2.0.0, < 3) tilt (~> 2.0) thin (2.0.1) daemons (~> 1.0, >= 1.0.9) eventmachine (~> 1.0, >= 1.0.4) logger rack (>= 1, < 4) tilt (2.6.1) PLATFORMS ruby DEPENDENCIES i18n maruku ostruct (~> 0.6.2) puma (~> 6.6) rack-ssl-enforcer rackup (~> 2.2) rexml sinatra (>= 2.2.0) thin (>= 1.8.1) RUBY VERSION ruby 3.2.3p157 BUNDLED WITH 2.4.20 content/de/port-binding.md0000644000175000056700000000403315226251677014300 0ustar0000000000000000## VII. Bindung an Ports ### Dienste durch das Binden von Ports exportieren Web-Apps laufen manchmal in einem Webserver als Container. Zum Beispiel laufen PHP-Apps als Modul in [Apache HTTPD](http://httpd.apache.org/), oder Java-Apps laufen manchmal in [Tomcat](http://tomcat.apache.org/). **Die Zwölf-Faktor-App ist vollständig eigenständig** und verlässt sich nicht darauf, dass ein externer Webserver zur Laufzeit injiziert wird, um dem Web einen Dienst zur Verfügung zu stellen. Die Web-App **exportiert HTTP als Dienst, indem sie sich an einen Port bindet** und wartet an diesem Port auf Requests. In einer lokalen Entwicklungsumgebung öffnet ein Entwickler eine Dienst-URL wie `http://localhost:5000/`, um auf den Dienst der App zuzugreifen. Beim Deployment sorgt eine Routing-Schicht dafür, dass Requests von einem öffentlich sichtbaren Hostnamen zu den an die Ports gebundenen Prozessen kommen. Üblicherweise wird dies mittels [Abhängigkeitsdeklaration](./dependencies) implementiert. Zu der App fügt man eine Webserver-Bibliothek hinzu wie [Tornado](http://www.tornadoweb.org/) für Python, [Thin](http://code.macournoyer.com/thin/) für Ruby oder [Jetty](http://www.eclipse.org/jetty/) für Java und andere JVM-basierenden Sprachen. Dies findet vollständig im *User Space* statt, also im Code der App. Der Vertrag mit der Laufzeitumgebung ist das Binden an einen Port um Requests zu bedienen. HTTP ist nicht der einzige Dienst, der durch Portbindung exportiert werden kann. Fast jede Server-Software kann betrieben werden, indem ein Prozess an einen Port gebunden wird und auf ankommende Requests wartet. Einige Beispiele sind [ejabberd](http://www.ejabberd.im/) (spricht [XMPP](http://xmpp.org/)) und [Redis](http://redis.io/) (spricht das [Redis-Protokoll](http://redis.io/topics/protocol)). Es sei auch erwähnt, dass durch Portbindung eine App ein [unterstützender Dienst](./backing-services) für eine andere App werden kann, indem die URL der unterstützenden App der konsumierenden App als Resource-Handle zur Verfügung gestellt wird. content/ja/dev-prod-parity.md0000644000175000056700000001332515226251677014740 0ustar0000000000000000## X. 開発/本番一致 ### 開発、ステージング、本番環境をできるだけ一致させた状態を保つ 歴史的に、開発環境（開発者が直接変更するアプリケーションのローカル[デプロイ](./codebase)）と本番環境（エンドユーザーからアクセスされるアプリケーションの実行中デプロイ）の間には大きなギャップがあった。これらのギャップは3つの領域で現れる。 * **時間のギャップ**: 開発者が編集したコードが本番に反映されるまで数日、数週間、時には数ヶ月かかることがある。 * **人材のギャップ**: 開発者が書いたコードを、インフラエンジニアがデプロイする。 * **ツールのギャップ**: 本番デプロイではApache、MySQL、Linuxを使うのに、開発者がNginx、SQLite、OS Xのようなスタックを使うことがある。 **Twelve-Factor Appでは、[継続的デプロイ](http://avc.com/2011/02/continuous-deployment/)しやすいよう開発環境と本番環境のギャップを小さく保つ。** 上で述べた3つのギャップを見る。 * 時間のギャップを小さくする: 開発者が書いたコードは数時間後、さらには数分後にはデプロイされる。 * 人材のギャップを小さくする: コードを書いた開発者はそのコードのデプロイに深く関わり、そのコードの本番環境での挙動をモニタリングする。 * ツールのギャップを小さくする: 開発環境と本番環境をできるだけ一致させた状態を保つ。 上で述べたことを表にまとめる。
伝統的なアプリケーション Twelve-Factor App
デプロイの間隔 数週間 数時間
コードを書く人とデプロイする人 異なる人 同じ人
開発環境と本番環境 異なる できるだけ一致
[バックエンドサービス](./backing-services)（アプリケーションのデータベース、キューイングシステム、キャッシュなど）は、開発/本番一致が重要になる領域の一つである。多くの言語は、異なる種類のサービスへの *アダプター* を含め、バックエンド・サービスへのアクセスを単純化するライブラリを提供している。以下の表にいくつかの例を示す。
種類 言語 ライブラリ アダプター
データベース Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
キュー Python/Django Celery RabbitMQ, Beanstalkd, Redis
キャッシュ Ruby/Rails ActiveSupport::Cache メモリ, ファイルシステム, Memcached
本番環境ではより本格的で堅牢なバックエンドサービスが使われるにもかかわらず、開発者は自身のローカル開発環境で軽量なバックエンドサービスを使いたくなることがある。例えば、開発環境ではSQLiteを使い、本番ではPostgreSQLを使ったり、開発環境ではローカルプロセスのメモリをキャッシュに使い、本番ではMemcachedを使ったりするなどである。 たとえ理論的にはアダプターがバックエンドサービスの違いをすべて抽象化してくれるとしても、 **Twelve-Factorの開発者は、開発と本番の間で異なるバックエンドサービスを使いたくなる衝動に抵抗する。** バックエンドサービスの違いは、わずかな非互換性が顕在化し、開発環境やステージング環境では正常に動作してテストも通過するコードが本番環境でエラーを起こす事態を招くことを意味する。この種のエラーは継続的デプロイを妨げる摩擦を生む。この摩擦とそれに伴って継続的デプロイが妨げられることのコストは、アプリケーションのライフサイクルに渡ってトータルで考えると非常に高くつく。 軽量なローカルサービスは、以前ほど魅力的なものではなくなっている。Memcached、PostgreSQLやRabbitMQなどのモダンなバックエンドサービスは、[Homebrew](http://mxcl.github.com/homebrew/) や [apt-get](https://help.ubuntu.com/community/AptGet/Howto) などのモダンなパッケージングシステムのおかげで、簡単にインストールして実行できる。あるいは [Chef](http://www.opscode.com/chef/) や [Puppet](http://docs.puppetlabs.com/) などの宣言的なプロビジョニングツールと、[Vagrant](http://vagrantup.com/) などの軽量な仮想環境を組み合わせることで、開発者は本番環境に限りなく近いローカル環境を作ることができる。開発/本番一致と継続的デプロイの利益に比べると、これらのシステムをインストールして利用するコストは低い。 異なるバックエンドサービスへのアダプターは依然有用である。これらのアダプターは、新しいバックエンドサービスに移植するときの苦痛を比較的和らげてくれるためである。しかし、アプリケーションのすべてのデプロイ（開発、ステージング、本番環境）は同じ種類かつ同じバージョンのバックエンドサービスを利用するべきである。 content/th/intro.md0000644000175000056700000000415415226251677013066 0ustar0000000000000000บทนำ ============ ในยุคสมัยใหม่ ซอฟต์แวร์ถูกส่งมอบทั่วไปเป็นบริการ: เรียกว่า *web apps*, หรือ *software-as-service*. twelve-factor app เป็นหลัการสำหรับสร้างแอพพลิเคชัน software-as-a-service ที่: * ใช้รูปแบบ **declarative** สำหรับติดตั้งระบบอัตโนมัต เพื่อลดเวลาและค่าใช้จ่ายสำหรับนักพัฒนาใหม่ที่เข้าร่วมกับโครงการ; * มี **clean contract** กับระบบปฏิบัติการที่แอพพลิเคชันทำงานด้วย นำเสนอ **maximun portibility** ระหว่างสิ่งแวดล้อมที่ระบบทำงาน; * เหมาะสมสำหรับ **deployment** บน **cloud platforms** สมัยใหม่, ลดความต้องการของเซิร์ฟเวอร์และผู้ดูแลระบบ; * **Maximized divergence** ระหว่างการพัฒนาและการใช้งานจริง ด้วยการใช้ **continuous deployment** เพื่อเพิ่มความเร็วสูงสุด; * และสามารถ **scale up** โดยปราศจากการเปลี่ยนแปลงของ เครื่องมือ สถาปัตยกรรม หรือแนวทางปฏิบัตของการพัฒนา หลักการ twelve-factor สามารถประยุกต์ใช้ได้กับแอพพลิเคชันที่เขียนด้วยภาษาใดๆ และซึ่งใช้ร่วมกับบริการสนับสนุนใดๆ (ฐานข้อมูล, คิว, หน่วยความจำเคช เป็นต้น).content/uk/intro.md0000644000175000056700000000403715226251677013072 0ustar0000000000000000Вступ ===== У наш час програмне забезпечення зазвичай поставляється у вигляді сервісів, що називаються *веб-застосунки* (web-apps) або *software-as-a-service* (SaaS). Застосунок дванадцяти факторів — це методологія для створення SaaS-застосунків, які: * Використовують **декларативний** формат для автоматизації встановлення та налаштування, що зводить до мінімуму витрати часу і коштів для нових розробників, що приєднуються до проекту; * Мають **угоду** з операційною системою, пропонуючи **максимальну переносимість** між середовищами виконання; * Придатні для **розгортання** на сучасних **хмарних платформах**, що усуває необхідність у серверах та їх системному адмініструванні; * **Мінімізують різницю** між середовищем розробки і production середовищем, що дозволяє **безперервне розгортання** (continuous deployment) для забезпечення максимальної спритності розробки (agility); * Можуть **масштабуватися** без значних змін в інструментах, архітектурі і практиці розробки. Методологію дванадцяти факторів можна використати для застосунків, що написані будь-якою мовою програмування та використовують будь-яку комбінацію із сторонніх служб (бази даних, черги, кеш-пам'ять тощо).public/12factor.mobi0000644000175000056700000114111415226251677013072 0ustar0000000000000000The_Twelve-Factor_AppS͋S͋BOOKMOBIs9$x+4k@s%B{D[F]H)JLN_PRTVXZ\8^ `bdfhxjlnpHr MOBI-0 T P EXTH<t j2014-02-18T21:15:22ZdHerokum Copyright © 2014 Heroku 2AFB en horizontal-lrkindle:embed:0005 ,,  0730-890adc2 } y The Twelve-Factor Appp1> XLogI5lXinYpm׾׾׾׼J߾0359Adm360RXa/manyask⦀-off/nav> TTwelve-FacppH

Af۰iHlways8erohystemuchѼhref="http://git-scm.com/">Git ,?ъXiȯ`ftehhenxtooi:jB.>Imultips,t'sa(--iibutȘ.ŔxpGePividually:8ڝo@`ЅMxqsamioqׂh Asolu-ؠԑdodentoibrarieshichancludedhrough@e dependencyanager.

Thersnly(e baseerpp,utA@will9xy loyf2X. <, >II.Ę͛Most!graؗlanguqackystfdistriupport_,shref="http://www.cpan.org/">CPANYPerlrubygemsR|ƀ.̤Fll//>e-wx (knownY"es")sȧdirXoHcontai _"v or""bundlq)EAwelve-fP@!nYelQhi8iXإZ/8ɚҞ,te(Xc`,iaЩ|Eaɩifest@ur), usKtoou(ecЪensuRatǖؙak"rom urndϮ euЇWspec8c°p0uormзbothϑ@otOK er.XGXBחМC<>III.ïigA{١GskivaryлHpos=X >Xloyغ`(hging,roduction,evelopernvironments,tc).hisncludes:

  • Resourceandlesoheatabase,emcached, r backervicesAppometimtoronfigAPsta@odeusiola fwelve-fac8,hiprequir8ictparރfrom"/res.rbS)$typȔeyȗsoYbdon9WppX!,pu?ɓ ckX0ovl.ymlougؕve @rاWr,⚐stiweaknesst'sasyQtaken` Aa?lȭ{;ɦten`c(ǯ sabdifjtlx8mamaitrdsemana is#Ȃ.ur,1langu@-frwork-specifĪTp߮Zߖiabqa׼.@jaws椝e0maHdheiwalWqjj8-wݥXult mbina`xxzϸP)r}I!,granulapefu Ȧgonx` 4nr˪JgHJ?9,"iea!ptdb2Kadeas(moPɊurIqQifR/sW> IV.acServi0AbۉyxL^hsunȯparʈnl aqxampincludata (aref="http://p.mysql.p/">MySQLM).

    BackzervicesikeheatabaserraditionallyanagedyRsam(administorxsjapp'sunti`deploy.nxoxloc)--,Mylsoavprovida8hirdarties.xamplPincludeMTPpostmarkX.comP,etrics-gar/-newrelicNewҀ!rwww.loggly$Ljbinarssetaws.amazons30A3aevenPI-acsibleonsumerϔOOJdev.twitterTsI,Ǖcode.googleBapis/maps/index.html">G ̀;ooiast.f2hkT拸awelve-fac8knobeH𕪓ʓwyh4ԗ:xotКattResourjc(viaURL/credehxiPhile=X >fig.772#fj}shoulswaput{MySQLGhne8ggWWrds_RDSnyhangp̧wisexcqp <-ceuOzTjchonHApndЎSeed:E0N/i8 R=p!deWStlliGsisbedupwiissuǽimighpXupX / V.uilpeHunǬdeY(nsmʎ*(non-elopm)_roughAe:"ul>

  • akcӆ7X؇ul(gXtainгϛM dyimxi1;environ76(also"time")ۯ''%,launchBomQte쏭gs ctJj|/03CbekdDPۮXong sbePeK6WQ ztimsihm5ݐL, c(heoao9ت9L]DtoolHypicyfCmanЁO,ono3abilitrroaeviouѯHxf="https://gub./capno_o/wiki">CZUntooltoreseleasHinubdirecyamed 

    Eve5shouldlwaysave0uniqueVID,chᇙtimestampfʈ(%2011-04-06-20:32:17)rncremingumbergv100ׂ.ґa@append-on`ledg8acannoteutatoncHta .nyhang9st̔newgcBuild initibx'sevelopersYnprJdeployRumexecution,Qcrast,!utomaticalc'serIreboo،Aashprocess8tar`a.Ԛf`,sun؀ؓ݊xkepf(movYp sossibls`pmsatBrom)nqcauq b(kQmiddle5night"oonh⍩$X plex5erroĈagrou`&pori /sЎЀW> <, >VI.Ўh2wq3wqERٟonr(tX3 >Aq(Hnvironقc/pIsiiӘ0tH-alqscrip߃߃ۮJFloaptopitȤ1lngu Xi,:X auncyvixXex(pythmy_s.pyo.ϖohsprumXduAophisɚQmay ٳy Twelve-@:Yh="http://en.wikipedia.org/q/Shd_h_architurs-tDRdat@neeXHiPhstefulAiceypdhbRmey0HIsystem%qbriefgle-Xnsca.ƔW,ownloadQar(`ixهѥEHul|isƪ"t')assumғ[ Tiskllavaila0iauqu1job --װep*幈(Ph߂ۄ ifft.ŵ(on誉| (trigÿjS@onfiشgrr(enX'hysʳ)usuwuX(e.g.,ͨ)ӭA`0(suXXdocntcloud.gub./jammit/">JJ).gooHp/djXo-et 8I)z2br)8񆸎AgfpYdoþdu*uil񾨡 ryanbhZguides/_pPy.html">R{ܤб8 ûSomeeb sɫL_bac%28!8ng%29#PseX">" kP8s"bir=+ h!exA sromSahvisirؿ`S"aolYhouupiuponІ䷒d9diؔ:[o񼠎(-iS?ǹó">M_Os.ioRY?/sonW> VII.o bi(h2 ><h3lign="left">Exportervicesia binding

    Webppsreometimexecutednsideebqerontainer.orXample,HP[mightunoduleUAjTTPD, 8JavatomcatTq.

    TXtwelve-facts@tely@lf-d\zhost:5000/endencyclaraQq:ddlibrarß,uch www.0nadofPython,wtQ.macourno(.(/thin8Ruby jettydehausJلoXVM-baslanguagXX@hen"u bacj>a靊rovic T ٻres 39}fig8sui/sW> VIII.oncurrAuthgramn,rephmoЬ׺ӡHtakeQvarietfU-行mhFe,HPchild_!Ahsta`demxeedolumX9pHikZmassixu0eRAȽqgXkystems (CPU:meXy)ju *}nd@nÑdbxXzn(es) q"impytwelve-f߰arcl㯰zen<ЖNromadam.pokum/past/2011/5/9/@ly__unix_ _b_to_web_񲀼)dan .s3RarXthioeeXȚXgJea!9p(HTTP6ya lH-%Agroutask)畚󿱶TQdo`hXual ownvultix,׉insitiVMcasync/M9oolsuؾubymine">EaMq,gdtwiXdmatrixrtracTˁ(/+njs.org0N0.jB8 bwo(ti)[1mual@aspU{ssesunningnultiplehysicalachines.

    Throcessodelruly2hentomtimeoPeut. share-notg,orizontalpartitionabnaturfwelve-factorppeseanHhatdd9moconcurrencysimandeli2operaarraytypnumber犹e2!knowniem>=form:U,distributed̕xaloulat1,aolikROHblog.daviddollar.orga1/05/06/introduce(tFsin䉰lopment)sזזҗput heamʊAspoxcrashesHhp`user-inaAshutd/sec)W> <, >IX.isabilityLs('". web,wB0dHќo`nxv(prexuany␭)Hllowtfshn@xngictmlthHTTPnA0AGzepll#li񜭰8satHptonn֚`xlostM$ork???Qtur0! ueCexae`nwww.rabbitmqRzMQ҂ se772amqp-0-9-1-quick#bc.nack">NACKlogicalonclusion.

    <, >X.ev/prodarity

    Historly,hereaveeenubntigapstwɃt (aUerak0ieditsoodeploa>f)pp)WӃ@runnopccessedyusers).hesemanifestnHre0s:*ul>imҁWPyork codhatakesays, Pk8or Hnonthgo ?Psonne6:q{sxeHen0eщ$itoolsǂǂÆbe8qackkeΓ8x,QLГ{OS؇xh؍Uxspach@MyKLinux/! hlve-fac(BisXfВXf="http://www.avc.com/a_vc/2011/02/thous-{.html">ԚzpkX #smx葽LooɓꚂ`cribaboveg`MXL:x2&it,houP=jumtHlater׃ǟ7hoocloselnvod9ˠwatchiPi_eGASummhz a8(p>TraPȀuGsLWH Cuthovs{.DiffpeopSa0Iev)'viIwverg:"A??%ǭǭBq`viPuchD'yasqueueystemconXAtXsmpor.anyngu0brp8plifyibυɃ边dadaph dtypj.o@exaPؘY )Hlow(8headprth>TDHـRuby/RailAveRecord">PostgreBτ>Q">Pyn/Dj(oφ">CeleꆯabbitMQ,eanlkd,edi4wI_O__O_SupI::Wemory,Ҙ}z4/EssP(He`Xhh1tiocotsa XeAi)robIWkwill.ƴC,ԑ#ӱAǺ;Xrm,Bϼ͊GD4TѮx7resisuAǢ\77JH\shelp.ubuntu0munity/AptGet/Howto">-getI.l nhh8declarzvPotooloDžwww.opscode.com/chef/">C8nd PHbinedithight-we9irtualnPonmentsuchsOLvagrantupVllowevelopersounocwhicloselypproximate Pduction.he0stfnstpingrusQtheseystemsswpar`enefi*H/q it0continuous@ployq.

    AdaptdifferXackIservices xtilleful,ca`yak0or@oew'%relatiHyinlesBut!sI (?8,Hag8,n)hould`amypv`eaP\gc/seW> <, >XI.ogskHyvide(sibilAinfhavioraQnpp.ner-bas:1monwtenaile disk (a "");tha utpforeyRwsadam.herokupast/2011/4/1/___not_s0sBggregd,ime-ordsllࡸfrom tڗP@s10ߑ|2airawKypi@yexone|e (t0ghtraх*excepsXypmultips)DeoxbeHenif+aBange<8>Awelve-factXinrYcer0it(frhsxzǗpɘ{88mp ooymanYLhIeaۄʛ' ,nbu‘o F)availrpurpose8yPQcȍ,watchpvixeap.osȹifntly$sindexퟀlysyHm WQwww.splunkJ">Sjaenl-ataHresge.axhe.orgHadoop/HȴASlqppowyfX-qHrP9,clud:ul>

  • F QHiLarge-seaphZrhquPP)7A𳰂(rcc٭uH-dehec"hequperroǸbea XHreld/a/s)onW> XII.dȲ-esmʠjrraR& ً2dow(gularYѤhlQweby Separ鶆趉oftwishuȑA@enan@뤻$tǖȾabami;(e.g.׽׽׽Ѯ#.pyncdb'&)Django,rakb:SȂҫswNo(alsonowxɱ7en.wikipediaq/R8-e -pr_lEPLshell))عbirydH9׼0delg`lɋ$luhrovipa Y02yrpr0ithoutnyrguments (e.g. python< Runningne-tihscripitted8tohpp'sepoߋߋߋphp/fix_bad_records.τ/ul>

    OoffdmpprocesishouldeunIa0dicalnviron1sregulaa fil s=X >long-`jF,atab`igDGGGrakeb:Sw.ikewisaЦ" m|VirtualpGPvor1in/bop9Tornadoserverr٬___Xage.pyww'"Nwelve-tstgly8vorsangushichvHHREPL@eٞ4box{mAit PyѢqYT.ɏloіlohdevelopeinvohWS@iq͢Qcheck9{oryducc ssh8remo/2u"manism]0ءqwWsu8a{/sW> INDXTAGX, @18IDXTINDX 00oڀ0102&ۢ03>04[05rԁ06 끀0708109G0A`%0B0Cˁ0D0E&0F>Â10[や11r12 13ꂇ14115H16`$炊1718ĂIDXT*9HWfuThe Twelve-Factor AppI. CodebaseII. DependenciesIII. ConfigIV. Backing ServicesV. Build, release, runVI. ProcessesVII. Port bindingVIII. ConcurrencyIX. DisposabilityX. Dev/prod parityXI. LogsXII. Admin processesOne codebase tracked in revision control, many deploysExplicitly declare and isolate dependenciesStore config in the environmentTreat backing services as attached resourcesStrictly separate build and run stagesExecute the app as one or more stateless processesExport services via port bindingScale out via the process modelMaximize robustness with fast startup and graceful shutdownKeep development, staging, and production as similar as possibleTreat logs as event streamsRun admin/management tasks as one-off processesJFIFHHC   %# , #&')*)-0-(0%()(C   (((((((((((((((((((((((((((((((((((((((((((((((((((E" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?(|M뛫B3`Hb>YAk͡x; BG^K);GmIwgޯM3s:uU('$;- u*^Ļ x;-ݦi XjB!mVP끌qrj?^0{ֺ<T{Y,;r(NG]ͽj>|2ƈaUbX0?nz O<i)-.u Kcwɱn;+@+]f/[<3haY'0c*߀y}j{s\ozOčR:"+ c ;?uxVڍ\ǀp@0423{ >.jVTڳ2Nҹ⏋tMw2eF$G,p99}GEx_:Dž惢GtLi6N7 ĀO`N;W%x? /H^y:ܭq-NWhc6DuXdQK@Q@Q@Q@Q@Q@Q@Q@g'xO֞'3,J-r)XZǿ)^$hf@^uQsi?ʁr<^O>16Y,X^6 8=QHD$n+`z{u|3hwI.٭c݆n }}++c:t'Aq%r8rGZ??^kmi\]h 0$֪?x^EYsn{tAMlj/Z+H>PqG_5ڝ?j,Z9'֏#?w~&Gtx#KSEyg}'8-zY22_t⦙U3yh g\omZ#"E #z>>֮?A;CZQ- ;Kތt=Mr|S׋+(( Zޛic6pX|_x4^׼/uh;c{jHR#$}WE| oC⭗u+[x_LMZiBpXS5huo?5IjאY&rCG ⾑>lO<1Yg:xi z0 )>:^(/ x2 Qh\bO}-E|iܥ*Y?,[ )!;R׼;5͕IK31R`s#_bQ@CMU߉nu? ?Qm:lpv?y߇^տ5h7ec"N0ۃzؔP4Ok^#9I֭ * Y F3y^iUl </x`G9I<3_i@/~+h xu6^cOY; 9>GLQj6v:/]fS$!ɗ|WTP b8J(P((((((((i]jß>Vn%Uf$9koZ9&,~5QԬ1#Hf'W]X]kX'eH?dmಶFHO|e<0˃a?mF%5+; 6{P SS J"T\NTH}FjI#IQDWF @.|V=c]^j8W'85\:Wt5Q`ֶVSP*ߌ!:4{?^@{%nK#i=^hhMzſo!)>|Gg-w:݆?7qh^u>s_SVٹ+(D~a.YI5sektTA1^Hcu_[ ȏIR$rqd3{"*E `0-QEQEQ^'>߈O~}r+tr1vp=Š/$7/$7诞?rLI3?rLI3/$7/$7诞?rLI3?rLI3/$7/$7诞?rLI3?rLI3/$7/$7诞?rLI3M>{w!YQ@$ :>z_Yt)#!sW@Q@Q@Q@Q@Q@mlo:ƴKmʩ gx&fŨhE匹88?PhZ+Z?IG-oKe诞?k|\[/%.->xslD_J%RQ [)(z+Z?IG-oKe诞?k|\[/%.->xslu}<[- 4>f^ GJT(0I?Z(RH#f=@ _<\(襬ǏFxg1jO`Hd{roeXB=s}E| WȟG-_K"}E| WȟG-_K"}E| WȟG-_K"}E| WȟG-_K"}E| WȟG-_K"}E| WȟG-_K"}E| WȟG-_K"}\o$0U5?2-%uiHqz$0U4~˟C<7o?Q-zyW$3תEPEPEPEPEPI??khYkGI??khYkQEQEQEQEQEQEW؟Hʼ7F?~GD?ZGQ?PGsp P-ݥlPYY^f>3|J n9*Ap~Mȳ 5|u]Mԭ-~7Ii1šr|LUyW>&*h3U/@DQ_;D'%WM}E| g_&\?^~r4E.OJ?9?r|LUyW>&*h3U/@DQ_;D'%WM}E| g_&?/xYеNH VR@8o_^I/?qyg8o_^I/?qs K^^U. DQEQEQEQEQ\ OYG7|.[95kۧ 'ƿ$>|gO?e"Zo|f*_n&?5˿D5թۓK^^Ý r{) .HzA!S k=At-ouo $C9#(_&o Zq}g FNl׫~w4I9gYq $l IWW؟H=o(Z(w:'x֊CIESW{@o{E OCIESW{@o{E EPEPEPEPEPEPEP_<|!ε=|Ngg:7|*F?I|a`k>7|*F?I|a`h?xoZZsHgJ%U(((+h!ӡ`6iq-ʱ#%yŽݡݭȹNOBW yx⮱>.M-}pǾ(bY,y$5 wWٮj[_b~j̇tӭ1ì#Hj$x~om} 8|gO?e"ZogO?e"Zo|W/'h}욄WgmһZ(> I .;kMlN:p͝ŷPAvZ)iZul-l-! X=F1AcO&tY3 I #,d p9JӢ2"΃ #CiqL.`8o~f=LS}J=:5kD= 'PCxgAhgM,LwgZxC'33hQEz$0U5QEz$0U4~˟C<7o?Q-zyW$3תEPE5lzC}k;*#;UQI?ƛOX>GnumrSKt{֑m{y3 z4 x@>c<~b}X zG2džc ͏z'(cc1M_h/6?蟘͏z'+e ǯq4,xo=~b6?蟘<7C} ?&>c<~b}X zG2džc ͏z'(cc1M_h/6?蟘 O}<7C}[-'5\sP;E`kEhiXX[Z[ɷbL៶ k4@⟶ k4@~kFrc6q Ԣ>li gVD-~Γ}4F'+GqFƫ>,\.&>g;>}ֿݥrFƨB45]Oٿi/k}QoK{ZvW[ϵ.tr+wME'ٿi/k}RoG#3ZJ?|qDQ &_"~_3sԴ4/?߹g_ci.4K*MG'<ި(xC'33kzu|nU]GW,ז|nU]GW,9. D_ K^@"ff8?-wYmSV|ڒ. Bx@ſ'_(t-_uSWWw~(k1xEeH@x"/,<)t5uL|.;=vg}1^@iVu6v[Z¡#% TQ@Q@Q@mjÿ|C鎩{ihB̻c o-͆J[+/Q_G=پ<ox?_?  ?k C>?g?5_DQ@;=BϢjGh_OsWP~п3}UE#ߴ/ '9ƨ{D?}E| C>?g?5_DQ@;=BϢjGh_OsWP~п3S.Αm"&`T4rX܏,q=:eV?-{ݜkH%ltV8#4Tzgm?!Exw$詫= 7x$詫= 7Ch}{Sӡ## =>5Kc3G͓HX·okԾ#>>!i^"[ Xvcڸf_Uƀ<$i4j1B'8s$Ovo%XZ w'Oo:û[ЎI||Õ p1ֻ(((((+珄?s??־>LwgZw8o_^I/?qyg8o_^I/?qs K]|OGEUvq9ꎬO\y҉kMe~-5C F #"!H9{+WƟ%h7<1>Qܞ+޾Bvh5 ;yt+OxjO jKF>%ShɌtQO6?}V(7ī!KUգwnXR$?1@FQ_>Ԟ\ GC-O|Fͅk~gǛqgzٓ+,=|6di^=@hsX+y a$NK ,x<@XQ_4|>4@dVO麾5+:z_hzt Ch$wſҩ~D-\$ѯW~<ox?_?  ?kEQEq_FC N<8 R~PoEyF7-̈́dQn ªxη>'CzadUY`"/VFuOgEp_| }ieiG5[.%Ѵ\-'އu{mF!ˤC%к8rѮG(/JSNo5>ϥ׆Tx@ WPH'riiz7)C僂NH 4QEW-/±k eV?-{ OQF OQ@h(?*jMh^)h(?*jMh@_oj,.Mn'14oqWc_&'OyX](|iD'ƟM?9_ҟi|4}O{o"nOm[dYh7$M' G½3PQok!OF%k ׃J8pF]$wſҩ~D-\$ѯ@EP_1|C߉4k~Qe_G/;.-lϵ}P}g=)=*F#">R}A, 躇4ɴrKLD]H3V,|b@J/G^ٰ-OӃ^ h04ʰԢ_ h|@k;)`Ehѫ)n ztfֿi}"]DφE*J@r29QHPx{?xHK׬I#r}z]̂7IB #1(?iEK_@W-/±hB4BCIESW{@o{E OCIESW{@o{E ^-H{OסІ;_ Z]w+.qֻZ]s70v $q^ OIb$̹U(w-:_?]=EK- ;\lY_$$ctq | zW~ӥ Zt/f_c | zW~ӥ Zt/f_c | zW~ӥ׼|/<>5rnۜrOC | z?ϖ@-ߢR c?75:-Cf_cc c?7CE4:e쀲@8W5:-C|W օmw*%:ᔩu珄?s??րNWu4WfK\^)N:Z%5)գS#*˙RZWWSXdPy. D/7tvl6ͻ9,G]Urm$Vw_2S,_NؚٗS=W}|RG2p$c? z#ᶵrxB 4WL劯uWޫ^DNFC[I]fk5H%fUG^g>k|)ccBL60#^Ѿ@=?_tψve#\]Igw>@Q@Q@ǟ#-Kp'o'zHp&x3DM;Vi}.#ᐙǡ4W _?G.6wW _?G.6wW _?G.6wW _?G.6wW _?G.6wW _?G.6w$K*Z?\?m oڷǞG>喡uPHA?LӺgm?!Egm?!Exw$詫= 7x$詫= 7ƍkP$:Ɵi}6K@:O >cE(±~1D_1[|2c|Wc4Vi:J6g`dЬazѯ?h ?h nO^hCdm?(ֽ ( ( ( ux.VB32L`ր;ύp Ѣ5GţzaA*a2#+ps ((^#/}R!-M }q>V3JLгmgßmU~0Po7Q z(χ?,oUy*?TM©EA@ 3 6?F|9f?^{ ~0Po7PŒsBͷ*QYW©EAG*?TM_>гmgßmU~0Po7Q z(χ?,t+ Z33y*?TMP~+|ڗ5yNMzYh"*\C;`u8WG (rS<#}}uĽX e.[=na"]+yY_LQ@–hi`Y_oT|+Yx/@|Ex~ ?{x牰W݇ 8PtSƭYsC%r(hu|Ws_U֙e ?kTզ׮O$rI;N:Z( ( (4Q 2+UCWO|)|? 9N{U' *اNnp|@EyomصFŀh ψXpV_aB9+_uM\Yu )p {?C !} -R,b%=13@GtZ6j kjyC|GkRY>]]KK!&$^־ ߇wӸ:-@COk_[e"/tF5u?_H]'э@EPEPEPEPEPEP^%_fK=/Az?HRG?HR@Ch(?*jMh^)h(?*jMh@袊(((oxEoC[JܱQՏFG=u(Tr€=ǿ3[O;ZpJ1'4D'޼U |N+CI:i=k +O7#1hU½(8R4UT`x_g j7&d;ids~'h6kk֖-O(((((((?'o~-W_ xZ c[?BX9u)::d}+ _/QЯ0hL)~kf/]K-ѢHyxAЭ{s4f]=,KE{ d=J h}+^CYs?'/P.n4]gfÌF5C{im}m%W !yoHỎDhX>VVkVwkZ2,P0zjV]H]M 33x⟄3˥꺄Wmm ee 9}jFwKwmnN֒ NU Ğ^|LӼ9.m9c n̬K$?g6ǃ>+xJ&密쥎D?FSwPO 5/Z d-ydb3Eo>1.HmFi"Lj!ݞ<Bn i$דMZW~-/{-6Ap97:pyUiOo//cx $qb3ߚ]Kbt2JA$ydn݀xkQ>%eޒ]\"&AAt5u 4 WL/R Jb10Tp`$uOK_3^^%_f=G$x{)h$x{)h /|/2pU sv'H~9;Cl,_DGc _H@=k k%B7m`>GU4^%v4'PчS?uWgn{? ~%:#ۯ> Ts=JQ.?Piwûy5v1@E@|=QQ#ɟ /;5l֖pc ڽ{ Y4 ʼE>$WbBPeu%־*> ԛ mF%E{iYivZZD60EQn((((((((+OD_4mdXu8Ia.M^zBk+PR1ZZݗcKKgy6=9V|V{_g%-LpF`ý}@Q@%+lOW)IcWYIo?khTQEQEQEi"ķ D/bXn.C6@qt^((+Ŀk#׶׉~G?Q'uZ('uZ(r((((((((((((((<qh60xC>gww ?[|5wQ_|/bB5Eп >?[|5wQ_|/bB5Eп >?[|5wQ_|/bB5Eп >?[|5wQ_|/bB5Eп >?[|5wQ_|/bB5Eп >?[|5wQ_|/bB5Eywk2o&URͼ99e/._ rx О*'uZ+mcEH*(P0PEQEQEQEQEQEQEQEQEQEQEQEQEQEWy W6v֟6/Cjj(g/<ڋ [G# pkի?zώxF]Z': 2H=wO/CNL Kil3W\s%ItL#ů28ӥ)W$x揯77mc#E{/$.tʲf!s([u?e wZ+*(e wZ([u?¾>}[u?e wZ+*(e wZ([u?¾>}[u?e wZ+*(e wZ([u?¾>}[u?¼+σ'U.$K}V9~Q_fW~Kl'=Db51%dԝM @{(Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@6hıOT}ֿIqh2y%ؓ-V~~᪝'/$yվ)_E~IKG*++ b+O?Ke?LwqiifhF(>9 wU4sGZ_?0l٧H>J(;YxK$z%_y^BE8;NXPQ_/|;ͨ Vu kTM_PCmk! ֻ kJ.j5~!# u vl3[tbYXUݿnuSG^G̖v m Q=~g$-bet=;6 5[=kb#lJQyѠx?xcGZ+۴/zr+*([lEu]&K9-<.ٝo}=Ro=ԦoZv@0@#:(k: 3ZZvt%7Пs?|i2xy%<>y=; (N?%{x'$q(t/i(B&^"EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP I/٧H>Jo5om3D]x|ͧx~HǀFnZ+oj; sZ?t5h+oj; sZ?t5h+oj; sZ?t5h+oj; sZ?t5h+oj; sZ?t5h+oj; sZ?t5hO?ImrUj; sZ_;]Mޭkp8iT0l+.9}OxE;FFGE*jzqE\(((((((((((((((((((((((((JFIFHHC   %# , #&')*)-0-(0%()(C   (((((((((((((((((((((((((((((((((((((((((((((((((((h" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?(((((((((((((((((((( _F~&;ճF g%E ~y4G?7Eb?H?߂>?=݄SM)wPIp@ ?/D|3qUP W?>Я  G4G?7E[ x.Q  ]  ?/D|3qUP W?>Я  G4G?7E[ x.Q  ]  ?/D|3qUP W?>Я  G4G?7E[ x.Q  ]  ?/D|3qUP W?>Я  G4G?7E[ x.Q  ]  ?/D|3qUP W?>Я  G4G?7E[ x.Q  ]  ?/x/tsjolC 8FB%Jzw1gCc⻵Ӯ'Au92cM ?>(((((((((((((((((((((((((((((((((((((((((((l$pNJ # pO8'%w?C;Z( ( ( ( ( ( ( ( ( (9MY`?mgb_$ş /^A6,&*((((((((((((((((((((((((((((((((((((((((((( a8 +)$ @~?H?GA h(((((((((&6gnKא~M ?oo&DyO$Y蘨J( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (Ϣ ľ$|95v{u4[U|*SׁQ{#_ׅq,!`TW!pNse5+"[V,y2QH,@R\yk ՜Om:,KIC)A_#xZWni3e%Skr%v|kg$5|{ \o,|%[1k2N9Uo]ӏ{fu o ,eD{$RQAaI$u<"u}D֏4urAi,e3RS'+cLӬ FՂ\M< IܼQVm.`hH$! |q:76?oXMWilɸg6㴕A{X>x'3ƹ^_ W!ۀ%:Oo/~"4FTcDY\csQ_={Z#ZXG4p:1WwsWֺHX,0d_Wt[Okm/u2ę=15xwl:gV}_&Бg ~<1"?heUA!\ w3Ʀ~^/ J"YZ< QG(Fv+4躭^^{*GU&7h9D!D#cVʰ> #[4jwqxH7$BѶGglx?<;k'ғÚ\^FU"p8O\\^}=5(|OwdK+oQӯf\':t]k<;ZxtR=.KǡYt /[ ims\"5b0N\=G;Rִ.Sl/_˶t|X`g%>k_c-J( Z+ǵT7LdOTU6½V=?~y{f{U*}zx=ΟJQ8IR@88EQE|Mm藯 k?z&,Mz؟Iag1PЕWVK{ҰRBrF?LXI $g!ƀ>lujWnmo[OH\K29૟K|AyBW+H괟{k(b##/>] aaqo%E  '~[it{|;M`C3ҴI(9;M&CQkΠ$GϰyTB9<'dr>T|#{_\%%W;USo102rN]c.hw˨Cue[jײȡY+~(@|E9VlN!Cd;Np2q5f:-LgO2 2n_\0~"4(((((((((((((((((((((((((((((((((((((}wĚnski{?}J֖3-ɍ7N=H+#?3=K-N+V=ҪBmPU>EO8'%w?C'I?@H!`?@Q@Q@Q@;dU~^%TÏj&^<1 w,4v/Ƌkĭ=W(jƞ lF Px3#!=v8=. A wh䄅 l9ع8$_UcEDMZI %eAO" )˖\qy.z|Ñz |*Ouֶ;e烱YN2>P83Ox/|FȦӵWz\p72gbA!8qx.{Oz/6{o2WKKмQ|E[/cj1B@;1F|W5MҝC:\.&8"X7dG/%\ Xg^8=I֚E㶊6\;A\wk|y7ÿ-K:w8P7|8N((($ş /^A6,&*MY`?mgb.81;)UFJ:W x:Kχ~0yr&Vϡ("+([|A𱽶Sp%F G SDn1w=-{[2V +μ[W^'Ň;ԅIx4}cM֏Z_L/P yuٓVnOmpq.YhT4&YNr>3q]Yܼ-$jەYA)?ſ.uV-+UI++JhH@1$U*1/ړڎȼGh"B?^w0֬5`]O-oL2^'tcê[a̜ H91xF] F *cj`gp0r8&/^4fN\=G*S,Vn(1qcxw@XOg2H1ܩ?±2 2$p8~?H?GA ?l$pNJ # vQEQEQEQEQEQEQEQEQEQEs_x7%?b&D^7I?w^'mYLT%Q@Q@Q@~x?Ż^ʛ&7챧i w$wCP}vpƾ>M?6'4ػ ~S OfƞKCe_ 'c.0 2W"2|%7,غ,[T|1uZw6sD>*XpG ּſ=xzEB~W'?7ִAPɛ2h xsL֏aVP x/NNI5hӭO (8,[>qioB[uZ }^/>ĵaoa>o|Gĺ?h״-b AeyK$u$u@3^[o i#>Q>tQ[420PB9Il2 Pj;Kkq* P6Sa|^<]6axCL[3l"KɂGd6x7cƖexU]Ŵoqo`;P@㓎MXÿvڌrl7o& Oke3wx6x_}+X&(Te ~[2+/N#{he.T0$g׎||T?΃w梀:;OIV!m+ݿMnT9# 8=3\ Ýj[ u>H=c֭Z& 8t}߼?=vhu[-F,d&ߨ ՠ Y(dW5Bfgyt+(mꄜY{1$0J4PU&]?IPe(g& */b98QO5;-cM4n]M VP( ( þMF`p d}q@UuFLԯ-!U2@c־;Pf{H|F>ȥOB+}WeJ2\?{ޒX\Vw\g0?RjHY0Z}սjy`VG{\MM8mn&?<ѓ?bƣ7p ՘j˂E7}oBb4`:y6Șjpc/0x u\i ׽q_T@*H>i|~Y붏j^BێoTPVgVO]Sx&-h#uJ'N4KaW+~x#Q~؞QJ{IS!Sq "ֻz&]_OEIk5Ơ F?F%JGNk֒܋w ɰ }1E|N'tĒmAOκ>>ӎCy[">0 ЃE:((($I8Ve4k,Wӭ͹Dk*~ țB;J[%b7xkH,5-akLN /+󃑑}\ fGh؟5iMj]PX+.45bt$yn$ya*ǀA<"ѵjhח PͶPO89xv~t:е{ys<a Xw-.t ɓ$[[ \ĤpsR|;6y _IuOQMwL AelM|H_ xmNpZOڀ31,NXry>{~&Yo{=VX7{ePVlxwy9#`#P_jz.A\nOXa[ҾjtcdϙGf#\"ޝ~*}j((('I?@H!`?U5#%H/uKtޤ#ǚ?f E(mTFUG@V_*8~?}UE| Əg4U3??|qC??TWʿ>8hq@UQ_*8~?}UE| Əg4U3??|qC??TWʿ>8kοoO 1?{핮/R8^3W?>8h+_g48~~&6gnKא~M ?yfK/pUr+پ9ោtA/.n2UP''g>QEQEQEQEQEQEQEQEQEx7cm.~O\ܡiyTKMek|oơi'zbQjƊ?$u]Mo"D<[K&r.Wp^ *k -lili1_7C +ҿlF-CǺ^aj=q$Q 8TR?ޯ >Ϥj2go(?] 9p&;FWc_^о!hZž ĖМ|##n_t=^HR?W5FO2F?Q_)~xCQ&qgō(_̛iws8w&6gnK J{jvvi41HW|N8rC@p_%wpKo'4RTަF=pmhe? ̇kN}}2h+ɴƤ>%.d\}Xv:oj`}:$^'4QP][&Y?M@Q@Q@$H1h'PkkؐEz=_Í,/`EI՞V]D5 C;%,. Y\FӚ,}y nj<j?#_uɗPU$̲yRxE :?Gh|3_jghf G>.gŸe cNvʾ🀼-(|=XٺyOFM@)¾>uo07SKu"?fjw|u-d]־>h4d.@ h,A%ëPGWx|Y6xË8RloMx^,abV_ePF񰟒P 24Tv%żSBۣCdTTw"cm(h@JA#>hƿr!Aө 떞%曭iM :r9SA]]iZhFm.v"$9,H : G㟇;eՠZ\ϣY2iV o cY'[Ե[7G{h)eX'݆!wQ@Q@Q@Q@Q@Q@Q@WkZX|;I'IeH`K0UE$x%|?Q|8vLo.˘䝔&2OF2ln"l QK\Ï h)yq{H1%vW'GAtQEQEQEQE`Luz3jR }=FFFG"'|տ𽥽#Ŵ7lB$ qc#9=cUźՆkmWx'\␖٭ɶl1S|iozKը$yv ӎOSs YV昳-fP0H HBElQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE|Mm藯 k?z&,Mz؟Iag1PЕwEc٭~V.>jQ@Y|qcđo\~*>rZUIG"`?}E|s%?R4H?C K^4m4ɍ}UE| /_%ƅ#sz?MU(ߋ|D4??᝼u!?Uˇk#G;J"Q*x9܎-z$J_"zv#m{WhjJчx4K/w- I|Oz6gB⼣}Ht鴋ɧK`P5σ|jY#cPWc_G8u*ls4:77zĴ˟试#cuEBշjqzm?kx zR oi{~iW~<z1M3_N.zI'PTWʿ>.\if]Kp^u,+uF}WY/Ddu?O\g&c' +wA_cMD6εKLY|daf.O(sƿtt/CsݎL07H> _^,Kx[=6:(`؄ sMK6kNEgPϝW}O-}i+g_}OZ26V.=:e5_Xڞ~ֱ,T;2xƹn[8DkV!Lש$-3?>K+mjv2Og/( QTKlF@99n+? }O½¯ rw@[? 2HpPcOٖmBSWn5  ngk|%xBm,## '97MoQ@Q@Q@Q@Q@Q@Q@Q@Q@6VA8M:O_mBX!ƣma%P72#9xo -&4`!`MfYQ^3k7(eIXch\|=I((((( z bպ__w>|Q~k#-?OmyWĭט *?o!?gO IQ.1 Ergk!Кf. Rn-0Wy?ĽcG>&0K[%C'5;YMN[9#;ke%@|=i!G0Aq%#mkNZKEO@Wy$}!?Z(?䏯'KEgK4 E'UO$ ^Uk,ҿ5W?D%uTQEQEQED>wgPk+DVhGq.zEQEQE/  U/  ~^LXW(((((((((fK{yg9HлlR̀2p$jJ_'2_9 "{#BWdp 8;} 6ԯ4R{[bOH1'xΧFm_G]1ҵK`{V-#h`A ;>!6v/m$7J:̊|Ǔ9%)v+8cbX9'VR᷇rc_R,Ww#?g/w7x$/YEq)n|?;z_|P\"=KE'ejV;hYRnT*WĞӴ!uo+>P@kjĢql|gּ5(Pk^O@Wy$}!?Z(?䏯'KEgK4 E'UO$ ^Uk,ҿ5W?D%uTQEQ^1E|QMᨼ7e]ɪº#.^aW էZeަl,D0l `nNM;{>#ZkX[x)H-!cŁ;ن7gzj+|kk~đ,}hV=ŔQ8E@d۰eL2xהƿ^i{x}GY|#iϘF @G}1Ex3^AhÝki Iyoıx?7_l-1H~c!8s+?gď彌0jhfQc!r翥z}QE/  U/  ~^LXW((((((((No:kHZW0DdppO#KḴ*y#@z[C̞S|Gܿn-d+N4 + $?+\߃UO3Yo<+p0YPברZw,n/2I3}:lm=Ɨp*| ;rUd`AWno1v4GM$t_%taD4L8⽒Mmb{ixzES7Y-EbYRQO]V]4%㹂;y&edYUT!#p8(^ii_i qi:T9 ?jQEQEQEQEQEQEQEQEQEQEQEs_x7%?b&D^7I?w^'mYLT%Q@Q@Q@Q@Q@Q@Q@p?*$P_O?c#a @+Q~,olBW~K4 E'UO$ @UQ@|QAE_3T?9mE}YjVW:cysde#۾A`JtOۯ4@~x{@gz @Q@Q@Q@Q@Q@Q@Q@S&8!yfu(Գ*$(Ki?5HGw?>F3W7&u_x?]nuy?cymUFݕ;y#p8jv[Ϳ Af=O!?ϨF=#ᶓ&ך{n.t`*U+p`? յ]A`n7M݅66g&0@ۑWGVǐ/,i7rA (S;?{R16_{D7&a0ݣ\}Ý7῅O5{͸ioE?4i^ͮE#pt4Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@;Fn$hP<B8g_?-/RF ][z0Xτ4z}_[I8|p{0Egk>(K P<3FH% B \ʞEr>/Ѭ.nc/Iݝُf&k+NK/kG+JzgYu yW 0#q?t[!{ 7,WS*)ˠbFq؃@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@&,Mz؟Iag1W|@~$C%mQ05߱F/uMWm3.P2=hz( ( ( ( ( ( ( ~:wUW~zޝ|#Zp}lѓK#`aGSP7_OCv4l=FHːQ@_+Q~,olBW~K4 E'UO$ @UQ@Q@Q@Q@Q@Q@Q@|p¿?|p¿?_׬_C?/U((((((( XSG e7HF`2{@"umW¾ѴxZyږx :~ rOnj/^+5m?SUλZy/iwq wt_L׎<3me麦gٱy HU 1א H4}R =|VD %ʹYNH;@vut?ś9CI?/H[~^ѳ}O|T6qm_/dYcm\6?gRxjK<[K{d&_Ng: ?iX%L9_%{`+h ( ( ( ( ( ( ( ( ( ( ( (0gm'ZƏڭŜ#FݝfBE|ayٳƿb%YG%QFb?|7xADr)v"2-;GJ"*VʪqCuRq"W:Nv ꐙl<hmHng#q9#FO]j %$L`?}⇀n|dӵKY-Ia:?Xljm͞}veiad+u dfjþҾx|IT4X,h~8Pg=qOLzO2[MZ]ޡedU9G4EQEQEQEQEQEQEQEQEQEWgbOx hs3C'eld}+(举%cf5WӢ3Gy_]jo]kNOV ?JC r^ om_Z\ޔ@# ~+Au!?km;R]u,5MSM' ?d}_n*'Y殿ʀ>UuƋ}\AG*_<b4"S?oу@UQ_*CKGw_Q kLPU ս~eAp5(/~ NBiYs}4Pjwee,?(I+iiN}GVp>lc\6~?߂mkfΑAk>?Њ5yt?J |WO /?Kk%ϠW?EwQEQEQEQEQEQP_^Z[56/ޒi(O_2}O-w6< K;ޯHt3)1$W4WcZ'nv BFFd`cB׬_bH!(,hUG@S(((((([ĺqswxutjgxv|C'u׎|F/5JIΣ0PYPΑFyT,q0 e|W v!J״ؗ9J  OgV˨JD=ܨIS|_xGOmBi&;;H{tUsq{ />~1xo?ɤ,Iʟds<|0us#uu',a='atؽv@U (((((((((((((( g4K#\K AW6)k_7TN.?vA(z0P>Ŭwk+Z6I EsSww_Ki#A=,v8e  ^cs!gκ5$EoӈS\Hw%VSWMGO- ˩x2@~We;_?o=sᴭF?*oMm o߈Mӵ/X07aE" C]A@;Oo^>SϖHm2?K ⎓ƿzb¾>Yx[|PL_ִ6֦oFhb6Hֳgއ9.!{Xվ94Mu}6'j 5o bg'M|'e?j Z_ J\·zyhM{^ X7WM*f,aO. +{tyERF/ّH4<tL?gm&|-elfMZ[%xD$cm$#ɯ)w?xeav"mIOvV4XR5 0AKEQEQEQEQEQEQEQEFz|W-7š泭-nv=XU؞~/^l~:j1äN S^ Aիo?tt(``<'jpĀ_֓ѿ5sXUzPvv(,,(,`kQ@vU/ h:w4+=E[k T/II'5@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@u&]n^; 1 !=ȯCxr߇ \$~R3Rkk:zƙs]Y\XeWSc{ϋI3Cq wZu29W5><;ifzrkڕc $2T-qY1--$HIP?,?D{[V8˵Jp |=9tz-#D5 [sO4vVbr!ʙ US'M6 /ndRяn~9p I돣mP 'OzZ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ~-x|Z<b ռQh>ŝ0ۮq #ŝKOv 9=k>/\7P#?)FF {~ɿr.%ᆛj A}ҺNcVY10F{@+&fɪ{P&~Cs_(((((((((((((((((XvZw6cWr#x!x$%5'TC{io}g51m:E `Q@G|Eo~QN/t +c!\}k_>$I ]Bz`Xs,A% Va<|FMFZkwij[_THqS((((((((((((((((((((((((((L🁐u_>Ep=uچR6^|-#z>RWKW p-/(O 7T78?h_M:gjSC]+/b?ٯԼYw9<"clտi+&!G_G#@p,ӏo ۟%aC4;au}*~Ο TF Ek8*>I*r浖߳B ?g .?ݽ-x<]pBlx /h$aYݩА-w: yR%Z"c"H) ;h.n. ;iiǩ 5=>C/nbVI!Uyv⣩}Q2qJE/|c_^m}h1ʻ~~֞85n+(2>@wizWmvǨa4QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEͼ7VDA*92=A_į_/>nI9qr=TɢxdhHR2z>xC૟I%mb[R`Ai'o hnhU\orA N0î|}k~4Ům,-ԟX'^=Qgx~ hd[Pq'O:Gs=r֋jz5{ViTV!i \?'>i`oBG΀g+((((((((((((((((((((((((/CVm.]]{W̿<+_S @K;#s6_*}L|nGs ;|k}DҴ1ii֚}vЬ`O||J'gic]!_ SnIDB2sv8{hk{y>rcϳWVvi"]T#wZ$&h((((F`YU$(k/9 e@? ^E/ &[wEh}Z֥}!jUKv,Z+NTmGxIǙ୹?E!^=&<*i9:dՙ+exz;(((((((((((((((((((im+A/#SoXܘԜn:g?Wyo~ ;ejO<VLmos/?~R~G\/?!%}+g獼r5 'V%{Vxʜb뜏-_\*bn27p:۞@":( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( kh4z|roieaFxg>m=W?}i*|ɬ~6/^Z:@$? goBv1L?h(O~Z7[g.7K [㦝>Sp߬oWM>G_K{ /e:m}UE| 3?m?zx9|Q_UQ@*yƝ9L(xسgXTPʇntnj؂qbPNXy^V<ÿ, w:H!7g):y#y?s!_ }U_*_?PTQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQES#8G4VrcdxCo|G[i3?vU3` OOC9yNԖἔcʀCW#_4&ퟣ DmpI?QS~"G㏳b:c'@R^_ZY.˨-׮e kl.Y[Pw5rHno*g9< ֭NGe$!\|c{L? ~;|5xfIX?؇7t#A:|5OI_MP_ h.?>? d)o24? /\t?gOtY鿫߷sf?rg ,dcFvk.?f N/ ЁWd {4:@gi|b8 Xodo3Hȼe}+~UTߛ~8^ Bx`S(Ohm'RmmnASj}.Iů2e;^[fe ƀ><'lީm@1o3:O((((((((((((((((nxWnxW>4@~x{@gz @PO!^ּ@"Yd1#}֑">,P~"^jw}KBB7 0EdW:g/:g%5-GK"4d`;[V81]߉^|/۽צ- hFJ0@=*wC7ZๅR7[$ĸu]Ϳ8;9$נSU7Aj6]+maQ^k㟊h/|?sO?i+Hc떑c\BY|=_hS}]qqm!I%6G1:+x/Fo$wG$ݷi8ytOT%gۋm5(; eB$4W4?Mc]\kB*[5ĺ97Sռ=|w"q vH1AL }!EPʿ|o_5U|mWC_UPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP\/'Y׼=mT~Hϵt5_?oרր< ?-CUǍ~ k7Y<pBѵ`$c%Xmھ7/^(}?n r;~oxpGJn%o'z( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( khLXWꇇ׬_P&ּ>%X;}ՑX:W>'-x_01~^V}T3B' P1GZ~[AZ"Fymnw1eSx:5sǷ&/~麜o^ƬoDwuTl379ַ4x~7Y%kg.n$%% `>:<)s}_[2vo +>x|?.ILΞ ?rxWu)$Vuƒ4 _b@1x=R#t7S\@aՏ^ٻfjVI]&ujPX09U+zС_kB  ( ( ( ( (2S[xsÚ|Ѭmp[hO׊.mKx{+큖+} I GpFs[KxKL3]%D䘣 ?5M_EQ҄p^J^7:`Ϧ@dW|H-~%i~[*}UXZQQ;q %ΗY{tFspSAg_?i?nKg=<O4O"^N\Om-"Ypˌ#$HjYecX=T@9qt/̼;/JSgk,>&G+DZ#6x' Z+4CPu2&cl+,]ľ$[xotr=Cb)5"o,DZ6 ye+9azO-բyM y]G@zA`ٞn׊V|d|CQ~eґg?P ϑ85w~5MVkHbV1)IHꡊ3Q=+_oW؟_:~z|gVu6 奆U$%Oّ=k(((((+οh"+Qz-y$[?5 'H_W0c߆ k<즸qe'Ժ`Ěd"}\^@:xSgONcfTA)ɮ{7ȩ/DS?GPz2lxj_X_%& WŋO<ێ-G4 tS_UQ@*L?~_"iOa +(_^.q=?[w'"X?3%?S_'O2zOQB7T78@9jUsRuX-~XMMQܧ+q*;Q@AX뵿Zx[k"ZvZw/ ?sQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEW̿<+_S _MW̿<+_S @E{@gz />;lz)4@݆'skV?Vo",v5׋lO/>z 7Lag# 5wYuBda>7"aO|;'<=6ojz50x4)7)*zw5{OK=._x/:Yd&rc6~59o-% AHBg 1p0s+Ϻxw|mIQ%CY,L);q>xMඡKka^ѹK 2NJ50b9'rWx1AXpX^2m+~#*H#p#Yڧu: V׵MAcnonI",'Qy^ɣ|:ˮSԲ[?onOMu>i|ObLp."<ϵ8o!]xEBA\oduf+^=+_J_~(x|YxM 2_+|P|f&$zNK.O+.ɬ}nDw6מ1u7OWm熧fV:M˸y9IyoxH׼mGS֧Zφ M9HRq+5XkԆNw4# ˴q*ηfkچv/&TerH[K`dc>V}j$,V07SͫQvYI 2r0/x#ڝui4V1+U'gO#t[IJy*p}@xn2[IfaD?[թm1>7}~_n+C+Fok[Atjn@%0緥|DiS|IƬm-ءW[|1׵A$Io* dIHA^6~V^]FTPr1yE9nq9 leZgP=x-BkkXB,k܂8l}>zdiw_,[2IL2Gpgҽ'4w|;tĻqOӠyֳ5S#ԬQ{ZZ\*O|>lfonSdVi"}G o$X,IP(((((-עם~EW^CZiq {%x$[Ok((((((((?k"ZvZw/ ?sWa$KW9kWn%o'z( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( khLXW??/VQEQEQEQEQEQEQE|mWC_UWʿ|o_5UQEQEQEQEQXx@X}&msJUE,Mw@M6|:sҀ6(]5Dl5;dkK!%I/֟~loCރ{IM@R#+0eaA#ֲ5hiZt2ww,Gb(bZjVu]AwlvX$#}ssr D_< ѼM-.PQGi6'Xfu#' C*x$W|! 9 *0<l\jXc,U&61SvBق3s F+g{GֺZ[7ְ HmY(5KZ7Ao~ $3 QHS0xÒG([VLBłhчUn3+xM/Pm|)ea,:eqMwϸ-itOgtmF\r\!LFv ) ;s Fi<RĶؖineH*ᗠ9ϱ l _2Fu(6=⎓ c힫'X \ȳ$Ҕ$n+pz+/l|EYYj^ 2H+\ِ;(,8'&@%0mOɳp0ktBVӭۈI6U ʟ9f?72B dd}= aX $\Z4|F\7in\h_VGZ촯מ @|W ]Zپi<*2P) qּ"Sd> Ěxխ,& u *!l >-OxPXoZn-`REVɻwğ'_xKMH %N5oQ}kk2C'+;vW> ?jG-jD-\dY_-_[_ٻH댟9Ҩ(((((((((((((((+~79O[MIQsvv8B>F|  GЮnp#8c6I%P: :gWOo|J-{+;I1Tluk'lmCqȍR!O-i[{v6Se3{.(٠+V[yXe]2E>Ui^3My/-~-lT_7ÜY-DO-7}YE| ;Əơx7Tإ$Jh+t3E[Kke7 >cMy~cWn?Q 45Fw n'cq|>z멱}UE||EFkXN NCI? 7A@~&d"O@Jxb2kΟ3F?@NO^3wºJI-uΊL7y}R_;%[XvbB ItM.u83Lg_(|O|`񽗌>$FZ%+jcT8<f䎄XEQEQEQEQE|=l;Icr g\>ƾʯ?(c>L[ c՝Xob[;# sr+< c'qno\#FmMoL9=+>=mwi[R/-Q= V`=ȯ/x[@!|.kH iFnq`O͓zd?Jψ:Mk6w Y6rۑ`k<1q{o>$㞟\G ɸf #nd`tRV:ῇ+k,9W* Hq8*7'RdD*JP7oz+j^ /b@@7|џ0.yԾ5 !IGr|?{gt|ixizEƭPBI1iiF9? ^O{*h]pbH`̽0O[ωzT\jq"Er@ )8'|RϣE՝nFm A v%9 BpѼ7Dʐ)fO4~iY={?D%| n?qVrzgO j,M>%WbF8XxgvH^KWi#T ؖ޽;7]QQ,n(ZSey~8*qT<WQ]6 ڈpVR:͠ wMt|95MjRXъ4#3} `ϭ`Z~"I_xgW(|+& n9;O;vLG$״B0,2uyTpu^6'^>s_^#ʒ-pcI85^(2>έ> DI%L]Sxboϊ #WNJi1N1^_>WAW fY0D#Hb RxƓgCOH -aRP&rRYxY9ec#+r9<_uT>5RoÍe-V%z6{TQEQEQEQEQE_?oרֽ-$[Ok+d"}\^@~ivciwzg#y$ ''=MhTZe'[I|nj>Eb?AOAi7$,Hn y#GgqlxTocn<qGZ(.ú-֪ΏMnF@##w !F2I}I먢2<7i\n閺t^[X-cHb% #tmJh4]2N!R}HPkB9UΙmsϴ#] lr*ޗXVV6Qg˷b2I8U OԚEcjt:ƅ_ܨeWذ&6fhS 1zcz(;Eд 9#4 :9[Kt1!@hEya$KW9kWn%o'z?jG-jD-\d@EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP]AUaFjiLIk;bO\ļjF&=>IGU)~T ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( Hk^^uC_z hI-5Om??ad((((((( ?jG-jD-\dY_-_[_ٻH댟9Ҩ((((((((((((((((((((((((((((((((((((((((((((+3%<=ڒiu%:jW0?.%n 2ar09ŀk|Ew6vϴǻmW,"FeaG2wxYUsy|4:Vj~i}e_Iv^?ey, τ_qk*Ź2?4MW \(+OLhm@S?K f!1Ю`TWʿ՚ՈkkS/?LPTWֶ?(r?kkQڀLTWʿպi?CڏhzoCAh+OMh]o Tt&j0is2Ŀ+|aExe{.v)y pOҸ 3W\}m,HAQxiXeny3<*'[Ac\q8 }_=ӴM00aB[X}jFkjv@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@A%-|z0hc>VŸyLQ@EQEQEQEQEQEQEQEQEQEQEQEJFIFHHC   %# , #&')*)-0-(0%()(C   (((((((((((((((((((((((((((((((((((((((((((((((((((0" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?(t vI{)Z V:Fpx[W-f6+̳gP4'^iUOz#/OwPL={=u_׬;NT ?*y74'^iUOz#/OwPL={=u_׬;NT ?*y74'^iUOz#/OwPL={=u_׬;NT ?*y74'^iUOz#/OwPώ ]&owyB{rqp z|+KڋYZlj1+j(((((((((((((((((((((((((*ۅe6Ԁ3SU @Z{I]/׵_ u2V{y]ԑ+q_ak T>glg;\꿲oB4?_D?f^~/G_3^Ex/?#/׿Q@ HCh$~!5P?r?y9{?_D?f^~/G_3^Ex/?#/׿Q@ HCk54|Hd}m&NA,KrAF#?#d7?7^^Nz?ԯ~((((t3k 612uB5? -uR44WG|7K _/@Ex4w ]M -uR44WG|7K _/@Ex4w ]M -uR44WG|7K _/@Ex4w ]M9?h߆#'6RT}cZ΂Hdjz(((((((((((((~8x6 8g$ ך|tx?Ek[2$u/3w_zPË?~z-2kTq2]G%L?PQ;G%L?PQ;G%L?֚|u"&X%D'WBa 'vJ>=Йkߪ-;^ Bgހ<#&h?(BfG~<&h?(BfG~<&hڊmf" 4`8P2OJU"^s9O6 }oS馒X3=@9#p#d7O Hݿ~e?aހt{x:oR ( ( ( (<_3w_vƑ$fk($'mqЫ%"^P赠 xcbh;.h[P!sF? 7w?\ѿ/&C1B15Ea4o й _Mn@_xcbh;.h[P!sFzqgs'ɝ nc0+>d kzBi:j5 nY؞Cs_Jiڍqk: "6 UOzw4['ZK$o{ҼKV{?Qw<^i)E2bLր=(((((((((((((^4?Eyu$f-*ȡ׌-hb((vxѼ|5ibI>NMb>tubCx*-hF8>潗>ߌ?i>U=@e 횆0};1BdV l0oz񋯈*hՑw1wss@o<[4էa k)k!%C)p3jJtO g>+($s$IfYc5@Q@eE}c jV_W?o_F+/Y !gB2Nz?ԯ~'MjWPEPEPEs_o:I0 q@((_ո~_ո~(((((((((((((k#7oWx7E `k^_] C(hZďxkT}7]oUIfwCf}7T-MkRjQ\+_3USxRᦧ3Y\IneKrFG=(?\lӿ ?s|;N+J>.>OK_hO\lӿ .n"43eҾW?W .aкȍ8`r_Q@o_7SС ??Pտ}!EEk0`DFjZ(+/_+7kRU"^se"8YuN1[xK& _?_֓aiiڽWv3ĉQ|FG MDm OQ(?>#SEsu|9mO3}P1}+dxYZi@i\8IExu$f-*? ȩה?-k?k#7oWKEMk@QE?'m:jo4hZ.\i;|FBvaʐG*( h!oR2|Gx2T,Ü}/Qլ!.wG4.X{@(((((((((((H~[U CC?Zח_FnBPoxր6+|`~8Z-yC"Ǟ3kޫ;ĩ Rsmn֒9l{h6Fh0_CQ?+ڇM@#}4_jΘ~?J0SfF`fWE^?j{ɋy(bi|W D5&SOcuE8-~uxgG2ߟ΀>':[&x啷}ˏƽj WyԬȯל)V_!?SB7o_1Y#d7?7^^Nz?ԯ~((((^/4_Eygu$f-*? ȩה?-hV((((((j_Vj_V=\{KNlἲv ːE|?o־.>eއ9.;p?|ޡ}!Ep (%m.coD?4%#?Ww^CG൏!xŐտȓ8CPku[쿲`vC{3?zz,k$Nr=4((xqgㆃ/xBӌŠcp2Hdu=|I(=|I(ߨ=|I(=|I(ߨ=|I(=|I(ߨ=|I(=|I(ߨ=|I(=|I(ߨ=|I(=|I(ߨ=|I(=|I(ߨ>|GskTal'8!ռKv=hH~[U CC?Zח_FnBPoxր6+#%)c) g{WPD??d|ca?U{?>10*YGO^Ex,L#G?&WQ@ #UPD??d|ca?U{?>10*YGO^Ex,L#߳_|K:.|Q%fp ׸Q@Q@`x'tY4Y%ͻro#uSNk~)y(|%5;k m ::>KH[AlFꮌ# Jo_gcP_epKir~U:2o )kqV _:* 1;=~/s+sKauıg- !=oDŽjOxGO{((((((( {'kcO$@Z=pA5⿱K MG@k#7oWx7E `k^_] C(hZk פoE-dr+? O@}v׌L@2E|Dh)47nYZCtD 1PG8IG8IѿO7G$o_/G8I>mi6Z'J0[7/묳+Hmm>m 8 @LQ_6DO%E}%E|ߌ=Ե:qKp6"V` 85QE@5Y~*_X9@S!gB2֧$ngbgcoxOXYtE%bσǠE'MjWWx?ষJOksOqczWEPEPEPEPEPEPEPEPEPEPEPEPEPEP\O xNBRӢI-̠iϭtP(EfO:s)|~R|ƿZ(5|78E-f^;+FA$jd`YNAoDŽj:^ ;)tQEQEW&A+|IүR 7F`*v(p\zλro {QkĺM A$^8` C5o ]nnbxJMV[Y'sV,.?KӎowdcYDr3ɠ^2XQѢi,l~.°S0UFH. k:OQ$Y$q@Ey¿v:.tKEvfP6ȥ2Z (I_I%&#jֿ\$Mxi$“H~[U CC?Zח_FnBPoxր6+i&KB,sj! Wa>?O]muxȀ:G;|}_} EB^S!¯\ےjm}$f6\[q۽ej (Z鷍eҟHæF\?@,rX;ڦ~ZG 뺌7kV"AXj6Ar5TP؍O^R+t-:+`Y܀2rwQ@Q@ ?^+$uZ넟 ?\Ro:] C(hZH~[U CC?Z zɹԴm2[XbA ["k~DEDTE 0 =)h ( ( *}iw\kkG2C\0xMT:|Ik*"3n%`TZ &s+ճЀzgތ4~_F+ڪiey+ FNIQEQEQEQEQEQTu-F%(n3W?/z=oC>$T`T@O^<5/GhoM{?g_4} ~KQ^<5/GhoM{?g_4} ~KQ^<5/GhoM{?g_4} ~KQ^3槮\7 xʧ˲;mr=+٨((x5Hn島ǘ-bqd`{ޯwN_ xz|Ik6`|ȓpcyjoeBp?SY /|i{]_Y;f"q,&3x[kD{k-z 2zs7x2Gnt =((8"  oxGO{oDŽj( ( ( ( ( ( ()_&W4IqaIڵ ?^+$t{3w_zPeޡv;idKdd 83:M}Px⧌|sthjI.;+Հ 儭=Fq$f'(~4|-Gqm'|Gd7!CB1~; GQG`{?i@g]s 9u7-{Q@Wԯtu R+TQܓ\Z X-cY+t xm HK]*+%͞yր,x/>+K: z=WluMUAwb~Vj3e?k4];MgcQ }IօG-3I-6e`( |R<_14vFna rޞ+ߨ rޞ+ߨ rޞ+ߨ rޞ+ߨ rޞ+ߨ rޞ+ߨ rޞ+ߨn#Hd_ lJ6 t#~|:^IrV0P}~\5P\>;{[,ΉK޸?vPpi4񆻠97%N>|s~]':f}7^Ex?Ԙ,?:_x\}1?{6ε:O ƻQ3bߠ>'|Ú=ckJVr󮖊((((((((((xڼG1c_wzP??٨+/}Hvq#AV~ C kjZ!RTi?3j]Z$z|Em$x8^Ey^s&ARc**v\4%|!']i}Ш~!//5?YiZ[1Zˇ{b̥A N{_FC{Xa|TϮ*Z((|;`e~|;`e~-'R%$-k|VH܊+&Əu4MОAq? h}(` #<Ŀ|N<:) mz(((((((((((((((((((((((((( ȡ׌-?d#?qקE sgm^a#=((K~=~6k6.M }ܺ8Նw5<ګm3RB'ׇ~au suKR&)SjC;s]/Z_5+\c`lp<xK|MoZƍwY~UtU ]Ϣt΃A^5ޠQe(#dabSc@FEQEWx>C2׿Wx>C2QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE/5Ey$b?:ȡ׌-?d#?qQEQEW͟ 5vg mWӯ[?Y$W3}'Fsh^!5 sPyml$H# p xoy<4,5?>].o=329 ( ( OÿoZOÿoZ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( -"ϓqDN~?{ðX%5P1h_4G š_^Ex3COMZ >%5P1h_4G š_^Ex3COMZ >%5P1h_4G š_^Ex3COMt_>~ d յ{cx[0O B{] ( ( ( ( ( ( ( ( ( ( ( ( (?JFIFHHC   %# , #&')*)-0-(0%()(C   (((((((((((((((((((((((((((((((((((((((((((((((((((" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?(((kbo5)IFGQG]?m_m+D𽬥e\8!+,~(+C/:h\d_`OЊ((((((((((((((((((((((((((Ώ^*↹&4֤*?-3wMrJRoly>P[_,}i6{0O$h؟Xms—uơj $E}kC khZG2̖8`s#+8r8(((((((((((((((((((((((((uAп'mt/ 'k{"m>eZߠ(((((((((((((((((((((((((uAп'mt/ 'k{"m>eZߠ(((((((((((((((((((((((((uAп'mt/ 'k{"m>eZߠ(((((j:v6љfC;|hWt(7~3>۶?j˽R[RKh\gqGԟ¨FXz @>m‰[G4,ߓ FXѾ??q^Ex4oE\Q ctPFXѾ??q^Ex4wG-XOn>>;E,F"(MNGUV!?)BMt9Cj.TiX<x?Þ~m_M7zuhBlX(((((((((((+0]'eo>Sv.e,ۆ%@bG{%򦡡:[B,ŹUYNF9s^ml <_ٵ v@˅;hmt/ '_kD Iȃ[襭{"m(((((?m=am_G~趠*+V'"^P<_x|-iZaqwϛB-lPaEyDlm.J oob|֥eVϪv>n7 6ɴuǽvWx֟}ZM鷖2Y[ݴ:xAU~2z_m-oEO:/" 8  :Q\]P񆙣iZro{G}[/d/&lrqg8`|37Vַhuq<.QH 9@^ Z/u=_+@Xx{@gz T<= 3b_(((((((((((е-o:{ZQ[Mm ɻ7;;TBbl#Pi?to@^4b߻|w$]For\ͭD^Lgu1c(QO/5@?Ey$)J"o3PF6UՌpf{;6)f{rۄl1؀cvPU]zh&1߸7ry]WᦇxatYTrR[S&3!8+}EvPvCkoQH#8*W~֟|K{xi* 7Ðig Tg׬_KCtR؅QEQEQEQEQEQEQEQEQEQEQEW 3jjzyei!I4oQ+h ֛!{'uѱ_2<U}E|y 'IyQ 'IyWtPǟ2<U2<U}E|y 'IyQ 'IyWtPǟ>2>N [?6o ex3W"xhB8};R$i[hd/2&ߠuAп'mt/ 'k{"m>eZߠ(((((kZz[XeW?ӽ] gKo V;R&$ߴ5Vx~xL\BOo-Ĭ;1X BO֫B\?)~i6?ý8sO犼nw#N`MXaʥč9'S}) 5tPډwnsҩ~ A;-F{+mHSym)x/4W_i6R եl_&>3_k_:_ _O_EWο:=_ K[D 2E-oEPEPEPEPEP^k,ҿ5Yj/=oxD_6E-nEmR;7 խ~iWV7-uT'8À1] ~*=˦iwJ)bvE>o*M;.l5mF*pq$APQ^oj:}_[=Ai"<1-{sx}lzGZ\O-cc$8Hh( z 3DDWK\2h@ r89ҢѢCu-KUOP\N-YyS @= G7H>g2\MrYBy$sד~&ހ>{"m>eZߠ((((((((((C⇊_t5}j9*OMR?jj}#nT/1X$1#*|[MKE|A;QՇ$< |DU P0z_5c߿uǃkX4ٕ1VdC]NyjI/ YEezŞ-ۅv9H-X?\xVi[^5/̳j7ͰB3'G1#cީa~4+ 0r0ǎԴÞ7MÍ4o{qlNH@쿗U|ɢPͪ}K|]SN:w++_kD IBz k)k~>ȃ[襭(((((+?mo%W׿ׁQ< tE,#ɘd$ƀ6"/?m'٭V-J]k@?)x<+χ! AtxcFӵ V4H7YMr5V>ӂA}dba -X(c+0υ4Fm<mbG"(1)ᲀ5F_-bx"`&9hIQ@Vҭ[{5+!0 np@ۀ{=_>[ K4Zƫq(&7rCeԱ'k=iIH0 ?ڻD#׷W1/tKR{ƑSUB ~t|5`oXKo~ iz#PEmEPEPEPEPEPEPEPEPEPEP^!F}~Dz5=yYJcz꺍\_wPY[fRM|_ xKNSľcºįsJ#Dem*q8"=iwY,4k]}"}6Ջ'̬I,rI>a~՗|8]J{]6m^;ϙs^5??h>1i_s\Hv9lctމk֩ki:8bI\s@Ş|9IQXq@\ '8_Vxfݴ '@"a?U|mȃOi={_|5`oXA-RQEQEQEQEQE_ 0kKy (w~Ư3CScsoBԟU}E|? ??><е'__@ j|yjOO*O?-IiWPڟZS RUǖG~ȃVǀ~ x^.'ũݕŤGypr<@03(((((((((((~naPgyy|z\k+ !,)nmƸGgcI=ˈ"H.bhdRXoJK4ȴ;%k 0 P 8y?c}e=H=qU#ز?k+]>ޕ,[+]F2:P$UDTE 0W}|#] ^o"mntrI&JO@5Au@Э/?9q5p0M 8S^>D'+=ZT4;t@ly| 25^?ďjG E{oIn_-W!Hbм=h>eR^2ZY嘒Izt ZBz*uAп'=>eZ[Ik4T3$YA-R׍zŷí.) 栾p*#0SusXu97#dGHj4'Ŀ"+Egh^l!XFIAf>`v%Љ\ПDƽ?hOCHq^W?^]]4-v㒱)}Nê@*~SڃNJ<==4 mPGfMeCyuW$!Ydl*($ fpzmˀhRBb@?ּӾ]nmBa%vch77ywKcM \\$eIܜ _8Yw_7Dk,c摛]x/!˿._C]{m_+Ї .?}W]uPB?,_8Yw׶@% %cgi z-_+1C7̄Wy^T趇Ún*j]F F{ǦM}sEs o֛o45,((((((((((("Ѽ[RԭSHL# JVs?th^un}^VSo ѵqI<|8<5ωȁG߆oͽ}W_ ?G` ^$ #Q}@|mȃOi=}_:_ _O@D 2E-x"_ ->ȃ[襯?KEvWF(Z?to@@x .XWc˴[RS# Yd,KK5$o+xbT9z:?xcĶZz ڔiz&( ̠S+ds[ <_qǤZaj)s$iCrpxC⬷VZh:'ԧ=>.Q1Pr_w0k(? AZO@<= 3bx$ I^i+ƿl$pNJO_ ׄ?_?M|3^"_×][Ԯ%їhrF9 AF=ÿaןFKayk<1ˆ$3AFBs׊Ꮘ뚾o:n|o #P}Ex"> $MM_#I*~NӎzG`Ѽ?yqA>d{TV8Pi @<3@Ey?N҅xnJ |w ޵$acꚕ1Xܘ¡e@Euߵ7O E 933j[rNm۟|S9_.JoI`_!wI?k(((((((((((+h-rrfkN >x[Af2jzxZz<u,:wթ c×H sNy|mp mn'򼯪8cR!>⾬uAп'mt/ 'k{"m?/oA-R׈q6 RQublTxOE]j?&hr{ F[O XxiL򲿙H n k?~SLh]XQB=;WkEr6>ѯtu+R)A[xJj.`ǀ3)77IڡM]*+y(8(rwg11]Eֆmr=@ZEe1hu9b71I&:(7_k?kI{hOLX^5d#pW葼:-R)WKxՁBRV-Fs0P5xCO XxiL򲿙H n τ3so UH_]}r/FJkb^%X3)QP0svh>4MZ Wqk}Y9Ϲ>@]Í hzZ5t-#v'˂/]VWX\sc,R&A(Pс>@:j^QBY5kYf819\$ԡ,RR8*;Wn?gEW嵳'sI"Ӏ:z^MS9_.Jڦx,^2?1@wI?k,rW]& Z((((((((((((_uxV%w;b;|)¼Reh853|/Kk:R1040\}*&D?U}E|{ Ɵ&EG&D?U}E|{ Ɵ&EG&D?U}E|{ Ɵ&EG&D?U}E|{ ƧW)<p1+gxƶ+mdBrxHIhaxgQT-g{=U +b?]QwscChhbz61+B\,h+B\,%%?+B\,h+B\,%%ោ;M[x}?F9̈́w\Fpr׷Pb"#U#@UF((((((((((((+.⫏ _[]Cvn'v<@V T3IGO<7 5qʭAU=TPO,C/+"ģ혁uҾ//˩5-յD{Fm*y\b? @Iq4|3+lltHl-mP" 8=|mȃOi=}_:_ _O@D 2E-jjj:vVfC:e=_ K^EgjW ,m r16?ŸSP/zƥMm gnI]}I_+Ї .Z%  ֱLs$B?,_8Yw׶@% pe^Ex/!˿._C]{m_~*'!:Ķ~GAi0֣~ԚT/xE瘞hVm21>A=T+=Ku;c24u?j׭esm=?μKԮ->X@#cl*;? _[KTkx$yqhT}W]u K= :,1"cIC3ߓ+_8Yw pmѫQEQEQEQEQEQEQE"a?U|mȃOi={_|5`o⟶:׵=_ K^)mȃOi=u 7A X 7A @x .XWc˴[RS# Yd,KK5$o+xbT9z:?xcĶZz ڔiz&( ̠S+ds[ <_qǤZaj)s$iCrpxCֹcB[-OLՕL_{gmU{W^Xȫ {xoa"_@4?K?oּ?Bzȗ>Ex"a?+D-Zcx+D-ZGom5 OY..qHWsEאs(8>)j?a?:mΥ6Z!bq%Ӵf{B[ \C~sOmF[hzZ+-Ǘn6l983qֲ>]k=O>pv34P>g$x45῵'~׹W*@Nx#D-kl$_EM^赯Z5h|1s]5s? c,WM@]QړizjXY|TF0(rɮS^14z:Ծ/JYb# sxvTW uڇW6v1c mOJ<5j\h^W [u[LF;X+@EdxKW^-5In͆5J|ʖ 354Ǟ7U"; rzhkjt /WK(蟆_M'`O5IiRZ(((((((+_kD IBz k)k?mt/ 'k{"m_؉ދ*(>L*"n^-kfxO5hƞ5F-e2 "2ARA:X =k˩ӆл/zv֊l| gi^m7W6 S\+(]gS4onoCq&TW-8mPq0Q8 cb(<'iiVi!)-{訢 E]Okܫ?k+ a=L %k^mȃOi={!{o J6Јb'oz,jf)1Wx[赪~9^KK;}cTN ' =5cSs 0GsPkv9M':&x8Mw"9X ۷*rMVv:/7zqDH8PH'iEr7[9'Ce+4oϗAW_V1çW֭O[ȧEnlbaQ@VTZMvױK $~H_=sj Լ 'uKVIrؔH2pp@: {UE῵'~׹W~Wr{/}'?K?oּOeahT'($VP#B#PkǿlȞO̊JǪBGa3߆?N|1`+WL/ Qa ?+cReqXOt"[Ȍ7 >V\ V?t6uo5fքE-I4gnz (>Ɨpg<ngwgcS|cim^RMPKs8slF =1]]h~ 'x즸+pce "y5vMA$uz;!E<¶hWK+ګĿjc_iW Fpφ_M'`O;7߅JȚUW"*(((((((+_kD IBz k)j?~τoLEr2HU2;ԟA-R|mkῌ ]'HN&/GCj%KU %KTWY/_`@WY/G%KU %KTWY/_`@WY/Z=socle!]9Tؼ"gy>}[E|C|#e+%Q@r>q޺:(k_ e^:Fu$9041}>OUL V?+B\,h+B\,%%?+B\,h+B\,%%V&{fWK) )ʦ=s#(?f>4UIae]}E|o>0|*N,3όw3֧w r_*>>w r_*J7З/ %(J7З/ %w r_*>>w r_*J7З/ %(J7З/ %~x7-5Ab}95{~J(U* Z((?o=kOgH$1Ts~+W-wˇZ: q4jn'<]F_m}(sx~~!x.F;cr@O_ׇt.o7:? s(?j^%"\/'U؃_j|~.]?ibi]pM#kҼ76eg[}k^ ( ( ( ( ( ( ( ( (  f uVdzχ0""nRϻ8#ۭ{|==>9q!Z-yyǦWo<[%u-9!o{+ҵ/;]xUocDv%ʂQC0PČk埍6WV_5„Xk垧8FViO+Ե ?4X Ȝfd,:2x~=W)gUc漫 iiڶnbYbBnd(r2A0F|ϨiѴ~LJQx2Tzm1eog+|;[hct2Y%v?M{ǎ#zey'Ү5eUgS+ e#ѮuV}f BIǮJ.-[Pci<3i66MptJ?w| '> h0d+FBQl{|f}kri7&9"/O֙m.lhWxğ LkxGOάHO''(|G崏Z嵜jHYFhpy_ěVSnxOf3D0 XƧ*5St{k X:Ʈ-V7'RGzdɬn|cR}!Uto{UUFK.8o񧍼;8n|QCaV G]FHdWj/fg4 `lZ72#3j$b3<@CF5H|=JO9O =":>/^xyMLclz_4kڝxU"+{y^&u/;9-#=rOԒK;tKr7g.)OC^ |B];gҫcUƒ>"ڭPwFU${{'3ZZkw&Oо:,|~\f_6v$I0Do2u܃hp:ǂ94_Ua=y+/)k] a %BE)e/hŭ̱FZQ $or(4ߌ-n=&֒^'cQ؜$*YG4[;h.~߽دUl #zg1>k?-_}C˶ѯ4݉wI eoIZ ,ۀO٭hѾ}45u{u˃o!JvlP99C4/kFy'e$+eG2Ö|־1-m4˘<>j N :L r FX߃[_9-|]4T H t Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@e76F.uf7}:h Zo_e֧oɻ7-rr20NFtM+\ ִF;;tA뚌Z>jw,乐?t_ //;hlo5^#JT+)LDp#(;Int@FuQҭCFnmE$1mRIq^Uh;DҬ/e+HH9Kp ;@0 ߉w'Y) tF6z{.VKWFon&fI\F@ C0#mM&GMc_Gn $m$S^/?k6~$4: y,Pe=jHnA־4jiksİPvZ o-@\ѴM+Ct:;;KtI!@S^]]͠2]]Gq3Y^eaWlezu/- +; Y96b-YNzg8o|v|UEᷱ l4-œI8bYF8{('@$$@qإpU/Ctˍ+K2[ktlʀX1^z<*AuG_^5#R {&e OEs wM;HGE%3pߌAu}#M֭>ˬizM+*dt;X͗~_ h,cRQ^T6/޳{:nc7Ӟ` ZwKM4IgXCm|f6Z3@T$8ۀ4m2GMƛe.#XEF ``Ukxmm8mAqFU pbWA=kڥ$r*D6-sfvƗWGh3zD4B's6ߛ{aU#FaN d`ܴ z]fK$VR&ڽXF!Fr,B3}xJ>5Ӿ i߆%to*]䑖.Og1WmN^^{H2Y;.%c"= xzU:EXݥk1's՘=&-bVKMV?*{ŷA4^ _?hr^5$`h,5=]Co=mcDn31zzUτ>!m׀umj~{K9f #9Fn39ȯ('׌ |;fTeNgMBI˨'}@OxOԼ;c|;Nm* nHbhHvaN?@@-|I_j6 F{xM"L3w#988]OO4+h>7ح>&PYid, `(?gw K׹G޶@,qX\xOZ'#Ot-f+9iZ(r1Np!k>DP~rkWpkg!6+ [sMWKmh?j{{N-V太k.v8$g|9'463λ$ys3 dJ{ V+߯mpFOyvKK:`uO%N''Bf <?R펩:u.!!نI83矛E|'Sy?|45=6# 2Y܌/|ot8eC]6ved[xkI=aY-iz(Gds@QEQEQEQEQEQEQEQEQERESCsize=PQ&version=1&type=12014-02-18T21:15:22ZFLISAFCIS((SRCS0PK RDoa,mimetypeapplication/epub+zipPK RD META-INF/PKRDwvw-META-INF/com.apple.ibooks.display-options.xml] @~FJn~Φ)Կ.//q <(bHXn/SvqITXl>227m|s$3Gmwjs>봍PKRDMETA-INF/container.xml]A0E4w@PˀLC[X''x)9& rhp]3\L8[hJ"0lGZkj<%fhSÂ"`L5&+Sˌx(.r5ȝPKRD) ch001.xhtmlun0E{ +&MJ-{Xc$E}\|E.b0ڄ)"w|tzH?,s> ۠Cnȭ l݊-b@(RF'#, zI3h!4uҴYIcY)jB}]6gӽG]@ƠI⢙p&G𭵨m)LhSw7u"m 4^Qg035zlY)T_ߘ/_o PKRD.A[ ch002.xhtmlVM6WLuiXvViCK4XS$KR>3$e˛Cs0d潁~??Fվi/~[ !ا>2PXMNK}6E߾hF A8a[La_\-FD0耚LнmAaǝ/GpB? Iy_@- j~Mjmv hUT0RxBu_p[828/.'[uFs٣Ufi8CY#, Ga98PTC%^:J+RrD Q܋&Z:ٯ 8[? <4"YrXufZFtPGZvrܨמ~*aE7`cu9g Qv0؜EdjYs7[Ɵ<ЙΨO'̭q4|WӪ-p_<؁qAzI@CD#i8@#µ`nᐢ:cEGr9K#xבrFq@_]e o< 5gI9f*uLibG{ADIM_ӎDpR-cdCqRAZuu{`:*,A'}pr7.T$l(KcpXF/:'OB9YV4L|2nc1$n35dA^;}\ɝDԒujY3ae\[0Q;r,̣&XͳY hib%0]L?O:j4T 9pD%[h;v.wˊIv-e(62P3o? D(o_"bwuLoa,1`aAq jJ7'g"OLTIN$" ӫ ]6JifM^TkbI;F&n䘥C$bNXY~+^%Ȉ(:7GبGPKRD/Dnj ch003.xhtml}WɎF+*!1 pv0A`$ȱEΐL/UsIV|K-ޫj?|埻wԄ>+ asXyU(gk䤮:}ů}&VYUgDEAQ(9\g1߲iǨ=v*XQiM`2-Az=M.'Zmq{0Q>^ٔgN?\~E;[ \m :z"Vy/mѼOc pmUxWw}tSWۢSunG:m*jϞl]#E*^wT[G] i=uZs!ʆBMu8"M&dۛ7\m;v-aϝ9\†>ITrEq6KIЎΎ냮~7`$kVb71KBn#J3 v4Ov6OBɁ2a?{;A+ Xp]};A-ɨvKoo - {.uK5J @ BЈh8J\U"Ww_s9ߣtQ@]}Cj08+'uSNEi+nӯxѩ0bRwBzsvoφn͊HAPX[ rY "x^_;D&Fp}8Y>hj<|cekA(w%P?job2skX|3}]]|EA$SJ(y^EQZ4RyTwjؠ.=KKHgPdd076@:54AeaE_=iga%M(dIɵσO0& hj]Y[$ ˆ{1$t)NZcy۲t_ԩ$8E:Ayk9h=IħaRUYdlUhs- U#*N4F#N-$ڋT LL`֡k77?.ec,= >WPKRDei ch004.xhtmluWM6W4l)Ef5HS ٽHK#YTH^ )nsLq߼???> z4ho>Cy.U?}z;EtC㴽ڱw޼/X+vJz EK)Sֿ;2d5 Ҵ4m>~XtjWW_je#}[p{PQ<) #z J[ B)Uhi#M{WŦ. axh^+=앳f@ YeDȈ \o1Kv] 9?zQӰif7(0ꎡWf#2V"X(DFreؖSiiJnkzVbtbVHn_ OxaOFO-77 y;DtgAF6=++[8#Y{r{8|^lZx rFe᧦ҋA_ A\O/H?ś!W<*-c7W|S]&Ys_t{qGjT~.2P$_p'bE [Co b izKѩYeul>1?cs>$YG _ x'&bs]؝\C3P!]D4.V*5Ėq>)?gr/XxYjv Ud{rg0CU#QZ Esâb:"RܟF䉻^*yPIbk˥i7/vf.8cގNOV#9W-K m{&T)[]x@(>2#x2tXQ&dA4d8Ix|&RܥD \(E7G -VbZ^!|EKVt\ho*QR/7Ľ' <,? Zl]ll-z礙tyZ̓xcvgy+8w |Bgݼ?Kp8% >syJF^H# ßtZw"@oSF-yx}jK*֭RW͟N'|dUVPKRD:> ch005.xhtmlW]o6|ϯ`$~hIZ[v Vq)ԝ_!E݇?䑳!o>{uś`T,>vͶ6mÇ_̋>0G+E=4ao`J.0qVuXrg$xOgIK w$ʑҁZWqNR]j-TnlDEvUR53$&I#r 53Yem4 1¬KZ1Q%b912Jn5Ibս"8s{r9ǫԐգyԇ9-<l`X L#u gS82isx1մ1KfLUڬ=;&eJK_l"c_x?.LJ5;n!LdǪ+kEW&'{/JyR\M.W9/6OW(u%4)>~' -oq~±'/|R>Ҹ ëo/1Y˰$r]cn)^]Mԣ\uxG]*U쩯"2`* X,L & /;rb=WL)^B %UGhX[ g\_pRW>HY4qi57#A˂3=׋YAuIQٴ j"-\p 3Kɂ#eM@AQ U|r$76r~T&ofINmH^m;;Ү kmo.VZye}+ ,o Q]*NՈ6)O}_o󤘻rV^P&vz*p*@-㜄{@;v$?kijPƀrSE(.ak[adsHhʟf:Lg6xHQd,.B.PUKaF&c*:cY* "_şQ;MϟQ}®eo(~=zx >&010`Od~f#oͲvVxWx {]=0}¶@R` w>#nĬptwN@Ȩl!WN߾&r=L=`B-yԴGҒQEs b–ǯТh+mO,`umcp=c4FA;<(yV1~0U ʮՖDۤh)2/BbB? ⏁|?PKRDuG ch006.xhtmlWM6W$VwhV@@N-Ҵ@4KBR IYڠ,|yo./Q~%q1뽟|>;c۷o'ޓM4nSeld[K:ǬXW1;&+hu5Mc'~KIGxuYU7(}@'-u/ƹLמ|pT16?}Nfyr3nh˪ ̠V5~&)Gl;w^=wq.QQ%Qi1)|Γ{~'J*Rгjy* Y 儷RؑZ7BW4tEK`.̇RPe1UG兛QB%숉qb!nM#B1N[AtPjCp>)0UJK)ԐەpbHE#q!vn,&p#H|Il-'eԁNp8dBh5LM LmciM:E ✪b2W}%gNwAPCf3&l%reO9IϰIOr'ƀGH>B3'*tx[Fw~yѸP-bm#%k 'jn8nA+k5(f%2 >|%%Oo}@zkguTY!}5ױxn%.%LVʼbC%RYc]0՗j}d'>a6$I>B?gҌ380:h Tɏkכ{z8sL=>O3t Y,^-{bw|}!?=ܾI,nP[4v_N:rgaF#8f!5RxС1X;ETUz%ktp-( FL]3"0o6 U.1~b];t8FMf2cEgN49P$8Q2F(NC6sq C8Էv|@z2%Yk䗱8nu٫37V[G$Ln˛'ռ^PKRDTཀྵ ch007.xhtmlW]o6|ϯ`UM-$A>$OP_>àg[66C_~/ׅu]Mk5lj6zҎ>$ہu/pM_efr2Xښ@KGi[/k ⃳5yO~[Z+s/̇YB&zG铢>a1c(eBfƏ:(kjnU蓦WY“H(=rssk(.\sm #F ^ Npq#(v\Iqe=|^+/ȍP&K\@S[ܸ+ջūa jiն!N(ir9;㖆cGr/жZh9; ATQdGM&ّ-_sD-'SXnxEE(2jCd| -BOU[FmjqiLI* μͰc|PdAb_3\\#SoIգZ VKB'2ݩ\䁱huW}ޓ~5FT3q_ SսQ2zߕ`4狼{ЎQVy~/4 e720/2CԠN+@G0ώ1([>iN{r dD,O8k=Ȑt)A[6>аrRQC)vNQ(N4^&k S5vo #Ч9Fe2!陫Gt+e=/N<%p3 `p4uH/R./V=d ;M31@ _Nyը꣺" y醏S/U/^0$%Ʊ$)2b:րpe ' "8uRZi^7|\:&}Ƕp@a`9~*Y\le*jSS%ڵ^جtL Z=yq'|:8{'F]k;5E]K,aP̪ t?w謅㶱lG k9et&3sbM#C!p ~ĭXvs젘Xx7|ލ ϓ"~QU1%>D $->Ln'q,ϯ^qC&V?$[ű[ A"8 stpA[%>vryqDBG>y {:;8bBA"}qa?㍆! \#읽oղ}UFky-R!*o f:9yeۤAf(ġog#kYzy9)_(x>yo2PKRDRU ( ch008.xhtml}VQo6 ~ 10EmMȒ'w)N.M  K>?\~o]CU*yAiwޏEq<Endǩ>_ 3QQ+r@/u诲w_^e{h76hLG[$[/M;c=RR"`%=XTWB# zӓq.?/xO>"F\֦iqxi4*;HoGrMn)J%<C{ Ao^0Eu.r n.r\v:G oAa"ȁPc R;"8b>цIcT " ;i i' R)Rdxis1 -lMYj8_fh?ż gHQ)5z_ݒ+Dum'{(Oˣmm۲HW4 !,Hݥb@On#l r l, X稨Ksl$gd(V6!%X߄·Hj‡ {7T\P ZVCO؄K O#{r}OkLU*^?e^һ DLdJYҹ ˁkqTfqhd)_Oה;khl9K;LDWaB0sۓvGCER* :PbcUEHYfʁ 8h))Y[a%6~njzL֢5E8i7 3YmĜQ^jƠe4shw3N/&܇#x;5m?wJ$D5{J5 +|j"rQcYv+C^EަI~'~ Y!1$7 >tI%A*3?N<@,|!RUSauߩ*;Qh\Te Qܟ<]|5۱qYݹ9s⫟{{;,_,:tƆ뢍}*T߼ySM1@m: %*rq 2Df H%gjt#c69PpQF5ZA@ὪWS Zlٻm*QUO!ž~]}S=L'-GwսhU,ywHE&k@P-K)Ul(1{LQ]NC_ 27d RROlQ{9B?y#-ZT8x:>ݞ Qx{)p xk)ۍw 6IܡO0pΙB SJ:fk˙W}$gqϚׇ,=.)8T½B(&)v§ܰ nl/ Tfr56+<^$E~6օ|9έUk~+|»-{%$tADV"^ _A=j\dXѕvBfvgUU 1H$ ɹq0ۋď#gKd(p]||b`<jmw,Q1P9Z2W gE 22,H+pcac D}~'Jh"v339c홃 VoF*]ś+PMs Hl.>c{ʜ 5R[,R Q!ъIh .L"Ӄa}92 mpz7;V3ZpeB{AyR|~ M~ܧ(ҳ2}`qƇGpQUeFV 6ח~^F-xeq/cn75n_b,@p"`94 6);?[8s4G$2-d~՟#Ld1QrL8wj3 d* sPlg?}lKv݈(cTGФbq /,Zَ|<.&^YQX|Ϲ*P< " &24{S]ܵT5MMNlk (Fi;舖G-ըjM- F>-xEebDkl3H'H}c{}*93.I,_ ~PbҨ'?DSFGqeɀQ'N|9jhԚam.p3C)ǡh.[`2C! v,OϾgr75 , cRlhttsTdr͇ː+8:`"=/)]3՘șOcPKRD/{j ch011.xhtmlXM۸W d]%8$ըjijgI-#`LE|"iCԱ,ҶkVf=3>ǽ3g^JKǏ^NվeoHq$r*̩P1 ҋ,0r WnJ1>*5PAyIURTFnIDFvb-;հGh jVH-4+*[S)=M5u"r) ^ 7EG*jQ\s!OV"28I(K ΚDPm< yUܜx;6+)rC^rQ:CF(&bma>G拂Y5C1+/v%EP''orT,;XrٻFdUdtCP0_>Bs/W(M1!GIV ^tjpɏsН#JVh̳bǼZzKnyeBg[^.^)~lb# .wb|4q}s1"ϐ[|GkcE0>ثIR9UY-`g &WBhH,]+`[hn@J 9]cԂ1*m=il-Vs%ujw&`v^*1VK6g.ߣ۞YQ8lȑmɭ#'I|9rv v*0d>aL)~*SOj#AVP$^ĸէw;\|f u/@J(U0~uZG0YPn*׼v)kم}|3!c-iadYT'iкE[O:>QkƍB)>rȨ,rEfGr_ށԣ9(n0r+c!\ RΖ܀υiJrN2͖%&,xD_X G6N' h7̣Kpvqs4 4hXBT .V A5_q;0~exɠJ1)`Cl'nW4Nxg$y |㨭PSHwC7"x~$Vua#Īͻ4FxxƛzA [Y x[~<6,l .AK5یE-hױ:Y2H1>f!7}5ÜsBZ/pg4\mЍ)q; /8mb2cCz8Y*NM<ڤMJm"0?NL M_KM* cݼ/{xmo0G7];YvfkW($#&\I$TT|ÅaT7ͷl/ԶFsq!BC@92@?'ʵwY?dƬv|A8Y>ϗ(uA' 0&d"( . & 0BdtI{<{)2Q*fܷ3?=Hg:e(}8GqM?q})<ķ!f 5# yPcdӋE:,/PKRDn} ch012.xhtml}V6+$ XV6[M4  E tiAK#XdHʲo(y Hgo޼rӇ4/vhl-y;l]oVG)w3K.۾yXHTVmh7rR *DNŔעzǪo-\(q6Wujt2\yK_\w-m(-b:s*h]l J'S%kOxDnvt{[4 `͛ o.[ Rv,U,bSeq.ҍDĞĞTlO=;t*(zz-U8D^0|p2t{mt:QE,/5*+V!FwLh j﫷f`:qCO]' H]ZZUcK C1w^fZyieUR{ADGmTryRg,n)rm-BjQ1<G_)dmAKs64gI@~diM^qr"sm%U@88g=8y-SMf6=2%,A#L>ڢ_*gJPU]h~l!] adj!ddĊۆ)W U $4*&|)OuWsV'JS<χw3T Og'tpu"])o`ژٻ\Ը YN1yN9/Qrz.#C:lW1A'tp=b !HXP7 SyC!'Le47D20&$-9'/M$ CJxW%ϙ.NvzͫPKRD7  ch013.xhtmluVMo6WLuix4>1dER4p=4bM*IZ}CI^a_C {/^E6bnt:C"R>ž{ !QsTtbUϷف-{Ϩq6El%6hӧ~n{mi8ż&QF{ln'ácu'yBFqP8C,?ʔtYvW&jgIكNIcejTjleUٽ{E,\󣝳ʪ8.pv*_*t-RJQsPA*В㢇L{C +:ܩ}dPkT4l)wWrP@{j")*9us0|a4S=m%06 @'!7#,mG6:icd[j$tبLShNنq+Z)*GSAfZUS>p~ȩl\M>L&۴uYy|GكZgj9o6M^(-dT3L ;YG[m~zV4򯸃w|TJߌsCV}91Y1捀EjրO$ jچpcŠxy+H9#P "F6ERIJ^! cFNh0/&D77?fogo)Q"NxXd ȫ#iΜ( Fz!1b.p˱aU÷Z<7η!zƥf!2߷ߌdXRbKT7ۣ&CQXSz9Un%nc8`9SNiҢNzԦHZH+wUpa\XSY%w[{}eBjb~Q-UWObGNIru0Ni;@Wup<ǐy{鳾gx4T%M~O 4- m7nKI\eY;':on a-rt^w 鸹^p秥6NL RAO+,*"AK2~r0B\j/Ѿo]rsy`RLG[cL^j}²z}^׷H GM;D/8z;V\IB}ܑL&g>A@/D; ]X86qaȅE#aS6 H܅Gb-\b#anБ@ #+@T~dn.S*[I;3g=#,crϘ0i"Zi&x1d-Qfywm!q2$FCtH !1qh%6353Ae޳&^rlWg}WuI?PK RDimages/PKRDێ 5a;cimages/img0.pngw4_ hщG D#%jh3ZtD%g 6:F^>~|[,}>g='ĄXCuQfJ7@DydfCVc%#\GT:D1LY V!"ln^.'Z'@'@|/3%W3:$Q"HVrܖ GSA8@"hyߏd`GLWqI{&̀C@.<8-r*,kۣRR2oii [(\:NoW6X P oH#ՄϤ}wz2X:̂y"ڴoZYO$n|ҸϗеaKsVkm^p14y@/TK'Eψ9ODbHwzG7%)ɿ᪨\:g޿6RãxA ]5Ҿ6ݡ$80m'n[1/#DVGhyb^ %a pRE%Wp 0!\kPZ LJ?\­TFC'SBz:ay[.p!}dƪRC/y:,PmkW)SUCL{)t._u4HjgC)>*6c\9e^YgKrz`*_ =PXV'wf a߲zEYdm=I= u”!{[CG2u?J~$;޽YkC^Q.EgE*ζ$ӺT)`+`7$Wo ``^eZF !}uNE6O$ˁȷtP qֆ09z/R o-8;\yqg!s[G)RA# BOS$A ~`3/5;<YQ:n#ŷAO0{z=TG\~z{Pq;,0{j8RyPTQoHq]D-`O)Y=>/$xFZ(C :rdy;/$޾H1̭XYz_u`LUp[Q]2hqQyGYU| e0zC%Pn-gJԔ}Jਈ 1:%Xå5 yIg4ߤikfqRD5W}-(qR|!#^! 4_ I[z.TPOͭGq"ɇ\M=P&H7kmر٢-hsF\b|1WZf+X$#e51n;tZXZ?ѠF*@Pu>z{;dۻ*2*\/yIdBAAZG@`>;OhMwhP(0AD3!,mRťZMQ+m#XJ=uI%<@*fK΁KQK*)+) ʛ y'xθo Q-9քN.HY=8}Fo=mkz:O}6O,a;^wSfM/aX*2MӭY+U5962Q,o`Zdw fw:S얪ZKk lA1Q@ &#Ai*j}Zv[ Zu MZQMfPT;Oq@W?m[pY (0#Q}ޛÂE 密]!D- ZKT&$>-M ͳL:~%[+AJYꉃ'6cle|WF'/y>3~=qV'DvzūOUFҋ[2~p3V #G7K ʼn% B񐌶mZ ۫C.~ Y@W?L9O.yO̳:ғ׹'چBu D0j%ǝ٨XmƱ>sI}JbђԈr=hq&aW#vyJ۟?_Uzϰ?⸌L$=uǁ(Q!l/ h=.>c_WiPS|x_ RCu&VΩbL\)>,N/9?C窚Pҷ,2*PS޿$4'Jg: <ͷqFo6:B8:Fvީ=$Pq[zC>3`ytS@`5>?oGY[",~PѨd7 Γo24s<5B<36bah)i/`"6F^Дg8A-[-7 ;#>`sCt{r͹,KήjOL jի6691:h X/ -[#/ܩ ⱙaۨoU={rQsT߭HVWWuIL ,noO4V>DΉ+fNgx,z4+-R\fY^lO[銓Fx Jn+,(L5+  ]Gv&KDzDrH1}$ ܶc8(k@V سaJ$M_gͤhD})q.5gM8٥[LEr3#=[u:LbTMy7)R UF3 mEj,ϻueur^,׀mvSnL0NIȋJ#:yi1$R }~O($Z56[jo-Zkb9A-ܱf)OHp k^&U>X=~^h*fX?rHؠwRGR;vbjJHg" X$mz)[I'A/ɒD̉rk[f- O?" E"~rPN\J}Gi}_͉TnPM-/@-=cһ ꭪#)m `)>Id  tA(*JT7bK}ZpNinL$0<n;,)#T39œ~F_( ."q6'feuʏ84ĕ6)zpSN t}q&i[9x(; m?[FW ]ckZʡeԼndע4o:O/6I7W8xm4X,D2xhfV0;)hZ!J_ JR025=YVr#7L: @ C/Pv':BlD 4ei>Ɲ{,y?\XEhQ6p:Y\GqL&T&dQ:>oF*ZDQw]QXo֡UjȤN+,<8%蟵HGzQ)  _Ȅ/cJz>dhw^>t;R\.*WK߲}nZMkՙD{aZ% `hYB#דX颮DÓ1[p$T=K>Yؠ_o:'Y 0~b*8l@Z RH 7\tKfzDzdWCָn\{:RwӿE"WWź~,rl_Aa(f֕C/;jWP[pgaXDGbr|*Jƒx#6yt[8#4DC|Fq{*Cck=iVe(8$PmW[ 8oc>-"4v}X4% :HKw!/J^tҼ7:$Ԙl\ w!g.ߒY%"<?K&HaqX`b{AY)r! QX(lJE8=6_7*xk[`gF74\JnΞ T *g)!ksO Ia__?MD#ݽqn~則Sv} n=O#N-CZ~Nh`;^%VD (kd!|T\#x֧!2x30ɥf tW~sR;R6Kk836T,~!O v+a:%s>E?;5!e! VWBk ]_⸇ < =4 g͓|G +~RW5ڥ@śx*״8&*y;'O-܊9z3`׶Kʠ ,|K+;{hYH9&}m23=<̤IluVޟLY;8&|Efy2¤3:U΁&nXg-'dz^ЕS)Vseodt.ܗ‹sX;8% ~YGR4h-!P#Z7zn FlMAp~E [i|_kHR8pT0"Kdzه ϔڔRJSlEb%1f)m19?A-\.d =ef#הQjIG:)3+"hH&'q/P K)u;şGX#{"^["~7& LcYU©͞QȮs}Bh@_IBFxB~8]ԙt19~/jv(z5A0OLjqǓ]-'.ux/LUM:@\ݾkxT}ݚ)jy]hηZSd"Oin՝M"(pI@\l!R _6"g[$}ݱa +n(=/j)DcQ[7\G<[ftToKb3/̄-vvo$x3o(%n}:ǖGT8e%y@moyY8}"_) h_#g%< ىj+HEFb@, LH6a[ ,l nv|gGZFYXJΐaq9yMV4 utMkJѮL5;]-Kz @L,G yVma23$t|P:{9 t$$jÃ\ؘPE(յ[,N$opumC6P6q~wYk{<юk(Ct0Nzضĥ'8ETpYod,[ЁܜLD~xc]lIMI&o~N'!j$"$ԧάz=aखPCx%y/$QM'7--Mt6S6 zArEqv\j}\K"t+›.ٲR 7f9a wljd^RUH>LKV$iJ b5! S۞ņpH;B.-TI/Py"zPSu/J8i}z}nCgGGLH_!LUjf(HeӥϱJA.Oiw>rR\> oB|IH.h /폈L7k|x==v|Țdp߆ZQ h!B.Ő*_KIW\0Nz+yfTD%Qe( zqC|<)5|E+u;uynU-J-sq ČRdMBݪ" /aUqj&uo-U9{;jk5cd<_(ZWDa[BFzc!Go#ݡ ` J+E KvB wb#NH̙.-,&ΘЕ5a:1 &SR xnP H.N,4X~`cx|Ǩr/n)PpJs]{SfP&akvc xWwZ(2c^D#%CÐ[ m1w3n~VKy JbWOF >VD DV$]"kb[3(/Bf7yi3MⱫ,s.*$3y $nx:2QM=G KzrQp%>).HüᎣ>hJRnZH[k{y\n(v>~1W̭ 8hC4(6ޙ!%gHw UUdٻxGq;0m9ݐW (SW՛%V y$"l^4򛿲ГY"`,)Ɵ=;MɏXgYgƺO9`UǍ` ;r2NL_ (nLHأ ^KKĠ3Q0'KVApe}G<Ե$;zIЙt f.9aO0>!hڱL?&vS_Taݲy0ŋnbw}"t"@.aGnp;H;6z\,m6LI 7X@ĝ (XgpfJ"?pg/lusd  ] w+R)FJ"*s87jݸ7꺏co"@~?_ n77' j{;3~\>$Ok#~>QF'p}o,jΩ? F=OєpZ]R+C?][qʸs~atiDT Il9 7kC^GXxOd]s^6 )>=)ِk0E8~qt7ˡiMԟ!AFupU _%=jvd@@>3pok}^Q u.nvL4?|er攡pY1uVʹNb!S ľ"A lT{뿨ٿ']mM 륆~߰ԺG=PTR"o&~Q߉9-#vi՞܃3č;8xEίҴɛmnܻJ ªQkGs[ݦd'0yw Es.%7*fnQK3ށo2pپ%*a hGgSnjDҘ4l7IFr+T[N6˽ ؒSC}<*…ɃJIeu_P]43 =?O qcu3F]1뾢 &[?u4 btk[Kx :bkI,/\ܩ%q@vCݗ8,(cbS BDo|~ }i~نeG+VcFHegDw*[2lyύP4o~y] $)gRQr:&qpT[ؗΨ5|) G3*{,P\¼4ʣMyoYHrt#\5 R"\"nN}N1F B@8'lCFc>qDe4txfhg~%^UNYy^H&r7wݓe1Iz`)8kKQҮ?rU kz=an",v=J_pC?[4澰9÷]K;e!Uoy"[),%>2L,@${~[iBٙ1ǫ^}Jtэ %J)rmP<3fąV/poOȘZLq$#pd $nd9bşD6y$Mc~ 8Ʈ%< e-E wЌnG)&1x}a͜ G؏N~jO hz{nu6W 1 vqʋ1X-Wƣ9dujucYb7c(wvK3{>`APax -Ʒ[.F|q)7j).:,;YB]~bQ`-,Eiފn@0տ9&ߖ44E IwaZ$@ޔjӥxDƭn}9 O&?(s=41Y@dOPJRq>smfo ]'笓OzׄRC(g4OiF5B-{ K^=I@$*1r(6` hW8櫂1ߋIV) nVmodﲻ-#<69F7?6 ;V@Y4<<,D>󎗄+· SR}|CtSdD\y,)k7O{11SO/x~;*Eh {UG@N?oF0erfk #>2RUG` \֥'_CR$ 1] Դ-s[bh Ligm`HM*,Js}ݺ~ќ ~ymLTwWĽQ=u6k` j:2R# 0)n:)F.J@T#Un]Vyi߭NJ=F[ec&RBÿ!Me?GY¨#,?F",& Ҝ,qi*M*&NLjMJ[z"5o RGW~g VPڛd0#Ở}De;@Zj-cȴEH ]\Ǧi@r/[#8%XH =ò׃3{gvX(i&^_Ķ dzI5HIzB҂V5=)+M 4ghSGtYvlbwG헝h]cAvTS)]Ky\Tx>Xѝ{Rb*awAeq\Qۑ7*HŒ32fO4YCΏg蛯(C YlE5uo1;Ti,TG1oBӯ(̀kʏ4a<80V cnб7 G&c(p-F>TzgJnɝҫ t)+GqЗ8gS$wĺPzǢ^PFn ?hbLﮑKx\߸)@|6ཎçӦ{9>< iO#Eoh?eG\U8VckjCu!BS~X*Hʿ$E e)7&_OŊ4ɫE02n _ܐJC[GlE&<̥B ʀ2š7 E ф Bl?lk<*RZt[jipkdq~J2OGNz7+۷yM`J/{ Dvk}Rn{KFgBŌ5(F$ +eq­ d a퇥&D)yg lW3HuSfna-;4g)C>*F }A[:kwv#Q_"r- |n×n"gz]$&Nv  dkBx(z&$S4;oU)#/-Q?Op'F5A]NuXv3kD48$)&F8^spg8 ܂WGod( 5CwkD 1d`L`7C3L"u--=D`.-0{M| Rk1cjy^4^Oer'dT/DTv@xn|]׏F,So\wUo2`I/vd# .OMR}#Kk&҆#pߺ+?~N? (z0{ L[ pL1oB##t#AMn'/PlKy_2ީW~PSCnQ$\[/j%ռ!s!@/޻pgi㬥GE`;:S[BF^u4L 1hㄤP/ʶBIF:X#+Xe8ﳓm$fm?D >j&ww)Ewsb.)p(X"g=CײsbILC Ma4 �U]l^pj[{5[6&Xo>ښW;o"o:,s8<$vNbSb dMmATgq~IC#5 }Zp}4]Z'00 +Jr9[v>jx[~`_#Ӑan3Q3}Zg!R|+вف+b3 Rvg|iP]~v(8Z$]tPr/eNw8vC; WNV*W_sd%aW^nnc_O{q{.U1n?U2 *,?S$R<ԝAf(ZnUGz#?}><1cWBqpqKܔ7ZvF?"?A1j50( JX;a;#b(; 70TCj"=ۈ4/|ixl51J|.F9^\Gjp}{a-ؿP6?4 }Cb'zH=Mfc#Ln#YDoR)(p'v}jA?$6cij4ޏdk୉{&m[k&$|zlatBM9pO#'ϛ2-P\a0{wa(%>aw_glt m;n޳xN }٫긑lȍ{!}̤2= ?״mB& ZWkE qcޑݗ W7?߂Zh(oKlHjYo8&[)NV{Xo\]Iak] sq 思wP@[ʇ`zz[j4ŕտL_Gy?&p_ҿ^IW8@c[*JKE5&zSC?,t1̐fp:ZsiٲDWsv uBwԇ] ҵSw1+I/uk΄}ʱ;I}ߴkqo_wݍ7$떜_^† dbه~%}n/ Uw[=E˜utBjٿEV1Y=j.OuMAbaHB5o.{%;S"z {W0 IȭNBdۿ.Ecb`1IXb%ְguv_8?Jw޾7k?)S]\P3G0hJSzƆ,h$CeC/9;qq&& _8Sx3d.1MGSpx`i.9AgFSVFlܼrE . :nC@So 6bl݊oOpF?o>!=8wY.޸IS #Lу w;S!%V{F}=Ii!'4Sx ¯6ѫ25OE1HG3؄r֒٨^4J\$!t%8ܰkY{k\<{_ԙDJkP_ًbpQW{3^$=tʶu`/ uہX SXH?\F8z3Caet:J9JחO ~gxxUXܳY5lWI__`wX(l눓U(m+ZJrDmmRHI(UD f'mo^4оÔ| @k\tcWI@FLҨрW0 6l Y/_^Į$Q=7,oDqAήD[A=%A] 6 ],wYw38QEgLЧG&mתJ^{ %JjX[w8zܚ2EWݦ|MO{o܅]"lgb ?]ZB;E=XGV^g5=HS#jq2YߺmSD|,Wm| 3W< t j Q 3)/ BHNTi,쓓;\[90ܓ[O)V:f\ р-:4x4@i/&$#Ms?5'1]ʠ pUAWR=(黽2~5$ksdeٸ' 3<N||'%݈-V`A pc[[$˟?ak|TI=%&$WX|F2aQճnl+FSj}Jo7 7%pl;؏&%ۛ[]4*#=kGe)ɣVfL}Prʰ #yd_e\CZwgKZirq>5yXlq*@Mi cWgT+cgtOxɳ`zz(rnߤ66]yaE3q]p@YRT2x,þJCP\{Ģ^i IC`tZI2#͈d$tkmӫ >q€.Q2ya"Z '$z_\dɠ[ V'x"c{:_.`3;$(X(]Jp˄-úA֘y*?1R/hw o v'kt⯫pz,PHFpjW%$݈ލgM:fvVӤgX0Ά=Uf8Z󀾴I #Eӏ-3XH4C}'W|Os lV33,C o#';}j֥G1xք5˃,p&pG(lW"wl}'W66 G ĉC$\lߟ0BcCX{o}|E?\Ks{ۤZOGUڀQA~"/Yl{YNd|!L&A}lPzeu@_ FqсWњ>Dס2R>RjN.$mEo.QvXFZrVwHl#G|6o$/~{bX⻹_JNu|-W%!WfFJsg oMac|KܭKTvCHf KIs.%퀥a5 h7lpѐ ]4͆?۽OyGg^-$>z\dgrέU]٥F#QɔjnX Xԅ#H> r/>(Y!iw򉄗#pe*CPYcuU{)Pѧ?g3݌^^czoYHVG^穨7=@f>i=B$.c4a8FpӔ+Cn;5; W0VEj(*/beTӾOٹO5ש Tl6+:8  z=2 a;Bx.0ƍ Gmgጪ/[ˈc6d3wa9 ?uKOф1'L~GOM)x_ eʬ\B d1)2 ak??iE|)X}<KQ#@Jd;fi\b KÙ(A !Y[?K(Iۀ>q;#@ȅM(4%Nm»[zdG'lU>>7eQh4{3ZzLYklF˩T4u hŵZ+ )87RRɧr"n{ x#$S|-H:Ip1R2wvͬqp3E{[&?ӵ~Vo]^VƟ2.9쏮09[V3O[n. JEPB2 DxPk ȃS+ؼvH”=xy=EGE#`GRƒaH/0ےQI;sAB6Į0cksդ&br< "y .ժ!eƯIآ{ 8\3eG ¯ŋ1EFwC^b2<"H8:Z -0kBi~݅wbKDo.bD:FI-l`}Ⴜôʆ0#WB)oa>r+X8528 XnK%= cJܡcM4qC^d> &r?:4̚!Y;+r\f^YA/ ?{0'L勘Q;_~9+RTz=A_wʱ9S `mFj7B_(8``\!?Ƅ>LuPcuƷgqh/* ~mB]jZ0FAMl%lt5š6P01O~ =iVLYlLєuٷn8$@bi- עZ.NSsbP/>Z#U :[x7_0$hk׈o) 4!"Gí i*cYIxvH/4^m(gҟ>(ڧx~K LŒ@ NߜtQAbVȕPHPVJK,=^>JѲ51AlŪ!-:?ߩcX^X5_E TQ:,=y =2NwʕD%NTM<3U`Kz)5vb54I]22GKH&w\ 25St_!5-d/ ~$. !ru"ddJ_]9Zn_Gq0xZr@6@]cP=?{lm{~":a?}}4wÓbr\W|L46|u _D!<($]ĹIr\N)%08}@"/L"Hl.HqFY(pLP@3|O8Q:}0OwCk+qVϑٹZ$Q仓lFa&~UDAiX_Q!-z=O2+4nȔJ%ܦdMsy:oM Ym{Jߗuj"mQ֪Ujϙ%bBi;>Q o`+)CalfQ 2} n|ēd |FWzGZHb@.iXi_7U-t\5gi"5 u'A0\bJH,M]'z9@gf-+on/VGnq,-KbHN_ ueX SrP~Kr}bsXmMƨKC6e@PRS T;f}o5LUmG\#u<7TZ09CVؑ`Mh9uvu[ 2$H#J1X*1_[qbpԾnN17)Pu"+P#@GAk^$&T ?)} O7,N s0jpثXH~G~ܙ)(xS!ؤf "9>q/im(1 nhS<"cm8PSbn0G[ +Vt]N6i]Z3,[:Xs2~vd_hq ݯBgn[,-o? rܿh|K.BYE?1x~?Pʄ.3 >:گ.c*9dny`6E`z#!tnY +JH;z`7;|&Vy[h?nЛRJV!\3oMN%z`U_<6]p ib gMc NEt [ sDM s4 Sh28+n2=Kf9nq %?8!֨#wZ!_a^"vtq?SK୺qdznp̜ ~;˚kc.V؎Px|F"^f ^W?vSsCNBCO=Mr0=y5  $%cqˆ>Q1vчΊkB~L|܋4pnaPm|؟E5Q $瑘ےrQүɖt_E1˛b.!oa/Y:\1W6l QH23h\͋P n-IvOzQ/bCr8H{"(b/";1(W^| Bc,< j=o<|CϘ0ngX%jyodTh эG 'a[&<3:[gk#] K[V3KG^k\wέCOؿ|ÿ~}n--^*XzR܅>GMg* 3UCF`hrl_2%A4dZDXD!Ekpصqb/ P{6q25\Szfϋ$Wؿz/" 7GQt@M5؂|/#˝EE@y{>`HRDMF/M)b5ظh5]5NhMJ+2~u?NC;"^RfyUi7ϡT _{йr4 =k|-zJ4Ա(G SN!0mwNQ=,|3cx5=+<82Us$']ӝ=n7 Lz _]-3zg!8 OɒD[ cU@@fVWl uF=%ăc!;:dJ"ԙ9tb Pco<X gvg[h&:qM)Z[*b9\>ܟ|2Z=}Ѯ@ֳ{k{ 0dPQ*E~N a5SK[b R0/<!@RF]忽U&p͈â@?J5 .=Q-FWcCSuJnI]G:'QEL5ܔ4kb<0\{ƫlU֑`ùp [x.,%vXQ^_.9|~yՊu~\M?ǰ1b/b#4_Z/ecޠa#/ZS[#*S9J9|hL庯`l՟| pE8^bM;[ s'hDdѺ?ßsq)l-4g7lR&m#:#n-T|S;тoӱYEؙ6lHGƾVAvE{Wcf=OZ'籓'gE櫓yxLҎSIm?+(Bud`5*Qخp^2ۅ;: &6@ E { \8 0wFhI Aic o?W7+JWcwq#R]Lcg䬜7dP=]^% \±boHTAȨw,hhGyRճaH}T ('9@,mYݍH'GhCEѵ _ءU6aJ[K*8:ꢗϣ+V<@CURݗe۰PKRDsBL|Rimages/img3.pnguP\ѳ. d n]CpM]  !0!˝9֫zUQ^w<*)*|.i NA  F SrKG]wNaŹEb`񟂲jgKdQ6qa8DZ=H/KJK=q7l@w`g *i5!Y ܫͲk"d?ڑc)F ݍM?IBI%ɡ) W8H?ulxljDWmnvZObڶ"YP$MFH $%WJ7'z֓PUA*HL#BC(jnŒSB+GY.4RzX7,X8K6Ĭ'iaFt A%Q3A4Wh٠v[ᑨC 12. !8Ͼ+ w斿 53IS=cؚ㠥0}\Om5F\LO «CɝVN`ʘSLGηà6K8T<Ά=ZeOC5fǼ5&oUI1|<+?y邐ܭɥyK> ι+s *OpE8癝gBW&柱\yαIUDʔǭ\@b"z [?@ ?xޯȬW+7j Ҥ"]LVgەxw ,|ǩƍGU,d,V1ANo R~ᗿ6#"ܪے)YC,Sz]0R(.dMWk2SyJI˚DKBihO @@p8/"vA ~e(χL$V}ڗsI{8 Ѵq#Ryi?m0O+pTL)^F&dzx:$ywQz׳U` a^;56)YEc{v_S"\rc WYb.RgnQt?G~b3_)e}M-SY#p)/v$@JsVcn!D(HwI55al{П*/D[%Ӆ< Y Z|FR%8Wo 2#aN&Jk9"tT:`3]@fQhAZqm-t~,ɼ\ rq]j8HYVG}C)DV" mS!v׶DYHCxS[bgH6uiΔ&^LoB+m/s\irCCH9h+RSv#1[ϥO1ppwnDr~욄A[a?Wt%H1LHGaU HV-sp ?CNTwԷU).4a;tsc̰u\ElDvLGB@X7сt`^y .Ѵ>3m\x?]ȭN?s`'B+"#NW\sGnYNK;^3z%BW%Tb0vdl%.)3Xhe@:B\}ib;y׮8PqP3}%;3K9Y"trQX"~[35$f~Lo4!*W2Y( ox&Nx}s2_wG>Դ@b/_:G = `Tzpvk<26)Ž-UHQp2/߽,w,#)'F)0z(22ii6:j9;eO`^z!6`o!HԾHuiZ ~VBfRXOEQBy) y(2\=/5&J;c|>rDZ1aOo#k261i͍Vaxok[.629oad庑` hX$?u:f=lceߩIh6EWI} S\nR^iO7\WDWA:xT K-^HK7;!RK%ñy%wN{gg/9 ߨX;yI]X2~ƣj `3GI > q?Yoۤ-Ǥ'Ʊfh$!,H !Z2םLk~ 1h"Y-7{8.YԋFF2O]1[6p3]g-Uok FJTQѩˉuޘ5g'kCkhEAq8=W 蛆-9Stm͌!A K"Mr!'sG SSAe!*/1[ '^ꯙL73lj^iM$ҹ .l) k}%'JO'*睼4\tAnr w A/pqucC3*dpk?{_alwX;oQatuMJDծO%3L2uZOa@X;b5U'/Dǽ8nU9 o>w0 DyLN3ͿaԜ DʾWpRE53_F?3z >1vjvc6V#T !,'DBI-I|^e>Hcp5%~q>S2%@k1Th ?DɞۣTRo0( is͍iKl*M qj,;;Hd 50}K[cD_2$1^i4ix>g+q˱0 A(V5 tA3B'?4 $Xc{70CSZ1sm`[V-כ5@T#} _b|$Ӫ`wa!br<}7qӅYYZ\|Iˎ'!-hH=%"L GvbeO ^&մ t 0 *OܸṚdm>m.TbD8<nG}LiԦ Ys3UɆ._I}a!~rtM& $ֽnHQvw6x-8'F.^;MZ>"` rD׾&X.ڄ5 $֯6-#(+1Ixt ~oqŠ<|:%[㻸㑯vQ79/¹ 44c{ eobƩ.ʍzT؞b 1~)] A\@5ui?+gMxE Y{EC^[W2O{؃lkY7N~!EM'sW# \vkO@A &6UhdFDT;T LuOB [; Y?Q2GYXA M+g]T/aV1ȕ z0? Wvll?Q\E;>B\lijR@33֕n]dR{f8ˬó<7OkkBtm&)LQH-yA^$8f+7{ ;9 GH0nN + \kr?h))k=^_0}w6 %.Ml@s0v SalcAT'0Ւ@4dō ZAޞ״EYe)oStH$PސIߡY /"S^c]5K4%5[Aw_-vͯ )s([^p[ RWW`Ԋs 7! Z"Xb~9ok7@ɑrjp;·q{a~y^$~l~o{? %v䮳o]gB2DRc)1WLFHLMn qWHTVξ.ۚ_rB02Q[\/548Yْ_][ۃD}3TEPz;~%1X ߭P|{GR$pqL㍇h)VeGfùo/ږgy5 >}mPDÃNp/wuV‚r,2hDO`r%Ը5Ͽ[2{T:@Bwxks/?ܮI3߭fT,yYþa2,Cw{ba펲HOUdi.zzc<>=vi6um2-A\c|4S;H+[@d,TOˣ5V;q-纅D0mxo={|wU!Rn֗'T& }u,A:+;WJ 輎l7C15Zmb?2A1AE 4ֆBv)m#EEa>ʑ9χwAVk:d0a;7RGY8BEZR>_J$UB*Tfn [E.;rw̮ 8j-7펆1|Ǎ{!.ͯD^C)ڢܢ&p[H\,:e<1]:|b[^'Clwp$uS6ֈAtkRT0Ktu7[2NY2> ~ iDYZbXR3{NLevV" =[lnJeS yklxS;:žĂqWr}|tnt_+2%%I[0)wjGLUW@=ubADLBA[| n2f?lW R2*J&+]QPW-Ahfp+rdDܿu,~NA~5'~6T T~N>Sln݋\JLčO6f؛$u qX@',:lv. Y*d>.=DFe,%o*"a]5xPS~>/FƆr{j) F$Y9)]CӔ$NM(vq]i HRF_qz qPjbU]Oo$.ƹ!g=}wK j< '#/ I?`x'Qߑfn-)N u53RL%%F?Q9od)2jp Xa߳z/۫3Cʘfn8zE?;A{5Wݠ3ި,|IcRc3c\ Rh:'DhkvfNTm{KA"=$&0:]<]K(v)<^5|2Y.WN62hW}g% eSI%^~hYck:]:B؀a@M1ُTC'̇;~fEiJ8 AfNaWz#<5U:S}kV:/0zADZif2Ml(:(#5ޥrHWOF x̓c߷^R|NEO>U/ǹnM8j:5W֖G9짏_a ؼcMxG`hU=]yjJ73hĊt7's_[5WfRj;UT!)9ړ)E8yXZ'RǿY<8O¨CK̷-~dFkxl (gU*$3okb?iYtI^~3p#b n±ALnƽy2>a U.\^l53zQ:RMkO&du$cAy2c&<{ZC$4kBkFj#4 szV[L~L=c7DLJv*Y`8F0ޯ%)MS<ǰD \觌-k;OxV= Ya>xo#)-4ۛF"{F`&r"GDGRP Q`Ќ$ڄMd.Pa5GgyԊ7;!Ta5¸G7"Sb>rFu}Y3?Ӫ3ل8i]_4Qo8lM3P{JH/{꘥NJsɚzFZl!3&3+Uwk zy903C>PhOO< \Gkժx)l+[-*?e䖴u!`j;^-ʮ F!6 ﾭvJq:/f'VIi)3ܨbJ~0ƳYཻ8"أ![[e޻Wvc\1[pF,L#(!xJ";9Te=5l=^fh%vIm59s%/[JG;I0aFeDښ Նxbv; vB]3wpՁRdEl9=Q=;JcH *KS[ڎF#Ͻ_&htE4"еH?%24 {=Q~PLy~dW`,|`.Bs6ƴ+UDx-ь wKHt5Oщ'م)R72]'cfP=}F{ fa8ԙ4\wGr )>@ۯiN1#r+yB V#oz0)D=on?q'0'xS<)'vC'ĥoaZК1zxUgq:"?H}m޹ !X )hcG(G lZVsE# 6˂o1*εd) q;فWkP2g*u̢[$|6i:nnɑ':=3oZXp)VNc"ʐ@52u9OJDP~ 7jDz㌍"7fE5bs)=.mK js)HR1Q2lۖ{D~QVKRg0&5`7tk/$&wO;GFV츥d@a]J57./!q*Yx:chc̟GBxwrĬ +*w"Ѻ_ {\c W{)-#T2i`YZ/XN!K8R) 1>l D[ Kν ygP{5 Ylir AJ7w{WMMFxM=|kzR%Et(M$ %6+X |4ʃ`n[g}Jޖ5+U|| {|[MTA57^*c3[ewr)ʜ$8 d|s;vF*okw0 JL Sz ڡ~ݞx_iZ] XQ".4Y;oǴkd!uVl^gky!V͗JT.aჺ d^dFb% LP Z$䍛GhD'"F~]VFnK}n\ô>{uyu:cnW|_gl[4 ]m4d*b~hSNB'5M`E1LS'n>&&GvK@ip#*f>.> P7B(&űXc҆0*SlE:m@>%t(:qNyyJj~tFRYXI}7EAcRˊ*LM#l\yHs* aT,/ϹO#,҈yizws3<7QMUDMJ,f|"BXF79'q7vQ&m}b ! |-'$u)!n|  Ԯ2CB53c:I#5UwAzcGlNFχ.n+]Q!n685#ȗ;3 Y[hmFo~kH2lwN?K6`R3Xz{s2U҅r13t!|-b ԗ8v"ܳQ_;k#_NŝҌ~;&ysI Cu^$Se?xJ `8駜PwtϦ̲/ e8&ADŢ]~ `M#ᓔ )_ҹDMcZ? ZZy4"f=zʤlf%`[H]KbWw3Y`>puK 9tu0_b0#}Q-eL5f +U3 5f;cCz3҂$~yXB(2+h}GH{L@g $f\.>Ο'nL KIk&҂|)!{\q4A-ғo뤥U}=bB{i!ZW,Tuݙ5#.RA<2c-*bK63YbQ) WD*<[_~qɸ?5Ȗ=d%BA3bMmi۱qT':A#K?W(8|] $˿I-'' +1_[BaA%|rr6ʗ=wUwwYfkvʎspbyBNJV'w*۴K`[=.?W[ $.6{7~~Q5d g֤T1Xf^qr}$w1\Q!W}לhdMKFi~6%Q2Q_v'22HV)땳$ϭVPC+Z &VzC+=g#6-IN|gRTXr-A-X!A_^Xi*ƹ.%=Bt*[,y4z$}ɷ_ah{GfnBkav9/Dvilxם8W5l x([^_kdrܞE3o LMFLI+WPFe}ͰazS\$FgWrج{(Xuwb͍kU |zC017D ~ T Fgt2.e47'FlJeoڼ yN2)[ AQJ]4&ק[]dIʎ."`,UL6- : vA>IG/ճJu1>ShkqoGLd4[ἜISdcZwday/VpC4_w˱ĹN^./YDٲʄGC&} o^eP=oC15$ >i[(?\?rôR2E\.inʴzikq"R3?Up5}(l6_0?c Okd$C5;J@Pd^J 1a bCAl+zwgjO/F t(S0 %I/vV*rNƃݫEާ|r_I߻2p˥pntw>~s0{Dnf^Wa- 5@-y:X lLg 8I@i%"ښojkiJhC<WIo=ɡ wy7UY x/]3mW󒭎V&JY-ͮl}QT2˗ C&* >!X6lMEvh:^НP|r%.ԊcJe.<.\aYޯڃ3mE 2H~v@jr ϟHJyv˘5%ǫԼ)] 9߇g=;2Չw}&Y ٭30 xp^\Rv"lTSzQ7%_[(o4]B٣ be#R?>"p w]&oџ&3Ia1xll\n3# ~yjv>Uk'B6I˜K|lx #ai,фL̓5xH-dXnfSUn`~Oj{:Fɀxy,,zg 㜧bxRpx-Jbq jjcZ ?aJ\=1Yn9_Ѵ~V}eFp@DW h{笺3 %Xn^1Oge37|_t^|Żqֻ9̥Q#{eDZ5}cQΘK}Q >B$ZUʇ/QdYoc!ƫy`"#ݜSSUSNd1Iz;)zݗ!8N@ae5wS&o X{æf`krk?5N[˜KW'MPG9w+g?qr;*eAҴ~2!$SJ LBb~BesG߮ZaEX0Gkʹ=iujzj R7yj8Ń3H} (R<n"]> h(v6o~n:6@ʁtб1= b CCFԍ4)g%'Ujz,^>x'GEIK 9uIX?FrrKl:/> W9,M\;pSX$ Vjȡԋ0 </{x7|nK<YޫYt aj,iE0cy 2V&v dП.NahɇDgC"9}kSucKϸoz}[> hJɴk D]Ɏ f;.,yDm|ָ5, -wv $nq%z5R'a|{[Bl I>O NXd@/+p ϾU} 8?CjᶌCo ya@k0%\򓸺FмO{0(1 Wm=5>t)rǽ'w-y'!\o~`O~6c'|dȂ>C佟iT$mN{\!R ZFAIG>r+5m /p,Υ97h(_Oa9Z;^qdvw kAw=?CI5!~-}:zi*+[UȰa&wRjISX1ޠ(K~Hղ*#f$|vSoG0K>zv[.&M,ܕ]uj@R?̷0CyLb( ^ae@7_#(!MX9Z֠kpZ=bo Aiϖ::r)J~~GY˵<)CŢ Rbӻ?\q@Zm$AVcscB #UKTc u Ni5'vF[tx#r^9ȍaVmxnW=?宛[W;foOZZoG5&p֢tl!@}g+ڂl"LHqaKtP|ϓZYe"9Ȇ-+sPHsPA2C0GY\%O)bTN N||A~Bxu{>= 󰟱*b.WSq=vD n4t[G& /Q'$]*W~1bl, zuE^TM Aڄ^N<%ٛGv'cfl;<'΄iKOK**=I, g?T=os^sCΧ⣊7Ic ߭I~]L5ĖWsV7#xAC\7rhS_:1cf}Е}I/?1E:@:fbF'v&eDS Plc:&J:=eJ%(-ʕp2@$saEL{[FYz3zݬ:$/pB!Ơ n]Ѓ!~F/]Մ$f/O'}H00gd4O_jm8'e1ã!]BԻiT$Co6x |ʡJ *>N8iW_1<ٚk(tk T|)OL-Cne' tڀS9.S4.\;F 7\O{V}ި%Jq~DI"ОEa l\=COcP) &hRuD:7nVZ^o 8ԋElu^'5G{PCIV]Z3?G /w M'y8@[ތӥ2HD n_(돶 (G#oo]wWƼX1(*;G{_qXUjlfi\dbnQedvNB+}}+-XG ;Ew(gϖC ޱ+mLVKoM 4TxqZUz ̗ ekn9OtS ESlsel̘.Rnn|ZzRwG4W@ d7HPKs2<NB@c5m/<6Q;gvV ʃ}s)߷3F7}v7?y6OI%;U1#G}z)B3 ӕOƀscJ_y> F+S>}wN'lb\GWL|Lܶ3L_L[9̧WQ^֟djuȭʀ/ڂ &6x Χ g wp0n1*$baH3Xy\Q}jB~_F7`|P|qY:O[U}#/V㯲G ϝk;qy_ o&kcQ::e;|k9dKp|;@?}LJ8*48V|9Vp,(ִKrV<3x$BBtoݼUƒbҩD-T6Ia tl#ϗ FcVE?ݣ\2y9)?\7T{"=;xmGeZ/dnoo׍U1\сZjq~Z/5gW(vD "1UCK#~e7ْgxNG,dqŅK/t- :ޱqZէ}pSW`ekx`%{xiSՁD;lS$VyWd'rOrWBIy$.o N@e/UJ~ \D rJk]qgѧ4e_9@HMv"[RgV#=<ѠU'0f.?jlw|L:]D̆Chr4#{>!ޛox?i%hBpx,rlMe|l<)+K@_:kLfmg.k>ísby,37I2~}9W>Ǯ4 Ĉl.\?30CA{NFER3TwLG TN@dvCtr.v[-T~~h$(fe0}  *Z.gqʪEGޛ0݄/Z$ i;y=7'``^Zo([Fof#r{i2/$w1^CڈǷP}!xDd_Wg|JߌU)_MY{fV#QT%,nfB\%r8t MԂ$]04PA DxLdn1ma =R.,\.FNJt(ɋ#ͥ T8-5\v۱V cpu[le%A_%]&v^'b!NO-t$#z#Vr39'u![zI+vo3U?(̩n8yRh'2TCƓ? 0p^P.7,nu4x5X/*>(@NQ`d*/vuq#_jL;zP84#]CA5IS ,[e8@ !p\ z1Rn1լ)߷{^*]T';'9fO}#Hyl$~1pA. vfBtnh?7%׳Sl"4πkƔ;lztރ\hWR {bדCͦWk svW*oy:4L5_4-?$46xk O9iɭX0Gܼ=pz뫔 }T^W)X0ʨcʦLvj܁&$FpsAO] BKX@U0P}jwv c`]0l ڿ/L>my,/~Gɼ7Z,%Zۗ8e)iژ͐&=As27=<mR%NB|ُDȅWnF Kj/1WN%k 0]Z"6 k8ѓ dj@V_]anr he( B6@{>x@GJ~ tQ*=3bP`4a6o^P=Kygjy4匉JHztkJXK &] \$ `=(YpI7Ï~@IC f 29W^Һs m^@2gf!]U|׼!M{&8|U[ɼ 1< K)*rK,WBD7wdj+=*-d{'C+ 7K\yW$!9yHǺc4Ҝ0! J85hڍ_>4N=(,cÈ\NȍwdW@.ݞfv فt b/'=ldžf('(z7z҈g:icxg8JLwP^y{C]/Xt{ܻ&z ݕ3, {XT;d8" }c~p?` FHy,ǓЗ (-_5l]>h=!X/tْ;벷?S !QVlPv0̀I[@3Fqւx8KS/ |WTji> uDFJٺ(ұ.F1ᙁp'>Hhn|n&CEp 3;; pҍy1c.o,CDoǦ=9)ν XfFc)Rc(C^S=1wbP}&Q@bJ(S&s1$ ʅ~)ʪȔI/PKRD{images/img1.pnguXa> SJ HKw C RCK Hw C#3#" H "8y}q{ u8ukM& =P Op_K |"_x KK]9Nq!e"QkZ}l&F7agp*dmkv7ӻxFYU\\*S5YB}+v֋\|%?}:mnߔA_pH.Bs*pK2@nvJOcS+mS}Q oj`/L|8j5W,8~de}cIn`SܼjSF9'AS4~s. @nXn-iz4}6\x10Ia 2hѪ"R'MPgkMQ7u 8}UOrtZZ2gB ̧?v.zM|UwHL3`.%9{Bj'MkXRX7@S'-BtfVXPVe.ϰSRZ 3G/6N-9Kζ*}6Ln9nxsGoPGNm!$ZN@{࢖e$)cޱ^)E@?$D6O3حrZDG=2g,4B>Ət!_BrP&犕L> bB _oв: #%018žصzנ~UzXwq`ZVJ(t~ M{7"HYxRף].v`g{K7SN9 , \?vLX;SRCcog*Eil^|!o X2u=m>pE'72XjVLg!.ʳUlT zd(!{d\⸱BNO[D~F!@=s/- v+e s^Q"HهP 2H SU@RȖ g׫9JJooS4.O>X~A@y?*";1# RaNba.rNRkJ-oU)U8#x*aV*&Ww<Ƞ'ng2_5N\49sE}{4l.&,P[ 7{ 7蔃 ׸|tQso}fֻz IXqn3z˘@ U!7ǚtVϰГgv&邌&V*R7@lYNt8XE KFw_@{Ja|Y>#f'h>㯋*污;.=1S+V{Y5oQVfmckn]Gug"ҲPHm_rk;hbicl,9Kw Vg=UzUIMyY% hzU#vǫC_/Dj`mV ,ĴjDh3:Q Hid2?JI0BEfcESӻnWjxrʷgOݹNW6))@"V@b/AF}A3eK*N}X(l!Ͻ np/?]ZD74Bio?77U@> MxHN:>8IJ*wju?HyF92e~ Uy mOc.ޭ9Oy= xDD7܆,N]X +;U}H @Kt_&/DǬp&;*A9'] 4˗Wp4m)ivX7EqbeJ34UQ}`@kO͚. H+T,2yG$O4[M)TG(4yЫZoLXڷua[E[rQκ, #clB<cJљ2C‡Sy 9 ?.xl 1)xulOjͿwP4䳗+4?;++դ+Ƈ\=p#.Y [-cEm!u0no!{= K(Mt,L7dVhjbe+x y ΄Xi-\2[8E`UZue5x$Y&ɛNSnfyB2rz8d8R\;ރБrOjƖ$OBL0*.p8Zv[8tDxy b! )N)W8F%H.YndٺԓϴQk}85vCO ulɇ&0 dG9nUU"2qT"ʹ@q\Ibpץ;SC N!yA:׹r!lV *i'{D=l#1nHҿͱm,_^וֹ/͓2)|%Иj9я"fo3a =~C!\u4sb!V]N9p.\dβoq#XhJp[7>gTMMtݭB0ͱ_qXR*X7,2=ZO|I_3V}n g5pҼ 1M:Q/Sn'F8m:=\g{^<1iz,rll>St2KWI~|xJTWE‘2}b0AlA{- eÉ64UIhE'dn4L >NI/G|~$杷'&}?:{k: ~#Ow7tN5H`gKAtd۰:+&Z]9m0֕Ѧ,]|I((>H=k˺QUgW7JW6!ŝ8Lzz9d) Fނ[*k}IA/,tGg EYUxLr<0KuÆTڬo2`dbx}cϧr޶M}P:o;xNm픦_Ƈ8O1⃕(¯pAS(S#qr *# kX}fe}D=bɔ~N#!fhtgQ}jq%$H}?i·@to69:0 T] CK`̻Cmc9xvceX#B& ]6Աam GOUe^,pVc;PB&4r\  RY\ѧOgiw Nk:0X=>tj51 졅.Qs 6)Q ucNXV)d]׿rP=r6+} ԣ\5TPCZ_Fإil@$ 9{C5LQ{nF~O#mo1w4|6{Ejn崆X.VW\!2WIǬ ꌬ` 8'b@nvb*\2)[>pfٯӵ=ēeդXe@c[ [3Mja <5~lJGNab ١wK:C OuR+NH_*[LP Жj%+d9jc X-ó<*W` ?rӧE\'µdY;E{G8.zVY-rX9+&*" .<҃8~fU,|)Bh CmC6Mk$wo!OFN:iD({l:'ր0Y_1u!] $\ hkk*җ3EN{'ry[֫9X<ȥB9D_PGeww');`O D&QⅩV-S)*|/`ͅ5%a]M.k-:%S\\܏P%υ#7 x>88hڪ7q(ow_9\2iei `Ð^{C?vJu8Rm>k{ۅ,?h,y|u10J}ؗ s;I4-gAT&E}dqu󿀩 Y%RYLliYe-QM*(NmHuK( kwKsw_ P4׆3Ts팦)6UT?}2OK _6{=BHXڒOBD^@DGj*xi:T[%KvgYO e)#D qv Ja:='WK"qc2O3L^&΂2w½k'@?SQQP'< ]\J+5Nl)˒cC>yiSF^k\a:w^A #p\FGZk_ek_ԅPS?bOAbgrcg'ܔ͞>SV.ڙ$7{b4%4@*='#eakG>ٶ Q|bia!Y{ ֹnglsB(ߺV? ,zD>/% uѫOϢVئɸ_X/g$o/zFqM?wS^a֏~?DS'` 91_/+Bxhn:;Ij1/ǚe`c]za^wuGm뵵 nszRs2"wd@ ԹQ܋L5px^"ئ:|dq/$Un$Lr#!Jŷׅ[Os30`X_9ϻK&Q2ʋFmoZQ4λF~Pӧ E !7χWY(GH N@DFjFy$)zq 5Emn9릔qK ;ȁN*D4Y+}S'Q+(}?fZ,bNh_vAv/r64U6 ZY@ 4u =G!c[z|}:YwͪZo@(,G$?w,(YӫT43۞M{Do!慐>[q{ˮwΣ:4kdedJH=L{JaV!LI4wW{FZEk,ܚu"Q~ ٻrX(7՚wC\R 916⺳2XMi%]2c*5: Rܑ#E٬Ei**>=3S w>ڮ΀%U8 #d:j)!q9D5>LoDJA7Xyj ^ Hٜ*hڊ,rмbr:3-":Lv'eEF/e=ѝoμw^ ޯ z|p-?%ET77WP]Acx€/%W&ƈo pB׸=_#0BSP,UÁ鐹-&qYR)6W`ׁfy"{vH2uOG9퇠rnyQ4zw/8S_+ھnr䦽i'J":mTu<@غaaWypA{] ,M( tm{8^DLH+Abb{*oO)sv*otJ@I1ªLQ~4WlFNFxM@0̝qO3…:[z.,FR Ǵ#;gk5$-eȂ3:dUN&SDXP1}MƧj`uq}w}''Ŀϩ%B+Q~r0h&b}}0dX\kG7`gI|G]u gW ['~(bF2nʷṉjmO,‰K|"ikhME;|zGxs]<}xYTXkj VDqRpn?=GB翻vŦ$wk[Pp=dL=Oyq!4g,ឺ|TSYai~8x#.I~Rnx nE1H^=+< اHqjGyU 6~bOg$)7O:i )V bJ2جC'" :逤r6YךۇQp7遧mݼywvܶ{7)g}KPGjμWde׹YjMͨya\ʰ0M1S8F?*'A5A>IfzvzsCQ H=`П+cݱ27r"M=0y{m.bFATa=XuP si!$ȺKFAUhwd?.7e#19~2~{ kK2^FDAVE500\u.us_2F>E }r'9\%|Ea (ݳ- BUݙY#=gһU;r!|vaoaebZݟyӱ=!cWY$P:#sh=bqu%F?-͓Gl|Wp*C%0,U;It$~c,h1p[?Yټ7 qQ"fWr\@;IHX|̮u}U芆o7$-A ( j)DFem13m' Op[p84_̜y7Zw\ { !X45>0>,o4{]s%lCJ8׉UKY'?-f)p1mUu5ШE#\> gdM9*ՙ!}(]/-ۉwj9`$K)(cfC'whf'aqz Cn+lN-{a*&m:WϲgP³g͌`.c2ҡ\V Ӡո#7x,{}STgN!rǞ1AanhR) T^+ ;2wpTWVdcQ04N ߕdJΗN'x(Xn[8uRmoR=|c]A;u;_D!p7ua")޽|aA!U&mr.=]P1ttpqeY1+̀+q$p ^ٮ U{ H?xK,7[wBl'w@9W.ֽE;dcڅIKnnOQ=-u'N,խ̼.YXMd/g/. ҘX]IZ#CymgSn{Ԧ2^)F&H֨?{ۈr¯C;U)AL8)f{6m*KvNĆDjvx|5F\0<0:"~GaŨ^fHZpI5LGE>1bxWJ:? ͬPN.9l0o n> 9}t]F~3 Lo[RJ_tm^OyH-}s"%ٻc__|4R>8ܨU"C%Td.'c{!3m Xc{n-/d7,=Z5wtw бִd n i~WvK7F5"|Ƿeܠi1̼,\{"9&I, v(_H<+2ARB^P=ݺ|*&VqM4 <,OMY_aZ*@J~-٤m&z3 >}:/& sIŽ$MI) w:lrk놵tXˁ* )S-ՔKV"ὂ82<oS-P 3⇝#nex 16 BgN*YcHCL*@x) ANSV13dq7YڀutA"тR`\<Yu}L:V*.J8nU1>: e2rCi (>"/LI 6ٯ

    3i[-NB;2b _$}K elB[HNo&6 n 0*Sۉ;}h/s$ȫ\V}֭L9(iwe%E5:z}(,^{zA}F3ƅ+ =U8"J{tM:F}1*A&\dwg?!$x?ēmחa "j?ܤ҇|M}b9DLxdl\6r< t9B \}e8-㨁Xoy=@S:rkeDoZ>a6|::4<_rmͶ$72w8L糸ywNc5uF 䝾mst qr GazqNK K p`g ? 3_mupxF~B`#}$7TJŧ[;(e^1 Ʈͯ'aa25h}U-G$&-ui6|hB-tDwzףTd/D0PVĞs?G…@!SDŽç"aM\#"Āp$fVH5UV IȪ/W(&f9…GN$$f/X0!j]L(Xc:{&5Gv:1@冧CYӊg6^*8^yCy[T!^DHbrd|ᛢz2REŪ !U|%\ۜ,p=+n%29Љ%Zhs Pw$}q{ M4pf!flքn6\)8nNި3p)ɣ+:@(QҟRwwSn =];kӨJ^GIuѰ.g=x͔_Kjr;|5 9~,>Ho@*b2#[;.ɘqgιUoJ#`?nfpSl")gLҋSUO8 ZE藌p;Aٳ [bHtTBiϬ_ GMոWT 訜v~zMX߄O pe<8v%}CԱQ%4P% pdH>2VV %HW9KO9JM AznʩWQ zl؁%f5 N6qJ پgcxwYK@-GJK¯Wc 'b[1?\eԢ;6OqPY=Jj`]J^rP䎛{8V@eV`AEU^`X<:ub9M4B}.@ayē9nNv͸<ŃԼx],1dxJFWl 9DL൲i=b~c tͻR"wŸ e+ݞFӿ 9u.6&J>Z J(쟻U |y?GȈcGTJ캌_VXh}+^(Nr[.W5vc+Rޢ۞RM2iJTrp.8kf;_vC̘[._]W';ql_pۧž7 &AtsN2ٍl_{} M~5_ [QنGbi2{s괱qfiT~fXfh/cשc "]õ+U̧m0HZ01m9M'p!ˍpK[8-]"y%6P;.gryu82ild[,֢~RT8},QJp8ƒQc|}Wm3P4V.E3 ?_MmjElsaTY?"uJn>~8S (ls 6.gZl3ד@PKJL,vEPmF sI)NQ>;/ OE+r:͈H {E2H+g3"@Ι<;g+:m-Y]p(٩`-u&7[ UdƉS&Z E ]^*>s]mNX DpNumEJAec-5,'/G5YPۼ*^0V]: OW$2KY]֒%Y{ܫgLp)ݜ$)uoy,$'(xe+;-:j|[M]^z<PUOʥb<8٤ՙwm@{2_1{ %"/voG~2eW<*lɋ bžUĭ|!vpy[*iö.ف@ÀeWWCI+u~̸&g|Ϭ|ٚ]I`-'V#_n5d |m6h7W|xݖ]%DDm[CĆ vS~Ja͑l=~(\MOjv!朚NĕBƛzZ|U9OWυF_->N<'ywVDcW gD!.9燿6 }RPS+2 3Cw9a! `Zem3o roLɐVUCǷK|ea*Um\2T>KZ#gmYD)>M=L&=&kt Fds,?]ƹ]l>7*FKY# 4gt^U,/vGY ɩ)PJaSyʨ灜&U~:n^+.;h䪕U6&~,rbM Q2$^eGPQ}t(XPkVLByf,CL⣰pD/ 睞!Kѣ7[cjNĉکY36b>kO U=w9X/9A|ߧGOb6^W.O%OWxgp%+5jA\aB\#c>4n8܆xmHб :o#sT/}k4]AJEpX$pp0,&fT!qt>P!_*>mFa.A!_^A >o퉡uЕjo(v{E &_xܻ:u鿪aJܾzσ<<<ӻ,EF] KUcp)d2'G6{ifoH6 PM5xۺeR`}&Rhi^1-c!:Jҏp‘e W{yŤ'X@T?wc>9E2\Wnڜ|k k99ppѫ00_ņ_R w|oS~KI|*] :?U\AY3}=ȏgnU9 o ;d;K~3/^^a@WR;@ũCTUĝFꧨBB8WdKxan3,ò s+-t{%SYQ] QTj,'zo9Isi){nkO!T#?i4 똗NeZjIr@Kf~h܏ؐ3+/kUJ[dF^w4YѢ|ė855$M}IFR 7 W͸3<\GDLGfN- a`U+{"5E7 SJ#Jh^[लD=t >"B}1DB' rt{ [\3J_Ѡv':ǣٚ,%o2,qsH0K&Ԧ-]`]A+GƗ:;3WO4њLv1lxS TL =2̥M-P!z^x1?a:]1f]2γI<{/7壣w*eYXDKjtM=A}D2lozNHP4SgO6l?X2-Q'Yq&C?ƅ.=|;k̈́I>Hx [|NK>O7/̯z K=ʈY*?e@SOEG֪fqwŇ+[y3*?ir\ ^8.薾!xZmHhP")e%eQ0 {\/+gN;zB*O?`BZy-!.M*g_9JvIi]:9bw>ˀ@nTґvU-ꊠLc2[T#~jItzQ-r۲A{ _JI5˼m ![. I Z-QBؽ4EVXE\ "ZٸˬM.A?^pM~b\L}xQŗԓ2 gOkn-Edh\z>2(yI)g jRO  ; ~*wڼEn.5:?}WR3~eCeaxZqFHͯ+-:ACMk%U|R֤ILq5ƆV5rhABr۶te]V;|b4 `-zTsڵF8,f/:~l>9wͰK/IT.K3%in~+: }|7\`XݼL"˜s\EDNFV ^P9,+lD ^uɀ"n "h}:H@YYC&@7̐=.Q/gH/-^3՚)`,tl3:pRoJtn{Sx~~.CK-㤓, ],\ZU;@Bm(ϔi-a /Ĩ pʋ? q /LXc. T65mQbٿJ_RnAP}߹X>KW>enZ8T ^x1cwlЊMfwua-ZRoEڞu^PZș|%mC?Z@yZty%~p(GY1>^cxtqA{1zYgX 2L6J ,՘?@>)s6A:}H!AM1z&ZuGd FXD,qd5VpPI}mhi;dqr S@󩿉BNJҍe19 $[ LK,V\ &?O"Zd|ߨ]NX'JͳuiD0! ᐪrzb,n]@+6iP"?( L(Б@sz o%ʿULy{M9 S eqYuR p`ϡY e^z*0LɈS9YW$,αy׈<ͷ4ּtzeNLW#$!REETc^; k;3sB s IȬF$~B/Kbz(=J >H;v L9b>Ibֽ~!'c0}ȨJTkAs*s [e?[ q^zF\`w=B1bd~l7t{JM)k% w%qvF_;|*ն*p!| kr'騄D뿸iB Ty57L6YYʦSR2>sU^'wZlM?aO;ҡeR<09]4W&mGxC{ŝ`s z6St#Yn}2`uM!GCZV{e>qw#-R~1"jFR{ x#BFxzKrED_%+R-C0wyLjEBq[:d*'?-+Cj`6/g>G܊b2'>'Ӟ5* طUsphz|5ů2q4c  ߽ ~Xy%l0@jz@V޾pei:p}mYX,"*HI)&SpCBFdLZU;um*ElKF 3}ZU'dxJ/*9o=Mcw?|~լ"`X?ǚ!בz Rm6߬SoU #u&8IJ<ГMwzmwy%#z2LI3pg@[3v=Flm@iⷔdGȶrˁ jȌc9{9G<#3Oqſ T Z56TB\%3ڵoleWsOWz,EkoGd~Ly ַ'vIxj ڊVTrbN3MnQNpqE?yUm70Oc>4s"4ϻ4rL>=:p+4.ygg9ƫ`"ݷfC7p=gN0ąM/0})N2z^pg82.rPX}:|W(\%N@c8O =2ut7}>3 nҐWA5^ԧ@w<zCa ! lS3Gxmꧣ5p鞼%ːL!)(ۇay+ߞpw0ixR"T+-Ke z{Ѝb^~[śORw'ag|L Y~ڜ`M>D͕pr)xJJVv@BnΙW]LSt3{?OîE)SÛnlԳb/ U6o}RIe:.z~5L"EW3nTarMEs*#FIcDV1[jr /AȌ(@} :p= 灩'^rm xqrd]Se>EbD/k}(fw[Xb%M=vJVCV~V- K:l?In[FI*肅Nn[)rXG^W{!ؓyIbxj8/$n(k3^3!q2Np<3zE)9KNKG;Pp쓿_N>(Z|gn5gbD;;ǽoj6&)BlOfbԧ&0"@=U!60xq#c>)1ejZcg+[=z'g&-mf2V!&5;3g29^ݦ[62^/$} d`9㋡9QjOYO#17=F-(!Kj"x$SK 7ZUc4`I喈z;6xlDe]G?j^V%B_?!d-lJSEarRuyPw5גS>+QDBdʦCCӨ<͋-?.f:I^c!k5:b۝--|CwsѮbI8߼{N$q4"x3E`1=f:glԩYe8C:/^‹B12viҕ'Wod6iuHe]v048 9K$T.QsBùHә9 Nz_yi.sEb\*%7^VS &G? 67*;(N(숳P0ګd)Mˌo1%BOǜ `lO 0*wܥ&z2Z(}*DZrD)_ }B os`Ϸ7Va"C֒_ZJ]աPn1q Pc&)<9sїy;S֥=fdP  礦ZKd*@n'&UHoUDԀ `w%\C,̉+z&fIoQuj]~.Cfý#xvQM< Po@(22cΛA*aMY^0Px@Yw˳ %Ӯ\(K*}ó/6D>C{zS@-$I5 TL<475qq#~h]#,b]eE6م⹫A9C.N;gBxX6[p }'AkR{p 0b\kaW]y7E &L]V5Oċ3#U v{ Tx!xtm5bA'N:syX|1^ - ݫڸwo)L'TgVs',#TCc)f H_!Mff`11=Fq 5G|.;9N,GU")u!hHsܝxnC>9dU- ,`η;=:3wù` RqQ1O׹2Mji#ï͡P)-mPlj"q kpf>+`qYdf^D]gnȬbfcDu){LV f4ju:tn=T |BѭΖOldXT#VGzr?z$7r;o|-kV̑c"k xhd}=lu>5}9j +*Hjr 7- I ;s7ޜ B }{AUpR{>zVYP֐Ń ,I)1w4 .](O k 5 [M$6H+j Mp`%+Jp~tT "Q:(v*]}2v5IFzlY-]h0]d,j 5Y%D+voqL[g ^ȘWgZ2 S "δЌg׎_5.|)uʳ_vX&"NL=tAŶs>dl2OXR NIܶT2>JF4ڤ║EW-cIW|^)y28"职G PlU-]fT+kwkϐY*KrcVCW}Ғw`K'c bC8`އW8g ;T< [3̻[Fe@G]b35DMr3[\bZ}ZU8r.D[dǃ #3x;Jc+83ՠ f7%] sLD15+vui&n!)JߔrIGjsWģ`Np[FYT.pDx7)hݰ]jyiKۊp%gbDPJc0<_H4ƙQƃerK鞠 I4{,̓ZAL~=D6hmVfsZw+Ɔv(-Vo,z(uΑ*nM㢝>Z|!*81tW¿U QM̩XBy_r%]_@Uw&߫'0>S~50'ՁZ̤겠= lF]evl 3Q^.N+N޳'ɹpc-79O۷lξXX(xN%ɅA\ ëx#I}Re+_a{;gQ-.z$ӬL݉ۂt>`?6 |UB icc}8X;]W|1) +'4=#ɥ쯜pQK1md˸;D8krΔOAkGج<B@5E <6~3JRVaM%{P6 8Wx/ls$sJ֖%n}<2H4o3(DUw?U+\/YeHg'`Z{/^b8,_rk䖪8'IJq].iѿz',H9f)9P yƓ3<Ҟ8U`JpVkw]Re AD.缩us^j i4[ N=(r70Х,'.|:4+ۊ.tPq&KPk͏S~U5Vr`<$eH x G%Z_3g!.mb'%3ǀ7[~ ؤN)ĝ4@$wGLu)P|aUƛ3ǰ_`=HFi*8AZ>q΄%`J91(4wѫPոOl{`lj<:K{n&(µrD5PuD(0` M6H~{3U~g#B 3|z~I[`‰1J8yʣC~KM_x~F'i }ܞ(~ς Q=)('vE]w.sf8<pC~LM S򄳷ӁvzE NKv{^Iy 1 n|Pi{E%zPq.>B-cU:8 ؐDے%w_1ID?^T0WlL7ŗ?7ܹefy;hhgi1彃Ђ+Dg""T⯤,=6QTߤ#/Gʎf\Q.6K%]oI-gJfFw[-88&Y∥JyEJN|fǰ"W7YXg ;,ϩG!2z!;5Og /Ygt&Ԅ$q%B߆~;&WhF[׋A.*Gr >ʛ)Iݏd<U xu䓖Wuȟ;?vdS!l4*GۢaKR Ȧ;?WN:nH ՝ܑ3{~2! ܞ@͇{I_pp&5(Y%EzY[)}3Dm.uZ2B)1-\fMuʮ^vjԋٲ_n7 ܺ}^t0qٸYkXM  $`ĝl7^B.#RFoSݳ/RR%C!cfq^WGŕh퉫ɋƃ-tR/v)ۿ2,wi߇[7\E#r4 7kXQsoӔ#C iYOC%Ӕ4ji%#=f,xsX& X|ca 3Nz 4@*t:ҾF0XgqQЪ38} 5MsV韒L">ް>vSAڔLĒ"PC&^ii.6*_p$ %+##]ة oLvb 3݃IyF9# iݟE+ƪ ځ {B]>>zJX .c-? A "ybR$[45ce߽kKrO;m {w{H*$g }/Z+1\Q6`užCrB0\>/W%8kEmuf&֔ NW K]z(& p;NM'ALdPE7;K.y;@z=COr{R瘅: aQڛ  IĪ!ShxLe-Wh͌ʐGd..Emп MNHs~m\+gs<7 qY%s2*~snfhÉËB .3jkN@ d{H!e:̥]ZllV]zD)n2(~jl&NtehvX|݆+6cC0*'Q/Vv<}}<-GB{)9=i-&;eSޡYLG1"O*Q+<_ 7ݜw@tՂ2O)Z2ԥ(*r1"\C7oN "B5S L77so ʼn%40 _z=f~! R[D QiX@ e[gtR3HReb=eO-P&|\r.s= '۾[Cޫ//K1َp|']C;^q[o>Tu\Pdo{ j{fOGk(ȊY+9_߼[ ܾM j]j^ I?7‰ 5MS$}IlޞoW$ w_j\//N޵*rr:9f_z>*5_5f7,vcŅp)4N26H? mXdqP+]fJ{ {98ܬ~e{-1wׂnV K3)e*c;*\GHk{_n-zJCqI7:~ě3z4C3Ց 4X:b,៴oG8/l۳Tv_];߁΄(w-Cֿ-.(A}Zc\81]7}hY(>HJzJa 6I[4Yuduyؐ9L)R~A[Ww̟q,-}5kAe"ۈ ܸ{JB ~w9wnFz(_+߾+o3$ 384{QVXe\}S'!"8t?^A!.~6c˓ a?MAXߣVx;_q( g1EK+qpAY(=u,>݊u,TΦx.c9d |%( f&o=鎝 %\A) rc6iG  !IdۣTξHZ+Ht`?P,q1KHSKw :Dk[Jr}S?*kwxJ u"v]24O2|ShGOo`=UCهjA,"%K޿(RSqv"M3\oS1b`F꧆i{[(\=3)&s VjgG\=9͊8uֵL-ǔ:5^3㠇kYYpdoC;Ч[ kӮngZT/7R~Azxe\bJ8&G ìY=˅g; PRV`UʌA9BJϾN=V 5zx%1rp,y%d3U˛G.v;^/}k8جO챑h+]YMQ $c~_EL |1p/Ri$8֙,=HWڲb4}k^4!Šɟö5\fbY42z@K-.;[KZߺn Sh3ŏ͂o9*'@ҋKWzFq,sT84u;5'պ):I: #pۅc/dV?i}뀬 Ҝ~^ ȸro7j}p5 k;>`h {DΙ= ]Ekn)^:ѓBd: %ư"yg1i1 NlVR:g(t3fa.9}A6QpM29&]$AZɘ⑸=Cg5BC?>o} ?|PwkGQ9MI6}FS`ҾJ NPhWKT=a@OAmP{$ʚe~Eя)!5_tT.*Z⸛hRȉ|ۿX7Nel#q3j쥘1?-xP4ϓqT#T;H-_N(c[)F\ /|x)36asUYy@\4|^D!Iɫ(Ž?+Xs']VU$ncmP0pwO,`N<(8=XQˎ~ퟔAB; !nL w1GkAI ·2@j5ޛ<%s13z@b]FX粈5za= %1,_<΍1qɼ/T~U8U9bHCNz5d0MSlB čcy^V+_4­#DS2G^{b$I UnUP`b?o}*#fĚ~~ mk x%\[)O(x4 v+ׇ&n'TUI+ +`vʺ* g݃X .{39_lf%qwKΗ g~<[-h~Jdp딵 FĬv!~^*k'đbs+fׇ O%6fD/w4u8&o/? aOh 0 .4R~Sz2Z-et&]lSsrm._Z:{>pr*pˁ_ J t|\Zr ?'Q8ҹui__h o[)J#J }͗E9(C`3r105'5",7\WV8Ea9Q<VhJ^~.߶D{ErXxx{ƕʧ-͏ +c.f 'j?dN9y,%:\Ej!2K4($PXCRW0uQs"Yc\u[*{UFD<M߳e}'gtOr`ͲO DG(Vv"n`w?b#ՕEoJ;y&b!G@?ZڐLy_I)#$ v8B>x!H`㼈 +CT@e A"alH[Zlc,[Xot-1E'MXOQ>/%Ҡb_`B9^oN޾]t>$`hT x-3ݐ+ɗ_ { cj hkwa0?r00}i&'xGLA!8!jEx|/oApoY~AEn*]H{YX$wSV2X>lfDԖdI5RSo@6}ށڗNoР붬O~~8&Q*^:|UHW~~W\8|fxKbH֊bP@m8'bQoOJny'Wົ3u]Zx JXQ ʾ$hϾjZ#Pi$p4 nb%Й%I?4,V vb6ZD:'zwZ 8A&/+uoS.aL/Us G1rM0ݠ-J8+ ܕߝwz"4 GY9EŽWy@ j2.7~AS n1ĄM;ww/RF#FjSY żHNO:l8v~%ZpO `P ?뭧[SGRH R6)1v;.di;(ϔT6ON!&Y9$`#ǚRA> {NBu B<Ԑ|w·iԲh$謝 S[`_*ڬGc&>}T8rW7Uiw'o~DG:EZ 5jԅP>{ 731USeA-/&O8ڳKzEa8{݄]=X5 Yz{8'GC#6[ٹzLLcy-Vhq"`$sWW/JK@U.y? o('e - YߥK<-dsn0 Pv^@pHP].چ~iMzYa- SK>1[## ȾLLK]?ֻ7+ݸj:y')>3VU[i;H(HL? G݉lR0qwȨǣ?}N-fcT\3XBe/ vaxST@ߊYfOg/rV}˃*Qh 2VM,>Owf%{$ ~NK TŎȹNo'ԀA]6.QGeP=@at+R)@Q%əГ ne Q8L}-<$ÏԿeVe/YF[Fѫe(Mx[,v%Br`+6$Iq󼕷w7я cdpTd(תtbu ^6W5"H ueU[ekI?ioCȦ"JV%?Oެc\%ncM ;b]7c*I2 _jq%FE{䝚A xdy vS66}3nâgҴ_sUٵD_\>.L oBuyHU&y=C{IAy/K/p #^TI%P>+1,TĞ] }O1 ¬)I+Yp~@R=|dQߟj8ot]$/s)+m+Y,c|5!ZLT,Ib2[釪nR3 ,<^Ly8%Fx[9sj&/˃^G0Xi &Y&0ΖC~oD?Ĺ 5 @ߛOLj(<U!2:~hfNzϸL!!ϼpK53-YIq0KS^%R>v3 ?r*1jWĜ"'juZP?]fܛzzGLjW|}SBvwі:aN8 &͞,o.xHyڽw) H_sP Z) OȽrF{]n+yW~oSxi[?;vhx:Gz"+Gady7,z:5ć{B^ywJ1,GVE?GeKf=qr'RxI۟DrA+9P4/ZԽjq`Ќ I>BCIa*+?Da ř2P?Grc,;}|a8rS/%z@J9Lz 컽d6ĹI@ͪS#8g>}\0P?ʇ@\ۡ#J#F'ASlvr|d BuVd^-HLRDmG }A">SUfL5X>%d EA5:i-(Pǟ#Jkg>|bOg=. 9"ZvQzi Ip wAڄPGgdSMe\ dhUDrJZ`]BP4aF0Qi¬Qhksqx2DCf2 kGK梁*UhW=or8wHs5)~zt CG䍈|x70zWRL{:"meP*Yʼn_2ZqU%wP,P3&=k ;RkuքK{HD }QК"Vq!k@OZ t{3kO)w/yu;%ظ֩9pc:SR[b\^Z//)U{5. GRXn%"nze'2qjA_>2:}!;)pLӸe3Q&_>0`g ]nJYn I<+ؒm`'X{ʱi0Eow!lڨLL=nǠQm^!{bryaSщwA'PŒr#"v/yM9&'/FLaL5FoQ܍[(c}c٠.΁|Bu*?,5e.mVp^=-زem'V@JZ(űfgca"txN( (bC0) =nUc_=)Oq/culOnI"y}}| 'Vfk LxqRc _*} a֘jzA,6~[]ǽGʃ0Bfd6l z}eXH_ bY% 6P~'1_C3QWѳoi?Y8 yo0HS2!3/0IWѿ)G7zOd[K0g8SL6ƨq.^TH'lp-~3LǩDhPD,?bc^98)o)'2#4Pcn6$M2xS$/쌞xo>ԯX%m|~Ji)/OHE~ۦa)z"ocTlǑ; VT%25I51-=};wC|5mo2FwίL+;͈>Hu](m+ȸ?i/;^p6w>yn4//KfF ;2x[>F-&# KaayB }TJL'~Ѓ+בG'rA__fTnWOS{m^7_-AG Il> tKeډA 4Y8n5L?Nj`d"OЎV-ӦzMU;/V5(i&m>8w@[ivnG˼7Gm,K1Ir:h55LkD{D~I? Ty&a;,i>\ȫl#G{y_gVuJ8eMwj ئN9`*+/"@uي.6m7Y -5HrJO[ m]E:5 1KGUn3?Xq'WWlTOڲF3ߴfb']N:[-k\D(5-:2X֬. }ʩ-ڠx`#{ Ζ2yrp{_jFfn.1PRr1xPܚcdS`S+Qڛf_v|<^žqjR:o> Aq/J QH>K2Ose~gF9rߑ9g[*`7N#lt]G%`}g;d_^.P˓cTa@8/i C|ga_o@g3kO,rxN ʝ}_֨l Ѽj܄4,lJ5oP>Iy.n-mHeZ|j~˧q1) 'RYN#JmSW Ub[a\#mwڛFDPlIqȕlBf8% ze{M{tR#ըI; &{x)Zu!bODf4vZ4џb wjWgt<9RK`i䂥,o F*DB"m=&pF>,2He`UBUG!姓s} ;b(I4M¨lv"L8$SJ\bK/jPA6*87M|qU3zg-J}Sԕd/?a+f>tq HLgD1/+$#)KhrΫJ6)[r$aJjLL ycZUkd`l*Gy奈"Wy)Ic PfB6yt{l~1bEhZs1uC p͟OoF J 6$-~8ypANA*.KVi;4&+ =X'Uw"#(*%f7+ 6 {^ U|اK4mbr^K 5$7(\t׊meA5iCbn"0-%ehNRK!펜:)9T|me7 - bV@\B^7u9@Js}3/k=D"%V(W+7++G2ru^*P_3~VVѳcӁVnLrTG1t 'Yf+gUbU/`=!FbB1 tg8߁ rvX|Td WX8R :#.aVxGrڞ^(4ZO֢Xnrc~-}eԞ$+w˛eHJ  b+.P^gݾMv~Lyu>J%X+@Nu0reN2k<1]i9Nாa.!4TX)rfJc-,RXFA/i5d!p:W=WpIA,Z/Yy4ve|Tv4Ve{$AKBrP,D _V<#yblb8![q jffÌ!x EYY.QH9զ|=T{A;qߦQ] ʶi᯺ figK0M u|2xw?gP:]T"洸:n}1@ԿTb<~L-PNȷF4Ev멭6Dƭ.0}1Lx*A@t8 &49nVm[L{hmN5d"Zt6!zyM2pacB8`e.#"z}B\k]:JzR0Ǚ;IgX/hkl#w1M_^7kSY}ZdybKC*JD$t7f):sN U.4bȄj`)a4BE6%oK0b&7\^ri%qВqmEr*u]K>HqMir+tK_'vhPn/Sc^SӆA^Q'YxݣL7A= VczgE ]ձ-l5 d޷t+b&G&98uxvmWvrI M%b5'JN=do x!1X3mz~FމqS\, 7:oJbvAf.W>٪:vA10Rƞ91nIf1X\I(Ee]b-iz;, ngo}I;puk]':ԭ-N Bҷn2> ll>[͎ŋJA>ATA."sr]?M:7f5 ѯJM 49V.?ҢoӷRD }s)^mNoGd`~F {[AgV|_؇ юu3G[ u~۬l{X:}0E?K@9(o.26ooE5U-䮇^,QMG~س4ku'Ja9Z!}/zf1r⊕2[z6[D߈{i6}̵P={k?OKNe:5FD$$es>2%gr^ᨊ 8ȍ2Q l(:>A>w2Դ080,TN/KNƳwlw1:WڶEfȅEwVP[sF[)geŋfsCFL%m*ۻu&p"Punز_r5jt;Ђ2_Er~5WdMX3-;~!'h#lZ40ز,r2Ԃ"-0ULh,٤.Rݟd"xk@όhfږdSttVTrKCGcA|]4?dK1_-筚>yR%83JF8cz{9ŷxtw%?z̭2x両}741Y~KVA+wzSy|xJz:LnzmAJY5#%H k8l $#S`c5VW@nౕo%s<8>d?KlF'u4'CӦpT{, XBȣZ!N$ȚJ*s~fF2̠+b~?`dаQZ Iክ͆}~_Ҭ3mOm_S骴NfޘfcT4Q#|W$ZE)Д-.#ܪ}Жkl5%(,1{cis pN ce n3lweWK[w/9 A;48*<l %sn~\\s)rzwJeoÌeI|XDfBl b-znRnq]td_Ө2oQm&J0-3={@'J0F[{镄2+ 4$!Iq}?x6:g(PlO1,eR?Ek̠.'}2-?XkMR yNZC"y~}]LA91]8B 'ޭy f vkҎ\QDw*U(hKˆSP-:Q!1V* Ȝ zG ڥxRu2,-kb}?j@o +ʿi](2yկGR#mhRy{5G7g^^7 $k<Of-AN.YdFŸe^$ |g>7Y'`6E=u opw^<}x-uz^x ZfW%ٞtQjGȺؘ0^DD$[2x6tM̿M\z)bV N1f!!="f`YVD|%%UB?|Xk;";9̬ٓ*݅qbp(#sդ֧Q;nx89jfKو3?gbxlWRg1Od-6OIiy;`+KKޝR#尲y&^q5:۴jm?)]ow9/vwO9Lw٘s>ȏmY,(\MS8ތȘO 8PTtDD) )*/G|Ƙ700@U&"|:h6 Y-Bj,$(s(R{/^(< ʽߑZ7eY E*AIj2Eܿ莟U֫zcI_K< RxingM%j5J}zCT+It+!$!몂?0wT1LBI`A%uhlT~1#-/$aUW5ſX bibDi%(Es!XzS yv[ռe`r<ߐ[D" %j,$I:"4#33u;5J!9Gm!5;ݘ =UF--u͸goRiS&N.*y(yg HLSK՟O c$V D8pFm-siId^%>L{ {߆BY"gbE413||d7hk$^fXZ>ILSj(UL"I<p$=&~tUɤFqQ-9{,+"N~Ė@O B- ;U"#+R46x^>U9$z:v]' pPvyR/P8{ bg',5EɾkfFOeA :"+gTW9x>祄υ ^:/x=ϓto?-S jCd`c jgu(Di6X+-;86(f܄#NH=j"xb1oubA emכsùMG{<Ϋ5h*oMu h}vdwQ wcqi&DBvoXܧ*,pF"P7CMGx?ƍXpoiʗoO'B`_6:`{>OJ-XR?8x{b*FQ;c};p~ R̠6~tj!vNB49p9T.0V1n|m̙3ǿlBq~"fmه +ŐpL{>Ƈ+3{BN?/l7rac#|=?䓷h5WGFUP|X&xBȍxp̈.ا﻾ݓ^>88-Lg:jD3{{Gp2'Ω&.i*tMvii-Wa6 yHz̭*_mYi^*5+Oj%YHUCdnsU@ koOm䘈<|-n RLdgnc?=4Ug_91/\^F"'TA&M\3%ĦŪǿPPXOw7-„3"bӕ-)bޗUÊ|=/bÕS&(muDM|'4vg-4C7{?Ķ\Gw7ߵǔ r$ANh nt.:g/s]"lWp3g OXGۘlXltؙ<^1G> ?t|_J!(3~2zJEFxZ)*2r䥴O}U56=fpG1Z!~.J盐Ucn)bZ0NDp NØGݵåPr2|/V)u/Aoc?!#Sɇ`Q=t-1)0*Tnf`:]q6@è)};ɟ3p>ByӠ^=ҒYИa=)e>7{d`>yEcҠRpZ{YL $}&tn7V8=}ļTݸlp۸Y7f/VոdD=R꣖| kQJUR$1b"0Kwb?w@d*-~TOs>}ܪ6)3nlȳt۶ S64Ըlf,;HQ:A gZ;~ٓlUQ1F҃_-kyB[㴧h3Mo1OjEVmcO'Ф_$ ~|g3mp)1qDbXȧ SӃ ըk\ i Qs( 2nri` ԓ I T ЎTCWDmnrv`cXv7T+\(o8~NtO/n=NUT=gO9+8?_n͒b_"d(F-G=DPh^;ND֕Fpo s͑m:C qrNx\]bE`f'- ܉v+{6 -yon/+o_wNDq`?[ȣ;G>N>ytA9-RL&yeubJ y#٬ ]UZFd ILI/A#.O%.&*~Wl3:xƆzEmǎ3;$`グ~u*V2fu~W&IT:O6>~>$.ցg]ڢd\CL>dTsdk31^lt3<Dx'c `hFvimTO3t)B4I6)}=%JmEͫ4G7?6[7$75Jwp9^Kuv'C{HRRȢ{?9fJ ]q-퇀#y#I?Z?F?XKtX!Y3Z|Ň%Cy lpA:p1S? !<,(ȻP}\H>`h:GL'~CW t*YoSGT Z<&+Y!SË Xۗߣmw,>.WZisˋuWzup@Xޓ::B蝭OvG!n(m9F|`>;x[橸dK]MG3UNè6󡱪hVPgT?Eye74)htD476ry]ms* 0QS/ޟZ1^.dWz%rV?]&ti֓hR)x㩟2Z%̛ ,PmK`y = w_‚^=恵,{: j NKvḰ+澹wr1sJ1cb|rqؽŠ@^ܭ?\kގpa,AlNףJ- 2YAkٞ]͗>lxpeG3TV];;NR:HU jݡe+ `#8ҁ<]O=6\͑#eM{9O0a0LhsMOBp!JFr{UlH~{3PwLD1͂EQy@/fG<#v/؉x x4h>`K&K9Mn㝐2jorfze=C4^a@V( ԈGg<>|_?EacZ}o=JWTN|d%&1ùf̀0Ӕc lAj?IeTwhI[1E0}3S'jqA _tcl恈: sڼ/]g:P)0Isg ZúȸR.W ? rƓu%\`^_m-xveCJܙe?E<}2a(1઎ JฯDK#{=,f:_cXdZ nKB|h;tBBgCg" ~tށW= 6\J` Y!vBݗwnx}%*0B&1@X셥[|"1hq_d;7_9*<,UA s'#L|i>I$Tp#nض nB'Q%Bb\PnEMe3o_M/ranG173^ue}d%zQZQ_|R/d8I^5ƼŒTlЩ!ږ v8:?FE4ޖh8^ˤ*稁oNzZ~Y]+`5O%^c_򃼢\`wLOj!އlOƜއnaJI"ZaDy-g 7^5FŊyI$̎Q^;pd5y,b 9B=BtRm;$ RM)r$2. x[䡥3vqL$ğlٛPKRDdLn68images/img2.pngm{TT]6 C 9CCH)5t CwwI %Rt ҡ ߌ}Z늮Žώ{X= rRfR<<^^#}t} Q1nd3kH]|p8ZsXuPPΟ GC@7B ?t}{d RdlZ-miD\r"Ny֙9=((︷Sq9 [0av]'@5PeW'^mxDp,!6y'byN\Xe7'ˑУmfHBz{0;r. ivRg0Z&5Yr~ozVs{Fͬ;T)t !' eK\!a=OOxX=Q?jdşWWܡ9@%OimlU8Ö/׭W4|0IpN+g"p_Fv}% GŴLVo[sZjWB_c],RȣB_PN(}LZLX<- ~Ut[8<WiQtkٽ Dwf} kc|~*lTJ|Z)J@%J1r !Kb&6+EB=siq/Uo"E S˼!UQw(UwRn6\P4Yl+/z<1cL3vA;跲=C.7˭ $ R.mIeb?~#'d Fvxt/ptZ̲}L~˔jM*vNjۺyO30#@EsvV@ԩ?!f`J+]r ,fV@E]:k8(ei=y&Ь茏p 4q#]8 CL~hf;Lπ@/e7V89_XE(},;HlvU9~q&׀T'ۥxW 7-3')tRi|,#ч#J5pm)Ԯ ADw{1 j(߅ݘ8د"x~ӨF7.tRߖ5=f_fshߗBtRIP Y^d9O/=8~ĚSwmM_tYZ667X'Nҡ%٢U[i?%~GPQVhc .Bmu;R51甑~^XIKoBƷm^ˏŒ nHbd2d nSu\:P=eOpG#QIΚS57ߺdN}QtNv,R߶DCU A,az'!ce %Ҏi135OWO)*-$E;j3t!al.խmOĐubpj%82@.s,-jďSmf?޾lKwY)} O;,jnJGV"jPMA=h} G -gl|"<٘=HƿNJ=`D&`seWR]]RM&_§YOڈYW|(H#!4^r1G4Qy4:d:kjV_8m;ĀsGÖ!bE%'*B"3Juxa  ?mMr"٬DZT$È Uy(,@h l%6 ΰ?)`鸉?h@Us>O^>|[Pm\gʟm2کgz#$bǬwekuRĬ xS|x:9 r~䞲sܴ}۝eW-mY`l&]VDiCG4֭W%&dq9*~WNOS&6'{wj.AdW-XYSbAYcs;z d  }Vy{e_3Ԗ+%MJ@wT!1Yu QEpG*eBEgyhD\O#pǘb5c[N}T'R1x drNcNC8 #üǝN]V_F ưo.XvT < aXA/'ԫ)ФUvW?д,ɿ^I$}$̵?}/yA*E(!ptuТ#7ݻ@/tjuD;ٰtp ^V&<ٗ2(Ԃ ϔddeD:RG_5j>.=MkXq&z!GS(c^,=DP2stukpإ -)5#),pph3{t9Q_HJ{,Ts lW,XB89ԍREFUkεCA ,4|FƴI >J`cϘV@/`H(9Is4DM1 QcMO<.o!:Ky*-B}V!rDuvvqHKlͣ])RD"vwi?n`Z٫CP =.G>XHdt2nCߍГ ?4K4lM9QT<%Xr]"x?c8(p @fՈ_v,ٌ5s8j6k 9U&SXsԑ"#^BqNΦ\6Ȥ>4 07D6o@EW>#M'yk!`m @QPH$X%?D[W򘧦5CB]Jk !.s + Hw}NdOƹ0 iư1 (ݐ^HT!f蒨\qXBA¦/N شtueًdf-)2EZ?okqtZ]#|W9*: s5Hlk0 amJ6H9)ilu9+:I^7IegHI4~t!¹-bG#_Ib~鵊goةi,EM7uVES[M|/o'b&83`׫j2ejY\Fa0:cm!&A]IKjV(E-Ѧ!@=ש8Kvl{\B }< $x#U5\z"CFnjfex{,1KI\ѹUH>S/\?5C"N^"YU:+f?WU$:S/ Xs_8RwDGDz_>"]4Yxѯ'$ t,MFϟ̈: VS4Ow,z\S%Ms`.$ӭۜj+* g7G]7Xadftџߝ9լEyP!)C2EF<( C0=15b#=ˇ]sƀ(IiH'FKcx L9Q9&2+0]sFu;dfcV**-3[ ZP ͤ+{׊JZش7i=yƆ"i,AvY(&ߠCȈ9// =Peuko'KJ *r oR& _5|l"؈3弁c! s(2"n $tS|^'S&L CS⒈)^2|'69W u?G,5:8* ZGFٌ098nˣ#M-z Pv/ޛlWrJ1z!|Oɂd- @O&k00~7#cCE?eۑA scTZ@Q)7q#Gn8$w(1WkM$+\n|SůC]ٴ85 0Ɨ!('S|/IF#YW?BU :-U闌D,7x^r[RʊK5 :nXA^nf rrz!Rn~5˪-`ȌX9s"x7uL}'iEZ,}2jX8_EwD$\_TWxPG~4}vH{A[OD 4}AX20q"ښ:1Uu/m=[{ / LZgjIJ"f'ΛIwDA#8la_*s3Ko A_r``4ͺOU57o"PtK]*a  fٍI O*Ad+ NUy6yj:Sԕ6V2_z}.BV2+XxbzJf }Fz:ng8&HKQ)qSe3gD^1ڮ`Bnn:>0BQyGñ?!]\% Z..ă%}$^ƤW9-D?Tԁx q/>P2MkMu2R䉓5NWQ_+*uiZ|9RuO~tc%O(9Yro3|3vǟgP 4(wMX': B愁 x52_eSVZ1gSWEwƾ5̅dU:>yTjd*?mF>؝-~׏+Z*"@qTc-E&_% SZ' QD Y!ҫꙦ-iD‰YʄDJ9ʭl.7BMx&pwDI0|qU%ny|Zj }Y]ѐy/W} Fȝ$r5m5yN㭔lwh)7yġ $:#廩RTJ]C+f.ic`A5F+)EgzpRtK @l~( $ܓa~pS'~D:RG^1_5R+nX5~;>XN"ݱʥ>b Uzj5 بf?W"Jn-(} #J ]$v&V܆IIӼ= PUNF86Kߥv?SPa5RH ew0a8jh[D ^o:dTI dYQf!H! +q:#kfNtƵO,fUjߊѽHճ'ϐiۃᰱ^3~ޫdU:͔i%VP]ݣ$ɂl> jpD/Bo"IM iL7G8NC-&M>/r5gbGS\kKN\)ޑKmPp%H !C6$XkY^WTD.*j51^$EWXhdjei%&1ȀgI>01E8gn[7k>#tk9 U&﹠0KR?XSY誊W;DjWgU{LE&_Q+ێ'$  IR3Xr8&dO}oFV1xSG2t'a]4FSmWɏZ&kNՙ#w֔ZD'{1f8&5s 2ukӅۮ!Ľa}S4Fup[kj E=0fխRwY|nGagnc/w<D^(#V}܆- hxSf,ه^c.) Xܪ~6-kvZt;iF?^EGF 5Fe?jeLv\)>p;ušbm B?)DMUG9RaTm?t (&48;b(I+nn Bʩ H>H<-)~k;[cSܮ6UU[M*aN>0P[:}V!6'xbn#4D!]RҠB*[a^poλ40$gtG0#sO0{yކ,gS>QVDUjeٍ tw3` K=f3ִ21 /_xDBa7)z'=fvl_A++Z)$#R-UI[nk/8gq^~qW[$>D2+#m>KFmib]o-)T \ʲ P$;? s;j' j- HoIZc 73kn T_E_nߙ˝Rwz4 jFݮuh:A# թg~jo.W}sӫf I}ۅL(ҩ{_z8*q8by 'qWVԩqZ@ 1d|+ι6q\g]IiPH*+B!s?E$|\(TỸpeN8 %+}9C׏ dwb돕^℅wgrSB͂Iו!Đ &Y8t| բN1x&x_jhdDVN )_`]FIäT \8ʤEKqB^}c5[;{^蟐m,=cp j PϢ"~tR-@skyrį7J% PhusRaLq'+iܪ<ۡrw l=\o)SI%Jm^2kP+6_ĥJY߃޻k춯ӴTyB"X4>Q{gk fG[orK0tp5[O}d$.EyPJ͛bR4ҝ bIg< b&3 S SA=7y8hO"\Zw5 )+ln {" ًG\-͞Ovrup8"B5: *L{V4c7XFɼY]],^WC^ߵES"Z'a%)#]ndJhi]PKH6x[G)!lزYTo crՇitl6A2n^33E)82b1Nj̕;L]ޯ2N >q_$~QK,] ~B-iVv>|GlgmYT5^Yp4c X0xJ@Qȩ*wq- :4:q K/y;bxJI3~1 l47֋9'q"uizxj;*;fոo7bh0}i~mu#h1a4{(qe湲4r".q4"YkUW ;﫚p.!iMϷO|:__).RQF4n]GIвү+'1Mld-X%Ls]Gn: ܯv  ~Q4XMS.2mxy߀{dnOD|bRw$u":͸/Z̚RadsW|Z^dF.BCt1:L'`XEm)> "x4U(X] s_ WGUrK}.;btȵA]#D_PjS&=p=dE[v^W$$ڏcih[XeƤƕG4[sg.9/p+',S+. џ4/S%k?|·:}A=&>g8lL.REy< vHzoe.lC:epVv+mw~I4LQ%%yk 8gNJ5L==" SS>N_SZƔ!&ݰV5#"I?$j99%,01Tk+z/*]"YaDuԉ:-! L/r[#XerCf2P;~廉Pp 5щEF1}Wf8n(3 uƀ.z0+UrgVZ-DQ'XjP˞jN} \Ո~D/e_^Ť@GE%m Rq: v>yo?C*3Xt' O'uwtȩL$]! 3EL]&dJlK&ZW-A#A" xkʗ [7DZ[ kA \ҜAqUUr8<؈\{ow˿iʃ w.VG٣L|o]067΀7;6vt;UO̽iZ]Ɇ/-"v i't[IvYSV`׎ ƺ_o@Mujɕ͉ 1"yN㸋Ş6G*TSvg)"[rw}qS{4KT`E킀 e֕V&T>Xco_r͹IP?=t9nZl?PKRD1Lw  nav.xhtmlXn6W kdY&m mEmI_sk<=iVn)y)M*,[PEO&$^73EYht&wg%5鄓r_Yᴁou=v umŹKmj~8*3ԛfS3]nb+ 7H 6y=i`%V6FK($:`Rap:|?:@ljAr; .YjQz(^r@+O +x Vh-%S{[šCBA8)ۍrofڨZ^ƴD15W%WG~ s-EHj3 OBIqRpKW_8pq @]v_gdh,*DC*rF%WW{62 ca/<\%&?C kP f%$S;p3Zf R?XQa4z @_-yG~HH 6BdN8hD_fDA%3b+%rLc~:H"gR.Qbaih| .MڞjhP&*)ȹh.nf;|ǬMvppR"eE-pd'>NȈA IJjF |EY++RH| g[01 ㄊI\֎16dҕɂILy(B>`֕jv+XX%Z{&]I>G4ڲP'Y,ſ<5zXHpU:gQm4ٶ72UJVpa x.twXv &u*BܙT7+yk#%`##nx-BSS1d6t>o*a grnd)4kO3ښOPKRDGn6stylesheet.cssu1n0 EwKv`]#P,f+FDUܽY4 ~"8(`(cu^#:2!``B7R[Okԑ١~`gI)1VkA6Q,c |@ϧKėvha:.9 c)Uix=iSTO}-iQ[vPKRD#"pititle_page.xhtmlu?O0 &5W C\^K(ۓHd=,緧4ى\`5D4MtWpeUU| ۠#9t_;YފkvbD fWLfg$@9Khfi M '_J8e2!?(xn"$.i*i0 ju1Q=+B2apɂ ,aDOnj$UpiAM n.:(O3:Ҍ^Fd G0 13^ި/2,cOR5v.f\1 `'Jɹ𵹽_pr,5Je9 &-;%!"ߛ͇t: R S [&o ʜ=(9]DQQC0 ؒ|T;D/yE( E9D%MrXhh*?#'WxGFL%9mqťBZ\º3bm|sxl ==%TB_́^:,/5.sBN^i4'Lʙ Z0 `Ԃ}SwL̕|M>ʹx_kൿrߡa>"KBu˥J@ZBtp*F<z8'A!Asi$j0Ku93dfV/a3 (WF20F-m(E[SGɈ*" CyF- y/dD]NeKD0huRp6AīmmphC^L>״ĞVwA5׸˧5Ok k$+K<0`E&*R_f`6e01(Mn1dj%4-) JHsR-jի[6Aa"8EpjM-4N\+xZ/CXvȯ3umLy %Uf1.Pe1:5xIఆMX•.) ~ǀZ;|6->6[ \ch005.xhtmlPKRDuG  ch006.xhtmlPKRDTཀྵ  ch007.xhtmlPKRDRU ( %ch008.xhtmlPKRDw *ch009.xhtmlPKRDNe 1ch010.xhtmlPKRD/{j 7ch011.xhtmlPKRDn} 3@ch012.xhtmlPKRD7  Ech013.xhtmlPKRD!; Kcontent.opfPK RDANimages/PKRDێ 5a;c:Nimages/img0.pngPKRDsBL|Rimages/img3.pngPKRD{images/img1.pngPKRDdLn68~images/img2.pngPKRD1Lw  nav.xhtmlPKRDGn6stylesheet.cssPKRD#"pititle_page.xhtmlPKRDu+toc.ncxPK9CMET -o|untitled-book.mobi| V2.9 Mac 1 Info(prcgen):I1047: Added metadata dc:Title "The Twelve-Factor App" Info(prcgen):I1047: Added metadata dc:Date "2014-02-18T21:15:22Z" Info(prcgen):I1047: Added metadata dc:Creator "Heroku" Info(prcgen):I1047: Added metadata dc:Rights "Copyright © 2014 Heroku" Info(prcgen):I1002: Parsing files 0000015 Info(prcgen):I1016: Building enhanced PRC file Info(prcgen):I1015: Building PRC file Info(prcgen):I1006: Resolving hyperlinks Warning(prcgen):W14001: Hyperlink not resolved: dependencies Warning(prcgen):W14001: Hyperlink not resolved: codebase Warning(prcgen):W14001: Hyperlink not resolved: backing-services Warning(prcgen):W14001: Hyperlink not resolved: config Warning(prcgen):W14001: Hyperlink not resolved: processes Warning(prcgen):W14001: Hyperlink not resolved: concurrency Warning(prcgen):W14001: Hyperlink not resolved: build-release-run Warning(prcgen):W14001: Hyperlink not resolved: logs Warning(prcgen):W14001: Hyperlink not resolved: code Warning(prcgen):W14002: Some hyperlinks could not be resolved. Info(prcgen):I1008: Resolving start reading location Warning(prcgen):W14016: Cover not specified Info(pagemap):I8000: No Page map found in the book Info(prcgen):I1045: Computing UNICODE ranges used in the book Info(prcgen):I1046: Found UNICODE range: Basic Latin [20..7E] Info(prcgen):I1017: Building PRC file, record count: 0000010 Info(prcgen):I1039: Final stats - text compressed to (in % of original size): 51.79% Info(prcgen):I1040: The document identifier is: "The_Twelve-Factor_App" Info(prcgen):I1041: The file format version is V6 Info(prcgen):I1031: Saving PRC file Info(prcgen):I1033: PRC built with WARNINGS! Info(prcgen):I1007: Resolving mediaidlinks Info(prcgen):I1011: Writing mediaidlinks Info(prcgen):I1009: Resolving guide items Info(prcgen):I1017: Building PRC file, record count: 0000014 Info(prcgen):I1039: Final stats - text compressed to (in % of original size): 50.36% Info(prcgen):I1041: The file format version is V8 Info(prcgen):I1032: PRC built successfully Info(prcgen):I15000: Approximate Standard Mobi Deliverable file size : 0000129KB Info(prcgen):I15001: Approximate KF8 Deliverable file size : 0000138KB deato s ma@MC0BOUNDARYίMOBI-0H PEXTH0t j2014-02-18T21:15:22ZdHerokum Copyright © 2014 Heroku 2AFB en horizontal-lrkindle:embed:0005 ,,  0730-890adc2 } The Twelve-Factor App<1mlns="http://www.w3.org/1999/xQ"+:epubWPidpfb2007/ops"ead> Thewelve-FacxppI.odebase'GwwZBw'3?C7`MDG7E">Onerackednvisionjrol,anyeploys?7ߑ&lio$W7__-4^xFߘ4GǘH(0Dependencie?gǟǤIǞw5J?GGϠG`GIKߢL">Explic(1pre solateшǡ77wא/WT6VMשwww5wwNO2nfigG?g߰zPGװ7׵_QW'RgWS">S1ɡtenvironmentGoooo'ǹ8ơMTG6ZU/VV.ªingervic??J0Ͽ_Y9_1wp2WL3">TreatsttachHresourϿǾ/ϲ77-1<8%47Z5wgh6">!uild,le Hun'߾DzDzǑ:7ߺoxϓ8w纗A_9Ͽ׺Aricseparabhtaggg粧׳׻125B߻߻߻8߲jCxDProsϿ纯/EwW?ǣFGgggQ'G"> ^Executeheppsneroretatelessroc@es/alioMol7Pli 9toc-li-14"alue="7"I"G aref="kindle:pos:fid:0009:offI?J?WWPK">VII.ortingOW/ Scalxut1Ldelowoooooon`l9nK0ooooiBoo:1H2">IX.isabilitWoo3_w'"ho4'GGߩGo5ﲷD6">Maximizeobustn withas tartu`ndracefulhutdown/2pEK7C8?WW9">ev/@darO7A/LJʲ]Bǿ?3CD">Keepevelopment,Ag@,JuctioslarYsible_?κ` KE߼DFO?צGȴLogs/ϳϩ HﻇBгϪI002G/J߿Ǯ\K">TreatnɀmO7߳߾4WKLwEM׼oNQXAdmin5eϳϹOﻇ5ϻPȾ(Q߿ǿ R">Ru8 /manageIask2one-Ｗ׿?ooooOO<1mlnhttp://www.w3.org/1999/xQ"+:epubWPidpfb2007/ops"eadjmetaharset="utf-8"/namgenerator"ont="dPctitle>Thewelve-Facxpp I.odebaseone-tracked-in-revisЃntrol-many-deployel3M334">One nhr,  3>Awelve-facxppslwaysnerolystem,uchs Git,mercurial.selenic7">M%σsubd.apache.orgHM8">S&Q.@pyfhe*ingataknow0 posiy.Theșa to-8ra beYv:ulwHpliIPZQpmultips,t's a--@istribut3.řHqp(ntGE#1,eividually:8withliWAJsAshioAǂ oluMHĔddnlibrHei,bclud!hrougxX_MK">endencyrr3/ulLȊ8lpe, will_@MunninstanceThX9ypicaroduC e; moȂ@gsddi, rHoh2ߗiromenvirona؎SalsoPifBcNacrosQɾRlthdiffhHsy 8iv!ƺexaso:Qys;_.‘4,uI@xt@absǓ/seW> II.ĞUexplicHy0re-X-ihate׃׃38334">EƼP¸ļ/h3 first-para _-after-h285ostgralanguPQack#fZupport,Qsߖ.c *86">CPANPerlrubygems#7">R܂&.̶N"llFe-wX (knows "ܒ)s@ dir8oaiJ%_"v o")"buq)T8o9">Aoj!nYѾQؕ90ػZo#>ɫ9N6,xte(c0,iaкޝAg`Ca)[ifest@urQ, pusGBohK^tooPuyecX ensuat ߸hakh"rom theurroundingystem.Ԁfullndxplicitependencypecificationsp(edniformlyoothroducBqdevelopment.

    Forample, Gem€ 8ubyffers aaestma:yclarقF">ec'isol.n,ythPrЀ twoep9hoolsZXshteps --߈www.pip-instalorg/en/`g28G">Pip"us;virtualenv+H">V>Vvenas7.gnus/autoconfO28I">A6Ǎoؕpticink canvi8.o(tterh)chaipg̎ualwaysetoge!onone 0x(notxfissfhwelve-factorǙJ">Oxbenef@oftsih`estup2newaY(〡checkup's ibaon iΟhchin@requir ڤlanguageuntimHd xpr(Xsi2yi80abet (0rЧneedaaؐminisq. OHA//!rLv,,Х Clojure/WPsYub:technocy/le ngen#readme8M">LN">!as?Tlsoo*reexfȳ(r#sclu8shelomMagiIrgP">cur%.׊"3may#ѰHд`imosjXz ranteQsNhݢ)TpAfutP,@b@s!f!T px9IfYPaWoliȋouȦ dori\b/seW> <1mlnsw321999/xQ"+:epub߶idpf2007/ops"> III.óigsxe-in-x-ironO3OQ3 34">Sagt3first-ph _-af-hWIQ5Ή6LskaXvaryxPX_Q7">loyة(g,odu2,߇ntetc)@s:Jul'8li9">Resourhldata,emcXed,2oo!AhacgHrviceZC8iȺɗernapucsmazhS3T`C">P plucanonich2b3/utDso@ЄOg(]э]iolصВ߼b0requiriceq=Dfrom@Ҵأi2b@acrosshdoWFtmueЉalcorr믠ɈԷٵsItmanڸؾmntis1cgG">NotNdefini"rGH">6%l𫂫;,<:VI/res.rbSpring.hisypefonfigoesotaryetweeneploys,ndo bestpnenhede.

    ApherpproachomusgilwhiXarejcheckedXrevisiontrol,uas /database.ymlRailsDXaugmHvement @r stant燠o.po,uttillweaknesses:t'sasyYmikenly3yagle;Qjtendencyorbecattpdboh@diffplacPHmat8makitrdseȏmana aKn Q.ur,؂langu@- framework-specific?N">Tlve-fact8(or(envi` 8iab     (ofhor@ؕG`QB9ۆQOhRJ).Łdch@e73ithan;nlikZ:littcm(_ZcciPty;=u`mσrhme9ismsFJavaystPropertiLyaOS-agnoxc(gSgaQ𥾔group8.ometimQppatPndsch"Gts")\ar Uפ%YGT">develop,wU">tYV"> ductEwئholea:m`Α*reated,ew?Sne0sX//R0">9͙IO!1">qa.pj)hws梥TeXmapdheiwx aly߄2">jP-ߌult;mbinaЂx0ҹCY@xr 7$3">Igd,granularѼefuЪXgoninXrg ,"ieaptpSd2adeAasmoxlur!IYif3/sPxW> <1mlns="http://www.w3.org/1999/xQ"+:epubWPidpfb2007/opsh> <Hset="utf-8"/ף="g(rI"="Qocdti>IV.acServi(TP+͠1ˉ3!first-para؀]--h3C5X <6">    BLsuynetworkinorm!a.xampainclu data@ (.a|.mysql./C7">MySQLC DB),pi/queueym_.rabbitmqc9">RMQߟQkr.githubbشlkd73CA">B΅\SMTP1outbouem oopostfixB">Pӈ1c W77memaedGC0RDʿbasпtradi5bysЍadminist'sun!dôxloly-]},lsoavmprovidpirdie_\wwmarkȘE trics-ganew(icwF">NewҀᛗ_logglygG">Lʛk binaryssetervices (such A3),ndvenPI-acsibleonsumerdev.twitterCI">TӃy,wtcode.googlezapis/maps/index.htmlCJ">Gj́ or'$www.last.fCK">Lˇ.

    oe,otrpttachedesour荨BviaURL9q/credentials@inX_CN">fig.ׂ?߂?O">deployfshouldqtowaputMySQLatabase hne`nagbrds3CPRDSbZnyhang'sj.ikewise0,SMTP*cp-+PostmarkOT.ɓcponlyʒ d eed:Q">EPackiPisR,hi8heio`؅`(Ho$Timrc="H:embed:0002?mime=im/jpglt="Arodul'our"/> U">R=!YdeCtlliۙsisbehavdu `wyissu_adminrgh8pXuw̪HfrohcHzupcurrOƇe+уw--0l (/seW> V.uilreleHunOictly-sepĬ0-stel3U3934">Sh Z"P3!firsta _-after-hJU5W6">鼙nsminz(non-dopm)roughAeЈ:Rul7 liO8">A9">~xp9repoDn`ecupbuknown1gjALUs Pso{JammiYecifib+c oeetxverȍߎ/B">enciፘApiinarЮetliQCD>akkˇKȉ`yEgogEanfigQ˾0ultْoPFfKaino;ry(rm(iyˤZnJenviron_GgNHXS(alsog"t(")AЃ,launchYsomtUˡ/7ס/I">䓝gqsct̓l/uJimrcembed3im/jpg0lCbeș٩,,8Td;pcaUK">߶(UL">Thewelve-factorppses picteparationeXenbuild,elease,ndunages.Ƃexampl0itsmpossibloakehancodettimsincPherenoaypropagatosObackubӄp>Deploymentxol(ypicallyffer-PnO,osthtabhabilitroll>aHevious.׈ъCFᎨorXnsubdireyamed <UP">,jrurrEymlin&'c.tsQ)mdzt quick`חR">Eveshou@alsavniqueID`uch!ᗈmpHU(%GS">2011-04-06-20:32:17) ncr2ihnumbϞT">v100.ҎaPhxend-onpledgxYacanut@dYSH.ny$8˖newU">B9kiniti bdpp'svelopersnprh!Rkpecu,Qconst,Qutom3(crserIrebooاhash࢘cese xtarsr. 36kep鑱fmovȗؒP}Emxh(ѤsromYnca٪hbk!midd night"RH⡸0xuerroĈagrou&oriQ/s0XW> <1mlnsK@www.w3.org/1999/xQ"+:epubWPidpfb2007/opshead> VI.Вk)ʹ="styleet"kin:flow:0001?m=text/css"Ϻe-8--ase-or-!-0txssY3G334 Aѕ53first-a _-after-h4G5">id.nviron"w/em>7">IsiQA0xt@-alscripj.loaptopit`@lngu@,ϻ auncavi0󿘷exߔ88ythmy_.pyOox(sprumducophis9amay `y sI-D>dazneehxuH(s "tefulOD">bacXgRice)ypb?EmeyafiPystM$0briefjglPransca.Ɨ,ownloadar؃i, atY8Y9result&tﺹn0ssum(Pb[TXiskllavailablfuɴqujob --;*ep,nhig߂ۄ biffer9.venh(on译y0tart (triggonfigr//,ȩ' hysa)usu wXuX(e.g.,ͪ)۰Ars (suȠdoc@ntcloud.gub./jammit/"id="7K4GG">Jamr  )seheilesystemsac(pds.welve-factappersooisingur99vX_GI">buildt,uchY'ryanbigg guides/_pipee.htmlGJ">RailЊ1 =[rar8antuntime.

    Someeb [selyn74en.wikhdia.org/q/Load_balanc_%28ut(%29#PinceGL">"stickyessions"--ts,zYxr=atanemor8fRx'socpndxpec)uturequestsromsavisi(b(out.ӅႨaolatфY'!8shou nevhd iuponІPtedndia sof#-ip__[:d/GM">MGG"s.io4GN0/sonW> VII.ortiPngP(vi-via3233W4">Ejka 3 first-parah]-after-h_L25">WssHecins8`iar.Ƶexample,HP[migh moduleU73id.axhe+6">ATTPD{PJava_[/(tot(7">T?48stro9 "dono𱔳4jrȪ܌envimQcre)2ia. Q񆏙DA">[s"yyn,l:vp!ڛaG,B">IHocalopt,ʀ7eRL8kcoYC">$host:5/    cʇӶ0i. HdeployaIlayPhXϹɝxublicaSouQesD8PPipiYus X_o2E">0endency)ddolibrarPX77gnadop_FiJPyth{A.macourno./thinL2GZ˂iRubyjettydehausWL2H">J9ޤxoȤVM-baslanguagȠhen(u8e    ȥionڠ㞲can♟ng.earany ѦѲ4softw$yЗ߅awaiin4Ŵ[ncluoejabberd.imgL2KHԗb(speaWxmWL">XMPP)˷GCredis.ioL2M">RY?tos/tocolw2NtrO">Noilsl0roeaخ on򏜷`?ף?P">bacfign suڰz/sW> <1mlns="http://www.w3.org/1999/xhtml"):epubWPidpfb2007/ops"> VIII.oncurrency scale-out-via-the-process-modeel3K33O4">Sa ` ` ` d b3>

    Any8mpu肩gram, eun,s@pres@edyPrr6es.ebppsaveakenarietf-execu:formFpexample,HPsildoqApachstarɎdem8needkrequesolume.ava:zoppositero,ithZJVMyvidingm@i0uberMthatservaargelocksystem our0 (CPU meXy)jupynagirnallyTrInoah,n(es)፠onminimQtwelve-fac,4itizen>И~iCcrom .idapns.sth Ôhrtito()es ge 1a B">wpeTdonotXcludPnidual?ÈۉowultiPx`,'insitMXr3sync/а: oolsupprubymineKD">EM,twidmatrixtracO5KEH+  njs.org5KF">N.jB8Ћ@bҎHwo(tiP z)CqBmualalspuO€hys*UG1 tru@shi0omɎ1out. X_KH">sh-horizontJponnatu1Ϧ<ΡanadHepai9breli arr8ϱȻnu(𽀡ߵkn!pHIxJWKgcdin.githubrH0/02/28-.htmlKKoulrʴ8wrIDlnad,Pۊ4ym'manr (oiupst.ubhKL">U {ahibu/+ aoulatQʥiokblog.dadolhj05/06/roducAPe7M">@єm0)93O_N">ppPeam spoYorasheu-inashutdȲ/sXW> <mlnswww.w31999/x;*:epubWPidpf407/ops"> d="maximize-robustness-with-fast-startup-and-graceful-shutdown"lass="level3"id="AFM63">MD G A A D @ E EThewelve ctorpp's procesre disposable,eanitheyane#ed stoppXatomentnotice.hiscilitatea`eHcal ,apideployYfooo9">cod(@?A)nfigzchanges,ڔ'!ductionspQNB">Pould`rivo C">minCtim.deallyakpewedromJlaunchomm1execuuntilrtreadyirecerequestrobs.horvidmoxagy`W_WD">releas\;ii0,causcՈPagerRilyYnphysichiPhenarranЏQ Y肪ʋahttp://en.wiki ia.org/q/SIGTERMO6G">signH6.ƣeb5,ǫ!Qd@oistؘД!servA(rex`uany)hllowcurr֙f8sh(nhitmplici1mlthHTTP'inok0noi(zeh lpolli5eamlhpattempt,onnect61plost7|H">orkx_turUN ueexaenwww.rabbitmq.@/6I">RMQ2seȖ?amqp-0-9-1-quick.html#bc.nack?6J8K">NACK;Wkr.gub:bhlkdM6L">Bιя3ᶰ˸pDutoma0 @Lock-syxmua_zswllvea/ayed_X#ame6M">DobneuyѪiirck͑Irdǚǚǚz}Reh_%28subroue%296ND3whi@typ<72wrappresul``a asamakoperWWW/0mpocM6O">˅j PpSalszQ aiddthn,ߤۥail饤underlyhardpWhilqXAᥑmmoc˭Ȩw0 'BR;t3ti0hrmmزro9BbP,N!s[b#sOttimut.Šway welve-fypprtpd@unexp,on-ntermin⟠GClwn.net/Arx/191059M6S">Crash-on`de٫ak(8ceiϭdocsdben/lat`/io/o0viewb6T">logylo/ɀW> Pkeep!elopt-g`-(-u-as-similarYpossiblȄel3O33O4">KXH^cnlonsimilarYpossibleHistorically,hereaveeenubstantialapstwdevelopment (a}erakingieditsoo deployf1pp)ndroductionIrunnopccessedyusers).hesemanifestnPre0reas:

    im(>xyork codhatakesays, xk8or nonthgo@.F\welve-faciIsignfhttp://www.avc.com/a_vc/2011/02/c0(ous-ۚI.htmlOG">G:0keepaysm@8]LooziJcribabove'H'bI">MC:ƞithoujumtla0O^Jׄ':hoocloselnvo(dqYwatchQ8ih'.KϘՎ!olexL">SummarizōCa`sOMHraX8ȁ;NX7[OxYsoP">W/SQPR">C:uthovs;\S">Diff8peop񇏷T8a6OUevIױviy,VvergڊP0">AL1O2">B0vi(9,chl'as`queueystemc;on˪8Y/)tsmportaanynguagoٿbr0 8plify,!bυɃncludadapȒem>d.typʈ.oexa@plowh8headp8lasser8ttyle="text-alp:eft;L_[yA/tr)QaggbPyn/Dj`o7CeleJ//xabbitMQ,eanstalkd,ediooǓCaWWWooSSup::'Ϙ''Memory,i`|z씳/P4stXs8appe輰usa ghX1OtiHocts, a eiou robusomwillpedojƸhD,ԕ{lw;mr欌9جR߳5stȉ6xQ resistuaЫ|7Ltwe1ocalervicesrhesshllqth`ynce@.onacksuchsemcached,ЉSQL,RabbitMQjnoifficultostall ruanksmpagystems,HʂG@sHhelp.ubuntuJmunity/AptGet/HowtoP9">apt-get.ltxv, clarzrovisbool/www.opsc;hefg6PA">CGdocs.puppetlabs_PB">PJbinw-virtuenPona׌/+vagrapSC">Vllowoper _Xwhi0closAproximhdutsWQQ9us3esxIq1XorbenefizH/qrH7tD">Ad$ءowtipuseful,ca`{makorHewrelin.utdse ((t,'n)hould7aHtyp(e]ϣӥC/seW> <1mlnsǘw3.org/1999/xQ"+:epubidpfb2007/"ead> xat-as-nt-sm3A334">TAg08AB83)first-a _-af-h7NA5em6em>dehsibil!inFhavior9.nrXbas' 2! on(wхqlnsk (a "8");✘th؁Ҿ@outpPforWɛ{Xᕸmpo"o9manY̺Ih,󎷎ۄʞ,nbu’Ao .urloٔ0еwqviPjKIegȿ8minbڸe'sN/$C">Q 'ecaptubyexecXdžygeozś0,ڐʘjqdes*y-ɦ`chival.hesZ[figura,imPtex?.pen-sourcRKrs (su _sgub:xAD򀩧jyGEfluȀF⩡)zavailBY:purposeFPqmxc߲,watchvieamЃЪS.osignifntly;t$s‹!index (lysym Ǵwww.splunkAG">SʲɅaenl-ataresw7Pe.ap@e.orgGNAH">Hadoop/H(i0lQ(powf8ibilityorntrospectingnpp'sehavioverime,Xclud8:

    Fina ificventsheast.Large-scaleraphofrends (suchsequespminute)L">Ave r3ccortoser-definedeuristicGhequant error'texceeHaダareshold/ul(sonW> ?run3managem-tasks-as-one-off 3S3Y34">Ru!/ ☉03>T masarraґ>ateaddo[Zregularus h8geb~)it 8s.etely,opsillpXsh "80m8ance$, ǔ7Ǖ8"nYdatabaseا0Ie.g. S.pyyncdbrakeb:eailsgBo (alsonow覹Ƥen.wikipedia€q/R0-evalh(_loopSCpEPLҠhll)ibiry@" lgsl.olu rovi yBirprePthounrgu׌ףDXyp駱E">erl)kome<mdWW7SF">irRubȑ:G߽Hץ!cripitt0߼po7SI0hp/fix_bad_res.YfJ">OxXuldez༘calnvironڽ𽁢7K">long-H\. ”ƙg'o'KLele,UsϬϭoϸM">ɬbW!N1nfigCș@i4mushipZ)lȽ2ʰavoidbhXiziss(WSOs׵϶^P">depen cy@oltechniٓǵCxa0mtypƱpexample,1"ͷ@k}Q">bueXectart,Qp/.XORe>.ikeaЦY mDVirtualHov or :Sin/o-boPTornaservqaTy}OJWtUPwelve-factly擐rshiB 韴box0x{mit yui)d.ɍloYlodevelopeinvoߧ۵i8q checkI{oryXducchsshٌremoumanism ؟ن`w߾`ksu8/shxW> /*isfin!tylYclaok */ bodyrgin: 5%;xt-aligjXify;`nt-size:dium; j{familyonospace h1:eft2πρ3Y4__!5''6.tit{R.au rs3.} ol.tocadding: 0;argin-left: 1em;Mli`list-style-type:onew INDXTAGX  0000049879IDXTINDX 0000000318 00000006306 0000007928 0000008382 0000011177˄ 0000014736߅ 0000019002󆆀 0000022846 0000026612 0000030064 0000033064Ê 0000036739׋ 0000040687댌, 0000046764 0000049879IDXT+=PcvP-//*[@aid='0']P-//*[@aid='UGI0']P-//*[@aid='1T140']P-//*[@aid='2RHM0']P-//*[@aid='3Q280']P-//*[@aid='4OIQ0']P-//*[@aid='5N3C0']P-//*[@aid='6LJU0']P-//*[@aid='7K4G0']P-//*[@aid='8IL20']P-//*[@aid='9H5K0']P-//*[@aid='AFM60']P-//*[@aid='BE6O0']P-//*[@aid='CCNA0']P-//*[@aid='DB7S0']INDXTAGX SKEL0000000014IDXTINDXXSKEL0000000000 ̀SKEL0000000001 SKEL0000000002 ;;SKEL0000000003 ??SKEL0000000004 TTSKEL0000000005 ppSKEL0000000006 SKEL0000000007 //SKEL0000000008 MMSKEL0000000009 hhSKEL0000000010 SKEL0000000011 SKEL0000000012 ;;SKEL0000000013 jjSKEL0000000014 IDXT &@Zv:INDXTAGXtocIDXTINDXtocIDXTThe Twelve-Factor AppINDXTAGX0 @18IDXTINDXD00=_ɀ01A떁02W碁03r!04052ԁ06O끀07j08090A=/0Bm0Cˁ0DB0EX0Fs Â10や11312P13kꂇ141516>.炊17m18ĂIDXT ,<M^o$3The Twelve-Factor AppI. CodebaseII. DependenciesIII. ConfigIV. Backing ServicesV. Build, release, runVI. ProcessesVII. Port bindingVIII. ConcurrencyIX. DisposabilityX. Dev/prod parityXI. LogsXII. Admin processesOne codebase tracked in revision control, many deploysExplicitly declare and isolate dependenciesStore config in the environmentTreat backing services as attached resourcesStrictly separate build and run stagesExecute the app as one or more stateless processesExport services via port bindingScale out via the process modelMaximize robustness with fast startup and graceful shutdownKeep development, staging, and production as similar as possibleTreat logs as event streamsRun admin/management tasks as one-off processesFDST ίίfFLISAFCISί((DATP )S4@KVCbn\zQgNRsn-.B?C@C@CnHzl{p{{T`{ -{l{q{pN{$ f```lx~ public/images/release.png0000644000175000056700000003436715226251677014206 0ustar0000000000000000PNG  IHDR0:_ pHYs   IDATxن!Ql "n,hT0Xc%]"+HDb/QŨbDl؈]Ał v`9wʖ置̽gwߝm/ @*MuYMLLL@`&`&`&:v`R\`000;0 (q֭We;{ȣvۘ¦gjWoLL ZW)$@|&0]F=g8b&`&`e$P.y)e,W|ji[)t MLJ]H2R-j9H?yH݅}ΤLLKLr`.kx'@Wa;jc300FR Ti}OW[*k50CL"xLLLJ#`4^m&`&`&v`\000؁)s $LLL4v`J&`&`&` `&;E000(@5o;]ZLLL ZRcs5B=󂣤2JTޠ<)]EviMLJE ȒmjY>樏=~F>rz풚 d@lv+.KYC`rNk81SS,LL ZėW/RF8 100Z; ~2VA_sh&o/#3 LLLZ+0O.q"R @ ;.;[z8LLԲ޶ @؁vUMLL +deO&`&`&#ě#l T5H/\yuPdG;-Y5h>;0g%MRaw ږ\5Ɖ"d&]BuK`mn%oYx NL%4p Lk~GuMٓ_խ&Z-Ɖ9ljLDLDWތ d\{g) :n%ҭH7t`8SQc~c@R՝wxǧy+[^9^^|/E%f1}q @ pv"e4e~ ";! D:7'7Q\LBw7 sE\{2vL 3u`hkG>%[tr^o߹5$_(HI4w'f$А6Qu-||'ZE(ɼs D'٨%&ޝ?0I%tf(@CL蟬,䮡⹦!htbT>OC]FH u'GDNZɉQKSm&`e&А̷# g'ׯQjOsS{Rf$PLJ1yY&zo[Ts4"NRKVѴ02L 0Gc4;*c&Pv`ʂ+10pbeJIF]j @؁)HL4&ci⎚ &`&wVY&P*;0s~0(ϱųrN(p9 @$20ҿwC롹^?&l>,W^5{E^LLL2dth+;`<90 ;0-EMLL2+зUsU%y'f4Vh8geb(%BST1_5R  T@f jy3qr4Bp&zMaz^S(|P12CH2܂6446v!RL{$'&O`LLL*H Kx7ay7l">pO  @Ap@@br"F>AL,Qf&`&`&PaYr`X41觨 ӏ4 }6DrFJvylBUQ!98500$]b)L̷ʹQ}DVx 8yFIGyeTgqh&`&`&P9XgņGYgcP){Ƽ̇&DQHzd" PȣDZ㬔Ov34ZnLLL*E ~Q6HC"FյHF2 mȱy)בlA rpTlyZgPh!j300t!E<:YM?gKFr:4~zZ(mh@KrzeL jsE%\)Z5BhG"̌GSq]R$&Qu)T efCt5 ȯiT_4xI"9#OӃYH2z}SXaSN dؔUK Ц)+w}]DH5U 'C/su4&D-*" ОH/C:f1)'t0jygf&cv`rVug4?" _2'9S%[)zrK-kG"Z74ִE?XͼЧ|=ZLrNL uHHytqӥt#iEFo2xm:Ծ|O NIpFYix<{E ggdL x'\4I).> aꒋ'kL&.8h #29.2u?i؁ @N6;qs\pJKa]࿬ it]u=ha^m_*71;E=Q?TԭTVZkk  d@8oДv`RjT\cy݁E %p\4F-] c\1yxo2 3&RKZx @ Ӂ '4!Mc7eUwL][궸=EUcy.y!@ TŁယy T@"; 1zhUO'ϫm&iUq`"ȁvF}Nj AsĭC%4FF]J"3F-ȓVfUkLm'0qOjgX ݪ#[ԓQm]BL 8⢾yD" ]yjIX?ND{Z_(J?gRmPWU9J}Vvk%],8ɿN A'4[G  J&0K[SkFȎ*oS]Hj^5 TNn6D'h57&ivZGnthd״CoĂUF_U_*IF060(oY<!uМp駐i39+aQX/eZEuQȏv*0|)qX47ZK}306BH5^ЖQO;ӨځQ΍03OikI=Lkα/"h=C7midZ堶f)SouxLEg Ozz{ |so!dB @Njš FT>=yaYkv@jԺ!H: QilfM>L pbu)mkWUH?p|>jB  L~K@New@E =)\|14S-8"\STs}T&7؎9*K b!q~GD(Gf=Bf O@b TŁgKp;yu L OX-7'Ey5/ 隰1t Z\I䀃 >m0:-t"ϻm&(r`UiN~ʷkpvI,lKbT&=n}%ӄG"^hc'|в6(j90zTiT̟_4m&K\#NrYyWgeO WtuB3xƲёTo'@ TŁϬ;}We&`&z8gB}F/$@~rtNgr>Sw%dDZ (v ʧ.j,ҢceLL p^:{JG%u'yd~׃&P490l':M (OpLL p@>jѠQ{t2׭{%u> k^Fe3r\RRd30H nh4'j u# l(MJ!$ @ |s$U|ፆL7w˼P&@s 92&`&`)#C"DO'5漄ZJDԸ LL 7PmȫLl Wd&`'@KJgj0X]#`1:g&`&0$8/&f &`Y$C^Ap^$'+-Ajs $馗bB^WFiٯ(? Q ަ $D==^u Ld弸kp% L4V3jx;$:f&85R>N#* U$P?O};ם$S$(eY #G~f&`MddeOLy40i즭 es`>mI-U2$͑m̞o&`!p 馮1kug3ݑD+Գ\%́iZv"O^rOau%A ~;,/0 @ h'GmO:\FF֖Λ0OQׂW)ߒwi{I'ǯ7ӛB}m#lt#^LtTh~3%* ?`(FeɁѣ~FѷHw0F}5LL /FU//BABjh I8c´eNG 5H8~H\^&IO8Kș`0l׵),ߛHi0吥ª;̛eO>)o;50"LXh=Ck[@zRːZ? ˰ZUBۡ+#ەP-8HZZȡy9{h(B93 FZPWty}C=NUˁ;<[fmsɟ;4fj uC¬I{_DEk3>z ]ОH ]z: eJ$FNH8Ñ7-4OI[ Dd0:BKZfܓ4mErB=&ת 5m̃ɋeT*: Fpe7@c ?KF| 2"9+q[uԙ:UKis)PېG}VMY`Nd&@hLLH@WH]2ꚹk3~E䐜t}`` ɹQMR5NjYnEP[;4XL$c"kiDv"< ]4f{4Z7 @3~t8RPBsJvGHׯf= @l@u|`8O㴬TNDݣH4`_Hy'pP4 b3AEgK*JX0ϒ&buwK*56GJpzU(of&`&#\pIDAT,fIeSw%O&ԝik cZ-3q O@f=R** |qOߣPhX600H804SM7FjڲUY|RH͚Zl&`&`&Uq`Hϣ*G@-%\f},EtArhl&`&`&r`|_]֒pu1ܥ!30 j90RRnD]H*~DZi颚1i Ԅ@U.zzdK.7(H5Bk$'F#GFLLL0~B]R6 %JV% $@jkhLHw(5ML2OաcvGK\MLLrN9]> !kκz<9PYn&`&` ;͓"h 'Pk]AB$\<002aї;UH׌[J&P67uf&`&`8-Çk>d3f(Ӭ{!00LPזG!}) wVwbHphS*170NRJ7$E, q%L4]&,qLTԕ0(/vqSZGMdT&7؁iPsѓbHa UU1#Ƶ,]T}KSh}m&"v`Z/9 sR:tլ.ĨEt" @)Ut jSBKN/yRrnS/&⨨dYZuA!9( Ƥ 4EN2谦2֙?+yMLU~A|3A2H#7$GeHa܋"}d30F Ђ2s)dZmh3: ıre]'uUEu RmSԿ4N 2ɔ_';0 4M8UG^JyLoS DVюH]Cr`G gxi7(8/qbK15~,jxU4?sr`'U)7+v`juhKw&h ntƢaEGNEI[J}XX}8OX*['*muיFgFJLYq6׫uM߇ +6 ]%tvic:3>ꋶUuG"K sa¡ O&[.A]Pq=Aq˝a`7;lj5#1.$'rڲ2ӝD}.BK""nw:Z{ԋy_L"T+ʬv';91qCh_m&M|ߑH/TJ?Ҧ2Z6ꡧ"C#Ms?uS+n#l&P1>)-{gV'Ew+0=݄AL 83U{E/%Uʿ1 0^υ6eN`Z/3wnBr:rNLrVDGUH t%z#cp5y@瀁HН4R՝D={#=eJ}TB}Ƽ,)MK%_bz5-$>֝!hت4();85f&a#9'F5Dcb\H]GϏI9-btpEOs f&;&CۚyOQD]6'Qci6ǓjUo&¾e^gڔjd60 p~IeZ z?yg]=Byѣϗ?Q9/fp L$H:fIp%|XQHOFoq||AXcRHH8Fmq$8BރC]CzF9ckz.O|8 $hq`H'JoB=GsWA6c3dxYjQXُysC*+-J.]pPF`lŶu[_TێcLDl"{Z6C=v(8.D /t BT^/p]7A23h9j\ CjμiO\7 ?hMu^C伌GG!h$3ֵrvD6@)їܵZ+jFFg 1 3Q 6Hb-T$Nl0 ɑ 1 nSsN60&*E,9Fs,%xt= S @Od z4JW dފE 9+{;X7_#ٽhB>sfe*}.5V.9j#omh8 . ݂m_.=m6C 8#zO-'zF]H_(1n9 [&#Co HhA#ŵ [نZ5WchS4 ֝\h"Qu_Jx1ce!ϯ2ʯNn?!5NnD&`ؑ0*&Cǜ|ⷣC&G?-|d'800&Dv.y|utE:sg_7b_·xB @QWM&"͗t%}^#4#FY;S=Nr:T}H=L&n`<4f2S7 8>2/ յn"uqc"ӱڦz<%+>7Z"H7!rrg ZJEu :PL 3r`C /!$,3x kfGwg*hw{7LiRzb<&` 6?+ qkjY "8b^[M!MLH]HrbJ598Zu+Լ\QrG~2C^?Z_8(tC6Z;H}/hͺ,TئNX:hWBjeQQ('Ke N9 aw $C>v@242jA[H*u߁)h⢖#r` P~_(qH&VhML')5[ψ2 ?Dj:FXE-*+uZHΊ5%5mtz 4+'%hHama+K!ӯvCc(ft& rPc۰Y<.̦QթH`+t"l M t`P34j\uFrXAr"t'0ə; $BM'=I⦓h1ZuBjCrhw$D(ƻLCZVwu弊XL'~8?#<.eVZ^VU3~@ʣ`#Hf]W.G:DwEPX/yogt!d2 O`3,РԏjyV!fYjlD'JDGR)6H%Q|E*+RBH71;"9;;V :j6!maM2UD"L}9pH29$# @s p^eB6wI_E7y'F l]$7q@8WsLNwohXQ_&1QCci@؁.wMNEхcT^`ߊSYl&/v`][0yx@=eBף/6=;0  @R༬FYAz:sDqQבL "ВG LLr>S?y J̬<kǡ!A? L'`0Y ܀@*~ԠüѾHz) 䞀r08#6(8/n v)uA7.;0ݷ $@XA#K/zǢm Fq&`&]H T~^tɣq/C6G Gm&`&P L*M uM `j @L*Mul-9dX5]H(3ӚQn@/bY%N,Ye&P[yE6M.Ċ@/~Q42;0Y޻ Ԑbl4@To(^w4c60?o Q]>z/mrgB" @ ؁7 .4Woϕ15džhAKsVeLELkcI!0F - ܽ ˜ " 5f'0ɬ"><L 'dG&Pk8!z';L%.z8LLL $yl&`&`&`S/' $$LLL^v`D000$㲙LM7efNǒHXpJQ'uϸ\&0+Ge[=8@,>&"v`Z @E }E-Ŀ&PBto$7׎+2> R&0;arqLZeƑ ڟ[wB&*J@% ؁$]LLL"܅T^ @% ؁$]LLL"TWj&`&`&PIv`*I600,|j%IENDB`content/ja/config.md0000644000175000056700000001027615226251677013161 0ustar0000000000000000## III. 設定 ### 設定を環境変数に格納する アプリケーションの *設定* は、[デプロイ](./codebase)（ステージング、本番、開発環境など）の間で異なり得る唯一のものである。設定には以下のものが含まれる。 * データベース、Memcached、他の[バックエンドサービス](./backing-services)などのリソースへのハンドル * Amazon S3やTwitterなどの外部サービスの認証情報 * デプロイされたホストの正規化されたホスト名など、デプロイごとの値 アプリケーションは時に設定を定数としてコード内に格納する。これはTwelve-Factorに違反している。Twelve-Factorは **設定をコードから厳密に分離すること** を要求する。設定はデプロイごとに大きく異なるが、コードはそうではない。 アプリケーションがすべての設定をコードの外部に正しく分離できているかどうかの簡単なテストは、認証情報を漏洩させることなく、コードベースを今すぐにでもオープンソースにすることができるかどうかである。 なお、この“設定”の定義には、アプリケーション内部の設定は **含まない** ことに注意する。内部の設定とは、Railsにおける`config/routes.rb`や、[Spring](http://spring.io/)において[コードモジュールがどう接続されるか](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html)などの設定を指す。この種の設定はデプロイの間で変わらないため、コードの内部で行うべきである。 設定に対するもう1つのアプローチは、バージョン管理システムにチェックインされない設定ファイルを使う方法である。例として、Railsにおける`config/database.yml`がある。この方法は、リポジトリにチェックインされる定数を使うことに比べると非常に大きな進歩であるが、まだ弱点がある。設定ファイルが誤ってリポジトリにチェックインされやすいことと、設定ファイルが異なる場所に異なるフォーマットで散乱し、すべての設定を一つの場所で見たり管理したりすることが難しくなりがちであることである。その上、これらのフォーマットは言語やフレームワークに固有のものになりがちである。 **Twelve-Factor Appは設定を *環境変数* に格納する。** 環境変数は、コードを変更することなくデプロイごとに簡単に変更できる。設定ファイルとは異なり、誤ってリポジトリにチェックインされる可能性はほとんどない。また、独自形式の設定ファイルやJava System Propertiesなど他の設定の仕組みとは異なり、環境変数は言語やOSに依存しない標準である。 設定管理のもう1つの側面はグルーピングである。アプリケーションは設定を名前付きのグループ（しばしば“環境”と呼ばれる）にまとめることがある。グループは、Railsにおける`development`、`test`、`production`環境のように、デプロイの名前を取って名付けられる。この方法はうまくスケールしない。アプリケーションのデプロイが増えるにつれて、新しい環境名（`staging`や`qa`）が必要になる。さらにプロジェクトが拡大すると、開発者は`joes-staging`のような自分用の環境を追加する。結果として設定が組み合わせ的に爆発し、アプリケーションのデプロイの管理が非常に不安定になる。 Twelve-Factor Appの場合、環境変数は粒度の細かい管理であり、それぞれの環境変数は互いに直交している。環境変数は“環境”としてまとめられることはないが、代わりにデプロイごとに独立して管理される。これは、アプリケーションのライフサイクルに渡って、アプリケーションが多くのデプロイへと自然に拡大していくにつれて、スムーズにスケールアップするモデルである。 content/ru/background.md0000644000175000056700000000452615226251677014070 0ustar0000000000000000Предпосылки ========== Участники, внёсшие вклад в этот документ, были непосредственно вовлечены в разработку и развёртывание сотен приложений и косвенно были свидетелями разработки, выполнения и масштабирования сотен тысяч приложений во время нашей работы над платформой [Heroku](http://www.heroku.com/). В этом документе обобщается весь наш опыт использования и наблюдения за самыми разнообразными SaaS-приложениями в дикой природе. Документ является объединением трёх идеальных подходов к разработке приложений: уделение особого внимания динамике органического роста приложения с течением времени, динамике сотрудничества разработчиков, работающих над кодовой базой приложения, и [устранение последствий эрозии программного обеспечения](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). Наша мотивация заключается в повышении осведомлённости о некоторых системных проблемах, которые мы встретили в практике разработки современных приложений, а также для того, чтобы предоставить общие основные понятия для обсуждения этих проблем и предложить набор общих концептуальных решений этих проблем с сопутствующей терминологией. Формат навеян книгами Мартина Фаулера (Martin Fowler) *[Patterns of Enterprise Application Architecture](http://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* и *[Refactoring](http://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*. content/th/build-release-run.md0000644000175000056700000001175015226251677015252 0ustar0000000000000000## V. Build, release, run ### แยกขั้นตอนของการ build และ run อย่างเคร่งครัด [codebase](./codebase) จะเปลี่ยนแปลงไปเป็น (non-development) deploy ด้วย 3 ขั้นตอน: * *ขั้นตอนการ build* เป็นการแปลงซึ่งเป็นการเปลี่ยน code repo ไปเป็นโปรแกรมที่ทำงานได้ (executable bundle) เรียกว่าการ *build* ใช้ version ของ code ที่ระบุ commit ด้วยกระบวนการ deployment ซึ่งขั้นตอนการ build นี้จะดึง[การอ้างอิง](./dependencies) และ compile เป็น binariy และ assets. * *ขั้นตอนการ release* จะนำ build ที่ได้จากขั้นตอนการ build และรวามเข้ากับ [การตั้งค่า](./config) ของ deploy ซึ่งจะได้ *release* ที่มีทั้ง build และ การตั้งค่า ที่พร้อมจะทำงานได้ในสิ่งแวดล้อมการทำงาน * *ขั้นตอนการ run* (หรือเรียกว่า "runtime") เป็นการทำให้ app ทำงานในสิ่งแวดล้อมการทำงาน ด้วยการเริ่มใช้งานบางเซตของ app [processes](./processes) ด้วย release ที่ถูกเลือก ![Code becomes a build, which is combined with config to create a release.](/images/release.png) **Twelve-factor app ใช้การแยกขั้นตอนการ build, release และ run ออกจากกันอย่างเคร่งครัด** ตัวอย่างเช่น เป็นไปไม่ได้ที่ทำการเปลี่ยนแปลงของ code ในขณะทำงาน เนื่องจากไม่มีวิธีใดในการเผยแพร่การเปลี่ยนแปลงกลับสู่สถานะ build เครื่องมื่อสำหรับ deployment โดยทั่วไปจะมีเครื่องมือจัดการการ release อยู่แล้ว และส่วนใหญ่จะมีความสามารถ roll back กลับสู่ release ก่อนหน้าได้ ตัวอย่างเช่น [Capistrano](https://github.com/capistrano/capistrano/wiki) เป็นเครื่องมือ deployment ที่เก็บการ release ในไดเรกทอรีย่อยชื่อว่า `releases` ที่ซึ่ง release ปัจจุบันเชื่อมโยงเข้ากับไดเรกทอรี release ปัจจุบัน สามารถใช้คำสั่ง `rollback` เพื่อทำให้มัน roll back กลับไปเป็น release ก่อนหน้าอย่างรวดเร็ว ทุกๆ release ควรจะมี release ID เฉพาะเสมอ เช่น timestamp ของ release (เช่น `2011-04-06-20:32:17`) หรือจำนวนนับที่เพิ่มขึ้น (เช่น `v100`), release เป็นบัญชีแยกประเภทที่เพิ่มขึ้นได้เท่านั้นและ release ไม่สามารถแก้ไขได้เมื่อถูกสร้างขึ้นแล้ว ทุกๆ การเปลี่ยนแปลงจำเป็นต้องสร้าง release ใหม่เสมอ การ build เริ่มต้นโดย developer ของ app เมื่อไรก็ตามที่ code ใหม่ถูก deploy, การทำงานในขณะทำงาน ในทางตรงกันข้าม สามารถเกิดขึ้นได้โดยอัตโนมัติในกรณีที่ server reboot หรือ crashed process ถูก restart โดย process manager ดังนั้นขั้นตอนการ run ถูกทำให้มีขั้นตอนน้อยที่สุดเท่าที่จะเป็นไปได้ เพื่อป้องกันปัญหา app สามารถหยุดการทำงานได้ในเวลาตอนกลางคืนเมื่อไม่มี developer อยู่ทำงาน ขั้นตอนการ build สามารถเป็นขั้นตอนที่ซับซ้อนได้ ในเมื่อ error จะแสดงต่อ developer ผู้ซึ่งทำการ deploy มัน content/th/dev-prod-parity.md0000644000175000056700000002027515226251677014763 0ustar0000000000000000## X. Dev/prod parity ### ทำให้ development, staging และ production ให้มีความใกล้เคียงกันที่สุด ในอดีต มีช่องว่างที่มากมายระหว่าง development (developer แก้ไข app ในเครื่องตัวเอง [deploy](./codebase)) และ production (deploy ที่ทำงานและใช้งานโดยผู้ใช้งานที่แท้จริง) ช่องว่างที่ชัดเจนมี 3 เรื่่อง: * **ช่องว่างของเวลา** developer จะทำงานบน code ที่ใช้เวลาเป็นวัน, เป็นอาทิตย์ หรือเป็นเดือนที่จะเอาขึ้นสู่ production * **ช่องว่างของบุคคล** developer เขียน code แต่วิศวกร ops ทำการ deploy code * **ช่องว่างของเครื่องมือ** developer อาจจะใช้ stack อย่างเช่น Nginx, SQLite และ OSX ขณะที่ production deploy ใช้ Apache, MySQL และ Linux **Twelve-factor app ถูกออกแบบสำหรับ [การ deployment อย่างต่อเนื่อง (continuous deployment)](http://avc.com/2011/02/continuous-deployment/) ด้วยการรักษาช่องว่างระหว่าง development และ production ให้แคบที่สุด** โดยพิจารณาจากช่องว่าง 3 เรื่องด้านบน: * ทำให้เวลาสั้นลง: developer อาจจะเขียน code และทำการ deploy ในเวลาเพียงชั่วโมงเดียวหรือเพียงไม่กี่นาทีหลังจากเขียน code เสร็จ * ทำให้ช่องว่างบุคคลแคบลง: developer เป็นคนเขียน code และเป็นคนที่ deploy code เองและเป็นคนที่ดูใน production เอง * ทำให้ช่องว่างเครื่องมือแคบลง: ทำให้ใช้เครื่องมือ developement และ production เหมือนกันมากที่สุดเท่าที่จะทำได้ สรุปข้างบนเป็นตาราง:
    Traditional app Twelve-factor app
    เวลาระหว่าง deploys สัปดาห์ ชั่วโมง
    คนเขียน code vs คน deploy code คนละคน คนเดียวกัน
    สภาพแวดล้อม Dev vs production แตกต่างกัน เหมือนกันมากที่สุด
    [Backing services](./backing-services) อย่างเช่น ฐานข้อมูลของ app, ระบบคิว, หรือ ระบบแคช เป็นสิ่งที่ dev/prod ควรมีควมคล้ายคลึงกันมากที่สุด หลายภาษามี library ซึ่งทำให้เข้าถึง backing service ได้ง่าย รวมทั้ง *adapter* กับบริการที่แตกต่างกัน ตัวอย่างบางส่วนในตารางนี้:
    Type Language Library Adapters
    Database Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
    Queue Python/Django Celery RabbitMQ, Beanstalkd, Redis
    Cache Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached
    Developer บางครั้งหาวิธีที่ใช้ backing service ง่ายๆ ในเครื่องตัวเอง ในขณะที่ backing service ใช้งานอย่างเคร่งครัดและแข็งแกร่งใน production ตัวอย่างเช่น ใช้ SQLite ในเครื่องพัฒนา และใช้ PostgreSQL ใน production หรือใช้ local process memory สำหรับแคชใน development และ Memcached ใน production **Twelve-factor developer ต่อต้านกำใช้งาน backing service ที่แตกต่างกันระหว่าง development และ production** แม้ว่าเมื่อใช้ adapter ในทางทฤษฎีแล้วไม่มีความแตกต่างกันใน backing service ความแตกต่างระหว่าง backing service หมายความว่าความไม่เข้ากันเพียงเล็กน้อยที่เป็นสาเหตุให้ code ทำงานได้และผ่านการทดสอบใน development หรือ staging แต่ไปทำงานผิดพลาดใน production ความผิดหลาดเหล่านี้สร้างความไม่ลงรอยกันกับการ delopyment อย่างต่อเนื่อง และราคาของความไม่ลงรอยกันนี้และความผันผวนตามมาของการ deployment อย่างต่อเนื่องสูงมากเมื่อพิจารณาตลอดอายุการทำงานของ application Lightweight local service ไม่น่าสนใจมากเหมือนเมื่อก่อน ด้วย backing service สมัยใหม่อย่างเช่น Memcached, PostgreSQL และ RabbitMQ ไม่มีความแตกต่างกันในการติดตั้งและทำงาน ต้องขอบคุณระบบ packaging สมัยใหม่ อย่างเช่น [Homebrew](http://mxcl.github.com/homebrew/) และ [apt-get](https://help.ubuntu.com/community/AptGet/Howto) อีกทางเลือกหนึ่ง เครืองมือจัดเตรียมที่เปิดเผยอย่างเช่น [Chef](http://www.opscode.com/chef/) และ [Puppet](http://docs.puppetlabs.com/) รวม light-weight สิ่งแวดล้อมเสมือนอย่างเช่น [Docker](https://www.docker.com/) และ [Vagrant](http://vagrantup.com/) ทำให้ developer รัน app ในสิ่งแวดล้องของเครื่องได้ใกล้เคียงกับสิ่งแวดล้อมของ production มากที่สุด และค่าใช้จ่ายของการติดตั้งและใช้งานระบบเหล่านี้ต่ำมากถ้าเทียบกับประโยชน์ที่ได้รับสำหรับความเท่าเทียมกันของ dev/prod และการ deployment ที่ต่อเนื่อง Adapter ไปยัง backing service ที่แตกต่างกันยังคงมีประโยชน์อยู่ เพราะว่าจะทำให้ port ไปใช้กับ backing service ใหม่ๆ ได้อย่างง่ายดาย แต่การ deploy ทั้งหมดของ app (developer environment, staging, production) ควรจะใช้ชนิดและเวอร์ชันที่เหมือนกันของแต่ล่ะ backing service. content/de/build-release-run.md0000644000175000056700000000532015226251677015223 0ustar0000000000000000## V. Build, release, run ### Build- und Run-Phase strikt trennen Eine [Codebase](./codebase) wird durch drei Phasen in einen (Nicht-Entwicklungs)-Deploy transformiert: * Die *Build-Phase* ist eine Transformation, die ein Code-Repository in ein ausführbarers Code-Bündel übersetzt, das man auch *Build* nennt. Ausgehend von einer Code-Version eines Commits, der im Deployment-Prozess festgelegt wurde, holt sie [Abhängigkeiten](./dependencies), verpackt sie zum Mitliefern, und kompiliert Binaries und Assets. * Die *Release-Phase* übernimmt den Build von der Build-Phase und kombiniert ihn mit der zum Deploy passenden [Konfiguration](./config). Der so erzeugte *Release* enthält sowohl den Build, als auch die Konfiguration und kann direkt in einer Ausführungsumgebung ausgeführt werden. * Die *Run-Phase* (auch "Laufzeit" genannt) führt die App in einer Ausführungsumgebung aus, indem sie eine Menge der [Prozesse](./processes) der App gegen einen ausgewählten Release ausführt. ![Code wird zum Build und zusammen mit einer Konfiguration ergibt sich ein Release](/images/release.png) **Die Zwölf-Faktor-App trennt strikt zwischen Build-, Release- und Run-Phase.** Es ist nicht möglich, Code-Änderungen zur Laufzeit zu machen, weil es keinen Weg gibt, diese Änderungen zurück in die Build-Phase zu schicken. Deployment-Werkzeuge bieten meist eine Release-Verwaltung an. Am bekanntesten ist die Funktion auf einen früheren Release zurückzusetzen. Zum Beispiel speichert das Deployment-Werkzeug [Capistrano](https://github.com/capistrano/capistrano/wiki) Releases in einem Unterverzeichnis mit Namen `releases`. Der aktuelle Release ist ein symbolischer Link auf aktuelle Release-Verzeichnis. Mit dem Kommando `rollback` kann einfach und schnell auf einen früheren Release zurückgesetzt werden. Jeder Release sollte eine eindeutige Release-ID haben, wie zum Beispiel einen Zeitstempel des Releases (`2011-04-06-20:32:17`) oder eine laufende Nummer (`v100`). Releases werden nie gelöscht und ein Release kann nicht verändert werden, wenn er einmal angelegt ist. Jede Änderung erzeugt einen neuen Release. Builds werden durch die Entwickler der App angestoßen, wenn neuer Code deployt wird. Im Gegensatz dazu kann die Ausführung zur Laufzeit automatisch erfolgen, wenn ein Server neu gebootet wird oder ein abgestürzter Prozess von der Prozessverwaltung neu gestartet wird. Deswegen sollte die Run-Phase auf so wenig bewegliche Teile wie möglich beschränkt sein, denn Probleme, die eine App vom Laufen abhalten, können sie mitten in der Nacht zusammenbrechen lassen, wenn keine Entwickler zur Verfügung stehen. Die Build-Phase kann komplexer sein, denn Fehler sind immer sichtbar für den Entwickler, der den Deploy vorantreibt. content/ko/dependencies.md0000644000175000056700000000605015226251677014354 0ustar0000000000000000## II. 종속성 ### 명시적으로 선언되고 분리된 종속성 대부분의 프로그래밍 언어는 라이브러리 배포를 위한 패키징 시스템을 제공하고 있습니다. Perl의 [CPAN](http://www.cpan.org/) 이나 Ruby의 [Rubygems](http://rubygems.org/)가 그 예입니다. 라이브러리는 패키징 시스템을 통해 시스템 전체(site pakages)나 애플리케이션을 포함한 디렉토리(vendoring 혹은 bundling)에 설치될 수 있습니다. **Twelve-Factor App은 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 절대 의존하지 않습니다.** *종속선 선언* mainifest를 이용하여 모든 종속성을 완전하고 엄격하게 선언합니다. 더나아가, *종속성 분리* 툴을 사용하여 실행되는 동안 둘러싼 시스템으로 암묵적인 종속성 "유출"이 발생하지 않는 것을 보장합니다. 이런 완전하고 명시적인 종속성의 명시는 개발과 서비스 모두에게 동일하게 적용됩니다. 예를 들어, 루비에서 사용되는 [Bundler](https://bundler.io/)는 종속성 선언을 위해 `Gemfile` manifest 포맷을 지원하며, 종속성 분리를 위해 `bundle exec`를 지원합니다. 파이썬에는 이를 지원하기 위한 2가지 도구가 있습니다. [Pip](http://www.pip-installer.org/en/latest/)은 종속성 선언을 위해 사용되며, [Virtualenv](http://www.virtualenv.org/en/latest/)는 종속성 분리를 위해 사용됩니다. 심지어 C언어에도 종속성 분리를 위해 [Autoconf](http://www.gnu.org/s/autoconf/)가 있으며, static link를 활용해 종속성 분리도 가능합니다. 어떤 툴체인을 사용하든, 종속성 선언과 분리는 항상 같이 사용되어야 합니다. 하나만 사용하는 것은 Twelve-Factor에 만족하는 데 불충분합니다. 명시적인 종속성 선언의 장점 중 하나는 애플리케이션 개발에 새로 참가하게 된 개발자가 설치를 간단하게 할 수 있다는 점입니다. 새로 참가한 개발자는 애플리케이션의 코드베이스를 개발 머신에 체크아웃 하고, 언어의 런타임과 종속성 매니저만 미리 설치하면 됩니다. 개발자는 정해져있는 *빌드 명령어*만 입력하면 응용 프로그램의 코드를 실행하는 데 필요한 모든 것을 설치할 수 있습니다. 예를 들어, Ruby의 빌드 명령어는 `bundle install`이며, Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme)에서는 `lein deps`입니다. Twelve-Factor App은 어떠한 시스템 도구에도 암시적으로 의존하지 않습니다. 예를 들어, ImageMagick이나 `curl`을 사용하는 경우가 있습니다. 이러한 툴들은 대부분의 시스템에 존재하지만, 모든 시스템에 존재하는 것이 보장되는 것은 아닙니다. 미래의 시스템에서는 존재하지 않을 수 있으며, 호환되는 버전이 있으라는 보장도 없습니다. 애플리케이션에게 시스템 도구가 필요하다면, 그 도구를 애플리케이션과 통합해야 합니다. content/tr/backing-services.md0000644000175000056700000000556015226251677015166 0ustar0000000000000000## IV. Destek servisi ### Destek servislerine ekli kaynak olarak davranma Bir *destek servisi* uygulamanın kendi normal işleminin bir parçası olarak ağ üzerinden tüketim yapan bir servistir. Örnekler veri deposu([MySQL](http://dev.mysql.com/) veya [CouchDB](http://couchdb.apache.org/) gibi), mesajlama/kuyruklama sistemleri( [RabbitMQ](http://www.rabbitmq.com/) veya [Beanstalkd](https://beanstalkd.github.io)), giden email için SMTP servisi([Postfix](http://www.postfix.org/) gibi) ve önbellekleme sistemleri([Memcached](http://memcached.org/) gibi) içerir. Destek servisleri, veri tabanı gibi, uygulamaların çalışma zamanlı dağıtımlarında olduğu gibi benzer sistem yöneticileri tarafından geleneksel olarak yönetilirler. Bu yerel yönetilen servislere ilave olarak, uygulama üçüncü parti uygulamalar tarafından onaylanmış ve yönetilmiş servislere sahip olabilirler. Örnekler SMTP servisleri([Postmark](http://postmarkapp.com/) gibi), Metrik toplama servisleri( [New Relic](http://newrelic.com/) veya [Loggly](http://www.loggly.com/) gibi), binary servisler([Amazon S3](http://aws.amazon.com/s3/) gibi) ve API-erişilebilir tüketici servisleri bile [Twitter](http://dev.twitter.com/), [Google Maps](http://code.google.com/apis/maps/index.html), ve [Last.fm](http://www.last.fm/api) gibi) içerir. **On iki faktör uygulaması için bu kod, yerel ve üçüncü parti servisler arasında ayrım yapmaz.** Uygulamada, her ikiside ek kaynaktır, [yapılandırmada](./config) saklanmış yer belirleyici/kimlik bilgileri ve URL aracılığıyla erişilir. On iki faktör uygulamasının bir dağıtımı, uygulama kodunda hiçbir değişiklik olmadan üçüncü parti([Amazon RDS](http://aws.amazon.com/rds/) gibi) tarafından yönetilenle yerel MySQL veritabanı silebilmelidir. Aynı şekilde bir yerel SMTP servisi(Postmark gibi), kod değişikliksiz bir üçüncü parti SMTP servisiyle değiş tokuş yapılabilir. Her iki durumda da, kaynak sadece değişmesi gereken yapılandırmada ele alınır. Her bir belirgin destek servisi bir *kaynaktır*. Örneğin, bir MySQL veritabanı(Uygulama katmanında parçalanma için kullanılmış) bir kaynaktır; iki MySQL veritabanı iki belirgin kaynak olarak nitelendirilir. On iki faktör uygulaması veritabanlarına, bağlı oldukları dağıtımlara gevşek bağlaşımlarını belirten *ek kaynak* olarak davranır. A production deploy attached to four backing services. Kaynaklar dağıtımlara istenilen zamanda eklenilip çıkartılabilir. Örneğin, eğer uygulamanın veritabanı donanım sorununa göre yanlış davranıyorsa, uygulamanın yöneticisi son yedeklemeden geri yüklenmiş yeni bir veri tabanı sunucusunu döndürebilir. Şuanki veritabanı ekten çıkarılmış olabilir ve yeni veri tabanı eklenmiş olabilir, hiç bir kod değişikliği olmadan. content/tr/port-binding.md0000644000175000056700000000410115226251677014331 0ustar0000000000000000## VII. Port Bağlama ### Port bağlama yolu üzerinden dışarı aktarma Web uygulamaları bazı zamanlar web sunucu taşıyıcıları içinde çalıştırılırlar. Örneğin, PHP uygulamaları modül olarak [Apache HTTPD](http://httpd.apache.org/) içinde veya Java uygulamaları [Tomcat](http://tomcat.apache.org/) içinde çalıştırılabilirler. **On iki faktör uygulama tamamen bağımsız** ve web dönüştürme servisi oluşturmak için çalışma ortamı içindeki web sunucunun çalışma zamanlı enjeksiyonuna dayanmaz. Bu web uygulaması port bağlama tarafından HTTP'yi servis olarak dışa aktarır ve o porta gelen istekleri dinler. Yerel geliştirme ortamında, geliştiriciler `http://localhost:5000/` gibi servis URL'ini, onların duygulamaları tarafından dışa aktarılan servise erişmek için ziyaret ederler. Dağıtımda, yönlendirme katmanı dışa bakan makine adından port bağımlı web süreçlerine gelen yönlendirme isteklerini ele alır. Bu tipik olarak, uygulamaya web sunucusu kütüphanesi eklemek için bağımlılık tanımlaması kullanılarak geliştirilmiştir, Python için [Tornado](http://www.tornadoweb.org/), Ruby için [Thin](http://code.macournoyer.com/thin/) veya Java ve diğer JVM-tabanlı diller için [Jetty](http://jetty.codehaus.org/jetty/). Bu uygulamanın kodu içinde *kullanıcı alanında* gerçekleşir. Çalışma ortamıyla olan anlaşma isteklere hizmet veren bir porta bağlıdır. HTTP port bağlama ile dışarı aktarılabilen tek servis değildir. Nerdeyse herhangi bir sunucu yazılım tipi port için süreç bağlama aracılığıyla çalışır ve gelen istekleri bekler. Örnekler [ejabberd](http://www.ejabberd.im/) ([XMPP](http://xmpp.org/) ile haberleşir) ve [Redis](http://redis.io/) ([Redis protocol](http://redis.io/topics/protocol) ile haberleşir) içerir. Port bağlama yaklaşımı bir uygulamanın,tüketici uygulama için yapılandırmadaki kaynak olanağı gibi destek uygulamasına URL sağlayarak diğer bir uygulamanın [destek servisi](./backing-services) olabileceği anlamına geldiğini de unutmayın. content/ja/concurrency.md0000644000175000056700000000677515226251677014257 0ustar0000000000000000## VIII. 並行性 ### プロセスモデルによってスケールアウトする すべてのコンピュータープログラムは、一度実行されると、1つ以上のプロセスとして表される。Webアプリケーションでは様々なプロセス実行形態がとられてきた。例えば、PHPのプロセスはApacheの子プロセスとして実行され、リクエスト量に応じて起動される。Javaプロセスは反対の方法をとる。JVMが1つの巨大な親プロセスを提供し、起動時にシステムリソース（CPUやメモリ）の大きなブロックを確保し、スレッドを使って内部的に並行性を管理する。どちらの場合でも、実行されるプロセスはアプリケーションの開発者にはほとんど見えない。 ![スケールは実行されるプロセスの数として表現され、ワークロードの種類はプロセスタイプとして表現される。](/images/process-types.png) **Twelve-Factor Appではプロセスは第一級市民である。** Twelve-Factor Appにおけるプロセスの考え方は、[サービスのデーモンを実行するためのUnixプロセスモデル](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)から大きなヒントを得ている。このモデルを使い、個々のワークロードの種類を *プロセスタイプ* に割り当てることで、開発者はアプリケーションが多様なワークロードを扱えるように設計することができる。例えば、HTTPリクエストはWebプロセスによって処理し、時間のかかるバックグラウンドタスクはワーカープロセスによって処理することができる。 このモデルは、ランタイムVM内のスレッドや、[EventMachine](https://github.com/eventmachine/eventmachine)、[Twisted](http://twistedmatrix.com/trac/)、[Node.js](http://nodejs.org/)などの非同期イベントモデルによって、個々のプロセスがプロセス内部で多重化することを禁止するわけではない。しかし個々のVMはそれほど大きくなる（垂直にスケールする）ことができないため、アプリケーションは複数の物理マシンで動作する複数のプロセスへと拡大できなければならない。 このプロセスモデルが真価を発揮するのは、スケールアウトが必要になったときである。[シェアードナッシングで水平分割可能なTwelve-Factor Appプロセスの性質](./processes)は、並行性を高める操作が単純かつ確実なものであることを意味する。プロセスタイプとそれぞれのタイプのプロセス数の配列は、 *プロセスフォーメーション* と言われる。 Twelve-Factor Appのプロセスは[決してデーモン化するべきではないし](http://dustin.github.com/2010/02/28/running-processes.html)、PIDファイルを書き出すべきではない。その代わりに、OSのプロセスマネージャー（例：[systemd](https://www.freedesktop.org/wiki/Software/systemd/)、クラウドプラットフォームの分散プロセスマネージャー、あるいは開発環境における[Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)のようなツール）を頼ることで、[出力ストリーム](./logs)を管理し、プロセスのクラッシュに対応し、ユーザーによる再起動やシャットダウンを処理すべきである。 content/de/backing-services.md0000644000175000056700000000540215226251677015124 0ustar0000000000000000## IV. Unterstützende Dienste ### Unterstützende Dienste als angehängte Ressourcen behandeln Ein *unterstützender Dienst* ist jeder Dienst, den die App über das Netzwerk im Rahmen ihrer normalen Arbeit konsumiert. Beispiele sind Datenspeicher (wie [MySQL](http://dev.mysql.com/) oder [CouchDB](http://couchdb.apache.org/)), Messaging/Queueing-Systeme (wie [RabbitMQ](http://www.rabbitmq.com/) oder [Beanstalkd](https://beanstalkd.github.io)), SMTP-Dienste für das Senden von Mail (wie [Postfix](http://www.postfix.org/)), und Cache-Systeme (wie [Memcached](http://memcached.org/)). Unterstützende Dienste wie Datenbanken werden traditionell von denselben Systemadministratoren verwaltet, die die App deployen. Außer diesen intern verwalteten Diensten können der App auch von Dritten verwaltete Dienste zur Verfügung stehen. Dazu gehören SMTP-Dienste (wie [Postmark](http://postmarkapp.com/)), Metrik-Sammler (wie [New Relic](http://newrelic.com/) oder [Loggly](http://www.loggly.com/)), Binary-Asset-Dienste (wie [Amazon S3](http://aws.amazon.com/s3/)), und auch über eine API zugängliche Dienste (wie [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), oder [Last.fm](http://www.last.fm/api)). **Der Code einer Zwölf-Faktor-App macht keinen Unterschied zwischen lokalen Diensten und solchen von Dritten.** Für die App sind sie beide unterstützende Dienste, zugreifbar über eine URL oder andere Lokatoren/Credentials, die in der [Konfiguration](./config) gespeichert sind. Ein [Deploy](./codebase) einer Zwölf-Faktoren-App könnte eine lokale MySQL-Datenbank, durch eine von Dritten zur Verfügung gestellten, ersetzen (wie [Amazon RDS](http://aws.amazon.com/rds/)). Genauso ohne Codeänderung kann ein lokaler SMTP-Server durch einen von Dritten zur Verfügung gestellten SMTP-Dienst ersetzt werden. In beiden Fällen muss sich nur der Resource-Handle in der Konfiguration ändern. Jeder einzelne unterstützende Dienst ist eine *Ressource*. So ist zum Beispiel eine MySQL-Datenbank eine Ressource; zwei MySQL-Datenbanken (die für ein Sharding auf Applikationsebene verwendet werden) stellen zwei Ressourcen dar. Dass die Zwölf-Faktor-App diese Datenbanken als *angehängte Ressourcen* behandelt, zeigt ihre lose Kopplung, zu dem Deploy an dem sie hängen. Ein Produktions-Deploy der an vier unterstützenden Diensten hängt. Ressourcen können beliebig an Deploys an- und abgehängt werden. Wenn zum Beispiel die Datenbank einer App aufgrund von Hardwareproblemen aus der Rolle fällt, könnte der App-Administrator eine neue Datenbank aus einem Backup aufsetzen. Die aktuelle Produktionsdatenbank könnte abgehängt und die neue Datenbank angehängt werden -- ganz ohne Codeänderung. content/ja/who.md0000644000175000056700000000043615226251677012506 0ustar0000000000000000このドキュメントの対象者 ============================== サービスとして動くアプリケーションを開発しているすべての開発者。およびそのようなアプリケーションをデプロイまたは管理しているインフラエンジニア。 content/pl/concurrency.md0000644000175000056700000000573515226251677014273 0ustar0000000000000000## VIII. Współbieżność ### Skaluj przez odpowiednio dobrane procesy Każdy program komputerowy od momentu uruchomienia jest reprezentowany przez jeden lub więcej procesów. Aplikacje internetowe mogą być uruchamiane w różnorodny sposób. Dla przykładu - procesy PHP uruchamiane są na żądanie (w zależności od potrzeby obsługi odpowiednio dużej liczby zapytań) jako podrzędne procesy Apache'a. W Javie procesy obsługiwane są zupełnie inaczej, z JVM zapewniającym jeden nadrzędny proces, który rezerwuje zasoby systemu (CPU oraz pamięć) na starcie oraz współbieżnością zarządzaną wewnętrznie i opartą na wątkach. Dla developerów aplikacji różnica jednak nie będzie szczególnie odczuwalna. ![Skala wyrażana jest przez działające procesy, natomiast różnorodność obciążenia wyrażana jest w typach procesów](/images/process-types.png) **W aplikacji 12factor, procesy są typem pierwszoklasowym** Zachowanie tych procesów jest mocno wzorowane na [modelu procesów unixowych dla usług działających w wewnątrz systemu operacyjnego](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Używając tego modelu programista może zaprojektować aplikację by radziła sobie z różnorodnym obciążeniem przez przypisywanie każdej czynności do *typu procesu*. Przykłady to m.in obsługa procesów sieciowych przez HTTP oraz długotrwałe działanie zadań w tle opierających się na procesach roboczych. Mimo tego procesy wciąż mogą się zwielokrotnić przez wątki w środowisku maszyny wirtualnej lub w asynchronicznym modelu wydarzeń, którego implementację możemy znaleźć wśród narzędzi takich jak [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), albo [Node.js](http://nodejs.org/). Należy pamiętać, że pojedyncza maszyna wirtualna może z czasem wymagać coraz więcej zasobów (skala pionowa), dlatego aplikacja musi być również w stanie pracować w oparciu o wiele procesów działających na wielu fizycznych maszynach. Największa zaleta modelu procesów objawia się w momencie skalowania. [Niezależność oraz dzielenie się na podprocesy](./processes) umożliwia proste i bezproblemowe dodawanie wiekszej liczby równolegle działajacych procesów. Tablica typów procesów i liczba procesów nazywana jest ich *formacją*. Procesy aplikacji 12factor [nigdy nie powinny być uruchamiane w tle](http://dustin.github.com/2010/02/28/running-processes.html) i nie mogą zapisywać plików PID. Zamiast tego opierają się na narzędziach systemu operacyjnego: do zarządzania procesami (np. [systemd](https://www.freedesktop.org/wiki/Software/systemd/), do zarządzania rozproszonymi procesami w chmurze, lub [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) w developmencie) do zarządzania [stumieniami wyjściowymi](./logs), do obsługi zatrzymanych procesów, restartu i zakończenia działań zainicjowanych przez użytkownika. content/pt_br/logs.md0000644000175000056700000000464715226251677013401 0ustar0000000000000000## XI. Logs ### Trate logs como fluxos de eventos *Logs* provém visibilidade no comportamento de um app em execução. Em ambientes de servidor eles são comumente escritos num arquivo em disco (um "logfile"); mas este é apenas um formato de saída. Logs são o [fluxo](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) de eventos agregados e ordenados por tempo coletados dos fluxos de saída de todos os processos em execução e serviços de apoio. Logs na sua forma crua são tipicamente um formato de texto com um evento por linha (apesar que pilhas de exceção podem ocupar várias linhas). Logs não tem começos ou términos fixos, mas fluem continuamente enquanto o app estiver operante. **Um app doze-fatores nunca se preocupa com o roteamento ou armazenagem do seu fluxo de saída.** Ele não deve tentar escrever ou gerir arquivos de logs. No lugar, cada processo em execução escreve seu próprio fluxo de evento, sem buffer, para o `stdout`. Durante o desenvolvimento local, o desenvolvedor verá este fluxo no plano de frente do seu terminal para observar o comportamento do app. Em deploys de homologação ou produção, cada fluxo dos processos serão capturados pelo ambiente de execução, colados com todos os demais fluxos do app, e direcionados para um ou mais destinos finais para visualização e arquivamento de longo prazo. Estes destinos de arquivamento não são visíveis ou configuráveis pelo app, e ao invés disso, são completamente geridos pelo ambiente de execução. Roteadores de log open source (tais como [Logplex](https://github.com/heroku/logplex) e [Fluentd](https://github.com/fluent/fluentd)) estão disponíveis para este propósito. O fluxo de evento para um app pode ser direcionado para um arquivo, ou visto em tempo real via `tail` num terminal. Mais significativamente, o fluxo pode ser enviado para um sistema indexador e analisador tal como [Splunk](http://www.splunk.com/), ou um sistema mais genérico de _data warehousing_ como o [Hadoop/Hive](http://hive.apache.org/). Estes sistemas permitem grande poder e flexibilidade para observar o comportamento de um app durante o tempo, incluindo: * Encontrando eventos específicos no passado. * Gráficos em larga escala de tendências (como requisições por minuto) * Notificações ativas de acordo com as heurísticas determinadas pelo usuário (como uma notificação quando a quantidade de erros por minuto exceder um certo limite). content/ru/dev-prod-parity.md0000644000175000056700000002110315226251677014765 0ustar0000000000000000## X. Паритет разработки/работы приложения ### Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими Исторически существуют значительные различия между разработкой (разработчик делает живые изменения на локальном [развёртывании](./codebase) приложения) и работой приложения (развёртывание приложения с доступом к нему конечных пользователей). Эти различия проявляются в трёх областях: * **Различие во времени:** разработчик может работать с кодом, который попадёт в рабочую версию приложения только через дни, недели или даже месяцы. * **Различие персонала**: разработчики пишут код, OPS инженеры разворачивают его. * **Различие инструментов**: разработчики могут использовать стек технологий, такой как Nginx, SQLite, и OS X, в то время как при рабочем развёртывании используются Apache, MySQL и Linux. **Приложение двенадцати факторов спроектировано для [непрерывного развёртывания](http://avc.com/2011/02/continuous-deployment/) благодаря минимизации различий между разработкой и работой приложения. Рассмотрим три различия, описанных выше: * Сделать различие во времени небольшим: разработчик может написать код, и он будет развёрнут через несколько часов или даже минут. * Сделать небольшими различия персонала: разработчик который написал код, активно участвует в его развёртывании и наблюдает за его поведением во время работы приложения. * Сделать различия инструментов небольшими: держать окружение разработки и работы приложения максимально похожими. Резюмируя сказанное выше в таблицу:
    Традиционное приложение Приложение двенадцати факторов
    Время между развёртываниями Недели Часы
    Автор кода/тот кто разворачивает Разные люди Те же люди
    Окружение разработки/работы приложения Различные Максимально похожие
    [Сторонние службы](./backing-services), такие как базы данных, системы очередей сообщений и кэш, являются одной из областей, где паритет при разработке и работе приложения имеет важное значение. Многие языки предоставляют библиотеки, которые упрощают доступ к сторонним службам, включая *адаптеры* для доступа к различных типам сервисов. Некоторые примеры, в таблице ниже.
    Тип Язык Библиотека Адаптеры
    База данных Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
    Очередь сообщений Python/Django Celery RabbitMQ, Beanstalkd, Redis
    Кэш Ruby/Rails ActiveSupport::Cache Память, файловая система, Memcached
    Иногда разработчики находят удобным использовать лёгкие сторонние службы в их локальном окружении, в то время как более серьёзные и надёжные сторонние сервисы будут использованы в рабочем окружении. Например используют SQLite локально и PostgreSQL в рабочем окружении; или память процесса для кэширования при разработке и Memcached в рабочем окружении. **Разработчик приложения двенадцати факторов сопротивляется искушению использовать различные сторонние сервисы при разработке и в рабочем окружении**, даже когда адаптеры теоретически абстрагированы от различий в сторонних сервисах. Различия в используемых сторонних сервисах означают, что может возникнуть крошечная несовместимость, которая станет причиной того, что код, который работал и прошёл тесты при разработке и промежуточном развёртывании не работает в рабочем окружении. Такой тип ошибок создаёт помехи, которые нивелируют преимущества непрерывного развёртывания. Стоимость этих помех и последующего восстановления непрерывного развёртывания является чрезвычайно высокой, если рассматривать в совокупности за всё время существования приложения. Установка локальных сервисов стала менее непреодолимой задачей, чем она когда-то была. Современные сторонние сервисы, такие как Memcached, PostgreSQL и RabbitMQ не трудно установить и запустить благодаря современным менеджерам пакетов, таким как [Homebrew](http://mxcl.github.com/homebrew/) и [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Кроме того, декларативные инструменты подготовки окружения, такие как [Chef](http://www.opscode.com/chef/) и [Puppet](http://docs.puppetlabs.com/) в сочетании с легковесным виртуальным окружением, таким как [Vagrant](http://vagrantup.com/) позволяют разработчикам запустить локальное окружение которое максимально приближено к рабочему окружению. Стоимость установки и использования этих систем ниже по сравнению с выгодой, получаемой от паритета разработки/работы приложения и непрерывного развёртывания. Адаптеры для различных сторонних сервисов по-прежнему полезны, потому что они позволяют портировать приложение для использования новых сторонних сервисов относительно безболезненно. Но все развёртывания приложения (окружение разработчика, промежуточное и рабочее развёртывание) должны использовать тот же тип и ту же версию каждого из сторонних сервисов. content/zh_cn/dependencies.md0000644000175000056700000000413515226251677015046 0ustar0000000000000000## II. 依赖 ### 显式声明依赖关系（ *dependency* ） 大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，就像 Perl 的 [CPAN](http://www.cpan.org/) 或是 Ruby 的 [Rubygems](http://rubygems.org/) 。通过打包系统安装的类库可以是系统级的（称之为 "site packages"），或仅供某个应用程序使用，部署在相应的目录中（称之为 "vendoring" 或 "bunding"）。 **12-Factor规则下的应用程序不会隐式依赖系统级的类库。** 它一定通过 *依赖清单* ，确切地声明所有依赖项。此外，在运行过程中通过 *依赖隔离* 工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。 例如， Ruby 的 [Bundler](https://bundler.io/) 使用 `Gemfile` 作为依赖项声明清单，使用 `bundle exec` 来进行依赖隔离。Python 中则可分别使用两种工具 -- [Pip](http://www.pip-installer.org/en/latest/) 用作依赖声明， [Virtualenv](http://www.virtualenv.org/en/latest/) 用作依赖隔离。甚至 C 语言也有类似工具， [Autoconf](http://www.gnu.org/s/autoconf/) 用作依赖声明，静态链接库用作依赖隔离。无论用什么工具，依赖声明和依赖隔离必须一起使用，否则无法满足 12-Factor 规范。 显式声明依赖的优点之一是为新进开发者简化了环境配置流程。新进开发者可以检出应用程序的基准代码，安装编程语言环境和它对应的依赖管理工具，只需通过一个 *构建命令* 来安装所有的依赖项，即可开始工作。例如，Ruby/Bundler 下使用 `bundle install`，而 Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) 则是 `lein deps`。 12-Factor 应用同样不会隐式依赖某些系统工具，如 ImageMagick 或是`curl`。即使这些工具存在于几乎所有系统，但终究无法保证所有未来的系统都能支持应用顺利运行，或是能够和应用兼容。如果应用必须使用到某些系统工具，那么这些工具应该被包含在应用之中。 content/it/concurrency.md0000644000175000056700000000611215226251677014262 0ustar0000000000000000## VIII. Concorrenza ### Scalare attraverso il process model Ogni software, una volta avviato, è rappresentato da uno o più processi. Le web application in particolare hanno assunto nel tempo una gran varietà di forme e di tipologie di esecuzione, in tal senso. Per esempio, i processi PHP vengono eseguiti come sotto-processi figli di Apache, avviati su richiesta quando necessari in base al volume di richieste. Java invece gestisce le cose nella maniera opposta, tramite un superprocesso unico che usa una grande quantità di risorse sul server (CPU e memoria) dall'avvio, con una concorrenza gestita "internamente" tramite i threads. In entrambi i casi, comunque, i processi non sono esplicitamente visibili allo sviluppatore. ![Il fattore di scale è espresso con un numero di processi dello stesso tipo avviati, la diversità del carico di lavoro, invece, come le varie tipologie di processo.](/images/process-types.png) **In un'applicazione twelve-factor, i processi sono "first class citizen"**. La visione del concetto di processo prende spunto dal [concetto, in unix, dedicato all'esecuzione di demoni di servizi](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Attraverso l'uso di questo modello, lo sviluppatore può realizzare la propria applicazione in modo tale da farle gestire senza problemi diversi livelli di carico di lavoro, assegnando ogni tipo di lavoro a un tipo di processo ben definito. Per esempio, le richieste HTTP possono essere gestite da un web process, mentre dei compiti più lunghi (in background) possono essere gestiti da un altro processo separato. Questo non esclude che un certo processo, individualmente, possa gestire in modo autonomo e interno il multiplexing, tramite threading, all'interno della VM in esecuzione, o magari un modello asincrono o basato su eventi come quello di [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), o [Node.js](http://nodejs.org/). Tuttavia, tutto questo può non bastare: l'applicazione deve essere anche adatta all'esecuzione su più macchine fisiche. Il modello di processo così come presentato rende il massimo quando arriva il momento di scalare. La [natura orizzontalmente partizionabile (e non soggetta a condivisioni) di un "processo twelve-factor"](./processes) permette di gestire la concorrenza in modo semplice e affidabile. L'array dei tipi di processo e il numero di processi presenti per ogni tipo è conosciuto come *process formation* (formazione di processi). I processi di un'app twelve-factor non dovrebbero [essere soggetti a daemonizing](http://dustin.github.com/2010/02/28/running-processes.html), o scrivere file PID. Al contrario, facendo affidamento sul process manager del sistema operativo (come [systemd](https://www.freedesktop.org/wiki/Software/systemd/), un process manager distribuito su piattaforma cloud, o tool come [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) durante lo sviluppo) per gestire [gli stream in output](./logs), rispondere adeguatamente a crash di processi e gestire riavvii e shutdown. public/images/favicon.ico0000644000175000056700000000370515226251677014171 0ustar0000000000000000PNG  IHDR(J< pHYs  wIDATh[e󔙦2#J(5ВAHF*n. ,ˆB+$" 0zQAif5k03/ֻ?3?3{ -bfˎ; 1QeVgkWW K2?&y d7IsCkCLƗee<3_ˎF[O6,`ljQIi}HڸOhm <1 y#ƄŲ0<5v. !2u%'ɸ9lʌ xR^YGJ#Sى?+G6?q5/r_$,NV6M8>Sk A76YķJLy=bwޜ]gwi)^ZC>tnDJbLX3z:ί%8d3'G^z9~W+h8A=^^zz^Ϻ'QҰ%+XƙDt++֨_قTo>}jR'S?@9ۉIG~,)Fpi:}+"CPò[ꫫ$鍨\UOZc2%PnVKDv+HIbթ$^s_ |(v).8~sBX$xԬsݘ_>_R1%"љ]la 8G9grTQy$9qF\wxQ_2i7̋Xi;C dVo䉛ӊ+|VkeV1׉9\~{#2_Zu&>_c)$/192/[/ǿy>c h 1RQm_8d'O ëacD>sL"9.3iy M ~G>s gnJ}ÇFe T?7}s_Oj̃sWBݸ=]zkЊDuh}U2;J$Ndޓn~8 c/ 3y3e~܎꾟PQщ 6Gܓ86Z ]`sw5Z2{djG՘gLqrvoWlتEu}Ena _,rE+2s[kźX_-3ܡ^#Zc+[/:-{8$? oz='QBFV/:^'l,zVTlWdGSy4oR_ZPUY dˌ:Io9}o2 リソースは自由にデプロイにアタッチしたり、デプロイからデタッチしたりできる。例えば、ハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合、アプリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上げる。そして現在の本番データベースをデタッチし、新しいデータベースをアタッチする -- コードを一切変更せずに。 content/ru/admin-processes.md0000644000175000056700000001015715226251677015042 0ustar0000000000000000## XII. Задачи администрирования ### Выполняйте задачи администрирования/управления с помощью разовых процессов [Формирование процессов](./concurrency) является некоторым набором процессов, которые необходимы для выполнения регулярных задач приложения (таких как обработка веб-запросов), когда оно исполняется. В дополнение к этому, разработчикам периодически необходимо выполнять разовые задачи администрирования и обслуживания приложения, такие как: * Запуск миграции базы данных (например `manage.py migrate` в Django, `rake db:migrate` в Rails). * Запуск консоли (также известной как оболочка [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)), чтобы запустить произвольный код или проверить модели приложения с действующей базой данных. Большинство языков предоставляют REPL путём запуска интерпретатора без каких-либо аргументов (например, `python` или `perl`), а в некоторых случаях имеют отдельную команду (например `irb` в Ruby, `rails console` в Rails). * Запуск разовых скриптов, хранящихся в репозитории приложения (например, `php scripts/fix_bad_records.php`). Разовые процессы администрирования следует запускать в среде идентичной регулярным [длительным процессам](./processes) приложения. Они запускаются на уровне [релиза](./build-release-run), используя те же [кодовую базу](./codebase) и [конфигурацию](./config), как и любой другой процесс, выполняющий этот релиз. Код администрирования должен поставляться вместе с кодом приложения, чтобы избежать проблем синхронизации. Те же самые методы [изоляции зависимостей](./dependencies) должны быть использованы для всех типов процессов. Например, если веб-процесс Ruby использует команду `bundle exec thin start`, то для миграции базы данных следует использовать `bundle exec rake db:migrate`. Аналогичным образом для программы на Python с использованием Virtualenv следует использовать поставляемый `bin/python` как для запуска веб-сервера Tornado, так и для запуска любых `manage.py` процессов администрирования. Методология двенадцати факторов отдаёт предпочтение языкам, которые предоставляют REPL оболочки из коробки, и которые позволяют легко выполнять разовые скрипты. В локальном развёртывании разработчики выполняют разовый процесс администрирования с помощью консольной команды внутри каталога с приложением. В рабочем развёртывании разработчики могут использовать ssh или другой механизм выполнения удалённой команды, предоставленный средой выполнения, для запуска такого процесса. content/ja/codebase.md0000644000175000056700000000515615226251677013462 0ustar0000000000000000## I. コードベース ### バージョン管理されている1つのコードベースと複数のデプロイ Twelve-Factor Appは[Git](http://git-scm.com/)や[Mercurial](https://www.mercurial-scm.org/)、[Subversion](http://subversion.apache.org/)などのバージョン管理システムで常に変更を追跡している。リビジョン追跡データベースのコピーは *コードリポジトリ* と言われ、単に *リポジトリ* とも言われる。 *コードベース* は、単一のリポジトリ（Subversionのような集中バージョン管理システムの場合）またはルートコミットを共有する複数のリポジトリ（Gitのような分散バージョン管理システムの場合）である。 ![1つのコードベースは複数のデプロイにマッピングされる](/images/codebase-deploys.png) コードベースとアプリケーションの間には、常に1対1の関係がある。 * もし複数のコードベースがある場合、それはアプリケーションではない -- それは分散システムである。分散システムのそれぞれのコンポーネントがアプリケーションであり、個別にTwelve-Factorに適合することができる。 * 同じコードを共有する複数のアプリケーションは、Twelve-Factorに違反している。その場合の解決策は、共通のコードをライブラリに分解し、そのライブラリを[依存関係管理ツール](./dependencies)で組み込むようにすることである。 アプリケーションごとにただ1つのコードベースが存在するが、アプリケーションのデプロイは複数存在する。 *デプロイ* はアプリケーションの実行中のインスタンスである。これは通常1つの本番サイトと、1つ以上のステージングサイトである。さらにすべての開発者はローカル開発環境で動作するアプリケーションのコピーを持っており、それらもデプロイと見なせる。 デプロイごとに異なるバージョンがアクティブであるかもしれないが、コードベースはすべてのデプロイを通して同一である。例えば、開発者はステージング環境にまだデプロイされていないコミットを抱えているし、ステージング環境には本番環境にデプロイされていないコミットが含まれている。しかし、これらのデプロイはすべて同一のコードベースを共有しているため、同一のアプリケーションの異なるデプロイであると認識できる。 content/tr/dev-prod-parity.md0000644000175000056700000001144515226251677014774 0ustar0000000000000000## X.Geliştirme/Üretim Eşitliği ### Gelişim, evreleme ve üretimi olabildikçe benzer tutma Tarihsel olarak, geliştirme (bir geliştirici uygulamanın yerel [dağıtımına](./codebase) canlı düzenlemeler yapar) ve ürün (uygulamanın çalışan dağıtımı son kullanıcılar tarafından erişilmiştir) arasında önemli aralıklar vardır. Bu aralıklar üç alanda belirtilir: * **Zaman aralığı:** bir geliştirici kod üzerinde günler,haftalar hatta aylar boyunca bile ürünü oluşturmak için çalışabilir. * **Eleman aralığı:** Geliştiriciler kod yazar, ops mühendisleri dağıtır. * **Araçların aralığı:** Geliştiriciler ürün dağıtımı Apache, MySQL ve Linux kullanırken; Nginx, SQLite, ve OS X gibi yığınları kullanıyor olabilir. **On iki faktör uygulaması, geliştirme ve ürün aralığını küçük tutarak, [sürekli dağıtım](http://avc.com/2011/02/continuous-deployment/) için tasarlanmıştır.** Yukarda tanımlanan üç aralığa bakarsak: * Zaman aralığını küçültme: bir geliştirici kod yazabilir ve bu kodu saatler veya hatta dakikalar sonra dağıtmış olabilir. * Eleman aralığını küçültme: kodu yazan geliştiriciler, kodu dağıtmakla yakından ilişkilidir ve üründeki davranışını izler. * Araçların aralığını küçültme: geliştirmeyi ve ürünü olabildiği kadar benzer tut. Üstekileri bir tablo olarak özetlersek:
    Geleneksel uygulama On iki faktör uygulaması
    Dağıtımlar arasındaki zaman Haftalar Saatler
    Kod yazarları ve kod dağıtımcıları Farklı insanlar Aynı insanlar
    Geliştirme ve ürün ortamı Farklı Olabildiğince benzer
    [Destek servisler](./backing-services); uygulamanın veritabanı, kuyruk sistemi veya önbellek gibi, geliştirme/üretim eşitliğinin önemli olduğu bir alandır. Bir çok dil, farklı tipteki servislerin *uyarlayıcılarını* içeren, destek servislerine ulaşımı kolaylaştıran kütüphanleri önerir. Bazı örnekler aşağıdaki tabloda vardır.
    Tip Dil Kütüphane Uyarlayıcı
    Veritabanı Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
    Kuyruk Python/Django Celery RabbitMQ, Beanstalkd, Redis
    Önbellek Ruby/Rails ActiveSupport::Cache Bellek, dosya sistemi, Memcached
    Geliştiriciler, üründe ciddi ve sağlam destek servisleri kullanırken, bazen kendi yerel ortamlarında önemsiz destek servislerini kullanmak için istek duyarlar. Örneğin, yerelde SQLite üründe PostgreSQL kullanılır veya geliştirmede depolama için yerel süreç belleği ve üründe de Memcached kullanılır. **On iki faktör geliştiricisi**, uyarlayıcılar teorik olarak destek servislerindeki herhangi bir farklılığı soyutladığı zaman bile **geliştirme ve ürün arasında faklı destek servisi kullanma isteğine karşı direnir.** Destek hizmetleri arasındaki farklılıklar, küçük uyumsuzlukların ortaya çıkması, kodun işe yaraması ve geliştirme aşamasında testlere geçilmesi veya üretimde başarısız olmaya neden olması anlamına gelir. Bu tür hatalar, sürekli dağıtımın etkisini azaltan bir sürtüşme yaratır. Bu sürtünme maliyeti ve sonraki devamlı dağıtımın azaltılması, bir uygulamanın ömrü süresince toplamda düşünüldüğünde oldukça yüksektir. Önemsiz yerel servisler bir zamanlar olduğundan daha zorlayıcıdır. Memcached, PostgreSQL ve RabbitMQ gibi modern destek servisleri, [Homebrew](http://mxcl.github.com/homebrew/) ve [apt-get](https://help.ubuntu.com/community/AptGet/Howto) gibi modern paket sistemleri sayesinde yüklemesi ve çalıştırılması zor değildir. Alternatif olarak, [Chef](http://www.opscode.com/chef/) ve [Puppet](http://docs.puppetlabs.com/) gibi bildiri sağlayıcı araçlar önemsiz sanal ortamlarla birleşir, [Vagrant](http://vagrantup.com/) gibi, geliştiricilerin yerel ortamda çalışmalarına izin verir, yaklaşık olarak ürün ortamına benzer. Bu sistemlerin yüklenmesi ve kullanımının maliyeti, geliştirme üretim eşitliği ve sürekli dağıtımın faydasıyla karşılaştırıldığında düşüktür. Farklı destek servislerinin uyarlayıcıları hala kullanışlıdır, çünkü yeni destek servislerine bağlanmayı nispeten zahmetsiz yapar. Ama uygulamanın bütün dağıtımları (geliştirme ortamları, evreleme, ürün) her bir destek servisinin aynı tip ve versiyonunu kullanmalıdır. content/uk/concurrency.md0000644000175000056700000001174315226251677014273 0ustar0000000000000000## VIII. Конкурентність ### Масштабуйте застосунок за допомогою процесів Будь-яка комп'ютерна програма після запуску представлена одним або декількома процесами. Веб-додатки мають різні форми виконання процесів. Наприклад, PHP-процеси виконуються як дочірні процеси Apache, які запускаються в разі потреби в залежності від навантаження. Java-процеси використовують протилежний підхід: JVM забезпечує один масивний мета-процес, який резервує велику кількість системних ресурсів (процесора і пам'яті) під час його запуску, і керує конкурентністю всередині себе за допомогою потоків виконання (threads). В обох випадках запущені процеси видимі для розробників застосунку мінімально. ![Масштабування виражається у вигляді запущених процесів, різноманітність навантаження виражається в типах процесів.](/images/process-types.png) **В застосунку дванадцяти факторів, процеси є сутностями першого класу.** Процеси в застосунку дванадцяти факторів взяли сильні сторони від [моделі процесів UNIX для запуску сервісів](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Використовуючи цю модель, розробник може спроектувати свій застосунок таким чином, що для обробки різних робочих навантажень необхідно призначити кожному виду робіт свій *тип процесу*. Наприклад, HTTP-запити можуть бути оброблені за допомогою веб-процесу (web process), а тривалі фонові завдання оброблені робочим процесом (worker process). Це не виключає можливості використання індивідуального мультиплексування для окремих процесів через потоки виконання віртуальної машини або асинхронні/подієві моделі в таких інструментах, як [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) або [Node.js](http://nodejs.org/). Але індивідуальна віртуальна машина може масшабуватися тільки обмежено (вертикальне масшабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів на декількох фізичних машинах. Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування. [Відсутність розділених даних і горизонтальне розділення процесів застосунку дванадцяти факторів](./processes) означає, що додавання більшої конкурентності є простою і надійною операцією. Масив типів процесів і кількість процесів кожного типу називається *формацією процесів*. Процеси застосунку дванадцяти факторів [ніколи не мають демонізуватися](http://dustin.github.com/2010/02/28/running-processes.html) та записувати PID-файли. Замість цього вони мають покладатися на менеджер процесів операційної системи (наприклад, [systemd](https://www.freedesktop.org/wiki/Software/systemd/), розподілений менеджер процесів на хмарній платформі, або в процесі розробки на такий інструмент, як [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)) для керування [потоком виведення](./logs), реагування на падіння процесів і обробку ініційованих користувачем перезавантаження чи завершення роботи. content/uk/toc.md0000644000175000056700000000412115226251677012516 0ustar0000000000000000Дванадцять факторів =================== ## [I. Кодова база](./codebase) ### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань ## [II. Залежності](./dependencies) ### Явно оголошуйте та ізолюйте залежності ## [III. Конфігурація](./config) ### Зберігайте конфігурацію в середовищі виконання ## [IV. Сторонні служби](./backing-services) ### Вважайте сторонні служби (backing services) підключеними ресурсами ## [V. Збірка, реліз, виконання](./build-release-run) ### Суворо відокремлюйте етапи збірки та виконання ## [VI. Процеси](./processes) ### Запускайте застосунок як один або декілька процесів без збереження внутрішньго стану (stateless) ## [VII. Прив'язка портів](./port-binding) ### Експортуйте сервіси за допомогою прив'язки портів (port binding) ## [VIII. Конкурентність](./concurrency) ### Масштабуйте застосунок за допомогою процесів ## [IX. Утилізовуваність](./disposability) ### Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення ## [X. Dev/prod паритет](./dev-prod-parity) ### Прагніть максимальної ідентичності development, staging та production середовищ ## [XI. Журналювання](./logs) ### Сприймайте журналювання (logs) як потоки подій ## [XII. Задачі адміністрування](./admin-processes) ### Виконуйте задачі адміністрування/керування за допомогою разових процесівcontent/en/logs.md0000644000175000056700000000430215226251677012661 0ustar0000000000000000## XI. Logs ### Treat logs as event streams *Logs* provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a "logfile"); but this is only an output format. Logs are the [stream](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) of aggregated, time-ordered events collected from the output streams of all running processes and backing services. Logs in their raw form are typically a text format with one event per line (though backtraces from exceptions may span multiple lines). Logs have no fixed beginning or end, but flow continuously as long as the app is operating. **A twelve-factor app never concerns itself with routing or storage of its output stream.** It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to `stdout`. During local development, the developer will view this stream in the foreground of their terminal to observe the app's behavior. In staging or production deploys, each process' stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment. Open-source log routers (such as [Logplex](https://github.com/heroku/logplex) and [Fluentd](https://github.com/fluent/fluentd)) are available for this purpose. The event stream for an app can be routed to a file, or watched via realtime tail in a terminal. Most significantly, the stream can be sent to a log indexing and analysis system such as [Splunk](http://www.splunk.com/), or a general-purpose data warehousing system such as [Hadoop/Hive](http://hive.apache.org/). These systems allow for great power and flexibility for introspecting an app's behavior over time, including: * Finding specific events in the past. * Large-scale graphing of trends (such as requests per minute). * Active alerting according to user-defined heuristics (such as an alert when the quantity of errors per minute exceeds a certain threshold). content/es/intro.md0000644000175000056700000000227315226251677013062 0ustar0000000000000000Introducción ============ En estos tiempos, el software se está distribuyendo como un servicio: se le denomina *web apps*, o *software as a service* (SaaS). "The twelve-factor app" es una metodología para construir aplicaciones SaaS que: * Usan formatos **declarativos** para la automatización de la configuración, para minimizar el tiempo y el coste que supone que nuevos desarrolladores se unan al proyecto; * Tienen un **contrato claro** con el sistema operativo sobre el que trabajan, ofreciendo la **máxima portabilidad** entre los diferentes entornos de ejecución; * Son apropiadas para **desplegarse** en modernas **plataformas en la nube**, obviando la necesidad de servidores y administración de sistemas; * **Minimizan las diferencias** entre los entornos de desarrollo y producción, posibilitando un **despliegue continuo** para conseguir la máxima agilidad; * Y pueden **escalar** sin cambios significativos para las herramientas, la arquitectura o las prácticas de desarrollo. La metodología "twelve-factor" puede ser aplicada a aplicaciones escritas en cualquier lenguaje de programación, y cualquier combinación de 'backing services' (bases de datos, colas, memoria cache, etc). Gemfile0000644000175000056700000000033715226251677010616 0ustar0000000000000000source 'http://rubygems.org' ruby '>=3.2' gem 'sinatra', '>=2.2.0' gem 'thin', '>=1.8.1' gem 'maruku' gem 'i18n' gem 'rexml' gem 'rack-ssl-enforcer' gem "rackup", "~> 2.2" gem "puma", "~> 6.6" gem "ostruct", "~> 0.6.2" content/de/intro.md0000644000175000056700000000215115226251677013036 0ustar0000000000000000Einführung ============ Heute wird Software oft als Dienst geliefert - auch *Web App* oder *Software-As-A-Service* genannt. Die Zwölf-Faktoren-App ist eine Methode um Software-As-A-Service Apps zu bauen die: * **deklarative** Formate benutzen für die Automatisierung der Konfiguration, um Zeit und Kosten für neue Entwickler im Projekt zu minimieren; * einen **sauberen Vertrag** mit dem zugrundeliegenden Betriebssystem haben, **maximale Portierbarkeit** zwischen Ausführungsumgebungen bieten; * sich für das **Deployment** auf modernen **Cloud-Plattformen** eignen, die Notwendigkeit von Servern und Serveradministration vermeiden; * die **Abweichung minimieren** zwischen Entwicklung und Produktion, um **Continuous Deployment** für maximale Agilität ermöglichen; * und **skalieren** können ohne wesentliche Änderungen im Tooling, in der Architektur oder in den Entwicklungsverfahren. Die Zwölf-Faktoren-Methode kann auf Apps angewendet werden, die in einer beliebigen Programmiersprache geschrieben sind, und die eine beliebige Kombination von unterstützenden Diensten benutzen (Datenbank, Queue, Cache, ...) content/pt_br/processes.md0000644000175000056700000000535015226251677014433 0ustar0000000000000000## VI. Processos ### Execute a aplicação como um ou mais processos que não armazenam estado A aplicação é executada em um ambiente de execução como um ou mais *processos*. No caso mais simples, o código é um script autônomo, o ambiente de execução é o laptop local de um desenvolvedor com o runtime da linguagem instalado, e o processo é iniciado pela linha de comando (por exemplo, `python my_script`). Na outra extremidade do espectro, o deploy em produção de uma aplicação sofisticada pode utilizar vários [tipos de processos, instanciado em zero ou mais processos em andamento](./concurrency). **Processos doze-fatores são stateless(não armazenam estado) e [share-nothing](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Quaisquer dados que precise persistir deve ser armazenado em um serviço de apoio stateful(que armazena o seu estado), tipicamente uma base de dados. O espaço de memória ou sistema de arquivos do processo pode ser usado como um breve, cache de transação única. Por exemplo, o download de um arquivo grande, operando sobre ele, e armazenando os resultados da operação no banco de dados. A aplicação doze-fatores nunca assume que qualquer coisa cacheada na memória ou no disco estará disponível em uma futura solicitação ou job -- com muitos processos de cada tipo rodando, as chances são altas de que uma futura solicitação será servida por um processo diferente. Mesmo quando rodando em apenas um processo, um restart (desencadeado pelo deploy de um código, mudança de configuração, ou o ambiente de execução realocando o processo para uma localização física diferente) geralmente vai acabar com todo o estado local (por exemplo, memória e sistema de arquivos). Empacotadores de assets (como [Jammit](http://documentcloud.github.com/jammit/) ou [django-compressor](http://django-compressor.readthedocs.org/)) usa o sistema de arquivos como um cache para assets compilados. Uma aplicação doze-fatores prefere fazer isto compilando durante a [fase de build](./build-release-run), tal como o [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html), do que em tempo de execução. Alguns sistemas web dependem de ["sessões persistentes"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- ou seja, fazem cache dos dados da sessão do usuário na memória do processo da aplicação, esperando futuras requisições do mesmo visitante para serem encaminhadas para o mesmo processo. Sessões persistentes são uma violação do doze-fatores e nunca devem ser utilizadas ou invocadas. Dados do estado da sessão são bons candidatos para um datastore que oferece tempo de expiração, tal como [Memcached](http://memcached.org/) ou [Redis](http://redis.io/). content/zh_cn/port-binding.md0000644000175000056700000000327015226251677015013 0ustar0000000000000000## VII. 端口绑定 ### 通过端口绑定(*Port binding*)来提供服务 互联网应用有时会运行于服务器的容器之中。例如 PHP 经常作为 [Apache HTTPD](http://httpd.apache.org/) 的一个模块来运行，正如 Java 运行于 [Tomcat](http://tomcat.apache.org/) 。 **12-Factor 应用完全自我加载** 而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用 **通过端口绑定来提供服务** ，并监听发送至该端口的请求。 本地环境中，开发人员通过类似`http://localhost:5000/`的地址来访问服务。在线上环境中，请求统一发送至公共域名而后路由至绑定了端口的网络进程。 通常的实现思路是，将网络服务器类库通过 [依赖声明](./dependencies) 载入应用。例如，Python 的 [Tornado](http://www.tornadoweb.org/), Ruby 的[Thin](http://code.macournoyer.com/thin/) , Java 以及其他基于 JVM 语言的 [Jetty](http://www.eclipse.org/jetty/)。完全由 *用户端* ，确切的说应该是应用的代码，发起请求。和运行环境约定好绑定的端口即可处理这些请求。 HTTP 并不是唯一一个可以由端口绑定提供的服务。其实几乎所有服务器软件都可以通过进程绑定端口来等待请求。例如，使用 [XMPP](http://xmpp.org/) 的 [ejabberd](http://www.ejabberd.im/) ， 以及使用 [Redis 协议](http://redis.io/topics/protocol) 的 [Redis](http://redis.io/) 。 还要指出的是，端口绑定这种方式也意味着一个应用可以成为另外一个应用的 [后端服务](./backing-services) ，调用方将服务方提供的相应 URL 当作资源存入 [配置](./config) 以备将来调用。 content/es/concurrency.md0000644000175000056700000000631715226251677014264 0ustar0000000000000000## VIII. Concurrencia ### Escalar mediante el modelo de procesos Todo programa de ordenador, al ejecutarse, se encuentra representado en memoria por uno o más procesos. Las aplicaciones web se pueden ejecutar de diferentes formas desde el punto de vista del modelo de procesos que usan. Por ejemplo, los procesos PHP se ejecutan como procesos pesados (o simplemente procesos), hijos del proceso Apache, creándolos bajo demanda a causa de la cantidad de peticiones si es necesario. Los procesos Java funcionan de forma distinta, la Máquina Virtual de Java (JVM) proporciona un conjunto de procesos que reservan al principio una gran cantidad de recursos del sistema (CPU y memoria), gestionando la concurrencia internamente mediante procesos ligeros (threads). En ambos casos, los procesos en ejecución son prácticamente transparentes para los desarrolladores de la aplicación. ![La escalabilidad está representada por el número de procesos en ejecución, mientras que la diversidad de carga de trabajo lo está por los tipos de procesos.](/images/process-types.png) **En las aplicaciones "twelve-factor", los procesos son ciudadanos de primera clase.** Los procesos de las aplicaciones "twelve-factor" se inspiran en [el modelo de procesos de unix para ejecutar demonios](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Usando este modelo, el desarrollador puede distribuir la ejecución de su aplicación para gestionar diversas cargas de trabajo asignando cada tipo de trabajo a un *tipo de proceso*. Por ejemplo, las peticiones HTTP se pueden procesar con un proceso y las tareas con mucha carga de trabajo con hilos. Esto no exime a los procesos de gestionar su propia división interna mediante threads en la ejecución de la máquina virtual o mediante un modelo asíncrono o por eventos con herramientas como [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), o [Node.js](http://nodejs.org/). No obstante, una máquina virtual aislada tiene una capacidad de crecimiento limitada, así que la aplicación debe ser capaz de dividirse en multiples procesos que se puedan ejecutar en múltiples máquinas físicas. El modelo de procesos muestra todo su potencial cuando llega el momento de escalar. La [naturaleza "share-nothing", divide horizontalmente los procesos de las aplicaciones "twelve-factor"](./processes) y se traduce en un aumento de la concurrencia como una operación simple y fiable. El conjunto de tipos de procesos y el número de procesos de cada tipo es conocido como *juego de procesos*. Los procesos de las aplicaciones "twelve-factor" [nunca deberían ser demonios](http://dustin.github.com/2010/02/28/running-processes.html) ni escribir ficheros de tipo PID. En su lugar, se debería confiar en un gestor de procesos del sistema operativo (como [systemd](https://www.freedesktop.org/wiki/Software/systemd/), un gestor de procesos distribuido en una plataforma en la nube, o una herramienta como [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) en desarrollo) para gestionar [los historiales](./logs), responder a procesos que terminen inesperadamente, y gestionar los reinicios y apagados provocados por los usuarios. content/fr/build-release-run.md0000644000175000056700000000614715226251677015252 0ustar0000000000000000## V. Assemblez, publiez, exécutez ### Séparez strictement les étapes d'assemblage et d'exécution Une [base de code](./codebase) est transformée en un déploiement (non-développement) à travers les étapes suivantes : * L'*étape d'assemblage* (ou "build") est une transformation qui convertit un dépôt de code en un paquet autonome exécutable appelé l'assemblage (ou "build"). En utilisant une version du code référencée par un commit spécifié lors du processus de déploiement, l'étape d'assemblage va chercher toutes les [dépendances externes](./dependencies) et compile les fichiers binaires et les ressources. * L'*étape de publication * (ou "release") prend l'assemblage produit à l'étape précédente et le combine avec la [configuration](./config) de déploiement courante. La release résultante contient à la fois l'assemblage et la configuration, et elle est prête pour une exécution immédiate dans l'environnement d'exécution. * L'*étape d'exécution* (ou "runtime") fait fonctionner l'application dans l'environnement d'exécution, en lançant un ensemble de [processus](./processes) de l'application associée à la release considérée. ![Le code devient un assemblage, qui est combiné à la configuration pour créer une release](/images/release.png) **Les applications 12 facteurs ont une séparation stricte entre les étapes d'assemblage, de publication et d'exécution.** Par exemple, il est impossible de faire des changements dans le code au moment de son exécution, car il n'y a pas moyen de propager ces changements vers l'étape de build. Les outils de déploiement offrent généralement des outils de gestion de release, permettant notamment de revenir à une release antérieure. Par exemple, l'outil de déploiement [Capistrano](https://github.com/capistrano/capistrano/wiki) stocke les releases dans un sous-répertoire appelé `releases`, où la release courante est un lien symbolique vers le répertoire de release courante. Sa commande `rollback` permet de facilement revenir à une release précédente. Chaque release devrait toujours avoir un identifiant unique, comme un horodatage (timestamp) de la release (tel que `2011-04-06-20:32:17`) ou un nombre incrémental (tel que `v100`). La liste des releases est accessible en écriture incrémentale uniquement, et il n'est pas possible de modifier une release une fois qu'elle a été réalisée. Tout changement doit créer une nouvelle release. Les assemblages sont initiés par le développeur de l'application dès que du nouveau code est déployé. Son exécution, au contraire, peut avoir lieu automatiquement en cas d'un reboot du serveur, ou du crash d'un processus qui est relancé par le gestionnaire de processus. De ce fait, l'étape d'exécution doit se limiter à un nombre minimal de parties mobiles, car les problèmes qui empêchent une application de fonctionner peuvent entraîner des dysfonctionnements au milieu de la nuit alors qu'aucun développeur ne sera là pour les corriger. L'étape d'assemblage peut être plus complexe, car les erreurs pourront toujours être résolues par le développeur qui réalise le déploiement. content/fr/codebase.md0000644000175000056700000000453115226251677013473 0ustar0000000000000000## I. Base de code ### Une base de code suivie avec un système de contrôle de version, plusieurs déploiements Une application 12 facteurs est toujours suivie dans un système de contrôle de version, tel que [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), ou [Subversion](http://subversion.apache.org/). Une copie de la base de données de suivi des révisions est appelée *dépôt de code*, souvent raccourci en *dépôt*. Le terme anglais *code repository*, raccourci en *repository* et *repo* est également utilisé. Une *base de code* correspond à chaque dépôt (dans un système de contrôle de version centralisé tel que Subversion), ou tout ensemble de dépôts qui partage un commit racine (dans un système de contrôle de version décentralisé comme Git). ![Une base de code est associée à plusieurs déploiements](/images/codebase-deploys.png) Il y a toujours un rapport direct entre la base de code et l'application : * S'il y a plusieurs bases de code, ce n'est pas une application, c'est un système distribué. Chaque composant du système distribué est une application, et chacun peut individuellement respecter la méthodologie 12 facteurs. * Plusieurs applications partageant le même code est une violation des 12 facteurs. La solution dans ce cas est de factoriser le code partagé dans des bibliothèques qui peuvent être intégrées via un [gestionnaire de dépendances](./dependencies). Il y a seulement une base de code par application, mais il y aura plusieurs déploiements de l'application. Un *déploiement* est une instance en fonctionnement de l'application. C'est, par exemple, le site en production, ou bien un ou plusieurs sites de validation. En plus de cela, chaque développeur a une copie de l'application qui fonctionne dans son environnement local de développement, ce qui compte également comme un déploiement. La base de code est la même à travers tous les déploiements, bien que différentes versions puissent être actives dans chaque déploiement. Par exemple, un développeur a des commits qui ne sont pas encore déployés dans l'environnement de validation. L'environnement de validation a des commits qui ne sont pas encore déployés en production. Par contre, ils partagent tous la même base de code, ce qui les identifie comme étant des déploiements différents d'une même application. content/pl/backing-services.md0000644000175000056700000000546215226251677015155 0ustar0000000000000000## IV. Usługi wspierające ### Traktuj usługi wspierające jako przydzielone zasoby Usługą wspierającą jest każda, z której aplikacja korzysta przez sieć jako część normalnego działania. Zaliczamy do nich np. magazyny danych (takie jak [MySQL](http://dev.mysql.com/) albo [CouchDB](http://couchdb.apache.org/)), systemy wysyłania/kolejkowania wiadomości (takie jak [RabbitMQ](http://www.rabbitmq.com/) czy [Beanstalkd](https://beanstalkd.github.io)), usługi SMTP do zewnętrznej wysyłki emaili (np. [Postfix](http://www.postfix.org/)) oraz systemy cachowania pamięci (np. [Memcached](http://memcached.org/)). Usługa wspierająca taka jak baza danych jest zazwyczaj zarządzana przez tych samych programistów, którzy zajmują się wdrażaniem aplikacji. Dodatkowo aplikacja może również korzystać z usług oferowanych przez osoby trzecie. Do przykładów zaliczają się usługi SMTP ([Postmark](http://postmarkapp.com/)),usługi zbierające metryki ([New Relic](http://newrelic.com/) czy [Loggly](http://www.loggly.com/)), usługi przechowywania danych (takie jak [Amazon S3](http://aws.amazon.com/s3/)), czy również usługi dostępne przez publiczne API (jak np. [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), lub [Last.fm](http://www.last.fm/api)). **Aplikacje 12factor nie rozróżniają usług lokalnych od zewnętrznych.** Dla aplikacji wszystkie są załączonymi zasobami, dostepnymi przez adres URL lub inny standard zdefiniowany w [konfiguracji](./config). Przy [wdrożeniu](./codebase) aplikacji nie może być problemów ze zmianą lokalnej bazy MySQL na oferowaną przez zewnętrznego usługodawcę (np. [Amazon RDS](http://aws.amazon.com/rds/)) bez żadnych zmian w kodzie aplikacji. Podobnie lokalny serwer SMTP może być zamieniony na zewnętrzną usługę SMTP (taką jak Postmark) bez zmian kodu. W obu przypadkach zmiana powinna wystąpić jedynie w konfiguracji aplikacji. Każda usługa jest traktowana jako *zasób*. Zasobem będzie np. baza MySQL; dwie bazy danych (używane do [shardingu](https://en.wikipedia.org/wiki/Shard_(database_architecture)) w warstwie aplikacji) kwalifikują się jako dwa odrębne zasoby. Aplikacja 12factor traktuje te bazy danych jako *załączone zasoby*, co wskazuje, że nie są z nią trwale powiązane. Produkcyjne wdrożenie aplikacji korzystajace z czterech usług wspierających. Zasoby mogą być dołączane i odłączane jeśli zajdzie taka potrzeba. W momencie gdy baza danych aplikacji z powodu usterek sprzętowych nie działa poprawnie, administrator może przełączyć bazę danych aplikacji na nowy serwer odtworzoną z ostatniego zapisu przywracania danych. Obecna produkcyjna baza może więc zostać przełączona bez żadnych zmian w kodzie aplikacji. content/th/concurrency.md0000644000175000056700000001025115226251677014260 0ustar0000000000000000## VIII. Concurrency ### ขยายออกของแอพพลิเคชันด้วยรูปแบบ process โปรแกรมคอมพิวเตอร์ใดๆ เมื่อทำงานแล้วจะถูกแทนที่ด้วย 1 หรือมากกว่า process เว็บแอพมีหลายรูปแบบของ process-execution ตัวอย่างเช่น PHP process ทำงานเป็น process ลูกของ Apache, เริ่มต้นตามความต้องการตามปริมาณคำขอ, Java process มีวิธีที่ตรงกันข้ามซึ่ง JVM จะใช้หนึ่ง uberprocess ขนาดใหญ่ที่สงวนบล็อกขนาดใหญ่สำหรับทรัพยากรระบบ (CPU และหน่วยความจำ) ในตอนเริ่มต้น ซึ่งจัดการ concurrency ภายในด้วย thread ทั้งสองกรณี process ที่ทำงานเป็นส่วนที่มองเห็นน้อยมากสำหรับ developer ของ app ![Scale is expressed as running processes, workload diversity is expressed as process types.](/images/process-types.png) **ใน twelve-factor app, process เป็นพลเมืองชั้นหนึ่ง** Process ใน twelve-factor app จะใช้คำแนะนำจาก [the unix process model for running service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/) การใช้รูปแบบนี้ developer สามารถออกแบบ app เพื่อจัดการกับ workload ที่หลากหลายโดยการกำหนดให้ work แต่ละชนิดเป็น *process type** ตัวอย่างเช่น HTTP request อาจจะจัดการด้วย web process และ long-running background tasks จัดการด้วย worker process ไม่รวม process ย่อยจากการจัดการ multiplexing ภายใน ด้วย thread ข้างใน runtim VM หรือ async/evnted model ที่พบในเครื่องมือเช่น [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) หรือ [Node.js](http://nodejs.org/) แต่ VM แต่ละตัวสามารถเติบโตได้มากเท่านั้น (การขยายแนวตั้ง) ดังนั้น application จำเป็นต้องสามารถขยายเป็นหลาย process ทำงานบนหลายเครื่องได้ รูปแบบ process ดีมากเมือมากับ time to scale out [share-nothing, horizontally partitionable nature of twelve-factor app processes](./processes) หมายความว่าเพิ่ม concurrency ได้ง่ายและทำงานได้น่าเชื่อถือ อาเรย์ชนิดของ process และจำนวนของ process ของแต่ละชนิด รู้จักกันใน *process formation* Process ของ twelve-factor app [should never daemonize](http://dustin.github.com/2010/02/28/running-processes.html) หรือเขียนไฟล์ PID แต่จะขึ้นอยู่กับตัวจัดการ process ของระบบปฏิบัติการแทน (เช่น [systemd](https://www.freedesktop.org/wiki/Software/systemd/), ตัวจัดการ process กระจายบน cloud platform หรือเครื่องมือ อย่างเช่น [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) ใน development) เพื่อจัดการ [output streams](./logs) ตอบสนองต่อ process ที่ล้มเหลว และจัดการ user-initiated restarts และ shutdowns content/es/logs.md0000644000175000056700000000523715226251677012676 0ustar0000000000000000## XI. Historiales ### Tratar los historiales como una transmisión de eventos Los *historiales* permiten observar el comportamiento de la aplicación durante su ejecución. En entornos basados en servidores es muy común escribir un fichero en disco (un "fichero de histórico") pero este, es tan solo un posible formato de salida. Los historiales son la [transmisión](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) de un conjunto de eventos ordenados y capturados de la salida de todos los procesos en ejecución y de los "backing services". En bruto, los historiales suelen estar en formato texto y tienen un evento por línea (aunque las trazas de excepciones suelen estar en varias líneas). Los historiales no tienen un principio y un final fijo, sino que fluyen continuamente mientras la aplicación está en funcionamiento. **Una aplicación "twelve-factor" nunca se preocupa del direccionamiento o el almacenamiento de sus transmisiones de salida.** No debería intentar escribir o gestionar ficheros de historial. En su lugar, cada proceso en ejecución escribe sus eventos a la `salida estándar` (o `stdout`). Durante el desarrollo, los desarrolladores verán el flujo en su terminal para observar el comportamiento de la aplicación. En despliegues de preproducción y producción, cada transmisión del proceso será capturada por el entorno de ejecución, siendo capturadas junto con todos los otros flujos de la aplicación, y redirigidas a uno o más destinos finales para ser revisadas y archivadas. Estos destinos donde se archivan no son visibles o configurables por la aplicación, se gestionan totalmente por el entorno de ejecución. Las herramientas de código abierto que capturan y almacenan los historiales (como [Logplex](https://github.com/heroku/logplex) y [Fluentd](https://github.com/fluent/fluentd)) se usan con este objetivo. Las transmisiones de eventos para una aplicación pueden ser redirigidas a un fichero u observadas en tiempo real mediante un "tail" en un terminal. Cabe destacar que la transmisión se puede enviar a un sistema de análisis e indexado como [Splunk](http://www.splunk.com/), o a un sistema de almacenamiendo de datos de propósito general como [Hadoop/Hive](http://hive.apache.org/). Estos sistemas se tienen en cuenta por el gran poder y la flexibilidad para inspeccionar el comportamiento de la aplicación a lo largo del tiempo, incluyendo: * Encontrar eventos específicos del pasado. * Gráficas de tendencia a gran escala (como las peticiones por minuto). * Activación de alertas de acuerdo con heurísticas definidas por el usuario (como una alerta cuando la cantidad de errores por minuto sobrepasa un cierto límite). content/ko/backing-services.md0000644000175000056700000000622015226251677015144 0ustar0000000000000000## IV. 백엔드 서비스 ### 백엔드 서비스를 연결된 리소스로 취급 *백엔드 서비스*는 애플리케이션 정상 동작 중 네트워크를 통해 이용하는 모든 서비스입니다. 예를 들어, 데이터 저장소(예: [MySQL](http://dev.mysql.com/), [CouchDB](http://couchdb.apache.org/)), 메시지 큐잉 시스템(예: [RabbitMQ](http://www.rabbitmq.com/), [Beanstalkd](https://beanstalkd.github.io)), 메일을 보내기 위한 SMTP 서비스 (예: [Postfix](http://www.postfix.org/)), 캐시 시스템(예: [Memcached](http://memcached.org/)) 등이 있습니다. 데이터베이스와 같은 백엔드 서비스들은 통상적으로 배포된 애플리케이션과 같은 시스템 관리자에 의해서 관리되고 있었습니다. 애플리케이션은 이런 로컬에서 관리하는 서비스 대신, 서드파티에 의해서 제공되고 관리되는 서비스를 이용할 수 있습니다. 예를 들어, SMTP 서비스 (예: [Postmark](http://postmarkapp.com/)), 지표 수집 서비스 (예: [New Relic](http://newrelic.com/), [Loggly](http://www.loggly.com/)), 스토리지 서비스 (예: [Amazon S3](http://aws.amazon.com/s3/)), API로 접근 가능한 소비자 서비스 (예: [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), [Last.fm](http://www.last.fm/api))등이 있습니다. **Twelve-Factor App의 코드는 로컬 서비스와 서드파티 서비스를 구별하지 않습니다.** 애플리케이션에게는 양 쪽 모두 연결된 리소스이며, [설정](./config)에 있는 URL 혹은 다른 로케이터와 인증 정보를 사용해서 접근 됩니다. Twelve-Factor App의 [배포](./codebase)는 애플리케이션 코드를 수정하지 않고 로컬에서 관리되는 MySQL DB를 서드파티에서 관리되는 DB(예: [Amazon RDS](http://aws.amazon.com/rds/))로 전환할 수 있어야 합니다. 마찬가지로, 로컬 SMTP 서버는 서드파티 SMTP 서비스(예: Postmark)로 코드 수정 없이 전환이 가능해야 합니다. 두 경우 모두 설정에 있는 리소스 핸들만 변경하면 됩니다. 각각의 다른 백엔드 서비스는 *리소스*입니다. 예를 들어, 하나의 MySQL DB는 하나의 리소스입니다. 애플리케이션 레이어에서 샤딩을 하는 두 개의 MySQL 데이터베이스는 두 개의 서로 다른 리소스라고 볼 수 있습니다. Twelve-Factor App은 이러한 데이터베이스들을 *첨부된(Attached) 리소스*으로 다룹니다. 이는 서로 느슨하게 결합된다는 점을 암시합니다. 4개의 백엔드 서비스가 연결된 production 배포. 리소스는 자유롭게 배포에 연결되거나 분리될 수 있습니다. 예를 들어, 애플리케이션의 데이터베이스가 하드웨어 이슈로 작용이 이상한 경우, 애플리케이션의 관리자는 최신 백업에서 새로운 데이터베이스 서버를 시작시킬 것입니다. 그리고 코드를 전혀 수정하지 않고 현재 운영에 사용하고 있는 데이터베이스를 분리하고 새로운 데이터베이스를 연결할 수 있습니다. content/ru/dependencies.md0000644000175000056700000001144315226251677014373 0ustar0000000000000000## II. Зависимости ### Явно объявляйте и изолируйте зависимости Большинство языков программирования поставляются вместе с менеджером пакетов для распространения библиотек, таким как [CPAN](http://www.cpan.org/) в Perl или [Rubygems](http://rubygems.org/) в Ruby. Библиотеки, устанавливаемые менеджером пакетов, могут быть установлены доступными для всей системы (так называемые "системные пакеты") или доступными только приложению в директорию содержащую приложение (так называемые "vendoring" и "bundling"). **Приложение двенадцати факторов никогда не зависит от неявно существующих, доступных всей системе пакетов.** Приложение объявляет все свои зависимости полностью и точно с помощью манифеста *декларации зависимостей*. Кроме того, оно использует инструмент *изоляции зависимостей* во время выполнения для обеспечения того, что неявные зависимости не "просочились" из окружающей системы. Полная и явная спецификация зависимостей применяется равным образом как при разработке, так и при работе приложения. Например, [Bundler](https://bundler.io/) в Ruby использует `Gemfile` как формат манифеста для объявления зависимостей и `bundle exec` -- для изоляции зависимостей. Python имеет два различных инструмента для этих задач: [Pip](http://www.pip-installer.org/en/latest/) используется для объявления и [Virtualenv](http://www.virtualenv.org/en/latest/) -- для изоляции. Даже C имеет [Autoconf](http://www.gnu.org/s/autoconf/) для объявления зависимостей, и статическое связывание может обеспечить изоляцию зависимостей. Независимо от того, какой набор инструментов используется, объявление и изоляция зависимостей должны всегда использоваться совместно -- только одного из них недостаточно, чтобы удовлетворить двенадцати факторам. Одним из преимуществ явного объявления зависимостей является то, что это упрощает настройку приложения для новых разработчиков. Новый разработчик может скопировать кодовую базу приложения на свою машину, необходимыми требованиями для которой являются только наличие среды выполнения языка и менеджера пакетов. Всё необходимое для запуска кода приложения может быть настроено с помощью определённой *команды настройки*. Например, для Ruby/Bundler командой настройки является `bundle install`, для Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) это `lein deps`. Приложение двенадцати факторов также не полагается на неявное существование любых инструментов системы. Примером является запуск программ ImageMagick и `curl`. Хотя эти инструменты могут присутствовать во многих или даже в большинстве систем, нет никакой гарантии, что они будут присутствовать на всех системах, где приложение может работать в будущем, или будет ли версия найденная в другой системе совместима с приложением. Если приложению необходимо запустить инструмент системы, то этот инструмент должен быть включён в приложение. content/es/toc.md0000644000175000056700000000257015226251677012514 0ustar0000000000000000Twelve Factors ============== ## [I. Código base (Codebase)](./codebase) ### Un código base sobre el que hacer el control de versiones y multiples despliegues ## [II. Dependencias](./dependencies) ### Declarar y aislar explícitamente las dependencias ## [III. Configuraciones](./config) ### Guardar la configuración en el entorno ## [IV. Backing services](./backing-services) ### Tratar a los "backing services" como recursos conectables ## [V. Construir, desplegar, ejecutar](./build-release-run) ### Separar completamente la etapa de construcción de la etapa de ejecución ## [VI. Procesos](./processes) ### Ejecutar la aplicación como uno o más procesos sin estado ## [VII. Asignación de puertos](./port-binding) ### Publicar servicios mediante asignación de puertos ## [VIII. Concurrencia](./concurrency) ### Escalar mediante el modelo de procesos ## [IX. Desechabilidad](./disposability) ### Hacer el sistema más robusto intentando conseguir inicios rápidos y finalizaciones seguras ## [X. Paridad en desarrollo y producción](./dev-prod-parity) ### Mantener desarrollo, preproducción y producción tan parecidos como sea posible ## [XI. Historiales](./logs) ### Tratar los historiales como una transmisión de eventos ## [XII. Administración de procesos](./admin-processes) ### Ejecutar las tareas de gestión/administración como procesos que solo se ejecutan una vez content/fr/backing-services.md0000644000175000056700000000626415226251677015152 0ustar0000000000000000## IV. Services externes ### Traitez les services externes comme des ressources attachées Un *service externe* (backing service) correspond à tout service que l'application utilise à travers le réseau pour son fonctionnement nominal. Cela concerne par exemple les bases de données (tel que [MySQL](http://dev.mysql.com/) ou [CouchDB](http://couchdb.apache.org/)), les systèmes de messages/files (tel que [RabbitMQ](http://www.rabbitmq.com/) ou [Beanstalkd](https://beanstalkd.github.io)), les services SMTP pour l'envoi d'email (comme [Postfix](http://www.postfix.org/)), ainsi que les systèmes de cache (comme [Memcached](http://memcached.org/)). Les *services externes* comme la base de données sont le plus souvent gérés par les mêmes administrateurs réseau que ceux qui gèrent l'application de production. En plus de ces services gérés localement, l'application peut également avoir besoin de services gérés par des tiers. Cela concerne par exemple les services SMTP (comme [Postmark](http://postmarkapp.com/)), les services de gestion de métriques (comme [New Relic](http://newrelic.com/) ou [Loggly](http://www.loggly.com/)), les services de ressources binaires (comme [Amazon S3](http://aws.amazon.com/s3/)), et même les services que l'on peut consommer à travers une API (comme [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), ou [Last.fm](http://www.last.fm/api)). **Le code d'une application 12 facteurs ne fait pas de distinction entre les services locaux et les services tiers**. Pour l'application, ce sont tous les deux des ressources attachées, accessibles via une URL ou un autre système de localisation et d'authentification stockée dans la [configuration](./config). Un [déploiement](./codebase) d'une application 12 facteurs doit pouvoir remplacer une base de données MySQL locale par une autre gérée par des tiers ([Amazon RDS](http://aws.amazon.com/rds/), par exemple) sans le moindre changement dans le code de l'application. De la même manière, un serveur SMTP local doit pouvoir être remplacé par un service tiers (Postmark, par exemple) sans changements dans le code. Dans les deux cas, seules les informations de configurations doivent changer. Chaque service externe est une *ressource*. Par exemple, une base de données MySQL est une ressource. Deux bases de données MySQL (utilisées pour faire du sharding dans la couche applicative) correspondent à deux ressources distinctes. L'application 12 facteurs traite ces bases de données comme des ressources attachées, ce qui indique leur couplage faible au déploiement auquel elles sont rattachées. Un déploiement de production lié à quatre services externes. Les ressources peuvent être attachées et détachées à volonté à des déploiements. Par exemple, si la base de données de l'application pose problème pour des raisons matérielles, l'administrateur de l'application peut vouloir lancer un nouveau serveur de base de données restauré à partir d'une sauvegarde récente. L'application courante pourrait être détachée de l'ancienne, puis rattachée à la nouvelle — le tout sans changement dans le code. content/ja/intro.md0000644000175000056700000000256115226251677013045 0ustar0000000000000000はじめに ============ 現代では、ソフトウェアは一般にサービスとして提供され、*Webアプリケーション* や *Software as a Service* と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 * セットアップ自動化のために **宣言的な** フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 * 下層のOSへの **依存関係を明確化** し、実行環境間での **移植性を最大化** する。 * モダンな **クラウドプラットフォーム** 上への **デプロイ** に適しており、サーバー管理やシステム管理を不要なものにする。 * 開発環境と本番環境の **差異を最小限** にし、アジリティを最大化する **継続的デプロイ** を可能にする。 * ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく **スケールアップ** できる。 Twelve-Factorの方法論は、どのようなプログラミング言語で書かれたアプリケーションにでも適用できる。また、どのようなバックエンドサービス（データベース、メッセージキュー、メモリキャッシュなど）の組み合わせを使っていても適用できる。 content/pl/intro.md0000644000175000056700000000232715226251677013066 0ustar0000000000000000Wprowadzenie ============ We współczesnym świecie oprogramowanie jest powszechnie wytwarzane w formie usługi, nazywane _software-as-service (SaaS)_ lub aplikacjami internetowymi. Dwanaście aspektów aplikacji jest metodologią budowania aplikacji SaaS, które: * Używają **deklaratywnego** formatu by zautomatyzować konfigurację aplikacji w celu zmniejszenia czasu i kosztów dołączenia nowych programistów do projektu; * Mają **czysty kontrakt** z systemem operacyjnym, umożliwiając **jak największą możliwość przenoszenia** pomiędzy środowiskami, w których działają; * Są dopasowane do **wdrożenia** na nowoczesne **chmury obliczeniowe**, zapobiegając potrzebie użycia serwerów i administracji systemu; * **Minimalizują rozbieżności** pomiędzy środowiskami developerskimi i produkcyjnymi, umożliwiając **nieustanne wdrażanie aplikacji** by zmaksymalizować prędkość zmian; * I mogą **skalować się** bez większej zmiany narzędzi, architektury, czy sposobu pracy zespołu. Metodologia dwunastu aspektów może być stosowana do aplikacji napisanych w każdym języku programowania i wykorzystujących dowolną kombinację usług wspierających (bazy danych, kolejki, cache pamięci etc). content/th/disposability.md0000644000175000056700000001256415226251677014616 0ustar0000000000000000## IX. Disposability ### เพิ่มความแข็งแกร่งด้วยการเริ่มต้นระบบอย่างรวดเร็วและปิดระบบอย่างนุ่มนวล **Process ของ twelve-factor app จะต้อง **disposable**, หมายความว่าสามารถเริ่มต้นหรือหยุดในขณะที่แจ้งให้ทราบล่วงหน้า** นี่ส่งเสริมให้ขนายยื่ดหยุ่นอย่างรวดเร็ว, deployment ของการเปลี่ยนแปลง [code](./codebase) หรือ [การตั้งค่า](./config) อย่างรวดเร็ว และแข็งแกร่งสำหรับ production deploy Process ควรจะมุ่งมั่นที่จะ **ลดเวลาเริ่มต้น** จะเป็นการดีถ้า process ใช้เวลาไม่กี่วินาทีจากคำสั่งเปิดใช้งานถูกประมวลผลจนกระทั่ง process ทำงานและพร้อมสำหรับรับ request หรือ job, การใช้เวลาเริ่มต้นที่สั้นนี้จะทำให้คล่องตัวสำหรับกระบวนการ [release](./build-release-run) และขยายออก และช่วยให้แข็งแกร่งเพราะเป็นการรับประกันว่าตัวจัดการ process สามารถย้าย process ไปยังเครื่องใหม่ได้ง่าย Process จะต้อง **ปิดระบบอย่างนุ่มนวลเมื่อรับสัญญาณ [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** จากตัวจัดการ process สำหรับ process ของเว็บ การปิดระบบอย่างอย่างนุ่มนวลสำเร็จได้ด้วยสิ้นสุดการเฝ้าดู service port (ปฏิเสธ request ที่เข้ามาใหม่) ประมวลผล request ที่รับเข้ามาแล้วให้เสร็จ และออกจากโปรแกรม โดยนัยในรูปแบบนี้คือ HTTP request จะสั้นมาก (ไม่มากไปกว่าสองสามวินาที) หรือในกรณีของการประมวลผลที่ยาวนาน, client ควรจะพยายามต่อเนื่องที่จะติดต่ออีกครั้งเมื่อการเชื่อมต่อขาดหายไป สำหรับ worker process การปิดระบบอย่างนุมนวลสำเร็จได้ด้วยการคืนงานที่ทำอยู่กลับให้ work queue ตัวอย่างเช่น บน [RabbitMQ](http://www.rabbitmq.com/) worker สามารถส่ง [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack), บน [Beanstalkd](https://beanstalkd.github.io) งานจะถูกส่งกลับไปยัง queue อัตโนมัติเมือใดก็ตามที่ worker ขาดการติดต่อ ระบบ Lock-based เช่น [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) จำเป็นต้องทำให้แน่ใจว่าปล่อยงานที่ลํอกไว้ออกให้หม โดยนัยในรูปแบบนี้งานทั้งหมดเป็น [reentrant](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29) ซึ่งโดยปรกติจะสำเร็จด้วยการห่อผลลัพธ์ใน transaction หรือสร้างตัวดำเนินงาน [idempotent](http://en.wikipedia.org/wiki/Idempotence) Process ควรจะ **ทนทานต่อการหยุดการทำงานอย่างฉับพลัน** ในกรณีนี้ความผิดพลาดที่เกิดขึ้นในฮาร์ดแวร์ ในขณะที่กรณีนี้เกิดขึ้นน้อยมากกว่าการปิดระบบอย่างนุ่มนวลด้วย `SIGTERM` มันก็ยังมีโอกาสเกิดขึ้นได้ วิธีที่แนะนำคือใช้ robust queueing backend อย่างเช่น Beanstalkd ที่จะส่งกลับงานไปยัง queue เมื่อ client ขาดการติดต่อหรือหมดเวลา ทั้งสองวิธี twelve-factor app จะถูกออกแบบให้จัดการกับสิ่งที่คาดไม่ถึง, มีการปิดที่ผิดปรกติ [Crash-only design](http://lwn.net/Articles/191059/) ใช้แนวคิดนี้กับ [logical conclusion](http://docs.couchdb.org/en/latest/intro/overview.html) content/th/who.md0000644000175000056700000000066515226251677012533 0ustar0000000000000000ใครควรจะอ่านเอกสารนี้? ============================== นักพัฒนาที่สร้างแอพพลิเคชันซึ่งทำงานเป็นเซอร์วิซ (service) วิศวกรดำเนินงานผู้ซึ่งปรับใช้ (deploy) หรือจัดการแอพพลิเคชันดังกล่าว content/uk/dependencies.md0000644000175000056700000001117615226251677014367 0ustar0000000000000000## II. Залежності ### Явно оголошуйте та ізолюйте залежності Більшість мов програмування мають системи пакунків для розповсюдження бібліотек, такі як [CPAN](http://www.cpan.org/) для Perl або [Rubygems](http://rubygems.org/) для Ruby. Бібліотеки, встановлені через систему пакунків, можуть бути доступними для всієї системи (так звані "site-packages") або встановлені в каталог застосунку (так звані "vendoring" або "bundling"). **Застосунок дванадцяти факторів ніколи не залежить від неявно існуючих, досупних всій системі пакунків.** Застосунок повно і точно вказує всі свої залежності за допомогою маніфесту *оголошення залежностей*. Крім того, він використовує інструмент *ізоляції залежністей* під час виконання, щоб гарантувати, що ніякі неявні залежності не "просочилися" з зовнішньої системи. Повна і явна специфікація залежностей використовується однаково як при розробці, так і в production. Наприклад, [Bundler](https://bundler.io/) в Ruby використовує `Gemfile` як формат маніфесту для оголошення залежностей і `bundle exec` для ізоляції залежностей. В Python є два окремі інструменти для цих задач - [Pip](http://www.pip-installer.org/en/latest/) використовується для оголошення і [Virtualenv](http://www.virtualenv.org/en/latest/) для ізоляції. Навіть C має [Autoconf](http://www.gnu.org/s/autoconf/) для оголошення залежностей, а статичне зв'язування може забезпечити ізоляцію залежностей. Який би не використовувався набір інструментів, оголошення і ізоляція залежностей завжди мають використовуватися разом — тільки одне або інше не є достатньою умовою для задоволення дванадцяти факторів. Однією з переваг явного оголошення залежностей є те, що це спрощує налаштування застосунку для нових розробників. Новий розробник може скопіювати кодову базу застосунку на свою машину, необхідними вимогами для якої є тільки наявність середовища виконання мови програмування та наявність менеджера залежностей. Все необхідне для запуску коду застосунку може бути налаштоване за допомогою визначеної *команди збірки*. Наприклад, команда збірки для Ruby/Bundler є `bundle install`, а для Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) це `lein deps`. Застосунок дванадцяти факторів також ніколи не залежить від неявно існуючих будь-яких системних інструментів. Прикладом може бути запуск застосунком таких системних інструментів, як ImageMagick або `curl`. У той час, як ці інструменти можуть бути встановлені на багатьох або навіть більшості систем, немає жодної гарантії, що вони будуть встановлені на всіх системах, де застосунок може запускатися в майбутньому, або версія інструменту, встановлена в системі, буде сумісна з застосунком. Якщо застосунку потрібно запускати певні системні інструменти, то такі інструменти мають бути включені в сам застосунок.content/uk/dev-prod-parity.md0000644000175000056700000001711215226251677014763 0ustar0000000000000000## X. Dev/prod паритет ### Прагніть максимальної ідентичності development, staging та production середовищ Історично склалося, що є суттєві відмінності між development середовищем (розробник вносить живі зміни в [локально розгорнутий](./codebase) застосунок) і production середовищем (до якого мають доступ кінцеві користувачі). Ці відмінності проявляються в трьох областях: * **Різниця в часі**: Розробник може працювати над кодом, який потрапить у production через дні, тижні або навіть місяці; * **Різниця в персоналі**: Розробники пишуть код, Ops-інженери розгортають його; * **Різниця в інструментах**: Розробники можуть використовувати стек технологій такий, як Nginx, SQLite та OS X, в той час як на production використовується Apache, MySQL та Linux. **Застосунок дванадцяти факторів проектується для [безперервного розгортання](http://avc.com/2011/02/continuous-deployment/), завдяки мінімізації різниці між production і development середовищами.** Розглянемо три відмінності, описані вище: * Зменшити різницю в часі: розробник може написати код і він буде розгорнутий через декілька годин або навіть хвилин; * Зменшити різницю в персоналі: розробники, які писали код, беруть активну участь в його розгортанні і спостерігають за його поведінкою на production; * Зменшити різницю в інструментах: тримати development та production середовища максимально ідентичними. Резюмуючи сказане вище в таблицю:
    Традиційний застосунок Застосунок дванадцати факторів
    Час між розгортаннями Тижні Години
    Автор коду/той хто розгортає Різні люди Ті ж люди
    Dev/Prod розгортання Різні Максимально ідентичні
    [Сторонні служби](./backing-services), такі як бази даних, системи черг повідомлень або кеш, є однією з областей, де dev/prod паритет має важливе значення. Багато мов програмування мають бібліотеки, які спрощують доступ до сторонніх служб, в тому числі, *адаптери* для різних видів сервісів. Деякі приклади наведені в таблиці нижче.
    Тип Мова Бібліотека Адаптери
    База даних Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
    Черга повідомлень Python/Django Celery RabbitMQ, Beanstalkd, Redis
    Кеш Ruby/Rails ActiveSupport::Cache Пам'ять, файлова система, Memcached
    Іноді розробники бачать переваги у використанні "легких" сторонніх служб в їхньому локальному середовищі, в той час як більш серйозні і надійні сторонні служби будуть використовуватися у production. Наприклад, локально використовують SQLite, а на production PostgreSQL; або локально пам'ять процесу для кешування, а на production Memcached. **Розробник застосунку дванадцяти факторів уникає використання різних сторонніх служб в development і production середовищах**, навіть якщо адаптери теоретично абстраговані від будь-яких відмінностей у сторонніх службах. Відмінності між сторонніми службами означають, що може виникнути крихітна несумісність, в результаті чого код, який працював і пройшов тестування в development та staging середовищах, після розгортання не працює в production середовищі. Такий тип помилок створює перешкоди, які нівелюють переваги безперервного розгортання. Ціна цих перешкод і подальшого відновлення безперервного розгортання надзвичайно висока, якщо розглядати в сукупності за весь час експлуатації застосунку. Встановлення локально "легких" сторонніх сервісів вже не є таким привабливим, як було раніше. Сучасні надійні сторонні сервіси, такі як Memcached, PostgreSQL і RabbitMQ, досить легко встановити і запустити завдяки сучасним менеджерам пакунків, таким як [Homebrew](http://mxcl.github.com/homebrew/) і [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Крім того, декларативні інструменти підготовки середовища, такі як [Chef](http://www.opscode.com/chef/) і [Puppet](http://docs.puppetlabs.com/), у поєднанні з "легким" віртуальним середовищем, таким як [Vagrant](http://vagrantup.com/), дозволяють розробникам запускати локальні середовища, які наближені до production. Ціна встановлення і використання цих систем є низькою у порівнянні з користю dev/prod паритету і безперервного розгортання. Адаптери для різних сторонніх сервісів все ж корисні, тому що вони роблять перенесення застосунку для використання з іншими сторонніми сервісами відносно безболісним. Але всі розгортання застосунку (development, staging та production середовища) мають використовувати один і той самий тип і версію кожного зі сторонніх сервісів.content/de/codebase.md0000644000175000056700000000356715226251677013464 0ustar0000000000000000## I. Codebase ### Eine im Versionsmanagementsystem verwaltete Codebase, viele Deployments Eine Zwölf-Faktor-App wird immer in einem Versionsmanagementsystem verwaltet, wie zum Beispiel [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) oder [Subversion](http://subversion.apache.org/). Eine Kopie der Versionsdatenbank wird *Code Repository* genannt, kurz *Code Repo* oder auch nur *Repo*. Eine *Codebase* ist jedes einzelne Repo (in einem zentralisierten Versionsmanagementsystem wie Subversion) oder jede Menge von Repos, die einen ursprünglichen Commit teilen (in dezentralisierten Versionsmanagementsystemen wie git). ![Eine Codebase bildet sich in viele Deploys ab.](/images/codebase-deploys.png) Es gibt immer eine eineindeutige Korrelation zwischen einer Codebase und einer App: * Wenn es mehrere Codebases gibt, ist es keine App -- sondern ein verteiltes System. Jede Komponente in einem verteilten System ist eine App, und Jede kann für sich den zwölf Faktoren entsprechen. * Wenn mehrere Apps denselben Code teilen, verletzt dies die zwölf Faktoren. Lösen lässt sich dies, indem man den gemeinsamen Code in Bibliotheken auslagert und über die [Abhängigkeitsverwaltung](./dependencies) lädt. Es gibt nur eine Codebase pro App aber viele Deploys der App. Ein *Deploy* ist eine laufende Instanz der App. Meist gibt es ein Produktionssystem und eines oder mehrere Staging-Systeme. Zusätzlich hat jeder Entwickler eine Kopie der App in seiner lokalen Entwicklungsumgebung, das sind auch Deploys. Die Codebase ist über alle diese Deploys hinweg dieselbe, auch wenn bei jedem Deploy unterschiedliche Versionen aktiv sind. So hat zum Beispiel ein Entwickler manche Commits noch nicht nach Staging deployt; Staging hat manche Commits noch nicht nach Produktion deployt. Aber alle teilen dieselbe Codebase, was sie als verschiedene Deploys derselben App auszeichnet. content/pl/build-release-run.md0000644000175000056700000000537615226251677015261 0ustar0000000000000000## V. Buduj, publikuj, uruchamiaj ### Oddzielaj etap budowania od uruchamiania [Codebase](./codebase) jest przetwarzany we wdrożenie w trzech etapach (poza lokalnym środowiskiem). * Podczas *etapu budowania* kod z repozytorium konwertowany jest do wykonywalnej paczki tzw. *buildu*. Używając wersji kodu zdefiniowanej przez commit w procesie deploymentu, w tym etapie pobiera i dołącza się do projektu [zależności](./dependencies) oraz kompiluje niezbędne zasoby. * Podczas *etapu publikacji* aplikacji używany jest build stworzony w poprzednim etapie i konfigurowany na podstawie [ustawień](./config) obecnego wdrożenia. Stworzony w ten sposób *release* zawiera zbudowane źródło kodu, jego konfigurację i jest gotowy do uruchomienia w wybranym środowisku. * *Etap uruchamiania* (znany również jako "runtime") startuje aplikację w środowisku wykonawczym przez uruchomienie zestawu [procesów](./processes) w oparciu o wcześniej przygotowany release. ![Kod staje się buildem, jeśli zostanie połączony z konfiguracją by stworzyć release](/images/release.png) **Aplikacja 12factor ściśle rozgranicza etapy budowy, publikacji i uruchomiania** Kiedy aplikacja została już uruchomiona, nie można zmienić jej kodu w inny sposób niż zbudować ją na nowo na podstawie wcześniej naniesionych zmian. Narzędzia do obsługi wdrożeń zazwyczaj oferują moduły do zarządzania releasami, w tym możliwość do powrotu do poprzedniej wersji (rollback). Np. narzędzie [Capistrano](https://github.com/capistrano/capistrano/wiki) przechowuje releasy w podkatalogu `releases`, gdzie obecna wersja opublikowanej aplikacji jest symlinkowana do jednej z wersji przechowywanej w katalogu Capistrano. Komenda `rollback` pozwala na szybką zmianę wersji opublikowanej aplikacji na jedną z poprzednich. Każdy release powinien zawsze posiadać unikalny identyfikator, jak np. data publikacji aplikacji (taka jak `2011-04-06-20:32:17`) lub inkrementowany numer (np. `v100`). Do rejestru opublikowanych wersji aplikacji można jedynie dodawać jej nowe wersje, jego zawartość nie może być zmieniana w żaden inny sposób. Aplikacja może zostać zbudowana gdy developer zdecyduje o wdrożeniu zmian do kodu. Uruchomienie aplikacji może natomiast nastąpić automatycznie po restarcie serwera lub jednego z procesów aplikacji po błędzie krytycznym. Dlatego też etap uruchamiania aplikacji powinien być jak najbardziej jednolity minimalizując równocześnie ryzyko wystąpienia problemów ze startem aplikacji - mogą one spowodować zaprzestanie działania aplikacji np. w nocy, kiedy to nie ma żadnego developera "pod ręką". Etap budowy aplikacji może być bardziej złożony, ponieważ ewentualne błędy są zawsze widoczne dla developera, który nadzoruje ten proces. content/pt_br/codebase.md0000644000175000056700000000405515226251677014173 0ustar0000000000000000## I. Base de Código ### Uma base de código com rastreamento utilizando controle de revisão, muitos deploys Uma aplicação 12 fatores é sempre rastreada em um sistema de controle de versão, como [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), ou [Subversion](http://subversion.apache.org/). Uma cópia da base de dados do rastreamento de revisões é conhecido como *repositório de código*, normalmente abreviado como *repositório* ou *repo*. Uma *base de código* é um único repo (em um sistema de controle de versão centralizado como Subversion), ou uma série de repositórios que compartilham um registro raiz. ![Uma base de código para vários deploys](/images/codebase-deploys.png) Existe sempre uma correlação um-para-um entre a base de código e a aplicação: * Se existem várias bases de código, isto não é uma app -- é um sistema distribuído. Cada componente do sistema é uma app, e cada uma pode individualmente ser compatível com os 12 fatores. * Múltiplas apps compartilhando uma base de código é uma violação dos 12 fatores. A solução aqui é dividir o código compartilhado entre bibliotecas que podem ser incluídas através do [gerenciador de dependências](/dependencies). Existe apenas uma base de código por aplicação, mas existirão vários deploys da mesma. Um *deploy* (ou implantação) é uma instância executando a aplicação. Isto é tipicamente um local de produção, e um ou mais locais de testes. Adicionalmente, todo desenvolvedor tem uma cópia da aplicação rodando em seu ambiente local de desenvolvimento, cada um desses pode ser qualificado como um deploy. A base de código é a mesma através de todos os deploys, entretanto diferentes versões podem estar ativas em cada deploy. Por exemplo, um desenvolvedor tem alguns registros ainda não implantados no ambiente de teste, o ambiente de teste ainda tem registros não implantados em produção. Mas todos esses ambientes compartilham a mesma base de código, tornando-os identificáveis ​​como diferentes deploys do mesmo app. content/ru/build-release-run.md0000644000175000056700000001105015226251677015256 0ustar0000000000000000## V. Сборка, релиз, выполнение ### Строго разделяйте стадии сборки и выполнения [Кодовая база](./codebase) трансформируется в развёртывание (не учитывая развёртывание для разработки) за три этапа: * *Этап сборки* -- это трансформация, которая преобразует репозиторий кода в исполняемый пакет, называемый *сборка*. Используя версию кода по указанному процессом развёртывания коммиту, этап сборки загружает сторонние [зависимости](./dependencies) и компилирует двоичные файлы и ресурсы (assets). * *Этап релиза* принимает сборку, полученную на этапе сборки, и объединяет её с текущей [конфигурацией](./config) развёртывания. Полученный *релиз* содержит сборку и конфигурацию и готов к немедленному запуску в среде выполнения. * *Этап выполнения* (также известный как "runtime") запускает приложение в среде выполнения путём запуска некоторого набора [процессов](./processes) приложения из определённого релиза. ![Код становится сборкой, которая объединяется с конфигурацией для создания релиза.](/images/release.png) **Приложение двенадцати факторов использует строгое разделение между этапами сборки, релиза и выполнения.** Например, невозможно внести изменения в код во время выполнения, так как нет способа распространить эти изменения обратно на этап сборки. Инструменты развёртывания, как правило, представляют собой инструменты управления релизами, и что немаловажно, дают возможность отката к предыдущему релизу. Например инструмент развёртывания [Capistrano](https://github.com/capistrano/capistrano/wiki) сохраняет релизы в подкаталогах каталога с именем `releases`, где текущий релиз является символической ссылкой на каталог текущего релиза. Команда Capistrano `rollback` даёт возможность быстро откатится к предыдущему релизу. Каждый релиз должен иметь уникальный идентификатор, такой как отметка времени релиза (например `2015-04-06-15:42:17`) или увеличивающееся число (например `v100`). Релизы могут только добавляться и каждый релиз невозможно изменить после его создания. Любые изменения обязаны создавать новый релиз. Сборка инициируется разработчиком приложения всякий раз, когда разворачивается новый код. Запуск этапа выполнения, напротив, может происходить автоматически в таких случаях, как перезагрузка сервера, или перезапуск упавшего процесса менеджером процессов. Таким образом, этап выполнения должен быть как можно более технически простым, так как проблемы, которые могут помешать приложению запуститься могут возникнуть в середине ночи, когда нет доступных разработчиков. Этап сборки может быть более сложным, так как возможные ошибки всегда видимы разработчику, который запустил развёртывание. content/uk/config.md0000644000175000056700000001357615226251677013214 0ustar0000000000000000## III. Конфігурація ### Зберігайте конфігурацію в середовищі виконання *Конфігурація* застосунку — це все, що може змінюватися між [розгортаннями](./codebase) (staging-розгортання, production-розгортання, локальне середовище розробника тощо). Це включає: * Параметри підключення до бази даних, Memcached і інших [сторонніх сервісів](./backing-services); * Реєстраційні дані для підключення до зовнішніх сервісів, таких як Amazon S3 або Twitter; * Значення, що залежать від середовища розгортання, такі як канонічне ім'я хосту. Застосунки іноді зберігають конфігурації як константи в коді. Це є порушенням методології дванадцяти факторів, яка вимагає **обов'язкового відокремлення конфігурації від коду**. Конфігурації застосунку в розгортаннях суттєво відрізняються, код — однаковий. Лакмусовим папірцем того, чи правильно розділені конфігурація і код, є можливість в будь-який момент відкрити вихідний код застосунку у вільний доступ, при цьому не оприлюднюючи будь-яких приватних даних. Зверніть увагу, що визначення "конфігурації" **не включає** в себе внутрішні налаштування застосунку, такі як `сonfig/routes.rb` в Rails, або [як пов'язані основні модулі](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) в [Spring](http://spring.io/). Ці налаштування не змінюються між розгортаннями, і тому краще місце для них — саме в коді. Іншим підходом до конфігурації є використання конфігураційних файлів, що не зберігаються в систему контролю версій, таких як `сonfig/database.yml` в Rails. Це перевага у порівнянні з використанням констант в коді, але все ж таки має суттєві недоліки: є ймовірність помилково зберегти файл конфігурації в репозиторій; існує тенденція коли конфігураційні файли розкидані в різних місцях і в різних форматах, і стає важко передивлятися всі налаштування і керувати ними в одному місці. Крім того, формати цих файлів, як правило, специфічні для конкретної мови програмування чи фреймворку. **Застосунок дванадцати факторів зберігає конфігурацію в *змінних оточення*** (часто скорочується до *env vars* або *env*). Значення змінних оточення легко змінити між розгортаннями без зміни коду; на відміну від конфігураційних файлів, менш ймовірно випадково зберегти їх в репозиторій коду; і на відміну від конфігураційних файлів або інших механізмів конфігурації, таких як Java System Properties, вони є стандартом, незалежним від мови програмування чи фреймворку. Іншим аспектом керування конфігурацією є групування. Іноді застосунки об'єднують конфігурації в іменовані групи (які часто називаються "оточеннями"), які називаються в залежності від конкретного розгортання, наприклад, `development`, `test` і `production` оточення в Rails. Цей метод погано масштабується: чим більше створюється різних розгортань застосунку, тим більше необхідно нових імен оточень, наприклад, `staging` або `qa`. При подальшому рості проекту розробники можуть додавати свої власні спеціальні оточення, наприклад, `joes-staging`, що призводить до комбінаторного вибуху конфігурації, який робить керування розгортанням застосунку нестабільним. У застосунку дванадцяти факторів змінні оточення є незв'язаними між собою засобами керування. Кожна змінна повністю незалежна від інших. Вони ніколи не групуються разом в "оточення", керування ними здійснюється незалежно для кожного розгортання. Ця модель добре масштабується разом з появою більшої кількості розгортань застосунку протягом його експлуатації.content/uk/disposability.md0000644000175000056700000001201215226251677014606 0ustar0000000000000000## IX. Утилізовуваність ### Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення **[Процеси](./processes) застосунку дванадцати факторів є *утилізовуваними*, тобто вони можуть бути запущені або зупинені в будь-який момент.** Це сприяє гнучкому масштабуванню, швидкому розгортанню [коду](./codebase) або змінам [конфігурації](./config) і надійності production-розгортання. Слід намагатися **мінімізувати час запуску процесів**. В ідеалі час між моментом виконання команди запуску процесу і моментом, коли процес готовий приймати запити чи задачі, має тривати лише пару секунд. Короткий час запуску забезпечує більшу гнучкість для [релізу](./build-release-run) і масштабування. Крім того, це підвищує стійкість, оскільки менеджер процесів може легко переміщувати процеси на нові фізичні машини у разі необхідності. Процеси мають **коректно завершувати свою роботу, коли вони отримують [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** сигнал від диспетчеру процесів. Для веб-процесу коректне завершення роботи досягається завдяки припиненню прослуховування порту, до якого він прив'язаний (що означає відмову від отримання будь-яких нових запитів), завершенню обробки будь-яких поточних запитів та зупинці самого процесу. В цій моделі передбачається, що HTTP-запити короткі (не більше ніж кілька секунд), а у разі довгих запитів (long polling) клієнт має намагатися відновити з'єднання у разі його втрати. Для процесу, що виконує фонові задачі (worker), коректне завершення роботи досягається за рахунок повернення поточного завдання назад у чергу задач. Наприклад, в [RabbitMQ](http://www.rabbitmq.com/) робочий процес може надіслати команду [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); в [Beanstalkd](https://beanstalkd.github.io) завдання повертається в чергу автоматично щоразу, коли процес втрачає з'єднання. Системи, що використовують блокування, такі як [Delayed Job](https://github.com/collectiveidea/delayed_job#readme), мають бути повідомлені, щоб звільнити блокування задачі. В цій моделі передбачається, що всі задачі є [повторно вхідними](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), що зазвичай досягається шляхом обертання результатів їхньої роботи в транзакції або шляхом використання [ідемпотентних](http://en.wikipedia.org/wiki/Idempotence) операцій. Процеси також мають бути **стійкі до раптової зупинки** в разі відмови апаратних засобів, на яких вони запущені. Хоча це менш ймовірна подія, ніж коректне завершення роботи за допомогою сигналу `SIGTERM`, вона все ж таки може статися. Рекомендованим підходом є використання надійних черг завдань, таких як Beanstalkd, які повертають завдання в чергу задач, коли клієнти втрачають з'єднання або від'єднуються по тайм-ауту. У будь-якому випадку, застосунок дванадцяти факторів має проектуватися таким чином, щоб обробляти несподівані та некоректні вимкнення. Прикладом вдалої реалізації [архітектури "тільки аварійного вимкнення" (Crash-only design)](http://lwn.net/Articles/191059/) є [СouchDB](http://docs.couchdb.org/en/latest/intro/overview.html). locales/de.yml0000644000175000056700000000034615226251677012060 0ustar0000000000000000de: # Name of language listed in locales menu language: "Deutsch (de)" # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "Dies ist eine Übersetzung." locales/fr.yml0000644000175000056700000000035015226251677012072 0ustar0000000000000000fr: # Name of language listed in locales menu language: "Français (fr)" # A text to make known that the article is a translation not an original. # Empty for English, original. translation: "Ce texte est une traduction" content/de/who.md0000644000175000056700000000026115226251677012500 0ustar0000000000000000Wer sollte dieses Dokument lesen? ============================== Jeder Entwickler der Apps baut, die als Dienst laufen. Administratoren, die solche Apps managen oder deployen. content/ja/dependencies.md0000644000175000056700000000703015226251677014334 0ustar0000000000000000## II. 依存関係 ### 依存関係を明示的に宣言し分離する ほとんどのプログラミング言語は、サポートライブラリを配布するためのパッケージ管理システムを提供している。例えば、Perlにおける[CPAN](http://www.cpan.org/)やRubyにおける[Rubygems](http://rubygems.org/)などである。パッケージ管理システムでインストールされるライブラリは、システム全体（“site packages”と言われる）にインストールされる場合と、アプリケーションを含むディレクトリのスコープ（“vendoring”または“bundling”と言われる）にインストールされる場合がある。 **Twelve-Factor Appは、システム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない。** すべての依存関係を *依存関係宣言* マニフェストで完全かつ厳密に宣言する。さらに、実行時には *依存関係分離* ツールを使って、取り囲んでいるシステムから暗黙の依存関係が“漏れ出ない”ことを保証する。完全かつ明示的な依存関係の指定は、本番環境と開発環境の両方に対して同様に適用される。 例えば、Rubyで使われる[Bundler](https://bundler.io/) は、依存関係宣言のためのマニフェストのフォーマットである`Gemfile`と依存関係分離のための`bundle exec`を提供している。Pythonではこれらのステップで2つの別々のツールが使われる -- [Pip](http://www.pip-installer.org/en/latest/)が宣言のために使われ、[Virtualenv](http://www.virtualenv.org/en/latest/)が分離のために使われる。C言語でも[Autoconf](http://www.gnu.org/s/autoconf/)で依存関係を宣言し、静的リンクで依存関係を分離することができる。ツールが何であれ、依存関係の宣言と分離は常に一緒に使わなければならない -- どちらか片方だけではTwelve-Factorを満足するのに不十分である。 明示的に依存関係を宣言する利点の1つは、アプリケーションに新しい開発者が加わった際のセットアップを単純化できることである。新しい開発者は、言語のランタイムと依存関係管理ツールさえインストールされていれば、アプリケーションのコードベースを自分の開発マシンにチェックアウトすることができる。開発者は決められた *ビルドコマンド* で、アプリケーションのコードを実行するために必要なすべてのものをセットアップできる。例えば、Ruby/Bundlerのビルドコマンドは`bundle install`であり、Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme)では`lein deps`である。 また、Twelve-Factor Appは、いかなるシステムツールの暗黙的な存在にも依存しない。例として、アプリケーションからImageMagickや`curl`を使う場合がある。これらのツールはほとんどのシステムに存在するだろうが、アプリケーションが将来に渡って実行され得るすべてのシステムに存在するかどうか、あるいは将来のシステムでこのアプリケーションと互換性のあるバージョンが見つかるかどうかについては何の保証もない。アプリケーションがシステムツールを必要とするならば、そのツールをアプリケーションに組み込むべきである。 content/ja/processes.md0000644000175000056700000000677515226251677013733 0ustar0000000000000000## VI. プロセス ### アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する アプリケーションは、実行環境の中で1つもしくは複数の *プロセス* として実行される。 最も単純な場合では、コードは単体のスクリプトであり、実行環境は言語ランタイムがインストールされた開発者のローカルノートPCであり、プロセスはコマンドラインから実行される（例：`python my_script.py`）。対極にあるのは、[複数の実行プロセスとしてインスタンス化される多くのプロセスタイプ](./concurrency)を使う洗練されたアプリケーションの本番デプロイである。 **Twelve-Factorのプロセスはステートレスかつ[シェアードナッシング](http://en.wikipedia.org/wiki/Shared_nothing_architecture)** である。永続化する必要のあるすべてのデータは、ステートフルな[バックエンドサービス](./backing-services)（典型的にはデータベース）に格納しなければならない。 プロセスのメモリ空間やファイルシステムは、短い単一のトランザクション内でのキャッシュとして利用してもよい。例えば、大きなファイルをダウンロードし、そのファイルを処理し、結果をデータベースに格納するという一連の処理において、ファイルシステムをキャッシュとして利用できる。Twelve-Factor Appは、メモリやディスクにキャッシュされたものが将来のリクエストやジョブにおいて利用できることを決して仮定しない -- それぞれのプロセスタイプのプロセスが多く実行されている場合、将来のリクエストやジョブが別のプロセスで処理される可能性が高い。1つのプロセスしか実行されていない場合であっても、プロセスが再起動すると、すべての局所的な状態（メモリやファイルシステムなど）が消えてしまうことがある。プロセスの再起動の要因としては、コードのデプロイ、設定の変更、プロセスを別の物理位置に再配置する実行環境などがある。 アセットパッケージャー（例：[Jammit](http://documentcloud.github.com/jammit/) や [django-compressor](http://django-compressor.readthedocs.org/)）は、コンパイルされたアセットをキャッシュするためにファイルシステムを利用する。Twelve-Factor Appは、このコンパイル処理を実行時に行うよりも、[Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html)のように[ビルドステージ](./build-release-run)で行うほうが、望ましいと考えている。 Webシステムの中には、[“スティッキーセッション”](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence)に頼るものがある -- これはユーザーのセッションデータをアプリケーションプロセスのメモリにキャッシュし、同じ訪問者からの将来のリクエストが同じプロセスに送られることを期待するものである。スティッキーセッションはTwelve-Factorに違反しており、決して使ったり頼ったりしてはならない。セッション状態のデータは、有効期限を持つデータストア（例：[Memcached](http://memcached.org/) や [Redis](http://redis.io/)）に格納すべきである。 content/ko/codebase.md0000644000175000056700000000417515226251677013501 0ustar0000000000000000## I. 코드베이스 ### 버전 관리되는 하나의 코드베이스와 다양한 배포 Twelve-Factor 앱은 항상 [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [Subversion](http://subversion.apache.org/) 같은 버전 컨트롤 시스템을 사용하여 변화를 추적하며, 버전 추적 데이터베이스의 사본을 *코드 저장소*, 줄여서 *저장소*라고 부릅니다. *코드베이스*는 단일 저장소(Subversion 같은 중앙 집중식 버전 관리 시스템의 경우) 일수도 있고, 루트 커밋을 공유하는 여러 저장소(Git 같은 분산 버전 관리 시스템)일수도 있습니다. ![하나의 코드베스는 여러 배포로 매핑됩니다.](/images/codebase-deploys.png) 코드베이스와 앱 사이에는 항상 1대1 관계가 성립됩니다. * 코드베이스가 여러개 있는 경우, 앱이 아니라 분산 시스템으로 봐야합니다. 분산 시스템의 개별 구성요소가 앱이 되며, 개별 앱이 Twelve-Factor를 따릅니다. * 여러개 앱이 동일한 코드를 공유한다면 Twelve-Factor를 위반하는것입니다. 이를 해결하려면 공유하는 코드를 라이브러리화 시키고, 해당 라이브러리를 [종속성 매니저](./dependencies)로 관리해야합니다. 앱의 코드베이스는 한개여야 하지만, 앱 배포는 여러개가 될수 있습니다. *배포*는 실행중인 앱의 인스턴스를 가리킵니다. 보통 운영 사이트와 여러 스테이징 사이트가 여기에 해당합니다. 모든 개발자는 자신의 로컬 개발 환경에 실행되는 앱을 가지고 있는데, 이것 역시 하나의 배포로 볼 수 있습니다. 배포마다 다른 버전이 활성화 될수 있지만, 코드베이스 자체는 모든 배포에 대해 동일합니다. 예를 들어, 개발자는 아직 스테이징 환경에 배포하지 않은 커밋이 있을 수 있으며, 스테이징 환경에는 아직 운영 환경에 배포되지 않은 커밋이 있을 수 있습니다. 하지만 이 모든 것들이 같은 코드베이스를 공유하고, 같은 앱의 다른 배포라고 할 수 있습니다.public/images/codebase-deploys.png0000644000175000056700000006147315226251677016006 0ustar0000000000000000PNG  IHDREJ pHYs   IDATx$Ն/ Ipװ$X `?=., , ;u;w9yj11B` Xn0 @0 ab@0 b C+: ` C` V QsL`X&Ղp.Y>)W-!91ϸY9P)3}26AI+ݚ`m}4aI`Wɰ+iwB.*?`: j*`xkFܻkh@y,Q5ُ 'r*8Bq py~U@0P t7E@ð/{ZQs)+®9v_ xsM @ `Y Fd`B:uӈ>U0ܗ-3r7?Pgcb Kң@!8;&Q5nBIH?ޕr6b#M z?>o6B 4}N+M^ l2<o9߅?߄}Fc w+i0\:,{v{#tuи n F@ۼoj??Eאly!ܭO#Oۯ.vN2:`=, *Nq^S= <!̱8+pz\S0m&S$i)i?3>BSy`W d+!}X O}2/I Пc s9oNؔQ#ҽ_8*Q FO@#دzHpհ8c,g'y# A|T)~|^ŧtXG*&v:λw>o>Y <) 5z/}S>y d|W:'^*4TҺjHׇy8V ^ۖ8̗Oqpe@c-1^JOlKD5Nxͧ2Ux7cWv||n[44Y^H|rwp;۞&w1&0KsmF_Gng[z  qdܣ ^EqJXl)c ^c_S Cw/70^CjJqR}vùp|t0LG<^;{% ,ˤ]?]X8n] Rۼ썿a6\9IOJ?eIҬe扻F8@6g-J@J_֚.\\̓]|~Voa8$'KEHFg* 6۷vʋ&\f-5M.qyuY}@#2S>>k 2 x%K'VIy̏+& nZ/+A*I-.ہTn0Geq#q[MvoDx~X*Tf)0uYwixR/OS7]  KqmPG C ֻ'eUF 9 .30`K!~]zm:p<]Zz.Jc?'&$ݘGi({Yʾ'L`0? AjޖLu>z UȋeNLiKT( is> z"IG൦8uE8aw{5pݜ OEؚkU8:-Lo*eKHr QV7W0+P|\%/ A>"y]҉({T$ABW!r p/Z;CW~}@e_J$5HbJɇ*}Y2J|R*r>0'x"q|' eek |ʁh@,tЎk[$$)IٚdV>Id.rn~-Ix?jؙׅ8yLlC$M_g Iޝo-[Ao`Xxm+Po8ׁ-e0J]>n$keV`Tֳ& :H`|=).ūEM );6gM'>-vҥ4i6^&ߧL$,epzh@+aֳ)Q$$'jψ Ĕ0YVuhOϐEt41F_Rw~؞N絭I'O 7w3x-K;>Ƶk"ui#?PxjLɠQspAzS+1e /#чm~W!d,tJ|:G=#xCEdMy SNVAju#Dܬ9;gpS^2Y_3 d1 _%Uy7_kr'8ܘ $]OۂyAyJTX81wKvj 'p{O=/ N*]n\8Nך5S2WK ¯n()&uU`ݮZk4>ӟ[U(iNrJO4/u wer ?]\Mk^IhtS|0LG8 myRlS{:,0޷ "C{hDR_wO)μWX Y+ [W,. G/TG?F₱7 =L=gyXL?)x 1w=0%0nQp"=Oc?Lꈔ(-vaPI/7@`{r?ijW%|O0ҤX,JLTF~xDžIi[gO2w5uV!xعJP*y@& žkbOwʅ/pօ`((o^߃ ;_ĹrI!ũMRC@J\rq/k@C7.)aOR3ݠԹ2'@Cn]3aH3W?W1_).Ǭ&5{2Hy8ǩpbjz[^V v bySxK}ㅋ'ݿ_4%?b!-ٔnRR`UqH˯q2p9SUI$f“P+䝅HFƓ|qPi ]4`s Γu3܂v|0Pyw,w}kCנJ\=ൗm 'sqrewy7n!lgx ;N (T0QF0 &(0GF'&oȆvENH3 pBi ڄiTW~6BZYL&SY ,s,mҿ۩_c<4 AԬ``#y^&o0/]Y B`9@9=FEل2M=LTmDBwH -(ȴ((VZC D% C) ` (2WLex(}WS5#ajTDC`MVGuPaD` KF\$67Obག\S# a{o~O1<ۗMeKۼ>1iHoV}֜aS `o𑧐` `0 -T'`@08` h@VtA0 @@0 Њ8` c `aZ@0 ab @0 b C+: ` C` V U[@0g9yd>:uc~%jcMH ˼ْ c{z ݦy w[,@BA*Af#v= ܁N~OAFaX=ٰk[Mٛ G+àA0 c'"5.׸^v;unTC`i4:: @5"U0 M@9` @` h04ͩ@050tH @0iNut41k.Vf!$i\k6ng@2ۭF ^@0P v+ɭKRDH1ƀۊKe펯 yʩK}a r2 i0` 0HiB&y40~< $k5u`^XS{>,a~GM=4w$ݔ@G0O)8%l82YƈU$V U9* O\ 71(D|ߢ78 I3%ބt  <[$*c M*yn{Ƣ n,=c A0>P\5<_1ơc m6t-'&lg׳Gpw L#Q5 P5` (b`ug*P~`{o1@,R?JxN vG_)8X~`;׀$70;0ؠ_ioo0 xo{:TSxwҌE5yZI= ǹ%?ez#aqGީhǸ|?IA oI iՙY (UGKYjf WEVWuh;0#؝p{M,pn|פm$ag*ڤW#-PwC]`O<;I&!~81#ho+Sa&P"B!b9¼Bj[.fS"T`[V!}s`ΜU#i(QY8,H^G`_ph$yƯX44$*}WJW]N@c (ハ`=)S \.IVy ۀmͯԾNS\_HKR 0hj.M8XNkgI P{0״$}-7ЀEpWq=U\ifqjPg{7GfKk@Q⚆E`}`%pitwOz_c0!P+o>@c> k$8 WA&?>h&]1 UTUyTNH[P.niV s j`V"7U袕 K uJ%QOE#I/~E!NŞ{!#!L%qSցU +o.,SjOd!@1P 0&#CH0Pv0 R _ a ,WC'@"# eƲᒸuwpF!>CX O(a`pG"$`u=8B'5s_ 7n:Ȅϖi}|WùwI56n :ӗ'ѯWI3owz.jh~x#\&cs]>8>w)]qu)J4:چa|4Sgjx8qD @]đO:h(t:k#]/ ?k# |چft"m`0 3нZ\\:Ķ'06~ i<JNP҉Vw?UY m(I| -Pf0 Q׹5>_l=i+`Ҙ 86/յ.hƥa@2Apt?g-OO֕&4z:{]j78 `av+6VK ,nCDH 0g$+uA܋? 8.IEH1rUE4 !@ 0W&ұD.ѐ,1ȱ޺bfު`go_4 6h:zco0ߍ -6 U+Im<oa0;'߶1O(`aHeV//8< ~ l(=79b[ T0| U>ZkTm؄Ir'r?_ 㹰oɼ/.em#U5 4$ۜUP3Ҷ6~'[f>([ sf[:&Q-1 5@ <1m܊~)M(UB~h {͸,^k6roc[ԌaUa X:Emva /#_X,W}(rig0xMnFHc00N%?WKxAt$sy$F?Mu eVF hOОy4\ݍ)<:ZR.Ԗj FY_(NKZ>+raFH3.t%e0 f3']a"v\p⋹fS3ܥ'Bk0pB(A Z )oXM@.PӾW>EyHBƛ3Ηk{OxB.GLx1 P8ҷU":a :ډQ;Ax4 4#dUg'{uk.Fw V~8c/r Z2 %R/:(lHMǁs5ĿPc0וa /m'ewF^Q {WHhn7{nH0 d Ԍa⼖6`l `S) gxG2Lhj0 Fa3'W?aɅ7r T0p _Y!@ dpsIns cn0 e_{^O0 1o,V5.0 ~2;$:`چtOtHODb4냣9FwBH0 tjόxW6ƛŐRlQK` (@ ,]},ulҾ B6 `V$HQgaⅵJ@a"swm,h cw#/ৄ8+3b 2n0 n`#Y)뎸GRd$$!e7 c=+8YWHZ/ك`E ?lw p FaD.<@0*aơq{g J2QؖA~ǘ ܋Bѹ>g=]iKe7$h qg-|?!o#ď_%QSwӽـ` Tb<b莢H= Bb0cpGn'}4},ا|#І} ܇"A?W!@Y(a`>HDH0P.f'Sf'(d@p)ʵ׀xBcʎG2Wbsۃ>ڔnCEeNY+'WRvW߿*W>ET ,O7uҙ(]22dp:w@x5BūаhhDC Ec0%)n9ej +up4"]M#{U:{8\TƎ[9Yy6 PEUk(yWD@2Py;@C"uC *Rb18Ԑ8LQV[\'@cQy\ӹ=fy>?u-~&v)+u{98~i nRsl`X~'ϳ%"[W˵f{xx^X\9lNJFhg?ǎB=;VjV0쩉%>:fRڳ_KI_ ur\Tk<\'|T~QzQQ**'E7W$*2WáF4 3; %ZWF~>U@p~NwrJW)X@N&yp8p2q1 '3 yo.{%MO$ݗp|X|!G jVJ ml4lcA# oW.'śKVh;XL4 ɠLUR9kԐhT:*&CPJrG5K k3nbv5춞d_{(\5i1ܛ@E(x+󟅻xh\5W[4w``9N <׉3g y`;TC(*\Wl2jZ0%Pf#Kᙻ8M:g=@ĻB}*g CrMDCߕ>hH\VRv>{^ץ`O%X Ƚ[JGҧ?+96Ιm4?,ϡv Ao1?s6u͌0X[|v#ͤDK?En;fax&pT\*.-UFl a&ikKWE'4&i{*6XA{Y(X< ɸqL\qv zmMQíh Lgyr}F;pb&`]3g~5vDA6Br1o[ $]{9;tv=4ស]x^hDtiN.+g*p2{Yִffqxڔ>±FV Ip|> cQe0.DVVᄸ7W'Zn`-c.^^ekçSN!}φij[ݭ}T.+q^w)[P7B{U|kj$)h Y'\CR" WM_o1PơΉ[cc=e׷VR DCCCODc\(: g+/d8\l ./׻x_-DC<o7u)?H]->|WJڪQARf&d[w=x~ D\9 AR9eU1G4vn;"Pۻӹ'6bQ1~  n/zir.1#8n\== i.\grx IU\ 9(i]|<: xhh4GўpWimI-g+iIWβU'.E@ }8 [@ E? Wjpj ]oDN}Oy?8*d&_K`f`9`ƅo`p:Py !N=1hticm^ѿ]Yo0 ikZ~QֹTr5wl z\E9gϧNNfg*ҋ|Yx< ř yp/(4W'd(g/ Wr2cal _00%vM͸ Se,& GN86jZʮ!%z,BJ3|𧬢Mqd ^ʅ1Cq^:_[iMn LJ ƅŰ_ Cu Ap;0 ji)a謷l%ZPH:_=>2/ 9vP~`+Uu#Q8.6{V@y/^/`5xx|[RU9%l\iV8,WVƬoޜJ|he8Q,ws?&dsq {T=\s;SD&{5/U5 !Ak7Ч*Is(-\Fw ѧ4s8d dʚr5RfCf[bK #k9 S2r g_)e_8` ha+~kaՒYkߏh+(k~Sr֓68#3 xCfچat\N=2H}tC@O_6I㺼0`ZS|9˸ oF`N޴V1?;_x?@1PU.7>p&PB\9bW5ϒ^"=?^N0T T$W e4ΘͲBqx(kظg,0/4뽹 _Bra j! IQV (R/W6BI>^`%ܫ@sYX8@S0Pm7)+ؖ .;g3joZ߅"K(oIoFYX8@3PU 6$(P'Pr`!ࣩ1q%ߡ!CO:X 5Ÿ .~0$ R}|JjJW]ߢFoDj-#Ax8$~df# Ҹ T0@$_@w J>}ӗR{.(p::Nv#z|ߑ ?5ALiLTRc*@v ?EiL'.a(p_8|d] 3,Dv&{'UY *@_ LW WZGy^K%ζݎM}"ja G@Ю`Tl9mS[J>O0/$}`1 ڎӃfy*F3UhJT1;Jn'v~S!M@CJޔH00 T0pHwpk)|gN Vފ"xڭ!(] OHc><?7H0 0pX3*_t%6g{#Bδ9pfQQj(0罢7)ߗ΢ !$lk4R  `᷸9${n`/uW!>kP*Z7iU . }z #}n,Ӗs-糰Fr3k~7b_u*0 SSݕ]j7}=՛@?7 . ig eVol7JHB#Vk}0HȈ- GT|hIag1I?%7.%m%ȪgyI@R c<SJ 6e T˨`sl]{ ? 7W)WRk- |ѳo H5 ވ * GT|[o4kEb8+δQ4j@86io߯{ Ox +UYԛȧӞ6y"{gY}фO{ i|,nOf;c7sY{0WQ53Ps8閐Yb;i C]U: ľaH"߻~zocȼ%<0ξCg C͟h`!)FX8~3"ܖra j0 5yZQb%SdW}bi\Xxb CMh߳juC%7EIq|4 w+Q.7,ǕoK5@ٟJb\x`8orAҖ t >﹞L<׳89ڃ_FYۑ0wV7'|o+,Zk0f߷&ZPf<#qW.aeפ -eAgcek3g2m%1!+ 2_Tڤ?&E3*Àڬ;{ɛ Lԓ5pHi.rK\n˸gQJPξu@pgok 'ߦ'#xVF1m+a,BJ39p0!8| ŭJq JrvY)G鷔=8ru}&a$M-mCj(ws=ivHƀٱ6R *l# 6pn__7MŹkH_7/|셀Pv"i"w|\NV!)Z9#hX'PJ̢֍$[(I~Th~s\*z);.9co/0 viBƕ[:F Y0fEg]:ns~MӀoDJ\V 9F w'-` 0tzئ@U+ҕ8;$KuH7 p^ڏZrpWv\6a1 U4rxH0P5jl1oyNz6 C}h`X()ސ:>6'Od/' IDATBHU`ek5Eu5+㺾^02Ҷߋ";J}HJ\¥¹e+eo#62y­[nՀ)߈% =)m%HА` T0NootScR GO> ;[wn4?kB1PUNO~bD 0n}xQi |4"B_P>SP'Sp=BORCK&`j.]O*2ꤿ]DopQ JH4 HOW3_{%*)#WD@pn7]HV+o})"~NVޅI!@U G@qvMǐ 깪A= Uc$%;޳( _@q~Mo<5 Bn1PmàҝL֭VV?߱iXȄtзY5 *\%Y4yu&XKZYƁ 0\',3wUNS{5!@aavu}/x){oQ i{*3e:඄ZxcU3q;) j8}mgpP?4s@#彈Aޠo tj+@VP/}y r'g Y_ &!ylV ~ \i 7_qR@* , 4Rbܑ|Roj3H/2l[r }BB` 1)ěyH,gskWY_iԲp%lAرUeLSK;=Dl k/A T0XyvT*lkm([?_mľ_0=0|g~y1?I~5@-Jywv*B S{bjO :eꆡE'[=Q 37[ nHy8b<'3ٸ P#@GF!fuH0)a: ",SR^}h>TVm_嬬mp ̎+P7 "h[]D02CzEDkX%]!Z3U k2pK m *"?/ jR;dz.8; @B87g{Y@9q{hx}?X8rf,_x.x9AcCc)Kji_@#^l ܣ.xs1=5sh87q_V(p }8_MU^ Bv.5v oGQ08ވvoU( Sq}UtE#ﵔ^WGdeHBp}3O$[+ݸh/a NUÕs 2>R_}+AG2#(A5.NO U/uyNM=uzp=x eYq PA9U *IlUppy0Bُ4WÞFߙWT;'QѲ`C#ОlB܆;Ul>Y>"^sKO(KuTCh*Ɏi/q7+-eVv"!Qi?uL ܳ mZ鐮?q>UaΖWW {ׯj\3_j*I+px<Wϐ]XI 0 ȩH>nvBSo?d ᖻP|p[ w&`?0WSȭ@½Vq>kpp@%gtsXp^Ut]Nӗ *Ekq|{iNK@*ZI7 Tw| _=;.X`ep p7cv<܊ LA%{MDΙ/p&X\ Z&[B^gM s$L $mpkN 'w^À4M.x, | xB06^w7$ o-)5|#pGQx4mƊ/p  &/7ڎzs g~[ۃܥFbl+au"ٱJw!q}; ;;KqY|,?#xS[sguj@ҟ3sz^{ݍS;Hܼ .y^\gǔdNy r{H?7hOeoBw?͕-za Da ɶX(3S5Tg!M9t@5pfLfv~CcD5Yrw|aI'kL>r\6ryWD?0)nKJj)>ur2t#no7%7Y\G5rBg[dm=63(@DHacx8obnTwf tmCH:x| 0!יJ:< Pn -_+%Wr6'a -߁[fS?~8E>Jߧ@Hszu3vL#' >JcSC_hb@egurvV:S<;~!± ,tn]ȥY1~ Evz\Y7MTʇ,ܸ+j~~Mge ߁:}ppAf/˂}rEc7a0e?~=?W kU] >p.x>ۻVg!4CVܸ} p?>\ }XF/6*erM ˀ+QJLvg?BH3ytH{a83U22~m󉋚: 􆲫d{g;ϨdC)J0l !@M1P00`?GK-g5&<~[u=QO, b;>6"` BY7)gЖcFo0з 4 6)S*I;w^ 7P)3ugxSM/pX>Ք`*1Xh lk՛@Cvm *l$X*YL }AH0P3 k-d@#"S_`6g*eh(Tľ*`iOp1|K}mVsl߭-F@!pɗXC>elT/2ŬWi"F P&h4:Á лԓOGPH0P 0f?8V^@烐`Oag\/^(] meǣ0wsm j>Gꀁ~47 4;W!@1Ϩ$q[)$30Qq0PxU``Ը{h`O'G GPk| a2(V⋝d0m(~*3ʄGu@)X5|A߀(+- @*0g[n[qx0*4G%@ jcGYq @Q]bϹKZS!π Hgo>wت W ߈m~E\@PUL>J}+S;:0 @ B _Hn#Ͱ_߀@_ȔT7~8ӏv(a:'">cj^||/ :5$1+!@ICDG ?ޖĿ-ơ\.?+Ɂ[uFd ` {vZ׈or+.g9fng8UE`͹ Psc9- Pb&<$( T`b JGJeg C)1׀Rٍq8@PvJ` `R9໬qeg C)0p.>u7*RS A@0!X ;?4n*{7o YvHc3c.'1`xN~m.nz#\{< $#zUҫ` ]ljZ0/~ÞAѨ AJ[28jDwN5`_4 \ð\*!_P](8ʬ.Ijag E|0P O̚淌࢟BMu*1K0 qM3xz u})?`W a}9;0PΪLC^1WE`-x=kOqt[ i03a)Kh¿Y\؋~`Rq Ðg#@}2A?5ݯhU}-흥 'h0 R@}0_g-^ח F X 21tHODuÀa5!1@ t@`>`0 Cp4]L̀J L*4##@3>4 ahݯXL 'wE:Q?]NHjJj[0`'8芸bX+ #M2y}ؑ./nݺ#-$hJjj?w - ɛ0 MtOiϻѻH;W7G&c Cnc1qPΠW~.NI]$ahƳ}n80ө-]蜟͘ "I2IO|t8#0ElB3rMw mX,|J[IU 4.k?> ,~CWT0T(<{P$OP%M9 o)b.MOw+^*>N?$4Ӽ#yZ L$ \gñLx sE#{Was}2~^&p܂QUa?D#xtCq[; 7u؟U#*YeNAIų6'ہ rO2h1&3·ҘRiF9~\Ɏm5eg.Ttׁ)Y#t<0jT-B[jG5`pXxcZ\*[f` XN qg>PkܶڇxǐG# (tt%H^3KG@0֜ nc!RɚYE΀Un(˭e3Ÿw火r3pW| 2n#M6߂,J@s/_m;/J&ոe=%@1m,ΤJ F`>aT\DH0 4(u(+j$T2MV/n]~Ju#GF;-*{A'UĽE'S@^ ž|T`8 ۖg#WL`R`ʁ ؾɁ-+g,uw%Soӄa-?SPpl%c*$I~+El?Lkh^2 KAg9'ON5e{)8gI'}/RD/W?gOS|CUf @1*O`}y*>\B -%!]"P;O3ۛ2(R.?UϒfN܉e2-PH",Ӄ'n+!,Qvi|'WPo$kYʢ` hZTd?v`,@E>4v0OXAP*{}Orx xv'xi¬w,[:W)(mp3_`I]rq8h,Q1 @Vcͳ)CWuM徍_%"dP!4OyU@JQQܞ㻁}w,<:Ҽ[[tT*IwU)|TvKsRCs՝c}e|\5`&$* fQz=yg gH. 3߂i+K o"jiuIDAT _8V_Bg\0WoTnٸ4n<@3MT>U$mrǻ-pE#Q֭دDcyPqKGط{92@c2spyֻ 5fO+p=/Ace_M5?7|@0 0྿R;ѝ` Oqt0z-[z[It@0 T0 U 9`POg+ @P` ꉁ0 t@0 T0 U 9`POg+ @P` ꉁ0 t@0 T0 U 9`POg+ @P` ꉁ0 t@0 T0 U 9`POg+ @P` ꉁ0 t@0 T0 U 9`F+툿 K& TХs~s<SaqUaS~8T3">hN3IC턒 OEt0:cS|Y{AJa@0V *z7",`f<` :` CDT0 @f<` :` CDT0 XeIENDB`content/en/background.md0000644000175000056700000000270215226251677014036 0ustar0000000000000000Background ========== The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books *Patterns of Enterprise Application Architecture* and *Refactoring*. content/en/port-binding.md0000644000175000056700000000357115226251677014320 0ustar0000000000000000## VII. Port binding ### Export services via port binding Web apps are sometimes executed inside a webserver container. For example, PHP apps might run as a module inside [Apache HTTPD](http://httpd.apache.org/), or Java apps might run inside [Tomcat](http://tomcat.apache.org/). **The twelve-factor app is completely self-contained** and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app **exports HTTP as a service by binding to a port**, and listening to requests coming in on that port. In a local development environment, the developer visits a service URL like `http://localhost:5000/` to access the service exported by their app. In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes. This is typically implemented by using [dependency declaration](./dependencies) to add a webserver library to the app, such as [Tornado](http://www.tornadoweb.org/) for Python, [Thin](http://code.macournoyer.com/thin/) for Ruby, or [Jetty](http://www.eclipse.org/jetty/) for Java and other JVM-based languages. This happens entirely in *user space*, that is, within the app's code. The contract with the execution environment is binding to a port to serve requests. HTTP is not the only service that can be exported by port binding. Nearly any kind of server software can be run via a process binding to a port and awaiting incoming requests. Examples include [ejabberd](http://www.ejabberd.im/) (speaking [XMPP](http://xmpp.org/)), and [Redis](http://redis.io/) (speaking the [Redis protocol](http://redis.io/topics/protocol)). Note also that the port-binding approach means that one app can become the [backing service](./backing-services) for another app, by providing the URL to the backing app as a resource handle in the [config](./config) for the consuming app. content/ja/build-release-run.md0000644000175000056700000000700715226251677015231 0ustar0000000000000000## V. ビルド、リリース、実行 ### ビルド、リリース、実行の3つのステージを厳密に分離する [コードベース](./codebase)は3つのステージを経て、（開発環境ではない）デプロイへと変換される。 * *ビルドステージ* は、コードリポジトリを *ビルド* と呼ばれる実行可能な塊へと変える変換である。デプロイプロセスで指定したコミットのコードで指定されたバージョンを使って、ビルドステージは[依存関係](./dependencies)を取得してローカル環境に配置し、バイナリやアセットファイルをコンパイルする。 * *リリースステージ* は、ビルドステージで生成されたビルドを受け取り、それをデプロイの現在の[設定](./config)と結合する。出来上がる *リリース* にはビルドと設定の両方が含まれ、実行環境の中ですぐにでも実行できるよう準備が整う。 * *実行ステージ* （ランタイムとも呼ばれる）は、選択されたリリースに対して、アプリケーションのいくつかの[プロセス](./processes)を起動することで、アプリケーションを実行環境の中で実行する。 ![コードがビルドになり、ビルドと設定が結合されてリリースが作られる。](/images/release.png) **Twelve-Factor Appは、ビルド、リリース、実行の3つのステージを厳密に分離する。** 例えば、実行ステージにあるコードを変更してもその変更をビルドステージに伝える方法がないため、コードを実行中に変更することはあり得ない。 デプロイツールは通常、リリース管理ツールを提供する。中でも注目すべきは、以前のリリースにロールバックする機能である。例えばデプロイツールの[Capistrano](https://github.com/capistrano/capistrano/wiki)は、リリースを`releases`という名前のサブディレクトリに格納し、現在のリリースは現在のリリースのディレクトリへのシンボリックリンクとなる。Capistranoの`rollback`コマンドを使うと、簡単かつ即座に以前のリリースにロールバックできる。 すべてのリリースは常に一意のリリースIDを持つべきである。リリースIDの例としては、リリースのタイムスタンプ（例：`2011-04-06-20:32:17`）や連番（例：`v100`）がある。リリースは追記専用の台帳であり、一度作られたリリースは変更することができない。変更する場合は新しいリリースを作らなければならない。 ビルドステージは、新しいコードがデプロイされるときに必ずアプリケーションの開発者によって開始される。一方実行ステージは、サーバーの再起動時や、クラッシュしたプロセスがプロセスマネージャーによって再起動された時に自動で開始される。このため、実行ステージはできるだけ可変部分を持たないようにするべきである。なぜなら、アプリケーションの実行を妨げるような問題が起きると、開発者が待機していない真夜中にアプリケーションが壊れる結果になるためである。ビルドステージはもっと複雑でも構わない。なぜなら、ビルドステージのエラーは常にデプロイを実行している開発者の目の前で発生するためである。 content/ko/admin-processes.md0000644000175000056700000000521315226251677015022 0ustar0000000000000000## XII. Admin 프로세스 ### admin/maintenance 작업을 일회성 프로세스로 실행 [프로세스 포메이션](./concurrency)은 애플리케이션의 일반적인 기능들(예: Web request의 처리)을 처리하기 위한 프로세스들의 집합 입니다. 이와는 별도로, 개발자들은 종종 일회성 관리나 유지 보수 작업이 필요합니다. 그 예는 아래와 같습니다. * 데이터베이스 마이그레이션을 실행합니다. (예: Django에서 `manage.py migrate`, Rail에서 `rake db:migrate`) * 임의의 코드를 실행하거나 라이브 데이터베이스에서 앱의 모델을 조사하기 위해 콘솔([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) Shell로도 알려져 있는)을 실행합니다. 대부분의 언어에서는 인터프리터를 아무런 인자 없이 실행하거나(예: python, perl) 별도의 명령어로 실행(예: ruby의 irb, rails의 rails console)할 수 있는 REPL를 제공합니다. * 애플리케이션 저장소에 커밋된 일회성 스크립트의 실행 (예: php scripts/fix_bad_records.php) 일회성 admin 프로세스는 애플리케이션의 일반적인 [오래 실행되는 프로세스](./processes)들과 동일한 환경에서 실행되어야 합니다. 일회성 admin 프로세스들은 릴리즈를 기반으로 실행되며, 해당 릴리즈를 기반으로 돌아가는 모든 프로세스처럼 같은 [코드베이스](./codebase)와 [설정](./config)를 사용해야 합니다. admin 코드는 동기화 문제를 피하기 위해 애플리케이션 코드와 함께 배포되어야 합니다. 모든 프로세스 타입들에는 동일한 [종속성 분리](./dependencies) 기술이 사용되어야 합니다. 예를 들어, 루비 웹 프로세스가 `bundle exec thin start` 명령어를 사용한다면, 데이터베이스 마이그레이션은 `bundle exec rake db:migrate`를 사용해야합니다. 마찬가지로, virtualenv를 사용하는 파이썬 프로그램은 tornado 웹 서버와 모든 `manage.py` admin 프로세스가 같은 virtualenv에서의 `bin/python`을 사용해야 합니다. Twelve-Factor는 별도의 설치나 구성없이 REPL shell을 제공하는 언어를 강하게 선호합니다. 이러한 점은 일회성 스크립트를 실행하기 쉽게 만들어주기 때문입니다. 로컬 배포에서, 개발자는 앱을 체크아웃한 디렉토리에서 일회성 admin 프로세스를 shell 명령어로 바로 실행시킵니다. production 배포에서, 개발자는 ssh나 배포의 실행 환경에서 제공하는 다른 원격 명령어 실행 메커니즘을 사용하여 admin 프로세스를 실행할 수 있습니다.content/ru/disposability.md0000644000175000056700000001232515226251677014624 0ustar0000000000000000## IX. Утилизируемость (Disposability) ### Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы **[Процессы](./processes) приложения двенадцати факторов являются *утилизируемыми*, это означает, что они могут быть запущены и остановлены в любой момент.** Это способствует стабильному и гибкому масштабированию, быстрому развёртыванию изменений [кода](./codebase) и [конфигураций](./config) и надёжности рабочего развёртывания. Процессы должны стараться **минимизировать время запуска**. В идеале процесс должен затратить всего несколько секунд от момента времени, когда выполнена команда запуска, и до того момента, когда процесс запущен и готов принимать запросы или задачи. Короткое время запуска предоставляет большую гибкость для [релиза](./build-release-run) и масштабирования. Кроме того, это более надёжно, так как менеджер процессов может свободно перемещать процессы на новые физические машины при необходимости. Процессы должны **завершаться корректно, когда они получают [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** сигнал от диспетчера процессов. Для веб-процесса корректное завершение работы достигается путём прекращения прослушивания порта сервиса (таким образом, отказаться от каких-либо новых запросов), что позволяет завершить текущие запросы и затем завершиться. В этой модели подразумевается, что HTTP-запросы короткие (не более чем на несколько секунд), в случае длинных запросов клиент должен плавно попытаться восстановить подключение при потере соединения. Для процесса, выполняющего фоновые задачи (worker), корректное завершение работы достигается путём возвращения текущей задачи назад в очередь задач. Например, в [RabbitMQ](http://www.rabbitmq.com/) рабочий процесс может отправлять команду [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); в [Beanstalkd](https://beanstalkd.github.io) задача возвращается в очередь автоматически, когда рабочий процесс отключается. Системы, основанные на блокировках такие, как [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) должны быть уведомлены, чтобы освободить блокировку задачи. В этой модели подразумевается, что все задачи являются [повторно входимыми](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), что обычно достигается путём оборачивания результатов работы в транзакции или путём использования [идемпотентных](http://en.wikipedia.org/wiki/Idempotence) операций. Процессы также должны быть **устойчивыми к внезапной смерти** в случае отказа аппаратного обеспечения. Хотя это менее вероятное событие, чем корректное завершение работы сигналом `SIGTERM`, оно всё же может случиться. Рекомендуемым подходом является использование надёжных очередей задач, таких как Beanstalkd, которые возвращают задачу в очередь когда клиент отключается или превышает лимит времени. В любом случае приложение двенадцати факторов должно проектироваться так, чтобы обрабатывать неожиданные и неизящные выключения. [Архитектура только аварийного выключения (Crash-only design)](http://lwn.net/Articles/191059/) доводит эту концепцию до её [логического завершения](http://docs.couchdb.org/en/latest/intro/overview.html). content/tr/config.md0000644000175000056700000000710515226251677013211 0ustar0000000000000000## III. Yapılandırma ### Ortamda yapılandırma depolama Bir uygulamanın *yapılandırması* muhtemelen [dağıtımlar](./codebase) arasındaki değişikliktir(kademelendirme, ürün, geliştirici ortamları vb.). Bunları içerir: * Veri tabanını ele alan kaynaklar, önbellek ve diğer [destek servisleri](./backing-services) * Amazon S3 ve Twitter gibi dış servisler için kimlik bilgileri * Dağıtımlar için standart sunucu ismi gibi her dağıtım için değerler Uygulamalar bazen yapılandırmayı koddaki sabitler gibi saklar. Bu on iki faktörün, **yapılandırmayı koddan mutlak ayırmayı** gerektiren bir ihlalidir. Yapılandırma dağıtımlar arasında önemli derecede değişime uğrar, kod uğramaz. Bir uygulamanın tüm yapılandırmaları koddan doğru bir biçimde çıkarılıp çıkarılmadığına dair bir litot testi, herhangi bir kimlik bilgilerinden ödün vermeksizin kod tabanının her an açık kaynak yapıp yapamayacağına karar verir. Bu *yapılandırma* tanımlamasının, [Spring](http://spring.io/)'de [kod modullerinin bağlantısında](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) olduğu gibi ve Rails'de `config/routes.rb` gibi dahili uygulama yapılandırmasını **içermediğini** unutmayın. Bu tip yapılandırma dağıtımlar arasında değişiklik göstermez ve bu kod içinde en iyi şekilde gerçekleştirilmiştir. Yapılandırmaya diğer bir yaklaşım Rails'deki `config/database.yml` gibi gözden geçirme kontrolünde kontrol edilmemiş yapılandırma dosyalarının kullanımıdır. Bu kod deposundaki kontrol edilmiş sabitlerin kullanımındaki büyük bir gelişmedir, fakat hala zayıflıkları vardır: Depoda, yapılandırma dosyalarının kontrolünde hata kolay yapılabilir; Yapılandırma dosyalarının farklı yerlerde ve farklı formatlarda dağılmış olması için bir eğilim vardır, bu durum bütün yapılandırmayı bir yerde görmeyi ve yönetmeyi zorlaştırır. Bu formatların özel dil veya çatı olma eğilimi vardır. **On iki faktör uygulamalarında yapılandırma *ortam değişkenlerinde* kaydedilir**(sıklıkla *env vars* veya *env* olarak kısaltılır). Ortam değişkenleri herhangi bir kod değişikliği olmadan, dağıtımlar arasında kolay değişebilir; Yapılandırma dosyalarının aksine, kod deposunda yanlışlıkla kontrol edilme şansı az; ve özel yapılandırma dosyalarının veya Java sistem özellikleri gibi yapılandırma mekanizmalarının aksine, onlar dil ve işletim sisteminden etkilenmez. Yapılandırma yönetiminin diğer bir açısı da gruplandırmadır. Bazen uygulamalar, Rails'deki `geliştirme`, `test` ve `üretim` ortamları gibi belirli dağıtımlardan sonra adlandırılmış, adlandrılmış guruplar içinde yapılandırılır(genellikle "environments" olarak adlandırılır). Bu method temiz bir ölçüm yapmaz: uygulamanın daha fazla dağıtımı oluştuğu sürece, yeni ortam isimleri gereklidir, `staging` veya `qa` gibi. Projeler ilerde geliştikçe, geliştiriciler `joes-staging` kendi özel ortam değişkenlerini ekleyebilir, dağıtım yönetimini çok hassas yapan yapılandırmanın birleşimsel infilakıyla sonuçlanır. On iki faktör uygulamasında ortam değişkenleri parçacıklı kontrol edilirler, her biri diğer ortam değişkenlerine karşı suffix/prefix olarak gelmez ayrı tanımlanır. Asla "environments" olarak beraber gruplandırılamaz, fakat onun yerine her bir dağıtım için bağımsız yönetilir. Bu, uygulamayı yaşam süresi boyunca daha fazla dağıtıma genişletmeyi sorunsuzca büyüten bir modeldir. public/css/mobile.css0000644000175000056700000000336615226251677013357 0ustar0000000000000000@media screen and (min-width: 1041px) { section { min-width: 65em; } article, nav { max-width: 55em; } } @media screen and (min-width: 481px) and (max-width: 800px) { article img { float: none; display: block; margin: 0 auto; } } @media screen and (min-width: 481px) and (max-width: 1040px) { header { font-size: 1em; } article, nav { width:85%; min-width: none; max-width: none; } section, footer { width:100%; min-width: none; max-width: none; } article h1, article h2, article h3, article p, article table { padding-left: 15px; padding-right: 15px; } article ul, article ol { padding-left: 35px; padding-right: 10px; text-align: left; } article table { font-size: 0.8em; } article table td { padding-left: 0.25em; padding-right: 0.25em; } article img { max-width: 100%; margin-bottom: 1em; } nav a { padding:1em; } nav a { padding:1em; } footer { padding-left: 0; padding-right: 0; } } @media screen and (max-width: 480px) { header { font-size: 0.75em; } section, article, nav, footer { min-width: 320px; max-width: 480px; } article h1, article h2, article h3, article p, article table { padding-left: 15px; padding-right: 15px; text-align: left; } article ul, article ol { padding-left: 35px; padding-right: 10px; text-align: left; } article table { font-size: 0.5em; } article table td { padding-left: 0.25em; padding-right: 0.25em; } article img { max-width: 100%; margin-bottom: 1em; } nav a { padding: 1em; } footer { padding-left: 0; padding-right: 0; } }content/it/backing-services.md0000644000175000056700000000541515226251677015154 0ustar0000000000000000## IV. Backing Service ### Tratta i backing service come "risorse" Un "backing service" è un qualsiasi servizio che l'applicazione consuma attraverso la rete durante la sua esecuzione. Alcuni esempi includono i database (come [MySQL](http://dev.mysql.com/) o [CouchDB](http://couchdb.apache.org/)), servizi di messaging/code (come [RabbitMQ](http://www.rabbitmq.com/) oppure [Beanstalkd](https://beanstalkd.github.io)), servizi SMTP per la posta (come [Postfix](http://www.postfix.org/)) e sistemi di cache (come [Memcached](http://memcached.org/)). Un backing service (prendiamo ad esempio un database) è tradizionalmente gestito dallo stesso amministratore di sistema, al deployment dell'applicazione. In aggiunta a questi servizi gestiti in locale potrebbero esserne presenti altri, forniti da terze parti. Parliamo di servizi SMTP (come [Postmark](http://postmarkapp.com/)), servizi di raccolta metriche (come [New Relic](http://newrelic.com/) o [Loggly](http://www.loggly.com/)), servizi per asset (come [Amazon S3](http://aws.amazon.com/s3/)), e anche servizi accessibili via API (come [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), o [Last.fm](http://www.last.fm/api)). **Il codice di un'app twelve-factor non fa distinzioni tra servizi in locale o third party**. Per l'applicazione, entrambi sono risorse connesse, accessibili via URL (o tramite un altro locator) e credenziali memorizzate nell'opportuno file di [configurazione](./config). A un qualsiasi [deployment](./codebase) di un'applicazione twelve-factor si deve poter permettere di passare velocemente da un database MySQL locale a uno third party (come [Amazon RDS](http://aws.amazon.com/rds/)) senza alcuna modifica al codice. Allo stesso modo, un server SMTP locale dovrebbe poter essere cambiato con uno third party (come Postmark). In entrambi i casi, a cambiare dovrebbero essere **solo** i file di configurazione necessari. Ogni backing service è quindi definibile come una "risorsa connessa". Un Database MySQL è una risorsa. Due database MySQL (utilizzati per lo sharding a livello di applicazione) saranno visti come due distinte risorse. Un'app twelve-factor vede questi database come *risorse* anche per sottolineare la separazione dal deployment a cui fanno riferimento. Un deployment di produzione collegato a quattro backing service. Le risorse possono essere collegate e scollegate da un deployment a piacimento. Per esempio, supponiamo che il database dell'applicazione si comporti in modo anomalo per problemi hardware. L'amministratore potrebbe decidere di voler configurare un altro server di database ripreso da un recente backup. Il vecchio database verrebbe scollegato, quello nuovo connesso -- senza modifiche al codice.