Email or username:

Password:

Forgot your password?
AkhIL

Дальнейшая разработка #tinkerbox становиться ещё интереснее.

Предположим образы (images) podman у нас будут играть роль снимков состояния контейнера. Тогда неизменность контейнеров podman можно обыграть на пользу контейнеров как среды разработки.

Пользователь получает возможность делать снимки состояния контейнера, под капотом делается обычный `podman commit`. Для отката мы удаляем поломанный контейнер и разворачивается точно такой же на базе сделанного ранее, при помощи commit, образа.

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

Новые контейнеры можно создавать не только на основе базовых образов, но и на базе сделанных снимков.

Можно использовать pdoman commit --squash, что бы не плодить образы.

7 comments
chipsetsv

@akhil, а какова целевая модель использования инструмента? Можно на примере?
Я просто пока не догоняю киллерфичи инструмента)

AkhIL

@chipsetsv Для разработки софта нужно устанавливать в систему всякие утилиты и библиотеки. При том для разных проектов этот набор разный. Кроме того обновление библиотек, на ранних этапах разработки, добавляет суеты по адаптации кода. Например обновление python иногда ломает виртуальные окружения.

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

#Tinkerbox - утилита использующая #podman для управления контейнерами как средами разработки. В отличае от #distrobox и #toolbox, tinkerbox по умолчанию максимально изолирован, и не предоставляет процессам в контейнере полный доступ к файлам хоста, минимизируя последствия toolchain атак.

@chipsetsv Для разработки софта нужно устанавливать в систему всякие утилиты и библиотеки. При том для разных проектов этот набор разный. Кроме того обновление библиотек, на ранних этапах разработки, добавляет суеты по адаптации кода. Например обновление python иногда ломает виртуальные окружения.

При помощи контейнеров можно вести разработку изолированно от хостовой системы. Контейнер можно не обновлять не опасаясь уязвимостей. В каждый контейнер можно устанавливать свои версии утилит и библиотек,...

chipsetsv

@akhil, вот эт спасибо за основательный ответ)
Преимущества контейнеризации понятны) интересно было вот как раз узнать про преимущества именно этой тулзы.
Ибо distribox и похожим пока чот пользоваться ещё не приходилось. Изолированность - это хорошо, но вроде ж по дефолту и так контейнеры изолированы?

AkhIL

@chipsetsv distrobox и toolbox монтируют корень хоста в /var/host и всю домашнюю директорию для обеспечения интеграции с хостом и рабочим столом. Моя утилита жертвует интеграцией ради изоляции. Проброс шины, графики и звука по умолчанию отключены, и при включении монтируется только необходимый минимум, что бы работало.

chipsetsv

@akhil, понял-принял) спсб)

ርዐነጠዐነቿረቻ

@akhil А Devbox пробовал для локальной разработки?
github.com/jetpack-io/devbox

AkhIL

@cosmoself Devbox, на первый взгляд, не даёт изоляции и привязан к Nix. Моя утилита работает с привычными мне debian, ubuntu, fedora, opensusе, arch и alpine. Совместимость с NixOS можно добавить, но я его не умею.

Go Up