Здравствуйте, Явь-Истъ, Вы писали:

ЯИ>Использовать докер без кубера — не совсем понятно зачем это нужно.

Не освоили еще. Весьма распространенное явление, все многие всегда находятся в процессе обучения. Это нормально

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

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

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

C>>В случае с Docker/Kubernetes такая ситуация НЕВОЗМОЖНА в принципе. Код, который может быть ошибочен, специально изолирован и ограничен, так что последствия его отказа тоже будут ограничены и предсказуемы. И это принципиально правильный подход, вообще во всей инженерной науке.
S>А у вас отказ кода может привести к краху системы вообще? И докер для того чтобы система не ломалась? Как вам такое удаётся?
Отказ кода может привести к краху, да. Как и в любой системе. Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката.

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

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

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

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

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

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

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

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

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

Замечаем, что если файл /etc/letsencrypt/live/srv/cert.pem существует, то скрипт ничего не сделает.

В частности, такая ситуация возможна, если файл остался от предыдущей версии софта. Так как Ansible ничего сам не чистит, то при удалении playbook'а легко этот файл случайно оставить.

Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл.

Замечательный пример халтуры, да.

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

Выделяй-не выделяй, не добьешься нифига.

Вот слова Шеридана:

Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо

(ансибл потому что) руками долго и сложно поддерживать единое окружение.

И одновременно он топит против докера. Он даже это не способен понять, а ты ему что-то выделяешь.

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

S>Чем не устраивает systemd?

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

+ разработку можно вести на чём угодно.

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

Чтобы минимизировать последствия ошибок.

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

А где-то уже научились писать софт без багов?

S>А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".

"Разделяй и властвуй". Ошибка может быть связана:
— с инфраструктурой (место на диске закончилось, кто-то в секьюрити-прокси урл нужный не добавил). Если я разработчик, то это а) не моя головная боль, б) у меня всё равно прав нет.
— с кодом. Если я девопс — это не моя проблема.

Если же все ошибки сваливать в одну кучу, то очень быстро на них все перестанут обращать внимание.

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

Ансибл — это такой продвинутый bash.

S>Рекомендации будут типа "смени порт",

Такие вещи на уровне конфигурации, а не кода делаются. В случае с докером вообще параллельно какой там порт или путь, всё можно замапить одной строчкой в конфигурационном файле.

S>"перейди на такую версию библиотеки" и чтото в этом роде.

Варианты ответов на такое предложение:
— Это сторонний софт.
— С текущей версией всё протестировано.
— Времени тупо нет.

M>С единственной поправкой: Шеридан — это второй, с претензией на первый. Его оппоненты — весь спектр между первым и вторым и почти никогда — строго вторые. Более того, его оппоненты как совокупно так и по отдельности имеют в разы больше опыта. В том числе с теми же инструментами, о которых он высокопарно вещает.

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

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

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

И если выход за эти рамки вызывает неправильное функционирование — это и называется "баг на баге и багом погоняет".

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

SD>Если код у тебя красивый, оттестированный и безбажный, но работает только вот в этом контейнере, и только вот с этим железом, и только вот с такой версией ядра на хосте, где запущен этот контейнер, ну и еще версия докера не какая-нибудь, а X.Y.Z, то... это "works on my machine".
В случае с Докером единственная реальная зависимость, которую я видел — это наличие нужного ядра, если используются продвинутые функции (io_uring, например). Я могу представить теоретически, что софт зависит от каких-то AVX-инструкций, которые есть только на определённом железе, но такого в реальной жизни я не видел.

А вот в случае с неконтейнерным софтом — ошибки из-за версии glibc встречаются чуть менее, чем всегда.

