Зазвичай розробник піклується про задоволення бізнес-вимог. Він / вона може мати досвід у певній стеці чи рамці. Але чи повинен він / вона докладати зусиль, щоб вивчити докер, і це різні методи розгортання (рій, кубе, мезо тощо)?
Простіше кажучи, чому розробник повинен дбати про докер?
PS: Батьківське питання до цієї посади полягає в тому, що потрібно представити докер до команди розробників
Відповіді:
Напевно, не відповідь, яку ви шукаєте, але все-таки відповідь :)
Дізнання про докер та його способи розгортання фактично може бути включено до бізнес-вимог, зробивши його частиною середовища розвитку проекту чи команди, як і мови коду, система управління версіями, компілятори, тестова інфраструктура тощо - для роботи в що команді або в цьому проекті потрібно знати і використовувати все це, не може "принести своє" (у більшості випадків).
Все стає дещо складніше, якщо під "розробником" ви маєте на увазі більшість або навіть всю команду розробників. Натискання інструменту в середовищі розробки, не маючи фактично жодного з розробників, які його підтримують, буде справді важким. Витратьте час, щоб створити одного такого прихильника спочатку з технічного керівництва команди.
Побічна примітка: також може не знадобитися кожному розробнику в команді стати експертом-докером. Заздалегідь встановлені рецепти використання, загорнуті в прості команди, готові до використання електронних таблиць, часто дозволяють розробникам використовувати рішення на основі докерів, не знаючи занадто багато про їх внутрішню роботу, що може бути досить прийнятним, особливо у великих командах. Так само, як мати можливість вносити код, не знаючи всіх подробиць про те, як будується кінцевий продукт.
Я дам вам свою точку зору. Розробники повинні дбати про докер, оскільки є й інші розробники, які бажають використовувати докер і вже створили досвід в ньому. Вони готові взяти на себе роль інженера DevOps, а також бути розробником. Тож Ops частина DevOps - це те, на чому вони зараз будують досвід.
У ці дні ви знайдете все більше хлопців, які можуть розробляти, упорядковувати, автоматизувати тести, автоматизувати завдання та створювати інструменти для моніторингу та прийняття цього повного пакету у виробництво вручну. Це хлопці, які просувають докер та інші інструменти серед спільноти розробників.
Крім того, приплив ринку спрямований на віртуалізацію, автоматичне масштабування, автоматизацію, машинне навчання та докер підходить до всього цього. Вкрай необхідним є використання докера. Підприємства готові платити 2 рази за одного хлопця, який бере на себе всі ці обов'язки, і коли є попит на таких хлопців, пропозиція також почнеться. Це з точки зору працівника-роботодавця.
Технічно в організаціях, в яких я працював, є окремі команди розробки та DevOps, хоча вони дуже тісно працюють над поставками. Інженери та розробники DevOps поділяють величезну більшість наборів навичок і тому іноді відбувається узгодження обов'язків.
Найменший мінімум, який може зробити розробник, - це поділитися своїми бінарними файлами, але він повинен розуміти, що бінарні файли будуть використовуватися для запуску всередині контейнера докера, і для цього йому потрібно зрозуміти, як працює докер. Що стосується кубів, роїв, мезосів тощо, розробник може навіть не байдуже, що використовується, але розробник розробників повинен дуже добре розуміти основи докера, а розум повинен бути з самого початку, щоб створити додаток вільно поєднане для повторного використання як мікросервіси. Якщо додаток побудовано з цього розуму (для якого потрібні основи докера), то інженери DevOps можуть взяти його звідти для автоматичного масштабування, упорядкування, тестування, розгортання та моніторингу.
Крім того, більшість випадків немає жодного розміру, який підходить для всіх видів. Розробник чітко не знає, як створити додаток, придатний для докерів, а інженер DevOps цілком справедливо не знає внутрішніх процесів створення додатків. Отже, більшість випадків організації вважають за краще віддавати обидва ці завдання одному і тому ж хлопцеві, щоб прискорити справи. Якщо існують окремі речі, тоді необхідний постійний механізм зворотного зв’язку від команди DevOps до команди розробників, щоб зробити програми більш футуристичними та готовими докер / хмара / масштабування.
Йдеться не про Докер або будь-які інші технології контейнерації.
Контейнери, такі як Docker, rkt тощо, - лише спосіб доставки вашої заявки аналогічно статичним двійковим. Ви будуєте розгортання, щоб воно містило все необхідне всередині, а кінцевому користувачеві не потрібно нічого, крім часу виконання.
Ці рішення схожі на жирові JAR в Java, де все, що вам (теоретично) потрібно, - це лише час виконання (JRE), попередньо встановлений, і все, що просто працює ™.
Причина, чому розробникам потрібно розуміти (їм не потрібно вчитися керувати таким інструментом, тільки для чого це потрібно) інструменти оркестрування, це те, що це дозволяє мати певні переваги перед «традиційним» розгортанням.
Про це EngineYard написали гарну статтю. Вся справа в тому, що коли ваш сервер помирає, ви знизаєте плечима і чекаєте, коли з’явиться новий. Ви ставитесь до них як до худоби, у вас працює десятки, сотні, тисячі, і коли хтось знижується, ні ви, ні ваші клієнти цього не повинні знати.
Інструменти оркестрації досягають цього, контролюючи стан усіх програм (стручки / завдання, що завгодно) в кластері, і коли він бачить, що один із серверів перестає реагувати (знижується), то він автоматично переміщує всі програми, що працювали на цьому сервері кудись інше.
Завдяки оркеструванню ви можете запускати кілька додатків на одному сервері, а оркестратор відстежує ресурси для вас. Він буде переставляти програми, коли потрібно.
Завдяки автоматичній роботі з відмовою в оркестрах ви можете запускати власні зображення в хмарі як є. Коли вам знадобиться оновлення, ви просто побудуєте нове зображення, встановіть конфігурацію запуску, щоб використовувати це зараз і просто прокручувати. Все буде оброблено за вас:
TL; DR Весь пункт стосується не Докера, а оркестрації. Docker - це лише розширена версія тарболу / жиру JAR, яка потрібна для правильної оркестрації.
Ось, наприклад, декілька аргументів із публікації в блозі, опублікованої ще у 2014 році та заголовок, що повністю відповідає вашій відповіді:
- Набагато гнучкіше введення нових технологій у навколишнє середовище
- Існує ще велика больова точка між введенням остаточного тестованого коду та його запуском на остаточні сервери виробництва. Докер значно спрощує цей останній крок
- Docker робить тривіальним збереження застарілої ОС, незалежно від того, який аромат Linux ви працюєте
Від: https://thenewstack.io/why-you-should-care-about-docker/
Якщо ви запускаєте своє виробництво в контейнері docker, важливо, щоб цей контейнер виготовляли ті самі розробники, які створили додаток, що працює на них. Кому ще краще, щоб знати, яка зовнішня залежність потрібна і так далі ...?
Також конвеєр може вийти з ладу на будь-якому кроці під час компакт-диска, особливо коли це крок збирання зображення докера, іноді це файл, який відсутній, або потрібна вкладка.
На роботі ми представляємо всі розробники докер-докерам, пояснюючи їм основи створення dockerfile, щоб обслуговувати їх додаток, також ми спростили конвеєр, тому можна лише додати ім'я та dockerfile, і його додаток автоматично буде побудовано на наступне натискання незалежно від тех, хто працює ним.
Швидкий старт Docker - це справді чудовий вступ до цього, після чого команда devOps керує розробником у виборі дистрибутива (багато з них не знають подібних речей alpine).
Наша робота полягає в тому, щоб надати їм легкий доступ до інструментів, а решта вони зробили, щоб вони могли виправити це, коли щось не так. Docker насправді є частиною процесу розробки, і команда devOps надає їм зображення докера, які відповідають нашим потребам, і це досить просто, тому для створення нового додатка та розгортання його потрібно без зайвої допомоги.
Докер отримує багато преси та блогу, що призводить до того, що розробники зацікавлені ним користуватися. Для деяких людей це інтерес грати з новою технологією або розуміти, як все працює. Для інших це бажання додати до свого резюме ключові слова. Так чи інакше, чим більше розробників знає про те, як все працює і як їх розгортати, тим менше здивуватися вони будуть пізніше. З того, що я бачив, існує пристойний обсяг уже існуючого інтересу до цього, тому не слід так сильно заохочувати це.
Що ж, якщо ви коли-небудь використовували VM для тестування, ви можете спробувати використовувати контейнери та докер - це насправді чудовий матеріал для тестування, і використовувати його набагато простіше замість LXC :)