Как обнаружить, что контейнерная система 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 удален некоторым сценарием инициализации.

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

Источник

2 ответа

Для контейнера, который работает на systemd, кажется, это работает хорошо:

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

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

Источник

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

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

      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
# ...

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

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

Источник
Другие вопросы по тегам