настраивать не надо если можно юзать докер?
Я пол дня убил на то что бы прод среду настроить, я в беке и в девопсе не бумбум, но как умел, так и делал и через nginx у меня все взлетело. Но когда начал внедрять ci для песочницы, я увидел что все что я делал, в доке по vapor, параллельно описано и про докер.
Проэктик маленький простенький - proxy webhook handler
Это разные вещи, могут быть и комбинированно и отдельно. А в чем проблема его настроить? Просто файлик скопировать
Ну я вижу что если запущен nginx, то мой проект валится в дебаге, ведь порт занят nginx.
Отсюда предполагаю что если и настраивать их работу в параллель, то внутри контейнера.
Ну как бы да, нгинкс должен быть на другом порту и проксировать вейпор. Вейпор запускаешь на любом, а нгинкс на каком нужно
Не даст, нельзя на один порт два сервиса ставить
При этом vapor вообще на локалхосте, нефиг ему наружу смотреть
А без nginx, только докер юзать в проде, получится?
Ну естественно он должен проксировать аналогично nginx запросы из вне
Разницы ноль, в сеть выставлено одно и тоже.
Ок, пошел копать дальше, спасибо!
О, так давайте позанудствуем, я только "за". У меня, очевидно, не получилось выразиться достаточно ясно, так что я сейчас исправлюсь. Выше я имел в виду, что если vapor'у при помощи wrk вставить столько, сколько в него не пролазит, и он уходит в астрал (тут ничего удивительного нет), а потом вставленное вынуть, то он из астрала не возвращается (а вот это уже плохо). Т.е. акцент не на том, что он нагрузку не держит (потому что держать больше, чем можешь, не способен никто, просто по определению), а на том, что не возвращается к нормальной работе потом, после снятия нагрузки. И ладно бы упал, его бы systemd перестартовал и всё было бы нормально — но нет, сидит молча и никаких сигналов не подает. Понятно, что такая ситуация неприятна тем, что если ваше приложение не обвешано мониторингом с головы до ног, то вы рискуете просто не узнать, что оно не работает, и, соответственно, не примите меры по исправлению ситуации. Тут нужно добавить, что я не пример из репозитория использовал, а рабочее приложение, в котором много всего. Не возьмусь утверждать, что так будет себя вести любая конфигурация vapor, но моя конкретная вела себя именно так. Настроил rate limiter в nginx — и стало хорошо.
Даже если так все плохо с вапором, то всегда можно отмониторить сторонней утилитой то, что сервер больше не отвечает и рестартануть его. Хорошим делом было бы создать issue на https://github.com/vapor/vapor и описать там эту проблему и глядишь бы в скором времени вапор бы научился выходить из астрала
Обсуждают сегодня