D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Приветствую всех: дамы, господа, друзья и недруги. Сегодня пофантазируем /поговорим о использовании контейнеров вместо VM для работы. А так же раздуем за систему мечты.
Подготовлено: ValeraSnowdrop
Специально для: xss.is
Уведомление
Важно отметить что я не являюсь экспертом в вопросе что я поднимаю и могу ошибаться в своих суждениях. Просьба к читающим: при нахождении какой либо ошибки/несостыковки/глупости оставьте комментарий под этой темой или напишите мне в PM. Давайте учиться вместе. Спасибо.
Терминология
Итак для начала определимся с терминами что будут использованы в статье. Часть терминов может считаться не общепризнанными но все равно будут использованы в рамках этой статьи.
Система для работы (System for work)
Набор программного обеспечения которое позволяет эффективно выполнять возложенные не нее обязательства в рамках набора требований. Для удобства использования этот термин может быть использован для описания хост системы и набора кубов вместе.
Хост система (host system)
Физическое устройство на котором находится программное обеспечение. В качестве примера можно привести laptop/desktop.
Куб (qube)
Один и более виртуальных машин или контейнеров изолированных от хост системы. Каждый куб выполняет свой набор задач и может отличаться от других кубов. Тут важно отметить что это именно набор из контейнеров.
Так например container-A (с ПО: браузер и firewall) и container-B (tor для container-A) могут вместе образовывать куб (назовем его person1).
Контейнер (container)
Контейнер в общем понимании. Можно использовать в том же виде, что используется в контексте docker'а.
Виртуальная машина (VM)
Виртуальная машина в общем понимании. Можно использовать в том же виде, что используется в контексте qemu/virutalbox/vmware.
Образ (image)
Образ операционной системы в общем понимании. Может использоваться и как (образ для VM) и как (образ для контейнера).
Теория
Теперь перейдем к основным требованиям и проблемам что я пытаюсь решить в рамках этой статьи.
Проблемы
Требования
Практика
Архив
Итак если я все сделал правильно, то на руках у вас будет архив с таким содержимым (исключая папки @nonroot и root они появятся после первого запуска):
Мне нужно объяснить происходящее здесь.
Перед запуском
Зависимости
Список необходимых пакетов установленных в системе (linux):
X11
Перед началом работ нам нужно изменить несколько файлов, чтобы запустить контейнер, а именно docker-compose.yml и scripts/run.sh, в зависимости от используемой хост системы вам нужна поддержка X11 либо Wayland. По умолчанию влючен именно Wayland, если вы используете X11 то необходимо в файле docker-compose.yml изменить эти строки:
Для работы в X11 так же нужно включить поддержку X11Forwarding, как это сделать вы можете почитать в info.txt. Необходимо изменить эти строки в /etc/ssh/sshd_config
Bash: Скопировать в буфер обмена
Подробнее можете узнать тут: https://www.baeldung.com/linux/docker-container-gui-applications
Так же вам нужно убрать коммент в файле scripts/run.sh
Важно отметить что при работе X11 вы будете видеть input-lag в 50-80мс на глаз. Так же нужно сказать что я давно не проверял и не могу сейчас проверить работу в X11. И гайд может вовсе не работать с X11 даже после того, что я описал выше.
Wayland
Работает по умолчанию, нет необходимости в дополнительных действиях. Важно отметить что я проверил работу только в DE: gnome(wayland session) и hyprland. Работает без ошибок.
Автозапуск
Контейнер при запуске будет запускать файл /deps/autostart.sh который копируется при установке из _deps/autostart.sh, Давайте взглянем на него:
По умолчанию в контейнере будет запущен ufw/gufw firewall который не даст ликнутся вашему ip. на 22/23 строчках установлен killswitch, тут вы можете указать ip куда может обращаться ваш контейнер.
В контейнере по умолчанию так же установлен nekoray который я использую для тунелирования трафика всей системы. Его запуск объявлен на 27 строке.
Hardering
Допил/настройка под вас делается через Dockerfile и docker-compose.yml. Как с ними работать я расписывать не буду, для этого есть dockументация docker, куда я вас направляю. С файлами в папке _deps вы так же можете ознакомиться самостоятельно.
Стартуем
Запускаем scripts/run.sh и если вы все выполнили правильно, у вас должна начаться установка образа archlinux и всего что вы понаписали в Dockerfile. После 10 минут томления у вас должно открыться подобное окно:
Выбираем Xray и подрубаем сюда ваш vpn, как пользоваться nekoray думаю не нужно описывать. Или стоит?
После этого я обычно запускаю ./scripts/app.sh xfce4-terminal
А из него уже стартую любое нужное мне ПО.
Вот например librewolf
Остановить эту чудо-машину можно через ./scripts/stop.sh
Я проверил работу этого ПО (все работает):
Заключение
В заключение приведу набор плюсов и минусов такого подхода.
Плюсы:
Отдельное спасибо ребятам из этого топика: https://xss.is/threads/113716/
Подготовлено: ValeraSnowdrop
Специально для: xss.is
Уведомление
Важно отметить что я не являюсь экспертом в вопросе что я поднимаю и могу ошибаться в своих суждениях. Просьба к читающим: при нахождении какой либо ошибки/несостыковки/глупости оставьте комментарий под этой темой или напишите мне в PM. Давайте учиться вместе. Спасибо.
Терминология
Итак для начала определимся с терминами что будут использованы в статье. Часть терминов может считаться не общепризнанными но все равно будут использованы в рамках этой статьи.
Система для работы (System for work)
Набор программного обеспечения которое позволяет эффективно выполнять возложенные не нее обязательства в рамках набора требований. Для удобства использования этот термин может быть использован для описания хост системы и набора кубов вместе.
Хост система (host system)
Физическое устройство на котором находится программное обеспечение. В качестве примера можно привести laptop/desktop.
Куб (qube)
Один и более виртуальных машин или контейнеров изолированных от хост системы. Каждый куб выполняет свой набор задач и может отличаться от других кубов. Тут важно отметить что это именно набор из контейнеров.
Так например container-A (с ПО: браузер и firewall) и container-B (tor для container-A) могут вместе образовывать куб (назовем его person1).
Контейнер (container)
Контейнер в общем понимании. Можно использовать в том же виде, что используется в контексте docker'а.
Виртуальная машина (VM)
Виртуальная машина в общем понимании. Можно использовать в том же виде, что используется в контексте qemu/virutalbox/vmware.
Образ (image)
Образ операционной системы в общем понимании. Может использоваться и как (образ для VM) и как (образ для контейнера).
Теория
Теперь перейдем к основным требованиям и проблемам что я пытаюсь решить в рамках этой статьи.
Проблемы
- Производительность. Как вы уже знаете использование VM это очень дорого в плане ресурсов компьютера. На средненьком ноутбуке за 400-500$ дай бог поднять хотя бы одну VM не говоря уже об использовании нескольких. Даже при условии что у вас действительно мощный компьютер задержку ввода никто не отменял, из-за чего падает удобство работы с такой системой, она становится неотзывчивой.
- Переносимость. Так же есть проблемы с переносом данных с такой системы. Так например чтобы получить какие либо данные с VM на хост нужно их скопировать, что само по себе является дублированием данных, так еще и при больших объемах может занимать значительное время.
- Переиспользование. Вы можете обменяться VM образом с другим человеком и он получит копию системы со всеми вашими конфигами (если вы не очистили их заранее), включая директорию /home, хотелось бы избежать такого поведения по умолчанию. Так же можем представить случай создания новой VM на основе старой. В таком случае вам прийдется удалять софт который не нужен в новой VM в ручном режиме и чистить от конфигов образ, либо тратить около 20 минут на установку новой голой системы, без учета времени скачивания .iso образа и ее настройки. Учитывая все эти проблемы не удивительно что мы не видим образов которыми люди делятся на форуме не опасаясь утечки данных.
- Изоляция. Как вы можете предположить изоляция в случае работы с docker ниже по сравнению с VM. Тем самым вы подвергаете себя большему риску при использовании контейнеров. Попробуем снизить этот вектор атаки в рамках статьи
Требования
- Высокая скорость работы. Желательно на около-любом железе. Отсутствие каких либо задержек при работе с кубом.
- Возможность создания бекапов и переноса блоков информации. Тут важно подметить что важна возможность переноса именно блоков данных, а не всех данных сразу. Зачастую вам не нужны в бекапе системные папки и прочий шлак установленный вместе с пакетами.
- Возможность поделится конфигом вашей системы с другим человеком. Переиспользование вашего куба для создания нового на его основе.
- Открытость. Возможность управления такой системой. Возможность отключения некоторых компонентов системы.
- Использование средств анонимности vpn/tor/proxy для всей системы, либо как прокси для отдельных приложений. А так же возможность использования их вместе. Тобишь создание цепочек.
- Изоляция личностей созданных в рамках системы (под личностями вполне конкретно можно понимать набор виртуальных личностей). Программные средства призванные защитить смешение/пересечение этих личностей.
- Достаточный уровень безопасности. Чтобы взломанный контейнер не мог значительно повлиять на хост. Желательно чтобы не мог оказать вообще никакого влияния.
Практика
Архив
Итак если я все сделал правильно, то на руках у вас будет архив с таким содержимым (исключая папки @nonroot и root они появятся после первого запуска):
Мне нужно объяснить происходящее здесь.
- Все *.sh скрипты в директории scripts отвечают за управление этим чудом (кубом)
- В Dockerfile и docker-compose.yml происходит настройка куба
- Директории начинающиеся на @, то есть root и @nonroot это volume docker'a в которых содержится 2 домашних папки пользователя root и nonroot соответственно.
- Директория _deps отвечает за софт который необходим для создания контейнера, его использование описано в Dockerfile
- Файл info.txt содержит пояснение для X11
Перед запуском
Зависимости
Список необходимых пакетов установленных в системе (linux):
- docker
- docker-compose
- xorg-xhost (только при использовании X11)
X11
Перед началом работ нам нужно изменить несколько файлов, чтобы запустить контейнер, а именно docker-compose.yml и scripts/run.sh, в зависимости от используемой хост системы вам нужна поддержка X11 либо Wayland. По умолчанию влючен именно Wayland, если вы используете X11 то необходимо в файле docker-compose.yml изменить эти строки:
Для работы в X11 так же нужно включить поддержку X11Forwarding, как это сделать вы можете почитать в info.txt. Необходимо изменить эти строки в /etc/ssh/sshd_config
Bash: Скопировать в буфер обмена
Код:
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
$ echo change this lines:
$ sudo vim /etc/ssh/sshd_config
X11Forwarding yes
X11UseLocalhost noТак же вам нужно убрать коммент в файле scripts/run.sh
Важно отметить что при работе X11 вы будете видеть input-lag в 50-80мс на глаз. Так же нужно сказать что я давно не проверял и не могу сейчас проверить работу в X11. И гайд может вовсе не работать с X11 даже после того, что я описал выше.
Wayland
Работает по умолчанию, нет необходимости в дополнительных действиях. Важно отметить что я проверил работу только в DE: gnome(wayland session) и hyprland. Работает без ошибок.
Автозапуск
Контейнер при запуске будет запускать файл /deps/autostart.sh который копируется при установке из _deps/autostart.sh, Давайте взглянем на него:
По умолчанию в контейнере будет запущен ufw/gufw firewall который не даст ликнутся вашему ip. на 22/23 строчках установлен killswitch, тут вы можете указать ip куда может обращаться ваш контейнер.
В контейнере по умолчанию так же установлен nekoray который я использую для тунелирования трафика всей системы. Его запуск объявлен на 27 строке.
Hardering
Допил/настройка под вас делается через Dockerfile и docker-compose.yml. Как с ними работать я расписывать не буду, для этого есть dockументация docker, куда я вас направляю. С файлами в папке _deps вы так же можете ознакомиться самостоятельно.
Стартуем
Запускаем scripts/run.sh и если вы все выполнили правильно, у вас должна начаться установка образа archlinux и всего что вы понаписали в Dockerfile. После 10 минут томления у вас должно открыться подобное окно:
Выбираем Xray и подрубаем сюда ваш vpn, как пользоваться nekoray думаю не нужно описывать. Или стоит?
После этого я обычно запускаю ./scripts/app.sh xfce4-terminal
А из него уже стартую любое нужное мне ПО.
Вот например librewolf
Остановить эту чудо-машину можно через ./scripts/stop.sh
Я проверил работу этого ПО (все работает):
- thunar
- telegram-desktop
- firefox
- librewolf
- xfce4-terminal
- xfce4-about
- xeyes
- nekoray
- chromium (нужны доп флаги для работы в wayland: chromium --enable-features=UseOzonePlatform --ozone-platform=wayland --force-dark-mode --enable-features=WebUIDarkMode)
Заключение
В заключение приведу набор плюсов и минусов такого подхода.
Плюсы:
- высокая скорость работы
- переносимость
- расширяемость
- отзывчивость
- требуется больше времени для установки ПО, иногда нужен перезапуск
- не все ПО может работать из коробки, без донастройки
- необходимо наличие специфичных технических знаний
Отдельное спасибо ребятам из этого топика: https://xss.is/threads/113716/