Docker in production: «Коли ти їси, тобі, як мінімум, не огидно, особливо якщо знаєш, як готувати»



Ідея контейнеризації з'явилася вже давно, однак Docker виявився першою технологією, яка змогла досягти масової популярності. Про те, чому це сталося, наскільки Docker «подорослішав» за 3 роки, а заодно про те, коли можна перестати хвилюватися і почати використовувати Docker у своєму production додатку, ми поговорили з нашими експертами:

Олександр aatarasoff Тарасов — Software Architect в Альфа-Лабораторії. Нині впроваджує микросервисную архітектуру і рухає напрямок DevOps, а більше року тому розповідав про свій досвід впровадження Docker в Альфа-Банку.

Docker in production: не Можна використовувати інструмент тільки тому, що він модний
– Чому ви стали використовувати Docker?

– Починалося все не з Docker'а, зрозуміло: в минулому році у нас відбувся тектонічний зсув у бік розподілених систем і микросервисной архітектури. В рамках цього процесу ми стали переробляти свою систему і переходити до більш легковажним API і UI, розробляти розподілені frontend-системи.

В якийсь момент ми зрозуміли, що з впровадженням нових технологій, таких як NodeJS, постає питання деплоймента в тестові та прод-оточення. З'явилася необхідність в інструменті, який дозволив би уніфікувати способи упаковки і доставки софта до клієнта, і при цьому максимально полегшив роботу супроводу, так що для нас Docker в першу чергу виконує функції інкапсуляції, приховуючи особливості реалізації програми за уніфікованим API. Це дозволяє розробникам більш вільно підходити до вибору технологій, а додатком досягти стану, який ми з Кирилом Толкачевым на одному з виступів назвали «stressless architecture»: в контейнері відразу є все необхідне, щоб софт був коректно запущений і не конфліктував з іншим, розміщеними в одному кластері/машині, і саппорт відчуває себе впевненіше при відновленні окремих частин програми.

Для прикладу «stressful» архітектури можна подивитися на класичне J2EE додаток: ми залежимо від версії Java, версії J2EE-сервер, і це накладає на нас певні обмеження, а міграція на нові версії вимагає масштабного тестування і виконується досить рідко. Переходячи на Docker, ми змінюємо цю концепцію: так як всі необхідні залежності вже знаходяться всередині нашого контейнера, то нічого не заважає почати використовувати нову версію Java або сервера.

– Але ж Docker не позбавляє від тестування при міграції. За рахунок чого вона стає простіше у разі Docker'а?

– Docker побудований навколо концепції одного додатка на контейнер, так що ти йдеш від ситуації, коли необхідно оновити J2EE-сервер, на якому задеплоено два десятки різних компонент. Замість цього необхідно мати справу з ізольованими додатками, які використовують більш легкі embedded-сервера. Це дозволяє «рознести» оновлення по часу (тимчасовій шкалі) і мігрувати по шматочках, замість міграції всього і відразу.

– тобто Docker активно підштовхує переходити на микросервисную архітектуру?

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

Ми не розбудовували нашу систему тільки для того, щоб використовувати Docker, навпаки, ми виходили з необхідності роздрібнити існував на той момент J2EE-сервер, і рішення використовувати Docker з'явилося із завдань, які перед нами встали. Я вважаю це дуже правильним підходом, тому що якщо ти не знаєш, навіщо тобі технологія, не можеш зрозуміти, які проблеми вона вирішує, то вона тобі не потрібна. Не можна використовувати інструмент тільки тому, що він модний.

– тобто у вас микросервисная архітектура ніколи не жила без Docker'а? Якщо уявити собі зворотну ситуацію, стали б ви переводити на Docker вже працює микросервисное додаток?

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

– А розглядали якісь інструменти, крім Docker'а?

– Коли ми обирали інструмент, якихось альтернатив Docker'у по факту не було, більше того, Docker півтора роки тому і Docker зараз – це абсолютно різні речі. На той момент існували LXC-контейнери, але Docker здався більш зручним в першу чергу з точки зору розробника.

Зараз, крім Docker'а, з'явився проект Rocket – теж система контейнеризації зі своїм API.

У якийсь момент багато великі компанії зрозуміли, що контейнеризація – дуже перспективна технологія, і створили консорціум Open Container Initiative, в рамках якого розробляється рантайм runC. Він повністю опенсорсний, дозволяє запускати Docker-образи і будь-які інші сумісні види контейнерів. На базі runC зараз працює і сам Docker. Так що, якщо використання Docker'а і є вендор lock'ом, то дуже незначно.

– Раз ми заговорили про вендор lock'е: використовувати чистий Docker' в продакшені все одно погано виходить: потрібні супроводжують сервіси для оркестрации, обробки логів і так далі. Чи Не вийде так, що всі такі рішення будуть створені для Docker'а, і замінити його буде складно ще й з цієї причини?

Безумовно, так як Docker зараз є лідером ринку, то всі рішення в цій сфері підтримують Docker або мають на нього фокус. Однак, якщо говорити про Marathon, який ми використовуємо зараз, то це просто фреймворк над Mesosphere, який спеціалізується на запуск контейнерів, точніше довго працюють завдань.