M>В итоге там (почти) все выкинули нахрен, сделали централизованный сервис, где деплой и развертка делаются по клику одной кнопки (среди прочего. Его медленно кусками опенсорсят тут: https://backstage.io). И постепенно перетаскивают все в кубернетес и докер.

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

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

Кстати, вот тут не согласен.
Любой уровень абстракции (включая кубернетес) есть не более чем еще один уровень абстракции. Если можно избежать добавления уровней абстракции без существенного изменения операционных характеристик, то это обязательно следует сделать. Иными словами, кубернетес нужно вкрячивать только если он реально очень нужен! А не потому что "я научился с ним работать, теперь везде его запихаю".

C>В случае с Докером единственная реальная зависимость, которую я видел — это наличие нужного ядра, если используются продвинутые функции (io_uring, например). Я могу представить теоретически, что софт зависит от каких-то AVX-инструкций, которые есть только на определённом железе, но такого в реальной жизни я не видел.

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

А вообще я еще и другой фактор имел в виду. У меня немало практики работы с людьми разных уровней, и почти всегда те, кто полагаются на конкретную-версию-этой-либы-и-этого-образа попросту не умеют писать надежный софт. И совершенно не умеют его тестировать. Попытки объяснить, как вообще осуществлять тестирование, разбиваются о волну непонимания. Из серии "да как же это так, с чего вдруг мы тестирование случайными запросами называем умным словом property-based testing, да еще и так выходит, что тесты сложнее самого кода, который тестируется".
В общем, перфекционизм, он или есть, или его нет. Надо просто найти правильное применение — перфекционистов вниз к железу и ОС, а тех, кому побыстрее скопипастить со стек-оверфлоу, — на передовую софтовой разработки.
Главное понимать, куда кого применить, и не пытаться от профессора требовать говнокода, а от говнокодеров — чистки и уборки за собой. Первых — в университет, вторых — в Докеры.

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

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

Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?

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

Хотя, конечно, зависит от того, что называть "микросервисами". Повсеместно лепить какие-нибудь CustomerService, ProductService, OrderService, OrderItemService это наверное чересчур и создаёт больше проблем, чем решает. Но в то же время отделить, скажем, ProductReportingService от OrderProcessingService теоретически может иметь преимущества вроде описаных выше.

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

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

такие случаи бывают( и как правило это какие то проприетарные 3rd party библиотеки),
но это не необходимое условие для использования докера.
Докер вполне себя оправдывает и с нормальным, чистым кодом который на любой машине

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

АБ>Что можно сделать с докером, просто глянув мануал:
АБ>....<SKIP>....

Шеридан все это сделает на ансибле не глядя в мануал

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

SD>Любой уровень абстракции (включая кубернетес) есть не более чем еще один уровень абстракции. Если можно избежать добавления уровней абстракции без существенного изменения операционных характеристик, то это обязательно следует сделать. Иными словами, кубернетес нужно вкрячивать только если он реально очень нужен! А не потому что "я научился с ним работать, теперь везде его запихаю".

+1
если говорить про AWS, то на небольших и средних проектах вполне работает ECS

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

S>>А вы не вкорячивайте старые либы а пользуйте те, которые в составе дистрибутива есть.
F>Это либы для других приложений от других поставщиков, к коим мы не имеем отношения. Поэтому контенеризация и рулит.
Раз они предназначены другим приложениям, вам не нужны, то зачем вы их ставите?

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

S>>Достаточно не выдавать нетестированный код в прод.
M>Anything that СAN go wrong WILL go wrong
Спасибо, кэп.

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

S>>А можно не забыть, например. Поэтому — смогу.
M>но это увеличивает стоимость, как создания плейбуков так и их поддержки
А то создание образов и их поддержка не увеличивает стоимость. А там ещо окажется что и за хранение образов надо платить сферическому докерхабу.

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

S>>Зачем себе в колёса пихать палки? Мсье мазохист?
S>>Нахрена на своих серверах для своего проекта городить зоопарк? Или просто в голову больше ничего не приходит в защиту докеров?
V_>Я читаю, и начинаю подозревать, что ты прав: у тебя задачи такие, что на VB в Экселе запустить можно. Не нужен ни докер, ни Ансибл ни Шеридан
То что ты не умеешь читать я уже давно понял.


S>>Я этот шаг успешно прошёл и научился определять когда контейнеризация нужна, а когда — нет.
V_>Я такое уже видел. У начинающих. А ты, одновременно, и начинающий и уже все, "остановившийся в начинании".
Начинающий это ты. Стадию докера так и не прошол, остановился в ней.


S>>Никогда не поверю, что у вас в мануале нет "рекомендуется использовать дистрибутив Х", что читается техподдержкой как "а, вы на У, тогда ой". А раз так, то тогда и окружение будет нужным.
V_>Не надо верить, надо фокусироваться на насущном. А насущное тебе: еще учиться и пройти отбор. С таким же успехом можешь почитать инструкцию по одеванию скафандра для выхода в открытый космос
Ну то есть я прав — у вас есть "рекомендации" и шаг в сторону от них будет означать отказ в техподдержке. То есть даже докеры не помогают. Софт работает вообще отвратно.


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


S>>Не нужно ничего выводить, нужно организовывать этот чек. Сразу. Нужен — сделали.
V_>У вас даже на прием на работу чек плохой, дальше и говорить нечего
Да уж получше чем у вас, это очевидно.


V_>>>- сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
S>>Для ансибла не нужно спецзнаний. Нужен плейбук и обезьяна.
V_>Подумай, может и на Экселе можно?
Завидно, что не нужно специальных знаний, да?


V_>>>- делается для всего кластера. Можно сделать для всех кластеров
S>>Никаких проблем. Для всех кластеров сразу.
V_>Весело, включая и твою ошибочную команду, ибо Ansible позволяет записать, все что угодно. Или "задисциплинировали" розгами по рукам так, что гарантия 100% безошибочности?
Обидно что годные специалисты работают не с тобой, да?


V_>>>- не зависит от внутреннего формата, документации и прочего
S>>Абсолютно верно, не зависит.
V_>(C) Шериданю Учитывая, что тебя тут уделали ни раз и не два, как бог черепаху, то верность утверждения тут чуть выше чем у игральной кости.
Вера, она такая, совершенно иррациональна.


S>>Так не зависьте. Набор плейбуков, мануал про бутстрап деплой и список рекомендаций.
V_>Видишь, в чем проблема отставания? В том, что советы твои вызывают только улыбку. Безо всяких кавычек, совершенно искреннюю улыбку, как от ребенка, дающим советы на уровне своего понимания. Только у ребенка есть потенциал.
Ну то есть вы пишете такой негодный софт, что даже для его деплоя нужно обучать специаличтов? Мде... Ну сочувствую, чо.