Как запустить docker-голосовалку на swarm, kubernetes и nomad

Trying it out

I launched a federated cluster in AWS using a CloudFormation template. After accessing the terminal on my bastion host I used the docker info subcommand to check the cluster health of each local cluster and the federated cluster:

# Check local cluster A statusdocker -H tcp://10.0.1.10:3376 info# Check local cluster B statusdocker -H tcp://10.0.2.10:3376 info# Check federated cluster statusdocker -H tcp://10.0.4.10:3376 info

I found that the local clusters had come up healthy. The federated cluster had come up and the local cluster managers had joined as nodes but they were stuck in a pending state. I knew that I had come across one of a few minor differences between the Docker Remote API and the Swarm API. This does not work out of the box.

Nodes: 2 (unknown): 10.0.1.10:3376 └ Status: Pending └ Containers: 0 └ Reserved CPUs: 0 / 0 └ Reserved Memory: 0 B / 0 B └ Labels:  └ Error: (none) └ UpdatedAt: 2016–03–11T18:07:18Z (unknown): 10.0.2.10:3376 └ Status: Pending └ Containers: 0 └ Reserved CPUs: 0 / 0 └ Reserved Memory: 0 B / 0 B └ Labels:  └ Error: (none) └ UpdatedAt: 2016–03–11T18:07:18Z

There are documented API incompatibilities and Swarm has check to make sure that each node is actually an engine. But the API’s are fundamentally compatible. The Swarm API only adds information, minor data structure changes, and has different version information. Ideally, Swarm would behave like a proper building block and stack. It doesn’t leaving two options: fork Swarm or build an adapter.

Step 2 — Configuring Firewall Rules to Allow Docker Swarm Traffic

A cluster has to have at least one node that serves as a manager, though for a production setup, three managers are recommended. For this setup, let’s pick the first node and make it the Swarm manager. The other two nodes will be the worker nodes.

Certain network ports must be opened on the nodes that will be be part of a cluster for the cluster to function properly. That entails configuring the firewall to allow traffic through those ports. Because there are three different firewall applications that can be used to accomplish that task, the commands you need to execute on the nodes for each firewall application has been documented in a separate article. Follow this guide and configure the firewalls for each host. Open the proper ports on the manager, then repeat to open the ports on the two client nodes.

After you’ve completed this step, you can initialize the cluster manager.

3: Инициализация менеджера кластера

Предположим, node-1 будет менеджером кластера; войдите на ноду с локального компьютера:

Командная строка изменится и вы увидите, что подключились к нужной ноде. Чтобы сделать ноду менеджером Swarm, введите:

Примечание: Вместо node_ip_address укажите IP-адрес вашей ноды.

Вы увидите такой вывод:

To add a manager to this swarm, run ‘docker swarm join-token manager’ and follow the instructions.

В выводе вы найдете ID ноды (a35hhzdzf4g95w0op85tqlow1 в этом примере) и инструкции, как добавить другие ноды в кластер.

Итак, теперь у вас есть менеджер Docker Swarm. Настройте остальные ноды.

Step 3 — Initializing The Cluster Manager

We’ve decided that will be our cluster manager, so log in to the node from your local machine:

The command prompt will change to reflect the fact that you’re now logged into that particular node. To configure the node as the Swarm manager, type the following command:

is the IP address of the node. You may get it from the output of or from your DigitalOcean dashboard.

You’ll see output that looks like the following:

Within the output is the ID of the node, which is a35hhzdzf4g95w0op85tqlow1 in this example, and the instructions on how to add the other nodes to the cluster.

So now you have a Docker Swarm with a manager configured. Let’s add the remaining nodes as workers.

Отказ узла в Docker Swarm

Также хочу затронуть тему отказа узлов в Docker Swarm. Команды, относящиеся к сервисам Docker Engine 1.12, являются декларативными. Например, если вы задаете команду «Я хочу 3 реплики данного сервиса», то кластер будет поддерживать это состояние.

В случае отказа узла контейнеры которого были задействованы, swarm обнаружит, что желаемое состояние не совпадает с действительным и автоматически исправит ситуацию путем перераспределения контейнеров на другие доступные узлы.

Чтобы это продемонстрировать, давайте зададим новый сервис с тремя репликами.

Запустите, чтобы проверить работу сервиса

Сейчас у нас есть по одному контейнеру на каждом из узлов. Давайте выведем из строя узел 3, чтобы посмотреть на регулирование swarm в действии.

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

Использование докер сервиса дает вам возможность увидеть, что количество реплик уменьшилось до двух, а затем снова вернулось к трем

покажет вам новый контейнер, назначенный на другом узле вашего кластера.

Этот пример показывает только регулирование контейнеров на рабочих узлах. Совершенно другой процесс происходит, когда из строя выходит менеджер, особенно, если это лидер raft группы для решения задач консенсуса.

Концепция сервисов — местный Service Discovery

В Сворме на смену приходит . Вторая команда по сути является надмножеством первой: все так же нужно/можно указывать желаемый образ, имя сервиса, доступные сети, опубликованные порты присоединенные вольюмы. Ключевая разница в том, что у сервиса есть параметр . Сворм может представить набор одинаковых контейнеров как единую сущность, к которой можно обращаться по имени сервиса.

В классическом режиме мы создавали контейнер бекенда через и обращались к нему по адресу .
В Сворме все точно так же: .
Только на этот раз — это не адрес отдельного контейнера, а всей группы из 3 контейнеров сразу. Запросы на это имя будут автоматически балансироваться между всеми репликами.

Добавим к этому тот факт, что благодаря оверлейной сети реплики одного сервиса могут быть раскиданы по разным физическим серверам, и получится, что мы скрыли от потребителей сервиса как количество реплик, так и их физическое положение. Адрес как был “местом, куда надо сходить за инфой от бекенда” на ноуте разработчика — так и им и остался в географически-распределенном докер-кластере на продакшене.

Кроме балансировки между репликами, концепция серисов имеет ряд опций для описания процесса обновления данного сервиса. Заданием всего нескольких опций и вызовом мы можем вызвать процедуру поочередного обновления всех контейнеров сервиса на новую версию образа или для изменения любых опций, доступных при его создании. Орекстратор Сворма будет поочередно производить следующую процедуру:

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

Таким образом во время обновления сервиса он всегда будет доступен (если конечно сервис не состоит из одной реплики), максимум неприятностей — это получение смешанных ответов от новой и старой версий сервиса.

Step 5 — Managing The Cluster

After the manager and worker nodes have been assigned to the cluster, all Docker Swarm management commands have to be executed on the manager nodes. So return to the terminal that you used to add the manager and type in this command to view all members of the cluster:

The output should be similar to this:

This output shows that we’re dealing with a 3-node Docker Swarm and its nodes — a manager and two workers. To view the other management commands that you can run on the manager node, type:

For detailed information about the cluster, you may use the following command on the manager or workers (it’s a generic Docker command):

The output should be of this sort, and should indicate the status of the cluster (active or pending), the number of nodes in the cluster, and whether the particular node is a manager or worker.

If you repeat the same command on the worker nodes, the Is Manager line should show .

Tip: You can add or remove nodes from the cluster at any time. Additionally, a worker node can be promoted to a manager, and manager can be converted to a worker.

Now let’s get a service running on the cluster.

6: Запуск сервиса в кластере Docker Swarm

Теперь, когда у вас есть запущенный кластер Docker Swarm и запущен, попробуйте запустить тестовый контейнер и посмотрите, как менеджер справится с этой задачей. На машинах Docker Engine 1.12+ контейнеры развертываются как сервисы с помощью команды docker service. Подобно команде docker node, команда docker service может выполняться только на ноде-менеджере.

Итак, для примера разверните сервис веб-сервера, используя официальный образ контейнера Nginx:

Эта команда соединяет порт 80 в контейнере Nginx с портом 80 кластера, благодаря чему вы можете получить доступ к приветственной странице Nginx из любой точки.

Чтобы убедиться, что сервисы работают, введите:

Команда должна вернуть такой вывод. Столбец REPLICAS показывает, сколько экземпляров сервиса запущено:

Вы можете определить, на каких нодах работает сервис, используя команду docker service ps и указав имя сервиса.

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

Еще одна особенность Docker Swarm – это возможность масштабирования сервиса, то есть разворачивания его дополнительных экземпляров. Предположим, что вам нужно масштабировать сервис webserver до пяти экземпляров. Для этого просто введите следующую команду, и система создаст еще четыре экземпляра:

Введите команду docker service ps, и вы увидите, на каких нодах запущены новые экземпляры сервиса:

Вывод показывает, что два из четырех новых экземпляров были запущены на node-3, один был запущен на node-1, а другой – на node-2.

Наконец, если сервис отказывает, он автоматически перезапускается на той же ноде (или на другой ноде, если исходная нода больше не доступна).

Kubernetes

Kubernetes – платформа с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями.

Концепция Kubernetes

• Мастер отвечает за управление кластером (управление состоянием кластера, планирование задач, реагирование на событие в кластере и т.д.)
• Ноды (раньше их называли миньонами. Да-да, как в мультике «Гадкий я») обеспечивают рантайм для запуска контейнера приложения (через Pods)

• Pod – это самая маленькая единица, которую можно развернуть на ноде. Это группа контейнеров, которые должны работать вместе. Но довольно часто Pod содержит всего один контейнер.
• ReplicaSet обеспечивает работу конкретного количества реплик пода.
• Deployment управляет ReplicaSet и позволяет производить rolling updates, синий/зеленый деплой, тестировать и т.д.
• Service определяет логический набор подов и политику получения доступа к ним

ReplicaSetDeploymentDeploymentReplicaSetNginx

Kompose

Использование Kompose для создания деплойментов и сервисов

Примечание:
Kompose использовать необязательно, все можно написать вручную, но он существенно ускоряет процесс развертывания

Kompose не учитывает все опции используемые в файле Docker Compose
Kompose можно установить на Linux или Mac с помощью следующих команд:

docker-stack.ymldocker-stack-k8s.yml

docker-stack-k8s.ymlvisualizer

Разворачивание приложения

kubectl Примеч.: так как мы оставили измененный compose-файл в текущей папке, то получили ошибку, потому что нельзя его распарсить. Но эту ошибку можно без всякого риска проигнорировать. Сервисы Деплойменты

vote result vote

ClusterIP NodePortClusterIP NodePort resultvoteresult

vote result

Overlay Network: любимые сети приложений — теперь между хостами

Возможность создать для проекта изолированную виртуальную сеть, в которой контейнеры могут общаться друг с другом просто по именам, например или — наверное вторая по значимости киллер-фича докера, после изоляции зависимостей. Возможность компонентов проекта обращаться друг к другу по одинаковым адресам вне зависимости от того, в каком окружении они запущены — тоже своего рода изоляция от среды исполнения.

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

Без оверлейной сети для мультихостового проекта пришлось бы публиковать порты приложений, а внутри контейнеров указывать реальные физические адреса вроде . С оверлейной же сетью разницы между на ноутбуке разработчика и на боевом кластере просто не будет.

5: Управление кластером

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

Согласно выводу, в кластере Docker Swarm есть 3 ноды – один менеджер и две рабочие ноды. Чтобы просмотреть список доступных команд для управления кластером, введите:

Для получения подробной информации о кластере вы можете использовать следующую команду (это общая команда Docker, ее можно запускать на менеджере или на рабочих нодах):

Команда сообщает статус кластера (active или pending), количество нод в кластере и роль ноды, с которой она запущена (менеджер или рабочая нода).

Если вы запустите эту команду на рабочих нодах, строка Is Manager будет показывать false.

Примечание: Вы можете добавлять или удалять ноды из кластера в любое время. Кроме того, вы можете менять роли нод: сделать рабочую ноду менеджером и наоборот.

Развертывание контейнера

После развертывания и запуска Docker мы можем немного поэкспериментировать. Четыре первые команды, которые нужно поставить в работу:

• create – создается контейнер из образа;
• ps – выводится список запущенных контейнеров, опционально флаг для списка всех контейнеров;
• start – запуск созданного контейнера;
• attach – присоединяет стандартный вход и выход терминала к работающему контейнеру, буквально подключая вас к контейнеру, как к любой виртуальной машине.

Начнем с малого. Возьмем образ Ubuntu из Docker Hub и создадим из него контейнер.

Мы добавляем как опциональную функцию, чтобы дать контейнеру интегрированный терминал. Мы можем подключиться терминалу, а также запустить команду . Указывая , мы получаем образ Ubuntu с тегом версии 16.04 из Docker Hub.

После запуска команды create убедитесь, что контейнер создан.

Список должен выглядеть примерно так.

Контейнер создан и готов к запуску. Запуск контейнера прост: задайте команду ID контейнера.

Еще раз проверьте, запущен ли контейнер, но теперь без флага .

Если запущен, присоединяйтесь к нему.

Cursor меняется. Почему? Потому что вы только что вошли в контейнер. Теперь вы можете запустить любую команду bash, к которой привыкли в Ubuntu, как будто это был экземпляр, запущенный в облаке. Попробуйте.

Все будет работать хорошо, и даже . Простой контейнер Docker – все, что вам нужно. Это ваша собственная маленькая виртуальная площадка, где вы можете заниматься разработкой, тестированием или чем хотите! Нет необходимости использовать виртуальные машины или тяжелое программное обеспечение. Чтобы проверить мою точку зрения, установите что-нибудь в этом маленьком контейнере. Установка Node пройдет хорошо. Если хотите выйти из контейнера, введите . Контейнер остановится, и вы сможете вывести список, напечатав .

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

Реальный сценарий

Время поработать с настоящим материалом. Это то, что вы будете использовать в реальной жизни для своих проектов и производственных приложений.

Часть 0.2 Процессы в контейнерах

1. Контейнер живет, пока живет процесс, вокруг которого рождается контейнер.
2. Внутри контейнера этот процесс имеет pid=1
3. Рядом с процессом с pid=1 можно порождать сколько угодно других процессов (в пределах возможностей ОС, естественно), но убив (рестартовав) именно процесс с pid=1, контейнер выходит. (см п.1)
4. Внутри контейнера вы увидите привычное согласно стандартам FHS расположение директорий. Расположение это идентично исходному дистрибутиву (с которого взят контейнер).
5. Данные, создаваемые внутри контейнера остаются в контейнере и нигде более не сохраняются (ну, еще к этому слою есть доступ из хостовой ОС). удалив контейнер — потеряете все ваши изменения. Поэтому данные в контейнерах не хранят, а выносят наружу, на хостовую ОС.

Давайте что-нибудь развернем (deploy)

Чтобы запустить приложение, мы используем служебную команду Docker’а create. С помощью флага —replicas, вы можете очень просто масштабировать сервис.

Первоначально мы хотим создать сеть верхнего уровня (оверлейную сеть), чтобы развернуть наше приложение.

До Docker Engine 1.12 оверлейные сети требовали внешнего хранилища ключ/значение, но с созданием распределенного хранилища в Docker 1.12 это больше не требуется.

Давайте развернем простое приложение Apache на публичном порту 5001. Я использую специальный образ Apache, найденный мной на DockerHub, который выводит ID контейнера, обслуживающего запрос. Позже это будет использовано для демонстрации балансировки нагрузки.

Вы можете использовать следующие команды, чтобы проверить ваш новый сервис:

Callouts, Considerations, and Ubernetes

The configuration described below does not create networks that span the set of all local clusters. While each local cluster might implement some form of multi-host networking the logical federated cluster does not.

It is worth mentioning that people have been doing this with Kubernetes already (at least experimenting with it). This article will not go into the fantastic detail as the Ubernetes proposal, but will provide a great starting place.

What is in a Swarm Cluster?

A Swarm based cluster is made up of three main components: a Swarm manager node (or nodes), a set of Docker nodes, and a node discover mechanism like a key-value store. There are a few popular and open source key-value store options. In this article I’ve used etcd, but could have just as easily used Consul, or ZooKeeper. The cluster works because all components can talk to each other via well known interface specifications. Docker nodes implement the Docker API. All nodes have an etcd driver that can register endpoints with etcd. The Swarm manager exposes the Swarm API — which is mostly compatible with the Docker API — to clients. Docker nodes join the cluster either using libnetwork at daemon startup, or using a Swarm container in join mode.

Inside a Swarm cluster

Before deploying Portainer inside your Swarm cluster, you should ensure that Docker and your Swarm are configured correctly. You can refer to the Troubleshooting section to ensure you have correctly configured your environment.

