Контейнеры Docker исчезли через некоторое время в CoreOS

У меня есть пара небольших проектов, работающих на бета-версии CoreOS (899.5.0)

Это случилось со мной во второй раз, когда у меня работает 3 контейнера. Все нормально и щегольски. Затем, через несколько дней, когда я не просматривал свои веб-сайты на этом сервере, я замечаю, что страницы не работают, когда я пытаюсь их посетить.

И когда я вхожу в свой компьютер CoreOS в Digital Ocean и набираю docker ps, я замечаю, что все мои контейнеры исчезли! Это безумие.

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

Я вижу это, хотя приветствую меня, когда вхожу в систему; Я не уверен, связано ли это с этим:

Last login: Sun Jan 17 23:42:37 2016 from 81.106.109.70
CoreOS beta (899.5.0)
Failed Units: 13
  [email protected]:22-219.219.114.120:14536.service
  [email protected]:22-219.219.114.120:30158.service
  [email protected]:22-219.219.114.120:17539.service
  [email protected]:22-122.224.34.168:1397.service
  [email protected]:22-122.224.34.168:3789.service
  [email protected]:22-122.224.34.168:2983.service
  [email protected]:22-219.219.114.120:51826.service
  [email protected]:22-219.219.114.120:38882.service
  [email protected]:22-219.219.114.120:34654.service
  [email protected]:22-219.219.114.120:21256.service
  [email protected]:22-219.219.114.120:39645.service
  [email protected]:22-219.219.114.120:63277.service
  [email protected]:22-219.219.114.120:37294.service

Я не мог найти никакой информации об этом в CoreOS в Google. Пожалуйста, приветствуется любая помощь!

P.S. моя конфигурация systemd выглядит так:

szeremi.service

[Unit]
Description=Run %p
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStartPre=-/usr/bin/docker kill %p
ExecStartPre=-/usr/bin/docker rm -f %p
ExecStart=/usr/bin/docker run -t --rm --name %p \
  -p 80:8080 \
  amcsi/szeremi
ExecStop=/usr/bin/docker stop %p

[Install]
WantedBy=multi-user.target

РЕДАКТИРОВАТЬ: последняя страница файла журнала (journalctl -u szeremi.service): https://gist.github.com/amcsi/95c8b0eb71de2f44c16b#file-journalctl-u-szeremi-service


docker digital-ocean systemd coreos
person Attila Szeremi    schedule 25.01.2016    source источник
comment
что вам показывает journalctl? journalctl -u szeremi.service   -  person Michael    schedule 26.01.2016
comment
Вы используете systemd напрямую, войдя в узел, или используете такой планировщик, как Fleet?   -  person Ben Campbell    schedule 26.01.2016
comment
Напрямую. Я скопировал его в / etc / systemd / system   -  person Attila Szeremi    schedule 26.01.2016
comment
@AttilaSzeremi Я отправил ответ, указывающий на необходимость включения службы, чтобы она продолжала загрузку.   -  person Ben Campbell    schedule 26.01.2016

Ответы (2)


arrow_upward
2
arrow_downward

Неудачные блоки sshd, о которых сообщается при входе в систему, являются результатом неудачных попыток входа в систему sshd, активируемого сокетом systemd в CoreOS. Они не связаны с отсутствующими контейнерами докеров.

Кажется вероятным, что контейнеры «исчезают» после перезагрузки системы для выполнения автоматического обновления. Это настройка по умолчанию для обновлений, и эти обновления происходят с некоторой частотой на бета-канале. Вы можете проверить, как давно была перезагружена система, с помощью uptime или другой подобной команды.

Если система была перезагружена, а контейнеры не перезагружались после этого, вы можете сосредоточить устранение неполадок на файле модуля systemd и запуске службы. Если он не был перезагружен, можно начать с журналов контейнера (например, docker logs szeremi) и журналов службы (например, systemctl status -l szeremi.service). У #coreos на freenode или в списке рассылки coreos-users будут люди готов помочь в любом случае.

person Josh Wood    schedule 26.01.2016

arrow_upward
1
arrow_downward

CoreOS использует systemd для определения процессов на хосте. Примером служебного файла является служебный блок, который определяет, как контейнер докеров будет запущен. Если вы используете systemd напрямую, войдя в узел CoreOS напрямую, вы должны enable службу, чтобы она сохранялась во время загрузки. Подкоманда enable программы systemctl принимает в качестве параметра модуль и создает символическую ссылку в структуре целевого файла systemd. Когда systemd загружается, он запускает любую службу в пределах заданной цели. Это гарантирует, что данная служба запускается при загрузке.

systemctl enable szeremi.service   # Creates a symlink within systemd 
systemctl start szeremi.service    # Starts the service => runs container
person Ben Campbell    schedule 26.01.2016