Сергей Протько:
Мне кажется, что мы доказываем друг другу одно и тоже. По моему оба согласны, что docker не всегда уместен - об этом же начался диалог. А то, что в других случаях он все же уместен - это я тоже соглашусь. Мне самому он нравится и я использую его для своего личного проекта (на RoR).
Как минимум разработчик должен создать пулл реквест, что означает "парни, я додлал, проверяйте, мерджите". Вот как он дал отмашку, что закончил работу - тогда можно собирать.
По поводу билдов 10 часов - вполне реально. Система рассчета рисков в Дойче Банке собирается 4 часа. Что, если проект разрастется в 2.5 раза? Это не похоже на фантастику.
По поводу прогона билда после каждого коммита: у нас в день около тысячи коммитов. Из них 97-98% сделаны в брэнчах "feature/" или "bugfix/" - этот мусор зачем собирать, если он еще не планируется к мерджу? Самому разработчику неприятно будет, что кто-то пытается "проверить" его недоделанную работу и сиди потом красней перед командой за сваленный билд.
"Обычно это все все же для всего хоста делается, или я не прав?"
Именно. А докерный процесс не имеет при этом доступа к TAP :) Тут можно выкрутиться сделав бридж до докера и подняв траффик до третьего уровня, чтобы netfilter позволил с ним работать, но проделывать эти чудеса ради того, чтобы использовать докер... докер все же - инструмент, а не модная самоцель. И здесь он явно не уместен. Он усложняет архитектуру, не давая ничего взамен.
__________________________
"а зачем в случае с docker паковать что-то в deb/rpm? Вот честно?"
Потому что вы паковали монолитный сервис (какой-нибудь простенький томкат или постргерсс). А что, если в коде также содержатся девелоперские хидеры, например? А если дебаг символы нужно убрать? Вы же не понесете их в прод? А что, если нужно управлять зависимостями (которые не для сборки, а для работы)? Миллион ситуаций.
__________________________
"p.s. докер не решает всех проблем"
Именно! Поэтому его не стоит лепить где попало. Что я и пытался объяснить тем товарищам. Докер отлично помогает в простых приложениях только.
Сергей Протько:
много контекстов. Например:
1. IPS/IDS приложение. Docker же приляпает новую сеть. Соответственно все, что ниже третьего уровня пройдет. Promiscous mode вообще не будет работать из контейнера.
2. Любой случай, когда проект серьезный и упаковывают все по правилам (.deb, .rpm).
3. Когда все уже в контейнерах (это как раз описанный мной случай с работодателем) и плодить контейнер в контейнере нет никакого смысла. Потому что даже контейнер первого уровня (BeansTalk) разворачивается так же легко.
Есть и еще варианты.
Серебрянной пули же не бывает :) Если вам показалось, что бывает, значит вы что-то упустили из виду.
romy4:
Не, мне это не интересно. Все это не будет работать, когда будет 10 разрабов и парочка тестеров. Методолигии тут никакой нет. Нет даже терминологии общепринятой :)
romy4:
Вы меня не услышали: коммит или мердж целого сэта коммитов? Как тестировщик получает извещения о новом функционале? Почему, кстати, "тестировщик" и "коммит" в единственном числе?
Думай Головой:
Если перестать слушать политику, то можно докатиться до того, что перестанете ненавидеть хохлов и начнете уважать израильский апартеид. Так нельзя ))))
Про buzz-word точно очень сказано. 99% людей употребляют этот термин, не понимая, что за ним стоит.
Меня как-то не взяли на работу потому, что при разработке плана инфраструктуры я не сделал Docker. Цитата:
- DevOps должен использовать Docker
- Вам надо оптимальное решение под ваши задачи или вам нужны модные технологии вне зависимости от их уместности?
- Нам нужен DevOps, а не сисадмин
:)
Небольшие замечания:
DevOps - не профессия
Vagrant - не контейнеры
YAML - не экзотика, а почти столь же распространенный язык разметки, как XML (куча продуктов на нем от Ansible до RoR-конфигов).
Bash, Ruby, Python, Go, Perl - зачем? Нужно знать языки для автоматизации (тут можно оставить Bash и Python только, изредка Ruby) и язык приложения, которое обслуживаешь - тут уж может быть любой язык.
Пума Тайланд: и еще один важный момент, чтоб вы знали: почти все программисты мира заняты где угодно, но только не в "софтверных компаниях". Потому что чисто софтверных компаний на всю Россию от силы две (ну где есть хотябы по 5-10 тысяч программистов) - это EPAM и Luxoft. А вот у меня из окна сейчас видно несколько зданий, где по 70-90 этажей забиты до отказа программистами по несколько тысяч человек на этаже - и все компании профильные. Они там начинаются от банковского сектора (Deutche Bank - 24 этажа по 2k человек) и заканчивается IBM (40 этажей по 3k человек).
Что вы называете "софтверной компание", а что телекомом - ума не приложу.
Пума Тайланд: я думаю, что я очень внимательно читаю тему и ответы на нее. Человек направлен явно в сетевое администрирование. Вы же ему советуете сменить деятельность на ту, где он не получит ни больше вариантов работы ни больше денег.
В доказательство своих слов вы приводите сначала умирание рынка Cisco, даже не подразумевая, что Cisco - это название компании, а не рынок. А сам рынок развивается, а не умирает, как бы там ни шли дела у Cisco.
Затем вы приводите размеры рынка телекома (в сравнении с чем?) как если бы телеком - это был рынок труда сетевиков, хотя на самом деле телеком - это рынок все тех же программистов[и сетевиков, дбашников, релиз/билд-инженеров, куашников и еще кучи всякого сброда]. И он крупнейший в мире, хотя это ни доказывает и не подтверждает вашу очень абстрактную точку зрения.
До тех пор, пока телеком будет для вас специальностью, а Cisco - рынком, мне будет тяжело оспорить эту вакханалию, не нарушив закон тождества логики. Начните точно и четко формулировать свои мысли на основе общепринятых терминов. После этого вы получите от меня четкий и внятный конструктив в ответ. А пока я могу лишь изображать facepalm.
Закройте этот диалог и напишите свое мнение на тему основного вопроса с нуля, с учетом того, что есть специальности, есть рынки и есть статистика. И это три разных существительных. И сделайте мысль законченной в одном посте, а не вкидывайте намеки типа "смените работу, вырастите, потом ещё раз смените работу".
Мне кажется, что мы доказываем друг другу одно и тоже. По моему оба согласны, что docker не всегда уместен - об этом же начался диалог. А то, что в других случаях он все же уместен - это я тоже соглашусь. Мне самому он нравится и я использую его для своего личного проекта (на RoR).