Простий production deployment із systemd: переваги, обмеження та коли час масштабуватись

Що я маю на увазі під systemd-style deployment

Systemd-style deployment не означає:

«SSH на сервер, вручну скопіювати binary і перезапустити процес».

Це все ще має бути нормальний production process.

Типовий setup може виглядати так:

• application збирається в immutable artifact;
• artifact має version;
• deploy script копіює нову версію на сервер;
• systemd керує lifecycle процесу;
• process запускається під окремим user;
• секрети передаються через systemd credentials або спеціалізований менеджер секретів, а захищені файли середовища можуть бути простішим запасним варіантом;
• application має healthcheck;
• logs збираються централізовано;
• monitoring контролює availability та ресурси;
• попередня версія зберігається для rollback;
• backups виконуються автоматично.

Тобто ми все одно маємо deployment automation, observability і operational discipline.

Просто без окремого orchestration control plane.

У чому головна перевага такого підходу

Найбільша перевага systemd deployment не в тому, що він «дешевший».

Вона в тому, що в системі значно менше moving parts.

Що менше компонентів, то менше речей:

• які можуть зламатися;
• які треба оновлювати;
• які треба моніторити;
• які потрібно розуміти під час інциденту;
• які створюють нові abstraction layers.

Якщо application працює на одному сервері, то production architecture може бути буквально:

Client → Cloudflare → Server → Application → Database

Цю систему легко намалювати.

Легко пояснити.

І, що особливо важливо, легко дебажити.

Менша operational complexity

У простій системі інженер може швидко відповісти на базові питання:

• Чи працює process?
• Скільки він споживає memory?
• Який у нього exit code?
• Що в logs?
• Чи відповідає health endpoint?
• Яка версія зараз запущена?
• Коли був останній deploy?
• Чи можна повернути попередню версію?

Systemd дає дуже прозору модель процесів.

Немає scheduler, control plane, pod lifecycle, deployment controller, admission rules або distributed reconciliation loop.

Для маленької системи це може бути великою перевагою.

Не тому, що ці речі погані.

А тому, що кожна з них додає complexity budget.

Простішим стає debugging

Коли production incident трапляється на одному сервері, шлях до проблеми часто короткий.

Можна подивитися:

• systemd status;
• journal;
• process metrics;
• open connections;
• disk usage;
• memory pressure;
• health endpoint;
• application logs.

У distributed orchestrated environment проблема може знаходитися вже не лише в application.

Вона може бути у:

• scheduler;
• ingress;
• service routing;
• DNS;
• node;
• pod eviction;
• container runtime;
• operator;
• service mesh;
• network policy;
• resource requests;
• autoscaler.

Для великої системи цей trade-off може бути виправданим.

Для маленької це іноді просто зайвий простір для помилок.

Нижча вартість інфраструктури

Systemd deployment часто дозволяє дуже ефективно використовувати один сервер.

Особливо якщо application:

• написана як single binary;
• має невеликий memory footprint;
• використовує SQLite або невеликий PostgreSQL;
• не потребує великої кількості sidecars;
• не має десятків internal services.

У такій системі немає потреби оплачувати окремі nodes лише для того, щоб підтримувати orchestration layer.

Для невеликого бізнесу це може бути важливим.

Але навіть якщо hosting cost не критичний, простіша інфраструктура часто означає нижчу вартість підтримки.

І це іноді важливіше за рахунок самого сервера.

Systemd уже вміє багато корисного

Systemd часто недооцінюють як production supervisor.

Але він уже дає:

• automatic restart;
• restart policies;
• startup ordering;
• dependency management;
• environment loading;
• resource limits;
• service users;
• process isolation;
• filesystem restrictions;
• read-only paths;
• capability restrictions;
• CPU quotas;
• memory limits;
• watchdog integration;
• journald integration.

Наприклад, для невеликого backend можна обмежити process:

• MemoryMax=100M
• CPUQuota=50%

і не дозволити сервісу випадково з’їсти весь server.

Для багатьох невеликих applications цього більш ніж достатньо.

Де цей підхід працює особливо добре

Systemd-style deployment дуже добре підходить для систем, де topology проста і передбачувана.

Невеликий SaaS

Один backend, database, background jobs і кілька інтеграцій.

Якщо traffic ще не вимагає horizontal scaling, Kubernetes не обов’язково дасть бізнесу щось корисне.

Telegram-бот

Для одного bot backend orchestration часто просто не має сенсу.

Один process під systemd може бути і простішим, і надійнішим.

Internal tools

CRM, admin panels, business automation, reporting systems.

