Как правило, разработчик заботится о соответствии бизнес-требованиям. Он / она может иметь опыт в конкретном стеке или структуре. Но должен ли он / она приложить усилия для изучения докера и его различных методов развертывания (роя, куба, мезо и т. Д.)?
Проще говоря, почему разработчик должен заботиться о докере?
PS: родительский вопрос к этому посту - Смысл введения докера в команду разработчиков
Ответы:
Вероятно, не ответ, который вы ищете, но ответ тем не менее :)
Изучение докера и методов его развертывания может быть фактически включено в бизнес-требования, сделав его частью среды разработки проекта или команды, точно так же, как язык (и) кода, система контроля версий, компиляторы, тестовая инфраструктура и т. Д. - для работы в та команда или тот проект, о котором нужно знать и использовать все это, не может «привнести свое» (в большинстве случаев).
Все становится немного сложнее, если под «разработчиком» вы на самом деле имеете в виду большинство или даже всю команду разработчиков. Продвигать инструмент в среде разработки, не имея на самом деле поддержки со стороны разработчиков, будет очень сложно. Потратьте время на то, чтобы сначала создать одного такого сторонника из технического руководства команды.
Примечание стороны: она может также не быть необходимым для всех и каждого разработчика в команде , чтобы стать экспертом в Докер. Предварительно установленные рецепты использования, заключенные в простые, готовые к использованию команды, часто позволяют разработчикам использовать основанные на докере решения, фактически не зная слишком много о своей внутренней работе, что может быть довольно приемлемо, особенно в больших командах. Точно так же, как возможность вносить код, не зная всех подробностей о том, как создается конечный продукт.
Я дам вам мою точку зрения. Разработчики должны заботиться о докере, поскольку есть другие разработчики, которые хотят использовать докер и уже накопили опыт в этом. Они готовы взять на себя роль инженера DevOps и быть разработчиком. Таким образом, Ops-часть DevOps - это то, на чем они сейчас основаны.
В эти дни вы найдете все больше и больше ребят, которые могут разрабатывать, организовывать, автоматизировать тесты, автоматизировать задания и создавать инструменты для мониторинга и запуска этого полного пакета в одиночку. Это ребята, которые продвигают Docker и другие инструменты среди сообщества разработчиков.
Кроме того, рыночный поток направлен на виртуализацию, автоматическое масштабирование, автоматизацию, машинное обучение и докер вписывается во все это. Стало очень важно использовать докер. Предприятия готовы платить 2 раза за одного парня, который берет на себя все эти обязанности, и когда есть спрос на таких парней, поставки также начнутся. Это с точки зрения работника-работодателя.
Технически, в организациях, в которых я работал, есть отдельные команды разработчиков и DevOps, хотя они очень тесно сотрудничают для поставок. Инженеры и разработчики DevOps разделяют подавляющее большинство навыков здесь, и поэтому иногда приходится обсуждать обязанности.
Минимум, который может сделать разработчик, - это поделиться своими двоичными файлами, но он должен понимать, что двоичные файлы будут использоваться для запуска в контейнере Docker, и для этого ему необходимо понять, как работает Docker. Что касается кубов, роев, мезо и т. Д., Разработчик может даже не заботиться о том, что используется, но основы докера должны быть очень хорошо поняты разработчиком, и с самого начала должно быть мышление для создания приложения, слабо связанного для повторного использования в качестве микро-услуги. Если приложение построено на основе этого мышления (для которого требуются основы докера), то инженеры DevOps могут использовать его для автоматического масштабирования, организации, тестирования, развертывания и мониторинга.
Кроме того, в большинстве случаев не существует одного размера, подходящего для всех видов вещей. Разработчик не знает четко, как создать дружественное к докеру приложение, а инженер DevOps совершенно справедливо не знает внутренности процесса сборки приложения. Следовательно, в большинстве случаев организации предпочитают передавать обе эти задачи одному и тому же парню, чтобы ускорить процесс. Если есть отдельные вещи, то от команды DevOps до команды разработчиков требуется непрерывный механизм обратной связи, чтобы приложения были более футуристичными и готовыми к Docker / Cloud / Scaling.
Речь идет не о Docker или каких-либо других технологиях контейнеризации.
Контейнеры, такие как Docker, rkt и т. Д., Являются просто способом доставки вашего приложения аналогично статическому двоичному файлу. Вы строите свое развертывание так, чтобы оно содержало все, что ему нужно, и конечному пользователю не нужно ничего, кроме времени выполнения.
Эти решения аналогичны толстым JAR-файлам в Java, где все, что вам (в теории) нужно, - это просто предустановленная среда выполнения (JRE) и все, что нужно, Just Works ™.
Причина, по которой разработчики должны понимать (им не нужно учиться работать с таким инструментом, только зачем это нужно) инструменты оркестровки, заключается в том, что это дает вам некоторые преимущества по сравнению с «традиционным» развертыванием.
EngineYard написал хорошую статью об этом. Весь смысл в том, что когда ваш сервер умирает, вы пожимаете плечами и ждете, когда появится новый. Вы относитесь к ним как к рогатому скоту, у вас работают десятки, сотни, тысячи, и когда кто-то падает, ни вы, ни ваши клиенты не должны об этом знать.
Инструменты Orchestration достигают этого, отслеживая состояние всех приложений (модулей / заданий и т. Д.) В кластере, и когда он видит, что один из серверов перестает отвечать на запросы (отключается), он автоматически перемещает все приложения, которые выполнялись на этом сервере, в другое место.
Благодаря оркестровке вы можете запускать несколько приложений на одном сервере, и оркестратор будет отслеживать ресурсы для вас. Он будет переставлять приложения, когда это необходимо.
Благодаря автоматической обработке отказов в оркестраторах вы можете запускать свои собственные изображения в облаке как есть. Когда вам понадобится обновление, вы просто создаете новый образ, настраиваете свою конфигурацию запуска, чтобы использовать ее сейчас, и просто катитесь. Все будет обработано для вас:
TL; DR. Суть не в докере, а в оркестровке. Docker - это просто расширенная версия tar-архивов / толстых JAR-файлов, необходимых для правильной оркестровки.
Вот, например, некоторые аргументы из поста в блоге, опубликованного в 2014 году и озаглавленного так, чтобы он полностью соответствовал вашему ответу:
- Гораздо более гибкий ввод новых технологий в окружающую среду
- по-прежнему существует серьезная проблема между принятием окончательного протестированного кода и его запуском на конечных производственных серверах. Docker значительно упрощает этот последний шаг
- Docker упрощает сохранение устаревших ОС независимо от того, какой у вас Linux
От: https://thenewstack.io/why-you-should-care-about-docker/
Если вы работаете в докер-контейнере, важно, чтобы эти контейнеры создавались теми же разработчиками, которые создали приложение, работающее на них. Кому еще лучше узнать, какие внешние зависимости нужны и так далее?
Кроме того, конвейер может дать сбой на любом этапе во время CD, особенно когда это этап сборки образа докера, иногда это файл, который отсутствует или необходим lib.
На работе мы познакомили всех разработчиков с докером, объяснив им основы построения файла Docker для обслуживания их приложения, а также упростили конвейер, чтобы можно было только добавить имя и файл Docker, и его приложение будет автоматически построено на следующий толчок, независимо от того, какая технология его запускает.
Быстрый старт Docker - отличное введение в процесс, после чего команда разработчиков DevOps руководит разработчиком в выборе дистрибутива (многие из них не знают, что такое alpine).
Наша задача - предоставить им легкий доступ к инструментам, они сделают все остальное, чтобы они могли исправить это, если что-то не так. Docker на самом деле является частью процесса разработки, и команда devOps предоставляет им образы докеров, которые соответствуют нашим потребностям и которые достаточно просты, поэтому создание нового приложения и его развертывание без помощи занимает всего пару минут.
Docker получает много упоминаний в прессе и блогах, что приводит к интересам разработчиков к его использованию. Для некоторых людей это интерес к игре с новой технологией или пониманию того, как все работает. Для других это желание добавить ключевые слова в свое резюме. В любом случае, чем больше разработчики знают о том, как все работает и как они развернуты, тем меньше они будут удивлены. Из того, что я видел, есть приличный интерес к этому, поэтому не должно быть так сложно поощрять его дальше.
Что ж, если вы когда-либо использовали виртуальные машины для тестирования, вы можете попробовать использовать контейнеры, и докер на самом деле отличный инструмент для тестирования, и его гораздо проще использовать вместо LXC :)