Комментарии 66
Прикольная вещь, но не особо понятно зачем. У меня есть базовый dockerfile дл asp.net можно нейронку попросить сделать для проекта и он будет такой же. А вот в дальнейшем начинаются ухищрения с пробросом каких-то команд, файлов, параметров окружений и т.д. и не думаю, что init с этим поможет.
Для пользователей у кого нет базового dockerfile и понимания как его писать - никогда не н. В лучшем случае - спросят нейронку. В более вероятно - возьмут первый пример с гугла который запустится. Даже если он устарел вконец.
Вот кстати некоторые нейронки вроде Ассистента в Kagi Search не только генерят код с пояснениями но еще и ссылки пишут на статьи почему (мне - на хабр кинула и сайт CROC'а), воде адекватно
M$ Copilot тоже ссылки даёт, откуда стырил.
Копайлот указывает, Gemini тоже. Иногда правда указывают ерунду, но в целом дают материал, куда копать и на основании чего они дали справку.
Смысл в том, что просто dockerfile, чтобы запустился - простой. И чреез init он будет скорее всего +- тем же самым. Вопрос в том, сможет ли init например при запуске базы данных добавить скрипт, который будет что-то делать или просто перенести конфиги для постгры? Поэтому и не понятен какой смысл, если нужен файл сложнее базовой версии.
В нашем проекте для . Net все докерфайлы удалил. Встроенная контейнеризация работает отлично, и можно спокойно двигать проекты, без опасения что забудешь про контейнеры.
+1, часто начал нейронку просить делать, исправлять, дополнять.
Пусть это будет простое Flask-приложение.
А пусть будет сложное. Что будет со сложным?
Кажется, проблема преувеличена. Не так часто, на мой взгляд, приходится добавлять в докерфайлы что-то принципиально новое. А если часто - есть различные практики, упрощающие прототипирование, та же "3 Musketeers".
Это уж безотносительно того, что заботиться о прямоте докерфайлов, контейнеризации вообще и CI должны сотрудники эксплуатации, а не разработки.
Это уж безотносительно того, что заботиться о прямоте докерфайлов, контейнеризации вообще и CI должны сотрудники эксплуатации, а не разработки.
Что прямо противоречит концепции DevOps, которая, как понятно из самого названия, есть DEVelopment+OPerationS.
Я не считаю контейнеризацию самым удачным способом упаковки кода для распространения. Но если с такой простой концепцией у разработчика возникают проблемы, то этот разработчик - максимум джун.
Хороший разработчик наверняка, загуглив, очень быстро сможет набросать работоспособный конфиг для Докера, Композа и даже Куба. Но нюанс в том, что работоспособности в некоторых случаях недостаточно - и вот на это может уйти довольно много времени, которое можно было потратить значительно продуктивнее, отдав задачи, связанные с инфраструктурой - эксплуатации, безопасностью - айтисекам и так далее.
Методология Devops вовсе не предполагает, что разработчик непременно должен тратить свой время на написание конфигов Докера, Хелм-чартов и прочей обвязки, собственно, приложения. Если, конечно, он не один в поле - но в таких вырожденных случаях странно вообще говорить о каких-то методологиях :)
Как программист со стажем скажу, что Dockerfile от разработчика - это очень хорошая и правильная практика. Просто потому, что он описывает в нем "а как вообще собрать мое приложение".
Это не трата времени, а его экономия - на выяснение "почему не собирается" или "почему не работает как надо" уйдет гораздо больше времени, чем на поддержку разработчиком Dockerfile-а.
А если есть нюансы - то ни кто не мешает DevOps или еще кому поработать над этим Dockerfile вместе с разработчиком, чтобы учесть все эти нюансы.
Так что Dockerfile от разработчика в корне проекта - это очень и очень хорошая практика. И очень полезная - неоднократно выяснял "а как это собрать" через изучение Dockerfile, не отвлекая расспросами других разработчиков.
И Dockerfile - это не конфиги докера, k8s или прочая "обвязка".
Из "обвязки" для разработчика хорошо владеть docker-compose (помимо docker) - чтобы уметь запускать все сервисы проекта в изолированной среде. Ну а большее - уже по желанию/возможностям/необходимости.
Повезло админам, работающим с вами, завидую им :)
Мне гораздо чаще встречались другие варианты развития событий:
Разработчик всё делает в IDE, в том числе компиляцию и запуск приложения - поэтому когда дело доходит до выкатки в какое-то общее окружение, время тратится на преодоление тезиса "у меня на компе, под 32-битной виндой с пятью версиями JDK - всё работает".
Разработчик копипастит в Dockerfile содержимое первых ссылок "spring boot dockerfile ubuntu" или ответ слегка галлюцинирующего ChatGPT, делая триста слоёв и образ размером 500 мегабайт + само приложение.
Вы описали как раз плохих разработчиков. За аргумент "у меня всё работает" вообще надо гнать из профессии, как по мне.
Админ может накрутить в Dockerfile не хуже разработчика. Но исправлять будет сложнее - потому как нужны согласованные изменения в проекте и там, где лежит его Dockerfile.
Если же бекенд-разработчик со стажем отказывается работать с Dockerfile и docker - то это крайне хреново.
Начинающему еще можно простить. И начать изучать новое - как раз есть повод (компиляция через IDE и отсутствие Dockerfile ;) ) Без docker сейчас никуда не деться.
P.S. Если над проектом работают только начинающие разработчики - то отсутствие Dockerfile и компиляция через IDE были бы далеко не самыми главными моими проблемами )
Можно и ещё как. За пределами докера есть огромный мир. Докеры для "продакшн" не пригодны совсем. Это так - дома студентам поиграться. Но для "продакшн" используются полноценная виртуализация или полноценные контейнеры LXC/Jail с пакетами, которые можно полноценно обслуживать. Это тоже самое, если студентом играть только с VirtualBox или VMWare Workstation и поговаривать - а куда сейчас без них, если нужна виртуализация?
За пределами докера есть огромный мир - не спорю, есть.
А вот про непрегодность докера для продакшена - поспорил бы. Уже лет 10 активно и успешно в продакшене он используется. И очень-очень-очень много где. Скажи мне кто, что он docker (или аналоги) совсем не использует - я скорее удивлюсь (речь, разумеется, про бекенд).
Так что эра docker-а (и/или аналогов) в продакшен пришла, и каких-либо предпосылок для ее завершения я не вижу.
Ну и у HighLoad-адептов может быть свой взгляд на пригодность docker к продакшену. Но опять же, не поверю, что они совсем от docker отказались.
Ну и не глядя на прод, разработчику, тем более бекенд-разработчику - docker очень и очень полезен.
Разные СУБД можно гонять локально, практически не заморачиваясь их конфигурацией. Можно развернуть пачку микросервисов локально для отладки. Можно много чего еще полезного сделать - да даже IDE в контейнере запустить.
P.S. Для embeded-разработки и системной разработки тоже можно использовать docker периодически (например, Lakka для сборки образов может использовать специально подготовленный docker-образ).
Разве что - для небольших проектов. А если на проекте 3-4 команды - какой из 20-ти вариантов "Dockerfile от разработчика" вы будете использовать?
Тот, что в корне проекта ) Или тот, что в ReadMe упоминается.
Но я ни разу не видел 20 Dockerfile в проекте (если не брать проекты-сборники Dockerfile или монорепы какие).
Несколько - да, бывает. Но в них можно разобраться при желании )
Есть и более 20 :) Но еще раз подчеркну - для небольшого проекта (если мы говорим о серьезных проектах - какой, в пень, readme?), или на старте проекта. Я вот сейчас смотрю на текущий проект - 4 Dockerfile + docker-compose. 2/3 от объема - env vars, большинство из которых - я понятия не имею для чего, и уж разбираться в этом точно не буду. Точнее так - какой смысл? Мое понимание проекта от этого не сдвинется ни в какую сторону. А как и где он разворачивается, нахрена эти переменные и в каких средах работает - мне, как разработчику, вообще по-барабану. Хоть на Siemens sl45 пусть запускают.
Серьезный / несерьезный проект - это несерьезная классификация )
Большой / небольшой проект - да, еще можно оценивать. Сложный / несложный - тоже можно (и не сказать, что это к размеру привязано сильно, хотя некая корреляция и есть).
Ну а сложность Dockerfile - не сказал бы что сильно от размера проекта зависит. Да, можно предположить, что большой и более сложный проект будет иметь и более сложный Dockerfile. Но это не точно. Просто потому что все эти десятки env заменяется простым конфиг-файлом. А в Dockerfile остается сборка да команда запуска. И даже для больших и сложных проектов этого может быть достаточно (а может быть и недостаточно, не спорю).
P.S. смотрю первый попавшийся в IDE проект - 3 Dockerfile + docker-compose. Но проект не сказать что сложный или большой.
Хотя... Сложный - еще можно назвать. Просто потому что бекенд на Golang, статичный фронт через NodeJS генерируется, а документация генерируется через Python. Ну и 60+ параметров, которые бекенду через env/флаги/конфиг задаются (в минимуме, правда, можно ничего не задавать).
А если разработчику не надо распространять код и он не в курсе всяких докеров и папетов, он тогда по умолчанию всегда ниже джуриора?))
Спасибо за ссылку на "мушкетёров"! Давно пришёл к набору аналогичных практик, но не знал что это было собрано в манифест.
Ты или сам разбираешься во всех этих нюансах, или работаешь с тем, кто в них разбирается. Или в самый неожиданный момент получишь много-много проблем, которые и не знаешь как решать или куда вообще смотреть.
Так что если надежность не важна - да, можно не париться.
Я принципиально не умею и не хочу даже разбираться в конфигурации серверов, подключении сторонних версий пхп, в получении сертификата и тд и тп.
Поддерживаю!
Ведь пока одни разработчики так считают, моя ценность и ценность других бекендеров, которые не чураются с докером разобраться, приложение на VPS перенести, ключи для ssh сделать и кучу чего по мелочи, растет, как и зарплата.
Да нифига, я работаю за одного, так как я работаю 8 часов в день, за них мне и платят, со всеми знаниями которыми я обладаю.
И когда я пополняю знания востребованными направлениями - зп растет. Правда в основном при смене работы. Так как на текущей ЗП растет по результатам работы а не багажу знаний. Ну если не растет - меняю работу.
Я прохожу курсы в рабочее время за счет работодателя. Так что я (пусть даже при равной с вами ЗП) еще и часть недели не формочки клепаю, а лекции смотрю, мозги разгружаю.
И я сильно сомневаюсь, что человек со знаниями 10-20 летней давности, ничему не учась может получать больше, чем я сейчас. (хотя была тут новость о серебрянной (по цвету волос) лиге кобола, но то в штатах)
Айтишник, который уже дет 10 или 20 как перестал развиваться и учиться новому, боюсь, отстал от рынка на 10-20 лет... Таеая у нас работа, мы учимся постоянно, каждый день. А как иначе?
Я понимаю Вашу идеологию, она имеет место быть, но вы берете какие-то крайние случаи.
Я програмист, а значит мне платят только за программирование. Общаться с заказчиками - дело аналитика, вы работаете только по ТЗ и не шага влево. Покрывать код тестами? Зачем, ведь это прямая обазанность тестировщиков. Если ваш код скомпилировался - значит все как надо. Работать с продом должны только девопсы, это ведь не Ваше дело, с какими параметрами и на каких ресурсах это все деплоится, пусть сами мониторят, чего это вдруг VPS отожрала ресурсов. Оптимизировать запросы к БД и отслеживать транзакции? Пусть DBA оптимизуруют базу, они за это деньги получают. Я уж молчу за составление документации, это вообще не царское дело.
Я не призываю работать за себя и того парня, просто есть реальность. Если вы работаете в довольно крупной фирме, с несколькими командами, отделами с архитекторами и системными инженерами, то Вас скорее всего физически не допустят до прода и Вам да, не надо разбираться в VPS и различных аспектах. Но есть куча компаний, где гораздо меньше штат, где аналитиков вообще может не быть, где разрабам, которые могут закрыть некоторые задачи аналитика или девопса платят и платят хорошо и выше рынка (если вы себя продать можете, конечно). Больше, чем простому мидлу-джуну, где моя хата с края и я не хочу знать, как это работает в проде. Вы рано или поздно выйдете на рынок труда в поисках новой фирмы, и в текущих реалиях, возможно будет просто больно.
И да. Это не зарплата у вас растет. Это новая яхта гендира и его новая квартира таким образом покупается.
Вы это моей 2НДФЛ расскажите, мы вместе посмеемся. Как там тратит деньги менджемент - мне все равно, покуда мне платят сумму, которая меня устраивает. И чем больше я делаю "дополнительных" задач, тем проще мне требовать повышения ЗП и получать его и тем проще поулчать новые офферы и либо уходить на новую ЗП в другую фирму, либо снова повышать на текущей работе. Так что ситуация win-win.
Вы когда в автосервис приезжаете, Вам электрику делает электрик, а не моторист, а механик не лезет в мотор. Это - нормально.
Так я и говорю, что все зависит от формата и размера компании, где вы работаете. На примере тех же сервисов, есть крупные диллеры, официальные сервисы и какие-то сети где да, будут и электрики, и жестянщики и много кто еще. В более мелких, "гаражных" будут пересечения. И там и там платят +- одинаково на самом деле.
Расскажите о своём НДФЛ юристам и адвокатам, которые работают по какой-то одной (или нескольким) зонам ответственности и получают порой миллионы
Юристы много не получают, даже если работают в газпроме, уж поверьте. За исключением наверное тех, кто ушел в менджмент или открыл свой бизнес. Да и вообще, вы еще сравните с футболистом, блогером или президентом, что так мелко?
Взрослые люди тем и отличаются от детей, что не стремятся стать стахановцами, не губят свою профессию, имеют неформальные профсоюзы и всячески пытаются отвесить от себя ненужные обязательства
Я не альтруист и все это делаю не из каких-то "стахановских" соображений, не за медальку или грамоту лучшего сотруднкиа месяца. Что-то мне просто интересно, что-то дает мне конкурентное преимущество на рынке труда перед другими такими, которые "мы только програмировать". И это хороший способ чтобы повышать свою ЗП, и повышать свой грейд.
Полностью поддерживаю ваше мнение. Даже если вам здесь сто минусов поставят. Точно также наблюдаю 20 лет, делаю ровно такие же выводы. Мой работодатель (компания растет в прибыли) последние 2 года форсит знание разработчиками девопс. Ну я и выступил под всеобщее молчание, что моя задача, как разработчика, выполнена, если все работает на локалке и не падают тесты в тестовых средах. Получил шейминг ограниченности мышления, на годовом ревью «понизили» в ранге. Зарплату тем кто за дев + девопс не повысили.
Почему соковыжималка то? Соковыжималка - это 60 часов в неделю, а то дедлайн. А "ребята, а давайте освоим еще вон ту и вот эту технику и внедрим в команде своими силами, а не будем записываться к SREшникам на через полгода" - это нифига не соковыжималка, а развлечение.
Да, конечно вместо девопса могут вкинуть дизайн или новый фреймворк, который потенциально решит какую-то бесячую проблему, но все равно это фан, по сравнению с "бери больше, кидай дальше, когда мы решим перейти на новый фреймворк, мы сделаем новую редакцию продукта, наберем на нее людей с рынка, которые в нем разбираются, а из вашего отдела оставим одного поддерживать легаси, а остальных уволим."
А "ребята, а давайте освоим еще вон ту и вот эту технику и внедрим в команде своими силами, а не будем записываться к SREшникам на через полгода" - это нифига не соковыжималка, а развлечение.
Давайте. А обычных задач меньше станет?
Да мне пофиг, сколько там у бизнеса обычных задач. У меня обучение встроено в работу, как и у всех в компанде. Поэтому велосити команды рассчитано с учетом обучения, отпусков и с риском больничных.
В работу берется столько обычных задач, сколько может сделать команда.
И так как это согласованно на высшем уровне и является корп стандартом - значит кто-то наверху решил, что это окупается.
Я пишу это как свидетель, во что за 20 лет превратилась эта сфера, став для её участников соковыжимающей машиной с непомерными требованиями от работодателей
Сфера стала другой, тут я с вами соглашусь. Но у меня другое мнение на этот счёт: 20 лет назад когда я собирался идти на программиста (потому что мне это было безумно интересно) мне мой отец говорил: "да нафиг тебе это программирование! Иди в юристы/экономисты! Программисты - это потные ботаники, сидят в своих микросхемах копаются, копейки получают, ты семью не прокормишь.".
Но я все равно пошел, потому что интересно. К счастью так получилось, что сфера "выстрелила", разработчики стали очень востребоваными. Отец потом спустя лет 5-10 стал говорить: "о, как хорошо что ты ИТшник! Это очень круто круто! Можешь теперь работать по интернету на любую компанию мира и быть востребованным!".
Поэтому как минимум этот факт ставит жирный плюс, что все что произошло в сфере ИТ - пошло сильно в плюс за последние 20 лет.
Про то, что "работа программиста это нажимать кнопочки и получать зарплату" - я тоже с вами не соглашусь. Для меня программирование, и всё вокруг что с этим связано - это всё очень интересные сферы, в которые интересно погружаться, копаться и разбираться, создавать и улучшать программы, и за это ещё и платят, да прилично! И при этом тебя ещё любят и хаят, смузи-пузи, гибкие графики (и гибридные) работы. Все условия, чтобы самореализовываться. Поэтому я считаю, что у современных ИТшников есть всё что нужно для счастья, и я не согласен с вами, что ИТ индустрия за последние 20 лет стала только хуже.
Плюс много. В противном случае через пару лет человек при поиске новой работы будет громко жаловаться, что его никуда не берет - а ведь он был очень крупный специалист по пришиванию зеленых пуговиц к левому рукаву.
Поэтому я и пишу систему, которая позволяет работать с контейнерами так же легко как ispmanager.
Может кто-нибудь объяснить: чем опасно запускать свое собственное приложение в контейнере под root? В особенности если к нему и доступа то нет из внешней сети.
Ну, в целом - не опасно, в большинстве случаев.
Однако, "своё собственное" приложение состоит из сторонних библиотек, собирается сторонним компилятором. Если где-то, вдруг, какая-то из библиотек окажется слегка заражённой - оно может запустить какую-то малварь, а способы выхода из контейнера - существуют. Вот один из примеров.
Вероятность этого небольшая, но выше нуля.
Уменьшает вектор атаки: в запущенном контейнере от рута будет достаточно namespace escape vulnerability, а с user-ом понадобится еще и privilege escalation найти, что бы до хоста добраться
Ну и внутри контейнера из-под юзера не так разгуляешься, как рутом
Меня это и смущает.
Я как-то столкнулся со сложным багом: джобина работала примерно год и вдруг зависла. Найти проблему удалось как раз изнутри контейнера. Доустановил всё необходимое для отладки и не только выяснил что было не так, но и оживил приложение (оказалось подвисшее сетевое соединение из-за бага в одной из либ).
А когда приложение не под рутом такое не проканает.
Т.е. получается безопаснее, да, но не отладить уже никак. А установить причину какого-то редкого бага другим способом может никак и не получится..
От такого по идее должен спасать userns-remap
Я вообще всегда перестраховываюсь так:
passwd -l root Чего и Вам желаю, причем и в контейнерах и на виртуалках и на физических машинах
А что до того, почему лучше не выполнять ничего от рута в контейнерах, очень доходчиво тут изложено:
Many users of containers underestimate this task and think that containers are properly isolated from hosts like virtual machines (VMs). The reality is different though. Privileged processes (e.g., running as root) running in the container are identical to privileged processes that run on the host. Therefore, running an application in the container does not isolate it from the host.
Ну, это как минимум, там поверьте, не только в этом причина, это вообще большая тема по безопасности, почему работать от рута плохая практика
Вы должны перестать вручную писать Dockerfile'ы
А ты перестала пить коньяк по утрам? Отвечай! "Да" или "нет"?
Если не писать docker-файлы на "простых" приложений, то ты никогда не научишься их писать для "сложных". Таким образом получается, что никто и никогда не должен и не может писать docker-файлы. У автора провалы в базовой логике рассуждений.
Вы должны перестать вручную писать Dockerfile'ы