SD>А вообще я еще и другой фактор имел в виду. У меня немало практики работы с людьми разных уровней, и почти всегда те, кто полагаются на конкретную-версию-этой-либы-и-этого-образа попросту не умеют писать надежный софт. И совершенно не умеют его тестировать. Попытки объяснить, как вообще осуществлять тестирование, разбиваются о волну непонимания. Из серии "да как же это так, с чего вдруг мы тестирование случайными запросами называем умным словом property-based testing, да еще и так выходит, что тесты сложнее самого кода, который тестируется".
часто проблемы с версиям бывают из-за third-party библиотек/софта котырые не обновлялись хрен знает сколько или апргрейд стоит кучу денег которые бизнес сейчас не хочет тратить.
Здравствуйте, mogadanez, Вы писали:
S>>А там ещо окажется что и за хранение образов надо платить сферическому докерхабу. M>репозиторий можно иметь свой. вот ты говоришь что пользовался докером — но по тому что ты про него пишешь — не похоже
Я ещё дополню, что докер образы по слоям хранит. Если базовый образ не менять, то накладные расходы пренбрежимо малы.
Здравствуйте, Sheridan, Вы писали:
S>Но ты конечно же будешь продолжать утверждать что ансибл говно.
вообще тебе все говорят что ансибл имеет право на жизнь в каких то сценариях, но докер для нас проще и надежне и мы выбираем его
твоя же позиция совсем ортодоксальна
Здравствуйте, Sheridan, Вы писали:
C>>Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа. S>Опакетить при сборке проекта, устанавливать пакет при деплое. Ну, первое что в голову пришло.
Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
Затем ещё несколько итеративных шагов — и получается Docker.
S>>>Достаточно не выдавать нетестированный код в прод. C>>Тестирование никогда не находит всех ошибок. Пора бы знать уже. S>Это должно как то противоречить моим словам или что? И почему у тебя "все ошибки" это именно "rm -fr /" или чтото типа этого?
Да. Если надеяться только на тестирование, то система работать не будет.
C>>Отказ кода может привести к краху, да. Как и в любой системе. S>Нет. постгрес, мускуль, раббит, бинд, дхцпц и так далее умудряются писать как то так, что их крах не приводит к краху системы. А вы умудряетесь.
О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh. В RabbitMQ я тоже сам находил и патчил ошибки (с пропадающими сообщениями).
Так что нет, НИКТО не может писать надёжный софт. Совсем.
C>>Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката. S>С ансиблом такое тоже возможно.
Нет, как я уже показал.
S>Только вот на самом деле надо писать код так, чтобы он работал. Тогда и не придётся тратить время на танцы с обеспечением тепличных условий.
Я уже показал, что никакой Ansible код не может быть надёжным.
C>>>>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков. S>>>Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей. C>>Мда. Выделил. S>Да хоть три раза выдели — эта теория всё равно не начнёт согласовываться с практикой.
Мда. Книжку скачай и прочитай.
Здравствуйте, Sheridan, Вы писали:
S>>>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт. C>>Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё. S>Нет, не будут они более предсказуемы. Хоть трижды возненавидь ансибл и возлюби докер.
Ты уже сам привёл пример скрипта, который даст непредсказуемую ошибку.
C>>Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать. S>Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее.
Нет, такие ошибки не отлавливаются тестами.
Здравствуйте, Sheridan, Вы писали:
C>>Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл. S>Надо другую проверку? Будет другая. Очевидно что автору этого достаточно. Потому что проще->понятнее->легче поддерживать.
Нет, не будет. Так как админ Sheridan просто берёт первые попавшиеся playbook'и и фигачит в production. То что там в одном из кусочков есть такая мина — админ Sheridan даже не узнает, до тех пор, пока мина не взорвётся.
S>Но ты конечно же будешь продолжать утверждать что ансибл говно.
Да, это именно так.
Здравствуйте, Sheridan, Вы писали:
АБ>>>> — получить горизонтальное скалирование, АБ>>>> — до кучи ещё балансировку нагрузки, S>Зависит от приложения. В общем виде — нужно приложению дать такие настройки чтобы оно поняло что оно работает в кластере и нашло соседние ноды. S>Ну или, если подходит, пользовать pacemaker/corosync, haproxy. АБ>>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, S>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис АБ>>>> — мониторинг на примитивном уровне, S>Насколько примитивном? systemctl status подойдёт? АБ>>>> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека, S>Разворачиваем ёлку, на хостах filebeat. В чом проблема? АБ>>>> — healthcheck S>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис. АБ>>>>и перезапуск, если кто-то в лесу умер. S>Restart=on-failure в юнит-файле сервиса. S>>>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле? F>>Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки.
В соседнем сообщении комрад все расписал. Я только еще зачему, что надо еще и ELK разворачивать куда-то.
В общем и целом это выглядит куда как сложнее, чем это можно было бы провернуть с докером и кубером.
S>Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например.
Я написал докер + кубер. Ну или сварм на худой конец.
S>Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится.
Докер как раз и снимает этот вопрос.
S>Ранее мне писали что ансибл это просто баш. Следует понимать что вы прогнулись?
Я нет, мне фиолетово что ансибл — запускалка, а докер — чрут. Инструмент помогает решать задачи и не делает мозг (за редким исключением).
S>Это ты не догоняешь что работать надо в команде и слушать что тебе говорят другие специалисты, а не "у меня всё работает!"
Это мне рассказывает человек, никогда не работавший в команде на разработке. Еще раз для сферического админа в вакууме — докер как раз позволяет решить эту проблему.
S>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис
Tckb допустить, что Шеридан может как в Кубернетес, то получим тот же network plugin
1. Осталось доказать, что он это сможет.
2. найти дурака, который это действо будет спонсировать
S>Насколько примитивном? systemctl status подойдёт?
Нет
АБ>>>> — healthcheck S>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис.
И фреймворк для запуска этого сервиса, документацию, стандарт. Вместо того что есть, да это хромой лошади дать. Зачем? Работают целые коллективы над такими системами, а тут некий Шеридан это на коленке слабает.
S>Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например.
Persistent state сервисы "из коробки" скалирование в горизонт "изкаробки" не умеют нигде, ни в ансибл, ни в докер ни в кубернетес. Даже сам вопрос показывает неграмотность.
Всегда нужно что-то еще, что поддерживает data mapping для data partitioning/sharding.
Это уже ваши личные споры и проблемы.
Тогда как суть моего утверждения очень проста: если можно избежать лишнего слоя абстракции, его *нужно* избежать, иначе последующие поиски бага и разборки "ну как же так, нас же докер должен был изолировать" затянуться еще на неделю, а то и больше.
Видишь ли, в моей практике хватает случаев, когда через ....дцать уровней абстракции я обнаруживал root cause в железке (материнке, и BIOS, их комбинации, когда level-triggered прерывание обрабатывалось как edge-triggered, а приводило это к внезапному увеличению latency для определенных типов запросов — через примерно десяток разных виртуальых машин, начиная от kernel, и заканчивая home-brew наворотами поверх еще нескольких виртуальных машин, среди которых, однако, был и аналог docker'а, только с чуть иным названием).
V_>Это, прежде чем развивать тезис, хотелось бы доказательство реальности проблемы. Тем паче, что проблема так детально описана, с привязкой к докеру, его версии и т.п.
Реальность проблемы такова: разработчик, который привык к "тепличным условиям", целиком и полностью зависит от тех, кто оные условия создает. Шаг влево, шаг вправо, и этот "тепличный разработчик" из себя представляет вредителя, на которого должна работать еще целая команда. Вот такой бизнес, увы.
C>О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh.
Это пример катастрофического головотяпства. Даже в моей совершенно нелепой практике подобных дел про KVM over IP я прочитал _перед_ тем, как что-то ставить в датацентр в Мельбурне (откуда из Сиднея лететь пусть и недолго, но все же).
Здравствуйте, Anton Batenev, Вы писали:
AB>Для разработки ресурсоемкость решения не особо принципиальна будь то docker, virtual box, kvm, chroot (и все остальное, что могут использовать для изоляции). Для прода, где нужна стабильность и прочие аттрибуты "зрелости" (а не хипстерское "упало, да и фиг с ним — облако новых нарожает") докер непригоден (но не из за оверхеда конечно же).
А из-за чего непригоден? Что там не так со стабильностью?
Здравствуйте, Sheridan, Вы писали:
G>>Установка сложного приложения без докера выглядит так: ... G>>Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик. S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
Представим что мы деплоим то самое приложение на nodejs, нам нужен npm, нам нужны пакеты из разных deb репозиториев чтобы установить монгу и прочую хурму, также нам нужны наши пакеты, которые берутся из нашей инфраструктуры, получается что твой деплой зависит от кучи разных endpoint-ов, часть которых ты не контроллируешь. Захочет npm попятисотить немного и часть твоего приложения не развернется. Получается, что нужно держать свой npm, свой deb репозиторий и тд. Вместо всего этого можно было бы поддерживать artifactory в котором бы лежали все твои docker images. Тупо дешевле и проще.
Еще один момент — cloud nativeness. Деплой ansible плейбуком это хорошо, но не cloud native. Мы сейчас хотим чтобы все было завязано на CI. Мы хотим непрерывный деплой и относительную независимость от клауд провайдера. Это достижимо только за счет автоматизации и непрерывной интеграции. Ты же не будешь каждый раз расчехлять свой плейбук, когда появится CVE с описанием уязвимости в какой-нибудь библиотеке, от которой зависит твое приложение. А CI проследит в том числе за CVE зависимостей и перестроит образы, в том числе.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
C>>>Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл. S>>Надо другую проверку? Будет другая. Очевидно что автору этого достаточно. Потому что проще->понятнее->легче поддерживать. C>Нет, не будет. Так как админ Sheridan просто берёт первые попавшиеся playbook'и и фигачит в production. То что там в одном из кусочков есть такая мина — админ Sheridan даже не узнает, до тех пор, пока мина не взорвётся.
причем даже если он протестирует это на своем pre-production, то все может вполне нормально отработать, но долбануть потом на проде
Здравствуйте, Андрей Бабошин, Вы писали:
S>>Ну или, если подходит, пользовать pacemaker/corosync, haproxy. АБ>Т.е. вместо того, чтобы сказать "replicas: xxx", мне надо: АБ> — запустить эти xxx процессов, АБ> — каждому подсунуть свою конфигурацию из-за портов, если на одной машине АБ> — настроить haproxy АБ> — как-то их разбросать по разным серверам.
Ну да, ну да. Внутри replicas живёт магия, которая сделает ваши процессы скалабельными. Ну или ваши процессы очень легко скалятся и поэтому трудностей никаких не будет и без докеров.
АБ>>>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, S>>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис АБ>Т.е. предлагается ещё и самому управлять vlan'ами.
Обязательно вланами? Вообще, для чего это? Если приложение работает без хитрых прижков по сетям, то зачем тогда они? Стоит ли в этот огород тащить ещо одну шестеренку, которая перестанет крутиться? Может достаточно просто огнестену нормально настроить?
АБ>>>>> — healthcheck S>>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис. АБ>Вот, писать отдельный ватчдог-сервис. АБ>В случае же с предметом обсуждения добавление healthcheck'а выливается в добавлении пары конфигруационных параметров.
И внутри этих конфигурационных параметров тоже магия, которая сама знает когда считать процесс нежитью?
АБ>>>Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка. S>>А когда головняк относится к деплою, то "это не моя проблема, у меня всё работает!", я правильно понял? АБ>Вот с этого момента подробнее, пожалуйста. АБ>Команда разработчиков выбрала версию X некой библиотеки.
Плохой шаг, негодный. Команда разработчиков при первом принятии либы в проект должна взять последний релиз этой либы. И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты).
АБ>В какой-то момент приходит девопс и говорит, что надо обновится до версии X + 1.
Да. Если программисты забыли.
АБ>В данном случае это проблема девопса обосновать необходимость обновления и согласовать дополнительные сроки.
Проблема девопса — добавить баг или таск с его обоснованием. А сроки — это дело программистов (им же программировать), равно как и обоснование этих сроков.
АБ>Понятно, что в чудесном мире с розовыми понями обновление библиотеки должно пройти безболезненно и, может даже, с некоторым удовольствием, АБ>только на практике окажется, что с большой долей вероятности обновление потянет за собой какие-то исправления.
Мне тут постоянно уши жужжат что я в команде не работал. Видимо эти люди сами не работали в командах, ибо там где я работал — дела обстояли +- как я описал сейчас.
И к тому же девапс отчегото воспринимается как лишнее колесо. Ну теперь я понимаю почему — он указывает как правило на проблемы проекта, которые а) "у нас и так работает" и б) лень этим заниматься. И всё это под соусом "бизнесу нинада".
Бизнесу нада. Надо годный код, который будет работать без лишних подпопрок.
АБ>>>>>+ разработку можно вести на чём угодно. S>>>>А ансибл как то мешает этому? F>>>Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации. S>>Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится. АБ>Софт работает у разработчика, софт работает на тестовом стенде, а на проде "вдруг" перестаёт работать, потому что версии библиотек не те.
ВНЕЗАПНО это как раз проблема программистов, которые вовремя не перешли на свежую версию либы.
АБ>>>По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут... S>>Ну ты сам понимаешь что сдавать софт работающий исключительно в песочнице — такое себе решение. АБ>Песочница выражатеся в том, что даёт гарантированное окружение.
Любой дистрибутив даёт гарантированное окружение.
АБ>Касаемо про "без багов": всего навсего вопросов выделенных временных и денежных ресурсов. АБ>Если заказчик готов ждать новую версию не две недели, а два месяца (с тем же набором фич), и готов за это платить, то багов будет меньше. АБ>Если готов ждать два года, то багов не будет. или почти не будет.
Верно. Почему вы тогда придерживаетесь поведения "поэтому совсем не будем за этим следить"?
АБ>П.С. Я выделил жирным про единое окружение. АБ>С докером софту абсолютно неважно, где запускаться: на машине ли разрабочика, на внутреннем ли тестовом стенде, в кластере у заказчика или в том же амазоне.
Это и плохо. Складывается ощущение, что всё хорошо, хотя на самом деле у проекта куча подпорок и без них он не работает никак.
АБ>Разработчик может жёстко прописать версии библиотек, с которыми всё точно работает, а не надеятся, что на целевом сервере будет нужная версия. Или не будет, потому что кто-то её обновил.
Плохой, разработчик. На нужную версию можно надеяться только когда эта версия свежая. На говоно мамонта надеяться нельзя.
АБ>Т.е. стандартизация и унификация, без необходимости настраивать окружение.
Если соблюдать простые правила то ничего настраивать не надо и в любом случае это проблема девапса и он её решать умеет.
АБ>Плюс большое количество вещей уже из коробки, без необходимости погружаться в детали: т.е. низкий порог входа.
Ничего себе низкий — изучить докеры с кубернетисами.
АБ>Я не говорю, что ansible+systemd далее по списку — это плохо и тьфу-тьфу, но порог входа, последствия ошибок как-то сильно не в его пользу.
Я так понимаю что основной камень преткновения это сторонние либы? Ну тогда я всё описал что с этим делать надо.
Здравствуйте, mogadanez, Вы писали:
S>>А то создание образов и их поддержка не увеличивает стоимость. M>сложность имеджа при прочих равных будет ниже
Нет. Она сопоставима с сложностью ансибла потому что нужно будет провернуть +- те же самые вещи. Магии не бывает.
S>>А там ещо окажется что и за хранение образов надо платить сферическому докерхабу. M>репозиторий можно иметь свой. вот ты говоришь что пользовался докером — но по тому что ты про него пишешь — не похоже
Можно и свой — я против что ли? У вас свой?
Здравствуйте, mogadanez, Вы писали:
M>вообще тебе все говорят что ансибл имеет право на жизнь в каких то сценариях, но докер для нас проще и надежне и мы выбираем его M>твоя же позиция совсем ортодоксальна
Не замечаю чегото. В основном говорят что я ничего не понимаю, потому что бизнес а докер, а ансибл, и вообще дурак.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
C>>>Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа. S>>Опакетить при сборке проекта, устанавливать пакет при деплое. Ну, первое что в голову пришло. C>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
Версий не несколько, а одна. Ставить не определённую, а свежую.
Такой сценарий настолько редок, что встречается один-два раза в жизни.
При правильном подходе к проектированию, программированию и планированию вам не придётся мнодить версии либ.
C>Затем ещё несколько итеративных шагов — и получается Docker.
Если для вас докер это инструмент для впулливания говна мамонта к проекту, то да.
S>>>>Достаточно не выдавать нетестированный код в прод. C>>>Тестирование никогда не находит всех ошибок. Пора бы знать уже. S>>Это должно как то противоречить моим словам или что? И почему у тебя "все ошибки" это именно "rm -fr /" или чтото типа этого? C>Да. Если надеяться только на тестирование, то система работать не будет.
А, у вас еще и тестирование никуда не годится? У вас то хоть тестер отдельный есть, ну хоть один? Или когото из программистов от работы отрываете?
C>>>Отказ кода может привести к краху, да. Как и в любой системе. S>>Нет. постгрес, мускуль, раббит, бинд, дхцпц и так далее умудряются писать как то так, что их крах не приводит к краху системы. А вы умудряетесь. C>О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh. В RabbitMQ я тоже сам находил и патчил ошибки (с пропадающими сообщениями).
Аааа, так у вас денег нет даже на нормальное железо с ilo/ipmi/etc...? И вы прямо на голом железе софт разворачиваете?
Мда. Это последствия отсутствия админа в команде. Ну и конечно докер магическим образом правит ошибки всего софта, который внутри. Сообщения перестают пропадать, да.
C>Так что нет, НИКТО не может писать надёжный софт. Совсем.
И поэтому надо сложить лапки и писать вилами по воде?
C>>>Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката. S>>С ансиблом такое тоже возможно. C>Нет, как я уже показал.
Ничего ты не показал.
S>>Только вот на самом деле надо писать код так, чтобы он работал. Тогда и не придётся тратить время на танцы с обеспечением тепличных условий. C>Я уже показал, что никакой Ansible код не может быть надёжным.
Я не удивлюсь что с вашим подходом к софтописанию и докер перестанет быть надёжным. Я уже почти готов поставить штутку баксов что у вас уже местами с докером возникают сложности и они пока решаются разделением бажного контейнера на два разных контейнера с выносом бажного функционала в более тепличные условия.
Здравствуйте, Cyberax, Вы писали:
S>>>>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт. C>>>Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё. S>>Нет, не будут они более предсказуемы. Хоть трижды возненавидь ансибл и возлюби докер. C>Ты уже сам привёл пример скрипта, который даст непредсказуемую ошибку.
Ты когда строку на печать выводишь — проверяешь наличие \0 в конце? Нет? Не нужно? Вот так и тут. Когда будет нужно — тогда будет и более строгая проверка.
C>>>Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать. S>>Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее. C>Нет, такие ошибки не отлавливаются тестами.
Такие ошибки замечательно отслеживаются тестами.
