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

S>Довольно много документации на тему контейнеров в Azure Service Fabric (микросервисная архитектура), но от меня ускользают конкретные примеры того, где они лучше, чем просто сервисы.
S>Пока единственное четкое различие какое я нашел — это управление ресурсами, т.е. контейнеру я могу указать сколько именно ресурсов он может потребить, а обычному сервису такие установки недоступны.
Откровенно говоря, я тоже не до конца понимаю, почему так усиленно хватаются за контейнеры.

S>В документации упор делается на "самодостаточность" контейнеров, типа он имеет все необходимые файлы и зависимости. Кто-нибудь может преивести конкретный пример, где это-бы имело значение в сравнении с сервисами? Какие-такие зависимости могут поломаться при деплойменте сервиса без контейнера в Service Fabric?
S>Существуют-ли еще какие-то плюсы?
Из обсуждений с коллегами и чтения разных источников я для себя вынес следующее:
1. Упрощение развертывания сервисов в разнородной среде (это про самодостаточность). Т.е. если у вас для всех сервисов требуется одно и то же окружение (одна версия фреймворка, один набор установленных системных и third-party продуктов, ...), то для вас этот пункт не актуален.
А вот зато когда для части сервисов нужно одно, для другой — немного отличное, для третьей — вообще что-то свое... вот тогда контейнеры позволят вам на одной машине развернуть любые сервисы — каждый со своим окружением.

2. Идентичность сред (тоже про самодостаточность). Т.е. как минимум в теории (а коллеги говорят, что у них эта схема вполне работает на практике) вы используете одни и те же образы на Dev-, Test-, Stage-, Prod-, ... окружениях. И у вас уже нет проблемы, что окружение на Prod и на Test — разное. И как следствие принцип "у меня на машине всё работает" легко переносится на все остальные стенды.

3. Дополнительный уровень изоляции. Вот тут я пишу вообще голую теории, потому что не вдавался в подробности. Но суть в том, что если злоумышленник через некий бэкдор в вашем коде, смог, например, внедрить на машину, где развернут сервис свой исполнимый код и запустить его, то в случае контейнера он всё равно окажется в изолированном окружении и навредить сможет только одному экземпляру сервиса. Остальные продолжат работать, как и работали.

4. Отдельный, специфичный для Docker момент (у других систем это не обязательно будет, хотя какие есть системы контейнеризации кроме Docker сейчас, я не знаю) — образы создаются на базе других образов. Т.е. можно иметь целое "дерево" образов с общим "корнем" — это тоже заметно упрощает поддержку идентичности

Другое дело, что и минус на текущий момент хватает.
1. Контейнер жрет заметно больше ресурсов, чем обычный процесс. Причем, в процессе эксплуатации начинают всплывать, например, такие моменты: чем длиннее цепочка образов на базе которой создан текущий запущенный экземпляр, тем больше накладных расходов. Я сам не проверял, но коллеги говорят, что если взамен цепочки из нескольких образов сделать один образ (одной операцией compose), то разница в потреблении будет заметна просто на глаз. А это значит, больше число запущенных экземпляров на 1 физическую машину.
2. У Windows контейнеров (я имею в виду Docker for Windows, то что говорят о неких не-Docker контейнерах в Windows — увы, я не нашел никакой толком информации о них. Такое ощущение, что публичного API для них просто нет) есть куча проблем, которые, я надеюсь, есть следствие их относительной молодости. Например, я так и не смог добиться нормального "проброса сети" из контейнера в хостовую ОС. Т.е. не меняя настройки просто запускаю/останавливаю экземпляры контейнера — связь с приложением в контейнере, то есть, то нету. Причем никакой вразумительной диагностики тоже нет...
Я искренне полагал, что это лично мое неумение, но опять же поговорив с коллегами, узнал, ситуация считается чуть ли не нормой (причем, как я понял она не связана с Windows только). И считается вполне себе решением поднять экземпляр контейнера, проверить, что связи нет, грохнуть и поднять заново...