Я думаю, якщо Rocket буде мати популярність, то люди напишуть новий фреймворк для Mesosphere, який буде підтримувати Rocket, ну або Rocket напише свої кошти оркестрации і використовувати їх.

– А не виходить, що всім розробникам доводиться вивчати Docker?

– Коротка відповідь: так. Довгий полягає в тому, що це питання культури і того, що розробник є інженером і здатний вирішувати завдання в комплексі.

Доброю аналогією є тестування: розробка юніт-тестів – це не завдання спеціального людини, навіть інтеграційні тести можуть бути роботою розробника. Ми вважаємо, що інженер повинен створювати повні і верифіковані рішення, готові до роботи у клієнта. Якщо ти сам пишеш тести на свій софт, запускаєш їх на CI-сервері відповідно до процесу доставки, то виділений тестувальник потрібен для опрацювання тест-кейсів і тестової моделі, а не самого процесу тестування. Так само і в світі контейнеризації: інженери пишуть сценарії розгортання свого, вони ж збирають контейнери і вміють запускати Docker-образи. Так, це додаткові знання, які вони мають, але це не означає, що вони повинні бути експертами в системному адмініструванні або тонкого налаштування чого-небудь з системного софта, хоча подібні знання суміжних предметних областей ніколи не бувають зайвими.

Це питання культури і культурного зсуву. Розробка – це не just a code, для нас розробка – це випуск готового рішення, яке можна доставити клієнтові.

– Багато знадобилося тонкої настройки, щоб деплоиться Docker'ом?

– Тонкої настройки Docker'а – небагато, але на інфраструктурний софт: різні системи зберігання конфігурацій (Consul, Zookeeper), засобів оркестрации (Mesosphere і Marathon), обробки логів (Elasticsearch, Kibana, Kafka – на них часу пішло досить багато.

Якщо питання в тому, чи більше стало роботи після інтеграції з Docker'м, я б сказав, що існує паритет. Десь її стає менше з-за незалежних і самодостатніх компонент, де доводиться вносити поправки на особливості Docker'а, які потрібно розуміти і враховувати при розгортанні.

Що ж до налаштування самого Docker'а, може бути, у нас поки не було таких завдань, але тонко налаштовувати docker engine, змінювати storage driver від програми до програми нам не доводилося.

– Де Docker знаходиться на кривий Гартнера для вашої команди?

– Я думаю, ми на плато продуктивності. Була досить велика ейфорія з-за того, що Docker вирішує багато проблем і має мінімум недоліків, поступово ми розуміли, що срібної кулі не існує, вирішували або обходили з'являлися проблеми, і тепер ми здатні ефективно вирішувати бізнес-задачі за допомогою цієї технології.

Prod-ready. Коли ти їси, тобі, як мінімум, не огидно, особливо якщо ти знаєш, як готувати
Андрій Філатов lincore — провідний системний інженер в компанії EPAM Systems, спеціаліст по хмарних рішень, фанат Docker і DevOps.

– Як ви використовуєте Docker?

– Ну, на одному проекті у нас повністю автоматизований CI за допомогою Docker'а і Jenkins'а.

Docker використовується для усього: slave'и запускаються в Docker-контейнерах, в інших контейнерах відбувається розгортання тестових оточень, ну і сам додаток теж запускається в Docker-контейнері.

– А майстер?

– Ні, майстер – велика залізна машина: коли тобі потрібно зібрати щось маленьке, запустити один-два білду, можна застосовувати Docker, але у нас 20-30 процесів працюють 24/7, і Docker не дуже підходить, ми вперлися б у продуктивність. Навіть у поточній конфігурації ми нашу велику залізну машину утилізуємо по максимуму при тому, що на майстрі відбувається тільки запуск і оркестрация, все збирається на Doker'зированых slave'ах.

– Як ви прийшли до Docker'?

– Ну, якщо говорити про цей проект, то коли я на нього прийшов, ніякого Docker'а там не було. Була класична зв'язка: два напівпорожніх постійно простоюють slave'а, більшості пайплайнов просто не існувало, всі кнопки натискали людьми. Тобто з точки зору CI мало що було зроблено. Я вибрав Docker як інструмент, бо вже знав, що він буде добре працювати і по максимуму утилізувати ресурси, які на той момент були.

– А якщо говорити про застосування Docker'а в виявляли у своєму житті таку?

– Можу розповісти про Docker'е «зі смаком Амазона». Є у Амазона сервіс, який називається Elastic Contaiers Service. За допомогою цього інструменту за півгодини я написав bash-скрипт, який організовує Zero-downtime деплоймент. Там під капотом використовується Docker: у нас є машинка, яка збирає образи і відправляє їх у registry в Амазоні, а далі магія самого ECS: створюєш завдання, вибираєш сервіс і ставиш, яку кількість примірників має бути підняте, і всі, просто диво! Тут треба зауважити, що з Амазоном я знайомий давно звик до JSON-програмування, але важливий сам факт, що за півгодини можна організувати доставку додатки від CI до деплоя з gradual rollout та іншими фишечками. Амазон надає всі необхідні інструменти аж до того, що якщо ти правильно налаштувати свої метрики і Auto Scaling, то взагалі ні про що не треба дбати: починають навалюватися користувачі – і автоматично піднімаються нові инстансы і нові контейнери на них.

– А до Docker'а як ви жили?

– Як усі живуть: Jenkins, jenkins slave'и, у slave'ів лежать ssh-ключі: вони заходять на машини, розкладають war, jar і так далі по своїх місцях і рестартуют сервіси. З Docker'му все стало більш гнучко і нормально: зараз ми можемо, в принципі, розвернутися де завгодно, нічого не змінюючи по суті розгорнути з образів Docker-контейнери, нічого не пересобирая.

– А як розробники переходили на Docker?

– У розробників Linux і там весь перехід займає одну сходинку. Довелося, правда, для декількох quality assurance інженерів написати на wiki докладну інструкцію, як завантажити і поставити Docker-машину, як поставити Docker Compose і як зробити так, щоб це все запрацювало під Windows, але все обмежується установкою Docker-машини Virtual Box, а далі можна користуватися cli-утилітами. Docker дуже простий інструмент.

– Коли ви переходили на Docker, дивилися інші технології? Що в той момент було на ринку?

– Реалізації на віртуальних машинах, давно існуючий Virtuozzo, але зручних інструментів, які дозволяли б зробити те, що ми зробили на Docker'е, не було, і довелося б будувати з допомогою великої конфігурації Vagrant, але таке рішення швидко перестає бути стерпним.

Ми дивилися на Hashicorp Otto, він подавав надії, але вже дуже він нещодавно на той момент з'явився, його було страшнувато використовувати. Так що альтернатив Docker'у нас не було, та й зараз, як мені здається, їх немає, принаймні зрілих.

– Наскільки добре розвиваються платформа і екосистема?

– Екосистема рухається в правильному напрямку, що ж до самого Docker'а: Swarm дуже сильно не дотягує до того, що дає Амазон, коли справа доходить до оркестрации, але і тут все досить непогано. Я навіть проводив невеликий R&D: з'ясувалося, що, якщо виникне необхідність, ми зможемо малою кров'ю мігрувати на Swarm.

– Навіть без застосування сторонніх сервісів на зразок mesosphere?

– Ну, для наших потреб – так, все що потрібно, в Swarm є. Ми не використовуємо складний networking, не використовуємо взаємну інтеграцію контейнерів. У нас досить проста інфраструктура.

– Можна про неї в двох словах?

– У нас є три шари: точка входу на nginx, є frontend-контейнери, є кілька різних типів API, обробників інформації, і є кілька сервісів, які спілкуються з базами даних. API-сервіси або самі читають з бази даних, або відправляють запити redis, а ті, хто займаються даними та їх модифікацією, беруть з redis всю необхідну інформацію. Якщо нам потрібно буде мігрувати з Амазона, де є redis і база даних як сервіс, то потрібно буде піднімати їх самостійно.

– Для чого б не варто використовувати Docker?

– Я думаю, в числодробилки його ставити не має сенсу. Якщо у вас reporting-інструмент, який перетравлює величезні обсяги даних, накладні витрати від Docker'а будуть позначатися на продуктивності, на рендеринг-фермах він теж не має сенсу. Загалом, там, де потрібен «raw performance», Docker не дуже годиться. Навіть не так: там, де є можливість застосовувати віртуальні машини – Docker підійде ідеально.

Ну і, наскільки я знаю, Docker не працює з Windows-контейнерами, хоча днями була новина, що в 2016 сервері буде підтримка docker-контейнерів, так що Microsoft співпрацює з командою Docker'a і, швидше за все, це найближчим часом зміниться.

– А якщо говорити не про інфраструктуру, а про самі додатки: змінилися підходи з приходом Docker'а?

– Практично немає. Спочатку ми готувалися до того, що інфраструктура буде на дрібних або середніх виртуалках і повинна добре горизонтально масштабуватися, так що Docker просто замінив нижній рівень. Звичайно, в деяких ділянках додалися перевірки на стани, в яких перебуває програми. Тобто, якщо раніше ми розраховували, що додаток або виртуалка можуть рестартовать і дані не загубляться, то зараз всі розуміють, що якщо контейнер помре, то твої дані помруть разом з ним, і їх потрібно їх зберігати в іншому місці, але redis і postgresql вирішують цю проблему.

– Наскільки Doker зріла технологія?

– Prod-ready. Коли ти їси, тобі, як мінімум, не огидно, особливо якщо ти знаєш, як готувати.




Якщо хочете дізнатися більше про Continuous Delivery, оркестровки та контейнеризації, вам швидше за все виявляться цікаві наступні доповіді Joker 2016 (СПб, 14-15 жовтня).

Реліз-менеджмент за допомогою Gradle
Контейнер не потрібен: Сучасний Java Stack з Bootique.io
Микросервисы: перша кров
Джерело: Хабрахабр

0 коментарів

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