[IT-инфраструктура, DevOps, Tarantool] Как эксплуатировать приложения на Tarantool Cartridge
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет! Я продолжаю разрабатывать распределённые системы на основе Tarantool. За последний год наша команда вывела в прод 17 новых систем. В прошлый раз я рассказал, как мы наладили автоматический деплой. В этой статье я покажу, как упростить обслуживание приложений на Tarantool Cartridge.
У одного крупного заказчика процесс выхода в прод сложный. Софт прогоняют через длинный чек-лист и, если система чему-то не соответствует, то никакого прода. Вместе с системой мы должны предоставить документацию по «эксплуатации в штатном режиме» и «траблшутингу» на случай аварий. Одной только документации мало, должно быть обучение! Взять хотя бы общий сценарий «как восстановить упавшую реплику Tarantool» — мы должны показать команде эксплуатации последовательность шагов и ответить на вопросы.
«Общетарантульные» сценарии не меняются от приложения к приложению. А есть специфичные операции: перезагрузить данные кэша, сформировать отчёт по рекламной кампании и т. д. Каждая система будет иметь свой набор. Запуском этих сценариев тоже занимается команда эксплуатации, и тоже необходимо обучение. Однако у нас возникла проблема с доставкой таких операций до конечного исполнителя.
Мы испробовали разные способы:
- Скрипт. Можно подложить в поставку с приложением. Плохая масштабируемость между разными приложениями и командами. Каждый разработчик захочет написать свой скрипт для вкручивания лампочки.
- HTTP API. По сути — удалённый способ вызова встроенной функции. Требует расширенной документации и способов использования. Сойдёт для первой реализации.
- Вместе с инструментом автоматизации. Например, отдельные ansible-playbook для работы с теми же HTTP-вызовами. Это удобнее с точки зрения эксплуатации, но требует повышенной осторожности и документации. Кажется слишком громоздким решением.
- Утилита для управления приложением. Единая точка входа для набора скриптов со встроенной документацией, возможными аргументами и сценариями использования. Можно реализовать --help для получения справки и всех доступных команд. Лучше переиспользуется, однако не защищает от копирования и создания по одной утилите на каждый проект.
Все методы вскрывали одни и те же проблемы. Каждый разработчик захочет написать свой велосипед, и каждый раз придётся выдумывать на чём ехать. Не забыть бы ещё про экплуатационную документацию, чтобы этим пользоваться. Затем провести обучение по взаимодействию с каждым из велосипедов. С таким подходом на внедрение одного скрипта уйдёт в лучшем случае месяц.
Тут появляется cartridge admin, который призван упростить для разработчика написание и поддержку эксплуатационных кейсов, повысить переиспользование операций, оптимизировать доставку до эксплуатации. Больше не нужно выдумывать, куда приложить кейс и как описать его в документации. cartidge admin становится единым местом описания всех процедур обслуживания. Эксплуатация становится частью кода, её можно обложить тестами и гарантировать работоспособность.
С точки зрения команды эксплуатации ситуация аналогична. Есть 17 проектов: каждый имеет свою специфику, документацию и скрипты. Нужно постоянно переключаться между контекстами: WebUI, tarantoolctl, cartridge, HTTP API и т.д. Чем больше разных вызовов, тем больше вероятность ошибки.
И здесь cartridge admin становится единой точкой взаимодействия. Утилита имеет простой консольный интерфейс и обратную связь. При обслуживании приложений на Tarantool Cartridge не придётся переключать контекст. Вызов справки позволяет ознакомиться со всеми операциями, доступными для конкретной системы. Риск человеческой ошибки минимизируется.
Далее опишу как работать с cartridge admin.
Необходимые компоненты
- cartridge-cli v2.7.0 https://github.com/tarantool/cartridge-cli
- cartridge-cli-extensions v1.1.0 https://github.com/tarantool/cartridge-cli-extensions
- Tarantool Cartridge v2.4.0 https://github.com/tarantool/cartridge
Установим cartridge-cli.
Для Centos:
$ curl -L https://tarantool.io/installer.sh | sudo bash -s -- --repo-only
$ sudo yum install cartridge-cli
Для MacOS:
$ brew install cartridge-cli
Альтернативно, можно использовать наше энтерпрайз-решение Tarantool Enterprise SDK, который уже содержит нужные версии компонентов и сам Tarantool. Также в составе идет скрипт для настройки окружения — env.sh.
Создаем приложение
Для простоты возьмём проект, созданный с помощью cartridge create (инструкция).
$ cartridge create --name tarantool-demo
$ cd tarantool-demo
$ cartridge build
Настраиваем сборку артефакта
- В файле проекта tarantool-demo-scm-1.rockspec нужно добавить зависимость cartridge-cli-extensions.
dependencies = {
...
'cartridge-cli-extensions == 1.1.0-1',
...
}
- В cartridge.pre-build добавить копирование бинаря cartridge, так как он не подкладывается в сборку автоматически. Например, если SDK был распакован в одноименную директорию:
#!/usr/bin/env bash
cp `which cartridge` .
Теперь артефакт будет содержать все нужные модули.
$ cartridge pack tgz --version 1
Пишем admin функцию
Вначале предлагаю ознакомиться с документацией README, которая находится в репозитории cartridge-cli-extension. Там пошагово описан процесс инициализации модуля и регистрации функций.
Из интересного:
- В функции можно использовать команду print(). Сообщение сразу же будет напечатано в консоль. Удобно для промежуточных результатов выполнения команды, ошибок, прогресса.
• Cleanup: ready to proceed on 2 storages
• Cleanup [1/2 tnt-storage_2]: deleted {«products»:100}
• Cleanup [2/2 tnt-storage_1]: deleted {«products»:50}
• Deleted total {«products»:150}
-------------------
• Cleanup: ready to proceed on 2 storages
• Cleanup [1/2 tnt-storage_2]: error NetboxEvalError: Peer closed
- Консольный вывод поддерживает смайлики (utf-8)
Пример
Я хочу организовать чистку хранилища, а именно таблицы некоторых продуктов. Ниже описана admin функция, которая вызывает box.space.products:truncate() на подмножестве серверов (в данном случае стораджей-мастеров) и возвращает количество удаленных записей.
Для этого добавим в конец файла init.lua следующий код. В коде есть пояснения к каждой секции.
local admin_tasks = {}
local json = require('json')
local pool = require('cartridge.pool')
admin_tasks.cleanup = {
-- описываем новую функцию
usage = 'Clean old products from cache',
-- конкретно cleanup не будет принимать аргументов.
-- с форматом аргументов можно ознакомиться в примере на GitHub
-- https://github.com/tarantool/cartridge-cli-extensions/blob/master/doc/admin.md#example
args = nil,
call = function(opts)
opts = opts or {}
local servers = {}
local total = { products = 0 }
-- функция для проверки имеет ли репликасет определённую роль
local function replicaset_has_role(replicaset, role)
for _, name in ipairs(replicaset.roles) do
if name == role then
return true
end
end
return false
end
-- обходим все сервера в кластере и выбираем только те, которые:
-- 1) имеют роль vshard-storage
-- 2) являются мастером в своем репликасете
for _, rs in pairs(cartridge.admin_get_replicasets()) do
if replicaset_has_role(rs, 'vshard-storage') then
local server = rs.active_master
if server ~= nil and server ~= "expelled" then
if server.status == 'unreachable' then
return nil, ("Server %s status is %s"):format(server.alias, server.status)
else
servers[server.alias] = server.uri
end
end
end
end
-- выполняем очистку данных по очереди на каждом из стораджей
for alias, uri in pairs(servers) do
-- префикс можно задать любой, например добавить порядковый номер сервера
local prefix = alias
local conn, err = pool.connect(uri)
if err ~= nil then
print(("Cleanup [%s]: error %s"):format(prefix, err))
else
-- собственно вызов функции
-- здесь есть небольшой хак, создадим таблицы прямо из admin функции
-- на реальном примере таблица должна существовать изначально
local res = conn:eval([[
box.schema.create_space('products', { if_not_exists = true })
box.space.products:create_index('primary', { if_not_exists = true })
local len = box.space.products:len()
box.space.products:truncate()
return { products = len }
]])
-- выводим промежуточный результат в консоль
print(("Cleanup [%s]: deleted %s"):format(prefix, json.encode(res)))
total.products = total.products + res.products
end
end
return ("Deleted total %s"):format(json.encode(total))
end
}
Я рекомендую добавлять обход по всем инстансам, как это сделано в примере. Тогда admin операции можно запускать с любой машины, потому что все инстансы кластера могут выполнять одни и те же функции.
Теперь зарегистрируем эту функции в кластере.
-- инициализация модуля admin
local cli_admin = require('cartridge-cli-extensions.admin')
cli_admin.init()
-- регистрируем все функции таблицы admin_tasks из примера выше
for name, task in pairs(admin_tasks) do
local ok, err = cli_admin.register(name, task.usage, task.args, task.call)
if ok ~= true then
error(err)
end
end
В коде есть создание таблицы прямо в admin-функции. Конечно на реальном примере так делать не нужно. Если запустить функцию без этих строк
box.schema.create_space('products', { if_not_exists = true })
box.space.products:create_index('primary', { if_not_exists = true })
то получим ошибку, так как таблицы products не существует.
⨯ Failed to call "cleanup": eval:1: attempt to index field 'products' (a nil value)
Запускаем приложение
$ cartridge start -d
$ cartridge replicasets setup
Запускаем admin функцию
Все вызовы необходимо производить из директории с бинарем cartridge-cli.
Начиная с cartridge-cli v2.6 есть два способа подключиться к инстансу Tarantool.
- Через socket-файл
./cartridge admin \
--name tarantool-demo \
--run-dir ./tmp/run \
--instance router \
--list
- С помощью логин-пароля по сети
./cartridge admin \
--conn admin:<cluster-cookie>@localhost:3301
--list
Далее буду рассматривать работу с socket-файлами. Оба способа идентичны в плане запуска команд.
Сначала проверим, какие функции определены в кластере. Используем директиву --list:
./cartridge admin \
--name tarantool-demo \
--run-dir ./tmp/run \
--instance router \
--list
- Обязательно задать имя приложения через --name.
- Директория для поиска socket-файлов --run-dir.
- Имя инстанса в кластере задается с помощью --instance.
- При указанных параметрах cartridge-cli будет работать с кластером через сокет tarantool-demo.router.control. Его наличие в run-dir обязательно. Для Tarantool Cartridge путь к сокету можно задать, например, через переменную среды TARANTOOL_CONSOLE_SOCK.
Получаем в ответ:
• Available admin functions:
cleanup Clean old products from cache
Теперь запустим желаемую операцию. Используя упомянутый выше пример, запущу чистку продуктов:
./cartridge admin \
--name tarantool-demo \
--run-dir ./tmp/run \
--instance router \
cleanup
- Название команды (cleanup) и любые параметры, которые были определены для этой команды, указываются в конце.
И всё, по завершению операции кластер будет чист!
Итоги
cartridge admin оказался неплохой заменой разрозненной кучке скриптов в нашем окружении. Мы перевели часть операций на его рельсы и не собираемся останавливаться.
Появилась единая точка «сбора» всех функций по управлению системой. Упростились как технические, так и административные процессы. Меньше затрат на разработку и поддержку эксплуатационных сценариев. С помощью cartridge admin обслуживание приложения на Tarantool Cartridge стало удобнее и понятнее.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Виртуализация, Хранение данных, Хранилища данных] Серия вебинаров по работе с программно-определяемыми хранилищами: обсудим нюансы Storage Spaces Direct 25 марта
- [Программирование, Анализ и проектирование систем, IT-инфраструктура, Носимая электроника] Аналитика событий на опасном производстве, или зачем «Цифровому рабочему» Kafka, Esper и Clickhouse
- [Программирование, IT-инфраструктура, Big Data, R] IT Service Health Monitoring средствами R. Взгляд под иным углом
- [Информационная безопасность, IT-инфраструктура, Сетевые технологии] 2020 Network Security and Availability Report
- [IT-инфраструктура, Карьера в IT-индустрии, DevOps, Облачные сервисы] Интенсив по работе с Terraform 24–25 апреля
- [Системное администрирование, IT-инфраструктура, Серверное администрирование] Групповые политики (GPO) Active Directory: разбираемся почему это важно и как ими управлять в GPOAdmin
- [Поисковые технологии, Big Data, DevOps, Искусственный интеллект] Ещё один поиск Вк по фото
- [IT-инфраструктура, Исследования и прогнозы в IT, IT-компании] Автоматизация работы в SAP с помощью роботов
- [Системы управления версиями, Управление разработкой, Управление проектами, Управление продуктом] Как мы построили систему управления проектами на базе Azure DevOps
- [Информационная безопасность, Системное администрирование, IT-инфраструктура, Софт] Фильтрация трафика PF
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_devops, #_tarantool, #_tarantool, #_cartridge, #_blog_kompanii_mail.ru_group (
Блог компании Mail.ru Group
), #_itinfrastruktura (
IT-инфраструктура
), #_devops, #_tarantool
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:11
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Привет! Я продолжаю разрабатывать распределённые системы на основе Tarantool. За последний год наша команда вывела в прод 17 новых систем. В прошлый раз я рассказал, как мы наладили автоматический деплой. В этой статье я покажу, как упростить обслуживание приложений на Tarantool Cartridge. У одного крупного заказчика процесс выхода в прод сложный. Софт прогоняют через длинный чек-лист и, если система чему-то не соответствует, то никакого прода. Вместе с системой мы должны предоставить документацию по «эксплуатации в штатном режиме» и «траблшутингу» на случай аварий. Одной только документации мало, должно быть обучение! Взять хотя бы общий сценарий «как восстановить упавшую реплику Tarantool» — мы должны показать команде эксплуатации последовательность шагов и ответить на вопросы. «Общетарантульные» сценарии не меняются от приложения к приложению. А есть специфичные операции: перезагрузить данные кэша, сформировать отчёт по рекламной кампании и т. д. Каждая система будет иметь свой набор. Запуском этих сценариев тоже занимается команда эксплуатации, и тоже необходимо обучение. Однако у нас возникла проблема с доставкой таких операций до конечного исполнителя. Мы испробовали разные способы:
Все методы вскрывали одни и те же проблемы. Каждый разработчик захочет написать свой велосипед, и каждый раз придётся выдумывать на чём ехать. Не забыть бы ещё про экплуатационную документацию, чтобы этим пользоваться. Затем провести обучение по взаимодействию с каждым из велосипедов. С таким подходом на внедрение одного скрипта уйдёт в лучшем случае месяц. Тут появляется cartridge admin, который призван упростить для разработчика написание и поддержку эксплуатационных кейсов, повысить переиспользование операций, оптимизировать доставку до эксплуатации. Больше не нужно выдумывать, куда приложить кейс и как описать его в документации. cartidge admin становится единым местом описания всех процедур обслуживания. Эксплуатация становится частью кода, её можно обложить тестами и гарантировать работоспособность. С точки зрения команды эксплуатации ситуация аналогична. Есть 17 проектов: каждый имеет свою специфику, документацию и скрипты. Нужно постоянно переключаться между контекстами: WebUI, tarantoolctl, cartridge, HTTP API и т.д. Чем больше разных вызовов, тем больше вероятность ошибки. И здесь cartridge admin становится единой точкой взаимодействия. Утилита имеет простой консольный интерфейс и обратную связь. При обслуживании приложений на Tarantool Cartridge не придётся переключать контекст. Вызов справки позволяет ознакомиться со всеми операциями, доступными для конкретной системы. Риск человеческой ошибки минимизируется. Далее опишу как работать с cartridge admin. Необходимые компоненты
Установим cartridge-cli. Для Centos: $ curl -L https://tarantool.io/installer.sh | sudo bash -s -- --repo-only
$ sudo yum install cartridge-cli Для MacOS: $ brew install cartridge-cli
Альтернативно, можно использовать наше энтерпрайз-решение Tarantool Enterprise SDK, который уже содержит нужные версии компонентов и сам Tarantool. Также в составе идет скрипт для настройки окружения — env.sh. Создаем приложение Для простоты возьмём проект, созданный с помощью cartridge create (инструкция). $ cartridge create --name tarantool-demo
$ cd tarantool-demo $ cartridge build Настраиваем сборку артефакта
Пишем admin функцию Вначале предлагаю ознакомиться с документацией README, которая находится в репозитории cartridge-cli-extension. Там пошагово описан процесс инициализации модуля и регистрации функций. Из интересного:
Пример Я хочу организовать чистку хранилища, а именно таблицы некоторых продуктов. Ниже описана admin функция, которая вызывает box.space.products:truncate() на подмножестве серверов (в данном случае стораджей-мастеров) и возвращает количество удаленных записей. Для этого добавим в конец файла init.lua следующий код. В коде есть пояснения к каждой секции. local admin_tasks = {}
local json = require('json') local pool = require('cartridge.pool') admin_tasks.cleanup = { -- описываем новую функцию usage = 'Clean old products from cache', -- конкретно cleanup не будет принимать аргументов. -- с форматом аргументов можно ознакомиться в примере на GitHub -- https://github.com/tarantool/cartridge-cli-extensions/blob/master/doc/admin.md#example args = nil, call = function(opts) opts = opts or {} local servers = {} local total = { products = 0 } -- функция для проверки имеет ли репликасет определённую роль local function replicaset_has_role(replicaset, role) for _, name in ipairs(replicaset.roles) do if name == role then return true end end return false end -- обходим все сервера в кластере и выбираем только те, которые: -- 1) имеют роль vshard-storage -- 2) являются мастером в своем репликасете for _, rs in pairs(cartridge.admin_get_replicasets()) do if replicaset_has_role(rs, 'vshard-storage') then local server = rs.active_master if server ~= nil and server ~= "expelled" then if server.status == 'unreachable' then return nil, ("Server %s status is %s"):format(server.alias, server.status) else servers[server.alias] = server.uri end end end end -- выполняем очистку данных по очереди на каждом из стораджей for alias, uri in pairs(servers) do -- префикс можно задать любой, например добавить порядковый номер сервера local prefix = alias local conn, err = pool.connect(uri) if err ~= nil then print(("Cleanup [%s]: error %s"):format(prefix, err)) else -- собственно вызов функции -- здесь есть небольшой хак, создадим таблицы прямо из admin функции -- на реальном примере таблица должна существовать изначально local res = conn:eval([[ box.schema.create_space('products', { if_not_exists = true }) box.space.products:create_index('primary', { if_not_exists = true }) local len = box.space.products:len() box.space.products:truncate() return { products = len } ]]) -- выводим промежуточный результат в консоль print(("Cleanup [%s]: deleted %s"):format(prefix, json.encode(res))) total.products = total.products + res.products end end return ("Deleted total %s"):format(json.encode(total)) end } Я рекомендую добавлять обход по всем инстансам, как это сделано в примере. Тогда admin операции можно запускать с любой машины, потому что все инстансы кластера могут выполнять одни и те же функции. Теперь зарегистрируем эту функции в кластере. -- инициализация модуля admin
local cli_admin = require('cartridge-cli-extensions.admin') cli_admin.init() -- регистрируем все функции таблицы admin_tasks из примера выше for name, task in pairs(admin_tasks) do local ok, err = cli_admin.register(name, task.usage, task.args, task.call) if ok ~= true then error(err) end end В коде есть создание таблицы прямо в admin-функции. Конечно на реальном примере так делать не нужно. Если запустить функцию без этих строк box.schema.create_space('products', { if_not_exists = true })
box.space.products:create_index('primary', { if_not_exists = true }) то получим ошибку, так как таблицы products не существует. ⨯ Failed to call "cleanup": eval:1: attempt to index field 'products' (a nil value)
Запускаем приложение $ cartridge start -d
$ cartridge replicasets setup Запускаем admin функцию Все вызовы необходимо производить из директории с бинарем cartridge-cli. Начиная с cartridge-cli v2.6 есть два способа подключиться к инстансу Tarantool.
Далее буду рассматривать работу с socket-файлами. Оба способа идентичны в плане запуска команд. Сначала проверим, какие функции определены в кластере. Используем директиву --list: ./cartridge admin \
--name tarantool-demo \ --run-dir ./tmp/run \ --instance router \ --list
И всё, по завершению операции кластер будет чист! Итоги cartridge admin оказался неплохой заменой разрозненной кучке скриптов в нашем окружении. Мы перевели часть операций на его рельсы и не собираемся останавливаться. Появилась единая точка «сбора» всех функций по управлению системой. Упростились как технические, так и административные процессы. Меньше затрат на разработку и поддержку эксплуатационных сценариев. С помощью cartridge admin обслуживание приложения на Tarantool Cartridge стало удобнее и понятнее. =========== Источник: habr.com =========== Похожие новости:
Блог компании Mail.ru Group ), #_itinfrastruktura ( IT-инфраструктура ), #_devops, #_tarantool |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:11
Часовой пояс: UTC + 5