кастомный jar на 443

4.1) Запускать на http, делать https средствами nginx’а + proxy_pass.

Даже если бы не было проблемы с 443 портом, всё равно лучше через nginx делать - потом будет проще с дальнейшими настройками доступов и/или логами, если надо, без вмешательства в настройки и работу самого приложения.

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

Это не всегда удобно (веб, внезапно, это не только большой продакшн в централизованных облаках, так только пацаны из РКН думают). Вот у торрентокачалки transmission есть веб-интерфейс, как и у pgadmin4. Их тоже надо в образ и контейнер или как? Да чтоб не голословить OpenRefine он на java как раз тоже в контейнер?

transmission есть веб-интерфейс, как и у pgadmin4. Их тоже надо в образ и контейнер или как?

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

У pgadmin4 вообще официальный образ есть. Качалка собрна на двух образах с linuxserver.io.

Из этих вариантов я бы выбрал 2 или 3.

Ещё из вариантов - подправить sysctl который разрешит всем обычным пользователям биндиться ниже 1024 порта. Всё равно безопасность всего этого на мой взгляд довольно условная.

А так на практике всегда впереди стоит реверс-прокси сервер, nginx или ещё какой, так что 4, но не ради порта, а для решения других проблем, порт тут это нюанс третьестепенный.

Это не всегда удобно

Это практически всегда удобно. Лично я с неудобствами сталкивался в своей жизни ровно один раз: когда docker контейнеры не хотят ходить в IPsec туннели. Но и это решается.

Вот у торрентокачалки transmission есть веб-интерфейс, как и у pgadmin4. Их тоже надо в образ и контейнер или как?

Непонятно, что тебя смущает. Безусловно их надо тоже в образ и контейнер. Вообще в первую очередь надо.

Обычно да, SSL терминируется каким-то Nginx'ом или HAProxy перед приложением.
Можешь сделать sysctl ip_unprivileged_port_start=443, как вариант.

Безусловно их надо тоже в образ и контейнер. Вообще в первую очередь надо.

Кому надо - тот делает. Кому не надо - делает по-другому, что за навязывание?

Меня смущает, зачем на Java привязываться к какой-то сторонней приблуде, когда надо чтоб софт работал не только в линуксах, идеальное java приложение это вообще одна кнопка/ярлык который ткнул, распаковав архив и оно работает везде, вне зависимости от того где, как и когда его запустили. Вообще задрали честно докеры, снапы, карго, флетпаки, пипы, анаконды и прочая лабуда, которая в теории должна избавлять от головной боли, но вместо этого добавляет её из-за неправильного применения, а именно те кто по работе используют один из этих инструментов начинают его везде тащить, не видя проблем и имея профдеформацию (у снапа вечно проблемы с доступом и что-то отваливается, то тема иконок, то звук, то сохранение настроек, то масштабирование экрана, у флетпака лучше но тоже самое только реже, карго и пипы вообще вне их ЯП не должны использоваться, докеру место только на проде и когда коду на проде полностью доверяешь, в отличии от виртуалки куда можно всякую гадость ставить). Чем всё это добро тянуть и поддерживать надо было репы делать, возможно как у NixOS, а может ещё более специфичные с какой-то песочницей на уровне ядра ОС. А так имеем кучу говна разной степени дырявости, так ещё и централизованно за всем этим не проследить. И да, изначально пипы, карго и прочие инструменты делали для разработки, но нет, там теперь тоже софт распространяется, и ладно пип и всякие программы для работы с облаками и сетью через парсинг, которые надо обновлять раз в пару часов, вроде скачивания видосиков с хостингов, которые копротивляются, но нет, растоманы в карго хорошую софтинку положили - oxipng, а в репы в полтора дистрибутива собрали и те дикая экзотика, а бинари растишки ещё менее стабильны чем у сишки в линуксах, когда надо чтоб свежий-свежий компилятор и растишкины либы были и вообще на расте не модно чтоб софт работал с либами которым хотябы пол года.

Их тоже надо в образ и контейнер или как?

А что мешает? https://snapcraft.io/transmission

