Здравствуйте, 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. В таких беседах очень четко раскрывается притягательность фильмов про зомби. Зомби — медленные, неуклюжие. Но их много и они со своей медленностью и неуклюжестью идут съесть твой мозг.