Чим менше досвіду — тим більше Kubernetes

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Це знову Мамкін Архітектор, і в мене для вас є тема, яка підняла цікаве обговорення в нашому каналі і може зацікавить вас також :) Але спочатку невеликий дисклеймер. Заголовок клікбейтний — дуже поважаю як сам Кубернетес, так і експертів у ньому. Ну а тепер — погнали!

Якийсь дядько в твітері заявив що docker compose в проді це антипатерн. «Воно було придумано для розробки, кококо». А я, наприклад, запускаю на ньому всі свої продакшн сервіси (привіт, bankoscan.com, який працює в мене в коридорі на домашньому серваку). Хтось тут неправий — і це не я.

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

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

Чому? Бо це максимально просто. Є можливість швидко докинути базу і якусь обвʼязку. Все зберігається в одному репозиторію (привіт, gitops). Одне і те саме запускається локально для розробки і віддалено. Підняти можна будь-як — rsync, ansible чи Portainer.

Одна з проблем — кастомні імеджи докера, тобто сама ваша апка. Їх треба кудись публікувати, або в безкоштовні і публічні реєстри, або заморочуватись з приватними. Але docker compose вирішує і цю проблему. Є така штука, як build, яка білдить імедж прямо на хості з сорсів. Реєстр не потрібен взагалі. Затягнув репо — і поїхали. Якщо чесно, то цей пост я почав писати саме через build і вирішення проблеми з публікацією своїх імеджів. А вийшло ось таке, і це може навіть краще :)

Мій прод піднімається з нуля за 10 хвилин на будь-якому VPS за $5. Спробуйте повторити це на кубері.