Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP
Code

Vagrant: що, чому і як

by
Difficulty:AdvancedLength:LongLanguages:

Ukrainian (українська мова) translation by Anton Bagaiev (you can also view the original English article)

Ця стаття допоможе вам ознайомитись, як керувати віртуальними машинами за допомогою Vagrant, а також пояснить, як користуватися Puppet для забезпечення такими інструментами, як PHP і PostgreSQL.


Вступ

Розробники мають величезний вибір способів для побудови їх середовища веб-розробки.

Розробники мають величезний вибір способів для побудови їх середовища веб-розробки. Ви можете використовувати локальні рішення, такі як готові серверні рішення "все в одному", наприклад, Zend Server, XAMPP, MAMP, WAMP та схожі. Або ж ви можете інсталювати кожен компонент окремо, або використовуючи такі сервіси як Homebrew, Apt, та Yum.

Це може створити незручне нагромадження під час роботи над різними проектами з PHP 5.3 і PHP 5.4, MySQL, SQLite, MongoDB, Postgres, PEAR, PHPUnit, Rails 3.1, Memcached, Redis, Gearman, NodeJS, та таке інше. Якщо вам доведеться оновити систему або з комп'ютером щось трапиться, ви будете змушені почати все спочатку.

Ви можете мати віддалене налаштування, використовуючи сервер у мережі з розширенням Samba, або SSH сервер, що під'єднано інструментом на кшталт ExpanDrive. Останній варіант може призвести до затримки читання і запису файлів, що надзвичайно дратує. Також ви можете використовувати SSH та Vim для всіх задач — що швидко, але навряд ви хочете використовувати Vim завжди і усюди.


Розробницьке середовище проти робочого середовища

Можливо, ви задоволені тим, як все працює зараз, проте як часто ви чули (або казали) — "Ну, все працює на моєму комп'ютері". Напевно, ви чули або навіть казали це багато разів. І таке може легко призвести до проблем.

Надзвичайно важливо переконатися, що ваше середовище розробки ідентичне до робочого середовища проекту, а також співпадає з допоміжними серверами та серверами відлагодження, якщо ви маєте такі.

Це може звучати легко, коли ви думаєте, що треба просто встановити Apache, PHP та якусь версію MySQL, проте є мільйон причин, щоб думати інакше. Наприклад, якщо ви розробляєте у OSX та розміщуєте код в Ubuntu, тоді ви можете помітити цікаві наслідки, пов'язані з іменами файлів. Таке трапляється часто у CodeIgniter, коли хтось має бібліотеку у файлі, ім'я якого починається на рядкову літеру. Це буде працювати на OSX, проте не запрацює на робочому сервері з Ubuntu. Так ваша організація роботи щойно стала наслідком втрат у бізнесі, а все це із-за тривіальних відмінностей операційних систем, про які ніхто навіть не задумувався, доки не стало пізно.


Розробницьке середовище = Робоче середовище

Примус розробників до використання однієї операційної системи призведе до проблем.

Тоді як вирішити кризу? Примусити всіх розробників викинути інструменти для роботи, до яких вони звикли, і працювати на одній моделі ноутбуків? Якщо всі ваші розробники отримають по новенькому Macbook Pro, ви не почуєте багато нарікань, проте тоді доведеться закупити і нових серверів на OSX.

Ви можете використовувати Linux для всього, проте тоді ви будете сперечатись, який саме дистрибутив обрати. Примус розробників використовувати один набір інструментів призведе до проблем, що знизять продуктивність праці та спричинить зайві балачки і суперечки. Ще й до бійки дійде!

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

Так, це ще можливо, якщо ви спробуєте запустити Windows на слабенькій машині, проте в ці дні середній мак із 4 GB оперативної пам'яті на борту має достатньо ресурсів, щоб запустити сервер Ubuntu у режимі командного рядку разом із усіма вашими улюбленими розробницькими придатками(IDE, браузер, інструменти відладки та таке інше). Є кілька варіантів для віртуалізації, але я віддаю перевагу VirtualBox від Oracle, що є безкоштовним. Це програмне забезпечення візьме на себе весь тягар віртуалізації, тоді інструмент, що називається Vagrant, буде керувати віртуальними машинами.


Крок 1 - встановлення VirtualBox

По-перше, завантажте VirtualBox і встановіть його. У *nix системах (Mac OSX, Linux, та подібних) вам потрібно модифікувати ваш .bash_profile (або .zsh_profile) для розширення змінної $PATH:

Це дасть змогу Vagrant зрозуміти, де розташовано VirtualBox.


Крок 2 - встановлення Vagrant

Ви можете завантажити зібраний Vagrant для вашої операційної системи, або встановити його за допомогою системи управління пакетами gem:


Крок 3 - Створення екземпляру віртуальної машини

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

Ми будемо встановлювати Ubuntu 12.04 LTS (Precise Pangolin), що вже запакований у формат "box", який є готовим файлом оточення.

В цій команді аргумент "precise32" це скорочення до посилання. Тепер ви можете створити віртуальну машину, яка самостійно завантажить оточення з box-файлу.

Це запустить процес створення віртуальної машини і встановлення операційної системи на неї. Легко! Якщо ви хочете отримати доступ у віртуальну машину за допомогою SSH, використайте цю команду:


Крок 4 - Налаштування

Налаштування зберігається у файлі Vagrantfile, що містить конфігурацію віртуальної машини:

Як ви вже могли помітити, це синтакс Ruby, тож, тут відкривається цілий простір для експериментів.

Але ми почнемо з найпростішого.