Following the above, you are ready to deploy Portainer inside a Swarm cluster using our recommended agent-enabled deployment. Note: This setup will assume that you’re executing the following instructions on a Swarm manager node.

$ curl -L https://downloads.portainer.io/portainer-agent-stack.yml -o portainer-agent-stack.yml
$ docker stack deploy --compose-file=portainer-agent-stack.yml portainer

Prerequisites

For this tutorial, you’ll need:

• A local machine with Docker installed. Your local machine can be running any Linux distribution, or even Windows or macOS. For Windows and macOS, install Docker using the official installer. If you have Ubuntu 16.04 running on your local machine, but Docker is not installed, see How To Install and Use Docker on Ubuntu 16.04 for instructions.
• A DigitalOcean API token. If you don’t have one, generate it using this guide. When you generate a token, be sure that it has read-write scope. That is the default, so if you do not change any option while generating it, it will have read-write capabilities. To make it easier to use on the command line, be sure to assign the token to a variable as given in that article.
• Docker Machine installed on your local computer, which you’ll use to create three hosts. On Windows and macOS, the Docker installation includes Docker Machine. If you’re running Ubuntu 16.04 locally, see How To Provision and Manage Remote Docker Hosts with Docker Machine on Ubuntu 16.04 for installation instructions.

Как сделать жизнь еще проще?

Есть поговорка: если нужно что-то сделать дважды, автоматизируй. К счастью, Docke позаботился об этом. Вместе с файлом index.html добавьте файл Docker. Его имя Dockerfile, без каких-либо расширений.

Dockerfile – конфигурация сборки для образов Docker

Основное внимание уделяется образам! Мы указываем, что хотим захватить образ nginx:alpine в качестве основы для нашего образа, создать том и выставить порт 80

Для создания образа у нас есть команда `build .

указывает, где находится файл Docker, который будет использоваться для сборки образа, а отмечает тег для образа. Образ будет известен как .

С помощью этой команды мы не извлекли образ из Docker Hub, а вместо этого создали свой собственный. Чтобы посмотреть все образы, используйте команду .

Запустим созданный образ.

Сила Dockerfile – надстройка, которую вы можете предоставить контейнеру. Можно предварительно создавать образы по своему вкусу, а если не нравятся повторяющиеся задачи, то совершить еще один шаг и установить docker-compose.

Выводы

На момент написания данной статьи проект имеет больше чем 2500 issues только в главном репозитории и это количество постоянно растёт. Несмотря на огромное коммьюнити и на то, что вам даже ответят, выглядит это так, будто у проекта просто не хватает сил на исправления и доработки всего, что было в нём намечено. Мне кажется что это в первую очередь связано с тем, что если Docker как упаковщик ПО интересен всем, то Docker Swarm Mode как оркестратор не так уж необходим рынку. Тем более, когда есть более крупные, надежные, а главное — production-ready игроки. Особенно странно выглядит всё вышесказанное учитывая, что Docker идёт по пути разделения Community Edition и Enterprise Edition — мне кажется что для этого они еще не готовы.

Скорее всего мне придется мигрировать этот проект, потому что дальнейшее использование Swarm Mode практически невозможно в силу обстоятельств описанных выше. К моему глубочайшему сожалению, это очень интересная, но очень сырая технология.

Что делать?

Если вам всё же приходится использовать Docker Swarm Mode по каким-либо причинам (требование заказчика, необходимость ультра-быстрого старта или вы просто не хотите разбираться с другими решениями), вот несколько советов:

• Придерживайтесь KISS. Где можно не делать несколько сетей — не делайте. Где можно использовать одну ноду вместо десяти — используйте.
• Забудьте про встроенный балансировщик, он не работает так как вам нужно.
• Держите базу данных как можно ближе к сервисам её использующим. А еще лучше не держите базу в Docker.
• Если у вас CI/CD — первым делом настройте уборку мусора, место на дисках закончится в самый неподходящий момент.
• И еще раз посмотрите в сторону других решений.

PS: и да, не используйте DigitalOcean для более-менее серьезных проектов. Или по-крайней мере не надейтесь на надежную связность между виртуальными серверами.