Практична автоматизація: Принципи автоматизації розгортання додатків, частина 2

1. Серія контенту:
2. Цей контент є частиною серії: Практична автоматизація
3. Про цю серії
4. Малюнок 1. Принципи автоматизації розгортання
5. Компілюйте один раз, розвертайте багаторазово в різних середовищах
6. Малюнок 2. Один Web-архів розгортається в декількох різних цільових середовищах
7. Здешевлення процесу розгортання за допомогою одноразових контейнерів
8. Розгортання одним натисканням на кнопку
9. Малюнок 3. Видалення і установка контейнера в процесі розгортання
10. Лістинг 1. Приклад скрипта розгортання Ant, який видаляє, встановлює, запускає і налаштовує контейнер
11. Виконання команд в декількох зовнішніх середовищах
12. Малюнок 4. Сервер управління складанням і віддалене розгортання в декількох середовищах
13. Лістинг 2. Безпечне копіювання файлу war з одного комп'ютера на інший
14. Переклад бази даних в відоме стан
15. Малюнок 5. Автоматизований процес послідовного внесення змін до бази даних
16. Лістинг 3. Запуск довільного скрипта SQL в складі набору змін LiquiBase
17. Перевірка успішності процедури розгортання
18. Малюнок 6. Виконання функціональних тестів додатки в процесі розгортання
19. Лістинг 4. Виконання перевірок перед процедурою розгортання для гарантії її успішності
20. Таблиця 1. Види перевірок при розгортанні додатки
21. Відкат змін, внесених в результаті розгортання
22. Малюнок 7. Схема скасування змін, внесених в процесі розгортання
23. Лістинг 5. Приклад вказівки процесу відкату при описі змін в базі даних
24. Захист інформації від цікавих очей
25. Малюнок 8. Використання захищеного сховища системи контролю версій для зберігання конфіденційних файлів
26. Лістинг 6. Захист сховища Subversion з використанням Apache
27. Розгортання одним натисканням на кнопку
28. На цьому все
29. Ресурси для скачування

практична автоматизація

Ще кілька способів організації процесу розгортання одним натисканням на кнопку

Серія контенту:

Цей контент є частиною # з серії # статей: Практична автоматизація

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Практическая+автоматизация

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Практична автоматизація

Слідкуйте за виходом нових статей цієї серії.

Розгортання - це ще один аспект створення програмного продукту, який добре піддається автоматизації. Це дозволяє отримати всі переваги надійного процесу: підвищити точність, швидкість і контроль над виконанням потрібних дій. В першій частині були розглянуті вісім принципів автоматизованого розгортання додатків. У цій статті ми поговоримо про наступні семи не менше корисних принципах:

• Принцип двійковій узгодженості, який гарантує, що жоден артефакт НЕ буде втрачено в процесі розгортання програми в цільових середовищах.
• Принцип одноразового контейнера, відповідно до якого середовище для розгортання повинна переводитися в заздалегідь відоме стан. Завдяки цьому знижується ймовірність помилок.
• Принцип віддаленого розгортання, що гарантує взаємодію з кількома віддаленими серверами з центрального комп'ютера або кластера.
• Принцип оновлення бази даних, цілями якого є організація і централізоване управління скриптовою процесом для виконання послідовних змін в базі даних.
• Принцип тестування розгортання, відповідно до якого перед розгортанням і після нього повинні виконуватися спеціальні перевірки, щоб переконатися, що додаток працює як очікується.
• Принцип відкату середовища, який повертає до програми та базу даних в початковий стан в разі невдалого розгортання.
• Принцип захисту файлів, який наказував би обмежувати доступ до певних файлів, що використовується системою збірки додатку.

Про цю серії

Оскільки ми є розробниками, наше завдання полягає в автоматизації праці кінцевих користувачів. При цьому багато хто з нас не приділяють достатньо уваги автоматизації своєї власної праці. серія статей jsp?search_by=%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F+%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F:> практична автоматизація присвячена практичним принципам автоматизації процесу розробки та відповідає на питання, коли і як їх слід застосовувати.

