Ansible і Docker, чому і навіщо?

      Досить багато інтересу проявляється серед технічного співтовариства до Docker і Ansible , я сподіваюся, що після прочитання цієї статті, ви теж розділіть цей інтерес. Ви так само отримаєте навички практичного застосування Ansible і Docker в налаштуванні сервера та оточення для Rails додатки.
 
«Чому б просто не взяти і використовувати Heroku?», Запитаєте ви.
Насамперед, я можу запустити Docker і Ansible на будь-якій машині, з будь-яким хостинг провайдером. По друге, я вважаю за краще гнучкість, зручності. Я можу, таким же чином, запускати все що завгодно, не тільки web додатки. Ну і наостанок, бо я експерементатором в душі, я отримую задоволення від розуміння того як воно все разом працює. Фундаментальна основа Heroku це Linux контейнер. Та ж технологія лежить і в основі Docker'a. Насправді, одним з девізів Docker'a є «Контейнеризація це нова віртуалізація»
 
 

Чому Ansible?

Після 4 років активного використання Chef, інфраструктура як код стала дійсно стомлюючої для мене. Я проводив більше часу за кодом, який керував моєї інфраструктурою, але не за самою інфраструктурою. Будь-яка зміна, не важно наскільки маленьке, потребують велику кількість зусиль для незначної вигоди.
 
З Ansible, з одного боку є дані описують інфраструктуру, з іншого обмеження між взаємодією інших компонентів. Ця модель набагато простіше, вона дозволяє набагато швидше рухатися далі, дозволяючи зосередиться на тому, що робить моя інфраструктура. Як і в Unix моделі, Anisible надає модулі з одиничною відповідальністю, які можуть бути об'єднані нескінченним безліччю способів.
 
Ansible не має залежностей окрім як Python і SSH. Їй не потрібно встановлювати агентів на віддалені машини, вона не залишає всякого роду сміття після своєї роботи. Більш того, вона поставляється зі стандартною бібліотекою модулів для управління всім чим завгодно, починаючи від пакетного менеджера в хмарі, закінчуючи базами даних.
 
 

Чому Docker?

Docker позиціонує себе як самий надійний та зручний спосіб розгортання процесу на машині. Це може бути все що завгодно, від mysqld до redis, закінчуючи Rails додатком. Таким же ефективним способом, як git знімки і розподіл коду, Docker робить теж саме з процесами. Він гарантує, що буде надано все, що потрібно для запуску цього процесу, незалежно від машини на якій він запущений.
 
Основна, але зрозуміла помилка, порівнювання Docker контейнера з VM. Тут застосовується принцип єдиною відповідальності, запуск одного процесу на контейнер дає простоту змінності та підтримки. Ця модель витримала випробування часом у філософії Unix, це дає міцний фундамент для дій.
 
 

Налаштування

Не покидаючи свій термінал, я можу отримати від Ansible налаштовану машину на одному з наступних хостингів: AWS, Linode, Rackspace або DigitalOcean. Якщо бути більш конкретним, я за допомогою Ansible створюю новий дроплет з 2ГБ пам'яті на DigitalOcean в регіоні Amsterdam 2 за 1 хвилину 25 секунд. Протягом ще 1 хвилини і 50 секунд я можу отримати налаштовану систему з Docker'ом і деякими іншими установками. Тепер, маючи базову систему, я можу розгорнути свій додаток. Зауважте, я не налаштовував який або мова програмування або базу даних. Docker сам подбав про це.
 
Ansible виконує всі команди на віддалених машинах через SSH. Мої SSH ключі, що лежать в локальному ssh-agent'е будуть віддалено розшарені через SSH сесію Ansible. Коли, на віддаленій машині, код мого програми буде клонований чи оновлений ніяких даних для авторизації в git не буде потрібно, для авторизації буде використаний проброшенний ssh-agent з локальної машини.
 
 

Docker і залежності додатки

Я знаходжу кумедним той факт, що більшість розробників точно вказують версію ЯП, модулі для Python, Ruby геми або node.js модулі, потрібні для їх застосування, але коли справа доходить до чегото важливого, наприклад сервер БД або сервер черг, вони використовують те що є на даний момент. Я думаю це одна з причин DevOps руху, розробники беруть на себе відповідальність за оточення в якому вони запускають додаток. Doker робить це завдання легше і простіше, додаючи часточку прагматизму і впевненості до існуючих практикам.
 
Моє додаток визначає залежно від процесів, таких як MySQL 5.5 і Redis 2.8 включає
.docker_container_dependencies 
файл
 
gerhard/mysql:5.5
gerhard/redis:2.8

 
Ansible playbook побачить цей файл і скаже Docker'у взяти правильні образу з індексу образів і запустити їх як контейнери. Також ці контейнери Слінко в контейнер мого програми. Якщо ви хочете подробиць про роботу лінковки контейнерів, загляньте в анонс Docker 0.6.5
 
Моє додаток так само йде з Dockerfile, який специфічний для Ruby Docker образу. Коли образ буде встановлений, кроки в Dockerfile гарантують, що буде встановлена ​​правильна версія Ruby.
 
 
FROM howareyou/ruby:2.0.0-p353

ADD ./ /terrabox

RUN \
  . /.profile ;\
  rm -fr /terrabox/.git ;\
  cd /terrabox ;\
  bundle install --local ;\
  echo '. /.profile && cd /terrabox && RAILS_ENV=test bundle exec rake db:create db:migrate && bundle exec rspec' > /test-terrabox ;\
  echo '. /.profile && cd /terrabox && export RAILS_ENV=production && rake db:create db:migrate && bundle exec unicorn -c config/unicorn.rails.conf.rb' > /run-terrabox ;\
# END RUN

ENTRYPOINT ["/bin/bash"]
CMD ["/run-terrabox"]

EXPOSE 3000

 
Перший крок — це скопіювати весь код мого програми в образ Docker'a і завантажити глобальні змінні оточення, додані попередні образами. Образ Ruby Docker, наприклад, додає в PATH шляхи для коректного завантаження правильної версії Ruby.
 
Далі, я видаляю історію git, оскільки вона не потрібна в даному контексті. Я встановлюю все геми і потім створюю / test-terrabox файл, який запускається тільки для тестів. Метою всього цього є мати «canary» версію, яка перевіряє додаток і всі його залежності, що всі Docker контейнери слінковать правильно і всі тести пройдені успішно, перед актуальним запуском програми.
 
Команда, яка викликається при запуску нового контейнера, визначена в кроці CMD.
Запуск / run-terrabox команди, визначений як частина процесу складання, відразу після процесу запуску тестів.
 
Остання інструкція в Dockerfile прокидає порт 3000 зсередини Docker контейнера на хост машину з під якої запущений Docker. Який можуть використовувати сервер або балансировщик навантаження для проксінг запитів в моє додаток контейнера.
 
 

Запуск Rails додатки всередині Docker контейнера

Для середнього Rails додатки, з десь приблизно 100 гемамі і безліччю інтеграційних тестів, що запускаються з під Rails, запуск всього цього займає 8 хвилин 16 секунд на 2GB та 2 ядерної машині, без яких або локальних Docker образів. Якщо у мене вже є Ruby, Mysql і Redis образу на цій машині, це займе 4 хвилини 45 секунд. Більш того, якщо у мене вже є еталонний образ мого програми, то це займає 2 хвилини 23 секунди. Якщо подивитися, в перспективі, розгортання нового Rails додатки, включаючи такі залежності як MySQL і Redis займає не більше 2 хвилин.
 
Так само слід зауважити, що розгортання додатка включає в себе запуск всіх тестів, які займають, впритул, хвилину часу.
Без перебільшень, Docker стає простим засобом безперервної інтеграції, яке залишає за собою тільки тестові контейнери для дослідження, якщо тести не проходять, або стартує новий контейнер додатки з останньою версією, коли тести проходять. Раптово, я можу перевірити новий код з моїми замовниками за хвилини, який гарантовано буде ізольований від інших версій програми на рівні операційної системи. У відмінності від традиційних VM, які завантажуються за хвилини, Docker на це витрачає секунди. Більше того, раз створивши образ Docker'a і переконавшись, що всі тести пройдені для специфічної версії мого програми, я можу залити образ у приватний реєстр, який в свою чергу, може бути завантажений іншими машинами з Docker'ом і запущений як новий контейнер, і все це за секунди.
 
 

Висновок

Ansible дозволив мені поглянути по новому на процес управління інфраструктурою. Docker дав мені впевненість і стабільність, коли мова заходить про один з найважливіших кроків розробки, фази доставки. У комбінації, вони не мають собі рівних.
 
Отримати з нуля повністю налаштоване Rails додаток за якихось 12 хвилин це вражаюче для будь-якого стандарту. Отримати базову Continuous Integration систему безкоштовно з можливістю попереднього різних версій додатку пліч-о-пліч, без зачіпання «робочою» версією, запущених на тій же машині, це неймовірно потужно. Це робить мене радісним, і досягнувши кінця статті, я можу тільки сподіватися, що ви розділите мою радість зі мною.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.