Що саме є "По-справжньому відтворювані конструкції"?

Які саме вони? Чому вони важливі в галузі безперервної доставки?

Контекст: Я бачив в одному з коментарів (я думаю, що Reddit), що справді відтворювані конструкції все ще є недостатніми технологіями, і це дуже важко створити.

Отже, я хотів знати, чому їх так складно створити?

Які саме вони?

Ось цитата від reproducible-builds.org :

Відтворювані збірки - це набір практик розробки програмного забезпечення, які створюють перевірений шлях від людського читаного вихідного коду до двійкового коду, що використовується комп'ютерами.

Чому вони важливі?

ІМО найпростішим способом пояснити їх важливість є розгляд їх як варіації процедури резервного копіювання.

Як приклад:

• Припустимо бізнес, який використовує (залежить) від певного пакета програмного забезпечення, ліцензованого деяким постачальником програмного забезпечення. Тоді як бізнес отримує лише виконувані файли, а не джерела тощо, які були використані для створення цих файлів.

• Все йде добре, але в якийсь момент щось не вдається з постачальником програмного забезпечення, наприклад, вони припиняють свою діяльність (наприклад, банкрутство).

• Це може становити ризик для бізнесу (у довгостроковій перспективі). Тобто, якщо для бізнесу не існує жодних процедур / угод, щоб отримати (законний) доступ до всіх необхідних джерел, документації, процедур збирання тощо, пов’язаних із чим-небудь від постачальника програмного забезпечення, який використовувався (ще в ті часи), коли виконувані файли (використовуються бізнес) були створені (і відправлені до бізнесу).

• Ось, на допомогу приходить " Програмне забезпечення уникнення ": якщо є така угода, можна подумати, що через третю сторону все-таки бізнес отримає доступ до "того, що було використано " для відтворення виконувані файли, так що з цього моменту бізнес може мати шанс продовжувати користуватися цим програмним забезпеченням, а там, де це підходить, починати підтримувати його самостійно (лише для ведення власного бізнесу).

• Однак " те, що було використано " в попередній кулі, є найскладнішою частиною для цього твору. Це вимагає, щоб третя сторона проводила відповідні перевірки заздалегідь. І повірте, пройде деякий час, перш ніж ви зможете відтворити виконуваний файл, для якого ви зможете довести, що, крім (наприклад) дати посилання, це ідеальна відповідність тому, що постачальник програмного забезпечення постачає програмному агенту.

І чому їх так складно створити?

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

Щоб навести практичний приклад спроби створення справді повторюваної збірки, розглянемо наступне -

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

Перший крок "побудови" після перевірки вихідного коду - це розкручування контейнера, який містить усі залежності часу побудови.

Виведенням запущеного контейнера часу збірки є контейнер, який містить скомпільований двійковий файл.

Більш важливі для повторюваності збірки наступні теги додаються до кінцевого контейнера:

• Точний хеш-код вихідного коду в оригінальному сховищі та URL-адресу як git repo, так і знімка кульки з дьогтем коду, який завантажується у сховище артефактів.
• Точна версія контейнера збірки, яка використовувалася для запуску збірки.
• Точна версія вихідного базового зображення, в яке було завантажено двійковий файл.
• Значення всіх змінних часу нарощування, які використовуються для створення бінарних даних.
• Версія докера, що всі три контейнери, де побудовані, а також версія, де вони працюють, коли вони побудували.

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

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

Важливість цього полягає в тому, що воно дозволяє нам подивитися на те, що працює у виробництві, і, навіть якщо все значно прогресувало версії, повернутися назад і витягнути версію коду, базовий образ і створити спочатку використаний контейнер, щоб ми могли, наприклад, , застосуйте гарячу виправлення до цієї версії перед повторною перебудовою точно так само, як і раніше, щоб ми могли повторно розмістити, знаючи, що це точно той самий артефакт, з єдиною дельтою, яка є гарячим виправленням.