На малюнку 1 показано взаємодію між принципами розгортання, описаними в цій статті (незафарбовані прямокутники відповідають принципам, розглянутим в попередній статті ).

Малюнок 1. Принципи автоматизації розгортання

Дотримання даними семи додаткових принципів організації автоматизованого розгортання укупі з вісьмома, представленими в попередній статті, допоможуть вам розгортати ваші програми одним натисненням на кнопку.

Компілюйте один раз, розвертайте багаторазово в різних середовищах

Назва. Двійкова узгодженість

Принцип. Один архів (WAR або EAR) використовується при розгортанні додатки в різних цільових середовищах.

Протилежний принцип. Додаток компілюється окремо для кожного середовища розгортання.

Після численних суперечок з колегами на цю тему я твердо вирішив дотримуватися точки зору, яку можна сформулювати, як "компілюйте один раз для всіх середовищ розгортання" (протилежним є підхід "компілюйте систему під щосереди розгортання"). Наприклад, артефактом при розгортанні Web-додатків на Java є файл Web-архіву (WAR) або корпоративного архіву (EAR). Цей файл повинен міститися в систему контролю версій і позначатися тегом один раз (наприклад, DEV для середовища розробки).

Принцип одноразової компіляції і багаторазового розгортання ілюструється на малюнку 2, відповідно до якого файл brewery.war створюється на сервері збірки, а потім розгортається в кожній з цільових середовищ.

Малюнок 2. Один Web-архів розгортається в декількох різних цільових середовищах

Ant включає завдання checksum, реалізовану на основі хешірующего алгоритму MD5 (Message-Digest 5), для перевірки того, що архів з скомпільований додатком, сформований на сервері збірки, не змінюється при розгортанні в кожній з цільових середовищ.

Існує думка, що хоча при розгортанні може використовуватися один артефакт, конфігурація може відрізнятися для кожного середовища. Іншими словами, при автоматичному скриптовій розгортанні багато автономні процеси можуть змінювати вміст файлів, незважаючи на те, що вони будуть розміщені в один і той же архів. Це вірно, але при цьому не виключено, що ви даремно витратите багато часу, намагаючись визначити причину проблеми, яка, наприклад, полягає в тому, що додаток було скомпільовано під однією версією JDK в середовищі для випробувань, а запущено під інший в середовищі для оцінки якості. Крім того, ризик проблем ще зросте, якщо версії JAR-файлів в центральному репозиторії сторонніх бібліотек (наприклад, Ivy або Maven), які використовуються в середовищі розробки, відрізняються від тих, які використовуються в середовищі для випробувань. Ці чинники все більше переконують мене в тому, що для гарантії бінарної узгодженості необхідно компілювати і формувати архів з додатком один раз, і цей архів потім може бути розгорнуто в різних середовищах.

Здешевлення процесу розгортання за допомогою одноразових контейнерів

Назва. одноразовий контейнер

Принцип. Автоматизація установки і конфігурації контейнерів бази даних і Web шляхом відділення цих етапів розгортання один від одного.

Протилежний принцип. Ручна установка і конфігурація контейнерів для кожного середовища розгортання.

В одній з попередніх статей серії jsp?search_by=%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F+%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F:> практична автоматизація під заголовком Невдалі принципи безперервної інтеграції, частина 2 пояснювалося яким чином очищення "брудного" оточення допомагає уникнути помилкових (негативних або позитивних) результатів збірки. Підхід на основі використання одноразового контейнера дозволяє уникнути багатьох проблем, пов'язаних з використанням постійних контейнерів. Даний підхід ґрунтується на двох принципах: по-перше, слід повністю видалити всі компоненти контейнера перед розгортанням, а по-друге - розділити етапи установки і конфігурації контейнера. Кому-то, особливо системним інженерам, це може здатися радикальним рішенням, оскільки контейнери, в основному, повинні управлятися окремою командою фахівців, як це було раніше, коли розробники взагалі не повинні були торкатися до контейнерів. Проте, беручи до уваги важко усуваються проблеми, які можуть виникнути в процесі розгортання, всі члени команди повинні в підсумку зійтися на найбільш виграшному вирішенні.

