diff --git a/content/uk/admin-processes.md b/content/uk/admin-processes.md index 19b876297..f9dd1e829 100644 --- a/content/uk/admin-processes.md +++ b/content/uk/admin-processes.md @@ -1,7 +1,7 @@ ## XII. Задачі адміністрування ### Виконуйте задачі адміністрування/керування за допомогою разових процесів -[Формація процесів](./concurrency) є певним набором процесів, які необхідні для виконання регулярних задач застосунку (наприклад, обробка веб-запитів). Разом з тим, розробникам часто необхідно виконувати разові адміністративні задачі для обслуговування застосунку, такі як: +[Формація процесів](./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). @@ -9,6 +9,6 @@ Разові процеси адміністрування слід запускати в такому ж середовищі, в якому запущені регулярні [тривалі процеси](./processes) застосунку. Вони запускаються на базі [релізу](./build-release-run), використовуючи ту ж [кодову базу](./codebase) і [конфігурацію](./config), як і будь-який інший процес на базі цього релізу. Для уникнення проблем з синхронізацією код адміністрування має поставлятися з кодом застосунку. -Для всіх типів процесів мають використовуватися однакові методи [ізоляції залежностей](./dependencies). Наприклад, якщо веб-процес Ruby використовує команду `bundle exec thin start`, то для міграції бази даних слід використовувати `bundle exec rake db:migrate`. Аналогічно, для програми на Python з Virtualenv слід використовувати `bin/python` як для запуску веб-сервера Tornado, так і для запуску будь-яких `manage.py` процесів адміністрування. +Для всіх типів процесів мають використовуватися однакові методи [ізоляції залежностей](./dependencies). Наприклад, якщо вебпроцес Ruby використовує команду `bundle exec thin start`, то для міграції бази даних слід використовувати `bundle exec rake db:migrate`. Аналогічно, для програми на Python з Virtualenv слід використовувати `bin/python` як для запуску вебсервера Tornado, так і для запуску будь-яких `manage.py` процесів адміністрування. -Методологія дванадцяти факторів надає перевагу мовам, які мають REPL "з коробки", і які дозволяють легко запускати разові скрипти. У локальному development середовищі розробник може запустити процес адміністрування за допомогою консольної команди всередині директорії застосунку. У production середовищі для запуску такого процесу розробники можуть використовувати ssh або інший механізм віддаленого виконання команд, що надається середовищем виконання. \ No newline at end of file +Методологія дванадцяти факторів надає перевагу мовам, які мають REPL "з коробки", і які дозволяють легко запускати разові скрипти. У локальному development середовищі розробник може запустити процес адміністрування за допомогою консольної команди всередині директорії застосунку. У production середовищі для запуску такого процесу розробники можуть використовувати ssh або інший механізм віддаленого виконання команд, що надається середовищем виконання. diff --git a/content/uk/background.md b/content/uk/background.md index fb1c16ccf..ac27b2e2b 100644 --- a/content/uk/background.md +++ b/content/uk/background.md @@ -3,6 +3,6 @@ Люди, що працювали над цим документом, брали безпосередню участь в розробці і розгортанні сотень застосунків, і мимоволі стали свідками розвитку, експлуатації та масштабування сотень тисяч застосунків під час нашої роботи над платформою [Heroku](http://www.heroku.com/). -В цьому документі узагальнюється весь наш досвід використання і спостереження за найрізноманітнішими SaaS-застосунками "в дикій природі". Документ об'єднує ідеальні практики розробки застосунків, особлива увага приділяється динаміці органічного росту застосунку з плином часу, взаємодії між розробниками, які працюють над кодом застосунку, та [уникненню витрат при ерозії програмного забезпечення](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/). +В цьому документі узагальнюється весь наш досвід використання і спостереження за найрізноманітнішими 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)*. \ No newline at end of file +Наша мета полягає в тому, щоб підвищити обізнаність про деякі системні проблеми, які ми бачили в практиці розробки сучасних застосунків, а також в тому, щоб сформулювати спільні загальні поняття для обговорення цих проблем, і запропонувати набір загальних концептуальних рішень цих проблем з супутньою термінологією. Формат навіяний книгами Мартіна Фаулера (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)*. diff --git a/content/uk/backing-services.md b/content/uk/backing-services.md index ee2457558..90e56493d 100644 --- a/content/uk/backing-services.md +++ b/content/uk/backing-services.md @@ -1,14 +1,14 @@ ## 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/)) тощо. +*Стороння служба* — це будь-яка служба потрібна для нормальної роботи застосунку, до якої застосунок отримує доступ за допомогою мережевого зʼєднання, наприклад: бази даних ([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)). +Допоміжні служби, такі як бази даних, традиційно управляються тими ж системними адміністраторами, які розгортають застосунок. Окрім локальних служб, застосунок може також використовувати служби, що надаються і керуються сторонніми постачальниками: 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) без зміни коду. В обох випадках необхідно змінити лише налаштування відповідного ресурсу в конфігурації застосунку. +**Код 12-факторного застосунку не робить різниці між локальними та сторонніми сервісами.** Для застосунку кожен з них є підʼєднаним ресурсом, доступним за URL-адресою або іншими даними, що зберігаються в [конфігурації](./config). [Розгортання](./codebase) 12-факторного застосунку повинно мати можливість, наприклад, замінити локальну базу даних MySQL на будь-яку іншу, що надається стороннім постачальником (наприклад, [Amazon RDS](http://aws.amazon.com/rds/)), без жодних змін в коді застосунку. Крім того, локальний сервер SMTP може бути замінений на сторонній SMTP-сервіс (наприклад, Postmark) без змін в коді. В обох випадках необхідно змінити лише налаштування відповідного ресурсу в конфігурації застосунку. -Кожна окрема стороння служба є *ресурсом*. Наприклад, база даних MySQL є ресурсом; дві бази даних MySQL (що використовуються для шардінгу на рівні застосунку) кваліфікуються як два різних ресурси. Застосунок дванадцяти факторів сприймає ці бази даних як *підключені ресурси*, що вказує на їхній слабкий зв'язок з розгортанням, в якому вони підключені. +Кожна окрема стороння служба є *ресурсом*. Наприклад, база даних MySQL є ресурсом; дві бази даних MySQL (що використовуються для шардінгу на рівні застосунку) вважаються двома різними ресурсами. 12-факторний застосунок сприймає ці бази даних як *підключені ресурси*, що вказує на їхню слабку привʼязку до розгортання, до якого вони підключені. -production-розгортання, в якому підключені чотири сторонні служби +production-розгортання, в якому використовуються чотири сторонні служби -Ресурси за необхідності можуть бути підключені та відключені до розгортання застосунку. Наприклад, якщо база даних застосунку функціонує некорекно у зв'язку з апаратними проблемами, адміністратор може запустити новий сервер бази даних, відновленої з останньої резервної копії. Поточна база даних може бути відключена, а нова база даних підключена — все це без будь-яких змін коду. +Ресурси за необхідності можуть бути додані та прибрані з розгортання застосунку. Наприклад, якщо база даних застосунку функціонує некоректно у звʼязку з апаратними проблемами, адміністратор може підняти новий сервер бази даних, скориставшись останньою резервною копією. Поточна база даних може бути відʼєднанна, а нова база даних підʼєднана — все це без будь-яких змін коду застосунку. diff --git a/content/uk/build-release-run.md b/content/uk/build-release-run.md index eaaed6b44..28df7f740 100644 --- a/content/uk/build-release-run.md +++ b/content/uk/build-release-run.md @@ -1,18 +1,18 @@ ## V. Збірка, реліз, виконання -### Суворо відокремлюйте етапи збірки та виконання +### Чітко відокремлюйте етапи збірки та виконання [Кодова база](./codebase) перетворюється в розгортання (крім розгортання для розробки) у три етапи: -* *Етап збірки* — це трансформація, яка перетворює код в репозиторії у пакунок, що може бути запущений, і який називається *збірка*. Використовуючи версію коду за вказаним у процесі розгортання коммітом, етап збірки завантажує [залежності](./dependencies) та компілює бінарні файли і ресурси (assets). -* *Етап релізу* приймає збірку, отриману на етапі збірки, і об'єднує її з поточною [конфігурацією](./config) розгортання. Отриманий *реліз* містить збірку і конфігурацію і готовий до негайного запуску в середовищі виконання. -* *Етап виконання* (також відомий як "runtime") запускає застосунок у середовищі виконання, увімкнувши деякий набір [процесів](./processes) застосунку з певного релізу. +* *Етап збірки* — це трансформація, яка перетворює код з репозиторію у пакунок, що може бути запущений, і який називається *збірка*. Використовуючи версію коду за вказаним у процесі розгортання коммітом, етап збірки завантажує [залежності](./dependencies) та компілює бінарні файли та ресурси (assets). +* *Етап релізу* використовує пакунок, отриманий на етапі збірки, обʼєднує його з поточною [конфігурацією](./config) розгортання. Отриманий *реліз*, що містить збірку та конфігурацію, готовий до негайного запуску в середовищі виконання. +* *Етап виконання* (також відомий як "runtime") виконує застосунок у середовищі виконання, запускаючи певний набір [процесів](./processes) застосунку з обраного релізу. ![Код стає збіркою, яка поєднується з конфігурацією для створення релізу.](/images/release.png) -**Застосунок дванадцяти факторів дотримується суворого відокремлення етапів збірки, релізу і виконання.** Наприклад, не можна вносити зміни в код під час етапу виконання, оскільки немає способу поширити ці зміни назад на етап збірки. +**12-факторний застосунок дотримується правила чіткого відокремлення етапів збірки, релізу і виконання.** Наприклад, не можна вносити зміни в код під час етапу виконання, оскільки немає способу поширити ці зміни назад на етап збірки. Інструменти розгортання, як правило, надають засоби керування релізами, які дають можливість відкату до попередньої версії. Наприклад, інструмент розгортання [Capistrano](https://github.com/capistrano/capistrano/wiki) зберігає релізи в підкаталог з назвою `releases`, де поточний реліз є символічним посиланням на каталог поточного релізу. Команда Capistrano `rollback` дає можливість швидко виконати відкат до попередньої версії. -Кожен реліз повинен завжди мати унікальний ідентифікатор, наприклад, мітку часу релізу (наприклад, `2011-04-06-20:32:17`) або номер, що зростає (наприклад, `v100`). Релізи можуть тільки додаватися, неможливо змінити реліз після його створення. Будь-які зміни мають створювати новий реліз. +Кожен реліз повинен завжди мати унікальний ідентифікатор, це може бути мітка часу релізу (наприклад, `2011-04-06-20:32:17`) або номер, що зростає (наприклад, `v100`). Релізи можуть тільки додаватися, неможливо змінити реліз після його створення. Будь-які зміни мають створювати новий реліз. -Збірка ініцюється розробником застосунку щоразу при розгортанні нового коду. Запуск етапу виконання, навпаки, може відбуватися автоматично в таких випадках, як перезавантаження сервера або перезапуск процесу, шо впав, менеджером процесів. Таким чином, етап виконання має бути максимально технічно простим, бо проблеми, які заважають застосунку запуститися, можуть призвести до його зупинки посеред ночі, коли розробників немає на місці. Етап збірки може бути більш складним, бо можливі помилки завжди видимі розробнику, який запустив процес розгортання. \ No newline at end of file +Збірка ініціюється розробником застосунку щоразу при розгортанні нового коду. Запуск етапу виконання, навпаки, може відбуватися автоматично в таких випадках, як перезавантаження сервера або перезапуск процесу, що впав, менеджером процесів. Таким чином, етап виконання має бути максимально технічно простим, бо проблеми, які заважають застосунку запуститися, можуть призвести до його зупинки посеред ночі, коли розробників немає на місці. Етап збірки може бути складнішим, бо можливі помилки завжди видимі розробнику, який запустив процес розгортання. diff --git a/content/uk/codebase.md b/content/uk/codebase.md index 75e86bf68..51331f69b 100644 --- a/content/uk/codebase.md +++ b/content/uk/codebase.md @@ -1,17 +1,17 @@ ## I. Кодова база -### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань +### Одна кодова база, що відстежується в системі контролю версій та має багато розгортань -Застосунок дванадцяти факторів завжди відслідковуються в системі контролю версій, такій як [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) або [Subversion](http://subversion.apache.org/). Копія бази даних відстеження ревізій називається *репозиторій коду (code repository)*, що часто скорочується до *code repo* або просто *repo*. +12-факторний застосунок завжди відстежується в системі контролю версій, такій як [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) або [Subversion](http://subversion.apache.org/). Копія бази даних відстеження ревізій називається *репозиторій коду (code repository)*, що часто скорочується до *code repo* або просто *repo*. -*Кодова база* — це один репозиторій (в централізованих системах контролю версій, як Subversion), або декілька репозиторіїв, які мають спільний початковий комміт (в децентралізованих системах контролю версій, як Git). +*Кодова база* — це один репозиторій (в централізованих системах контролю версій, як Subversion), або декілька репозиторіїв, які мають спільний початковий комміт (в децентралізованих системах контролю версій, як Git). -![Одна кодова база — багатьо розгортань](/images/codebase-deploys.png) +![Одна кодова база — багато розгортань](/images/codebase-deploys.png) Завжди існує однозначна відповідність між кодовою базою і застосунком: -* За наявності кількох баз коду, це не застосунок, це — розподілена система. Кожен компонент в розподіленій системі є застосунком, і кожен з них може окремо дотримуватися дванадцяти факторів. -* Кілька різних застосунків, що спільно використовують загальну базу коду, є порушенням дванадцяти факторів. Рішенням в даній ситуації є виділення загального коду в бібліотеки, які можуть бути підключені через [менеджер залежностей](./dependencies). +* За наявності кількох баз коду, це не застосунок, це — розподілена система. Кожен компонент в розподіленій системі є застосунком, і кожен з них може окремо дотримуватися дванадцяти факторів. +* Кілька різних застосунків, що спільно використовують загальну базу коду, є порушенням цих дванадцяти факторів. Рішенням в даній ситуації є виділення загального коду в бібліотеки, які можуть бути підключені через [менеджер залежностей](./dependencies). -Існує тільки одна кодова база для кожного застосунку, але може бути багато розгортань одного і того самого застосунку. *Розгортанням (deploy)* є запущений екземпляр застосунку. Це, як правило, production-сайт і один або більше staging-сайтів (проміжних розгортань). Крім того, розробник має копію застосунку, запущеного в його локальному середовищі розробки. Кожну з таких копій також можна кваліфікувати як розгортання (deploy). +Існує тільки одна кодова база для кожного застосунку, але може бути багато розгортань одного і того самого застосунку. *Розгортанням (deploy)* є запущений екземпляр застосунку. Це, як правило, production-сайт і один або більше staging-сайтів (проміжних розгортань). Крім того, розробник також має копію застосунку, запущеного в його локальному середовищі розробки. Кожну з таких копій також можна кваліфікувати як розгортання (deploy). -Кодова база має бути єдина для всіх розгортань, хоча в кожному розгортанні можуть бути активні різні її версії. Наприклад, розробник може мати деякі зміни у коді, які ще не додані в staging-розгортання; staging-розгортання може мати деякі зміни, які ще не додані в production-розгортання. Але всі вони використовують одну і ту саму кодову базу, таким чином можна їх ідентифікувати як різні розгортання одного і того ж застосунку. \ No newline at end of file +Кодова база має бути єдина для всіх розгортань, хоча в кожному розгортанні можуть бути активні різні її версії. Наприклад, розробник може мати деякі зміни у коді, які ще не додані в staging-розгортання; staging-розгортання може мати деякі зміни, які ще не додані в production-розгортання. Але всі вони використовують одну і ту саму кодову базу, таким чином можна їх ідентифікувати як різні розгортання одного і того ж застосунку. diff --git a/content/uk/concurrency.md b/content/uk/concurrency.md index de609a2c8..0ad359624 100644 --- a/content/uk/concurrency.md +++ b/content/uk/concurrency.md @@ -1,14 +1,14 @@ -## VIII. Конкурентність +## VIII. Паралелізм ### Масштабуйте застосунок за допомогою процесів -Будь-яка комп'ютерна програма після запуску представлена одним або декількома процесами. Веб-додатки мають різні форми виконання процесів. Наприклад, PHP-процеси виконуються як дочірні процеси Apache, які запускаються в разі потреби в залежності від навантаження. Java-процеси використовують протилежний підхід: JVM забезпечує один масивний мета-процес, який резервує велику кількість системних ресурсів (процесора і пам'яті) під час його запуску, і керує конкурентністю всередині себе за допомогою потоків виконання (threads). В обох випадках запущені процеси видимі для розробників застосунку мінімально. +Будь-яка компʼютерна програма після запуску представляється одним або декількома процесами. Вебзастосунки мають різні форми виконання процесів. Наприклад, 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). +**В 12-факторному застосунку, процеси є сутностями першого класу.** Процеси в 12-факторному застосунку взяли сильні сторони від [моделі процесів 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/). Але індивідуальна віртуальна машина може масшабуватися тільки обмежено (вертикальне масшабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів на декількох фізичних машинах. +Це не виключає можливості використання індивідуального мультиплексування для окремих процесів через потоки виконання віртуальної машини або асинхронні/подієві моделі в таких інструментах, як [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) або [Node.js](http://nodejs.org/). Але окрема віртуальна машина може масштабуватися тільки обмежено (вертикальне масштабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів, що працюють на кількох фізичних машинах. -Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування. [Відсутність розділених даних і горизонтальне розділення процесів застосунку дванадцяти факторів](./processes) означає, що додавання більшої конкурентності є простою і надійною операцією. Масив типів процесів і кількість процесів кожного типу називається *формацією процесів*. +Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування. [Відсутність розділених даних і горизонтальне розділення процесів 12-факторного застосунку](./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), реагування на падіння процесів і обробку ініційованих користувачем перезавантаження чи завершення роботи. +Процеси 12-факторного застосунку [ніколи не мають ставати системними](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), реагування на падіння процесів і обробку ініційованих користувачем перезавантажень чи завершення роботи. diff --git a/content/uk/config.md b/content/uk/config.md index 8205ba784..268d30049 100644 --- a/content/uk/config.md +++ b/content/uk/config.md @@ -1,22 +1,22 @@ ## III. Конфігурація -### Зберігайте конфігурацію в середовищі виконання +### Зберігайте конфігурацію як частину оточення -*Конфігурація* застосунку — це все, що може змінюватися між [розгортаннями](./codebase) (staging-розгортання, production-розгортання, локальне середовище розробника тощо). Це включає: +*Конфігурація* застосунку — це все, що може змінюватися між [розгортаннями](./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/routes.rb` в Rails, або [як повʼязані основні модулі](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) в [Spring](http://spring.io/). Ці налаштування не змінюються між розгортаннями, і тому краще місце для них — саме в коді. -Іншим підходом до конфігурації є використання конфігураційних файлів, що не зберігаються в систему контролю версій, таких як `сonfig/database.yml` в Rails. Це перевага у порівнянні з використанням констант в коді, але все ж таки має суттєві недоліки: є ймовірність помилково зберегти файл конфігурації в репозиторій; існує тенденція коли конфігураційні файли розкидані в різних місцях і в різних форматах, і стає важко передивлятися всі налаштування і керувати ними в одному місці. Крім того, формати цих файлів, як правило, специфічні для конкретної мови програмування чи фреймворку. +Іншим підходом до конфігурації є використання конфігураційних файлів, що не зберігаються в системі контролю версій, таких як `сonfig/database.yml` в Rails. Це перевага у порівнянні з використанням констант в коді, але все ж таки має суттєві недоліки: є ймовірність помилково зберегти файл конфігурації в репозиторій; існує тенденція коли конфігураційні файли розкидані в різних місцях і в різних форматах, і стає важко передивлятися всі налаштування і керувати ними в одному місці. Крім того, формати цих файлів, як правило, специфічні для конкретної мови програмування чи фреймворку. -**Застосунок дванадцати факторів зберігає конфігурацію в *змінних оточення*** (часто скорочується до *env vars* або *env*). Значення змінних оточення легко змінити між розгортаннями без зміни коду; на відміну від конфігураційних файлів, менш ймовірно випадково зберегти їх в репозиторій коду; і на відміну від конфігураційних файлів або інших механізмів конфігурації, таких як Java System Properties, вони є стандартом, незалежним від мови програмування чи фреймворку. +**12-факторний застосунок зберігає конфігурацію в *змінних оточення*** (часто скорочується до *env vars* або *env*). Значення змінних оточення легко змінити між розгортаннями без зміни коду; на відміну від конфігураційних файлів, менш ймовірно випадково зберегти їх в репозиторій коду; і на відміну від конфігураційних файлів або інших механізмів конфігурації, таких як Java System Properties, вони є стандартом, незалежним від мови програмування чи операційної системи. -Іншим аспектом керування конфігурацією є групування. Іноді застосунки об'єднують конфігурації в іменовані групи (які часто називаються "оточеннями"), які називаються в залежності від конкретного розгортання, наприклад, `development`, `test` і `production` оточення в Rails. Цей метод погано масштабується: чим більше створюється різних розгортань застосунку, тим більше необхідно нових імен оточень, наприклад, `staging` або `qa`. При подальшому рості проекту розробники можуть додавати свої власні спеціальні оточення, наприклад, `joes-staging`, що призводить до комбінаторного вибуху конфігурації, який робить керування розгортанням застосунку нестабільним. +Іншим аспектом керування конфігурацією є групування. Іноді застосунки обʼєднують конфігурації в іменовані групи (які часто називаються "оточеннями"), які називаються в залежності від конкретного розгортання, наприклад, `development`, `test` і `production` оточення в Rails. Цей метод погано масштабується: чим більше створюється різних розгортань застосунку, тим більше необхідно нових імен оточень, наприклад, `staging` або `qa`. При подальшому рості проєкту розробники можуть додавати свої власні спеціальні оточення, наприклад, `joes-staging`, що призводить до комбінаторного вибуху конфігурації, який робить керування розгортанням застосунку нестабільним. -У застосунку дванадцяти факторів змінні оточення є незв'язаними між собою засобами керування. Кожна змінна повністю незалежна від інших. Вони ніколи не групуються разом в "оточення", керування ними здійснюється незалежно для кожного розгортання. Ця модель добре масштабується разом з появою більшої кількості розгортань застосунку протягом його експлуатації. \ No newline at end of file +У 12-факторному застосунку змінні оточення є незвʼязаними між собою засобами керування. Кожна змінна повністю незалежна від інших. Вони ніколи не групуються разом в "оточення", керування ними здійснюється незалежно для кожного розгортання. Ця модель добре масштабується разом з появою більшої кількості розгортань застосунку протягом його експлуатації. diff --git a/content/uk/dependencies.md b/content/uk/dependencies.md index 64dde9f30..b6e22c23d 100644 --- a/content/uk/dependencies.md +++ b/content/uk/dependencies.md @@ -3,10 +3,10 @@ Більшість мов програмування мають системи пакунків для розповсюдження бібліотек, такі як [CPAN](http://www.cpan.org/) для Perl або [Rubygems](http://rubygems.org/) для Ruby. Бібліотеки, встановлені через систему пакунків, можуть бути доступними для всієї системи (так звані "site-packages") або встановлені в каталог застосунку (так звані "vendoring" або "bundling"). -**Застосунок дванадцяти факторів ніколи не залежить від неявно існуючих, досупних всій системі пакунків.** Застосунок повно і точно вказує всі свої залежності за допомогою маніфесту *оголошення залежностей*. Крім того, він використовує інструмент *ізоляції залежністей* під час виконання, щоб гарантувати, що ніякі неявні залежності не "просочилися" з зовнішньої системи. Повна і явна специфікація залежностей використовується однаково як при розробці, так і в production. +**12-факторний застосунок ніколи не покладається на неявне існування загальносистемних пакунків.** Застосунок повно і точно вказує всі свої залежності за допомогою маніфесту *оголошення залежностей*. Крім того, він використовує інструмент *ізоляції залежностей* під час виконання, щоб гарантувати, що ніякі неявні залежності не "просочилися" з зовні, з оточуючої системи. Повна і явна специфікація залежностей використовується однаково як при розробці, так і в експлуатації. -Наприклад, [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/) для оголошення залежностей, а статичне зв'язування може забезпечити ізоляцію залежностей. Який би не використовувався набір інструментів, оголошення і ізоляція залежностей завжди мають використовуватися разом — тільки одне або інше не є достатньою умовою для задоволення дванадцяти факторів. +Наприклад, [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`. У той час, як ці інструменти можуть бути встановлені на багатьох або навіть більшості систем, немає жодної гарантії, що вони будуть встановлені на всіх системах, де застосунок може запускатися в майбутньому, або версія інструменту, встановлена в системі, буде сумісна з застосунком. Якщо застосунку потрібно запускати певні системні інструменти, то такі інструменти мають бути включені в сам застосунок. \ No newline at end of file +12-факторний застосунок також ніколи не залежить від будь-яких неявно присутніх системних інструментів. Прикладом може бути запуск застосунком таких системних інструментів, як ImageMagick або `curl`. У той час, як ці інструменти можуть бути встановлені на багатьох або навіть більшості систем, немає жодної гарантії, що вони будуть встановлені на всіх системах, де застосунок може запускатися в майбутньому, або версія інструменту, встановлена в системі, буде сумісна з застосунком. Якщо застосунку потрібно запускати певні системні інструменти, то такі інструменти мають бути включені в сам застосунок. diff --git a/content/uk/dev-prod-parity.md b/content/uk/dev-prod-parity.md index d31c57991..9fa6801ce 100644 --- a/content/uk/dev-prod-parity.md +++ b/content/uk/dev-prod-parity.md @@ -1,25 +1,25 @@ -## X. Dev/prod паритет +## X. Паритет між розробкою та експлуатацією ### Прагніть максимальної ідентичності development, staging та production середовищ Історично склалося, що є суттєві відмінності між development середовищем (розробник вносить живі зміни в [локально розгорнутий](./codebase) застосунок) і production середовищем (до якого мають доступ кінцеві користувачі). Ці відмінності проявляються в трьох областях: * **Різниця в часі**: Розробник може працювати над кодом, який потрапить у production через дні, тижні або навіть місяці; * **Різниця в персоналі**: Розробники пишуть код, Ops-інженери розгортають його; -* **Різниця в інструментах**: Розробники можуть використовувати стек технологій такий, як Nginx, SQLite та OS X, в той час як на production використовується Apache, MySQL та Linux. +* **Різниця в інструментах**: Розробники можуть використовувати стек технологій такий, як Nginx, SQLite та OS X, в той час, як на production використовується Apache, MySQL та Linux. -**Застосунок дванадцяти факторів проектується для [безперервного розгортання](http://avc.com/2011/02/continuous-deployment/), завдяки мінімізації різниці між production і development середовищами.** Розглянемо три відмінності, описані вище: +**12-факторний застосунок проєктується для [безперервного розгортання](http://avc.com/2011/02/continuous-deployment/), завдяки мінімізації різниці між production і development середовищами.** Розглянемо три відмінності, описані вище: -* Зменшити різницю в часі: розробник може написати код і він буде розгорнутий через декілька годин або навіть хвилин; -* Зменшити різницю в персоналі: розробники, які писали код, беруть активну участь в його розгортанні і спостерігають за його поведінкою на production; -* Зменшити різницю в інструментах: тримати development та production середовища максимально ідентичними. +* Зменшення різниці в часі: розробник може написати код і він буде розгорнутий через декілька годин або навіть хвилин; +* Зменшення різниці в персоналі: розробники, які писали код, беруть активну участь в його розгортанні та спостерігають за його поведінкою на production; +* Зменшення різниці в інструментах: зберігайте середовище розробки та експлуатації якомога подібнішими. -Резюмуючи сказане вище в таблицю: +Узагальнимо сказане вище в таблицю: - + @@ -27,18 +27,18 @@ - + - +
Традиційний застосунокЗастосунок дванадцати факторів12-факторний застосунок
Час між розгортаннямиГодини
Автор коду/той хто розгортаєАвтор коду/Той хто розгортає Різні люди Ті ж люди
Dev/Prod розгортання РізніМаксимально ідентичніЯкомога подібніші
-[Сторонні служби](./backing-services), такі як бази даних, системи черг повідомлень або кеш, є однією з областей, де dev/prod паритет має важливе значення. Багато мов програмування мають бібліотеки, які спрощують доступ до сторонніх служб, в тому числі, *адаптери* для різних видів сервісів. Деякі приклади наведені в таблиці нижче. +[Сторонні служби](./backing-services), такі як бази даних, системи черг повідомлень або кеш, є однією з областей, де dev/prod паритет має важливе значення. Багато мов програмування мають бібліотеки, які спрощують доступ до сторонніх служб, в тому числі *адаптери* для різних видів сервісів. Деякі приклади наведені в таблиці нижче. @@ -63,14 +63,14 @@ - +
Кеш Ruby/Rails ActiveSupport::CacheПам'ять, файлова система, MemcachedПамʼять, файлова система, Memcached
-Іноді розробники бачать переваги у використанні "легких" сторонніх служб в їхньому локальному середовищі, в той час як більш серйозні і надійні сторонні служби будуть використовуватися у production. Наприклад, локально використовують SQLite, а на production PostgreSQL; або локально пам'ять процесу для кешування, а на production Memcached. +Іноді розробники бачать переваги у використанні "легких" сторонніх служб в їхньому локальному середовищі, в той час, як більш серйозні та надійні сторонні служби будуть використовуватися у production. Наприклад, локально використовують SQLite, а на production PostgreSQL; або локально памʼять процесу для кешування, а на production Memcached. -**Розробник застосунку дванадцяти факторів уникає використання різних сторонніх служб в development і production середовищах**, навіть якщо адаптери теоретично абстраговані від будь-яких відмінностей у сторонніх службах. Відмінності між сторонніми службами означають, що може виникнути крихітна несумісність, в результаті чого код, який працював і пройшов тестування в development та staging середовищах, після розгортання не працює в production середовищі. Такий тип помилок створює перешкоди, які нівелюють переваги безперервного розгортання. Ціна цих перешкод і подальшого відновлення безперервного розгортання надзвичайно висока, якщо розглядати в сукупності за весь час експлуатації застосунку. +**Розробник 12-факторного застосунку уникає використання різних сторонніх служб в 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 паритету і безперервного розгортання. +Встановлення локально "легких" сторонніх сервісів вже не є таким привабливим, як було раніше. Сучасні надійні сторонні сервіси, такі як Memcached, PostgreSQL і RabbitMQ, досить легко встановити та запустити завдяки сучасним менеджерам пакунків, таким як [Homebrew](https://brew.sh) і [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Крім того, декларативні інструменти підготовки середовища, такі як [Chef](http://www.opscode.com/chef/) і [Puppet](http://docs.puppetlabs.com/), у поєднанні з "легким" віртуальним середовищем, таким як [Docker](https://www.docker.com/) та [Vagrant](https://www.vagrantup.com/), дозволяють розробникам запускати локальні середовища, які наближені до production. Ціна встановлення і використання цих систем є низькою у порівнянні з користю dev/prod паритету і безперервного розгортання. -Адаптери для різних сторонніх сервісів все ж корисні, тому що вони роблять перенесення застосунку для використання з іншими сторонніми сервісами відносно безболісним. Але всі розгортання застосунку (development, staging та production середовища) мають використовувати один і той самий тип і версію кожного зі сторонніх сервісів. \ No newline at end of file +Адаптери для різних сторонніх сервісів все ж корисні, тому що вони роблять перенесення застосунку для використання з іншими сторонніми сервісами відносно безболісним. Але всі розгортання застосунку (development, staging та production середовища) мають використовувати один і той самий тип і версію кожного зі сторонніх сервісів. diff --git a/content/uk/disposability.md b/content/uk/disposability.md index 1aa86f6dd..7a2633dbf 100644 --- a/content/uk/disposability.md +++ b/content/uk/disposability.md @@ -1,12 +1,12 @@ -## IX. Утилізовуваність -### Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення +## IX. Одноразовість +### Максимізуйте надійність за допомогою швидкого запуску та коректного вимкнення -**[Процеси](./processes) застосунку дванадцати факторів є *утилізовуваними*, тобто вони можуть бути запущені або зупинені в будь-який момент.** Це сприяє гнучкому масштабуванню, швидкому розгортанню [коду](./codebase) або змінам [конфігурації](./config) і надійності production-розгортання. +**[Процеси](./processes) 12-факторного застосунку є *одноразовими*, вони можуть бути запущені або зупинені в будь-який момент.** Це сприяє гнучкому масштабуванню, швидкому розгортанню [коду](./codebase) або змінам [конфігурації](./config) та надійності production-розгортання. -Слід намагатися **мінімізувати час запуску процесів**. В ідеалі час між моментом виконання команди запуску процесу і моментом, коли процес готовий приймати запити чи задачі, має тривати лише пару секунд. Короткий час запуску забезпечує більшу гнучкість для [релізу](./build-release-run) і масштабування. Крім того, це підвищує стійкість, оскільки менеджер процесів може легко переміщувати процеси на нові фізичні машини у разі необхідності. +Слід намагатися **мінімізувати час запуску процесів**. В ідеалі час між моментом виконання команди запуску процесу і моментом, коли процес готовий приймати запити чи задачі, має тривати лише декілька секунд. Короткий час запуску забезпечує більшу гнучкість для випуску [релізів](./build-release-run) і масштабування. Крім того, це підвищує надійність, оскільки менеджер процесів може легко переміщувати процеси на нові фізичні машини у разі необхідності. -Процеси мають **коректно завершувати свою роботу, коли вони отримують [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** сигнал від диспетчеру процесів. Для веб-процесу коректне завершення роботи досягається завдяки припиненню прослуховування порту, до якого він прив'язаний (що означає відмову від отримання будь-яких нових запитів), завершенню обробки будь-яких поточних запитів та зупинці самого процесу. В цій моделі передбачається, що HTTP-запити короткі (не більше ніж кілька секунд), а у разі довгих запитів (long polling) клієнт має намагатися відновити з'єднання у разі його втрати. +Процеси мають **коректно завершувати свою роботу, коли вони отримують сигнал [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) операцій. +Для процесу, що виконує фонові задачі (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). +Процеси також мають бути **стійкими до раптової зупинки** в разі відмови апаратних засобів, на яких вони запущені. Хоча це менш ймовірна подія, ніж коректне завершення роботи за допомогою сигналу `SIGTERM`, вона все ж таки може статися. Рекомендованим підходом є використання надійних черг завдань, таких як Beanstalkd, які повертають завдання в чергу задач, коли клієнти втрачають зʼєднання або відʼєднуються по тайм-ауту. У будь-якому випадку, 12-факторний застосунок має проєктуватися таким чином, щоб обробляти несподівані та некоректні припинення роботи. Реалізація архітектури ["тільки аварійного вимкнення" (Crash-only design)](http://lwn.net/Articles/191059/) доводить цю концепцію до [логічного завершення](http://docs.couchdb.org/en/latest/intro/overview.html). diff --git a/content/uk/intro.md b/content/uk/intro.md index 736e89c77..5cdb5f621 100644 --- a/content/uk/intro.md +++ b/content/uk/intro.md @@ -1,12 +1,18 @@ Вступ ===== -У наш час програмне забезпечення зазвичай поставляється у вигляді сервісів, що називаються *веб-застосунки* (web-apps) або *software-as-a-service* (SaaS). Застосунок дванадцяти факторів — це методологія для створення SaaS-застосунків, які: +У наш час програмне забезпечення зазвичай поставляється у вигляді сервісів, що називаються _веб-застосунки_[^web-apps] або _програмне-забезпечення-як-послуга_[^saas]. 12-факторний застосунок — це методологія для створення SaaS-застосунків, які: -* Використовують **декларативний** формат для автоматизації встановлення та налаштування, що зводить до мінімуму витрати часу і коштів для нових розробників, що приєднуються до проекту; -* Мають **угоду** з операційною системою, пропонуючи **максимальну переносимість** між середовищами виконання; -* Придатні для **розгортання** на сучасних **хмарних платформах**, що усуває необхідність у серверах та їх системному адмініструванні; -* **Мінімізують різницю** між середовищем розробки і production середовищем, що дозволяє **безперервне розгортання** (continuous deployment) для забезпечення максимальної спритності розробки (agility); -* Можуть **масштабуватися** без значних змін в інструментах, архітектурі і практиці розробки. +* Використовують **декларативний** формат для автоматизації встановлення та налаштування, що зводить до мінімуму витрати часу і коштів для нових розробників, що приєднуються до проєкту; +* Мають **чітке узгодження** з операційною системою, пропонуючи **максимальну переносимість** між середовищами виконання; +* Придатні для **розгортання** на сучасних **хмарних платформах**, що усуває необхідність у власних серверах та їх системному адмініструванні; +* **Мінімізують розбіжності** між середовищем розробки і середовищем експлуатації[^prod], що дозволяє здійснювати **безперервне розгортання**[^cd] для забезпечення максимальної спритності розробки[^agile]; +* Можуть **масштабуватися** без значних змін щодо інструментів, архітектури та підходу до розробки. -Методологію дванадцяти факторів можна використати для застосунків, що написані будь-якою мовою програмування та використовують будь-яку комбінацію із сторонніх служб (бази даних, черги, кеш-пам'ять тощо). \ No newline at end of file +Методологія дванадцяти факторів може бути застосована до застосунків, написаних будь-якою мовою програмування, і які використовують будь-яку комбінацію додаткових служб (бази даних, черги, кеш-памʼять тощо). + +[^web-apps]: web-apps +[^saas]: software-as-a-service, SaaS +[^prod]: production +[^cd]: continuous deployment +[^agile] agility diff --git a/content/uk/logs.md b/content/uk/logs.md index 324dc0b39..a837ee251 100644 --- a/content/uk/logs.md +++ b/content/uk/logs.md @@ -1,15 +1,15 @@ ## XI. Журналювання -### Сприймайте журналювання (logs) як потоки подій +### Вважайте журналювання (logs) потоками подій *Журналювання* забезпечує наочне уявлення про поведінку запущеного застосунку. Зазвичай у серверних середовищах журнали записуються у файл на диску ("logfile"), але це лише один з форматів виведення. -Журнал — це [потік](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) агрегованих, впорядкованих за часом подій, зібраних з потоків виведення всіх запущених процесів і сторонніх сервісів. Журнал в сирому вигляді, як правило, має текстовий формат з однією подією на кожен рядок (хоча трасування винятків можуть займати кілька рядків). Журнали не мають фіксованого початку і кінця, потік безперервний поки працює застосунок. +Журнал — це [потік](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) агрегованих, впорядкованих за часом подій, зібраних з потоків виводу всіх запущених процесів і сторонніх сервісів. Журнал в необробленому вигляді, як правило, подається в текстовому форматі з однією подією на кожен рядок (хоча трасування винятків можуть займати кілька рядків). Журнали не мають фіксованого початку і кінця, потік безперервний поки працює застосунок. -**Застосунок дванадцяти факторів ніколи не займається маршрутизацію і зберіганням свого потоку виведення.** Застосунок не повинен записувати журнал у файл або керувати файлами журналів. Замість цього кожен запущений процес записує свій потік подій без буферизації в стандартне виведення `stdout`. В development середовищі розробник має можливість переглядати цей потік в терміналі, щоб спостерігати за поведінкою застосунку. +**12-факторний застосунок ніколи не переймається маршрутизацією і зберіганням свого потоку виведення.** Застосунок не повинен записувати журнал у файл або керувати файлами журналів. Замість цього кожен запущений процес записує свій потік подій без буферизації в стандартний вивід `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/). Ці системи мають широкі можливості і гнучкість для детального аналізу поведінки застосунку протягом тривалого часу, в тому числі: +Потік подій застосунку може бути направлений у файл або переглянутий у терміналі в режимі реального часу. Найважливішим є те, що потік може бути направлений у систему індексування та аналізу журналів, таку як [Splunk](http://www.splunk.com/), або систему зберігання даних загального призначення, таку як [Hadoop/Hive](http://hive.apache.org/). Ці системи мають широкі можливості та гнучкість для детального аналізу поведінки застосунку протягом тривалого часу, в тому числі: * Виявлення конкретних подій у минулому; * Побудова графіків трендів (наприклад, кількість запитів за хвилину); diff --git a/content/uk/port-binding.md b/content/uk/port-binding.md index 99ae00cb7..16fc5e249 100644 --- a/content/uk/port-binding.md +++ b/content/uk/port-binding.md @@ -1,14 +1,14 @@ -## VII. Прив'язка портів -### Експортуйте сервіси за допомогою прив'язки портів (port binding) +## VII. Привʼязка портів +### Експортуйте сервіси за допомогою привʼязки портів (port binding) -Веб-застосунки іноді запускаються всередині контейнера веб-сервера. Наприклад, PHP-застосунок може бути запущений як модуль всередині [Apache HTTPD](http://httpd.apache.org/) або Java-застосунок може бути запущений всередині [Tomcat](http://tomcat.apache.org/). +Вебзастосунки іноді запускаються всередині контейнера вебсервера. Наприклад, PHP-застосунок може бути запущений як модуль всередині [Apache HTTPD](http://httpd.apache.org/) або Java-застосунок може бути запущений всередині [Tomcat](http://tomcat.apache.org/). -**Застосунок дванадцяти факторів є повністю автономним** і в процесі виконання, щоб створити веб-сервіс, доступний через web, не покладається на ін'єкцію веб-сервера в середовище виконання. Веб-застосунок **експортує HTTP-сервіс шляхом прив'язки до порту** і прослуховує запити, що надходять на цей порт. +**12-факторний застосунок є повністю самодостатнім** і в процесі виконання, щоб створити вебсервіс, доступний через web, не покладається на вживлення вебсервера в середовище виконання. Вебзастосунок **експортує HTTP-сервіс шляхом привʼязки до порту** та прослуховує запити, що надходять на цей порт. -У локальному development середовищі розробник відвідує URL-адресу вигляду `http://localhost:5000/` для доступу до сервісу, що експортується застосунком. При розгортанні рівень маршрутизації обробляє запити до загальнодоступного хосту і перенаправляє їх до порту, до якого прив'язано веб-процес. +У локальному 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. Це відбувається повністю в *просторі користувача*, тобто в коді застосунку. Прив'язка до порту для обробки запитів є "угодою" із середовищем виконання. +Як правило, це реалізується за допомогою [оголошення залежностей](./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)). +HTTP — не єдиний сервіс, який може бути експортований шляхом привʼязки портів. Майже будь-яке серверне програмне забезпечення може бути запущено за допомогою процесу привʼязки до порту та очікування вхідних запитів. Прикладами є [ejabberd](http://www.ejabberd.im/) (використовує [XMPP](http://xmpp.org/)) і [Redis](http://redis.io/) (використовує [протокол Redis](http://redis.io/topics/protocol)). -Також зверніть увагу, що підхід прив'язки до портів означає, що застосунок може виступати як [стороння служба](./backing-services) для іншого застосунку, надаючи свою URL-адресу як ресурс в [конфігурації](./config) застосунку-споживача. \ No newline at end of file +Також зверніть увагу, що підхід привʼязки до портів означає, що застосунок може виступати як [стороння служба](./backing-services) для іншого застосунку, надаючи свою URL-адресу як ресурс в [конфігурації](./config) застосунку-споживачу. diff --git a/content/uk/processes.md b/content/uk/processes.md index f3baa70cc..09be95c8b 100644 --- a/content/uk/processes.md +++ b/content/uk/processes.md @@ -1,14 +1,14 @@ ## VI. Процеси -### Запускайте застосунок як один або декілька процесів без збереження внутрішньго стану (stateless) +### Запускайте застосунок як один або декілька процесів без збереження внутрішнього стану (stateless) Застосунок запускається в середовищі виконання у вигляді одного або декількох *процесів*. -У найпростішому випадку код є окремим скриптом, середовище виконання — ноутбук розробника зі встановленим середовищем виконання мови програмування, а процес запускається за допомогою командного рядка (наприклад, `python my_script.py`). В іншому випадку, це може бути production-розгортання складного застосунку, яке може використовувати багато [типів процесів, кожен з яких запущений у необхідній кількості екземплярів](./concurrency). +У найпростішому випадку код є окремим скриптом, середовище виконання — ноутбук розробника зі встановленим середовищем виконання мови програмування, а сам процес запускається з командного рядка (наприклад, `python my_script.py`). В іншому випадку, це може бути production-розгортання складного застосунку, яке може використовувати багато [типів процесів, кожен з яких запущений у необхідній кількості екземплярів](./concurrency). -**Процеси застосунку дванадцяти факторів не зберігають внутрішній стан (stateless) і [не розділяють ресурси](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Будь-які дані, що підлягають збереженню, мають зберігатися в [сторонній службі](./backing-services) зі збереженням внутрішнього стану (stateful) (як правило, в базі даних). +**Процеси 12-факторного застосунку не зберігають внутрішній стан (stateless) і [не розділяють ресурси](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Будь-які дані, що підлягають збереженню, мають зберігатися в [сторонній службі](./backing-services) зі збереженням внутрішнього стану (stateful) (як правило, в базі даних). -Пам'ять та файлова система процесу можуть бути використані як короткостроковий кеш. Наприклад, завантаження, обробка і збереження великого файлу в базі даних. Застосунок дванадцяти факторів ніколи не припускає, що щось, закешоване в пам'яті або на диску, буде доступне при наступному запиті — за наявності багатьох запущених процесів різних типів є велика ймовірність, що наступний запит буде оброблений іншим процесом. Навіть при роботі тільки одного процесу перезапуск (викликаний розгортанням, змінами конфігурації або переміщенням процесу в інше фізичне місце розташування середовищем виконання), як правило, призведе до знищення всіх локальних (у пам'яті і файловій системі) станів. +Памʼять та файлова система процесу можуть бути використані як короткостроковий кеш. Наприклад, завантаження, обробка і збереження великого файлу в базі даних. 12-факторний застосунок ніколи не передбачає, що щось, закешоване в памʼяті або на диску, буде доступне при наступному запиті — за наявності багатьох запущених процесів різних типів є велика ймовірність, що наступний запит буде оброблений іншим процесом. Навіть при роботі тільки одного процесу перезапуск (викликаний розгортанням, змінами конфігурації або переміщенням процесу середовищем виконання в інше фізичне місце розташування), як правило, призведе до знищення всіх локальних (у памʼяті та файловій системі) станів. -Пакувальники ресурсів (наприклад, [Jammit](http://documentcloud.github.io/jammit/) або [django-compressor](http://django-compressor.readthedocs.org/)) використовують файлову систему як кеш для скомпільованих ресурсів. Застосунок дванадцяти факторів надає перевагу здійсненню такої компіляції під час [етапу збірки](./build-release-run), наприклад, як в [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html), а не під час виконання. +Пакувальники ресурсів (наприклад, [django-assetpackager](http://code.google.com/p/django-assetpackager/) використовують файлову систему як кеш для скомпільованих ресурсів. 12-факторний застосунок надає перевагу здійсненню такої компіляції під час [етапу збірки](./build-release-run). Пакувальники ресурсів, такі як [Jammit](http://documentcloud.github.io/jammit/) або [Rails asset pipeline](http://ryanbigg.com/guides/asset_pipeline.html) можуть бути налаштовані для виконання пакування ресурсів під час стадії збірки. -Деякі веб-системи покладаються на ["липкі сесії"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) — тобто кешують дані сесії користувача в пам'яті процесу застосунку і очікують, що наступні запити від того ж самого користувача будуть спрямовані до того ж самого процесу. Липкі сесії є порушенням дванадцяти факторів і їх ніколи не слід використовувати та покладатися на них. Дані сесії користувача є хорошим кандидатом для сховища даних, яке надає функцію обмеження терміну зберігання, наприклад, [Memcached](http://memcached.org/) або [Redis](http://redis.io/). \ No newline at end of file +Деякі вебсистеми покладаються на ["липкі сесії"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) — тобто кешують дані сесії користувача в памʼяті процесу застосунку та очікують, що наступні запити від того ж самого користувача будуть спрямовані до того ж самого процесу. Липкі сесії є порушенням дванадцяти факторів і їх ніколи не слід використовувати чи покладатися на них. Дані сесії користувача є хорошим кандидатом для сховища даних, яке надає функцію обмеження терміну зберігання, наприклад, [Memcached](http://memcached.org/) або [Redis](http://redis.io/). diff --git a/content/uk/toc.md b/content/uk/toc.md index b9f5cb23e..dc2b36ded 100644 --- a/content/uk/toc.md +++ b/content/uk/toc.md @@ -2,37 +2,37 @@ =================== ## [I. Кодова база](./codebase) -### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань +### Одна кодова база, що відстежується в системі контролю версій та має багато розгортань ## [II. Залежності](./dependencies) ### Явно оголошуйте та ізолюйте залежності ## [III. Конфігурація](./config) -### Зберігайте конфігурацію в середовищі виконання +### Зберігайте конфігурацію як частину оточення ## [IV. Сторонні служби](./backing-services) -### Вважайте сторонні служби (backing services) підключеними ресурсами +### Вважайте сторонні служби (backing services) підʼєднуваними ресурсами ## [V. Збірка, реліз, виконання](./build-release-run) -### Суворо відокремлюйте етапи збірки та виконання +### Чітко відокремлюйте етапи збірки та виконання ## [VI. Процеси](./processes) -### Запускайте застосунок як один або декілька процесів без збереження внутрішньго стану (stateless) +### Запускайте застосунок як один або декілька процесів без збереження внутрішнього стану (stateless) -## [VII. Прив'язка портів](./port-binding) -### Експортуйте сервіси за допомогою прив'язки портів (port binding) +## [VII. Привʼязка портів](./port-binding) +### Експортуйте сервіси за допомогою привʼязки портів (port binding) -## [VIII. Конкурентність](./concurrency) +## [VIII. Паралелізм](./concurrency) ### Масштабуйте застосунок за допомогою процесів -## [IX. Утилізовуваність](./disposability) -### Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення +## [IX. Одноразовість](./disposability) +### Максимізуйте надійність за допомогою швидкого запуску та коректного вимкнення -## [X. Dev/prod паритет](./dev-prod-parity) +## [X. Паритет між розробкою та експлуатацією](./dev-prod-parity) ### Прагніть максимальної ідентичності development, staging та production середовищ ## [XI. Журналювання](./logs) -### Сприймайте журналювання (logs) як потоки подій +### Вважайте журналювання (logs) потоками подій ## [XII. Задачі адміністрування](./admin-processes) -### Виконуйте задачі адміністрування/керування за допомогою разових процесів \ No newline at end of file +### Виконуйте задачі адміністрування/керування за допомогою разових процесів diff --git a/content/uk/who.md b/content/uk/who.md index 2041a0c75..86377007b 100644 --- a/content/uk/who.md +++ b/content/uk/who.md @@ -1,4 +1,4 @@ -Кому слід читати цей документ? -============================== +Хто повинен прочитати цей документ? +=================================== -Розробникам, які створюють SaaS-застосунки. Ops-інженерам, які виконують розгортання і керування такими застосунками. \ No newline at end of file +Будь-хто з розробників, які створюють застосунки, які працюють як послуги. Ops-інженери, які розгортають або керують такими застосунками.