268 lines
No EOL
17 KiB
Markdown
268 lines
No EOL
17 KiB
Markdown
---
|
||
marp: true
|
||
theme: uncover
|
||
paginate: true
|
||
|
||
---
|
||
<!--
|
||
Чтобы сгенерировать из этого файла презентацию в pdf, html или pptx, нужно воспользоваться утилитой Marp https://marp.app/ или одноимённым расширением VSCode https://marketplace.visualstudio.com/items?itemName=marp-team.marp-vscode.
|
||
-->
|
||
# Nix/Nixos
|
||
ОС-независимая сборка пакетов ROS
|
||
|
||
|
|
||
|
||
Брылёв Игорь
|
||
robossembler.org
|
||
|
||
---
|
||
|
||
# Что же такое ROS?
|
||
|
||
<!--
|
||
В сообществе часто спорят по поводу того чем является или не является ROS. ROS звучит буквально как операционная система для роботов, однако де-факто операционной системой не является. Как правило, все сходятся на том, что ROS включает в себя много разных сущностей - это и стандарт, и фреймворк, и формат взаимодействия приложений, и непосредственно программное обеспечение - стандартная библиотека, если хотите. Но конкретно в этом докладе я бы хотел поговорить о ROS в немного другом свете - как о системе сборки и дистрибьюции программного обеспечения, что тоже имеет место быть. Причём этот аспект я считаю весьма важным, потому что почти любое ROS-приложение в среднем на 95% состоит из подгруженного из пакетных репозиториев кода, из которых на долю ROS-экосистемы приходится меньшая часть.
|
||
-->
|
||
|
||
* Стандарт
|
||
* Фреймворк
|
||
* Набор форматов
|
||
* ...
|
||
* Система сборки и дистрибьюции ПО
|
||
---
|
||
|
||
<!--
|
||
Итак метод сборки и дострибьюции пакетов в ROS в значительной опирается на пакетных менеджер apt и пакетные базы debian/ubuntu (по статистике ros index 2100 пакетов представляют собой системные зависимости, предоставляемые операционной системой), а следовательно зависит от них. Многие пакеты ROS-экосистемы представляют в качестве рекомендуемого способа установки именно установку из своих репозиториев собранных заранее бинарных пакетов. Компиляция проектов их исходников редко практикуется и достаточно сложна. В целом, apt свойственны следующие проблемы.
|
||
-->
|
||
|
||
### Проблемы пакетных менеджеров
|
||
|
||
* Апгрейд конфигурации безвозвратно изменяет состояние системы
|
||
* Сборки не детерминированы
|
||
* Не поддерживаются разные версии бинарников и библиотек
|
||
* Конфликты пакетов
|
||
|
||
---
|
||
|
||
#### Проблемы управления зависимостями в ROS
|
||
|
||
* Зависимость от Ubuntu и её системных зависимостей (apt-пакеты)
|
||
* Сложность интеграции с ПО вне ROS-экосистемы
|
||
* Подготовить для удобного запуска сложный ROS-проект - трудоёмкая задача
|
||
|
||
---
|
||
|
||
# Тренды
|
||
|
||
* Из набора библиотек для одного робота ROS становится стандартом для роботизированных кибер-физических систем
|
||
* В робототехнику проникают инструменты из других ниш: web, машинное обучение, DevOps
|
||
|
||
---
|
||
<!--
|
||
Когда рассказываешь про nix часто у инженеров возникает прочная ассциация с Docker. А не решает ли Docker ту же самую проблему? Да, действительно, эти инструменты решают одну и ту же проблему, которую можно было бы кратко сформулировать так
|
||
-->
|
||
# А как же Docker?
|
||
---
|
||
<!--
|
||
С проблемой сталкиваются нууууу почти все - от первой линии службы технической поддержки до программистов. Это проблема состояния окружения - если ваша программа или приложение в какой-то степени опирается на него, то неизбежно будут возникать проблемы с его корректной работы на компьютерах с другим окружением.
|
||
-->
|
||
|
||
|
||
---
|
||
<!-- Как добиться того, чтобы программа запущенная успешно на одном компьютере, была также успешно запущена на другом? Современные проекты представляют собой зачастую сложную комбинацию инструментов, библиотек и обеспечить воспроизводимость в этих условиях непросто. Классическое управление зависимостями в Linux-системах не позволяло добиться хорошей воспроизводимости. Docker появился во многом в ответ на эту проблему плохого управления зависимостями в операционной системе. Как это решил Docker? -->
|
||
|
||
# "В"
|
||
воспроизводимость
|
||
|
||
---
|
||
<!-- Как мы знаем, Docker создаёт своеобразную песочницу вокруг вашего приложения и вы передаёте его вместе с ней, чтобы состояние машины пользователя не влияло на работоспособность. Идеальная картика выглядит так: на входе Dockerfile, на выходе Образ. Вроде всё круто -->
|
||
|
||
# Теория
|
||
Dockerfile -> Image
|
||
|
||
---
|
||
<!-- Но де-факто с одним и тем же докерфайлом вы можете получить кучу разных образов. Почему так происходит? -->
|
||
|
||
# Реальность
|
||
Dockerfile -> Image1 || Image2 ... ImageN
|
||
|
||
---
|
||
<!--
|
||
Если посмотреть вглубь, то можно обнаружить, что в типичном Docker-файле для ROS есть сразу несколько мест, которые сделают вашу сборку невоспроизводимой на другом компьютере:
|
||
1. hub.docker.com
|
||
2. apt-репозиторий
|
||
3. rosdep-репозиторий
|
||
3. файл, взятый по имени
|
||
|
||
Но есть другие недостатки:
|
||
1. Возможность комбинировать зависимости (docker позволяет создавать контейнеры только наследуя от одного базового - нельзя добавить несколько базовых контейнеров)
|
||
2. Необходимость тянуть с собой все зависимости, даже если они представлены в системе
|
||
-->
|
||
|
||
# Типичный Dockerfile для ROS
|
||
FROM ros:foxy-ros-base-focal
|
||
...
|
||
RUN rosdep update && apt-get update
|
||
...
|
||
RUN apk add --no-cache python g++ make
|
||
...
|
||
RUN curl -sSL http://get.gazebosim.org | sh
|
||
...
|
||
CMD [ "ros2", "launch", "app", "app_bringup.launch.py" ]
|
||
---
|
||
<!-- # Что предлагает Nix? -->
|
||
# Ключевая идея nix
|
||
Описывать сборку в виде _чистой функции_ или уравнения(derivation), результат исполнения строго детерминирован входными параметрами.
|
||
|
||
---
|
||
<!-- Именно эта идея и легла в основу диссертации автора nix под названием ___, где как раз и описывались недостатки классической системы использования динамических библиотек в unix-подобных системах. Данный подход получил название декларативным в противовес императивного. -->
|
||
|
||
Eelco Dolstra
|
||
## The Purely Functional Software Deployment Model
|
||
PhD Thesis'2006
|
||
https://edolstra.github.io/pubs/phd-thesis.pdf
|
||
|
||
---
|
||
# Парадигмы программирования
|
||
* Императивная (как?) - C, C++, Java
|
||
* Декларативная (что?) - Lisp, Prolog, Nix
|
||
|
||
---
|
||
<!--
|
||
nix использует функциональный язык программирования для описания процесса сборки. Тут можно сделать некоторое отступление о том, что ROS создан робототехниками для робототехников, а у них по прежнему был и остаётся доминирующим императивный подход к программированию, что обусловлено высокими требованиями к производительности и реальному времени исполнения. Собственно, императивная парадигма распространилась не только на сферу низкоуровневых программ, но и на управление операционной системой. Однако, сфера сборки ПО не требует гарантий реального времени или высокой производительности, в ней куда важнее как раз воспроизводимость, отсутствие неявных обращений к состоянию системы.
|
||
-->
|
||
|
||
# Парадигмы конфигурации
|
||
|
||
* Императивная конфигурация (apt)
|
||
- Изменение состояния (dependency hell, неконсистентные состояния)
|
||
* Декларативная конфигурация (nix)
|
||
- Пакеты = иммутабельные переменные (нельзя изменить напрямую, только через функцию)
|
||
- Одно и то же nix-выражение даёт всегда один и тот же результат
|
||
|
||
---
|
||
<!-- как выглядит типичное Nix-выражение. Это уравнение превращается в такой json-образный файл, где и прописаны все версии с хэшами конкретных зависимостей. Этот файл и является по сути инструкцией или чистой функцией, на выходе которой мы получаем конкретные артефакты в виде пакетов, бинарников, динамических библиотек и т.п. -->
|
||
{
|
||
pname = "hello";
|
||
version = "2.12.1";
|
||
src = fetchurl {
|
||
url = "http://github.com/hello-${version}.tar.bz2";
|
||
sha256 = "0x2g1jqy...";
|
||
};
|
||
buildInputs = [ libbar perl ncurses ];
|
||
buildPhase = ''gcc hello.c -o hello'';
|
||
installPhase = ''mkdir -p $out/bin && cp hello $out/bin'';
|
||
}
|
||
---
|
||
{
|
||
"builder": "/nix/store/561wgc73s0x1250hrgp7jm22hhv7yfln-bash-5.2-p15/bin/bash",
|
||
"env": {
|
||
"builder": "/nix/store/561wgc73s0x1250hrgp7jm22hhv7yfln-bash-5.2-p15/bin/bash",
|
||
"out": "/nix/store/260q5867crm1xjs4khgqpl6vr9kywql1-hello-2.12.1",
|
||
"src": "/nix/store/pa10z4ngm0g83kx9mssrqzz30s84vq7k-hello-2.12.1.tar.gz",
|
||
"stdenv": "/nix/store/b09v23lirgvci3wzszh22mbkdfj0h0yq-stdenv-linux",
|
||
"version": "2.12.1"
|
||
},
|
||
"inputDrvs": {
|
||
"/nix/store/0hnjp6s8k71xm62157v37zg3qzwvl8lx-bash-5.2-p15.drv": [ "out" ],
|
||
"/nix/store/8n3ib41pb90nkq3vv49z520qinf4q9c0-hello-2.12.1.tar.gz.drv": [ "out" ],
|
||
"/nix/store/r2h029bx2fbyxxj84s5hf1abp2vfkah2-stdenv-linux.drv": [ "out" ]
|
||
},
|
||
"inputSrcs": [ "/nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh" ],
|
||
"outputs": {
|
||
"out": { "path": "/nix/store/260q5867crm1xjs4khgqpl6vr9kywql1-hello-2.12.1" }
|
||
},
|
||
"system": "x86_64-linux"
|
||
}
|
||
}
|
||
|
||
---
|
||
<!-- А вот как это выглядит на диске. Заметьте, имя каждого пакета снабжается хэшом, который позволяет избежать коллизий при совпадении имён и даже совпадении имён и версий, а ещё даёт использовать несколько версий библиотеки одновременно. Откуда берётся этот хэш? -->
|
||
|
||
$ ls /nix/store/ | grep humble
|
||
00z4hg8q0cxhsl5jq4s7iq81zz54j8vy-ros-humble-ament-lint-common-0.12.5-r1
|
||
01nvrmwbf0zbchb3d25kb49rl8jzspv6-ros-humble-ament-cmake-cppcheck-0.12.5-r1
|
||
02gdrzn2yrngmqih4hq0j17vj2hgiiz3-ros-humble-unique-identifier-msgs-2.2.1-r3
|
||
08s5gvg7gaypllyxvzd17w21ijqx3hgd-ros-humble-tf2-msgs-0.25.2-r1
|
||
0hwva9zk3250hd6spwq11ayk0aq4flnm-ros-humble-control-msgs-4.1.0-r1
|
||
|
||
---
|
||
<!-- Собственно этот хэш и получается с помощью криптографической хэш-функции применённой ко всем входным зависимостям -->
|
||
|
||
|
||
---
|
||
<!-- Вы не полагаетесь на apt, можете при желании собрать систему полностью из исходников. -->
|
||
|
||
# Что это даёт для ROS?
|
||
|
||
* Возможность запустить проект ROS на любой ОС, даже без apt
|
||
* Контролируемое управление зависимостями
|
||
* Возможность использования разных версий одних и тех же пакетов и библиотек
|
||
* Детерминированные сборки одной командой
|
||
* CACHE!!!
|
||
|
||
---
|
||
<!--
|
||
|
||
-->
|
||
|
||
# Основные компоненты nix
|
||
|
||
* Nix (менеджер пакетов и язык программирования)
|
||
* Nixpkgs (репозиторий пакетов и стандартная библиотека)
|
||
* NixOS (операционная система)
|
||
* NixOps (DevOps инструмент)
|
||
|
||
---
|
||
<!--
|
||
# Текущее состояние nixpkgs -->
|
||
|
||
|
||
|
||
---
|
||
|
||
## Nix ROS Overlay
|
||
https://github.com/lopsided98/nix-ros-overlay
|
||
|
||
Автоматическая генерация nix-выражений для сборки пакетов ROS из официальных репозиториев (github:ros/rosdistro).
|
||
|
||
---
|
||
{ lib, buildRosPackage, fetchurl, ament-cmake ... }:
|
||
buildRosPackage {
|
||
pname = "ros-rolling-std-msgs";
|
||
version = "4.6.1-r1";
|
||
src = fetchurl {
|
||
url = "https://github.com/ros2-gbp/common_interfaces/std_msgs/4.6.1-1.tar.gz";
|
||
name = "4.6.1-1.tar.gz";
|
||
sha256 = "87eee895c2c60a8335ae2a63b05f99773f0897e451e5bf7f45a14a6c36295640";
|
||
};
|
||
|
||
buildType = "ament_cmake";
|
||
buildInputs = [ ament-cmake rosidl-default-generators ];
|
||
checkInputs = [ ament-lint-common ];
|
||
propagatedBuildInputs = [ builtin-interfaces rosidl-default-runtime ];
|
||
nativeBuildInputs = [ ament-cmake rosidl-default-generators ];
|
||
|
||
meta = {
|
||
description = ''A package containing some standard message definitions.'';
|
||
license = with lib.licenses; [ asl20 ];
|
||
};
|
||
}
|
||
---
|
||
|
||
# Недостатки
|
||
|
||
* Пологая кривая обучения
|
||
* Некоторая разрозненность документации
|
||
* Не все пакеты ROS адаптированы в nix
|
||
* Необходимость сборки мусора
|
||
|
||
|
||
---
|
||
# Полезные ресурсы
|
||
|
||
|
||
Русскоязычное сообщество Telegram
|
||
@ru_nixos
|
||
|
||
Туториал для новичков
|
||
zero-to-nix.com |