Помимо безудержного переедания, вопиющего нарушения режима сна и прочих непотребств, эти каникулы я посвящаю одному семейному IT-проекту, до которого раньше никак не доходили руки. Расскажу о нём отдельно в другой раз, а пока — об одной его подзадачке 👇🏼
Возникла потребность принимать на публичном сервере HTTPS-траффик с клиентских устройств, терминировать на нём TLS и отправлять дальше в прикладной сервис. В общем, типичная работёнка для обратного прокси-сервера. Заодно хотелось бы избежать головняка и расходов на SSL-сертификаты (намекаю на Let's Encrypt) и обеспечить перенаправление http(80)->https(443). Значит, нужен какой-то веб-сервер. Благо, варианты есть 📚
1️⃣ Мой собственный опыт в этой сфере сводится только к настройке Apache HTTPD — я вдоволь "наигрался" с этим сначала в универе, потом на работе. Вариант рабочий, но в 2026-ом году, пожалуй, нет, спасибо; здоровье дороже 🤢
2️⃣ В интернетах >80% ответов на подобный запрос сводятся к совету брать Nginx+Certbot — эта связка настолько популярна, что под неё есть даже готовые решения (пример), правда, со своими особенностями применения. В какой-то момент я уже принял мысль, что пойду этим путём, но всё же почти страничный конфиг и 10+ шагов инструкции по его применению не давали покоя, и я решил покопать дальше ⛏️
3️⃣ Модно-молодёжный вариант решения — Traefik — входная точка для микросервисов, поддерживает применение Let's Ecnrypt серфтификатов из коробки и ещё кучу всего. Но вот эта куча меня как раз и смутила — показалось, что это целый комбайн с тонной фич, которые мне не нужны, но за которые придётся "платить" ресурсами машины, а у меня их кот наплакал. Возможно, это заблуждение, но всё же решил поискать ещё 🔍
4️⃣ И тут наткнулся на Caddy — полнофункционональный, но при этом (вроде как) легковесный веб-сервер на Go, главными фичами которого заявлены полная автоматизация настройки TLS и простота конфигурации. Оба пункта прозвучали для меня очень вкусно, и я решил попробовать 😋
После недолгих изысканий я понял, что весь мой конфиг будет состоять из всего 3 строчек в специальном декларативном Caddyfile:
<мой_домен> {
reverse_proxy http://<адрес_моего_сервиса>
}При первом запуске Caddy увидел, что Let's Encrypt сертификата ещё нет, и автоматически провернул всю процедуру по его получению, а она, кто не в курсе, отнюдь не тривиальна:
* нужно инициировать запрос на выпуск
* пройти т.н. challenge (проверку владения доменом, она бывает 3 типов)
* получить и применить сам сертификат (+ключ)
* настроить перенаправление траффика 80->443.
Так вот Caddy всё это сделал сам с первого раза, чем уже меня порадовал 🪄
Но оставалось опасение, что он будет прожорлив по ресурсам. В качестве бенчмарка (и основного применения) я стал заливать через Caddy на сервер бинарные данные по 100 МБит/с каналу на протяжении нескольких часов с регулярным наблюдением за состоянием витуальной машины. Перед этим я проводил аналогичную процедуру через SSH-туннель — хуже точно не стало, а кое в чем (по мелочи) даже лучше. Это, конечно, не полноценный нагрузочный тест, но для моих целей он пройден ✅
Возможно, мне просто повезло с тем, что Caddy пришёлся кстати именно в моём случае, но 69К звёзд на его GitHub позволяют думать, что он всё же реально неплох, поэтому в следующий раз, когда потребуется поднять реверс-прокси, сбалансировать нагрузку или просто удобно раздать статику, я намерен применить его снова. Предлагаю взять его на заметку и вам 📝
#инструменты