Розгортання одним натисканням на кнопку

Мені часто доводилося чути від розробників: "Так, у нас організувати процес автоматичного розгортання". При цьому у відповідь на прості питання, наприклад: "Чи можете ви розгорнути робоче додаток шляхом введення всього однієї команди", - я, як правило, чув щось на кшталт: "Так, як тільки встановлений і налаштований Web-контейнер ..." або : "Так, залишиться тільки створити і наповнити базу даних". Особисто я вважаю, що дійсно автоматичне розгортання - це коли достатньо встановити тільки платформу Java і Ant на чисту машину (до речі, навіть це можна автоматизувати), а потім ввести всього одну команду для розгортання програми. Якщо ви не можете це зробити, то ваш процес не можна назвати "розгортанням одним натисканням на кнопку" і як наслідок можуть виникати важко розв'язні проблеми, зумовлені людським фактором.

В основі принципу одноразового контейнера, показаного на малюнку 3, лежить філософія, яка полягає в тому, що всі об'єкти і процедури, необхідні для розгортання, повинні перебувати в репозиторії (див. Принцип "Репозиторій" в попередній статті ), А не в чиїйсь голові.

Малюнок 3. Видалення і установка контейнера в процесі розгортання

Скрипт Ant, наведений у лістингу 1, завантажує ZIP-архів з Tomcat з Інтернету, видаляє всі сліди попередньої спроби розгортання, а потім розпаковує, встановлює і запускає Tomcat.

Лістинг 1. Приклад скрипта розгортання Ant, який видаляє, встановлює, запускає і налаштовує контейнер

Переклад середовища в заздалегідь відоме стан і контроль над розгортанням контейнерів дозволяють знизити ризик появи багатьох поширених помилок, які доставляють найбільше проблем при розгортанні додатків.

Виконання команд в декількох зовнішніх середовищах

Назва. віддалене розгортання

Принцип. Використання центрального сервера або кластера для розгортання програми в декількох цільових середовищах

Протилежний принцип. Ручне розгортання програми в кожному середовищі локальних чином.

Після того як були встановлені Web-контейнер і сервер бази даних, запуск процесу розгортання на робочому комп'ютері розробника, як правило, досить тривіальний. Проте існує безліч відмінностей між середовищами розробки та експлуатації програми. Якщо в компанії ведеться кілька проектів і підтримується кілька середовищ, в яких може бути розгорнуто додаток (наприклад, для тестування та симуляції), то часто буває необхідно управляти процесом розгортання централізовано, тобто з одного комп'ютера або кластера. Нерідко розробники використовують сервер збірки для управління розгортання у всіх середовищах. В першій частині розповідалося про принцип використання автономних процесів, відповідно до якого застосовуються публічні і секретні ключі, завдяки яким не доводиться вручну підключатися до кожного комп'ютера. Принцип віддаленого розгортання, показаний на малюнку 4, в свою чергу заснований на принципах автономного виконання, єдиної команди і розгортання за допомогою скриптів, завдяки яким весь процес значно спрощується.

Малюнок 4. Сервер управління складанням і віддалене розгортання в декількох середовищах

Для розгортання програми з центрального сервера збірки віддаленим чином необхідно використовувати механізми безпечного копіювання та віддаленого виконання команд. У даній статті ілюструються два таких механізму - безпечне копіювання (Secure Copy - SCP) і безпечний командний інтерпретатор (Secure Shell - SSH). У лістингу 2 показано, як Web-архів, згенерований скриптами розгортання на центральному сервері збірки, потім копіюється на віддалений комп'ютер.

Лістинг 2. Безпечне копіювання файлу war з одного комп'ютера на інший

Після того як WAR-файл був безпечним чином скопійований в віддалену середу, можна використовувати Ant-завдання SSHExec і віддалено виконувати команди SSH через безпечний канал Java (Java Secure Channel) з центрального сервера збірки. Також можна підключитися до віддаленого комп'ютера через ssh і виконувати всі команди локально. Це дозволить знизити трафік і скоротити загальний час розгортання.

