slurm.io )

В пень

посещал?

Коллега пойдет.

хрыч перелогинься

А вообще я за практиу

Какие-то проблемы, личные счёты?

у тебя мнение основано на слухах. я посещал, мне понравилось.

Мне достаточно неорганизованности первых слермов

опять же сам присутствовал? или ктотто написал на хабре и ты прочитал?

Кубирнетис хард вей - наш выбор

Не обязательно что-то делать, чтобы понять, что это неэффективно или тупик

забаньте меня, но ты походу долбоебушка.

А, по-моему, ты 😂

Можно и видео на ютуб

Добрый вечер, посоветуйте пожалуйста хороший гайд для начала работы с кибернетис

Кубирнетис хард вей - наш выбор

Кубирнетис хард вей - наш выбор

Если серьезно, то очень хорошим стартом будут видосики от Флант, доступные с конференций хайлоад и рит

нахуй иди.

нахуй иди.

Тут группа не для срачей..Хочешь оскорблять в личку пиши. А не малолетний ли ты дебил?

хрыч перелогинься

Один файл на один инстанс, а переменные прокидывать через env Для дева и стейджа возможно один и тот же компоуз будет, а вот для прода всяко другой

Коллеги привет! ПОдскажите, для конфигурирования нескольких сред (dev, stage, prod) без ci/cd лучше использовать несколько docker-compose файлов или использовать 1 docker-compose и переменные среды проставлять в .env

В разных папочках же все находится?

Верно, поэтому все в отдельных папках для разных окружений

плюс это не решает проблему - тебе как-то надо доставлять компоуз и .env на удаленную машину

хз о чем ты, не понимаю ход твоих мыслей но поясню за свой метод у меня репа - в которой хранятся stage/prod/dev папочки с кмпоуз-файлами и прочее это все лежит на трех серверах с помощью гитлаба я собираю образы, в зависимости от ветки/коммита образу задается тег окружения (опять же prod/dev/stage) и всего лишь одной командой (service update) все это обновляется и никуда ничего мне не надо доставлять))

ах, у тебя сворм )

мне казалось, что тип итак спрашивает за него, раз собрался разносить свои образы на несколько окружений

у меня 2 сервера и локалка. Я часто пользуюсь командами docker-compose, поэтому я не стремлюсь все максимально автоматизировать. Мне не понравилась идея override compose файлов, по этому и спросил) Ты подкинул идею за разные папки с композами, что мне тоже не оч нравится со стороны юзабельности. Я думаю сделатьотдельный env проект, который будет на одном уровне с проектами и как раз держать в себе композ файлы. .env сделаю как .env.prod, .env.dev и на нужном сервере скопировать нужный в просто .env хотел еще сделать docker-compose.dev.yml, но по ходу запустить из командной строки его напрямую нельзя

не, забудь, наврал, компоуз вроде не умеет

ok (

всё, проверил, вспомнил docker-compose -f docker-compose.dev.yml build и т.д.

Выглядит мерзко. Сколько раз народ обжигался на build через компоуз. То кэш не сработает. То наоборот. А ещё те же .env, которые непредсказуемо подставляются

Я уж не говорю, что без костылей не умеет в порядок запуска сервисов

в том числе

без него контейнер не будет резолвит другой контейнер по имени

так если упал условный db, то те, которые зависят от него (app) - не стартанут

Нет, в штатном депендс_он - стартанут