Terrarium Assembler — эффективные сборка и распространение высокотехнологичных Python-приложений под различные операционные системы (Стас Фомин, OSSDEVCONF-2021) — различия между версиями

К 2020 году, исполнилось 30 лет языку Python, и при этом он стал самым популярным языком в рейтинге TIOBE. За это время, Python, идеальный язык для обучения, рожденный как язык для обучения от уровня младших школьников, стал использоваться профессионалами во всех областях, как в программировании, так и в куче научных областей — будь то астрономия, биоинформатика, статистика… везде.

Можно долго рассуждать о причинах такого успеха — повлиял ли простой синтаксис, понимаемый не только профессиональными разработчиками, но и любым неглупым пользователем, «дзен питона», ориентированный не на удобство компьютера, а пользователя, максимальная простота и читаемость, удобство для пользователя в разработке и отладке, выбирались при любых инженерных дилеммах построения языка. Но это неважно, а важно то, что сейчас Python — самый удобный язык, по крайней мере для прототипирования и разработки высокотехнологических приложений, ибо сейчас в нем есть «батарейки» практически для всех областей научной разработки:

• Криптография

• Символическая алгебра — sympy

• Линейная алгебра — numpy

• Алгоритмы оптимизации — cvxopt, or-tools

• Машинное зрение — opencv

• Artificial Intelligence и Machine Learning — torch, keras, catboost, xgboost, h2o…

Если раньше, для разработки и прототипирования новых алгоритмов нужно было прибегать к использованию специализированных «пакетов для математиков» — систем типа Mathematica, Mathcad, Mapple и т.п., с переписыванием их для реального использования на языки промышленной разработки (C/C++/Java), то сейчас, разработку новых алгоритмов принято вести на Python, причем заменяя или дополняя привычные «статьи с псевдокодом», алгоритмы в которых невозможно проверить и исследовать без реализации, на Jupyter-ноутбуки, являющиеся гибридами чередующегося текста, формул, и работающего и проверяемого кода на Python, выдающего верифицируемые графики и визуализации.

Более того, движениеpaperswithcode.com, и множество статей практически констатирует текущий кризис воспроизводимости научных результатов, призывает, чтобы все научные результаты были в таком формате.

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

Да, сам интерпретатор Python существует практически под все платформы и операционные системы, и потенциально, многие вообще не видят проблем — ну вот, код на Python — «почему бы ему не работать на всем, от привычных x86 до ARMов, MIPSов и Эльбрусов, от древних версий Windows, до сертифицированных российских линуксов?».

К сожалению, с этим все непросто:

• Базовый интерпретатор Python, как правило да, есть везде.

• Но вот сборка всех необходимых стеков Python-модулей — серьезная проблема, по крайней мере, для старых версий Windows и малораспространенных линукс-дистрибутивов (к которым относятся и российские сертифицированные линукс-дистрибутивы), пакетная база которых в десятки раз меньше, чем у популярных дистрибутивов с большим сообществом майнтейнеров (Fedora-Debian-Ubunta), а используемые базовые библиотеки серьезно устарели, так, что собрать современный прикладной стек поверх них попросту невозможно.

• Попытка сделать «единый дистрибутив пакет», с минимумом вариаций (windows/linux), не сильно менее проста, особенно в связи с слабой обратной бинарной совместимостью (libc, ld.so) линуксов, и отсутствием поддержки в старых сертифицированных линуксах технологий изоляции и контейнеризации (docker/flatpack/snapd), которые могли бы эту проблему решить.

Отдельно, стоит проблема сохранения интеллектуальной собственности. Конечно, open-source и открытость научных результатов — это прекрасно. «Если у вас есть идея, и у нас есть идея — то обменявшись — у нас будет две идеи» — говорят сторонники открытости. Однако, это работает не всегда — если мы обменяемся секретами, то секреты просто исчезнут.

В ряде случаев, особенно, когда речь идет про информационную безопасность, несмотря на то, что «Security by Obscurity» сам по себе не является надежным принципом для ИБ, это может создавать дополнительный уровень защиты — при условии, разумеется, применения всех остальных принципов надежной и верифицируемой разработки. Не говоря уже, о конкурентном преимуществе вашего решения, которое может быть даже в наборе некоторых констант и небольших улучшений к известным алгоритмам, но найденных вами в результате тяжелых лет исследований.

Вот тут, увы, у Python все было не очень хорошо. Да, существовали методы получения скомпилированных утилит из Python кода, таких как Py2exe, PyInstaller, и т.п., но все они по сути, «зашивали» в выполняемый файл готовый интерпретатор питона, и байт-код скомпилированных python-библиотек. Декомпилировать все это, несмотря на некоторые возможные методы обфускации — задача увы, технически простая (см. decompile6)

И так получилось, что в ходе одного из проектов ИСПРАН, возникла необходимость разработки решения, в области борьбы с утечками данных, для которого:

• Не существовало хороших известных решений.

• Разрабатываемые новые алгоритмы активно используют алгоритмы компьютерного зрения, распознавания текста, AI/ML и т.п. — по вышеуказанным причинам, никакой другой стек (С++, Go, Rust… ) не позволил бы эффективную разработку таких алгоритмов непосредственно с обкаткой и сбором обратной связи от заказчика.

• Решение должно выкатываться на сотни тысяч компьютеров, и множество операционных систем, как правило различные 32-битные и 64-битные версии Windows, и 64-битные сертифицированные линуксы, разных версий и вендоров (Astra Linux, ALT Linux) и т.п, содержало клиентскую и серверную часть.

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

• Но при этом, решение должно пройти сертификацию в специализированной лаборатории, и поэтому, должна существовать простая и автоматизированная система сборки, где все артефакты — код, библиотеки, можно было бы проследить, проанализировать на уязвимости и недокументированные возможности.

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

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

Для решения этих задач, был реализован комплекс управления сборкой Terrarium Assembler, с версиями под Linux и Windows, и другие вспомогательные проекты, которые были опубликованы в open-source.

В докладе, мы рассмотрим вышеупомянутые проблемы, технологические дилеммы, и наши решения более подробно.