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

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

V_>1. Стандартизация, единая по всему миру, кроме некоторых маргиналов:

V_>- единый "интерфейс" внутри, для приложения (docker image)

V_>- единый интерфейс снаружи, Docker/ContainerD
V_>- единый подход к daemonization (Pid 0)

Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую?
Чем не устраивает systemd?

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

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

V_>2. Инкапсуляция\изоляция, гарантируемая фреймфорком.

Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?


V_>Docker разделяет сложность на 2 разных domain. Внутри контейнеров и снаружи. DevOp не нужно фокусироваться на особенностях/ошибках в целом. Ошибка локализуется или внутри blackbox (artifact/image/base OS) или снаружи (Orchestration)

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


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

Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".

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

С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.



Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде.
Если удобно разрабу в докере писать — да велкам, пусть пишет.
Matrix has you...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.