Comments 10
В официальном репозитории есть пример Dockerfile в котором используется 2 образа первый это sdk для dotnet publish второй runtime для запуска приложения. Очень удобно когда не надо каждый раз запускать dotnet publish
Единственная проблема, с которой реально столкнулись — это то, что в документации, на момент деплоя не был освещён момент по поводу работы за обратным прокси (UseForwardedHeaders). Но на IIS всё волшебным образом работало. Почитали исходники модуля (слава MIT лицензии), который Kestrel с IIS интегрирует, там и нашли перенаправление заголовков. Единственное, нужно не забыть их перенаправление и в nginx'е настроить, и будет счастье))
Работаем без виртуализации. Полгода, полёт отличный.
Используем dotnet core практически с момента релиза. Примерно в тоже время, открыли для себя прелести докера, так что всё в нём.
Сейчас в проде — 4 веб приложения, несколько десятков консольных.
Проблем с деплоем не было, были «проблемы», связанные скорее со связкой dotnet core + linux:
Итого, у нас работа построена так:
1. Есть контейнер nginx, который выступает в качестве reverse-proxy.
2. Есть контейнеры с базами
3. Есть контейнеры с dotnet приложениями, внутри которых, кроме самого приложения, supervisor.
Объясню почему supervisor, а не вариант из репозитория — есть несколько контейнеров, внутри которых сидит не одно приложения. Обычно, это какие-то маленькие приложения, которые шлют письма или что-то подобное, для чего не хотелось бы создавать множество контейнеров.
Нюанс про docker-compose и локальную сеть между сервисами.
Если у вас много приложений и они все в разных compose-файлах, проще создать собственную сеть внутри docker. При работе с собственной сетью, все приложения, которые её используют, могут обратиться к любому другому приложению в этой сети по имени контейнера.
Сейчас в проде — 4 веб приложения, несколько десятков консольных.
Проблем с деплоем не было, были «проблемы», связанные скорее со связкой dotnet core + linux:
- сокеты dotnet core не умеют коннектиться по url'у в linux (проверено на debian 8, ubuntu 14+), исключительно по ip адресу
- довольно часто консольное приложение работает в роли некоторой службы, где запускается вечный(условно) цикл. Чтобы сразу же после запуска приложение не закрывалось что обычно делаем? Пишем что-то вроде Console.Read/ReadLine/ReadKey. Если наше приложение запускает supervisor, то работает только вариант с Console.Read.
Итого, у нас работа построена так:
1. Есть контейнер nginx, который выступает в качестве reverse-proxy.
2. Есть контейнеры с базами
3. Есть контейнеры с dotnet приложениями, внутри которых, кроме самого приложения, supervisor.
Объясню почему supervisor, а не вариант из репозитория — есть несколько контейнеров, внутри которых сидит не одно приложения. Обычно, это какие-то маленькие приложения, которые шлют письма или что-то подобное, для чего не хотелось бы создавать множество контейнеров.
Нюанс про docker-compose и локальную сеть между сервисами.
Если у вас много приложений и они все в разных compose-файлах, проще создать собственную сеть внутри docker. При работе с собственной сетью, все приложения, которые её используют, могут обратиться к любому другому приложению в этой сети по имени контейнера.
Помню, препод по матану тоже обожал употреблять слова «банально», «элементарно» и «интуитивно понятно» и исчеркивал доску формулами. До сих пор не могу вспомнить что тогда изучал.
А допустим такой странный запрос… если хочется разрабатывать из Visual Studio на Windows, а разместить контейнер нужно на Linux машине. Такое возможно?
Возможно несколько вариантов:
1. Вы можете делать publish на windows машине. В VS предусмотрено несколько вариантов, вплоть до создания готового dockerfile или копирования результатов publish на нужный вам ftp.
2. Можно настроить CI. Допустим, после прохождения тестов, у вас может создаваться новый контейнер, куда попадает исходный код (затем уже внутри делается publish), либо результаты publish, и сразу стартует контейнер.
1. Вы можете делать publish на windows машине. В VS предусмотрено несколько вариантов, вплоть до создания готового dockerfile или копирования результатов publish на нужный вам ftp.
2. Можно настроить CI. Допустим, после прохождения тестов, у вас может создаваться новый контейнер, куда попадает исходный код (затем уже внутри делается publish), либо результаты publish, и сразу стартует контейнер.
Немного дополню ответ от FJCrux: dotnet publish вне зависимости от ОС, на которой она запускается, можно указывать, под какую целевую ОС собирать бинари. Ну и сборка через CI на Linux вполне себе вариант — мы у себя смотрим именно в эту сторону
в последней коре (1.1.2) уже не надо указывать под какую платформу собирать. все работает на всех платформах
Бизнес логика требовала раз в секунду скачивать HLS плейлист и проверять не появилась ли там новая запись, если появилась, то новый файл (или файлы) скачивался на диск (с помощью HttpClient). Под Windows все работало прекрасно, а вот в Docker под Linux начались проблемы: скачивание плейлиста занимало от 3 до 6 секунд. То же самое происходило с файлами (~200 KB). Что бы узнать проблема в Docker или в Linux код был запущен на Linux машине без Docker'а, как оказалось Docker здесь не причем. Потом я наткнулся на этот блог:
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
Изменив имплементацию на повторное использование HttpClient, все идеально заработало под Linux'ом, а под Windows стало работать еще быстрее.
Вопрос к знатокам: почему такая огромная разница в поведении HttpClient под Windows и Linux?
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
Изменив имплементацию на повторное использование HttpClient, все идеально заработало под Linux'ом, а под Windows стало работать еще быстрее.
Вопрос к знатокам: почему такая огромная разница в поведении HttpClient под Windows и Linux?
Sign up to leave a comment.
Yet another tutorial: запускаем dotnet core приложение в docker на Linux