Pull to refresh

Comments 6

А зачем указывать image в compose файле, если дальше идёт build и происходит сборка контейнера?

Это фича docker-compose. Позволяет pull-ить образы, указанные в image, если вам не хочется собирать самому через команду docker-compose pull. Полезно для фронтендеров, которым нужно просто запустить последний рабочий билд бэкенда. Бэкендер делает docker-compose build.

У меня только один вопрос — pачем Net Core запихивать в докер? Чисто дань моде? Реальный профит от Docker вижу только в мертвых проектах, которые никто дальше поддерживать не планирует, но надо чтобы они работали и дальше. В остальном от Docker одни минусы.

— Docker полезен исключительно для воссоздания кривых окружений кривых программ (непременно stateless)
— В подавляющем большинстве случаев люди пытаются внедрением Docker компенсировать изначально кривую архитектуру своих приложений. Когда это не помогает начинаются разговоры о том, что Kubernetes поможет решить проблемы, но это приводит лишь к новым сложностям
— Docker вводит лишний уровень абстракции, зачастую там где она не нужна
— Содержимое Docker контейнера крайне плохо поддается аудиту
— Docker крайне не прост в настройке и поддержке. Большинство людей которые все же используют докер редко уходят дальше «Just use the docker image»
— Корректная настройка Docker требует найма дополнительного персонала с очень специфическими навыками. Уметь правильно настраивать сеть != уметь правильно настраивать сеть в Docker
— Docker никогда не бывает один и тянет за собой огромную экосистему. Этим он похож на NodeJS, когда очень скоро оказывается, что ваше Hello World приложение зависит от 300 разных библиотек и плагинов.
Вы просто не умеете его готовить. В разработке это мега удобно. Если весь сервис состоит из одного приложения и nginx, то профита наверное не много. Но вот когда сервис состоит из десятка приложений, то докер очень сильно помогает. Можно упаковать все приложения вместе с настройками в контейнеры, написать скрипт, который всё это поднимает и запускать на своем компе. Некоторые разработчики под каждую задачу поднимают новый сервис с нуля, благо это делается одной командой. Далее гитлаб CI — при пуше приложение собирается в контейнеры, поднимается весь сервис из собранных контейнеров и тестируется. После всех действий остаются артефакты, если нужно разобраться в каких-то проблемах, то можно всё это добро поднять прямо на своей тачке. У контейнеров свои имена, благодаря этому каждый контейнер кажется отдельным компьютером и можно поднимать просто кучу сервисов на своем компе, например моделируя горизонтальное масштабирование. Установленные обычном способом приложения часто распиханы по разным каталогам и оставляют свои следы везде где только можно. Докер это проблему решает элегантно — приложение гадит только в примонтированные папки. Благодаря этому можно весь свой локальный сервис забэкапить буквально копированием и поднять в случае чего на другой тачке за считанные минуты.
У меня другой вопрос зачем в контейнере nginx?
Почему его не расположить на системном уровне пусть себе обслуживает сайт с 10 контейнеров.
Базовые образы уже давно поменялись:
для сборки: microsoft/dotnet:2.2-sdk
для публикации: microsoft/dotnet:2.2-aspnetcore-runtime
и минимальные образы: microsoft/dotnet:2.2-aspnetcore-runtime-alpine
И уже в альфе 3.0 версия которая будет запускаться исключительно на netcoreapp 3.0.
Sign up to leave a comment.