Переклад бази даних в відоме стан

Назва. Оновлення бази даних

Принцип. Використовуйте скрипти для послідовного внесення змін до бази даних в кожному середовищі розгортання.

Протилежний принцип. Ручне зміна вмісту бази даних в кожному середовищі розгортання.

На малюнку 5 показана схема використання скриптів для автоматичного оновлення бази даних в процесі розгортання програми.

Малюнок 5. Автоматизований процес послідовного внесення змін до бази даних

У ранній статті серії "Практична автоматизація" під назвою Автоматичне перенесення бази даних розповідалося про необхідність автоматизації процесу внесення послідовних змін в базу даних. Оновлення бази даних є частиною процесу скриптового розгортання, а значить, всі скрипти повинні зберігатися в центральному репозиторії.

LiquiBase (див. Розділ ресурси ) Є прикладом застосування для послідовного оновлення бази даних. При цьому одні й ті ж зміни вносяться в кожному середовищі при виконанні скриптів розгортання. У лістингу 3 показаний SQL-скрипт, який є частиною набору змін (changelog) LiquiBase. Подібні набори змін описуються в XML, а потім виконуються в процесі скриптового розгортання. Як правило, скрипти викликаються засобами, аналогічними Ant.

Лістинг 3. Запуск довільного скрипта SQL в складі набору змін LiquiBase

Ці питання аж ніяк не вичерпують тему автоматичного оновлення бази даних, але головним моментом в ній є те, що всі зміни повинні вноситися в процесі виконання скриптів розгортання. Таким чином, всі зміни є частиною system розгортання, а не просто процедурою, записаної на папері або в чиїйсь голові.

Перевірка успішності процедури розгортання

Назва. тестування розгортання

Принцип. Скрипти розгортання повинні включати можливості тестування успішності свого виконання.

Протилежний принцип. Результат розгортання перевіряється вручну шляхом запуску функціональних тестів, які не перевіряють конкретні аспекти процедури розгортання.

На малюнку 6 показаний приклад запуску тестів перед процедурою розгортання і після неї.

Малюнок 6. Виконання функціональних тестів додатки в процесі розгортання

У лістингу 4 наведено приклад використання Ant для виконання тестів перед процедурою розгортання з метою перевірки того, що використовуються коректні версії програм. В процесі скриптового розгортання скрипти можуть перевіряти, чи не зайняті чи потрібні порти (оскільки в цьому випадку запуск Web-контейнера завершиться невдачею), встановлено з'єднання з базою даних, запущені всі потрібні контейнери, а також виконувати інші внутрішні тести.

Лістинг 4. Виконання перевірок перед процедурою розгортання для гарантії її успішності

У розширений варіант тестів можуть також входити перевірки коректності функціонування програми. Ви можете створювати автоматичні функціональні тести, специфічні для конкретного процесу розгортання, за допомогою таких засобів, як Selenium (для Web-додатків) або Abbot (для клієнтських додатків). З їх допомогою можна перевіряти успішне внесення всіх змін при розгортанні. Подібні тести являють собою мінімальні перевірки цілісності системи (smoke tests): вони тестують тільки функціональність, яка змінилася в процесі розгортання. У таблиці 1 наведено ряд способів використання Selenium та інших засобів для тестування Web-додатки.

Таблиця 1. Види перевірок при розгортанні додатки

Автоматизовані тести служать не тільки для перевірки функціональності, з якої безпосередньо працюють користувачі. Вони також можуть перевіряти успішність процесу розгортання, таким чином знижуючи ризик подальших помилок і витрати на розробку системи.

Відкат змін, внесених в результаті розгортання

Назва. відкат середовища

Принцип. Автоматичний відкат всіх змін після невдалого розгортання. Ця операція повинна проводитися шляхом введення єдиної команди.

Протилежних принцип. Ручна скасування всіх змін в додатку і базі даних.

На малюнку 7 показаний процес відкату змін в базі даних, а також автоматичне скасування результатів розгортання Web-додатки.

