Lets-proxy

После некоторой работы с выписыванием сертификатов от Lets encrypt (в т.ч. написанием собственных утилит для массовой работы с доменами) я заметил, что они все (в т.ч. своё) требуют неочевидных настроек для начала работы. Тут мне пришла в голову мысль написать программу для работы с lets encrypt, которая настроек требовать не будет.


И вот результат: https://github.com/rekby/lets-proxy

Доступны исходники и скопилированные бинарники под основные платформы где это может потребоваться (windows,linux,freebsd).

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

При запуске без параметров программа будет слушать 443 порт на всех локальных IP-адресах и при получении запроса сама выписывать через Lets encrypt валидный сертификат и дальше проксировать запрос на тот же IP-адрес порт 80 (стартандный http-сервер). При устаревании сертификатов они будут автоматически обновляться.

При добавлении/удалении доменов ничего править не придётся - сертификаты выписываются автоматически.

Единственное требование - клиентское ПО, которое осуществляет запрос должно поддерживать работу со SNI (много сертификатов на одном IP-адресе). Это нужно чтобы сервер понял к какому домену происходит обращение до начала шифрования.

Все современные браузеры этот режим поддерживают.

За что мне нравится Go lang

1. Не мешает выражать то что думаешь
1. Простой синтаксис
2. Огромное количество библиотек на все случаи жизни
2. Простая кросс-платформенная компиляция: установить в переменной окружения целевую ОС/архитектуру и на этом всё: никаких танцев с вытягиванием/подключением библиотек целевой платформы. Т.е.я разрабатывая программу на винде потом просто компилирую её на своём же компьютере под linux и вот она уже пошла работать на серверах. То же самое в обратную сторону: пишу программу для linux-сервера. Отладил. Компилирую для Windows и она просто работает как работала. с другими языками для этого обычно нужно как минимум настраивать систему сборки на целевых системах или вытягивать оттуда и как-то подцеплять ключевые библиотеки.
3. Благодаря повсеместному использованию gofmt все исходники оформлены единообразно.
4. Встроенная система вендоринга (таскания всех зависимостей с собой) позволяет легко предотвращать ситуации когда всё накрылось из-за того что github недоступен или пакет удалился вместе со страницей автора.
5. Дешевое создание логических потоков (горутин) и простые способы связи между потоками.
6. Отсутствие средств мета-программирования направляет в русло решения собственно текущей задачи, а не построения абстрактных универсальных конструкций (которые зачастую больше не пригодятся).
7. Бинарник, получающийся после компиляции содержит в себе всё что нужно – никаких дополнений с собой на целевую систему тащить/прописывать не нужно.

По выразительности (простота + количество библиотек) я его воспринимаю на одном уровне с питоном с важным дополнением, что для python много библиотек написаны на C, а для go основная масса написана на Go и ничего дополнительного не требуется. По многопоточности – рядом с Erlang.

Из минусов:

1. Многословная обработка ошибок
2. Некоторые неочевидные способы выстрелить в ногу, например неявные переопределения уже существующих переменных через := внутри вложенных блоков кода.
3. Отсутствие средств для работы с GUI.