Re[22]: Киллер-фичи докера
От: Sheridan Россия  
Дата: 15.05.20 15:54
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V_>Набери в гугле "systemd vs" и читай ниже, стандартизация:

Ансиблом можно добиться стандартного окружения. Не только докером единым.


V_>>>Стандартизация как Deployment так и runtime

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


V_>Вне контейнеров/компонентов есть еще очень большой мир, не видимый из твоей песочницы. Чтобы ухватить внимание знающих людей, тебе придется это подтянуть. Не хочешь подтягивать — игнор/кризис/голод и прочие стимуляторы тебе в помощь. В мире миллиарды людей которые не саморазвиваются. Они никому не интересны, кроме как для своих мамы/папы и, в очень малой степени, местным органам власти. Почему ты должен быть исключением?

Песочница у вас, докер называется.


V_>Дихотомия. Быстро определить, где ошибка и отдать человеку соответствующей квалификации, направления и ответственности. Чтобы не забивать гвозди микроскопом, каждый раз привлекая дорогостоящего специалиста или team meeting, охватывая весь диапазон для мозгового штурма. Это как вместо механика, каждый раз машину на завод отправлять, главному инженеру, если error domain — это вся машина в целом

А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.


V_>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.

Это и есть гарантия работы компонента.


V_>>>4. Единообразие environment для компонента, задаваемое создателем Image

S>>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
V_>Про стандартизацию уже было — подтянешь, поговорим.
Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?


S>>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде.

S>>Если удобно разрабу в докере писать — да велкам, пусть пишет.


V_>Про версии библиотеки знает разработчик и/или создатель Docker Image. Читай, натренированный девелопер. DevOps/SecOps ревьювит для соответствия best practices/security standards. Маппинг портов/интерфейсов легко разруливается на уровне DevOps, для этого не нужно лезть внутрь ini/conf файлов компонентов

Ну то есть по твоему мнению девапс это такой раб, который обязан слушаться программеров иначе розги? Они должны в команде работать. Девапс выступает вдобавок ко всему еще и связующим звеном. Говорит одной команде например что другие уже перешли на новую версию либы и надо бы тоже подтянуться.
И выучи понятия "например", "чтото типа", "в этом роде". А то воспринимаешь всё буквально...
Matrix has you...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.