`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

µScalpel (автоматическая трансплантация), и пара слов о Docker

+55
голосов

«Повторное использование кода» - замечательная в теории и на удивление сложная в практической реализации, идея. На более приземлённых уровнях практических подходов эта идея реализуется от проектирования на основании критерия «пригодности к повторному использованию» (что даже на бумаге бесчисленных тематических книг выглядит далеко не просто, и, тем более, не универсально) до всевозможных пост-проектных, «работающих» на этапе жизненного цикла ПО, методологий (выявления фрагментов с клонированной функциональностью, миграции и утилизации кода, анализа зависимостей, техник выделения деталей-features).

Всё это на деле – не инструменты, а, чаще всего, даже не пригодные для разработки инструментария (то есть, не формализуемые) «подходы».

Если говорить об этапе жизненного цикла ПО, можно сформулировать задачу «повторного использования кода» следующим образом – из кода программной системы-донора таким образом выделить завершённый его фрагмент (или множество фрагментов как завершённое целое), чтобы, дополнив им целевой код, расширить его функциональность.

В Университетском колледже Лондона (UCL, University College London) попробовали решить эту задачу до уровня работающего инструмента. И получили пусть пока ограниченный в возможностях (в первую очередь, в языке реализации системы-донора и целевой системы, им может быть только С), но подтверждённо работающий инструмент.

Так, одной из тестовых задач было автоматическое выделение кода кодека H.264 из большой и далеко не новой библиотеки x264 для дополнения функциональности известного плейера VLC. Задача была решена в полностью автоматическом режиме за 26 часов машинного времени. На эту же работу «вручную» программистам необходимо минимум 20 полных рабочих дней.

Эта задача интересна даже на уровне мотивации – казалось бы, зачем что-то делать с кодом библиотеки, по сути реализующей требуемое? Проблема в разных проектных темпах (к слову, характерная для open source разработки) –за 11 лет x264 претерпела 39 фундаментальных модификаций, изменяющих API. При затратах 20 рабочих дней на каждую ручную «трансплантацию» кода x264 в код VLС, только эта процедура «выедает» больше трёх лет непрерывного труда. Кроме того, автоматическая трансплантация кода «очищает» оригинальную библиотеку от более чем 47% избыточного кода (ни для кого не секрет, что избыточный код – это источник потенциальных опасностей и уязвимостей).

Лаконично и высокоуровнево суть «автоматической трансплантации» можно описать так: постановщик задачи находит в коде-доноре точку входа в подсистему, реализующую требуемую функциональность, определяет аналогичную точку входа в коде целевой системы, точно формулирует интерфейс и разрабатывает систему тестов, позволяющих определить и подтвердить «завершённость пересадки».

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

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

Алгоритм µTrans и его инструментальная реализация µScalpel эту фантастику превращают в реальность. Принципиальная работоспособность µScalpel пока подтверждена пятнадцатью экспериментами, двенадцать из которых оказались успешными «трансплантациями» из пяти «донорских» программ в три целевые (все использованные для этого программы – реальные, а не учебные или специально разработанные).

С другой стороны, внимательный читатель уже должен был заметить в самом высокоуровневом описании «автоматической трансплантации» слова «программист точно формулирует интерфейс и разрабатывает систему тестов». Их достаточно для понимания очевидного – даже овеществлённая на первый взгляд фантастика никакого отношения к магии не имеет.

Насколько хорошо программистом решены эти задачи (и решаемы ли они вообще в конкретном случае), настолько хорошим будет результат «трансплантации».

Следовательно, фундаментальную функциональность трансплантируемого кода-органа всё равно надо превосходно знать, код «донора», так и целевой программы тоже, до детального понимания потребностей на уровне формализации API и набора тестов. Эти задачи, конечно же, не автоматизируются. А, так как они крайне нетривиальны, то и для реального «боевого» применения µScalpel очень легко отыскать нишу. Аналогичную ситуации разработчиков VLC – в случаях трансплантации кода из долгоживущей системы с несовпадающей с целевым проектом скоростью развития. В таких случаях есть смысл затратить усилия на освоение очень специфического инструмента, на глубокий анализ и разработку серьёзной системы тестов. Как видно из опыта разработчиков VLC, эти затраты времени окупаются.

Глубже погружаться не будем. µScalpel – проект открытый (включая исходные тексты, конечно), весьма неплохо документированный и требующий де-факто стандартной рабочей станции Linux (64-битовой с не менее чем 16 GB RAM). Для удобства развёртывания разработчики предусмотрели и готовые Docker-образы. Так что можно пробовать. Очень интересная разработка (и хорошо, что удалось избежать упоминаний «искусственного интеллекта», несмотря на использование в µTrans весьма хитрого генетического алгоритма; ничего общего с «интеллектом» это, конечно же, не имеет).

Теперь пара слов о Docker.

Новая версия (1.8) даёт администраторам и деплой-инженерам очень важный инструмент безопасности, которого многие ждали. DCT, Docker Content Trust, «вписана» в систему так, что на уровне команд (и скриптов) её практически нет – всё остаётся так же, как было (что особенно ценно). Но при этом появляются двухключевая защита репозиториев (один ключ для одного владельца репозиториев – оффлайн, второй, точнее, семейство ключей – экспортируемые маркировочные, tagging ключи), расширенные средства подтверждения подлинности содержимого образов, и в результате – защита от всевозможных злонамеренных действий, как-то – от компрометации ключей, подделки образов и атак повторного воспроизведения (replay attacks).

В общем, тоже не буду вдаваться в детали, кому они интересны и нужны – самостоятельно разберутся, прочим же, кто просто слышал и интересуется Docker, могу сказать, что система за этот год набрала невероятную скорость развития и с введением серьёзной системы безопасности становится полноценным и очень опасным «врагом», например, виртуальных машин и гипервизоров (особенно если учесть растущую заинтересованность компаний в простых и реально работающих механизмах развёртывания ПО).

Откланиваюсь

+55
голосов

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT