Здравствуйте, mogadanez, Вы писали:
S>>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть? M>для меня — это дешевле чем любым другим способом из тех что я пробовал.
Дешевле — это...? Ну, понятно что времени меньше на чтототам тратится как правило, но хотелось бы подробностей.
M>обойтись могу — например фронтенд не в докере лежит
А бакенд без докера работает?
Здравствуйте, Cyberax, Вы писали:
S>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса. C>
Ещё один, чтающий по диагонали. Я для кого писал что этот шаг после тестов на стейже?
C>Основное требование к системе деплоймента — это НАДЁЖНОСТЬ. Она никогда не должна застревать в промежуточных ситуациях.
Спасибо, кеп.
C>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд.
А докер это тупой chroot, да?
C>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п.
Я с ансиблом тоже такое гарантировать могу. Достаточно просто знать что программисты вот тут и вот тут мусорят и надо подметать.
Здравствуйте, Mamut, Вы писали:
M>Потому что блин. Тту рядом Шеридан даже понять не может, что ему Киберакс говорит про чистку окружения на хосте в случае чего. Почитай подтред
, весьма показтелен.
Пожалуй изменю разок своему правилу не кормить тебя.
C>он сам (ансибль — прим.) ничего не чистит.
Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
...
Или ты про удаление проекта с хоста? Зачем тогда ставить?
Впрочем насрать. Надо будет — значит будет плейбук и про удаление.
, весьма показтелен. S>Пожалуй изменю разок своему правилу не кормить тебя.
Единственный, кого кормят тут, — это ты. Удивительно, что народ вообще все еще пытается тебе хоть что-то объяснить.
S>
C>>он сам (ансибль — прим.) ничего не чистит.
S>Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
Выделенное
S>Но тебе плевать, тебе главное плеснуть так чтобы ложечки остались.
Это тебе плевать. Понимать, что тебе пишут оппоненты ты не способен физиологически
Cyberax: В отличие от анзибля, докер гарантирует, что выполняемый контейнер не оставит НИЧЕГО на хосте
Sheridan: чистит. Не там и не то что ты думаешь
Sheridan: При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.
Опять фигурная резка по цитате. Причом не стесняясь, тут же, сразу.
Приведу полностью опять. Выделю обрезанное тобой.
C>он сам (ансибль — прим.) ничего не чистит.
Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
... Или ты про удаление проекта с хоста? Зачем тогда ставить?
Впрочем насрать. Надо будет — значит будет плейбук и про удаление.
Здравствуйте, Sheridan, Вы писали:
M>>хуяк хуяк и в продакшен? S>Печально если вы так делаете. S>Я для кого, бл, написал "Ну вот подготовили релиз/фикс. Оттестили на stage."?
"С ансиблом практически то же самое. Только сразу на прод."
Здравствуйте, mogadanez, Вы писали:
M>>>хуяк хуяк и в продакшен? S>>Печально если вы так делаете. S>>Я для кого, бл, написал "Ну вот подготовили релиз/фикс. Оттестили на stage."? M>"С ансиблом практически то же самое. Только сразу на прод."
После прогона на стейже, да. Имелось в виду деплой не в контейнеры с последующим их разворачиванием на проде, а сразу разворачивать на прод.
SD>Второй — на передовой продуктового софтостроения. Неважно, что там баг на баге и багом погоняет, важно, что это первый софт такого рода, и его *уже покупают*. Быть первым — это тоже круто, тоже сложно, тоже выгорание, тяжелые мозги и вечная гонка.
вот это странный вывод — одно из другого никак не вытекает.
Если у меня красивый оттестированый и безбажный код — это не значит что я должен выкинуть докер.
Докер нужен для удобства и низкой стоимости поддержки независимо от качества кода внутри
Здра
S>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть?
1. Стандартизация, единая по всему миру, кроме некоторых маргиналов:
— единый "интерфейс" внутри, для приложения (docker image)
— единый интерфейс снаружи, Docker/ContainerD
— единый подход к daemonization (Pid 0)
— на уровне процессов
— на уровне файловой системы
— на уровне сети
3. Complexity reduction
Docker разделяет сложность на 2 разных domain. Внутри контейнеров и снаружи. DevOp не нужно фокусироваться на особенностях/ошибках в целом. Ошибка локализуется или внутри blackbox (artifact/image/base OS) или снаружи (Orchestration)
Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется"
4. Единообразие environment для компонента, задаваемое создателем Image
Здравствуйте, Vetal_ca, Вы писали:
S>>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть? V_>1. Стандартизация, единая по всему миру, кроме некоторых маргиналов:
V_>- единый "интерфейс" внутри, для приложения (docker image) V_>- единый интерфейс снаружи, Docker/ContainerD V_>- единый подход к daemonization (Pid 0)
Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую?
Чем не устраивает systemd?
V_>Стандартизация как Deployment так и runtime
Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
V_>2. Инкапсуляция\изоляция, гарантируемая фреймфорком.
Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
V_>Docker разделяет сложность на 2 разных domain. Внутри контейнеров и снаружи. DevOp не нужно фокусироваться на особенностях/ошибках в целом. Ошибка локализуется или внутри blackbox (artifact/image/base OS) или снаружи (Orchestration)
А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".
V_>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется"
Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".
V_>4. Единообразие environment для компонента, задаваемое создателем Image
С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде.
Если удобно разрабу в докере писать — да велкам, пусть пишет.
Здравствуйте, Sheridan, Вы писали:
S>Дешевле — это...? Ну, понятно что времени меньше на чтототам тратится как правило, но хотелось бы подробностей.
* не нужен специально обученный админ/девопс с завышеным ЧСВ
* за последние 5 лет в сумме на два десятка проектов потрачено сумарно не больше 10 человеко-дней на работу с докером.
до этого когда был ансибл лично потратил несколько месяцев причем был крайне недоволен результатом. после этого наняли "специально обученного человека".
пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить
параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
* Я выбираю самый простой способ, это не челендж какой то чтобы для ачивки на ансибле деплой делать и колоться. Если будет чтото еще проще чем докер — уйду туда
M>>обойтись могу — например фронтенд не в докере лежит S>А бакенд без докера работает?
в докере
S>Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую? S>Чем не устраивает systemd?
сколько ты потратишь времени на то чтобы запустить например 2 одинаковых процесса А параллельно? гарантируешь что это будет работать для вообще любого процесса?
сколько ты потратишь времени на разруливание конфликта версий библиотек для процессов А и Б
S>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
так начинается бардак и проблемы
S>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>Если удобно разрабу в докере писать — да велкам, пусть пишет.
а так начнется срач между девопсами и разработчиками. Плюс кто платить за это будет?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Vetal_ca, Вы писали:
S>Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую? S>Чем не устраивает systemd?
Я скажу честно, проще отсеять Шеридана с его непониманием. Это не издевательство а очень честный ответ, от самого сердца. Спустить стандартное решение в регионы и не мучаться, дешевле и проще на пособии держать.
Набери в гугле "systemd vs" и читай ниже, стандартизация:
V_>>Стандартизация как Deployment так и runtime S>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
Понимание, что такое стандартизация и для чего это нужно — базовое для инженера. От международной системы единиц, ГОСТ-ов на гайки и болты, до стандартов на электронику и IT. Если человек этого не понимает, он должен быть отбракован экзаменатором, чтобы не тратить время специалистов. В данном случае, хватило бы, HR или, даже, бота с хорошим AI. ДевОпсов не было, а стандартизация уж точно была в советской инженерной школе, тут путаться — недопустимо.
Утомил, правда, эти "дятлы" — мусор в твоей голове
V_>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком. S>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
Вне контейнеров/компонентов есть еще очень большой мир, не видимый из твоей песочницы. Чтобы ухватить внимание знающих людей, тебе придется это подтянуть. Не хочешь подтягивать — игнор/кризис/голод и прочие стимуляторы тебе в помощь. В мире миллиарды людей которые не саморазвиваются. Они никому не интересны, кроме как для своих мамы/папы и, в очень малой степени, местным органам власти. Почему ты должен быть исключением?
S>А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".
Дихотомия. Быстро определить, где ошибка и отдать человеку соответствующей квалификации, направления и ответственности. Чтобы не забивать гвозди микроскопом, каждый раз привлекая дорогостоящего специалиста или team meeting, охватывая весь диапазон для мозгового штурма. Это как вместо механика, каждый раз машину на завод отправлять, главному инженеру, если error domain — это вся машина в целом
V_>>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется" S>Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".
Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
V_>>4. Единообразие environment для компонента, задаваемое создателем Image S>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
Про стандартизацию уже было — подтянешь, поговорим.
S>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>Если удобно разрабу в докере писать — да велкам, пусть пишет.
Про версии библиотеки знает разработчик и/или создатель Docker Image. Читай, натренированный девелопер. DevOps/SecOps ревьювит для соответствия best practices/security standards. Маппинг портов/интерфейсов легко разруливается на уровне DevOps, для этого не нужно лезть внутрь ini/conf файлов компонентов
P.S. В таких беседах очень четко раскрывается притягательность фильмов про зомби. Зомби — медленные, неуклюжие. Но их много и они со своей медленностью и неуклюжестью идут съесть твой мозг.
M>* за последние 5 лет в сумме на два десятка проектов потрачено сумарно не больше 10 человеко-дней на работу с докером. M>до этого когда был ансибл лично потратил несколько месяцев причем был крайне недоволен результатом. после этого наняли "специально обученного человека". M>пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить M>параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
Это вы Ансибл иасилили. Взяли бы Шеридана — были бы на тех же недостижимых высотах, как и он.
А так, искреннее сочувствие и все такое прочее. Убер ответ. Там-тарам-тарам-пам — пум
А, вообще, мы халявщики. Работаем с понятными и предсказуемыми железяками и программами.
Я рукоплещу стоя людям, работающим с другими людьми. У которых свои тараканы, странности и виденье мира. Учителям, врачам, психиатрам, сиделкам, нянечкам, HR-ам/кадровикам на "передовой", управляющим персоналом.
Здравствуйте, mogadanez, Вы писали:
S>>Чем не устраивает systemd? M>сколько ты потратишь времени на то чтобы запустить например 2 одинаковых процесса А параллельно? гарантируешь что это будет работать для вообще любого процесса?
Быстрее, чем программер напишет код.
M>сколько ты потратишь времени на разруливание конфликта версий библиотек для процессов А и Б
А вот тут неправильное решение. Правильное решение — добиться чтобы процессы А и Б работали с одинаковыми версиями библиотек.
S>>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение. M>так начинается бардак и проблемы
Значит плохой девопс. или разраб. Надо выяснять почему они не общаются.
S>>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>>Если удобно разрабу в докере писать — да велкам, пусть пишет. M>а так начнется срач между девопсами и разработчиками. Плюс кто платить за это будет?
Значит давать розг обоим пока не начнут работать вместе, а не друг против друга.
Здравствуйте, mogadanez, Вы писали:
S>>Дешевле — это...? Ну, понятно что времени меньше на чтототам тратится как правило, но хотелось бы подробностей. M>* не нужен специально обученный админ/девопс с завышеным ЧСВ
Не нанимайте с завышенным.
M>* за последние 5 лет в сумме на два десятка проектов потрачено сумарно не больше 10 человеко-дней на работу с докером. M>до этого когда был ансибл лично потратил несколько месяцев причем был крайне недоволен результатом. после этого наняли "специально обученного человека". M>пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить M>параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
Девопсу не ставились задачи значит. Кинули в воду и смотрели как выплывет. Вот он и заскучал, и начал рефакторинги с переходами.
M>* Я выбираю самый простой способ, это не челендж какой то чтобы для ачивки на ансибле деплой делать и колоться. Если будет чтото еще проще чем докер — уйду туда
Ансибл — проще.
M>>>обойтись могу — например фронтенд не в докере лежит S>>А бакенд без докера работает? M>в докере
То есть работает только в тепличных условиях?
Здравствуйте, Vetal_ca, Вы писали:
V_>Набери в гугле "systemd vs" и читай ниже, стандартизация:
Ансиблом можно добиться стандартного окружения. Не только докером единым.
V_>>>Стандартизация как Deployment так и runtime S>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
V_>Вне контейнеров/компонентов есть еще очень большой мир, не видимый из твоей песочницы. Чтобы ухватить внимание знающих людей, тебе придется это подтянуть. Не хочешь подтягивать — игнор/кризис/голод и прочие стимуляторы тебе в помощь. В мире миллиарды людей которые не саморазвиваются. Они никому не интересны, кроме как для своих мамы/папы и, в очень малой степени, местным органам власти. Почему ты должен быть исключением?
Песочница у вас, докер называется.
V_>Дихотомия. Быстро определить, где ошибка и отдать человеку соответствующей квалификации, направления и ответственности. Чтобы не забивать гвозди микроскопом, каждый раз привлекая дорогостоящего специалиста или team meeting, охватывая весь диапазон для мозгового штурма. Это как вместо механика, каждый раз машину на завод отправлять, главному инженеру, если error domain — это вся машина в целом
А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
V_>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
Это и есть гарантия работы компонента.
V_>>>4. Единообразие environment для компонента, задаваемое создателем Image S>>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение. V_>Про стандартизацию уже было — подтянешь, поговорим.
Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
S>>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>>Если удобно разрабу в докере писать — да велкам, пусть пишет.
V_>Про версии библиотеки знает разработчик и/или создатель Docker Image. Читай, натренированный девелопер. DevOps/SecOps ревьювит для соответствия best practices/security standards. Маппинг портов/интерфейсов легко разруливается на уровне DevOps, для этого не нужно лезть внутрь ini/conf файлов компонентов
Ну то есть по твоему мнению девапс это такой раб, который обязан слушаться программеров иначе розги? Они должны в команде работать. Девапс выступает вдобавок ко всему еще и связующим звеном. Говорит одной команде например что другие уже перешли на новую версию либы и надо бы тоже подтянуться.
И выучи понятия "например", "чтото типа", "в этом роде". А то воспринимаешь всё буквально...
Здравствуйте, Vetal_ca, Вы писали:
V_> Работаем с понятными и предсказуемыми железяками и программами.
Как ни странно я точно так же делаю, но без докера. Магия наверное...
Здравствуйте, Sheridan, Вы писали:
S>>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса. C>> S>Ещё один, чтающий по диагонали. Я для кого писал что этот шаг после тестов на стейже?
Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать?
C>>Основное требование к системе деплоймента — это НАДЁЖНОСТЬ. Она никогда не должна застревать в промежуточных ситуациях. S>Спасибо, кеп.
Пожалуйста.
C>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд. S>А докер это тупой chroot, да?
Да. И благодаря этому он и гарантирует надёжность.
C>>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п. S>Я с ансиблом тоже такое гарантировать могу.
Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например.
