04.07.2017, 20:18, "Lucas Viecelli" <lviecelli...@gmail.com>: > Alguém utiliza o PostgreSQL com Docker em um ambiente de produção?
Tenho alguns serviços ainda com docker em produção, mas me arrependi disso já faz tempo e estou gradualmente mudando isso. O docker tem vários problemas com algumas coisas que são importantes para os meus ambientes (mas talvez não seja para o seu), como selinux (exigido por algumas auditorias) e ipv6. Mesmo nas coisas mais simples, ele consegue causar mais trabalho do que resolve, como quando embaralha as regras dos meus firewalls para fazer o NAT funcionar no bridge entre os containers (o que é tudo completamente desnecessário quando usando ipv6, se ele usasse endereços do escopo certo para redes locais: link-local e realm-local, por exemplo). E quando ele tenta mapear volumes inteiros na memória virtual do dockerd (se eu não me engano, ele faz um monte de mmap MAP_PRIVATE, sob copy-on-write, que precisa de espaço caso aconteça o write) e falha com "falta de memória" por causa do overcommit_memory=2 (mesmo com muitos GBs efetivamente livres na RAM) não é legal. </rant> E isso eu nem falei dele com o Postgres ainda. Concordando com o Leonardo e indo mais além, eu também preciso fazer muitas configurações de kernel para memória, rede e outros I/Os variados (parâmetros de SAN, por exemplo) nos servidores de banco de dados. E não dá para fazer isso só com o docker (nem com swarm+machine, se eu não me engano). Pior que isso, alguns parâmetros do Postgres atrapalham o docker e vice-versa (exemplo foi o overcommit_memory, que me obrigou a colocar swap desnecessariamente exagerados só para conseguir fazer o docker-pull de imagens gordas; também tem outro de ipv6 que eu não lembro agora). E tem inicialização de clusters, de tablespaces, configurações de replicação, de backup etc. Basicamente a única utilidade de um Postgres em docker seria para entregar o executável cru porque todo o resto precisaria ser feito por fora dele. E já que essa é a situação, então um repositório rpm/deb/apk junto com systemd/upstart faz isso melhor que o docker hoje em dia para ambiente produtivo. E as configurações externas viriam de um ansible/chef/puppet, que fica mais adequado para isso mesmo. Então recomendo algo parecido com o que o Leonardo disse: colocar o banco em uma (ou mais, claro) máquina própria, bare metal ou virtualizada. E deixar o docker só para as outras partes da sua solução, em máquinas diferentes. É o que eu tenho feito ultimamente, depois de passar pelo vale de desilusão do hype (mas admito que a mão está coçando para ir para o próximo hype e substituir os meus dockers por rkt). Agora, se a conversa for sobre ambientes para testes, então o docker pode ajudar bastante. Criar um container com o Postgres, já com um cluster interno inicializado e com um banco de dados carregado com dados de testes ajuda muito os desenvolvedores que souberem colocar a aplicação deles em um container e subir os dois localmente por um docker-compose. Mas desses dois containers, eu só levaria o da aplicação para produção, se muito. Boa sorte, -- Arthur Nascimento - tureba
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