А почему навязывание? ТС спросил «как надо» — чуваку ответили как надо. Контейнеры ещё и дополнительный слой изоляции организуют, а ТС-у надо «безопасно».

Я предлагаю либо nginx/angie, либо контейнеры, а почему нет.

P.S. обратный прокси тоже можно в контейнере гонять, чтобы если что, из него по сети можно было обратиться только в соседний контейнер, а по ФС вообще никуда.

Ну это из разряда «зачем заводить отдельного пользователя для сервиса, можно же под рутом». Можно, а зачем? Так и тут.

В нынешнее время контейнеры это хороший бонус для изоляции. В первую очередь логической, чтобы знать на 100%, как конкретная программа взаимодействует с остальной операционной системой (т.к. контейнер заставляет явно перечислять все порты, используемые образом, все точки монтирования, случайно нагадить куда-то программа уже не сможет).

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

В общем я считаю применение контейнеризации на сегодняшний день практически обязательным. Исключение - когда сервер используется строго для конкретной цели и на нём не планируется запуск произвольных программ. Типа вот у меня есть сервер-бастион, туда по wireguard подключаются и всё. Там вообще никакого софта не крутится, только wireguard скрипты на старте настраивают интерфейсы, ну и nftables роутинг и прочее настраивает. Там - да, контейнеры не нужны. А когда речь идёт о запуске transmission и pgadmin, ну тут уже понятно, что на сервере запущено куча всего и контейнеры будут хорошей идеей.

Технически можно и без них, конечно. Даже проще будет поначалу. Но см. аргумент про рута.

Меня смущает, зачем на Java привязываться к какой-то сторонней приблуде

Не хочешь - не привязывайся.

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

Когда какой-то HTTP сервер просто смотрит в интернет, он имеет дело с потенциально плохими дядями. Вот взять типовое Java приложение до изобретения виртуальных потоков. На подключение запускается новый поток. В этом потоке уже идёт работа с сокетом. Плохой дядя подключается к серверу и начинает слать HTTP запрос. Один символ раз в минуту. В общем будет сутки его слать. При этом для приложения вроде всё хорошо, запрос потихоньку приходит, мы его читаем, парсим заголовки. И все эти сутки поток висит, кушает там несколько сотен килобайтов оперативной памяти. А рядом ещё сто потоков. И всё, упёрлись в лимит, сервис по сути лежит. DDOS называется.

Или какие-нибудь заголовки гигабайтного размера придут. А там StringBuilder собирает его и отжирает память, пока не упадёт процесс.

Это всё предположения. Наверное явные косяки подобного рода в томкате исправлены. Но кто это проверял? Реально в интернет всегда смотрит nginx и подобные. Вот они уже, как говорится, протестированы в бою, там таких косяков 100% нет. И если запрос от nginx ушёл в томкат, значит запрос проверен и перепроверен, полностью считан, и проблем с ним нет. Вот для вот этой безопасности и нужен нгинкс перед томкатом.

Помимо этого среднестатистический сисадмин легко настроит HTTPS с certbot-ом, например, для nginx. А для томката с каким-то произвольным приложением? Да фиг он что настроит, он даже не найдёт, как сделать, чтобы .well-known отдавался. Настроить, конечно, можно, но в nginx-е это проверенный путь. Какие там алгоритмы шифрования в томкате прописаны, кто там это проверял? Это, конечно, мелочи, но какой-нибудь аудит безопасности может и не пройти, придерутся к какой-нибудь ерунде, а ты задолбаешься настраивать эти нюансы в томкате, а в nginx всё уже по гайдам давно сделано.

Ещё частенько хочется за одним доменом прятать несколько веб-приложений. Самое банальное - /api идёт на наш пресловутый томкат, а всё остальное на какой-нибудь статический фронтэнд. Бывают и менее банальные варианты, и довольно часто. Тут уже без реверс-прокси становится совсем грустно.

Вот это всё про то, зачем nginx нужен перед томкатом.

идеальное java приложение это вообще одна кнопка/ярлык который ткнул, распаковав архив и оно работает везде, вне зависимости от того где, как и когда его запустили

Такого не бывает. Тебе нужна сборка JVM под конкретную платформу. Ни на одной ОС JVM не стоит из коробки. Наверное программку на питоне в этом плане проще запустить, питон почти на любом линуксе и на макоси идёт из коробки. Про винду хз, но вообще не удивлюсь, если нынче и там есть.

Самое интересное, что многие популярные программы на Java идут вместе с JVM. Ну пользователю так проще. И, конечно, архивы скачиваются разные для каждой ОС и архитектуры. А раз они разные - какой вообще смысл в этой Java, можно и на Go разные бинарники выкладывать точно так же, ещё и удобней будет с одним файлом.

Так что все эти мантры про Write Once, Run Anywhere они больше теоретические, на практике частенько вылазят нюансы…

Ну это из разряда «зачем заводить отдельного пользователя для сервиса, можно же под рутом».

Нет, это всё же разные вещи.

Я нормально отношусь к докеру, но тянуть в него абсолютно всё - это вот тоже самое, что и «я знаю молоток, всё вокруг гвозди», действительно. И я хорошо помню эпопею с xml.

Да фиг он что настроит, он даже не найдёт, как сделать, чтобы .well-known отдавался.

Это всё настраиваемо, но вот для применения нового https-сертификата, насколько я помню, томкат надо перегружать :) В отличие от reload nginx :)

Когда какой-то HTTP сервер просто смотрит в интернет, он имеет дело с потенциально плохими дядями. Вот взять типовое Java приложение до изобретения виртуальных потоков. На подключение запускается новый поток. В этом потоке уже идёт работа с сокетом. Плохой дядя подключается к серверу и начинает слать HTTP запрос. Один символ раз в минуту. В общем будет сутки его слать. При этом для приложения вроде всё хорошо, запрос потихоньку приходит, мы его читаем, парсим заголовки. И все эти сутки поток висит, кушает там несколько сотен килобайтов оперативной памяти. А рядом ещё сто потоков. И всё, упёрлись в лимит, сервис по сути лежит. DDOS называется.

ИМХО должен быть тайм лимит на такое дело. Т.е. запрос не держать дольше минуты, может 5 минут. А кто это делать должен, томкат (иногда в связке с апачем) или энжин-икс, дело десятое. Гайды тоже понятие поправимое. Понятно что как сервер энжин-икс куда более взрослый и полноценный. Но это просто говорит о том, что надо томкат развивать и улучшать, чтоб он не ломался на раз два, тем более у софта на сишке потенциальных уязвимостей больше на порядок, чем у джавы. В идеальном мире ему бы ещё и статику научиться хорошо отдавать, чтоб нужды в сервере под статику впереди него не было.

Такого не бывает. Тебе нужна сборка JVM под конкретную платформу. Ни на одной ОС JVM не стоит из коробки.

Она туда ставится, если нужен софт на джаве. И головная боль по поддержке джавы на разных платформах не у разработчиков конечного приложения, а у разработчиков JVM, которые, к слову, бывают даже не от оракла. У самой джавы одна проблема на самом деле - UI, он везде неродной, веб UI эту проблему решает. Ну и конечно медленный старт JVM в сравнении с CLR это не плюс для Java, не смотря на то что после запуска JVM работает быстро. У шарпа приложение запустил и оно мгновенно работает, а в случае с UI джавой часто даже индикатор для запуска приложения делают, прежде чем оно прогрузится, чтоб юзеру так не напряжно было.

Печалька конечно. Но это ИМХО надо томкат опять развивать, не более. Сама по себе идея томката как по мне лучше, чем у электрона.

5. authbind

софтина из тех же времен, что и linux capabilities. В отличие от cap_net_bind можно выдать разрешение пользователю на privileged порт, а не бинарю. Ничего не скажу за актуальность и безопасность, но когда тестировал - функцию свою выполняла

В rpm дистрибутивах обычно ее нет, но можно скомпилить или найти сборку. В deb дистрибутивах есть

А что мешает пользоваться веб-интерфейсом transmission на другом порту?

Если порт недоступен снаружи, я делаю ssh -L 59091:127.0.0.1:9091 user@mylittlehost.domain.org.