Один контейнер с утилитами для обслуживания кластера DOCKER-SWARM

1. clean-node
   1. Удалить все EXITED/STOPPED/COMPLETED containers: docker container prune -f
   2. Удаление ненужных images: docker image prune -f -a
   3. Очистка кэша билдера: docker builder prune -f
   4. ВАЖНО
      1. На данный момент не реализован механизм Labels у Node
      2. Все Node в кластере - будут очищаться
   5. Параметры API запроса
      1. token - обязательный параметр
      2. nodeName - обязательный параметр (super-worker-1)
   6. Запуск: CRON / API
2. backup-service
   1. Резервное копирование
   2. Работает только на service
   3. Загрузка копий на S3 хранилище (Через offen-backup)
      1. Creds для S3 - общие на весь кластер. Указываеются через ENV переменные swarm-utils
   4. Параметры API запроса
      1. token - обязательный параметр
      2. serviceName - обязательный параметр (stack-name_service-name)
   5. Запуск: CRON / API
3. clean-service
   1. Очистка одного или нескольких сервисов. (Например - registry, smtp cache)
   2. Параметры API запроса
      1. token - обязательный параметр
      2. serviceName - обязательный параметр (stack-name_service-name)
   3. Запуск: CRON / API
4. update-service
   1. Перезапуск (Обновление) сервисов. Через команду docker service update SERVICE_NAME
   2. Можно указать: serviceName, image?
   3. Параметры API запроса
      1. token - обязательный параметр
      2. serviceName - обязательный параметр (stack-name_service-name)
      3. image - обязательный параметр. Полное название. image-name:tag
      4. isForce - необязательный параметр. Обновляем FORCE или нет
         1. Если force === true -> task, будет пересоздана. Даже если image - не изменился
   4. Запуск: API

1. swarm-utils.clean
   1. enable=true/false
   2. exec
   3. exec.shell='/bin/bash'
   4. token
2. swarm-utils.backup
   1. enable=true/false
   2. exec
   3. exec.shell='/bin/sh'
   4. stop=true/false
   5. volume-list-upload=volume1,volume2,volume3,...
   6. volume-list-upload.s3.url=s3-api.domain.com
   7. volume-list-upload.s3.https=true/false
   8. volume-list-upload.s3.access-key=...
   9. volume-list-upload.s3.secret-key=...
   10. volume-list-upload.s3.bucket=...
   11. volume-list-upload.s3.retention-days=8
   12. token
3. swarm-utils.update
   1. enable=true/false
   2. registry.auth=true/false
   3. registry.user=...
   4. registry.password=...
   5. registry.url=...
   6. token

На данный момент - НЕТ

1. Есть кластер - docker-swarm
   1. 1 голова
   2. 2 воркера
   3. 2 билдера
   4. 1 хранилище
2. Доступ к серверам по SSH - есть только у Админа (Админов)
   1. То есть - НИКТО из обычных разрабов не имеет доступа к серверам (Напрямую)
3. На голове установлен - swarm-utils
   1. Наружу - никаких портом не открывается (По умолчанию)
   2. Если надо - можно. НО - тогда нужно подумать про безопасность
   3. Доступ - возможен только через внутренню overlay сеть
4. CI/CD
   1. На сборщиках - установлены раннеры (GitLab runner, Github runner и ТД)
   2. У раннера есть доступ к docker.sock - ЭТО ВАЖНО
   3. Производится сборка - docker build . -t ...
   4. Производится push - на regisdtry. Не важно - что это за registry
   5. Поднимается сервис - alpine-curl (Условно) + attach к overlay сети, которая имеет доступ к swarm-utils
   6. Запрос - на /update с параметрами
   7. Готово
5. Идея токенов - .labels.token
   1. У каждого сервиса, который обслуживается через swarm-utils - свой токен доступа
   2. Токен доступа - один на сервис+действие
6. Работаем через GitHub, организация
7. Работаем через просто GitHub
8. Работаем через GitLab (self-hosted или нет)

1. Когда вызывается /update - через параметры можно указать ЛЮБОЙ image
2. Ничего не мешает разработчику - модифицировать CI/CD и указать вредоносный image

1. Есть разработчик X
2. У него есть доступ к двум проектам - a, b
3. Следовательно - разработчик знает токены для перезапуска проектов a, b
   1. Для кажого проекта - свой токен (Помним правило)
4. В какой-то момент - принято решение забрать права доступа у разработчика X к провекту a
5. Все - разработчик X больше не может делать коммиты в проект a
   1. Он все еще может делать коммиты в проект b -> тригерить CI/CD в кластере -> имеет доступ к swarm-utils
