Кожен сеньйор, у якого я питав, казав одне й те саме: Docker Compose не для проду, бери Kubernetes, Compose — це для ноутбука. А я взяв і викотив Docker Compose у прод — реальний застосунок, живі користувачі, справжнє навантаження. І воно просто працювало. Не «ледве вижило», а спокійно й надійно — місяцями.
Це історія про те рішення, про цифри за ним і про те, чому найважчою виявилась зовсім не техніка.
Три дні, які перепрошили мені голову
Мій найперший docker-compose.yml — це WordPress і MySQL. І я провозився з ним три дні.
Три дні конфліктів портів. Три дні я дивився на базу, яка навідріз відмовлялася приймати підключення. Три дні я не розумів різниці між контейнером і образом — чесно думав, що це одне й те саме. Добив мене порт 3306: він був уже зайнятий, бо MySQL крутився прямо на машині, а я навіть не підозрював, що колись його поставив. Цілий вечір пішов на один рядок.
Сьогодні той самий стек я піднімаю за три хвилини. Але за ті три дні не шкодую ні секунди — вони назавжди змінили те, як я думаю про інфраструктуру. Бо всередині крихітного compose-файлу були всі справжні проблеми проду в мініатюрі: service discovery, мережа, volumes, конфіги, порядок запуску залежностей. Compose — це зменшена модель будь-якого складного інфраструктурного питання, яке тобі коли-небудь поставлять.
Як «прод» виглядав насправді
Промотаємо вперед. Застосунок: web-сервіс із базою, кешем і фоновими воркерами. Помірний, передбачуваний трафік. Близько 500 користувачів.
Ось і вся конструкція:
- Docker Compose на одній VM
- Nginx як reverse proxy із SSL
- Health-check'и та авто-рестарт
- Blue-green деплой через один нудний bash-скрипт
- Моніторинг на Prometheus + Grafana
- Автоматичні бекапи, назовні з машини
Підсумкова вартість інфраструктури — $40 на місяць.
Еквівалент на Kubernetes — managed control plane плюс ноди — я оцінив у $200–400 на місяць, і це ще не рахуючи годин мого життя на його обслуговування. Аптайм за півроку — 99.9%. Жодного підйому о третій ночі. Жодних загадкових evictions. Жодного дебагу service mesh, який потім довелося б комусь пояснювати.
Урок із того першого файлу досі чинний
- Інфраструктура як код. Усе оточення — у файлі, який можна прочитати, порівняти й відкотити.
- Відтворюваність.
docker compose upдає той самий результат щоразу. - Ізольовані, композовні сервіси. Кожен робить свою справу й спілкується описаною мережею.
Застосунку на 500 користувачів не потрібна оркестрація контейнерів. Йому потрібні VM, compose-файл та інженер, який реально розуміє trade-off'и. Over-engineering — це не про «просунутість». Це той самий інженерний провал, просто дорожчий і на вигляд солідніший.
Найскладнішою була не техніка
Скажу чесно про те, про що не попереджають: техніка була легкою частиною. Війною було — відстояти рішення.
На кожному код-ревʼю хтось питав про Kubernetes. На кожній зустрічі з архітектури хтось піднімав питання масштабування — під трафік, якого не було й за будь-якими чесними прогнозами ще довго не передбачалося. У індустрії справжня залежність від складності, і «а раптом колись доведеться масштабуватись» — її улюблена фраза.
Тому я завів один гранично простий документ: поточні користувачі, поточне навантаження, прогноз росту. Щоразу, коли зринало питання про Kubernetes, я показував на цифри. Цифри жодного разу не виправдали складність. Не виправдовують і досі.
Підганяй складність під задачу, а не під резюме
Мораль тут не «ніколи не бери Kubernetes». Kubernetes чудовий, коли твоя задача справді має форму Kubernetes. Мораль вужча й корисніша: підганяй складність інфраструктури під складність задачі.
Найкраще інфраструктурне рішення того року — це коли я вибрав НЕ будувати щось вражаюче. Нудна технологія, що тихо працює в проді, обійшла всі розумні альтернативи на столі — за грошима, за аптаймом і за моїм власним сном.
І ось питання до тебе, те саме, що я поставив своїй стрічці: яке найнудніше технічне рішення зекономило тобі найбільше нервів? Бо з мого досвіду нудний, очевидний вибір найчастіше і є найпрофесійнішим у кімнаті.