Как правило, разработчик заботится о соответствии бизнес-требованиям. Он / она может иметь опыт в конкретном стеке или структуре. Но должен ли он / она приложить усилия для изучения докера и его различных методов развертывания (роя, куба, мезо и т. Д.)?
Проще говоря, почему разработчик должен заботиться о докере?
PS: родительский вопрос к этому посту - Смысл введения докера в команду разработчиков
docker
project-management
orchestration
Абхай Пай
источник
источник
Я дам вам мою точку зрения. Разработчики должны заботиться о докере, поскольку есть другие разработчики, которые хотят использовать докер и уже накопили опыт в этом. Они готовы взять на себя роль инженера 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 году и озаглавленного так, чтобы он полностью соответствовал вашему ответу:
От: https://thenewstack.io/why-you-should-care-about-docker/
источник
Если вы работаете в докер-контейнере, важно, чтобы эти контейнеры создавались теми же разработчиками, которые создали приложение, работающее на них. Кому еще лучше узнать, какие внешние зависимости нужны и так далее?
Кроме того, конвейер может дать сбой на любом этапе во время CD, особенно когда это этап сборки образа докера, иногда это файл, который отсутствует или необходим lib.
На работе мы познакомили всех разработчиков с докером, объяснив им основы построения файла Docker для обслуживания их приложения, а также упростили конвейер, чтобы можно было только добавить имя и файл Docker, и его приложение будет автоматически построено на следующий толчок, независимо от того, какая технология его запускает.
Быстрый старт Docker - отличное введение в процесс, после чего команда разработчиков DevOps руководит разработчиком в выборе дистрибутива (многие из них не знают, что такое
alpine).Наша задача - предоставить им легкий доступ к инструментам, они сделают все остальное, чтобы они могли исправить это, если что-то не так. Docker на самом деле является частью процесса разработки, и команда devOps предоставляет им образы докеров, которые соответствуют нашим потребностям и которые достаточно просты, поэтому создание нового приложения и его развертывание без помощи занимает всего пару минут.
источник
Docker получает много упоминаний в прессе и блогах, что приводит к интересам разработчиков к его использованию. Для некоторых людей это интерес к игре с новой технологией или пониманию того, как все работает. Для других это желание добавить ключевые слова в свое резюме. В любом случае, чем больше разработчики знают о том, как все работает и как они развернуты, тем меньше они будут удивлены. Из того, что я видел, есть приличный интерес к этому, поэтому не должно быть так сложно поощрять его дальше.
источник
Что ж, если вы когда-либо использовали виртуальные машины для тестирования, вы можете попробовать использовать контейнеры, и докер на самом деле отличный инструмент для тестирования, и его гораздо проще использовать вместо LXC :)
источник