Особливо якщо ними користуються десятки або сотні людей, а не мільйони.

Landing pages та business websites

Для server-rendered site один binary за reverse proxy може бути майже ідеальним deployment model.

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

Background workers

Якщо їх невелика кількість і scaling не автоматичний, systemd instance units можуть закрити більшість задач.

Але systemd не вирішує все

Systemd добре керує processes на одному host.

І саме тут проходить його природна межа.

Як тільки основна проблема стає distributed, починаються складніші питання.

Наприклад:

• Як запускати 20 instances на 10 nodes?
• Як автоматично розподіляти workload?
• Як виконувати rolling update?
• Як зробити service discovery?
• Як переносити workload після падіння node?
• Як автоматично scale out?
• Як управляти сотнями deployments?
• Як централізувати policy management?
• Як ізолювати багато команд?

Тут orchestration уже починає давати реальну цінність.

Multi-node deployment швидко ускладнює картину

На одному сервері deploy простий.

На двох теж ще цілком manageable.

Але коли servers стає багато, виникає coordination problem.

Потрібно вирішувати:

• у якому порядку оновлювати nodes;
• як перевірити readiness;
• як уникнути одночасного downtime;
• як rollbackнути fleet;
• як тримати конфігурацію consistent;
• як знаходити healthy instances;
• як направляти на них traffic.

Це все можна автоматизувати самому.

Але в якийсь момент ви починаєте будувати власний маленький orchestrator.

І це вже сигнал, що час подивитися на готові системи orchestration.

Zero-downtime deploy теж не з’являється автоматично

З systemd легко зробити:

stop → replace binary → start

Але це дає короткий downtime.

Для багатьох applications кілька секунд downtime під час planned deployment є прийнятними.

Якщо ж zero-downtime є strict requirement, deployment стає складнішим.

Можна використовувати:

• blue-green deployment;
• два application instances;
• reverse proxy switching;
• socket activation;
• load balancer;
• rolling deployment по кількох hosts.

Це все можливо.

Але кожен такий requirement поступово зменшує перевагу простоти.

Autoscaling доведеться будувати окремо

Systemd не є autoscaler.

Якщо workload постійно змінюється і application потрібно автоматично scale out та scale in, доведеться або:

• писати власну automation;
• керувати instances зовнішнім інструментом;
• переходити до orchestration platform.

Для системи з predictable traffic це не проблема.

Для системи з різкими traffic spikes це може стати bottleneck.

Service discovery теж не входить у комплект

Якщо service один, discovery не потрібний.

Якщо їх три, можна мати static config.

Якщо їх десятки і вони постійно переміщуються між nodes, static configuration вже перестає бути зручною.

Orchestrators значною мірою існують саме для таких задач.

Secrets management потрібно продумати

Systemd deployment не означає, що secrets потрібно писати прямо в unit file.

Це погана практика.

Варто віддавати перевагу systemd credentials або спеціалізованому менеджеру секретів. Належно захищені файли середовища можуть бути простішим запасним варіантом; звичайні змінні середовища — не найнадійніший вибір для чутливих секретів.

Серед варіантів:

• systemd credentials;
• спеціалізований менеджер секретів, наприклад Vault або 1Password CLI;
• SOPS;
• належно захищені файли середовища як запасний варіант.

Головне, щоб secrets:

• не потрапляли в repository;
• не були world-readable;
• не логувалися;
• мали зрозумілий rotation process.

У Kubernetes є своя модель secrets.

У systemd-середовищі цю модель просто потрібно визначити самому.

Observability теж нікуди не зникає

Одна з небезпечних помилок:

«У нас один сервер, тому monitoring не потрібен».

Навпаки.

Production system має відповідати хоча б на базові питання:

• service доступний?
• latency нормальна?
• error rate зростає?
• CPU перевантажений?
• memory закінчується?
• disk заповнюється?
• database працює?
• backup останньої ночі успішний?

Systemd вирішує process supervision.

Він не замінює monitoring.

Простий production stack може мати:

• VictoriaMetrics для metrics;
• vmagent або Vector для collection;
• centralized logs;
• alerting;
• health checks;
• uptime monitoring.

Це все ще lean architecture.

Просто вона lean не за рахунок відсутності operational practices, а за рахунок відсутності зайвих layers.

Не варто плутати простоту з ручною роботою

Systemd-style deployment не повинен означати:

• вручну редагувати файли на production;
• копіювати binaries по SCP без versioning;
• перезапускати service «на око»;
• не мати rollback;
• не знати, яка версія запущена;
• зберігати secrets у shell history;
• не мати monitoring.

Це не простота.

Це відсутність process.

Хороший systemd deployment усе одно має бути автоматизованим і повторюваним.

Мінімальний production setup

Для невеликої системи хороший мінімум виглядає приблизно так.

Immutable artifact

Production binary не збирається прямо на сервері.

Він уже має бути протестований і versioned.

Dedicated user

Application не повинна працювати від root без необхідності.

Systemd hardening

Де можливо, варто обмежити:

• filesystem access;
• Linux capabilities;
• writable directories;
• memory;
• CPU.

Automatic restart

Для crash:

Restart=on-failure

з адекватним delay і rate limit.

Healthcheck

Application має мати endpoint або інший спосіб перевірити, що вона справді готова працювати.

Versioned deployment

На сервері варто знати:

• current version;
• previous version.

Це робить rollback простим.

Monitoring

CPU, memory, disk, service availability і application metrics.

Centralized logs

Навіть якщо journald достатній локально, для production часто корисно мати remote copy logs.

Backup policy

Особливо якщо database або uploads знаходяться на тому самому сервері.

Backup без регулярної restore-перевірки не можна вважати повністю перевіреним backup process.

Коли варто залишатися на systemd

Systemd deployment має сенс, якщо більшість таких тверджень правдиві:

• application працює на одному або кількох servers;
• traffic передбачуваний;
• horizontal autoscaling не потрібен;
• кількість services невелика;
• команда маленька;
• deployments не відбуваються сотні разів на день;
• кількасекундний maintenance window допустимий або zero-downtime легко реалізується;
• failover можна вирішити простими механізмами;
• infrastructure легко зрозуміти одній людині за короткий час.

У такій ситуації orchestration може додати більше complexity, ніж value.

Коли варто дивитися на Kubernetes або іншу orchestration platform

Ознаки вже інші:

• десятки або сотні services;
• багато nodes;
• workloads постійно переміщуються;
• потрібен automatic scheduling;
• потрібен autoscaling;
• deployments дуже часті;
• потрібні rolling updates на великому fleet;
• infrastructure використовують багато команд;
• потрібні standardized policies;
• service discovery стає складним;
• high availability вимагає автоматичного rescheduling;
• вручну управляти topology вже небезпечно.

У цьому випадку orchestration не є overengineering.

Вона починає компенсувати реальну complexity системи.

Короткий орієнтир для вибору

Systemd deployment не означає «без DevOps»

Це важливе уточнення.

DevOps practices не починаються з Kubernetes.

Вони включають:

• automation;
• repeatable deployment;
• infrastructure management;
• monitoring;
• incident response;
• backups;
• security;
• rollback;
• operational ownership.

Усе це можна робити і на одному сервері.

Тому правильніше казати:

systemd deployment зменшує orchestration complexity, але не скасовує operational responsibility.

Не треба будувати платформу раніше, ніж з’явилася платформна проблема

Це, мабуть, головний принцип.

Kubernetes вирішує справжні проблеми.

Але він вирішує проблеми певного масштабу.

Якщо у вас:

• один service;
• один server;
• кілька deployments на тиждень;
• predictable traffic;
• маленька команда;

то дуже ймовірно, що ваша головна infrastructure problem ще не orchestration.

Інженерний вибір має виходити з requirements, а не з популярності технології.

Простота теж має межу

Водночас systemd не варто перетворювати на релігію.

Якщо deployment scripts стають сотнями рядків shell.

Якщо nodes десятки.

Якщо потрібно вручну координувати failover.

Якщо кожен deploy викликає страх.

Якщо половина infrastructure code уже імітує scheduler.

Тоді «просте рішення» перестало бути простим.

І саме в цей момент додаткова abstraction може фактично зменшити complexity.

Висновок

Systemd-style production deployment може бути дуже сильним рішенням для невеликих і середніх систем.

Він дає:

• просту mental model;
• низьку operational complexity;
• прозорий debugging;
• невелику infrastructure footprint;
• хороший контроль ресурсів;
• швидкі deployments;
• менше moving parts.

Але він має природні межі.

Коли система стає distributed, dynamic і multi-team, orchestration починає вирішувати проблеми, які вручну підтримувати вже дорожче.

Тому питання не повинно звучати:

«Чи використовувати Kubernetes?»

Краще запитати:

«Яку конкретну проблему orchestration platform вирішить у нашій системі сьогодні?»

Якщо на це питання немає чіткої відповіді, можливо, Linux, systemd і добре автоматизований deployment поки що є не компромісом.

А найпростішим правильним рішенням.