Open wilcorrea opened 6 years ago
1- colocar o docker-compose.override.yml
no .gitignore e deixar um docker-compose.override.yml.example
2- colocar o docker-compose.yml
no .gitignore e versionar um docker-compose.yml.example
3- colocar todas as propriedades em .env.example
, que deverá ser renomeado como .env
e utilizar elas dentro do docker-compose.yml
Massa viu @wilcorrea ! Eu acho que a opção 1 ou 2 seria totalmente válidos! Tendo em vista que até tem um .env.dist
já no projeto. O que tu acha @Luitame ? Já que tu quem propôs o docker no projeto pode falar com mais propriedade.
@dersonsena e @wilcorrea o que você decidirem aí tá beleza! =)
kkkkkk... Queremos tua opinião @Luitame ! Sai de cima do muro homi !
@dersonsena mano a minha escolha é a mesma (3) do @wilcorrea lá no grupo, mas não vejo problema em ser a (2) não.
Eu votei no 2 e 3 porque fica bem flexível e eu não fui muito com a cara do override (desde que vi isso a primeira) porque fiquei achando que pode gerar confusão para quem não está ligado nos funcionamentos dos esquema
@wilcorrea Pois arrocha na PR! Cria esse paranauê e já inaugura a primeira de muitas PR's suas =)
Versionar o docker-compose.yml pode ser problemático. Cada ambiente tem suas peculiaridades e quando uma configuração de ambiente é sincronizada entre dispositivos podem acontecer conflitos de portas ou outras diretivas.
O Docker Compose prevê isso (https://docs.docker.com/compose/extends/#example-use-case) e nos dá até a opção de usar o
docker-compose.override.yml
. Então temos algumas opções à seguir: