Что лучше выбрать для реверс-прокси в контейнере?

Зависит от используемого оркестратора.

Для docker-compose есть очень удобные SWAG и NPM, но без поддержки cloud-native Ingress, а для Кубера IMHO идеален Traefik, хотя он и без Кубера тоже неплох.

Стоп-стоп-стоп! На данном этапе я бы хотел пройти через все трудности командной строки. То есть перед компосом, я хочу понять все тонкости запуска контейнера с необходимыми параметрами из консоли, пусть даже это вываливается в 3 - 4 строчки одной команды. До кубера мне видимо ещё вообще далеко.

Из содержания вопроса, аппликухи пусть будут пока два html файла с тегами <h1>, которые выводят Раз и Два. Я на данном этапе хочу разобраться что лучше подойдёт для обратного проксирования и не могу понять, чем лучше решения искаропки, вместо обычного nginx

Ничем не лучше. Докер (и докерхаб) - помойка, держись от него подальше.

Докер (и докерхаб) - помойка, держись от него подальше.

Why? Я на сегодняшний день неплохо «могувлинукс», но мои собеседования резко заканчиваются на вопросах контейнеризации. Решил изучить этот вопрос.

Или ты подразумеваешь сборку своих контейнеров мастхэв?

В виртуализации у меня реверс-прокси ВМ занимает 6 гб, а в контейнере на алпайне ~ 50 мб. Как бы есть в этом профит

Подскажите, чем лучше готовые решения от ванильного nginx’a

У тебя вопрос на самом деле «чем контейнеры лучше». Тем, что вокруг них есть мощная инфра, которая позволяет реализовать инфраструктурные паттерны, как минимум деплой и обнаружение сервисов. На этой диаграмме внизу можно ознакомиться: https://microservices.io/patterns/index.html

вокруг них есть мощная инфра

Согласен. Контейнеры - это стильно-модно-молодёжно, да и развернуть разрабу среду для работы в трипятнадцать быстрее будет в контейнере, чем в виртуализации.

В общем я так понимаю что разницы между готовым реверс-прокси и обычным nginx’ом, настроенным для проксирования нет. Главное что ты на выходе получаешь

Обычно не говорят «готовый образ». По крайне мере, я не слышал. Это просто дистрибуция софта, как и в обычных ОС, только для контейнерного окружения. И там и там предполагается этот софт как-то конфижить, и там и там есть дефолты для усреднённого частого случая.

А что ты понимаешь под обычным nginx? Чем необычен nginx с докерхаба?

разницы между готовым реверс-прокси и обычным nginx’ом, настроенным для проксирования нет

Так вопрос nginx в контейнере vs nginx без контейнера или nginx vs другие реверс-прокси? Если первое, то контейнеры делаются не для приобретения nginxом «необычных» свойств, а для развертывания. Чтобы например у разработчика было все как в проде и он мог увидеть, не порушат ли его изменения чегонить.

А что ты понимаешь под обычным nginx? Чем необычен nginx с докерхаба?

Если я хочу на завтрак бутер с маслом и колбасой, то я беру ингредиенты и делаю.

Для примера бутер с маслом и колбасой - это jwilder/nginx-proxy
Обычный nginx - это nginx и дальше я на него намазываю масло (готовлю nginx.conf) и ложу сверху колбасу (прокидываю файл внутрь контейнера)

nginx vs другие реверс-прокси

Вот так

Чел, очнись, ты на техническом форуме, какие ещё дебильные аналогии с бутерами?

Первое это такой же обычный nginx обвязанный умными скриптами (ну, вроде там какая-то прога на го) Второе просто nginx в контейнере.

Хочешь ванильного экспириенса, возьми второй и сооруди что-то похожее на первый, хочешь быть дурачком девопсом, который умеет только кнопки в браузере нажимать и попивать смузи на соевом молоке пока все само разворачивается, бери первый.

В общем для разработчика, чтобы понять как это работает и связать контейнеры - собирай все сам. Можно даже не брать готовые докерфайлы, а самому написать что-то вроде RUN apt install nginx

Но в целом, как сказал Фиркакс, докер это помойка, лучше бы его не существовало.

Какие ещё дебильные аналогии с бутерами?

Это я для дебилов, которые не понимают сути вопроса, стараюсь на их языке разъяснить, что я хочу получить

Относительно хорошая контейнеризация в линуксе это lxc. Докер и всё что с ним связано (в том числе его клоны с другими названиями) - плохая, лучше не идти туда где их хотят.

Что касается реверс-прокси то просто установи nginx штатно пакетным менеджером и запусти.

lxc и docker это одно и тоже, они оба основаны на cgroup и namespace.

лучше не идти туда где их хотят.

Сисадмин линуксойд на хх.ру - 150 - 200к
DevOps на хх.ру - 200 - 300к

Я бы может и рад, но улучшить финансовое положение не плохо было бы. Поэтому погрязаю в контейнерах. Как осилю, надо будет в k8s заныривать.

https://edu.softline.com/vendors/akademiya-ayti/rabota-s-konteynerami-docker-i-vvedenie-v-administrirovanie-klastera-kubernetes/

Недельный курс за 56000 р. и хоба, ты уже сеньор девопс с зарплатой на 100к выше. Курс веду я, приходи.

для Кубера IMHO идеален Traefik, хотя он и без Кубера тоже неплох

