Комментарии 9
Можно ли сделать автоматическое добавление как в Traefik? Ну т.е. в самом сервисе указать лейблы и чтобы они автоматически подтянулись в proxy?
Вручную добавлять не хотелось бы
NPM имеет REST API, и на его базе можно собрать автоматизацию — есть готовые скрипты которые при старте контейнера сами дёргают этот API и создают proxy host. Но это самодельный велосипед, не нативная фича.
Если нужна полноценная автоматизация через лейблы — Traefik, он именно для этого и создан. NPM же про другое: небольшое количество проектов, удобная веб-морда, минимум порога входа. Разные инструменты для разных задач.
Деградация девопса вышла на новый уровень.
Имея рут на сервере и задачу казуально запустить один контейнер под новым доменом за nginx, надо замутить ещё одну прослойку с веб-интерфейсом, вместо того, чтобы написать один простейший конфиг для nginx, сгенерировать сертификат certbot'ом и запустить один контейнер. И это преподносится как замена, простигосспади, Кубера. 3 максимально банальные операции.
Да, контейнеры, конечно, надо запускать в rootless, а каждому программисту выдавать своего пользователя. Ну можно ещё прав дать на добавление конфигов nginx и его reload и на certbot. Но это слишком тонкая шутка для нашего цирка.
Мне вот интересно, как может программист, пишущий web-приложения, не знать nginx и certbot? Каким надо быть аутистом? И каким надо быть лентяем, чтобы не изучить этот вопрос один раз и навсегда где-то в начале карьеры?
У меня для пет проектов используется traefik. Получается что каждый проект независим, а сам реверс прокси ничего не знает об этих проектах. Это хороший пример паттерна infrastructure as a code, хоть и в маленьких масштабах
запустить один контейнер под новым доменом
Как раз реверс прокси используют когда нужно запустить не один проект. А кол-во проектом может постоянно меняться. Каждый раз при добавлении проекта лезть и править конфиги? зачем? Чтобы при какой нибудь ошибке в конфиге nginx положить все сайты? Для чего все эти ручные действия?
Для разработки не то, что докер не нужен, вообще ничего не нужно. Приписывать конфиги nginx руками удобнее, если надо тюнить, а иногда надо тюнить. Поднимать приложения в докере — ну, на любителя модных технологий, я в этом смысла не вижу никакого, но даже в этом случае дополнительный управляющий слой выглядит избыточным. Nginx + Certbot + любой WSGI + ваше приложение в виртуальном окружении/докере, всё это не требует обёртки ввиду банальности и гибкости настройки.
В целом, если вы про деплой думаете в контексте докера, кубера и вот этой всей модной хрени, скорее всего, вы просто откровенно плохой devops. Если у вас nginx в докере, в моём понимании это сразу увольнение. Потому что приложение в первую очередь должно уметь работать на голой системе, без рута, безо всего, на systemd. Сколько было крови и пота пролито из-за того, что в продакшн уезжала какая-то программистская ебала́ в докере, которая и работала через жопу, и сам деплой даже в докере был неправильным, хотя там можно любую содомию запустить, которая как-то работать будет. Или потому что никто не знал и уже не умел понимать приложение без докера, а это надо было делать по какой-то причине, следующей из закона Мерфи.
Вы боитесь положить все сайты неправильным конфигм nginx? А про динамическое перечитывание конфигов nginx вы слышали? А знаете, что он не подсосёт новый конфиг, если там ошибка. Вы же сами сказали, что это пет проекты, это разработка, а не продакшн. В продакшн не может попасть конфиг nginx, кладущий систему без тестирования. А если цена не такая большая, то в чём проблема?
Короче, это оверинжениринг на пустом месте и болезнь современного девопса в виде докеров. @CeregaKC, учитесь работать без докера. Это не только качает мозг, но и помогает в сложных жизненных ситуациях. Сам докер — это довольно плохой, нечеловеческий продукт, который плевать хотел и на UnixWay, и на правила, и на культуру програмирования и деплоя. Его терминальная стадия — кубер, не нужен в абсолютно подавляющем большинстве случаев. Вы всегда сможете запустить ваше приложение в докере, если вы не идиот. А вот наоборот люди уже не могут. Но UnixWay и Systemd гораздо красивее философии докера. Не надо за громадьём новых и модных технологий прятать свою беспомощность и некомпетентность. Вы не понимаете деплой, если не умеете не в докер. Базу надо знать.
Вопрос от совсем новичка: а с systemd, cunicorn, и руками прописать пути в конфиге Nginx будет не легче чем подымать docker? Так же наделать поддоменов, порты не смотрят наружу, все за reverse proxy. В случае чего systemd перезагружает/запускает сервисы сам.
Казалось бы написано как избавиться от боли и к8с, а тут столько действий что аж страшно. Не проще поставить какой-то dokploy или просто docker-compose? Зачем столько действий для простого запуска докер контейнеров
Похоже на устаревшую информацию. Зачем столько действий, если можно поставить на vps код-агента и он сделает все остальное? Как будто, пет проекты сейчас руками уже лучше не кодить и не настраивать, а то опоздаешь.
Как превратить один VPS в платформу для деплоя нескольких проектов без боли и Kubernetes