Малюнок 7. Схема скасування змін, внесених в процесі розгортання

Незалежно від того, використовуєте ви автоматизовану процедуру розгортання чи ні, бажано мати можливість відкотити результати в разі, якщо щось піде не так. Можливі ситуації, в яких помилково внесені зміни можуть привести до виходу системи з ладу, що може обійтися компанії в мільйони доларів. Відкат середовища означає, що оточення вашого застосування повинно бути повернуто до стану, в якому воно перебувало до спроби розгортання. Для цього необхідно мати скрипт для відкату кожного внесеного зміни. При цьому при розгортанні Web-додатки часто робиться більше змін, ніж потім може знадобитися відкотити. Одним із прикладів процедури відкоту середовища може служити створення резервної копії поточного архіву додатки (файлу WAR) перед розгортанням, а також використання скриптів для відкату змін в базі даних. При цьому також необхідно повернути в початковий стан конфігурацію Web-контейнера.

У лістингу 5 демонструється приклад оператора для відкату змін, зроблених кожним оператором LiquiBase. Зокрема, створення нової таблиці brewery відповідає оператор dropTable для її видалення.

Лістинг 5. Приклад вказівки процесу відкату при описі змін в базі даних

Метою цього простого прикладу була ілюстрація принципу відкату змін, а не його спрощення. Скасування змін попереднього розгортання часто представляє собою тривалу завдання, складну для виконання і автоматизації. Час, який доводиться витрачати на написання скриптів відкату змін, має бути пропорційно збитку від невдалого розгортання.

Захист інформації від цікавих очей

Назва. захист файлів

Принцип. Знаходяться в репозиторії файли повинні бути доступні тільки для авторизованого персоналу.

Протилежний принцип. Файли знаходяться на комп'ютерах розробників або на загальних дисках, які повинні бути доступні тільки авторизованому персоналу і додатків.

На малюнку 8 показана система контролю версій, що використовується для зберігання файлів, доступ до яких відкритий тільки авторизованим користувачам і додаткам.

Малюнок 8. Використання захищеного сховища системи контролю версій для зберігання конфіденційних файлів

У деяких випадках не всі члени команди повинні мати доступ до інформації, що відноситься до конкретного середовища розгортання. Однак зберігання такої інформації окремо від скриптів розгортання може порушити їх виконання. Під час обговорення автономних процесів згадувалося про використання ключів SSH і безпечних каналів Java для копіювання файлів і віддаленого виконання команд без втручання людини. При цьому файли властивостей, що використовуються при зовнішньому конфігурації, швидше за все, будуть містити дані, які не повинні бути доступні всім членам команди. Для того щоб забезпечувати виконання автономних процесів, забезпечуючи конфіденційність даних в файлах властивостей, їх слід зберігати в захищеному репозиторії.

У лістингу 6 показаний приклад конфігурації сховища Subversion на сервері Apache, який забороняє доступ до заданого каталогу для всіх, крім перерахованих, користувачів.

Лістинг 6. Захист сховища Subversion з використанням Apache

При використанні захищеного сховища Subversion скрипти розгортання зможуть отримати доступ до файлів властивостей від імені користувачів, що володіють відповідним правами. Весь процес буде відбуватися як і раніше, тобто за допомогою ключів SSH і без участі людини.

Розгортання одним натисканням на кнопку

У моєму арсеналі є ще кілька принципів автоматизації розгортання крім тих 15, які були перераховані в даній міні-серії. Однак ці 15 принципів виявляються застосовні в 80% ситуацій, з якими я коли-небудь стикався. Кожен з них допоможе вам організувати процес автоматичного розгортання вашого застосування в декількох середовищах шляхом виконання єдиної команди (або натисканням на кнопку). Бажаю, щоб ваш досвід розгортання додатків був максимально безболісним.

На цьому все