У меня тоже Traefik оставил крайне благоприятное впечатление.

Курс веду я, приходи.

Благодарю за предложение и уверен, что переданные знания безусловно ускорят усвоение материала и помогут в жизни, но пойми меня правильно, вся информация по любому продукту лежит на поверхности бесплатно =) Не то, что бы я скупердяй, я просто могу и усею найти искомое =)

В любом случае ещё раз спасибо!

Недельный курс за 56000 р. и хоба, ты уже сеньор девопс с зарплатой на 100к выше. Курс веду я, приходи.

Недельный сеньор, самому-то не смешно?

Да я не против, твой выбор. Вся эта информация на поверхности, на английском, просто ты потратишь полгода-год. Удачи )

Пробовал разные traefic, npm, haproxy.

В итоге остановился на чистом nginx. Ибо больше контроля и возможностей. Бегает в отдельном lxc контейнере.

Раскатка виртуальных сайтов происходит через Ansible, где есть роль и список параметров сайтов (server name, port, auth, etc) в vars. Он же создает серты через certbot.

Нужен новый сайт - добавил новый в список и раскатал роль.

Ansible

Это довольно древний устаревший не cloud-native способ.

Нужен новый сайт - добавил новый в список и раскатал роль.

Правильнее и современнее через kubectl apply.

Но почему не helm install тогда уж? Как будто без шаблонижатора деплоить манифестами - такое себе. ТС: я бы ещё посоветовал посмотреть на Angie

Но почему не helm install

Уж тогда сразу Cozystack? ;)

Btw., мне больше нравятся Helmwave и Flux пока велосипедно без Cozy, но я уже готовлюсь к его освоению и буду рад внедрениям в т.ч. с моей помощью, если будут желающие.

А вообще конечно подразумевалось, что через Кубер и его API, у Хелма ведь под капотом тоже шаблоны манифестов Кубера, в конечном итоге отправляемые в его API аналогично kubectl?

я бы ещё посоветовал посмотреть на Angie

Я бы тоже посоветовал посмотреть на него повнимательнее:

https://ruvds.com/ru/helpcenter/kak-ustanovit-sertifikat-lets-encrypt-na-angie/

В Traefik это делается полностью автоматически его родными операторами, что как бы намекает … (на необходимость отдельного админодевопса для анжи, который будет отслеживать обновы сертов ?)

:)

Скажу честно, cozy как-то не тыкал, flux да. Но как будто любой GitOps инструмент будет делать примерно то же самое.

Я бы тоже посоветовал посмотреть на него повнимательнее:

https://ruvds.com/ru/helpcenter/kak-ustanovit-sertifikat-lets-encrypt-na-angie/

Когда смотрел в последний раз, там уже была поддержка ACME и автоматический выпуск сертификатов, например, вот (angie.software), или это обман и они так не могут? А еще нормальный модуль с метриками, а не костылить, как с nginx. Для кубов использовал этот инструмент, но есть нюанс, что не всегда кластеры видны напрямую из интернета без сложных схем с кучей WAF/реверс-прокси посередине.

https://traefik.io/compare/traefik-vs-nginx/

Да я даже спорить не собирался. Если бы у него не было преимуществ, скорее всего, проект был бы никому не нужен, но это не так. В целом да, сейчас nginx уже не выглядит современно, собственно, поэтому написал про одну из альтернатив. Очевидно, их больше одной, и можно повыбирать.

В общем для своей задачи нашёл мануал, который прям покрывает всё, что мне требуется. Это своего рода заготовка или шаблон, руководствуясь которому выходит вроде как неплохое решение

Поменьше думай о финансах, это вредно.

Да вроде вполне адекватные люди используют, другой вопрос что когда говорят «я взял готовый образ и хренак хренак и в продакшен» это имхо не здорово.

Судя по этой теме до 150к вам ещё расти и расти. И таки да, 200-300 включают в себя те самые 150-200.

Если вопрос между nginx vs caddy vs etc, то могу заметить, что у nginx на голову ушибленная реализация DNS, поэтому для корректного реверс-проксирования как минимум надо брать openresty. У всего остального таких проблем нет. При прочих равных мне нравится caddy, т.к. он вопросы с TLS решает с нулём усилий, у nginx такого простого функционала пока тоже нет, насколько я знаю. Пользовал caddy на нескольких проектах, проблем не испытывал, хотя всё же к nginx доверия больше, проект уже испытанный временем.

Если вопрос между nginx и сборочкой nginx от васяна, ну я последние не пробовал. Изучай гитхаб, смотри, чего они там понаделали. Я бы не стал их использовать, но как источник для вдохновения - почему бы и нет. А так - лучше всего брать любимый дистрибутив в качестве базового образа, ставить туда nginx из пакетов и всё, вот тебе и «официальный образ» в две строчки. Зачем нужен docker.io/library/nginx, я лично не знаю.

В этом вся суть твоих девопсов.

что у nginx на голову ушибленная реализация DNS

На голову ушибленные это те кто в веб-сервер зачем-то днс засовывают. А у nginx всё в порядке.

Ну а го-мусор (твой кадди) не нужен.

Кому не нравится, могут пойти в академическую науку. Там полная противоположность: сначала нужну двадцать лет напряжённо учиться, а потом зарабатываешь сущие копейки.

Вот же ты позорище.