xyOps об’єднує планування завдань, автоматизацію робочих процесів, моніторинг та реагування на інциденти в єдину, самостійну контрольну площину для вашої інфраструктури.
xyOps – це платформа з відкритим кодом, яка самостійно розгортається і поєднує планування завдань, автоматизацію робочих процесів, моніторинг серверів, оповіщення та реагування на інциденти в єдину цілісну систему. Розроблена компанією PixlCore, вона призначена для команд, які хочуть мати повний контроль над своєю автоматизаційною інфраструктурою, не відмовляючись від володіння даними або приймаючи залежність від постачальника. Замість того, щоб з’єднувати окремі інструменти для cron, перевірки здоров’я, оповіщення на виклик та створення квитків, xyOps пропонує єдину контрольну площину, яка зберігає операційний контекст, телеметрію та дії в одному місці.
У своїй основі xyOps націлений на загальну проблему в середовищах DevOps: фрагментовані інструменти, які ускладнюють розуміння того, як заплановані завдання, здоров’я серверів та інциденти пов’язані між собою в режимі реального часу. Підключаючи виконання завдань до даних моніторингу, правил оповіщення та квитків, xyOps створює зворотний зв’язок, де збої та аномалії можуть автоматично відкривати інциденти, прикріплювати знімки серверів та запускати робочі процеси з усунення.
Огляд основної архітектури
xyOps працює як сервіс, побудований на основі фреймворку pixl-server для Node.js, з основним кондуктором, відповідальним за планування завдань, оркестрацію робочих процесів, обслуговування веб-інтерфейсу та надання REST API. Посібник з розробки вказує на Node.js v16 або пізнішу версію як вимогу, разом з Git і локальним робочим простором для побудови та запуску сервісу. Внутрішньо сервер організований на компоненти, такі як engine.js для планувальника, job.js для управління життєвим циклом завдань, workflow.js для двигуна робочих процесів і schedule.js для оцінки тригерів, що відображає модульний дизайн, який розділяє оркестрацію, виконання та планування.
Для збереження даних xyOps використовує pixl-server-storage з бекендами SQLite і файлової системи, кешуючи JSON-записи в пам’яті для підвищення продуктивності. За замовчуванням Docker-деплойменти зберігають дані в /opt/xyops/data в іменованому томі, з конфігураційними JSON-файлами в /opt/xyops/conf, тому стан і конфігурація відокремлені від файлової системи контейнера. Посібник зі масштабування документує параметри конфігурації для кешування SQLite і автоматизованих резервних копій, дозволяючи операторам налаштовувати розміри кешу та вмикати обертання стиснених резервних копій для вбудованої бази даних.
Веб-інтерфейс є односторінковим додатком, побудованим з використанням jQuery, фреймворку pixl-xyapp, CodeMirror, Chart.js і xterm.js, що забезпечує багатий інтерфейс для управління подіями, робочими процесами, серверами, моніторами, сповіщеннями та квитками повністю через браузер. Всі взаємодії користувача в кінцевому підсумку проходять через REST API, який надає кінцеві точки для подій, завдань, серверів, моніторів, сповіщень, квитків, користувачів та адміністративних операцій.
Розподілена архітектура агентів та супутників
xyOps використовує розподілену архітектуру з одним або кількома серверами-кондукторами та легкими супутниковими агентами (xySat), розгорнутими на керованих хостах. Кондуктор є центральною контрольною площиною, яка зберігає конфігурацію, планує завдання, відображає інтерфейс користувача та оцінює монітори та сповіщення. xySat працює на кожному цільовому сервері як виконавець завдань і збирач даних, виконуючи завдання від імені xyOps та передаючи назад метрики для використання процесора, пам’яті, диска та мережі.
Документація з самостійного хостингу описує, як можна запускати контейнерів робітників, використовуючи образ ghcr.io/pixlcore/xysat:latest, налаштований через змінну середовища XYOPS_setup, яка вказує на URL-адресу встановлення на кондукторі. Для розгортання на фізичних серверах або віртуальних машинах репозиторій xySat надає інсталятор в один рядок, який копіюється з інтерфейсу користувача xyOps, використовуючи шаблон curl | sh для отримання та встановлення агента з відповідним токеном автентифікації. Цей дизайн дозволяє операторам масштабувати обчислення та моніторинг без встановлення важких залежностей на кожному вузлі, оскільки xySat розроблений бути легким і самодостатнім.
Об’єднані функції операцій
Планування завдань та автоматизація робочих процесів
xyOps надає комплексний планувальник завдань, який підтримує традиційний синтаксис cron, фіксовані інтервали, одноразові таймери та вікна блокування для запобігання виконанню під час періодів обслуговування. Контроль паралельності та повторні спроби можуть бути налаштовані для кожного завдання, що робить його придатним для критичних пакетних процесів і довготривалих робочих навантажень, де потрібні точний час і обробка помилок. Події в xyOps визначають, що запускати, де і коли, включаючи сценарії оболонки, контейнеризовані завдання або дії, керовані плагінами, і можуть бути запущені за розкладом або вручну через інтерфейс користувача або API.
На додаток до базового планування завдань, xyOps пропонує візуальний редактор робочих процесів, який дозволяє операторам моделювати багатокрокову автоматизацію у вигляді орієнтованих графів. Робочі процеси можуть об’єднувати кілька завдань, додавати умовні гілки, обробляти помилки та передавати дані між кроками, ефективно перетворюючи скрипти на багаторазові, спостережувані інструкції. Це дозволяє виразити складні конвеєри розгортання, процедури усунення інцидентів або ланцюги обробки даних у такий спосіб, що вони є як виконуваними, так і підлягають аудиту.
Моніторинг серверів та метрики
Після підключення агентів xySat, xyOps автоматично збирає системні метрики з усіх підключених серверів, включаючи використання процесора, пам’яті, диска та мережі. Розділ “Сервери” в інтерфейсі користувача відображає перегляди цих метрик у реальному часі разом з історичними тенденціями, щоб оператори могли відстежувати використання ресурсів і потужностей з часом. Монітори визначаються за допомогою мови виразів, яка може посилатися на метрики та часові вікна, наприклад, вирази, які попереджають, коли середнє навантаження на процесор перевищує поріг протягом кількох хвилин.
Мова виразів і механізм моніторингу підтримують створення перевірок вищого рівня, які об’єднують кілька сигналів, що дозволяє здійснювати більш інтелектуальне оповіщення, ніж прості системи на основі порогів. Оскільки дані моніторингу зберігаються на тій самій платформі, що й планування завдань, стає простіше співвідносити виконання завдань зі сплесками використання ресурсів або збоями, що допомагає в аналізі першопричин.
Інтелектуальне оповіщення та квитки на інциденти
xyOps включає гнучку систему оповіщення, яка може спрацьовувати на складних умовах, визначених виразами моніторів, часовими вікнами та групами серверів. Коли умови виконуються, оповіщення можуть надсилати повідомлення, відкривати квитки або запускати завдання з усунення, що дозволяє реалізувати замкнуті цикли реагування на інциденти, які починаються з телеметрії і закінчуються автоматизованими діями.
Інтегрований модуль обробки заявок дозволяє відстежувати інциденти безпосередньо всередині xyOps, зв’язуючи заявки з завданнями, сповіщеннями та знімками серверів, які спричинили або були уражені проблемою. Це зберігає операційний контекст близьким до основних подій та телеметрії, зменшуючи необхідність переходу між окремими інструментами обробки заявок та моніторингу під час збою.
Плагіни, секрети та розширюваність
xyOps надає систему плагінів, яка дозволяє розширювати функціональність будь-якою мовою, з маркетплейсом для пошуку та встановлення плагінів спільноти. Плагіни можуть діяти як обробники подій, процесори даних або інтеграційні мости до зовнішніх систем, таких як хмарні провайдери та сервіси зберігання. Наприклад, плагін xyplug-s3 на npm надає інструменти для завантаження, завантаження та управління об’єктами в AWS S3 як частина завдань та робочих процесів xyOps.
Управління секретами вбудоване в платформу, забезпечуючи безпечне зберігання облікових даних, які можуть бути впроваджені в завдання та плагіни під час виконання. Це дозволяє уникнути жорсткого кодування секретів у скриптах або змінних середовища та інтегрується з автоматизацією та моніторингом робочих процесів, щоб чутливі дані оброблялися контрольованим чином.
Інструкція з встановлення
Системні вимоги та модель розгортання
Для розробки або ручного встановлення документація вказує Node.js v16 або пізнішу версію, Git та відповідний редактор коду як передумови, відображаючи ядро на базі Node. Продуктивні розгортання зазвичай виконуються через Docker, використовуючи образ ghcr.io/pixlcore/xyops:latest, з налаштуванням контейнера для відкриття портів 5522 і 5523 та монтування постійних томів для даних та конфігурації. Сервер або контейнер, що хостить xyOps, повинен бути доступним у мережі за стабільним ім’ям хоста, оскільки робочі сервери та супутники підключаються до диригента за ім’ям хоста, а не за сирою IP-адресою.
Вимоги до зберігання залежать від обсягу завдань та політик збереження, але керівництво по масштабуванню передбачає використання SQLite як основного сховища даних з налаштовуваними обмеженнями кешу та автоматизованими опціями резервного копіювання, що робить можливим запуск xyOps на скромних віртуальних машинах і масштабування за потреби. Рекомендації щодо розміру ОЗП та ЦП у документації з масштабування зосереджені на кількості одночасних завдань та розмірі флоту, заохочуючи операторів розглядати xyOps як легку контрольну площину, яку можна реплікувати для високої доступності.
Швидкий старт з Docker (Рекомендовано)
Найшвидший спосіб розгорнути xyOps – це використання одного Docker-контейнера, який об’єднує кондуктор, вбудоване сховище та веб-інтерфейс. Офіційна команда швидкого старту запускає образ ghcr.io/pixlcore/xyops:latest з параметрами –detach, –init та –restart unless-stopped, монтуванням іменованого тому xy-data до /opt/xyops/data, прив’язкою сокета Docker та відкриттям портів 5522 та 5523.
Типова команда швидкого старту виглядає так (спрощено для ясності):[9]
docker run
–detach –init –restart unless-stopped
–name “xyops01” –hostname “xyops01″
-v xy-data:/opt/xyops/data
-v /var/run/docker.sock:/var/run/docker.sock
-e XYOPS_xysat_local=”true”
-e TZ=”America/Los_Angeles”
-p 5522:5522 -p 5523:5523
ghcr.io/pixlcore/xyops:latest
Після запуску контейнера веб-інтерфейс доступний за адресами http://localhost:5522 (HTTP) та https://localhost:5523 (HTTPS), з обліковими даними за замовчуванням admin / admin для початкового входу. Конфігурація швидкого старту також активує локального працівника xySat всередині контейнера через прапор XYOPS_xysat_local, тому завдання можуть виконуватись негайно без налаштування зовнішніх агентів.
Docker Compose та налаштування з кількома кондукторами
Для більш надійних розгортань документація з хостингу надає приклад Docker Compose, який визначає сервіс xyOps з тим самим образом, ім’ям хоста, змінними середовища, томами та відображенням портів, як у прикладі з одним контейнером. Топології з кількома кондукторами підтримуються шляхом вказівки кількох імен хостів у змінній середовища XYOPS_masters, що дозволяє Nginx або спеціальному образу xyOps Nginx здійснювати балансування навантаження та перемикання між вузлами кондукторів.
Супутній контейнер xyops-nginx можна запустити, використовуючи образ ghcr.io/pixlcore/xyops-nginx:latest, монтувавши сертифікати TLS і вказавши на імена хостів кондукторів та порт, з вбудованим демоном перевірки стану, який динамічно переналаштовує Nginx на основі доступності кондукторів. Цей шаблон дозволяє операторам надавати доступ до xyOps через HTTPS з належними сертифікатами, зберігаючи кондуктори у внутрішній мережі.
Ручна установка (без Docker)
Для середовищ, де Docker не є бажаним, xyOps можна встановити вручну, клонуючи репозиторій GitHub, встановлюючи залежності Node.js та запускаючи наданий скрипт установки. Документація з журналу змін посилається на bash-потік install.sh, виконуваний у /opt/xyops, що відображає звичайне розташування сервісу Node.js на серверах Linux. Після встановлення xyOps налаштовується через JSON-файли в /opt/xyops/conf, з можливістю перевизначення та змінними середовища, що надають додатковий контроль для налаштування продуктивності.
Початкове налаштування та посилення безпеки
Система конфігурації зосереджена навколо основного JSON-файлу в /opt/xyops/conf/config.json, з змінами, внесеними через інтерфейс користувача, що зберігаються в overrides.json, накладеними на базову конфігурацію. Це дозволяє операторам підтримувати чисту, контрольовану версіями базову конфігурацію, при цьому динамічно налаштовуючи параметри через інтерфейс користувача без ручного редагування файлів.
Посібники з самостійного хостингу наполегливо підкреслюють важливість забезпечення того, щоб ім’я хоста xyOps було вирішуваним і стабільним, оскільки робочі сервери покладаються на це DNS-ім’я для підключення до API та отримання конфігурації. Налаштування TLS зазвичай здійснюється шляхом запуску xyOps за зворотним проксі, таким як наданий образ Nginx, який завершує HTTPS, використовуючи сертифікати, надані оператором, і пересилає трафік до кондуктора на порт 5522.
З точки зору безпеки, стандартні облікові дані слід змінити одразу після початкового входу, а доступ слід обмежити за допомогою мережевих контролів і облікових записів користувачів на основі ролей, використовуючи вбудоване управління користувачами та ключами API xyOps. Ключі API можуть бути створені через інтерфейс користувача, обмежені певними привілеями і передані в заголовках або параметрах запиту, що дозволяє безпечно інтегруватися з системами CI/CD, чат-ботами або зовнішніми інструментами.
Інструкція з використання та конфігурації
Додавання серверів та агентів xySat
Щоб додати сервери, адміністратори починають в інтерфейсі користувача xyOps, відкривають розділ Сервери і використовують процес “Додати сервер”, який генерує команду встановлення, адаптовану до цільової платформи. Для серверів Linux документація xySat показує однорядкову команду, яка завантажує та виконує інсталяційний скрипт з кінцевої точки API xyOps з токеном автентифікації, встановлюючи агента та реєструючи сервер. Після запуску xySat сервер з’являється у вигляді Сервери з живими метриками і може бути призначений до груп для цільового виконання завдань та моніторингу.
Створення вашої першої перевірки моніторингу
З серверами онлайн наступним кроком є визначення моніторів за допомогою мови виразів. Простий приклад у документації попереджає, коли середнє навантаження на процесор перевищує 2.0 протягом п’яти хвилин, виражене як cpu.avgLoad > 2.0 з відповідним часовим вікном. Монітори можуть бути прикріплені до конкретних серверів або груп, і налаштовані з порогами сповіщень, рівнями серйозності та каналами повідомлень, що дозволяє точно контролювати, коли спрацьовують сповіщення і хто отримує повідомлення.
Оскільки моніторинг і виконання завдань використовують одну платформу, оператори можуть співвідносити монітори з конкретними завданнями або робочими процесами, наприклад, щоб попередити, якщо нічне завдання ETL перевищує допустимі межі навантаження або не встигає завершитися вчасно. З часом визначення моніторів можуть еволюціонувати в закодовані SLO, які безпосередньо пов’язані з автоматизованими робочими процесами відновлення.
Створення автоматизованого робочого процесу (логіка тригер–дія)
Посібник з швидкого старту робочого процесу проводить через створення події, яка запускає простий shell-скрипт, планування його, а потім створення робочого процесу для оркестрації багатокрокового процесу. Робочі процеси складаються у візуальному редакторі шляхом перетягування вузлів, що представляють події, умови та дії, а потім з’єднання їх для визначення порядку і розгалуження. Дії можуть включати запуск завдань на конкретних серверах або групах, відправку повідомлень, виклик вебхуків або взаємодію з плагінами, що дозволяє створювати багаті ланцюжки тригер–дія.
Типовий робочий процес операцій може починатися з спрацьовування монітора, що, в свою чергу, запускає сповіщення, налаштоване на відкриття тікета і запуск робочого процесу відновлення, який збирає діагностику, перезапускає сервіс і публікує оновлення статусу в чаті. Оскільки xyOps пов’язує завдання, сповіщення, монітори та тікети, вся історія інциденту — включаючи знімки телеметрії та кроки відновлення — залишається видимою в одному місці для перегляду після інциденту.