Це була моя остання стаття з серії jsp?search_by=%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F+%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F:> практична автоматизація . Розділяти свій досвід з читачами протягом більш ніж двох років було неймовірно захоплююче. Моєю метою при цьому завжди було пояснення того, як і чому слід автоматизувати безліч різних процесів при розробці програмного забезпечення, щоб ви могли приділяти більше часу роботі над цікавим завданням, а не займатися стомлюючої роботою, яка має небезпеку помилками. У цій серії я показав, як можна автоматизувати процес рецензування коду з метою подальшого рефакторінга, виконання послідовного оновлення бази даних, використання принципів і засобів безперервної інтеграції, запуску тестів при кожній зміні, генерації графічних інсталяторів, організації процесу розгортання одним натисканням на кнопку, генерації документації , управління залежностями, використання систем контролю версій, а також різних скриптів і засобів збирання. Сподіваюся, що, читаючи мої статті, ви отримали не менше задоволення, ніж я в процесі їх написання.

Ресурси для скачування

Схожі тими

• Оригінал статті: Automation for the people: Deployment-automation patterns, Part 2 (Пол Дюваль, developerWorks, лютий 2009 р). (EN)
• Прочитайте попередню статтю Практична автоматизація: принципи автоматизації розгортання додатків, частина 1 (Пол Дюваль, developerWorks, січень 2009 року), в якій описуються принципи організації процесу розгортання одним натисканням на кнопку. (EN)
• прочитайте книгу Прініпе управління конфігурацією додатків (Стівен Берказк і Бред Епплтон, Stephen Bercuzk і Brad Appleton, Addison-Wesley Professional, 2003), в якій описується принцип єдиного сховища та безліч інших підходів до конфігурації додатків. (EN)
• Ознайомтеся зі сторінкою в Вікіпедії SmartFrog від HP Labs, на якій міститься каталог багатьох принципів розгортання додатків . (EN)
• Прочитайте восьму главу книги Безперервна інтеграція: поліпшення якості ПО і зниження ризиків (Пол Дюваль, Стів Матьяс, Steve Matyas і Ендрю Гловер, Andrew Glover, Addison-Wesley Signature Series, 2007) під назвою "Безперервне розгортання", в якій демонструються приклади включення розгортання в автоматизований процес інтеграції. (EN)
• Зверніться до книги Прагматичний підхід до автоматизації проекту: збірка, розгортання і моніторинг додатків на Java (Майк Кларк, Mike Clark, The Pragmatic Programmers, 2004), в якій описується практичний автоматизований процес випуску програмного продукту, що володіє необхідною надійністю і точністю, а також не вимагає контролю з боку персоналу. (EN)
• Якщо ви - розробник, і вам не хочеться, щоб вас будили в 3 ранку до кінця кар'єри, то прочитайте книгу Випуск програмного забезпечення: проектування і розгортання готових до експлуатації систем (Майкл Т. Найгард, Michael T. Nygard, The Pragmatic Programmers, 2007). (EN)
• прочитайте статтю Прискорення розгортання шляхом автоматизації (Пол Дюваль, IBM developerWorks, січень 2008 року), в якій пояснюється, як автоматизований процес розгортання дозволяє прискорити розгортання програми в різних середовищах.
• прочитавши статтю Невдалі підходи до безперервної інтеграції, частина 2 (Пол Дюваль, IBM developerWorks, березень 2008 року), ви значно полегшите своє життя і організацію процесу безперервної інтеграції, дізнавшись про те, чого слід уникати.
• Зверніться до статті Автоматичне перенесення бази даних (Пол Дюваль, IBM developerWorks, серпень 2008 року), що розповідає про використання LiquiBase для управління змінами в базі даних. (EN)
• Ant Завантажте Ant і організуйте надійний і передбачуваний процес складання ваших додатків. (EN)
• JSch Завантажте Java-бібліотеку захищених каналів, що забезпечує безпечний обмін даними. (EN)
• Selenium Завантажте Selenium - кошти для виконання функціонального тестування аспектів, специфічних для процесу розгортання. (EN)
• LiquiBase Завантажте LiquiBase для автоматизації внесення змін до бази даних. (EN)
• Abbot Завантажте Abbot - засіб для виконання функціонального тестування в процесі розгортання. (EN)

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів