Реализация сборки Docker образов для GOST Engine

[kaperusov]

Этот PR добавляет поддержку Docker для простой сборки и распространения GOST Engine.

Что добавлено:

• docker/Dockerfile.alpine - минимальный образ на базе Alpine Linux
• docker/Dockerfile.debian - образ на базе Debian Trixie
• docker/Makefile - GNU make утилита для автоматической сборки и тестирования образов
• .dockerignore - оптимизация контекста сборки Docker
• Обновление INSTALL.md - документация по сборке через Docker

Дополнительные комментарии:

• openssl используется системная, то есть устанавливается из репозитория базового образа. Пока готова поддержка двух дистрибутивов: Alpine и Debian. При желании, список образов можно расширить, но нужно подбирать образы, в которых openssl совместимы (3.4+) по версии с текущей версией engine. Собирать отдельно openssl внутри этих образов считаю не целесообразным, это совсем другая задача.
• Я добавил свой Makefile, так это немного упрощает многие действия. Так, команды make alpine или make debian выполняют не только сборку, но формирование имени образов исходя из названия тега в гите или по имени текущей ветки. Плюс делается автоматическая проверка: после сборки образы тестируются на корректность установки GOST движка.
• Я не уверен, что мне стоило обновлять INSTALL.md. Может было бы лучше составить отдельный md файл в папке docker и на него уже ссылаться из общей документации. Но пока оставил так. За вашим комментарием.

[chipitsine]

в github actions хотите добавить (можно в принципе на базе makefile, заодно и его будем тестировать) ? или я могу нарисовать.

и вопрос, наверное, на будущее, публиковать ли образ где-нибудь в ghcr или docker hub

[chipitsine]

касаемо "Собирать отдельно openssl внутри этих образов считаю не целесообразным, это совсем другая задача." - обычно это делают через multi stage build, когда в конечный образ включаются только результирующие библиотеки

но все подобные улучшения оставим на совесть тех, кого текущий вариант не устраивает )) пусть делают пул реквесты

[kaperusov]

в github actions хотите добавить (можно в принципе на базе makefile, заодно и его будем тестировать) ? или я могу нарисовать.

и вопрос, наверное, на будущее, публиковать ли образ где-нибудь в ghcr или docker hub

Actions добавить - идея правильная! И в docker hub публиковать тоже считаю нужно и полезно, а иначе зачем всё это? :)
На счёт того, кому actions делать - скрипты набросать не сложно, главный вопрос под чей учёткой в реестр пушить. Я так понимаю, gost-engine ещё не заводилась в docker hub? Это кто-то из майнтейнеров должен делать, я считаю.

[kaperusov]

касаемо "Собирать отдельно openssl внутри этих образов считаю не целесообразным, это совсем другая задача." - обычно это делают через multi stage build, когда в конечный образ включаются только результирующие библиотеки

но все подобные улучшения оставим на совесть тех, кого текущий вариант не устраивает )) пусть делают пул реквесты

Тут вопрос не в том КАК собирать, а в том, с какой целью это делать. Какую задачу этим хочется решить! Я имею в виду, в данном, конкретном проекте. Может сбоку openssl в docker оставить ребятам из openssl?

Ну хорошо, есть очевидная проблема: в каком-то дистрибутиве версия openssl ниже 3.4, и сборка проекта и главной ветки уже не пройдёт. Я так обломался, когда хотел в это PR ещё rockylinux добавить. Но там в latest образе openssl 3.2... я просто плюнул на него. Может позже гляну на другие оси.

Ну допустим, мы хотим эту проблему решить, тогда нужна карта соответствий версий. Наверное, в проекте что-то такое есть и можно на это заложиться (точно? А если мы из тега будет собирать, это же как-то нужно программно сделать, надо думать). Ну хорошо, следующий вопрос - openssl Хотим ставить в обособленных папках (/opt/openssl, /usr/local, etc) или обновлять системный? Я за то чтобы, ставить сбоку. И не потому что так проще, а потому что в противном случае
это "слегка" инвалидирует дистрибутив. Тот же debian довольно сильно заморачивается с совместимостью своих библиотек в репах, а тут мы со своим самоваром. И не абы каким! Легко можно curl отломать, wget и пр. Но как раз это может быть конечно целью тех разработчиков, кому такая сборка и нужна. Может им нужно curl скомпилять на стероидах...

В общем, я думаю, что под всех мы не подстроимся и нужно задачу сразу упростить. Тут исходники engine, их мы и собираем, все третье-стороние зависимости - это уже кем-то собранные и проверенные бинари. А то ещё сидеть и разбираться, поему openssl в alpine не собрался из night build комита.

Пардон, что длинно и занудно.

[vt-alt]

А зачем собирать через Docker? gost engine dso скорее всего должен быть собран совместимым с конкретными библиотеками openssl из системы, иначе возможна разница в abi, которая может проявиться не сразу.

Для тестирования или как пример сборки это да.

Кстати, cmake поддерживает cpack - сборку пакетов. Сам я этим не поьзовался.

ps.

COPY CMakeLists.txt .
COPY *.c *.h gost.ec gostsum.1 gost12sum.1 LICENSE .
COPY benchmark/ benchmark/
COPY etalon/    etalon/
COPY libprov/   libprov/
COPY patches/   patches/
COPY tcl_tests/ tcl_tests/
COPY test/      test/ 

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

[kaperusov]

А зачем собирать через Docker?

Ну во-первых это красиво! :) Причин можно много найти, у каждого будут свои соображения, я думаю это не важно. А если посмотреть по issues в проекте, то таких собирателей образов как я, половина пользователей бибилотеки. И каждый раз люди изобретают какие-то свои способы и борятся с одними и теми же проблемами. Собственно, и я с одной из таких пришел в ищью, где уважаемый @chipitsine и предложил PR уже офромить.

Для тестирования или как пример сборки это да.

Есть и продуктивные задачи, где openssl+gost+curl нужные в докере, в кубере и пр...

gost engine dso скорее всего должен быть собран совместимым с конкретными библиотеками openssl из системы, иначе возможна разница в abi, которая может проявиться не сразу.

Мне кажется мы в одном направлении мыслим, только у вас выразить мысль получилось более лаконично.

Кстати, cmake поддерживает cpack - сборку пакетов. Сам я этим не поьзовался.

пупупу... тоже не пользовался, но как бы да, есть разные способы готовки образов без docker buildx, когда-то я пробовал сборку java приложения через Google JIB, интересно, но есть свои особенности. В общем, я бы не стал на них закладываться, по причине малой популярности.

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

В целом - да, COPY . . рабочий вариант и именно с него я начал, на самом деле. Поэтому в проекте добавлен .dockerignore, который сейчас не используется, но я всё равно не стал его удалять, так как посчитал, что лишним он не будет. Наверняка кто-то будет COPY . . для себя пользоваться. А мне не очень нравится, что любой шорох в папке с проектом вызывает у докера полную пересборку. Я пока Makefile свой редактировал устал ждать бесконечный цикл компиляции.

Слоёв в итоге там совсем не много, мне кажется что довольно компактно получилось: