Назад | Перейти на главную страницу

Есть ли причина использовать Consul с современным («интегрированным») Docker Swarm?

В прошлом я делал небольшой Docker Swarm, и он был довольно несложным - создать Swarm Manager на одном узле, создать Swarm Workers еще на двух узлах, придерживаться одного Manager. Я хотел бы узнать больше о Swarm, поэтому слежу за серией видео «Docker Swarm: Native Docker Clustering» Найджела Поултона на Pluralsight.

Однако эти видео намного сложнее, чем мои впечатления от Swarm два года назад, возможно потому, что они работают на старой («автономной») версии Swarm. Я хотел бы задать уточняющий вопрос, чтобы убедиться, что материал, который я сейчас изучаю, слишком устарел, чтобы иметь смысл. (Ниже я опишу, что находится на видеокурсе, чтобы не было необходимости знать его, чтобы ответить на вопрос).

Видеоряд, которому сейчас четыре года, показывает, как:

Автор признает, что все это довольно сложно, и намекает, что во время съемки видео ядро ​​Docker может упростить этот материал в будущем. Он говорит (Создание кластера Swarm -> Установка службы обнаружения высокой доступности -> 5:39):

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

И эта особенность, кажется, именно то, что произошло на самом деле, если я правильно понимаю. Из руководства:

Вы просматриваете документацию по устаревшей автономной версии Swarm. В этих разделах описывается автономный Docker Swarm. В Docker 1.12 и выше режим Swarm интегрирован с Docker Engine. Большинству пользователей следует использовать интегрированный режим Swarm.

По общему признанию, в моем предыдущем опыте работы со Swarm использовался только один менеджер, но, насколько я понимаю, можно добавить менеджера к существующему плоту, просто используя docker swarm join-token.

Итак, на мой вопрос: эта эволюция функции Docker Swarm заставляет меня задаться вопросом, предлагает ли Consul какую-либо ценность для управления самим Swarm. Могу ли я это сделать? Нужно ли мне? Есть ли другие функции, которые он предлагает по сравнению с интегрированной системой консенсуса плота? Этот учебный материал теперь вреден?

(Кроме того: я просмотрел пару видео от этого автора, и они отличные - если это устарело, то это вне его контроля. Если материал нуждается в пересъемке, это курс / платформа. владельцев, которые должны были бы это устроить).

Я действительно сожалею о путанице ... Я постараюсь удалить это старое видео или обновить его.

Для Swarm вы должны посмотреть соответствующие разделы в:

  • Начало работы с Docker
  • Докер глубокое погружение

Поскольку оба они используют более современные Режим роя который интегрирован в Docker Engine и не требует какого-либо старого безумия консула.

Если у вас возникнут вопросы, напишите мне на @nigelpoulton.

Есть два варианта Docker Swarm. Версия Classic / Legacy, которая может использовать внешнее хранилище ключей / значений, например Consul. Маловероятно, что в будущем появятся какие-либо обновления, и репозиторий недавно был переименован в «classicswarm», чтобы помочь уменьшить некоторую путаницу.

Интегрированная версия - Swarm Mode, основанная на проекте swarmkit. Для этого не требуется никакого внешнего хранилища ключей / значений, и попытка настроить его в движке докеров для оверлейной сети не удастся, если вы включите режим Swarm, поскольку он контролирует базу данных ключ / значение изнутри с помощью собственного решения на основе рафта.

Следовательно, нет необходимости использовать Consul, и любое руководство, которое не начинается с docker swarm init следует игнорировать как устаревшие.