Стандартна ситуація, у вас є основний робочий комп’ютер, на якому у вас є три різних проекта.
Один проект на nodejs, другий продакшн на python, а третій ваш власний “pet project”, теж на python.
А ще у вас у цій же системі особиста та робоча пошта, та й, скажімо, браузер і клієнт-банк.
І це все під вашим юзером.
Звичайно ж, головне, щоб не під рутом!
Решта не має значення. ¯\_(ツ)_/¯
Все цілком звичайне.

У багатьох технічно грамотних розробників таких проектів можуть бути десятки і десятки ключів для ssh або git серверів.

Приклад із популярним фреймворком PyTorch

Цілком повсякденно Ви пишете свій код, іноді комітіте, і тут у ваш затишний pet-project з AI прилітає оновлення torchtriton.
А після цього з вашої системи відлітають наступні набори даних, відповідно до основної функції бінарника, яка робить наступне:

• Збір системної інформації:
  • nameservers з /etc/resolv.conf
  • hostname з gethostname()
  • поточний логін з getlogin()
  • поточна робоча директорія з getcwd()
  • змінні оточення
• Читання наступних файлів:
  • /etc/hosts
  • /etc/passwd
  • Перші 1,000 файлів з $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

Оновлення прилетіло, конфедиційні дані – відлетіли.
Скомпрометовано не тільки все під вашим юзером (і, можливо, системою), але й по ланцюжку все, чим ви керували, куди комітили, куди підключалися.

Дуже, дуже часто доводиться стикатися з необхідністю використання певної версії Пітона, наприклад, для torch, або чогось специфічного.
Використовувати conda або Docker у зв’язці з nvidia-container-toolkit і потім налаштовувати образи наприклад nvidia/cuda:13.0.1-runtime-ubuntu22.04 мені відчувається протиприродно, хоча часто так робив.
Та й у контейнері доводиться встановлювати додаткові пакети.

Простіше і зручніше зібрати все на хостовій системі, але при цьому не допустити контамінації всієї системи сторонніми бібліотеками та файлами.

Далі наводиться приклад компіляції кількох версій Python тільки для групи verpy, що дещо зручніше, ніж встановлення лише для одного користувача.

• ai - довільний користувач, від якого здійснюється компіляція.
• verpy - група, якою буде дозволено використання.

1
2
3
4

apt install \
    build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
    wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev \
    liblzma-dev libgdbm-dev libnsl-dev libgdbm-compat-dev

mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai

Не вдаючись до подробиць, як саме і чому все організовано, доступ здійснюється по наступному ланцюжку:

1

Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance.

Основний фронтенд управляє піддоменом gitlab, який закритий для зовнішнього доступу за допомогою авторизації auth_basic.

У цьому прикладі показана установка поверх LXC, тоді як для будь-якого більш-менш серйозного застосування це абсолютно неприйнятно і вимагає використання KVM з додатковими заходами безпеки.
І, крім того, встановлення на KVM буде набагато, набагато простіше.
LXC не забезпечує адекватної безпеки, оскільки для правильної роботи потрібне монтування розділів /sys та /proc з хоста, які доступні всім примірникам LXC.
Крім того, цей приклад потребує використання привілейованого контейнера LXC.
Однак LXC дозволяє легко налаштувати тестову інфраструктуру без накладних витрат, пов’язаних з KVM.
Тому деякі аспекти в цьому прикладі будуть пов’язані виключно з налаштуванням в LXC.

Хост

Спочатку давайте підготуємо хост-систему.

nano /etc/modules

1
2
3
4
5
6
7
8
9
10
11

overlay
nf_nat
br_netfilter
xt_conntrack
rbd
fuse
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
iptable_nat

nano /etc/sysctl.d/35-lxc-kubernetes.conf

1
2
3
4
5
6
7
8
9
10
11

kernel.dmesg_restrict = 0
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.bridge.bridge-nf-call-iptables = 1
# --conntrack-max-per-core Default: 32768 * N
net.netfilter.nf_conntrack_max=131072
# net.bridge.bridge-nf-call-arptables
# kernel.pid_max=100000
# user.max_user_namespaces=15000
vm.compact_memory = 1
vm.overcommit_memory = 1