Здравствуйте, Cyberax, Вы писали:

C>Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа.
Опакетить при сборке проекта, устанавливать пакет при деплое. Ну, первое что в голову пришло.


C>>>Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию.
S>>Достаточно не выдавать нетестированный код в прод.
C>Тестирование никогда не находит всех ошибок. Пора бы знать уже.
Это должно как то противоречить моим словам или что? И почему у тебя "все ошибки" это именно "rm -fr /" или чтото типа этого?


S>>А у вас отказ кода может привести к краху системы вообще? И докер для того чтобы система не ломалась? Как вам такое удаётся?
C>Отказ кода может привести к краху, да. Как и в любой системе.
Нет. постгрес, мускуль, раббит, бинд, дхцпц и так далее умудряются писать как то так, что их крах не приводит к краху системы. А вы умудряетесь.


C>Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката.
С ансиблом такое тоже возможно.
Только вот на самом деле надо писать код так, чтобы он работал. Тогда и не придётся тратить время на танцы с обеспечением тепличных условий.


C>>>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков.
S>>Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей.
C>Мда. Выделил.
Да хоть три раза выдели — эта теория всё равно не начнёт согласовываться с практикой.

Здравствуйте, Cyberax, Вы писали:

C>>>Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать?
S>>Дядя, у тебя цель какая? Доказать что ансибл гавно или что? Вот этот глупый вопрос к чему ты принёс? Ты вроде не глупый человек но пошол по пути "А щас я спрощу какую нибудь херню и понаблюдаю."
S>>Про сборка/деплой я писал раньше. Даже вроде бы тебе.
C>Ну так как собирать-то будем?
программирование->сборка->тесты->деплой->эксплуатация
Догадайся сам — на каком этапе сборка.

C>>>>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд.
S>>>>А докер это тупой chroot, да?
C>>>Да. И благодаря этому он и гарантирует надёжность.
S>>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт.
C>Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё.
Нет, не будут они более предсказуемы. Хоть трижды возненавидь ансибл и возлюби докер.


S>>>>Я с ансиблом тоже такое гарантировать могу.
C>>>Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например.
S>>А можно не забыть, например. Поэтому — смогу.
C>Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать.
Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее.
Мне правда тебя этому ещё учить надо?

Здравствуйте, Cyberax, Вы писали:

C>Ооочень хороший пример работы кое-какеров, у которых цивилизация рухнет от первого дятла.
Оооочень хороший пример раздувания из мухи слона.

C>

C>- name: Check if certificate already exists.
C>  stat:
C>    path: /etc/letsencrypt/live/{{ item.servername}}/cert.pem
C>  register: letsencrypt_cert
C>  with_items: "{{ apache_vhosts }}"

C>- name: Generate new certificate if one doesn't exist.
C>  shell: "certbot certonly --standalone --noninteractive --agree-tos --email {{ certbot_admin_email }} -d {{ item.item.servername}}"
C>  with_items: "{{ letsencrypt_cert.results }}"
C>  when: item.stat.exists == False
C>

C>Замечаем, что если файл /etc/letsencrypt/live/srv/cert.pem существует, то скрипт ничего не сделает.
C>В частности, такая ситуация возможна, если файл остался от предыдущей версии софта. Так как Ansible ничего сам не чистит, то при удалении playbook'а легко этот файл случайно оставить.
C>Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл.
Надо другую проверку? Будет другая. Очевидно что автору этого достаточно. Потому что проще->понятнее->легче поддерживать.
Но ты конечно же будешь продолжать утверждать что ансибл говно.



C>Замечательный пример халтуры, да.
Халтура у тебя в коде, он без контейнеров работать не может.

Здравствуйте, User239, Вы писали:

U>Здравствуйте, gandjustas, Вы писали:

G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.

U>Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
А как насчет увелиения времени сборки если изменение затрагивает более одного компонента? Причем если мы делаем микросервисную архитектуру с начала, то мы платим за призрачную будущую выгоду прямо сейчас.

Здравствуйте, Андрей Бабошин, Вы писали:

S>>Чем не устраивает systemd?
АБ>Что можно сделать с докером, просто глянув мануал:
АБ> — выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе),
АБ> — получить горизонтальное скалирование,
АБ> — до кучи ещё балансировку нагрузки,
АБ> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть,
АБ> — мониторинг на примитивном уровне,
АБ> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека,
АБ> — healthcheck и перезапуск, если кто-то в лесу умер.
Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?


АБ>+ разработку можно вести на чём угодно.
А ансибл как то мешает этому?


V_>>>Стандартизация как Deployment так и runtime
S>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
АБ>Чтобы минимизировать последствия ошибок.
Последствия ошибок всегда одинаковы: гдето не работает кусок чегото.
Три базовых подхода: масштабирование, рестарт, починка ошибки.
Последнее относится в программированию. А первые две относятся к деплою и отлично решаются ансиблом.


V_>>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком.
S>>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
АБ>А где-то уже научились писать софт без багов?
Настолько чтобы не нужна была песочница? Да, подавляющее большинство программистов так делают.


S>>А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".
АБ>"Разделяй и властвуй". Ошибка может быть связана:
АБ> — с инфраструктурой (место на диске закончилось, кто-то в секьюрити-прокси урл нужный не добавил). Если я разработчик, то это а) не моя головная боль, б) у меня всё равно прав нет.
АБ> — с кодом. Если я девопс — это не моя проблема.
Это видно и без всяких докеров.
Докер для этого абсолютно не нужен.


АБ>Если же все ошибки сваливать в одну кучу, то очень быстро на них все перестанут обращать внимание.
А их не надо сваливать в кучу, правильно. Более того, нужно поднимать мониторинг и алерты на базовые "кончается место/сертификат/память/сахар в сахарнице".


V_>>>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется"
S>>Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".
АБ>Ансибл — это такой продвинутый bash.
докер — это такой продвинутый chroot.

S>>Рекомендации будут типа "смени порт",
АБ>Такие вещи на уровне конфигурации, а не кода делаются. В случае с докером вообще параллельно какой там порт или путь, всё можно замапить одной строчкой в конфигурационном файле.
Абсолютно верно. Если программер реализовал. Тут гдето пробегало что "докер нужен чтобы приложения другдругу не мешали порты поднимать".


S>>"перейди на такую версию библиотеки" и чтото в этом роде.
АБ>Варианты ответов на такое предложение:
АБ> — Это сторонний софт.
Что значит "сторонний"? Понтно что не ваш. Чей, откуда взялся?

АБ> — С текущей версией всё протестировано.
Достаточно глупая отмазка. Так можно дойти и до "дальше разрабатывать не надо, текущая версия протестирована" и поувольнять программистов.

АБ> — Времени тупо нет.
Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"

SD>Мне сие неизвестно. Я лишь вижу что один хочет от девелоперов, чтобы те сами за собой чистили,

Вот девелоперы и выбирают инструменты которые позволяют им гарантированно убрать за собой А Шеридан несет чушь (включая пургу типа «девопсы должны говорить программистам, что подчищать и какие версии библиотек использовать»).

SD>а второй говорит "нефиг им на это время тратить, пусть за них чистят докеры". Оба подхода имеют право на жизнь — в конце концов, сами эти докеры кто-то же должен писать, и за самим докером тоже кто-то должен же прибрать.

Да неужели? А ансибл, за который цепляется Шеридан, никто не должен писать?

Здравствуйте, Sheridan, Вы писали:

S>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?

Можно, вопрос сколько времени мне надо будет потратить, чтобы соорудить то же самое с помощью systemd+ansible.
А ещё у меня есть привычка уходить в отпуск и отключать телефон, т.е. мне надо будет не только сделать и описать, но и подготовить кого-то, кто в случае чего сможет дополнить и расширить, или починить.
Порог входа с докером существенно ниже.

АБ>>+ разработку можно вести на чём угодно.
S>А ансибл как то мешает этому?

У разработчиков могут быть маки, винда и какая-нибудь версия линукса. Ну так исторически сложилось.
Пересадить всех на одну версию ОС нельзя, потому что сейчас бюджета не это нет.
А целевая платформа — линукс конкретной версии.

Варианты:
— поставить докер и взять нужный базовый образ,
— поднять виртуалку и разобраться как запускать этот ansible. На винде он без WSL не работает.

V_>>>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком.
S>>>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
АБ>>А где-то уже научились писать софт без багов?
S>Настолько чтобы не нужна была песочница? Да, подавляющее большинство программистов так делают.

По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут...

S>докер — это такой продвинутый chroot.

Ну да.

S>Что значит "сторонний"? Понтно что не ваш. Чей, откуда взялся?

Купили, разработан другим отделом.

АБ>> — С текущей версией всё протестировано.
S>Достаточно глупая отмазка.

Нормальная отмазка. Разработчику нужно бизнес-требования имплементировать, а не с разными версиями очередной библиотеки сношаться.
Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка.

S>Так можно дойти и до "дальше разрабатывать не надо, текущая версия протестирована" и поувольнять программистов.

"Вы не поверите". В какой-то момент заказчик решает, что текущая версия его удовлетворяет и оставляет только поддержку.

АБ>> — Времени тупо нет.
S>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"

Угу, запланируйте, согласуйте бюджет, договоритесь с заказчиком, что в следующем спринте фич будет меньше, потому что девопсу надо библиотеку обновить.

Здравствуйте, Sheridan, Вы писали:

S>Раз они предназначены другим приложениям, вам не нужны, то зачем вы их ставите?
Мы их не ставим, их ставят другие поставщики. Совсем потерялся?

Здравствуйте, Андрей Бабошин, Вы писали:

АБ>Можно, вопрос сколько времени мне надо будет потратить, чтобы соорудить то же самое с помощью systemd+ansible.
Зависит от задачи. В среднем время сопоставимо.

АБ>А ещё у меня есть привычка уходить в отпуск и отключать телефон, т.е. мне надо будет не только сделать и описать, но и подготовить кого-то, кто в случае чего сможет дополнить и расширить, или починить.
Это валидно для чего угодно. Точно так же и с докером.

АБ>Порог входа с докером существенно ниже.
Я бы не сказад что ансибл сильно сложнее.

АБ>>>+ разработку можно вести на чём угодно.
S>>А ансибл как то мешает этому?
АБ>У разработчиков могут быть маки, винда и какая-нибудь версия линукса. Ну так исторически сложилось.
А, ты про разработку. Ну так для разработки докеры хороши, я сразу об этом написал

Автор: Sheridan
Дата: 07.05.20

АБ>>>А где-то уже научились писать софт без багов?
S>>Настолько чтобы не нужна была песочница? Да, подавляющее большинство программистов так делают.
АБ>По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут...
Ну ты сам понимаешь что сдавать софт работающий исключительно в песочнице — такое себе решение.


S>>Что значит "сторонний"? Понтно что не ваш. Чей, откуда взялся?
АБ>Купили, разработан другим отделом.
Купили бажный, не работающий софт?
Отдел не может перейти на свежую версию используемой либы?


АБ>>> — С текущей версией всё протестировано.
S>>Достаточно глупая отмазка.
АБ>Нормальная отмазка. Разработчику нужно бизнес-требования имплементировать, а не с разными версиями очередной библиотеки сношаться.
АБ>Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка.
А когда головняк относится к деплою, то "это не моя проблема, у меня всё работает!", я правильно понял?


S>>Так можно дойти и до "дальше разрабатывать не надо, текущая версия протестирована" и поувольнять программистов.
АБ>"Вы не поверите". В какой-то момент заказчик решает, что текущая версия его удовлетворяет и оставляет только поддержку.
LTS аббревиатура тебе о чом нибудь говорит?

АБ>>> — Времени тупо нет.
S>>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"
АБ>Угу, запланируйте, согласуйте бюджет, договоритесь с заказчиком, что в следующем спринте фич будет меньше, потому что девопсу надо библиотеку обновить.
Да. Иначе заказчик уйдёт к тому поставщику, у которого нет проблем поддерживать актуальность своего софта для того чтобы деплой был без головняка.
Или вы пользуетесь отсуствием конкуренции и считаете что в таком случае можно х..к, х..к и в продакшн.

Здравствуйте, Sheridan, Вы писали:

АБ>>Что можно сделать с докером, просто глянув мануал:
АБ>> — выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе),
АБ>> — получить горизонтальное скалирование,
АБ>> — до кучи ещё балансировку нагрузки,
АБ>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть,
АБ>> — мониторинг на примитивном уровне,
АБ>> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека,
АБ>> — healthcheck и перезапуск, если кто-то в лесу умер.
S>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?
Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки.

АБ>>+ разработку можно вести на чём угодно.
S>А ансибл как то мешает этому?
Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации.

АБ>>Ансибл — это такой продвинутый bash.
S>докер — это такой продвинутый chroot.
Ранее ты писал, что это просто chroot, а теперь вот продвинутый. Прогибаешься?

S>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"
Все таки ты не догоняешь, что такое девопс.

Здравствуйте, Farsight, Вы писали:

S>>Раз они предназначены другим приложениям, вам не нужны, то зачем вы их ставите?
F>Мы их не ставим, их ставят другие поставщики. Совсем потерялся?
Тогда это их головная боль. За всем миром все баги не вылечишь. Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.

Здравствуйте, Farsight, Вы писали:

АБ>>>Что можно сделать с докером, просто глянув мануал:
АБ>>> — выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе),
https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html

АБ>>> — получить горизонтальное скалирование,
АБ>>> — до кучи ещё балансировку нагрузки,
Зависит от приложения. В общем виде — нужно приложению дать такие настройки чтобы оно поняло что оно работает в кластере и нашло соседние ноды.
Ну или, если подходит, пользовать pacemaker/corosync, haproxy.


АБ>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть,
Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей.
Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис


АБ>>> — мониторинг на примитивном уровне,
Насколько примитивном? systemctl status подойдёт?


АБ>>> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека,
Разворачиваем ёлку, на хостах filebeat. В чом проблема?


АБ>>> — healthcheck
Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис.

АБ>>>и перезапуск, если кто-то в лесу умер.
Restart=on-failure в юнит-файле сервиса.

S>>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?
F>Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки.
Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например.


АБ>>>+ разработку можно вести на чём угодно.
S>>А ансибл как то мешает этому?
F>Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации.
Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится.


АБ>>>Ансибл — это такой продвинутый bash.
S>>докер — это такой продвинутый chroot.
F>Ранее ты писал, что это просто chroot, а теперь вот продвинутый. Прогибаешься?
Ранее мне писали что ансибл это просто баш. Следует понимать что вы прогнулись?


S>>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"
F>Все таки ты не догоняешь, что такое девопс.
Это ты не догоняешь что работать надо в команде и слушать что тебе говорят другие специалисты, а не "у меня всё работает!"

Здравствуйте, Sheridan, Вы писали:

S>Тогда это их головная боль. За всем миром все баги не вылечишь. Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.
Я не вижу проблем в тепличных условиях. Только пользу и удобство. Появится что-то удобнее, пойду туда.

Здравствуйте, SkyDance, Вы писали:

V_>>Не освоили еще. Весьма распространенное явление, все многие всегда находятся в процессе обучения. Это нормально
S>> А не потому что "я научился с ним работать, теперь везде его запихаю".

Выдумал аргумент, и думаешь, "сейчас его запихаю".


Если " А не потому что "я научился с ним работать, теперь везде его запихаю".

Для Шеридана "если" превращается в стейтмент.

А "если" я могу много привести.

Если у вас сбоит память, не стоит использовать Кубернетес
Если у вас нет сети, не стоит ...
Если вы гуманитарий ...
Если у вас нет компьютера ...


В общем, аргумент отклонен как не относящийся к делу.

S>Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.

Ладно. Покормлю тебя, потому что твои оппоненты не задают тебе очевидный вопрос. А зачем нужно вот это: «софт хотя бы заработал без тепличных условий.»? То есть понятно, зачем это нужно user-facing софту: приложениям, с которыми работают пользователи.

Зачем это нужно внутреннему софту, который разрабатывается для внутренних изначально тепличных требований (разрабатывается для определенной версии линукса, с определенными версиями библиотек, крупные изменения в окружении не требуются почти никогда, а обновления зависимостей происходят редко и обычно известны заранее)?

И чем плохи «тепличные условия», если ты сам говоришь, что «ансибл нужен, потому что руками долго и сложно поддерживать единое окружение». Чем «единое окружение» не тепличные условия?

Здравствуйте, SkyDance, Вы писали:

M>>Если у меня красивый оттестированый и безбажный код — это не значит что я должен выкинуть докер.

SD>Если код у тебя красивый, оттестированный и безбажный, но работает только вот в этом контейнере, и только вот с этим железом, и только вот с такой версией ядра на хосте, где запущен этот контейнер, ну и еще версия докера не какая-нибудь, а X.Y.Z, то... это "works on my machine".
SD>И если выход за эти рамки вызывает неправильное функционирование — это и называется "баг на баге и багом погоняет".


Пришельцы, терроризирующие мирное население, тоже зло. Только, в природе не встречались.

Это, прежде чем развивать тезис, хотелось бы доказательство реальности проблемы. Тем паче, что проблема так детально описана, с привязкой к докеру, его версии и т.п.

Здравствуйте, Sheridan, Вы писали:


S>>>

Проскипано, ничего нового


S>>>И ты говоришь о надёжности? Не нужно выводить список. Нужен алерт на "сертификат закончится через Х часов" и реакция на алерт с получением и установкой сертификатов. Ручная или атоматическая — другой вопрос.
S>>>https://medium.com/@khandelwal12nidhi/automate-letsencrypt-ssl-installation-with-ansible-for-multiple-domains-8453f2c3212d
V_>>Ты даже смысл написанного осилить не можешь. Ближайший пример я видел, это африканцы, которые гайку на болт накрутить не могут. Для нас это интуитивно-понятно, а они никогда не держали в руках и не могут. Ну и советы дают, про другую гайку.
S>Повторю твои же слова: ты даже смысл написанного осилить не можешь.

