M>пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить M>параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
Прям история Спотифая. В теории все хорошо: централизированный репозиторий, где плейбуки, где общие части плейбуков вынесены в расшаренные плейбуки, от которых можно наследоваться (или как оно там в ансибле называется).
На практике: сотни плейбуков. Часть с начала создания компании, часть по best practices, которые уже устарели, часть по новым best practices, которые еще не до конца внедрены. Некоторые новые плейбуки ссылаются на «устаревшие» плейбуки, потому что «устаревшие» имеют то, что нет в новых. Одинаковые куски кода раскиданы по десятку разных плейбуков, потому что разным приложениям и сервисам требуются чуть-чуть разные окружения, например. Ну и т.п.
В итоге там (почти) все выкинули нахрен, сделали централизованный сервис, где деплой и развертка делаются по клику одной кнопки (среди прочего. Его медленно кусками опенсорсят тут: https://backstage.io). И постепенно перетаскивают все в кубернетес и докер.
Здравствуйте, Sheridan, Вы писали:
S>Ансиблом можно добиться стандартного окружения. Не только докером единым.
разные distro's?
S>Песочница у вас, докер называется.
Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
S>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
V_>>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно. S>Это и есть гарантия работы компонента.
Как ансибл влияет на компонент после деплоймента?
S>Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере.
kubectl get certificate --all-namespaces -o json | jq --raw-output ".....
Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Причем:
— сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
— делается для всего кластера. Можно сделать для всех кластеров
— не зависит от внутреннего формата, документации и прочего
Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать.
А зависеть от местных наполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
Здравствуйте, Sheridan, Вы писали:
S>Не нанимайте с завышенным. S>Девопсу не ставились задачи значит. Кинули в воду и смотрели как выплывет. Вот он и заскучал, и начал рефакторинги с переходами. S>Ансибл — проще.
Есть такие чуваки... Если у бизнеса проблемы, нет роста, застой, их нанимают консультантами и они разруливают сложности. Дико дорого стоят. Не тем ты занят, Шеридан. Мог бы рубить бабло, решать интересные задачи... А ты ансибл теребонькаешь, людям с докером работать мешаешь.
S>То есть работает только в тепличных условиях?
Да, да! Работаем в изолированной среде, не заботясь о том, что там рядом у заказчика крутится, и не сломается ли что-нить, если мы какую-нить свою либу вкорячим на сервант. Да!
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
F>Есть такие чуваки... Если у бизнеса проблемы, нет роста, застой, их нанимают консультантами и они разруливают сложности. Дико дорого стоят. Не тем ты занят, Шеридан. Мог бы рубить бабло, решать интересные задачи... А ты ансибл теребонькаешь, людям с докером работать мешаешь.
Уверяю, очень хорошо он живет у себя в провинции. Не надо ему бабло ради бабла рубить в угоду внутреннему дзену.
Комфорт это один из опаснейших причин застоя
И это я могу понять, там, хорошо, спокойно, правильно все. Надо немного, а все что надо, есть. Друзья-знакомые-родственники.
Но то что несет ерунду полную. Да и, перемены, рано или поздно выкинут его из этого дзена на мороз.
Здравствуйте, Sheridan, Вы писали:
M>>* Я выбираю самый простой способ, это не челендж какой то чтобы для ачивки на ансибле деплой делать и колоться. Если будет чтото еще проще чем докер — уйду туда S>Ансибл — проще.
нет
ты дркер пробовал вообще?
M>>>>обойтись могу — например фронтенд не в докере лежит S>>>А бакенд без докера работает? M>>в докере S>То есть работает только в тепличных условиях?
он работает в любых условиях. разворачивать его докером проще и дешевле чем любым другим способом.
Здравствуйте, Sheridan, Вы писали:
V_>>Стандартизация как Deployment так и runtime S>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
Хватит бредить, а?
Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию.
В случае с Docker/Kubernetes такая ситуация НЕВОЗМОЖНА в принципе. Код, который может быть ошибочен, специально изолирован и ограничен, так что последствия его отказа тоже будут ограничены и предсказуемы. И это принципиально правильный подход, вообще во всей инженерной науке.
Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков.
Здравствуйте, Cyberax, Вы писали:
S>>Ещё один, чтающий по диагонали. Я для кого писал что этот шаг после тестов на стейже? C>Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать?
Дядя, у тебя цель какая? Доказать что ансибл гавно или что? Вот этот глупый вопрос к чему ты принёс? Ты вроде не глупый человек но пошол по пути "А щас я спрощу какую нибудь херню и понаблюдаю."
Про сборка/деплой я писал раньше. Даже вроде бы тебе.
C>>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд. S>>А докер это тупой chroot, да? C>Да. И благодаря этому он и гарантирует надёжность.
chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт.
C>>>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п. S>>Я с ансиблом тоже такое гарантировать могу. C>Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например.
А можно не забыть, например. Поэтому — смогу.
Здравствуйте, Vetal_ca, Вы писали:
S>>Ансиблом можно добиться стандартного окружения. Не только докером единым. V_>разные distro's?
Зачем себе в колёса пихать палки? Мсье мазохист?
Нахрена на своих серверах для своего проекта городить зоопарк? Или просто в голову больше ничего не приходит в защиту докеров?
S>>Песочница у вас, докер называется. V_>Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
Я этот шаг успешно прошёл и научился определять когда контейнеризация нужна, а когда — нет.
S>>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да. V_>Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
Никогда не поверю, что у вас в мануале нет "рекомендуется использовать дистрибутив Х", что читается техподдержкой как "а, вы на У, тогда ой". А раз так, то тогда и окружение будет нужным.
V_>Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере. V_>
V_>kubectl get certificate --all-namespaces -o json | jq --raw-output ".....
V_>Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Не нужно ничего выводить, нужно организовывать этот чек. Сразу. Нужен — сделали.
V_>- сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
Для ансибла не нужно спецзнаний. Нужен плейбук и обезьяна.
V_>- делается для всего кластера. Можно сделать для всех кластеров
Никаких проблем. Для всех кластеров сразу.
V_>- не зависит от внутреннего формата, документации и прочего
Абсолютно верно, не зависит.
V_>Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать. V_>А зависеть от местных наполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
Так не зависьте. Набор плейбуков, мануал про бутстрап деплой и список рекомендаций.
Здравствуйте, Farsight, Вы писали:
F>Есть такие чуваки... Если у бизнеса проблемы, нет роста, застой, их нанимают консультантами и они разруливают сложности. Дико дорого стоят. Не тем ты занят, Шеридан. Мог бы рубить бабло, решать интересные задачи... А ты ансибл теребонькаешь, людям с докером работать мешаешь.
Так случилось что я тепреть не могу человейники. А на удалёнку мало кто согласен.
S>>То есть работает только в тепличных условиях? F>Да, да! Работаем в изолированной среде, не заботясь о том, что там рядом у заказчика крутится, и не сломается ли что-нить, если мы какую-нить свою либу вкорячим на сервант. Да!
А вы не вкорячивайте старые либы а пользуйте те, которые в составе дистрибутива есть.
.
S>>То есть работает только в тепличных условиях? M>он работает в любых условиях. разворачивать его докером проще и дешевле чем любым другим способом.
Ну так если можно без докера, то зачем докер?
Здравствуйте, Cyberax, Вы писали:
V_>>>Стандартизация как Deployment так и runtime S>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей. C>Хватит бредить, а?
Действительно.
C>Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию.
Достаточно не выдавать нетестированный код в прод.
C>В случае с Docker/Kubernetes такая ситуация НЕВОЗМОЖНА в принципе. Код, который может быть ошибочен, специально изолирован и ограничен, так что последствия его отказа тоже будут ограничены и предсказуемы. И это принципиально правильный подход, вообще во всей инженерной науке.
А у вас отказ кода может привести к краху системы вообще? И докер для того чтобы система не ломалась? Как вам такое удаётся?
C>Я рекомендую почитать книги Сиднея Деккера (Sidney Dekker), особенно книгу "Behind Human Error". Или хотя бы: http://www.humanfactors.lth.se/fileadmin/lusa/Sidney_Dekker/books/DekkersFieldGuide.pdf C>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков.
Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей.
Здравствуйте, mogadanez, Вы писали:
S>>Ну так если можно без докера, то зачем докер? M>если можно без ансибла — зачем ансибл
Ну хотя бы потому что руками долго и сложно поддерживать единое окружение.
Здравствуйте, Sheridan, Вы писали:
S>А вы не вкорячивайте старые либы а пользуйте те, которые в составе дистрибутива есть.
Это либы для других приложений от других поставщиков, к коим мы не имеем отношения. Поэтому контенеризация и рулит.
Здравствуйте, Sheridan, Вы писали:
M>>если можно без ансибла — зачем ансибл S>Ну хотя бы потому что руками долго и сложно поддерживать единое окружение.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Как без контейнеров деплоить приложение на kubernetes? Никак. Если кубера нет, можно рассматривать варианты. Если принято решение использовать облако в виде контейнерного оркестратора, то других вариантов не остается.
Контейнер это действительно дополнительный уровень абстракции над программой. И как любая абстракция, она в общем случае помогает, а в отдельных начинает сковывать. Поэтому в каждом отдельном случае надо смотреть индивидуально.
Использовать докер без кубера — не совсем понятно зачем это нужно.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Vetal_ca, Вы писали:
S>Зачем себе в колёса пихать палки? Мсье мазохист? S>Нахрена на своих серверах для своего проекта городить зоопарк? Или просто в голову больше ничего не приходит в защиту докеров?
Я читаю, и начинаю подозревать, что ты прав: у тебя задачи такие, что на VB в Экселе запустить можно. Не нужен ни докер, ни Ансибл ни Шеридан
S>Я этот шаг успешно прошёл и научился определять когда контейнеризация нужна, а когда — нет.
Я такое уже видел. У начинающих. А ты, одновременно, и начинающий и уже все, "остановившийся в начинании".
S>Никогда не поверю, что у вас в мануале нет "рекомендуется использовать дистрибутив Х", что читается техподдержкой как "а, вы на У, тогда ой". А раз так, то тогда и окружение будет нужным.
Не надо верить, надо фокусироваться на насущном. А насущное тебе: еще учиться и пройти отбор. С таким же успехом можешь почитать инструкцию по одеванию скафандра для выхода в открытый космос
Ты даже смысл написанного осилить не можешь. Ближайший пример я видел, это африканцы, которые гайку на болт накрутить не могут. Для нас это интуитивно-понятно, а они никогда не держали в руках и не могут. Ну и советы дают, про другую гайку.
У вас даже на прием на работу чек плохой, дальше и говорить нечего
V_>>- сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе S>Для ансибла не нужно спецзнаний. Нужен плейбук и обезьяна.
Подумай, может и на Экселе можно?
V_>>- делается для всего кластера. Можно сделать для всех кластеров S>Никаких проблем. Для всех кластеров сразу.
Весело, включая и твою ошибочную команду, ибо Ansible позволяет записать, все что угодно. Или "задисциплинировали" розгами по рукам так, что гарантия 100% безошибочности?
V_>>- не зависит от внутреннего формата, документации и прочего S>Абсолютно верно, не зависит.
(C) Шериданю Учитывая, что тебя тут уделали ни раз и не два, как бог черепаху, то верность утверждения тут чуть выше чем у игральной кости.
S>Так не зависьте. Набор плейбуков, мануал про бутстрап деплой и список рекомендаций.
Видишь, в чем проблема отставания? В том, что советы твои вызывают только улыбку. Безо всяких кавычек, совершенно искреннюю улыбку, как от ребенка, дающим советы на уровне своего понимания. Только у ребенка есть потенциал.
