nginx и регулярки прямо скажем не всегда работают как ожидаешь. Особенно, когда используется map и переменные вида $1..$9
Связано это, насколько я понимаю, с тем, что в $1..$9 содержатся данные последней вычисленной регулярки, а если используется map то, получается, значения там буду из него, а не из location (например)
У них даже дефект соответствующий есть, но воз и ныне там
Искать первопричину — это важно, но не всегда эту причину могут устранить за приемлимые время и деньги, откуда и получаются костыли. И тут вторая проблема, что после того, как причину устранили (а это может быть не скоро), те самые костыли обрасли новыми костылями
«Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?
Да, действительно. Спасибо!
А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.
Если говорить про вариант «Не так давно», то он делался на коленке и команда не рассматривала рефакторинг этого кода, как нечто необходимое
Если же говорить про текущий вариант, то да, как выше отметили, мы либо закладываем это в оценку задачи, либо убеждаем продуктовый офис вынести это отдельной задачей, обычно они идут нам навстречу.
На них вряд ли стоит строить БЛ, но у нас была потребность показать пользователю, какие от данной команды можно ожидать неуспешные результаты (и сказать, что они значат, чтобы он мог это поправить)
Ваши примеры, на самом деле, заставляют разработчика дополнительно описать какие-то описания и аннотации, а мы хотел избавиться от этого.
В нашем случае, у нас всегда должны быть тесты. А вот аннотаций для документации может не быть, а чтобы их писать, нужно изменить процесс разработки
Эти классы описывают входные и выходные параметры action'ов? То есть вместо request на вход, там какой-то класс, на выход вместо прямой записи в response body там тоже какой-то класс. А как вы, в таком случае, будете обрабатывать ошибочные случаи?
Не совсем понимаю, зачем вы во ViewModel помещаете DTO объект, который, по факту, не имеет к нему никакого логического отношения. Вы ведь смешиваете логику, которая нужна для создания новых объектов (различные валидации в DTO объекте) и объекты отображения, на которых никакой логики в принципе нет.
Используйте в полной мере доступный функционал — есть ведь прекрасные PartialView, ChildAction(в ASP.NET) и ViewComponent(в ASP.NET Core).
Появится у вас задача на той же страничке, отобразить еще какой-то блок информации, не будете же вы и её добавлять во ViewModel?
Помимо того, что вы разделяете логику и отображение, вы еще и избавитесь от обеих ваших проблем
Возможно несколько вариантов:
1. Вы можете делать publish на windows машине. В VS предусмотрено несколько вариантов, вплоть до создания готового dockerfile или копирования результатов publish на нужный вам ftp.
2. Можно настроить CI. Допустим, после прохождения тестов, у вас может создаваться новый контейнер, куда попадает исходный код (затем уже внутри делается publish), либо результаты publish, и сразу стартует контейнер.
Используем dotnet core практически с момента релиза. Примерно в тоже время, открыли для себя прелести докера, так что всё в нём.
Сейчас в проде — 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. При работе с собственной сетью, все приложения, которые её используют, могут обратиться к любому другому приложению в этой сети по имени контейнера.
Не очень понимаю, зачем добавляем ForwardedHeaders:
Насколько знаю (и использую в своих проектах), можно спокойно вытащить настоящий Ip — Request.HttpContext.Connection.RemoteIpAddress либо из заголовка X-Real-IP, даже если kestrel прячется за прокси.
В своих проектах используем supervisor, чтобы «демонизировать» asp.net core.
В итоге выходит как-то так: есть n-контейнеров с asp.net core приложениями, у которых внутри supervisor и само приложение, есть контейнер с nginx, который слушает все входящие запросы на 80 и 443 порты, а потом просто прокидывает в нужный контейнер, ну и всякие контейнеры с базами и прочим.
Из приятного в таком подходе — можем держать зоопарк приложений с разными версиями dotnet core всего лишь создав несколько образов
Так ведь тут не лень. Упор на людей, которые, так случилось, читают комиксы на смартфонах (да, это странно). И, как правильно замечено выше, зумить каждый раз, чтобы прочитать новую реплику — не очень приятно.
FF:06:B5 разгадали же. в награду получаем автомобиль Demiurge в игре
Мало того, что продажи закрыли, так еще и текущие предзаказы вернули, в тч оплаченные, в тч в сторонних магазинах
nginx и регулярки прямо скажем не всегда работают как ожидаешь. Особенно, когда используется map и переменные вида $1..$9
Связано это, насколько я понимаю, с тем, что в $1..$9 содержатся данные последней вычисленной регулярки, а если используется map то, получается, значения там буду из него, а не из location (например)
У них даже дефект соответствующий есть, но воз и ныне там
Это сработает, если окружение linux. Для macos и windows не уверен, что профит будет существенным
Искать первопричину — это важно, но не всегда эту причину могут устранить за приемлимые время и деньги, откуда и получаются костыли. И тут вторая проблема, что после того, как причину устранили (а это может быть не скоро), те самые костыли обрасли новыми костылями
Да, действительно. Спасибо!
Если говорить про вариант «Не так давно», то он делался на коленке и команда не рассматривала рефакторинг этого кода, как нечто необходимое
Если же говорить про текущий вариант, то да, как выше отметили, мы либо закладываем это в оценку задачи, либо убеждаем продуктовый офис вынести это отдельной задачей, обычно они идут нам навстречу.
В нашем случае, у нас всегда должны быть тесты. А вот аннотаций для документации может не быть, а чтобы их писать, нужно изменить процесс разработки
Используйте в полной мере доступный функционал — есть ведь прекрасные PartialView, ChildAction(в ASP.NET) и ViewComponent(в ASP.NET Core).
Появится у вас задача на той же страничке, отобразить еще какой-то блок информации, не будете же вы и её добавлять во ViewModel?
Помимо того, что вы разделяете логику и отображение, вы еще и избавитесь от обеих ваших проблем
1. Вы можете делать publish на windows машине. В VS предусмотрено несколько вариантов, вплоть до создания готового dockerfile или копирования результатов publish на нужный вам ftp.
2. Можно настроить CI. Допустим, после прохождения тестов, у вас может создаваться новый контейнер, куда попадает исходный код (затем уже внутри делается publish), либо результаты publish, и сразу стартует контейнер.
Сейчас в проде — 4 веб приложения, несколько десятков консольных.
Проблем с деплоем не было, были «проблемы», связанные скорее со связкой dotnet core + linux:
Итого, у нас работа построена так:
1. Есть контейнер nginx, который выступает в качестве reverse-proxy.
2. Есть контейнеры с базами
3. Есть контейнеры с dotnet приложениями, внутри которых, кроме самого приложения, supervisor.
Объясню почему supervisor, а не вариант из репозитория — есть несколько контейнеров, внутри которых сидит не одно приложения. Обычно, это какие-то маленькие приложения, которые шлют письма или что-то подобное, для чего не хотелось бы создавать множество контейнеров.
Нюанс про docker-compose и локальную сеть между сервисами.
Если у вас много приложений и они все в разных compose-файлах, проще создать собственную сеть внутри docker. При работе с собственной сетью, все приложения, которые её используют, могут обратиться к любому другому приложению в этой сети по имени контейнера.
Насколько знаю (и использую в своих проектах), можно спокойно вытащить настоящий Ip — Request.HttpContext.Connection.RemoteIpAddress либо из заголовка X-Real-IP, даже если kestrel прячется за прокси.
В своих проектах используем supervisor, чтобы «демонизировать» asp.net core.
В итоге выходит как-то так: есть n-контейнеров с asp.net core приложениями, у которых внутри supervisor и само приложение, есть контейнер с nginx, который слушает все входящие запросы на 80 и 443 порты, а потом просто прокидывает в нужный контейнер, ну и всякие контейнеры с базами и прочим.
Из приятного в таком подходе — можем держать зоопарк приложений с разными версиями dotnet core всего лишь создав несколько образов