From 7dd0f3f1a897904f46230320161aad2e893280a1 Mon Sep 17 00:00:00 2001 From: movefasta Date: Sun, 19 Feb 2023 13:04:59 +0300 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=20html?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../2023-ros-meetup/ros-meetup-slides.html | 244 ++++++++++++++++++ 1 file changed, 244 insertions(+) create mode 100644 docs/slides/2023-ros-meetup/ros-meetup-slides.html diff --git a/docs/slides/2023-ros-meetup/ros-meetup-slides.html b/docs/slides/2023-ros-meetup/ros-meetup-slides.html new file mode 100644 index 0000000..81bba23 --- /dev/null +++ b/docs/slides/2023-ros-meetup/ros-meetup-slides.html @@ -0,0 +1,244 @@ +
+

Nix/Nixos

+

ОС-независимая сборка пакетов ROS

+

|

+

Брылёв Игорь
+robossembler.org

+
+
+

Что же такое ROS?

+ +
    +
  • Стандарт
    • +
  • Фреймворк
    • +
  • Набор форматов
    • +
  • ...
    • +
  • Система сборки и дистрибьюции ПО
    • +
+
+
+

Проблемы пакетных менеджеров

+
    +
  • Апгрейд конфигурации безвозвратно изменяет состояние системы
    • +
  • Сборки не детерминированы
    • +
  • Не поддерживаются разные версии бинарников и библиотек
    • +
  • Конфликты пакетов
    • +
+
+
+

Проблемы управления зависимостями в ROS

+
    +
  • Зависимость от Ubuntu и её системных зависимостей (apt-пакеты)
    • +
  • Сложность интеграции с ПО вне ROS-экосистемы
    • +
  • Подготовить для удобного запуска сложный ROS-проект - трудоёмкая задача
    • +
+
+
+

Тренды

+
    +
  • Из набора библиотек для одного робота ROS становится стандартом для роботизированных кибер-физических систем
    • +
  • В робототехнику проникают инструменты из других ниш: web, машинное обучение, DevOps
    • +
+
+
+

А как же Docker?

+
+
+

+
+
+

"В"

+

воспроизводимость

+
+
+

Теория

+

Dockerfile -> Image

+
+
+

Реальность

+

Dockerfile -> Image1 || Image2 ... ImageN

+
+
+

Типичный 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

+

Описывать сборку в виде чистой функции или уравнения(derivation), результат исполнения строго детерминирован входными параметрами.

+
+
+


+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
    • +
+
+
+

Парадигмы конфигурации

+
    +
  • Императивная конфигурация (apt) +
      +
    • Изменение состояния (dependency hell, неконсистентные состояния)
      • +
    +
    • +
  • Декларативная конфигурация (nix) +
      +
    • Пакеты = иммутабельные переменные (нельзя изменить напрямую, только через функцию)
      • +
    • Одно и то же nix-выражение даёт всегда один и тот же результат
      • +
    +
    • +