6. Он знает токен от проекта a -> модифицирует CI/CD проекта b и указывает токен от проекта a
7. Запускает вредоносный image (Что следует из первой уязвимости)

1. Админы
   1. Cписок токенов указан через ENV SWARM_UTILS_ADMIN_TOKEN_LIST
   2. Могут делать ВСЕ
   3. Не зависят от labels.token
2. Все остальные пользователи
   1. Могут делать ВСЕ
   2. Зависят от labels.token
   3. Работают только с теми контейнерами, к которым у них есть доступ

1. Бэкап и очистку - можно запустить по API
2. Бэкап name: nodeName_volumeName_date
3. Бэкап + Очистка идут по одной кроне
   1. CLEAN
   2. BACKUP

1. Через API запустили clean-service - service_A
2. Запустился процесс. Процесс займет условно 30 секунд
3. Через 5 секунд - стартует CRON для очситки всех сервисов
4. И запускает очситку на service_A
5. Итог: НЕИЗВЕСТНО. Но ничего хорошего...

1. На все действия с конкретным service, node - ставится MUTEX
2. На уровне кода в TypeScript (JS) NodeJS - используется async-lock
3. Ключ для блокировки - название сервиса или название node
4. И только после успешной установки блокировки - NodeJS идет выполнять работу с сервисом

1. Через API запустили clean-service - service_A
2. Запустился процесс. Процесс займет условно 30 секунд
3. NodeJS - упал, перезапустился, сервер перезапустился
4. Итог: async-lock сбросился
5. Через 5 секунд - стартует CRON для очситки всех сервисов
6. И запускает очситку на service_A
7. Итог: НЕИЗВЕСТНО. Но ничего хорошего...

1. очистка сервиса - это exec команда на docker container
2. Чтобы выполнить docker exec - нужно иметь доступ к docker.sock, где запущен контейнер
3. Мы работаем в условиях - DockerSwarm cluster (10 отдельных серверов)
4. Чтобы выполнить docker-exec на Node_A
   1. Создается service с образом docker-cli на указанной Node
   2. Название сервиса - CONSTANT+SERVICE_NAME
   3. Монтирование docker.sock - через volume
   4. Как параметр запуска: docker exec CONTAINER_ID /bin/sh ...
5. Создать более обного сервса с одинаковым названием - НЕЛЬЗЯ (На уровне docker engine)

1. Через API запустили clean-service - service_A
2. Запустился процесс. Процесс займет условно 30 секунд
3. NodeJS - упал, перезапустился, сервер перезапустился
4. Итог: async-lock сбросился
5. Через 5 секунд снова кинули запрос на очистку сервиса - service_A
6. LOCK - поставился (Так-как он сбросился после перезапуска сервиса)
7. А новый сервис - создать не можем
8. Так как - на уровне docker engine запрещено создавать сервисы с одинаковым названием

1. Перед запуском нового сервиса - для работы с service_A - проверка и удаление
2. Проверить и удалить существующие ВСЕ сервисы для service_A
   1. Все сервисы NOT_EXIST - продолжаем
   2. Некоторые сервисы EXIST && canRemove (isComplete) - завершаем их и продолжаем
   3. Есть хоть один сервис который EXIST && !canRemove - выброс с ошибкой
3. Это значит - что в один момент времени с service_A может происходить только ОДНА операция

1. Время на блокиррку = 10 секунд
2. Время на выполнение = 10 минут
3. Общее время = 10 минут 10 секунд

1. Приходит два запроса через API на update, service=service_a
2. Прежде чем выполнить команду - ставится AsyncLock с ключем: update_service_a
3. Один из запрсоов - сможет поставить LOCK и начать процесс обновления
4. Второй из запросов - вывалится с ошибкой, так как не сможет поставить LOCK

1. async-lock, Timeout состоит из нескольких частей
   1. Время на установку LOCK (пакет: async-lock)
   2. Время на выполнение операции, после установки LOCK
   3. Общее время: установка LOCK + выполнение операции
2. dockerWaitForServiceComplete - Ожидание, пока сервис закончит работу
   1. Для каждой операции есть фиксированный timeout - указан в ENV
   2. SWARM_UTILS_PENDING_SERVICE_TIMEOUT - Время на запуск сервиса. Указано в ENV
   3. Ситуация: Запуск сервиса с неправильным Constraint -> вечный pending