Налаштування share_folder потрібно для того, щоб пов'язати локальну директорію з директорією на віртуальній вашині. Використовуючи параметр nfs => true віртуальна машина матиме змогу записувати і змінювати рівні доступу до файлів, що потрібно, наприклад, для встановлення CMS.

Керування портами дозволить вам мати доступ до серверу за адресою http://localhost:8080 та, звісно, змінити порт у разі конфліктів.

Цей файл конфігурації також виставить часовий пояс на лондонський час, а потім запустить apt-get update, що змусить систему оновитись після запуску. Якщо ви пропустите цю частину налаштувань, у вас можуть виникнути проблеми з інсталяцією та залежностями пакунків, оскільки вони можуть застаріти.

Якщо ви змінюєте конфігурацію, перезавантажте віртуальну машину цією командою:

Тепер, коли наш сервер працює і готовий до роботи, нам необхідно встановити програмне забезпечення. Далі ми не будемо просто встановлювати необхідні пакунки за допомогою apt-get install, ми будемо "забезпечувати" наші сервери.


Крок 5 - Забезпечення (Provisioning)

Забезпечення серверів це не те, про що мають думати розробники.

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

Безжалісний олдскул

Сисадміни вигадали безліч способів вирішення цієї проблеми — від створення списків команд, що треба запускати(але такі списки швидко розростаються і стають застарілими), до подібної до жонглювання "мультитермінальності", коли доводиться вводити команди в одне термінальне вікно, а потім послідовно дублювати їх на термінали інших серверів. Всі ці методи жахливі.

Одне з рішень цієї проблеми це створення власного .box файлу, або .iso бекапу, з яких потім будуть розгортатись нові сервери, проте підготовка таких образів займає багато додаткової роботи, і, незалежно від ваших старань, рано чи пізно — всі ці налаштування застаріють.

Сучасні методи

На даний момент існує дві популярні системи, що називаються Puppet і Chef.

На даний момент існує дві популярні системи, що називаються Puppet і Chef. Обидва існували протягом багатьох років, але стали більш популярним із розповсюдженням методології розробки DevOps. Ідеї цих систем досить схожі і вам слід ознайомитись з обома, проте в цій статті річ піде тільки про Puppet.

По суті, замість запуску купи команд із надією, що все запрацює, ви будуєте маніфест для Puppet із поясненнями того, що вам потрібно, щоб забезпечити правильне налаштування. Коли ви запускаєте команду у терміналі, ви говорите своєму комп'ютеру:

"Встанови Apache"

Використовуючи Puppet, ми, скоріше, говоримо:

"Переконайся, що Apache інстальовано"

Або, замість:

Зроби нову папку, під назвою /var/www і дай дозволи на www-data:www-data"

Використовуючи Puppet, ми говоримо:

Переконайся, що /var/www існуює і є дозволи на www-data:www-data"

Основа полягає в тому, що для забезпечення актуальності системи маніфести можуть бути виконані багато разів(або із періодичністю раз на годину чи день за допомогою крону), і їх повторне виконання не призведе до неочікуваних результатів на кшталт повторного встановлення.

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

Маніфести та модулі

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

Переглянемо простий приклад:

Тут поки не треба пояснень, егеж?

Далі цей файл можна використовувати для тестування залежностей.

Для подальших прикладів ми будемо посилатися на маніфести Puppet до PyroCMS на GitHub.

Тут підключається модуль "apache", вказується декілька змінних, запускається додатковий до модулю apache маніфест "apache::php", та встановлюється віртуальний хост, після цього виконується перевірка на те, чи ввімкнено модуль "mod_rewrite".

Всі ці класи визначені у модулі Apache, що ми підключили.

На додачу ми також хочемо встановити PHP:

Ця колода маніфестів встановить необхідні розширення PHP, а потім опція notify дасть Apache знати, що було встановлено нову конфігурацію, та перезапустить його:

Це налаштування встановить сервер postgres, створить базу даних із ім'ям "pyrocms" та переконається, що користувач із іменем "pyrocms" існує і має пароль.

Майже готово! Остання річ, в якій ми маємо переконатись, це те, що всі файли, що мають піддаватися запису, мають відповідний рівень доступу:

Тепер треба переконатися, що ми знаходимось у корені Apache та змінити рівень доступу до файла конфігурації на 0666, а кілька дозволених до запису тек на 777.

Ось і все!

Щоб запустити це все, просто перезавантажте ваш екземпляр vagrant, або виконайте наступну команду:

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

Тут застосовані наступні модулі: ApachePostgresPHP і ви можете побачити весь процес у дії, склонувавши репозиторій PyroCMS Vagrant:

Відкрийте у вашому бразері посилання http://localhost:8089/ і ви маєте побачити запрошення до інсталяції. Надзвичайно просто, егеж?

Примітка: Це налашутвання встановить MySQL, оскільки у PyroCMS підтримка Postgres і SQLite перебуває на стадії розробки, доки CodeIgniter завершить необхідну підримкуPDO. Для цікавості ви можете поекспериментувати з налаштуванням Vagrantfile, використавши маніфест ubuntu-apache2-pgsql-php5.pp, знищити віртуальну машину та запустити її знов. Також для цього субмодуль pyrocms потрібно змінити на feature/pdo.


Отже

В цій статті ми використали Vagrant, VirtualBox та Puppet не тільки для того, щоб створити сервер для роботи. Також ми створили тестове середовище для того, щоб впевнитись, що все працює, інстальоване та конфігуроване правильно.

Також ми створили список потреб, щоб, за вимоги, у майбутньому створити будь-яку кількість ідентичних серверів не за години, а за лічені хвилини!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.