+
+
{
+    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
+
+
+
+

+
+
+

Что это даёт для ROS?

+
    +
  • Возможность запустить проект ROS на любой ОС, даже без apt
    • +
  • Контролируемое управление зависимостями
    • +
  • Возможность использования разных версий одних и тех же пакетов и библиотек
    • +
  • Детерминированные сборки одной командой
    • +
  • CACHE!!!
    • +
+
+
+

Основные компоненты nix

+
    +
  • Nix (менеджер пакетов и язык программирования)
    • +
  • Nixpkgs (репозиторий пакетов и стандартная библиотека)
    • +
  • NixOS (операционная система)
    • +
  • NixOps (DevOps инструмент)
    • +
+
+
+

+
+
+

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

+
+

Чтобы сгенерировать из этого файла презентацию в pdf, html или pptx, нужно воспользоваться утилитой Marp https://marp.app/ или одноимённым расширением VSCode https://marketplace.visualstudio.com/items?itemName=marp-team.marp-vscode.

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

Итак метод сборки и дострибьюции пакетов в ROS в значительной опирается на пакетных менеджер apt и пакетные базы debian/ubuntu (по статистике ros index 2100 пакетов представляют собой системные зависимости, предоставляемые операционной системой), а следовательно зависит от них. Многие пакеты ROS-экосистемы представляют в качестве рекомендуемого способа установки именно установку из своих репозиториев собранных заранее бинарных пакетов. Компиляция проектов их исходников редко практикуется и достаточно сложна. В целом, apt свойственны следующие проблемы.

Когда рассказываешь про nix часто у инженеров возникает прочная ассциация с Docker. А не решает ли Docker ту же самую проблему? Да, действительно, эти инструменты решают одну и ту же проблему, которую можно было бы кратко сформулировать так

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

Как добиться того, чтобы программа запущенная успешно на одном компьютере, была также успешно запущена на другом? Современные проекты представляют собой зачастую сложную комбинацию инструментов, библиотек и обеспечить воспроизводимость в этих условиях непросто. Классическое управление зависимостями в Linux-системах не позволяло добиться хорошей воспроизводимости. Docker появился во многом в ответ на эту проблему плохого управления зависимостями в операционной системе. Как это решил Docker?

Как мы знаем, Docker создаёт своеобразную песочницу вокруг вашего приложения и вы передаёте его вместе с ней, чтобы состояние машины пользователя не влияло на работоспособность. Идеальная картика выглядит так: на входе Dockerfile, на выходе Образ. Вроде всё круто

Но де-факто с одним и тем же докерфайлом вы можете получить кучу разных образов. Почему так происходит?

Если посмотреть вглубь, то можно обнаружить, что в типичном Docker-файле для ROS есть сразу несколько мест, которые сделают вашу сборку невоспроизводимой на другом компьютере: +1. hub.docker.com +2. apt-репозиторий +3. rosdep-репозиторий +3. файл, взятый по имени + +Но есть другие недостатки: +1. Возможность комбинировать зависимости (docker позволяет создавать контейнеры только наследуя от одного базового - нельзя добавить несколько базовых контейнеров) +2. Необходимость тянуть с собой все зависимости, даже если они представлены в системе

# Что предлагает Nix?

Именно эта идея и легла в основу диссертации автора nix под названием ___, где как раз и описывались недостатки классической системы использования динамических библиотек в unix-подобных системах. Данный подход получил название декларативным в противовес императивного.

nix использует функциональный язык программирования для описания процесса сборки. Тут можно сделать некоторое отступление о том, что ROS создан робототехниками для робототехников, а у них по прежнему был и остаётся доминирующим императивный подход к программированию, что обусловлено высокими требованиями к производительности и реальному времени исполнения. Собственно, императивная парадигма распространилась не только на сферу низкоуровневых программ, но и на управление операционной системой. Однако, сфера сборки ПО не требует гарантий реального времени или высокой производительности, в ней куда важнее как раз воспроизводимость, отсутствие неявных обращений к состоянию системы.

как выглядит типичное Nix-выражение. Это уравнение превращается в такой json-образный файл, где и прописаны все версии с хэшами конкретных зависимостей. Этот файл и является по сути инструкцией или чистой функцией, на выходе которой мы получаем конкретные артефакты в виде пакетов, бинарников, динамических библиотек и т.п.

А вот как это выглядит на диске. Заметьте, имя каждого пакета снабжается хэшом, который позволяет избежать коллизий при совпадении имён и даже совпадении имён и версий, а ещё даёт использовать несколько версий библиотеки одновременно. Откуда берётся этот хэш?

Собственно этот хэш и получается с помощью криптографической хэш-функции применённой ко всем входным зависимостям

Вы не полагаетесь на apt, можете при желании собрать систему полностью из исходников.

# Текущее состояние nixpkgs

\ No newline at end of file