3. Как считается
   1. Время операции = SUM((timeout операции + SWARM_UTILS_PENDING_SERVICE_TIMEOUT) * количество операций) + EXTRA_TIMEOUT
   2. Время суммарно = Время операции + LOCK_TIMEOUT
   3. Количество операций: Например надо сделать clean-service, а у service 4 реплики (4 task, на разных Node) = execTimeout * 4

1. Остановка сервиса в момент BACKUP
2. Остановка === docker service scale SERVICE_NAME=0
3. Работает только на сервисы, которые запущены в mode=Replicated

1. Кластер подразумевает (Хоть и не всегда) работу с приватным container-registry
   1. Доступ по логин/пароль
   2. Указать конкретный URL
2. Могут быть контейнеры, из разных registry, с разными CREDS
3. Для каждого сервиса, который .update.enable=true -> можно указать через labels данные для registry
   1. auth = true/false
   2. user
   3. password
   4. url
4. Если auth = true (Нужна авторизация, чтобы обновить этот service)
   1. НО - не указаны через labels: user || password || url
   2. -> будут взяты из ENV
5. Если в ENV они не указаны (Хоть одна из переменных - пустая)
   1. Будет ошибка
6. Авторизация требует наличия файла: $HOME/.docker/config.json
   1. Этот файл НЕ МОНТИРУЕТСЯ внутрь контейнера при запуске
   2. -> Авторизация будет производиться внутри контейнера, который отвечает за обновление сервиса

1. Немного теории
   1. Сервис swarm-utils - работает в контуре docker-swarm
   2. Все контейнеры в кластере docker-swarm - можно связать через overlay сеть
      1. В этом сценарии - контейнеры могут общаться между собой
   3. Если overlay сеть сделть attachable -> к ней можно присоединять обычные контейнеры, запущенные через docker run ...
2. Практика
   1. Создать overlay сеть, отдельную для swarm-utils
   2. docker network create --driver overlay --subnet 10.48.0.0/16 --gateway 10.48.0.1 --attachable swarm-utils-overlay-net
   3. 10.48.0.0/16 и 10.48.0.1 -> можно менять. Тут кому как надо
   4. --attachable -> обязательный параметр

1. Как известно из документации Docker: 1 service === MANY tasks
2. Введем определения
   1. TASK
   2. HELP_SERVICE
   3. TARGET_SERVICE/TARGET_NODE
3. После завершения команды dockerWaitForServiceComplete запускается команда dockerHelpServiceCompleteInfo
   1. Это команда собирает логи с каждой TASK в указанном SERVICE (по serviceName)
   2. Что собирать логи с SERVICE/TASK - нужно запускать SERVICE с log-driver=json-file/journald
   3. В данном случае serviceName === HELP_SERVICE.name
4. Если хоть одна TASK упала с ошибкой -> ВЕСЬ HELP_SERVICE упал с ошибкой
   1. За это отвечает параметр isFailed в результате команды dockerHelpServiceCompleteInfo
5. На самом верхнем уровне (Где async-lock) - возвращается массив из результатов по каждому HELP_SERVICE
   1. Например: При clean-node - заускается 3 helpService. Container, image, builder
6. Если хоть один HELP_SERVICE упал с ошибкой -> вся процедура по TARGET_SERVICE/TARGET_NODE прошла с ошибкой
7. Из метода возвращается массив с резльтатами

1. docker node ls --format json
2. docker volume ls -f driver=local --format json
3. docker service ls --filter label="LABEL" --format json
   1. Получение списка сервисов
4. docker service ps SERVICE_NAME --format json
   1. Получение списка TASKS
   2. taskId = .ID (380xcsrylpmc0wvl5ntd3xfa5)
   3. taskName = .Name (nginx_master.2)
   4. taskNode = .Node (internal-manager-1) (hostname)
5. docker inspect TASK_ID --format json
   1. Чтобы получить id контейнера - нужно проинспектировать task
   2. containerId = .[0].Status.ContainerStatus.ContainerID
6. docker inspect SERVICE_ID --format json
7. docker service ps SERVICE_NAME --filter 'desired-state=running' --format json
8. Команда, для запуска внутри контейнера: docker exec CONTAINER_ID /bin/sh -c 'LABEL_STRING'
9. docker service ls --filter label="docker-backuper.volume-list-upload" --format json
10. docker service ls --filter mode=replicated --filter label="docker-backuper.stop=true" --format json
11. docker service scale SERVICE_NAME=123
12. docker service scale SERVICE_NAME=0
13. docker service logs SERVICE_NAME/SERVICE_ID/TASK_NAME/TASK_ID
    1. Проблема: работает только на сервисы с log-driver = json-file/journald
