Вышла версия Proxmox VE 9.1
Не зря я обратил внимание на новые опции в lxc
- В CT Templates скачиваем образ из OCI репы (аутентификация не поддерживается)
- Видим архив с образом
- При создании контейнера выбираем
- В опциях контейнера видим, что данные параметры были скопированы из контейнера
- В настройках сети видим галочку Host-Managed (она автоматически включится при создании контейнера если PVE пойдем, что это OCI образ)
Дело в том, что docker изначально не поддерживает настройку сети самим контейнером, поэтому, PVE назначает IP адрес самостоятельно и прокидывает в контейнер уже настроенный сетевой интерфейс
Я Обнаружил, что в версии PVE 9.1.1 IPv6 работает не совсем корректно, при попытке включить SLAAC ругается, а при Static и пустых полях должен отсутствовать IPv6 адрес, а он получен по SLAAC, в общем, ждем допиливаний.
- Запускаем LXC контейнер и видим
- Собственно, мы видим, что не зря нам ранее дали возможность просмотра IP адресов
Это все было в рамках подготовки к запуску Docker контейнеров в LXC
Смотрим на ресурсы, которые потребляет наша LXCшка
Думаете все хорошо?
В опциях консоль не через tty, а console, что логично
Думаете работает консоль?
На самом деле работает, но не как консоль, а как вывод stdout контейнера без интерактивного режима
Меняем консоль на shell и заводится
Давайте рассмотрим минусы данного решения
- Нет docker-compose, нет даже docker cli
- Только 1 процесс, нет ssh, нет нескольких контейнеров через docker compose, чтобы все это работало надо добавлять какой-то init процесс, который бы уже был родительским для остальных, т.е. по сути, собирать LXC контейнер
- Нет overlayfs, по сути, это подход микротика, когда все слои распаковываются в одно место, все конфиги правятся прямо на лету, т.к. смотрим следующий пункт
- Тут нет разделения на контейнер и о образ, если в докере мы делаем
docker pull && docker stop && docker rm && docker run, то тут просто удалять LXC контейнер со всеми данными и создавать новый, либо же, написать баш скрипт, который скачивает docker образ куда-то, останавливает и монтирует rootfs контейнера, потом копирует файлы из одного места в другое, но с учетом волюмов (смотрим следующий пункт) - Нет волюмов, по сути, это уже не stateless а stateful контейнер, если надо хранить пользовательские файлы, то пробрасываем каталог стандартной “матрешкой”
mp0: /host/path,mp=/container/path - Нет вменяемого API по работе с этим
- Ну и в целом, очень много ограничений данного решения, но с другой стороны, это еще один вариант запуска, он может пригодиться кому-то + можно же собирать свои кастомные докер образы, которые будут обновляемые и к какими-то своими фишками.
Есть еще вариант обновления контейнеров
- Создаем новый LXC контейнер с новой версией
- Удаляем старый LXC контейнер со старой версией
Тут мы понимаем, что все персистентные данные нам надо выносить в точки монтирования
Если мы обращаемся к контейнеру по сети, то надо как-то перенаправить клиентов на новый адрес, тут первое, что приходит в голову, это какой-то service-discovery, но с ними у нас большие проблемы
- Из коробки мы имеем только DHCP, в теории можно попробовать как-то его использовать
- Consul и прочие не будут работать т.к. нам нужен клиент, а тут не поды, а контейнеры, с подами было бы чуть легче
- Docker api у нас тоже нет, можно было бы натравить какой-нить traefik или типа того, реализовать куберовский оператор, в общем
- Остаются веб-хуки самого PVE, можно в конфиг добавить вызов скрипта при старте или остановке контейнера, этот скрипт может дергать serivce-discrovery для обновления
- Ну и мы же не будем руками создавать и удалять контейнеры? Скорее всего, у нас будет какой-нить terraform или ansible, который будет создавать нам контейнеры, в нем же тогда можно и дергать service-discovery провайдера
- Опционально, можно прикрутить скрипт, который будет получать список контейнеров и по тегам раскидывать контейнеры по сервисам
- Ну и можно попробовать поковырять SDN + IPAM, тут в рамках 1 проекта/неймспейса можно создать отдельную подсеть с IPAM
- Ну и мы должны понимать, что в данном случае у нас контейнеры все будут висеть в одном списке, если в кубере у нас есть несколько уровней организации, то тут только 1, максимум, что можем разные бриджи завести чере SDN
И и главный вопрос тогда: а оно вам надо? по сути, это будет попытка собрать кубер из 
и 
Тогда уже проще поднять кубер и получить все из коробки.
Уточнение
Самый главный момент
Это не запуск Docker напрямую в PVE
Это просто конвертация Docker образа в формат rootfs LXC + мелкие допилы типа кастомного entrypoint вместо/bin/initи передачи переменных окружения
Для себя вижу только 1 вариант: попробовать собрать минималистичную систему для запуска podman на основе libc т.к. пока с LXC шаблонами у меня не очень хорошо пошли дела и насколько я понял из общения с GPT, то там все равно шаблон надо собирать на основе docker образов
Еще вижу еще несколько вопросов:
- Нет аутентификации для OCI, тут либо ждать добавления данного функционала в PVE, либо идти по пути (на который намекнули сами Proxmox) подготовки архива своими силами и отправки его в хранилище. Тут я вижу добавление в CI/CD отдельного шага, который будет выполнять что-то типа
skopeo copy docker-daemon:my-app:1.2.3 oci:my-app_1.2.3 && tar -czf my-app_1.2.3.tar.gz -C my-app_1.2.3 . && scp my-app_1.2.3.tar.gz proxmox:/var/lib/vz/templates/cache/ - В docker-compose (ну и docker) есть restart: unless-stopped/always, непонятно, как поведет себя PVE при вылете entrypoint, по идее просто выставит ошибку контейнеру и не будет пытаться загрузить его снова
- Docker менеджеры типа Dockge, Portainer, Komodo, Arcane, DockPort, Watchtower идут лесом, остается Pulse и еще парочка, которых сильно меньше
- Sidecar/agents, похоже идут лесом, пока не придумал как организовать
- Не совсем понятно, что делать с логами, как их вообще можно смотреть за претелами текущего noVNC буфера
Будем посмотреть