☰

Как определить готовность контейнерной системы LXC?

tag-icon • tag-icon boot lxc
Как определить готовность контейнерной системы LXC?

Я пытаюсь запустить контейнер LXC, а затем выполнить команду внутри него. Проблема в том, что даже если контейнер находится в состоянии RUNNING, он не завершил всю свою загрузку. Это приводит к проблемам с /tmp (и, я полагаю, с другими инициализациями).

Это можно проиллюстрировать с помощью следующей последовательности вызовов, которая создает контейнер, запускает его, ждет его состояния RUNNING и выполняет некоторые команды; команды создают файл /tmp/hello, показывают каталог, немного ждут и снова показывают каталог:

lxc-clone -B overlayfs -s -o vm -n c1 ; lxc-start -n c1 ; lxc-wait -n c1 -s RUNNING ; lxc-attach -n c1 -- su -c "touch /tmp/hello; ls -la /tmp; sleep 5; ls -la /tmp" slave ; lxc-stop -n c1 ; lxc-destroy -n c1

чей выход

Created container c1 as snapshot of vm total 16 drwxrwxrwt 1 root root 4096 May 24 09:37 . drwxr-xr-x 1 root nogroup 4096 May 24 09:37 .. drwxrwxrwt 2 root root 4096 May 22 21:19 .ICE-unix drwxrwxrwt 2 root root 4096 May 22 21:19 .X11-unix -rw-rw-r-- 1 slave slave 0 May 24 09:37 hello total 16 drwxrwxrwt 1 root root 4096 May 24 09:37 . drwxr-xr-x 1 root nogroup 4096 May 24 09:37 .. drwxrwxrwt 2 root root 4096 May 24 09:37 .ICE-unix drwxrwxrwt 2 root root 4096 May 24 09:37 .X11-unix

и показывает, что файл /tmp/hello удален каким-то скриптом инициализации.

Как дождаться полной загрузки системы внутри контейнера? И как это сделать извне контейнера?

решение1

Для контейнера, работающего на systemd, похоже, это работает хорошо:

lxc-attach -n [CONTAINER NAME] -- systemctl isolate multi-user.target

Вероятно, вы могли бы применить ту же логику для контейнера на основе sysvinitили upstart(запустить команду, которая блокирует выполнение до тех пор, пока не будет достигнут уровень выполнения), но я не могу сходу сказать, какие команды могут это сделать.

решение2

В моем случае я считаю контейнер LXC «готовым», когда у него есть сетевое подключение (например, чтобы команды, такие как , apt updateработали в скрипте настройки контейнера LXC).

На Debian 11 bullseye в качестве хоста lxc с контейнером Debian 11 bullseye lxc мне удалось успешно использовать следующую схему:

lxc-unpriv-start -n "$LXC_CONTAINER"

lxc-wait -n "$LXC_CONTAINER" -s RUNNING
# the lxc-wait RUNNING state is not that useful;
# a container is already considered RUNNING even though the network is not yet up

# the following command blocks until the container's network is up
lxc-unpriv-attach -n "$LXC_CONTAINER" -- systemctl start systemd-networkd-wait-online.service

# when the script reaches this part, the lxc container's network probably is completely up and running

lxc-unpriv-attach -n "$LXC_CONTAINER" -- apt update
# ...

Соответствующая systemctl start systemd-networkd-wait-online.serviceчасть: systemd-networkd-wait-online.service— это готовая к использованию служба systemd, для которой требуется толькоnetwork-online.target(по крайней мере, я так понимаю).

Поэтому выполнение systemctl start systemd-networkd-wait-online.serviceблоков происходит до тех пор, пока сеть не будет запущена.

Связанный контент