14. docker service remove SERVICE_NAME
15. docker inspect --type
    1. container|image|node|network|secret|service|volume|task|plugin

1. Сделать метод, для переноса docker-volumes между серверами
   1. Нужно перенести Minio с сервера A -> на сервер B
2. В момент update добавить labels
   1. .update.exec-pre
   2. .update.exec-post
3. Добавить node.labels.token
   1. Чтобы можно было по АПИ дергать Clean на Node
4. Labels. Добавить возможность настрйоки timeout для каждого действия
   1. Если label не указан - timeout из ENV (по умолчанию)
   2. Список labels (SERVICE)
      1. .backup.exec.timeout
      2. .backup.stop.timeout
      3. .backup.volume-list-upload.timeout
      4. .backup.start.timeout
      5. .clean.exec.timeout
   3. Список labels (NODE)
      1. .clean.image.timeout
      2. .clean.builder.timeout
      3. .clean.container.timeout
5. Использовать node-labels
   1. Сколько времени на каждую операцию - для очистки NODE
   2. Какие пользователи, имеют права доступа на очистку этой NODE
   3. Список labels
      1. clean.enable
      2. clean.image.enable
      3. clean.image.timeout
      4. clean.builder.enable
      5. clean.builder.timeout
      6. clean.container.enable
      7. clean.container.timeout
      8. clean.token
6. API. Во все методы - добавить параметр waitRes=true/false
   1. Если ждать ответ не надо - запускать без await. И сразу отдать res: процесс запущен
7. Labels. Добавить labels для Node
   1. swarm-utils.clean
      1. enable=true/false
      2. exec
      3. token
   2. swarm-utils.backup
      1. enable=true/false
      2. exec
      3. volume-list-upload=volume1,volume2,volume3,...
      4. token
8. Добавить ENV переменную для маскирования логов
   1. Скрыкает полный вывод в команде bashExec. Добавляет звездочки
9. Добавить API методы
   1. GET /service/status (info)
   2. получение списка Service
   3. получение писка Service по labels
   4. Получение списка Nodes по Labels
10. Уменьшить общее количество логов
    1. Сейчас для CLEAN одного сервиса - тонна логов....
11. Логи bashExec, логи вывода
    1. Там могут быть секретные данные - надо придумать, как их скрывать
    2. Передавать функцию в команду bashExec - для модификации ввода/вывода ?
12. API. Маска на токен
    1. боди
    2. bashExec
    3. На данный момент - токен, с которым идет запрос, светится в логах, без маски
13. Немного переработать структуру файлов
    1. Связанных с Docker
    2. Они стали достаточно большими
14. При update - есть проблема с логами
    1. Хотим собрать логи с сервиса, которы обновляли
    2. А у сервиса настроен log-drivar как syslog или что-то еще
    3. Выполнить команду docker service logs XXX -> не получится, работает на сервисы с log-driver=json-file/journald
    4. А при перезапуске - контейнер упал ...
    5. В логах команды docker service update будет только: service update paused: update paused due to failure or early termination of task TASK_ID
15. Функционал, обновления версий контейнеров
16. Отдельный сервис (Контейнер) - для обновление сервисов. Вызов команды /service/update
17. Отдельный сервис для PUSH собранный образов в registry ?
    1. Через docker info --format json - можно получить Swarm.NodeID
    2. Swarm: {"NodeID":"gw97a8q5pfqsfqhncmj987qc2","NodeAddr":"185.224.248.118","LocalNodeState":"active","ControlAvailable":false,"Error":"","RemoteManagers":[{"NodeID":"cxfiamgp1mwxqcjzvbl6jd7ox","Addr":"185.224.248.76:2377"}]}
    3. Произвести сборку на этой Node
    4. После - обратиться в swarm-utils и попросить его запушить в registry ?
18. Получить список неиспользуемых volumes
    1. Получить список node
    2. на каждой node - получить список volumes
    3. проверить - что они unused
19. Добавить возможность указать адрес docker.sock
    1. На примере с Traefik + HA-proxy + WorkerNode
    2. Можно поднять HA-proxy на ManagerNode и открыть доступ к docker.sock через TCP
20. multi-tenant
    1. В одном swarm cluster - может быть запущено НЕСКОЛЬКО swarm-utils
    2. Учесть проблему с CRON. Там нет выборки по токен - там используются ВСЕ и СРАЗУ