Контейнеры systemd-nspawn: различия между версиями
Дым (обсуждение | вклад) |
Дым (обсуждение | вклад) |
||
Строка 72: | Строка 72: | ||
# systemctl status systemd-nspawn@spawn-1 | grep /usr/bin/systemd-nspawn | # systemctl status systemd-nspawn@spawn-1 | grep /usr/bin/systemd-nspawn | ||
└─238367 /usr/bin/systemd-nspawn -q --keep-unit -b -j -U --settings=override -M spawn-1 | └─238367 /usr/bin/systemd-nspawn -q --keep-unit -b -j -U --settings=override -M spawn-1 | ||
А всё потому, что, как явствует из мана systemd-nspawn, некоторые операции в образах контейнеров | А всё потому, что, как явствует из мана systemd-nspawn, некоторые операции в образах контейнеров осмысленны, эффективны, да и вообще поддерживаются лишь на файловой системе btrfs. | ||
С контейнером же в простом каталоге порядок действий таков: | С контейнером же в простом каталоге порядок действий таков: | ||
# Разворачиваем, входим без запуска, меняем пароль рута, перезаходим с запуском, настраиваем сеть, доустанавливаем требуемые пакеты, обеспечиваем дальнейший автозапуск нужных сервисов, выходим. | # | ||
** Разворачиваем, входим без запуска, меняем пароль рута, перезаходим с запуском, настраиваем сеть, доустанавливаем требуемые пакеты, обеспечиваем дальнейший автозапуск нужных сервисов, выходим. | |||
# Стартуем юнит для этого контейнера, рулим им по ссх. | # Стартуем юнит для этого контейнера, рулим им по ссх. | ||
# В случае надобности реконфигурирования и прочей обслуги стопорим юнит, входим с запуском, обслуживаем, выходим, — далее см. п.2. | # В случае надобности реконфигурирования и прочей обслуги стопорим юнит, входим с запуском, обслуживаем, выходим, — далее см. п.2. | ||
{{Category navigation|title=Виртуализация|category=Виртуализация|sortkey={{SUBPAGENAME}}}} | {{Category navigation|title=Виртуализация|category=Виртуализация|sortkey={{SUBPAGENAME}}}} | ||
[[category:systemd]] | [[category:systemd]] |
Версия от 02:08, 2 октября 2020
Подготовка
Первым делом не обойтись без установки пакета означенной в заголовке системы виртуализации:
# apt-get update && apt-get install systemd-container -y
Вторым — понадобится минимальный образ системы, годный для виртуальных сред контейнерного типа (LXC, Docker и т.п.), взять который можно в репозитории. На момент написания статьи привлекательнее прочих выглядел этот.
Установка
Развернём предварительно скачанный тарбол в контейнер (допустим, первый из них будет называться spawn-1):
# machinectl import-tar alt-p9-rootfs-systemd-x86_64.tar.xz spawn-1 Enqueued transfer job 1. Press C-c to continue download in background. Importing '/var/lib/machines/alt-p9-rootfs-systemd-x86_64.tar.xz', saving as 'spawn-1'. Imported 0%. ... Imported 99%. Operation completed successfully. Exiting.
Настройка
Как контейнеры запускаются, можно подглядеть в пункте ExecStart
сервисного шаблона /lib/systemd/system/systemd-nspawn@.service, а именно:
# systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth -U --settings=override --machine=%i
С сокращёнными опциями, не загораживая горизонты, та же команда выглядит так:
# systemd-nspawn -q --keep-unit -b -j -n -U --settings=override -M spawn-1
Дабы впоследствии не мучиться со входом в контейнер с отлупом по паролю, следует задать таковой пользователю root, для чего первый вход произвести в незапущенный контейнер без лишних на данном этапе опций:
# systemd-nspawn -M spawn-1
Получив приглашение [root@spawn-1 ~]#
, задать пароль и выйти:
[root@spawn-1 ~]# passwd passwd: updating all authentication tokens for user root. ... Enter new password: Re-type new password: passwd: all authentication tokens updated successfully. [root@spawn-1 ~]# exit logout
Запуск
Стартанём новый контейнер, одновременно включив его запуск при каждой загрузке компьютера:
# systemctl enable --now systemd-nspawn@spawn-1 Created symlink /etc/systemd/system/machines.target.wants/systemd-nspawn@spawn-1.service → /lib/systemd/system/systemd-nspawn@.service.
Проверим, всё ли удалось:
[root@comp ~]# systemctl status systemd-nspawn@spawn-1 ● systemd-nspawn@spawn-1.service - Container spawn-1 Loaded: loaded (/lib/systemd/system/systemd-nspawn@.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2020-10-01 21:38:31 +08; 8s ago Docs: man:systemd-nspawn(1) ...
Работает. Заходим уже штатным образом:
# machinectl login spawn-1
Первый облом
Если входить в контейнер при остановленном юните из командной строки, получаем:
# systemd-nspawn -q -b -j -n -U --settings=override -M spawn-1 systemd v243.8-alt2 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) Detected virtualization systemd-nspawn. Detected architecture x86-64. Welcome to ALT Starterkit (Hypericum)! ... spawn-1 login: root Password: Last login: Thu Aug 27 11:55:00 +08 2020 on pts/0 [root@spawn-1 ~]#
Однако пробовать штатным образом залезть в запущенный юнит бесполезно:
# machinectl login spawn-1 Connected to machine spawn-1. Press ^] three times within 1s to exit session. spawn-1 login: root Password: Login incorrect login:
При этом видно, что строка запуска та же самая, с добавкой опции --keep-unit
:
# systemctl status systemd-nspawn@spawn-1 | grep /usr/bin/systemd-nspawn └─238367 /usr/bin/systemd-nspawn -q --keep-unit -b -j -U --settings=override -M spawn-1
А всё потому, что, как явствует из мана systemd-nspawn, некоторые операции в образах контейнеров осмысленны, эффективны, да и вообще поддерживаются лишь на файловой системе btrfs.
С контейнером же в простом каталоге порядок действий таков:
- Разворачиваем, входим без запуска, меняем пароль рута, перезаходим с запуском, настраиваем сеть, доустанавливаем требуемые пакеты, обеспечиваем дальнейший автозапуск нужных сервисов, выходим.
- Стартуем юнит для этого контейнера, рулим им по ссх.
- В случае надобности реконфигурирования и прочей обслуги стопорим юнит, входим с запуском, обслуживаем, выходим, — далее см. п.2.