Восстановление докера завершается неудачно - при проверке с активными TCP-соединениями - criu

Question

Я использую восстановление контрольной точки cr-defunct (основываясь на отзывах Росса Баучера), чтобы собрать 1.10.0-dev из исходного кода для получения функциональности контрольной точки / восстановления.

Когда я проверяю контейнер без активных соединений TCP, а затем восстанавливаю его во вновь созданное, у меня нет проблем. Однако при активном TCP-соединении восстановление завершится неудачно. Вполне возможно, что отказ по другим причинам... Я не уверен. Но сбой TCP выскакивает в restore.log. Вот как я это делаю

Запустите докер-контейнер (я использую alpine-sshd) в качестве базового образа.

docker run -d --security-opt seccomp:unconfined --name a1 alpine-sshd

Затем я ssh в контейнер. Я уже настроил пользователя

ssh abc@172.17.0.2

Итак, теперь есть активное TCP-соединение на порту 22 для этого контейнера, которое я могу проверить, введя контейнер и выполнив команду "netstat -na" внутри контейнера.

Теперь я создаю новый контейнер (не запускаю его), используя

docker create --security-opt seccomp:unconfined --name=a3 alpine-sshd

"Докер PS -a" показывает два контейнера, a1 и a3

Затем я проверяю контейнер a1, используя опцию checkpoint. Флаг --leave-running не оказывает влияния, так как он не используется в восстановлении, где лежит фактическая ошибка

docker checkpoint --image-dir=/tmp/ABC a1

Затем я восстанавливаю с помощью /tmp/ABC

docker restore --force=true --image-dir=/tmp/ABC a3

Это вызывает следующую ошибку

Error response from daemon: Cannot restore container a3: cantstart: Cannot start container c40adc.....<snip ID>...: criu failed: type NOTIFY error 0
log file: /var/lib/docker/0.0/containers/c40adc...<snip ID>../criu.work/restore.log

В restore.log есть следующие заметные ошибки:

14: Restoring TCP connection
14: Restoring TCP connection id 13 ino 153c9
14:      Setting 1 queue seq to 2533629009
14:      Setting 2 queue seq to 1507997351
14: Error (sk-inet.c:721): Can't bind inet socket (id 19): Cannot assign requested address
10: Error (cr-restore.c:1350): 14 exited, status=1

В нижней части файла журнала

10: Restored
Error (cr-restore.c:1352): 20710 killed by signal 9
Error (cr-restore.c:2182): Restore failed

Теперь мне не нужно обязательно восстанавливать сеть - хотя это было бы полезно. Прямо сейчас я просто хочу стабильного восстановления ранее проверенного образа с активными сетевыми подключениями.

Обратите внимание, что если я делаю всю эту последовательность без подключения ssh/TCP, она работает хорошо.

Любая помощь будет оценена. Я могу предоставить полный restore.log и другие файлы, если это необходимо. заранее спасибо

Answer 1

Я полагаю, что наиболее вероятное объяснение состоит в том, что оба контейнера должны иметь один и тот же IP-адрес, чтобы восстановление соединения tcp работало. К сожалению, этого нелегко достичь с помощью докера 1.10.

Вы можете попробовать создать новую версию контрольной точки / восстановления на основе 1.12, доступную в ветке "docker-checkpoint-restore" моего репозитория github (я постараюсь сделать предварительно скомпилированный выпуск в ближайшее время). Docker 1.12 позволяет запрашивать IP при создании контейнера. API контрольной точки / восстановления немного изменился:

# to create
$ docker checkpoint create <container_id> <checkpoint_name>

# to restore
$ docker start --checkpoint <checkpoint_name> <container_id>

Обратите внимание, что если вы хотите создать новый контейнер в этой новой системе, в настоящее время вам придется скопировать каталог контрольных точек, расположенный в /var/lib/docker/containers/<container_id>/checkpoints,