Comments 26
А в меня каждый раз летят помидоры, когда я говорю, что проще писать docker-compose для дева и k8s.yml для прода. Контейнеры должны быть гибкими и одинаково просто запускаться в любой среде.
Но все же нам кажется, что лучше иметь одинаковую платформу для dev и prod.
Можно и так. Но ведь кроме DEV есть еще SIT, UAT, Regression?
Дев может отличаться вплоть до того, что включены отладчики, дебаг логи и кучи других вещей, которые могут не только быть отключены, но даже и не включены в прод-кандидат пакет.
Чем лучше?
И вообще не обязательно виртуалки. Даже для билда могут подниматься временные облачные кубер ноды с нужными компиляторами, собирать, прогонять тесты на других временных виртуальных нодах, и деплоиться в более стабильный тестовый енвайрнмент. Все автоматом. все быстро, ибо нет лимитированного количества виртуалок. Все недорого, ибо все лишнее останавливается.
Выглядит, что если на проде k8s, то docker-compose новая сущность. И поддерживать надо будет две системы оркестрации. А насчёт практически нулевой сложности… из коробки нет чего-то вроде ingress. Виртуалка для k8s нужна ровно там где нужна и для docker-compose. И примаунтить в k8s PHP ничто не мешает.
Если отдельные сервисы, да с моками остальных, то может и есть какой-то смысл. На моей практике все, от фронтендеров и QA до CTO хотят полную систему из 30+ контейнеров (без репликации по дефолту) локально запускать. И те же фронтендеры пускай базово, пускай копипастой пишут конфиги подов, сервисов и т. д.
В docker-compose вам тоже строчку в секции volumes сервиса надо написать, а то и не одну, а то и сторонний (?) драйвер ставить
HostPath делает тоже самое, что и volumes.
Только прибить под нужно к ноде.
Чуть более сложный метод — local volumes.
Я не фанат куба на машинах штатных разработчиков, потому что это в общем сложно. Просто сказал, что конкретно эта пробелма — не проблема. В деве используется миникуб, там есть minikube mount $HOME:/host на хост машину.
Вы про запуск k8s в виртуалке? Ну, можно, наверное. У нас запускался непосредственно на хосте. minikube --native или как-то так.
А с docker-composе не привязаны? Вообще тут мне сложно сказать что-то. С современными виртуалками не работал для подобных задач. Какие-то средства наверняка есть, но, наверное, они к инфраструктуре виртуализации относятся, а не к docker/k8s. Манифесты и т. п. не должны меняться от того, что кубер в виртуалках крутится
Ещё проще, compose для дева и никаких k8s для прода. Должно сработать достаточно хорошо для 99.9% проектов.
Контейнеры просто запускаются и через docker run. Сложности со связью контейнеров друг с другом и локализацией проблем
K8s в проде и в разработке: четыре мифа