ну если у тебя микросервисная архитектура из 1 сервиса и бд, то да 👍
а докер компоуз не предполагает микросервисной архитектуры? 🤔 Хотя да, получается, что нжинкс, например, отдельным контейнером нужно делать. Допустим есть монолитное приложение и лендинг с разными зависимостями тот и тот. Это ещё 2 контейнера. И получается, когда такой взаимосвязанный пучок контейнеров, то лучше компоуз делать и всё это в рамках одного пода? А если приложение начинает делиться на микросервисы, то их лучше пихать в отдельные поды, где ещё один нжинкс поднимать, при необходимости в рамках этого другого пода?
Docker Compose это пару контейнеров в одной сети и с общими вольюмами, в основном под тесты и локальные небольшие проекты, как выше сказали. А кубер - инструмент оркестрации, который в отличии от компоста предусматривает технологии масштабирования, управлением состоянием подов и их обновление, используется в больших прод средах.
ну да, это понятно. Вопрос мой скорее чтобы отделить для самого себя, что нужно делать на уровне compose, а что на уровне кубернетиса и подов. Чтобы потом не делать лишней работы и не удалять кучу строчек из compose.yaml.
может какие-нибудь бестпрактис почитаешь
Кубер надо если: 1) Твое приложение должно быть отказоустойчиво 2) Тебе нужно много одинаковых инстанций одновременно 3) Сложная инфа (много сервисов)
есть хорошие линки?
4) ещё можно было бы добавить разные виды деплоя (канари, blue green ...) 5) работу с креденшиалсами
Сикреты ты имел в виду?
я думаю, что общее правило тут, наверное, нужен ли контейнеру будет отдельный айпишник и сможет ли он быть вообще на другой машине? Если да, то планировать его заранее как отдельный под?
Обсуждают сегодня