Налаштування Docker-контейнера для торгового бота

Чому торговий бот падає вночі: Docker і ресурси

Торговий бот найчастіше падає не через логіку стратегії. Його запускають на сервері «як є»: інтерпретатор, набір бібліотек і системні залежності встановлені глобально, поряд живуть інші сервіси, а сам процес стартує з консолі або простого скрипта. Поки навантаження рівномірне, це працює місяцями — до першого різкого руху ринку.

Вночі, коли потік ринкових даних і обсяг заявок зростають у рази, назовні виходить те, що накопичувалося тижнями. Витік пам'яті у процесі з'їдає доступний обсяг, обробник подій перестає встигати за чергою, і бот або падає з помилкою, або зависає, продовжуючи вважатися запущеним.

Позиції при цьому залишаються відкритими без контролю: стоп-заявки не виставляються, а повідомлення нікуди не надходять — дізнатися про збій вдається лише вранці за просіданням на рахунку.

Окрема причина — конфлікт залежностей. Оновлення системної бібліотеки заради сусіднього сервісу ламає сумісність із тією версією, на якій бот збирався, і він перестає стартувати взагалі.

Відновлення відбувається вручну: знайти потрібну ревізію, підняти процес, звірити стан позицій з біржею.

Docker закриває весь цей клас відмов. Бот отримує ізольоване середовище із зафіксованими залежностями, обмеження за пам'яттю та процесором, політику перезапуску і передбачуваний старт.

Нижче розбираємо, як налаштування Docker-контейнера для торгового бота прибирає нічні падіння і що саме перевіряється перед розгортанням.

Що дає контейнеризація торгового бота на сервері

Контейнер фіксує середовище бота цілком: версії бібліотек, змінні, параметри запуску і системні залежності. У Docker це описано одним файлом поряд із кодом стратегії — він однаково розгортається на ноутбуці, тестовому стенді та бойовому сервері.

Перезапуск за секунди замість ручного розбору

Політика перезапуску піднімає процес, що впав, без входу на сервер: бот повертається до роботи за секунди, а не за десятки хвилин, поки черговий читає логи. Вікно, у якому сигнали пропускаються, стискається майже до нуля.

Однакове середовище на тесті та в бою

Образ збирається один раз і запускається тим самим усюди. Клас відмов «на тесті працювало, на сервері ні» зникає: розбіжність версій бібліотек і налаштувань більше не відтворюється на бойовому рахунку.

Ізоляція: кілька стратегій на одному сервері

Кожен бот живе у своєму контейнері зі своїми залежностями та лімітами. Конфлікт версій між стратегіями зникає, а падіння одного процесу не тягне за собою інші — частка зірваних сигналів за портфелем падає.

Передбачуваний відкат версії

Кожна збірка отримує свій тег, тому повернення до попереднього стану — це запуск попереднього образу, а не відновлення з резервної копії. Робоча стратегія залишається доступною, поки нова перевіряється.

Варіанти розгортання: Docker, служба ОС, хмара

Варіант запуску визначають не зручністю розгортання, а вимогами біржі до підключення: запити приймаються лише з адрес із білого списку, торговий потік тримає одну довготривалу сесію, а розбіжність системних годинників із сервером біржі ламає підписи запитів.

До цього додається вимога переживати перезапуск, не втрачаючи стан позицій і не виставляючи дублі ордерів. Нижче — чотири реальні варіанти й те, як кожен закриває ці пункти.

Переїзд між варіантами проходить без ручної звірки угод, якщо стан, ключі доступу та журнали винесені за межі процесу: контейнер тоді перестворюється, служба перезапускається, а машина переноситься між регіонами.

Як ми налаштовуємо Docker-контейнер для торгового бота

Бот, запущений вручну на сервері, живе до першого збою: після перезавантаження він не піднімається сам, ключі доступу лежать у конфізі поряд із кодом, а логи зникають у нікуди — під час розбору інциденту незрозуміло, чому позиція залишилася відкритою.

Контейнер знімає ці ризики, але лише якщо він зібраний з урахуванням торгової специфіки: коректного завершення, обмежень ресурсів і винесення секретів. Розбираємо шість етапів, з яких складається налаштування.

1. Аудит поточного запуску. Дивимося, як бот стартує сьогодні, де зберігаються ключі, що відбувається з відкритими ордерами при падінні та куди пишуться журнали. Фіксуємо залежності й точки відмови — це база для схеми середовища.
2. Схема середовища. Визначаємо, які сервіси потрібні боту поряд: доступ до торгового API, база угод, кеш. Розділяємо, що потрапляє в образ, що монтується як том, а що живе в спільній мережі та переживає перезбирання.
3. Збірка образу. Залежності фіксуються в маніфесті, бот працює під непривілейованим користувачем. Журнали пишуться в спільний потік із ротацією — їх збирає система логування, нічого не втрачається при перезапуску.
4. Обмеження ресурсів і політика перезапуску. Задаємо ліміти пам'яті та процесора, перевірку живості й коректне завершення за сигналом: контейнер закриває з'єднання з біржею і не залишає «висячих» ордерів. Політика перезапуску піднімає бота після збою автоматично.
5. Секрети й ключі доступу. Ключі не потрапляють ні в образ, ні в репозиторій — вони монтуються на час роботи з обмеженими правами, окремо для тестового та робочого контуру. Ротація ключа не потребує перезбирання.
6. Перевірка на тестовому ринку та передача. Проганяємо бота на тестових ключах, розбираємо журнали за циклами угод, фіксуємо команди керування та передаємо документацію з навчанням команди.

Такий контейнер переживає перезапуск вузла й оновлення образу без втрати стану.

Що залишається у вас після налаштування контейнера

Контейнер із торговим ботом — це не «налаштували й забули», а відтворюваний артефакт: поки він описаний файлами та регламентами, його можна підняти на іншій машині, передати іншому інженеру й оновити без простою. Тому робота закінчується не запущеним процесом, а комплектом, який залишається у вас на руках.

• Конфігурація середовища — складальний файл із зафіксованими базовими образами та окремий файл змінних: ключі, ліміти, режими логування. Секрети не лежать усередині образу, інакше зміна ключа потребує перезбирання.
• Схема розгортання — де запускається контейнер, куди пише логи, які томи змонтовані та що в них переживає перезапуск, як влаштований обмін із біржею та сховищем стану.
• Правила доступу — хто і яким каналом заходить у контейнер, які порти відкриті назовні, де зберігаються ключі та як вони ротуються.
• Регламент оновлення — порядок випуску версії: збірка, перевірка на тестовому контурі, перемикання, строк зберігання попереднього образу для відкату.
• Інструкція з відновлення — покроковий сценарій підйому з нуля: що розгорнути, які файли підкласти, як переконатися, що бот знову бачить ринок.
• Журнал перевірок — дати й результат прогонів: старт, перезапуск, поведінка при розриві зв'язку, коректність зупинки за сигналом.
• Передача документації — усе перелічене лежить у репозиторії поряд із кодом, а не в листуванні.

Такий комплект знімає залежність від конкретної людини: контейнер розгортається на новому сервері, відкочується на попередню версію й іде на супровід без археології по чатах і нотатках.

Кейс: бот на Docker перестав падати в години волатильності

Команда вела торгового бота на виділеній машині: у спокійні години він працював тижнями, але в моменти волатильності — на відкритті ринків і після виходу новин — падав через пам'ять.

Про падіння дізнавалися вранці, піднімали процес вручну і лише потім бачили, скільки входів пропущено.

Ціна збою тут не в процесі, що впав, а в простої торгового процесу: поки бот лежить, сигнали не обробляються, а відкрита позиція залишається без нагляду. П'ять-сім таких падінь на тиждень — і помітна частина торгових сесій проходить повз ринок.

Що змінили

Бота перенесли в контейнер Docker: задали ліміти за пам'яттю, стан і журнал угод винесли в окремий том — перезапуск більше не втрачає відкриті позиції.

Перевірка живості дивиться не лише на процес, а й на доступність біржового з'єднання, а політика перезапуску піднімає контейнер автоматично, без участі чергового.

Метрики до і після: падінь на тиждень — було п'ять-сім, стало нуль ручних розборів; простій торгового процесу скоротився з десятків хвилин до одиниць; частка пропущених сигналів упала в рази. За квартал — жодного нічного втручання людини.

Ключовим виявився не сам факт контейнеризації, а те, що перезапуск повертає бота в ринок, а не просто піднімає процес. Такий самий контур — з обмеженням ресурсів і перевіркою стану — ми збираємо й для інших сервісів, де збій коштує пропущеної угоди.

Чим контейнер відрізняється від віртуальної машини для бота?

Контейнер — це процес у ядрі хост-системи, якому ядро обмежує видимість через простори імен, а споживання ресурсів — через ліміти. Віртуальна машина запускає власне ядро й цілий гостьовий дистрибутив поверх гіпервізора.

Звідси розходиться все інше: накладні витрати на ізоляцію, швидкість запуску середовища та клас захисту.

За швидкістю старту різниця на порядок величин. Контейнер піднімається разом із процесом бота — секунди, а на прогрітому хості — частки секунди. Віртуальній машині потрібно завантажити ядро, підняти служби, дочекатися мережі.

Для торгової логіки це прямо впливає на результат: перезапуск після падіння, оновлення стратегії або перенесення на інший вузол укладаються в коротке вікно, і бот менше часу проводить поза ринком.

Накладні витрати на ізоляцію теж різного порядку. Контейнер бере зріз спільних ресурсів хоста і не дублює ядро, тому на одній машині уживаються десятки ботів із різними стратегіями та різними наборами залежностей.

Віртуальна машина резервує ресурси під гостьову систему — частина потужності йде на саму ізоляцію, а не на обчислення.

Ізоляція процесів у контейнері достатня, але не абсолютна: спільне ядро означає і спільний ризик — уразливість або перевантаження одного сусіда зачіпає інших. Усередині контейнера ізольовані файлова система, змінні середовища, відкриті порти.

Ключі до біржі, конфіг і стан позицій тримаємо в окремому томі, тому перезапуск не втрачає локальний кеш і не потребує повторної ініціалізації.

Окрема віртуальна машина потрібна, коли вимоги жорсткіші: інше ядро або несумісна версія системи, регламент регулятора про розділення середовищ, прив'язка до апаратних інтерфейсів або чутливість бота до сусідів по хості, коли важлива передбачувана затримка.

Тоді ізоляція на рівні заліза виправдовує втрату в швидкості запуску — під такі сценарії ми й розводимо середовища.

Ризики та обмеження контейнера: часті запитання

Контейнер Docker ізолює бота та його залежності, але не скасовує власних точок відмови: зупинку процесу, оновлення базового образу, перенесення на інший майданчик.

Ці сценарії розбираємо до запуску — щоб поведінка при збої була передбачуваною, а не з'ясовувалася в момент відкритої позиції.

Швидкість реакції на ринок від контейнера майже не залежить: накладні витрати ізоляції мережі нижчі за затримку до біржі, а вузьке місце — ліміти за частотою запитів і логіка повторних надсилань.

Як зберігаються ключі доступу до біржі?

Ключі не потрапляють ні в образ, ні в репозиторій — передаємо їх через секрети, а права обмежуємо торгівлею без виведення коштів. Витік разом із копією образу виключено.

Чи можна перенести працюючого бота без простою?

Так: конфігурація та стан переносяться як артефакти, новий екземпляр піднімається поряд, перевіряється звіркою балансу, потім перемикається потік і старий гаситься. Простій — секунди, при перекритті нульовий.

Хто відповідає за оновлення образу?

Базовий образ фіксуємо й оновлюємо за регламентом: спочатку прогін на копії, потім перемикання. Відкат — на попередній тег у реєстрі, тому невдале оновлення не залишає бота без робочої версії.

Обговоримо задачу: аудит бота та план перенесення

Щоб аудит запуску бота зайняв дні, а не тижні, від вас потрібно небагато: репозиторій або архів із кодом, поточний спосіб запуску, список залежностей і доступ до тестового середовища.

Якщо бот уже десь крутиться — розкажіть, як він переживає перезапуск сервера й оновлення бібліотек: це одразу показує, які місця доведеться переробляти при перенесенні.

• Точка входу: як процес стартує сьогодні — скрипт, служба, ручний запуск, куди пишуться логи та де лежать конфіги.
• Середовище та залежності: версії мови й бібліотек, звернення до біржового API, що переноситься в образ, а що залишається секретом.
• Стан і дані: де зберігається стан стратегії, чи потрібен окремий том для журналу угод, що буде при падінні контейнера.
• Вузькі місця: незакріплені версії залежностей, права всередині контейнера, відсутність перевірки працездатності, ручні кроки в деплої.
• План перенесення в контейнер: опис образу та шарів, монтування конфігів, параметри запуску, мережа, політика перезапуску.
• Оцінка строків робіт: розбивка за етапами, що критично для першого запуску, що розумно винести в другу ітерацію.
• Передача в супровід: інструкція зі збірки й оновлення, порядок відкату на попередній образ, дії чергового при збої.

Опишіть задачу — що за бот, на чому написаний, як запускається зараз, який результат потрібен. Ми повернемося з оцінкою, планом робіт і межами відповідальності: без загальних слів про якість, з конкретними кроками та зрозумілим строком до першого запуску в контейнері.