Что такое «действительно воспроизводимые сборки»?

Что именно они? Почему они важны в области непрерывной доставки?

Контекст: я видел в одном из комментариев (я полагаю, Reddit), что сборки Truly Reproducible все еще не изучены, и их очень сложно создать.

Итак, я хотел знать, почему их так сложно создать?

Что именно они?

Вот цитата из reproducible-builds.org :

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

Почему они важны?

ИМО Самый простой способ объяснить их важность - это рассмотреть их как вариант процедуры резервного копирования.

Например:

• Предположим, что бизнес использует (зависит) от некоторого программного пакета, лицензированного у какого-либо поставщика программного обеспечения. Принимая во внимание, что бизнес получает только исполняемые файлы, а не источники и т. Д., Которые использовались для создания этих исполняемых файлов.

• Все идет хорошо, но в какой-то момент что-то идет не так с поставщиком программного обеспечения, например, они разоряются (например, банкротство).

• Это может представлять риск для бизнеса (в долгосрочной перспективе). Т.е. если не существует процедуры / соглашения для бизнеса, чтобы получить (легальный) доступ ко всем необходимым источникам, документации, процедурам сборки и т. Д., Связанным с чем-либо от поставщика программного обеспечения, используемого (в те времена), когда исполняемые файлы (используемые бизнес) были созданы (и отправлены в бизнес).

• Вот тут-то и приходит на помощь « Software Escrow »: если будет достигнуто такое соглашение, можно подумать, что через третье лицо у бизнеса все равно будет возможность получить доступ к « всему, что использовалось », чтобы иметь возможность воспроизвести исполняемые файлы, так что с этого момента у бизнеса может появиться шанс продолжить использовать это программное обеспечение и, где это уместно, начать поддерживать его самостоятельно (только для ведения собственного бизнеса).

• Тем не менее, « все, что использовалось » в предыдущем пункте, является самой сложной частью, чтобы сделать эту работу. Это требует, чтобы третье лицо выполнило соответствующие проверки заранее. И поверьте мне, требуется некоторое время, прежде чем вы сможете воссоздать исполняемый файл, для которого вы можете доказать, что, помимо (например) даты ссылки, он идеально соответствует тому, что поставщик программного обеспечения предоставляет программному агенту.

И почему их так сложно создать?

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

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

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

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

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

Более важно для повторяемости сборки следующие теги добавляются в окончательный контейнер:

• Точный хэш исходного кода в исходном репозитории и URL-адрес как репозитория git, так и снимка tar-шара кода, загруженного в репозиторий артефактов.
• Точная версия контейнера сборки, которая использовалась для запуска сборки.
• Точная версия исходного базового образа, в который был загружен бинарный файл.
• Значения всех переменных времени сборки, используемых для создания двоичного файла.
• Версия докера, в которой были собраны все три контейнера, а также версия, в которой они работали.

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

Теоретически это должно дать нам возможность точно воспроизводить версию сборки.

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