Оновіть контейнер Docker без простоїв

Скажімо, у мене є контейнер Docker з веб-сервером (наприклад, Apache 2). Тепер я хочу оновити ОС під нею. Ця відповідь SF каже, що найкращим способом є відновлення базового зображення та мого зображення Apache. Але розгортання зображення означає простої, оскільки я маю видалити старий контейнер, перш ніж я можу створити новий, тому є лише один контейнер, який прив’язує до порту 80/443.

Але як я можу розгорнути це оновлення з нульовим простоєм? Чи слід використовувати балансир навантаження та використовувати міжконтейнерну комунікацію? І як оновити балансир навантаження?

Ідеальний цільовий сценарій

Так, ви повинні використовувати балансир завантаження та оновлювати по одному екземпляру за раз. Я не впевнений, куди заходить міжконтейнерне спілкування.

Як приклад, уявіть, що у вас є балансир навантаження, який обслуговує ваш сайт А. Користувачі підключаються до нього лише як і знають його лише як "А". Балансир навантаження знає, що є два або більше резервних файлів (B, C і т.д.), і чи є вони машинами вітрини або контейнерами не має значення.

Потім потрібно оновити мітки, які в даному випадку є екземплярами Apache.

1. вийміть B з придатних програм для балансування навантаження, щоб він більше не приймав жодного трафіку.
2. дочекайтеся подання поточних запитів і наявних з'єднань.
3. оновити контейнер або базовий VM, який обслуговує B
4. перезапустіть B, дочекайтеся його завантаження та почніть працювати
5. тест B, щоб переконатися, що він правильно обслуговує нові запити
6. додати B назад до резервного пулу балансира навантаження, щоб знову включити трафік

Потім виконайте той самий процес для C, D тощо.

Зауважте, що відкритий запит на місцеві оновлення контейнерів Docker з листопада 2013 року, але, схоже, не має великого прогресу, тому вищенаведене рішення - це те, що вам слід зробити в середній час.

Що робити для існуючого живого сайту

Імовірно, ви це запитуєте, оскільки ви вже працюєте на веб-сайті в цій моделі, і ви хочете оновити його без простоїв. Отже, нам потрібно дістатися до ідеального цільового стану вище, але поступово.

Припустимо, що:

• у вас є DNS-ім’я, що вказує на ваш контейнер
• ваш контейнер працює на певній IP-адресі
• ваші користувачі не знають IP-адресу контейнера, і це ніде не важко кодується

Якщо ці припущення помилкові, спершу слід виправити це так, щоб це було правильно.

Потім виконайте наступні дії:

1. створіть балансир навантаження на новому IP-адресі та вкажіть його на існуючий контейнер як єдиний резерв
2. змінити DNS, щоб вказувати на балансир завантаження, а не безпосередньо на контейнер IP
3. додайте ідентичний сервер Apache з тією ж установкою контейнера VM +
4. тепер у вас є балансир навантаження з двома прохідними B і C, тому дотримуйтесь вказівок у розділі "ідеальний цільовий сценарій" для їх оновлення одночасно

Як оновити балансир навантаження

Простий (розміщений) спосіб

Найпростіший варіант - не запускати власний балансир. Наприклад, якщо ви використовуєте хмарну платформу, яка забезпечує балансування навантаження як послугу, розгляньте її використання, а потім обслуговування та оновлення балансира навантаження не є проблемою.

Ручний спосіб

Якщо ви працюєте з власним балансиром навантаження, додавання ще одного шару непрямості (тобто DNS) допоможе. Припустимо наступне:

• що у нас є ім'я хоста, яке відповідає IP-адресу нашого балансира навантаження A, яку ми хотіли б оновити
• наш балансир навантаження має резервний пул P1, P2 тощо.

Ми діємо так:

• створити новий балансир навантаження B з новою версією програмного забезпечення
• додайте всі екземпляри резервного пулу P1, P2 тощо до нашого нового балансира навантаження B як резервні

• додати IP-адресу B до роздільної здатності DNS разом з A

  • тепер ми ефективно використовуємо DNS як балансир навантаження
  • якщо записи для A і B не зважені, вони фактично 50-50
  • тепер дивіться, щоб побачити, як працює B, чи є помилки тощо.

  • якщо з B щось не так, скасуйте наступне:

    1. видаліть B з конфігурації DNS
    2. зачекайте, поки запис B у DNS зникне (тобто, дочекайтеся закінчення терміну дії TTL )
    3. відхилити В
• припустимо, що ви зробили тест на «згоряння» для B і все в порядку
• поступово оновлюйте пріоритет та вагу для B у DNS
• видалити A повністю з DNS
• чекати закінчення терміну дії DNS TTL; А більше не слід отримувати жодних запитів
• відхилити А

і ви закінчили.

Деталі, діаграми та інструментарій

Перегляньте ці записи та інструменти, які можуть допомогти вам автоматизувати процес, але загальна ідея та ж:

• Набережна: нульовий час простою
• Нульовий час простою Frontend розгортається з Vulcand на CoreOS

Мораль

"Усі проблеми в інформатиці можуть бути вирішені іншим рівнем непрямості, за винятком, звичайно, проблеми занадто багатьох непрямих". - Девід Уілер