Причина Query

А ты зачем-то привел пример своего "и так сойдет" подхода.

Здравствуйте, Sheridan, Вы писали:

S>Ну или, если подходит, пользовать pacemaker/corosync, haproxy.

Т.е. вместо того, чтобы сказать "replicas: xxx", мне надо:
— запустить эти xxx процессов,
— каждому подсунуть свою конфигурацию из-за портов, если на одной машине
— настроить haproxy
— как-то их разбросать по разным серверам.

АБ>>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть,
S>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей.
S>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис

Т.е. предлагается ещё и самому управлять vlan'ами.

АБ>>>> — healthcheck
S>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис.

Вот, писать отдельный ватчдог-сервис.
В случае же с предметом обсуждения добавление healthcheck'а выливается в добавлении пары конфигруационных параметров.

АБ>>Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка.
S>А когда головняк относится к деплою, то "это не моя проблема, у меня всё работает!", я правильно понял?

Вот с этого момента подробнее, пожалуйста.
Команда разработчиков выбрала версию X некой библиотеки.
В какой-то момент приходит девопс и говорит, что надо обновится до версии X + 1.
В данном случае это проблема девопса обосновать необходимость обновления и согласовать дополнительные сроки.
Понятно, что в чудесном мире с розовыми понями обновление библиотеки должно пройти безболезненно и, может даже, с некоторым удовольствием,
только на практике окажется, что с большой долей вероятности обновление потянет за собой какие-то исправления.

АБ>>>>+ разработку можно вести на чём угодно.
S>>>А ансибл как то мешает этому?
F>>Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации.
S>Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится.

Софт работает у разработчика, софт работает на тестовом стенде, а на проде "вдруг" перестаёт работать, потому что версии библиотек не те.

АБ>>По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут...
S>Ну ты сам понимаешь что сдавать софт работающий исключительно в песочнице — такое себе решение.

Песочница выражатеся в том, что даёт гарантированное окружение.
Касаемо про "без багов": всего навсего вопросов выделенных временных и денежных ресурсов.
Если заказчик готов ждать новую версию не две недели, а два месяца (с тем же набором фич), и готов за это платить, то багов будет меньше.
Если готов ждать два года, то багов не будет. или почти не будет.

П.С. Я выделил жирным про единое окружение.
С докером софту абсолютно неважно, где запускаться: на машине ли разрабочика, на внутреннем ли тестовом стенде, в кластере у заказчика или в том же амазоне.
Разработчик может жёстко прописать версии библиотек, с которыми всё точно работает, а не надеятся, что на целевом сервере будет нужная версия. Или не будет, потому что кто-то её обновил.
Т.е. стандартизация и унификация, без необходимости настраивать окружение.
Плюс большое количество вещей уже из коробки, без необходимости погружаться в детали: т.е. низкий порог входа.

Я не говорю, что ansible+systemd далее по списку — это плохо и тьфу-тьфу, но порог входа, последствия ошибок как-то сильно не в его пользу.

Здравствуйте, gandjustas, Вы писали:

U>>Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
G>А как насчет увелиения времени сборки если изменение затрагивает более одного компонента? Причем если мы делаем микросервисную архитектуру с начала, то мы платим за призрачную будущую выгоду прямо сейчас.

Сборку разных компонентов можно запустить параллельно (понятно, конечно, что параллельная сборка одного большого компонента тоже возможна, но это не всегда и не так просто).

G>Причем если мы делаем микросервисную архитектуру с начала, то мы платим за призрачную будущую выгоду прямо сейчас.

В этом согласен. Тут можно провести аналогию с рефакторингом кода. Вместо того чтобы пытаться строить "идеальную" архитектуру, лучше сделать как проще и быстрее и, когда необходимость назреет (из-за слишком долгой сборки или других требований), провести "рефакторинг" архитектуры.

Здравствуйте, Sheridan, Вы писали:

S>А то создание образов и их поддержка не увеличивает стоимость.

сложность имеджа при прочих равных будет ниже

S>А там ещо окажется что и за хранение образов надо платить сферическому докерхабу.

репозиторий можно иметь свой. вот ты говоришь что пользовался докером — но по тому что ты про него пишешь — не похоже