Table of contents
Основная цель Octopod ― упрощение управления разными развертываниями сервисов в Kubernetes.
При разработке рассчитывалось, что сам Octopod тоже будет разворачиваться при помощи Kubernetes.
Взаимодействовать с Octopod возможно либо через веб-интерфейс (рассчитано на использование разработчиками, PM, QA и т. д.), либо через консольный клиент octo CLI (рассчитано на использования DevOps инженерами и программно, например в CI).
Все взаимодействие Octopod с самими развертываниями производится через скрипты управления развертываниями (control scripts), которые передаются ему при запуске. Это позволяет сделать Octopod очень гибким ― его возможно настроить для работы с практически в любой организацией развертываний.
Все данные об окружениях развертываний и всех операция совершаемых над ними Octopod хранит в базе данных PostgreSQL.
UI – веб интерфейс, используется для управления развертываниями посредством отправки команд управления развертываниями. Взаимодействует с Octopod Server посредством отправки HTTP/1.1 запросов, а также получает события от Octopod Server по Websocket. Между UI и Octopod Server Basic Auth. Написан на Haskell и Reflex-Dom.
В интерфейсе нет технических деталей системной администрации и оркестрации ― работа с развертываниями производится очень просто. Интерфейс рассчитан на использование разработчиками любого уровня, QA инженерами, PM, а так же людьми без ИТ образования.
Octopod Server – непосредственно сам сервер, который обрабатывает запросы работы с развертываниями и делегирует базовые операции, модифицирующие развертывания, скриптам управления стеджингами (control scripts).
Сервер обрабатывает команды управления развертываниями от octo CLI и UI, обновляет состояние развертываний. octo CLI и UI взаимодействуют с ним путем отправки HTTP/1.1 запросов. Сервер шлет событие обновления на UI по Websocket. Сервер взаимодействует с Kube API Server через скрипты управления развертываниями (control scripts). Для хранения настроек и статусов развертываний, и логов действий пользователей используется PostgreSQL. Написан на Haskell. Для работы с развертываниями использует скрипты управления развертываниями (control scripts).
PostgreSQL – РСУБД для хранения настроек и статусов развертываний, и логов действий пользователей.
octo CLI – консольный клиент используется для управления развертываниями посредством отправки команд управления развертываниями. Взаимодействует с Octopod Server посредством отправки HTTP/1.1 запросов. Написан на Haskell. Между octo CLI и Octopod Server аутентификация по сертификату, новый сертификаты создается вовремя каждой сборки и упаковываются в контейнеры с octo CLI и Octopod Server.
В нем можно делать все операции, которые можно делать в UI, но также есть доступ к расширенным операциям над развертываниями, таким как просмотр логов деплоя, что может быть полезно при диагностике возникающих проблем.
Этот клиент рассчитан на использование DevOps инженерами.
Его также можно использовать если необходимо автоматизировать управление развертываниями. Например, при настройке автоматического обновления развертываний при успешно пройденном CI.
Скрипты управления развертываниями (control scripts) – контейнер с исполняемыми файлами, в которые инкапсулирована логика работы с Kube API Server, облачными провайдерами, развертываниями, системами контроля версий и т.д.
Они нужны для того, чтобы Octopod не был завязан на какую-то конкретную организацию развертываний ― его можно настроить для работы с практически любой организацией развертываний.
Во время старта пода Octopod Server содержимое контейнера с утилитами копируется в ФС контейнера с Octopod Server, поэтому исполняемые файлы должны быть либо интерпретируемы через Bash, либо статически слинкованны. Логику исполняемых файлов предлагается реализовать пользователям Octopod (смотри Control scripts).
Clean Archive CronJob – CronJob, которая запускается раз в час и через octo CLI удаляет заархивированные развертывания старее 14 дней.
Это сделано из-за того что при архивировании развертываний удаляются только вычислительные его части, persistent volumes не удаляются, и при необходимости развертывание возможно восстановить в том виде, в котором он был до архивирования. Такая возможность пропадает по истечению 14 дней с момент его архивирования.
Kube API Server – сервис на стороне Kubernetes, к которому должны обращаться скрипты управления развертываниями (control scripts).
octo CLI в виде статически слинкованного исполняемого файла. Собранные исполняемые файлы доступны во вкладке "Releases" этого проекта на GitHub.
Octopod Server и UI поставляются упаковынными в один Docker образ. Для развертывания в Kubernetes используется набор Chart-ов. Образы доступны в нашем registry на Docker Hub.
Docker образ скриптов управления развертываниями (control scripts) пользователь Octopod собирает сам.
Далее здесь для справки приводятся схемы последовательностей для каждой из базовых операция работы с развертываниями. При их исполнении вызываются скрипты управления развертываниями (control scripts). На схеме они помечены как ControlScripts.
create – создание нового развертывания.
В качестве аргументов принимаются name, tag и опциональные overrides (уровня App или Deployment, открытие или секретные).
Переданные аргументы вместе с project-name, base-domain, namespace передаются в качестве аргументов в create из скриптов управления развертываниями (control scripts).
create создает новое развертывание в кластере используя полученные аргументы.
Например, он может выполнять:
helm upgrade --install --namespace "$namespace" "$name" "$deployment_chart" \
--set "global.project-name=$project_name" \
--set "global.base-domain=$base-domain" \
--set "app.tag=$tag" \
--set "app.env.foo=$app_env_override_1" \
--set "app.bar=$deployment_override_1" \
--wait \
--timeout 300
update – обновление существующего развертывания.
В качестве аргументов принимаются name, tag и опционально изменения overrides (уровня App или Deployment, открытие или секретные).
Затем из базы достаются overrides (уровня App или Deployment, открытие или секретные), они мерджатся с изменениями overrides
и передаются вместе с project-name, base-domain, namespace в качестве аргументов в update из скриптов управления развертываниями (control scripts).
update обновляет существующее развертывание в кластере используя полученные аргументы.
Например, он может выполнять:
helm upgrade --install --namespace "$namespace" "$name" "$deployment_chart" \
--set "global.project-name=$project_name" \
--set "global.base-domain=$base-domain" \
--set "app.tag=$tag" \
--set "app.env.foo=$app_env_override_1" \
--set "app.bar=$deployment_override_1" \
--wait \
--timeout 300
delete – архивирование существующего развертывания.
Производится удаление только подов, Persistent Volumes (диски) сохраняются. Отменить действие этой команды можно с помощью команды restore.
В качестве аргументов принимается name.
name вместе с project-name, base-domain, namespace передаются в качестве аргументов в archive из скриптов управления развертываниями (control scripts).
archive удаляет существующее развертывание в кластере, используя полученные аргументы.
Например он может выполнять:
helm delete "$name" --purge
cleanup – полная очистка развертывания.
В качестве аргументов принимаeтся name.
Например, можно удалять сертификаты, Persistent Volume Claim и Persistent Volumes.
name вместе с project-name, base-domain, namespace передаются в качестве аргументов в cleanup из скриптов управления развертываниями (control scripts).
cleanup выполняет освобождение ресурсов в кластере, которые ранее использовались одним из удаленных развертываний.
Например, он может выполнять:
kubectl delete pvc -n "$namespace" "$name-postgres-pvc"
kubectl delete certificate -n "$namespace" "$name-postgres-cert"
restore – восстановление заархивированного развертывания с последними настройками.
В качестве аргументов принимается name.
Из базы достаются недостающие для восстановления tag и опциональные overrides (уровня App или Deployment, открытие или секретные). Они передаются вместе с project-name, base-domain, namespace в качестве аргументов в restore из скриптов управления развертываниями (control scripts).
restore выполняет восстановление в кластере ранее удаленного развертывания используя полученные аргументы.
Например, он может выполнять:
helm upgrade --install --namespace "$namespace" "$name" "$deployment_chart" \
--set "global.project-name=$project_name" \
--set "global.base-domain=$base-domain" \
--set "app.tag=$tag" \
--set "app.env.foo=$app_env_override_1" \
--set "app.bar=$deployment_override_1" \
--wait \
--timeout 300
Мы используем несколько кластеров Kubernetes: отдельный кластер для каждого приложения, а так же разделяем по кластерам production и deployment окружения.
В каждый deployment кластер мы устанавливаем Octopod, через Octopod осуществляем разворачивание различных версий deployment'ов необходимых для QA.
Существует 6 статусов развертываний:
- Running
- Failure
- CreatePending
- UpdatePending
- DeletePending
- Archived
Running, Failure, Archived являются постоянными, т.е. развертывание уже не находится в режиме выполнения команды.
CreatePending, UpdatePending, DeletePending являются переходными, т.е. развертывание находится в режиме выполнения команды.
