Евгений Штольц - Из разработчика в архитекторы. Практический путь

открыт и на хостовой машине для прямого перенаправления трафика) и HostNetwork (контейнеры в поде

будут находиться в сетевом пространстве хоста)

Мастер как минимум содержит: kube-apiserver, kube-sheduler и kube-controller-manager. Состав слейва:

* kubelet – проверка работоспособности компонента системы (ноды), создание и управление контейнерами. Он находится на каждой ноде,

обращается к kube-apiserver и приводит в соответствие ноду, на которой расположен.

* cAdviser – мониторинг ноды

//http://linux-notes.org/nastrojka-docker-swarm-klastera-v-unix-linux/

Допустим у на есть хостинг и мы создали три AVS сервера. Теперь необходимо на каждый сервер установить docker и docker-machine, о том как это сделать было рассказано выше. Docker-machine сама является виртуальной машиной для doker контейнеров, мы собирем лишь внутренний для неё драйвер – virtualbox – чтобы не устанавливать дополнительные пакеты. Теперь, из операций, которые должны быть выполнены на каждом сервере останется создать doker машины, остальные же операции по настройки и созданию контейнеров на них можно выполнять из master-ноды, а они буду автоматически запущены на свободных нодах и перераспределяться при изменении их количества. Итак. запустим docker-machine на первой ноде:

docker-machine create – driver virtualbox – virtualbox-cpu-count «2» – virtualbox-memory «2048» – virtualbox-disk-size «20000» swarm-node-1

docker-machine env swarm-node-1 // tcp://192.168.99.100:2376

eval $(docker-machine env swarm-node-1)

Запускаем вторую ноду:

docker-machine create – driver virtualbox – virtualbox-cpu-count «2» – virtualbox-memory «2048» – virtualbox-disk-size «20000» swarm-node-2

docker-machine env swarm-node-2

eval $(docker-machine env swarm-node-2)

Запускаем третью ноду:

docker-machine create – driver virtualbox – virtualbox-cpu-count «2» – virtualbox-memory «2048» – virtualbox-disk-size «20000» swarm-node-3

eval $(docker-machine env swarm-node-3)

Подключимся к первой ноде инициализируем в ней распределённое хранилище и передаём ему адрес ноды менеджера (лидера):

docker-machine ssh swarm-node-1

docker swarm init – advertise-addr 192.168.99.100:2377

docker node ls // выведет текущий

/// docker swarm join-token worker

Если токены будут забыты, их можно получить, выполнив в ноде с распределённым хранилищем команды docker swarm join-token manager и docker swarm join-token worker.

Для создания кластера необходимо зарегистрировать (присоединить) все его будущие ноды командой docker swarm join – token … 192.168.99.100:2377, для аутентификации используется токен, для их обнаружения необходимо, чтобы они находились в одной подсети. Посмотреть все сервера можно командой docker node info

Команда docker swarm init создаст лидера кластера, пока одинокого, но в полученном ответе будет на неё будет придана команда, необходимая для подключение других нод к этому кластеру, важная информация в котором – токен, например docker swarm join – token … 192.168.99.100:2377. Подключимся к оставшимся нодам по ssh командой docker-machine ssh name_node и выполним её.

Для взаимодействия контейнеров используется сеть brige, которая является свитчем. Но для работы нескольких реплик нужна подсеть, так как все реплики будут с одинаковыми портами, а проксирование производится по ip с помощью распределённого хранилища, при этом не имеет значение физически они расположены на одном сервере или разных. Следует сразу заметить, что балансировка осуществляется по правилу roundrobin, то есть поочерёдно к каждой реплике. Важно создать сеть типа overlay для создания DNS по верх неё и возможности обращаться к репликам по им именам. Создадим подсеть:

docker network create – driver overlay – subnet 10.10.1.0/24 —opt encrypted services

Теперь нам нужно наполнить на кластер контейнерами. Для этого создаём не контейнер, а сервис, который является шаблоном для создания контейнеров на разных нодах. Количество создаваемых реплик указывается при создании в ключе – replicas, причём распределение случайное по нодам, но по возможности равномерное. Помимо реплик, сервис имеет балансировщик нагрузки, порты с которого на которые (входные порты для всех реплик) происводится проксирование указывается к ключе – p, а Servis Discovery (обнаружение работающих реплик, определение их ip-адресов, перезапуск) реплик балансировщик осуществляет самостоятельно.

docker service create – p 80:80 —name busybox – replicas 2 —network services busybox sleep 3000

Проверим состояние сервиса docker service ls, состояние и равномерность распределения реплик контейнеров docker service ps busybox и его работу wget – O- 10.10.1.2. Сервис – более высокоуровневая абстракция, которая включает в себя контейнер и организующее его обновление (далеко не только), то есть для обновления параметров контейнера не нужно его удалять и создавать, а просто обновить сервис, а уже сервис сперва создаст новый с обновлённой конфигурацией, а только после того как он запустится удалит старый.

Docker Swarm имеет свой балансировщик нагрузки ingress load balacing, который балансирует нагрузку между репликами на порту, объявленном при создании сервиса, в нашем случае это 80 порт. Входной точкой может быть любой сервер с этим портом, но ответ будет получен от сервера на который был перенаправлен запрос балансировщиком.

Мы также можем сохранять данные на хостовую машину, как и в обычном контейнере, для этого есть два варианта:

docker service create – mount type=bind, src=…, dst=…. name=…….. #

docker service create – mount type=volume, src=…, dst=…. name=…….. # на хост

Развёртывание приложения производится через docker-compose, запущенного на нодах (репликах). При обновлении конфигурации docker-compose нужно обновить docker stack, и кластер будет последовательно обновлён: одна реплика будет удалена и в место неё будет создана новая в соответствии с новым конфигом, далее следующая. Если произошла ошибка – буде произведён откат к предыдущей конфигурации. Что ж, приступим:

docker stack deploy – c docker-compose.yml test_stack

docker service update – label-add foo=bar Nginx docker service update – label-rm foo Nginx docker service update – publish-rm 80 Nginx docker node update – availability=drain swarm-node-3 swarm-node-3

Docker Swarm

$ sudo docker pull swarm

$ sudo docker run – rm swarm create

docker secrete create test_secret docker service create – secret test_secret cat /run/secrets/test_secret проверка работоспособности: hello-check-cobbalt пример pipeline: trevisCI —> Jenkins —> config – > https://www.youtube.com/watch?v=UgUuF_qZmWc https://www.youtube.com/watch?v=6uVgR9WPjYM

Docker в масштабах компании

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

Рассмотрим эволюцию:

* Разработчик создаёт необходимые контейнера руками.

* Разработчик создаёт необходимые контейнера используя для этого заранее подготовленные скрипты.

* Системный администратор, с помощью какой-либо системы управления конфигурации и развёртывания, таких как Chef,