Dois projetos Compose podem partilhar um único contentor de base de dados em segurança?

Sim, quando a base de dados tem uma rede externa estável, bases de dados e utilizadores separados, uma definição explícita de responsabilidade pelo ciclo de vida e cópias de segurança independentes de qualquer um dos projetos de aplicações.

A decisão é importante quando duas aplicações auto-hospedadas devem reutilizar um único contentor PostgreSQL ou MariaDB para poupar memória. Os dois estados concorrentes são um serviço partilhado com isolamento entre inquilinos e atualizações, credenciais, reinícios e concorrência por recursos interdependentes. Comece com uma configuração guardada e dados descartáveis, observe um ramo de cada vez e pare se o teste aumentar o risco de perda de dados, permissões ou disponibilidade.

Defina as condições subjacentes à decisão sobre um serviço de base de dados partilhado entre projetos Compose

Registe o ambiente antes de alterar qualquer coisa: versões de software e firmware, identidades dos dispositivos, caminho de montagem ou de rede, espaço livre, permissões e o sintoma observável. A linha de base deve preservar detalhes suficientes para reproduzir o cenário em que duas aplicações auto-hospedadas devem reutilizar um único contentor PostgreSQL ou MariaDB para poupar memória.

O primeiro candidato é um serviço partilhado com isolamento entre inquilinos. O segundo é a dependência entre atualizações, credenciais, reinícios e concorrência por recursos. As redes Compose externas atuais definem o mecanismo ou limite de comandos utilizado no teste; não substituem a observação deste servidor doméstico específico.

Escreva a condição de aceitação e a condição de paragem antes de executar o discriminador. Um resultado aprovado deve alterar as evidências previstas por um dos ramos, mantendo os serviços não relacionados inalterados; um resultado reprovado deve devolver o sistema ao estado guardado, em vez de desencadear uma cadeia de correções especulativas.

Teste a afirmação sem reduzir o requisito original

Utilize este discriminador: ligue cada projeto através de uma rede externa, crie utilizadores com o menor privilégio possível e, em seguida, pare e atualize uma aplicação enquanto a outra está em execução. Mantenha constantes a carga de trabalho, o cliente, o caminho, o conjunto de ficheiros e o momento, para que o resultado possa ser atribuído à variável alterada.

Utilize o ciclo de vida das redes Compose para selecionar o campo que pode realmente separar os ramos e, em seguida, registe o respetivo carimbo temporal, estado de saída, texto do erro, identidade do dispositivo ou instantâneo, latência, bytes transferidos, permissões e estado de recuperação. Uma saída limpa do comando não é suficiente quando a identidade, a durabilidade ou o estado da aplicação são a afirmação em teste.

Repita o teste uma vez após um reinício, uma nova ligação, uma nova montagem ou uma cache fria, quando esse evento fizer parte da condição original. Se a primeira execução for destrutiva ou não for possível restaurar o ambiente, pare e reproduza o teste numa cópia descartável.

networks:
  database-net:
    external: true
# O ciclo de vida da base de dados pertence a um projeto de infraestrutura separado

Interprete os resultados aprovados, reprovados e excecionais

APROVADO: cada aplicação acede apenas ao seu esquema ou à sua base de dados e um dos projetos pode ser reimplementado sem recriar a base de dados partilhada. Registe a versão, a identidade e a carga de trabalho exatas que foram aprovadas, para que a conclusão permaneça condicional em vez de se tornar uma afirmação universal.

REPROVADO: o Compose down remove o estado partilhado, um utilizador consegue ler a base de dados de outro, ou as migrações e os picos de recursos afetam ambas as aplicações. Um resultado reprovado não prova automaticamente o ramo oposto quando a rede, a memória, as permissões ou a consistência da origem podem influenciar ambos; isole essas dependências partilhadas antes de escalar o diagnóstico.

RESULTADO EXCECIONAL OU AMBÍGUO: separe as bases de dados ou implemente um projeto Compose de infraestrutura dedicado que seja responsável pelo serviço partilhado. Preserve os registos e não execute comandos de reparação, limpeza, destruição, reparticionamento ou alteração recursiva de propriedade até existir uma cópia recuperável.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirme a decisão com a carga de trabalho original

Aplique a ação correspondente ao ramo observado e, em seguida, repita a condição original, em vez de uma versão reduzida. A decisão só é válida quando cada aplicação acede apenas ao seu esquema ou à sua base de dados e um dos projetos pode ser reimplementado sem recriar a base de dados partilhada ao longo de dois ciclos ou do reinício, suspensão, interrupção ou transição de carga relevante.

Utilize as redes Docker dedicadas para verificar o fluxo de trabalho dependente mais próximo, mas mantenha inalterado o acionador original. Os conjuntos de dados, partilhas, contentores, utilizadores e pontos de recuperação não relacionados devem manter o acesso e os tempos anteriores.

O limite de paragem é explícito: se o Compose down remover o estado partilhado, um utilizador conseguir ler a base de dados de outro, ou as migrações e os picos de recursos afetarem ambas as aplicações, volte à última configuração verificada, conserve as evidências e escale para um teste mais aprofundado da plataforma ou do hardware apenas quando o ramo for reproduzível.

Depois de obter o resultado pretendido, compare-o com as políticas de reinício dos serviços, para garantir que a correção não transfere o risco para um serviço vizinho. Um teste-alvo bem-sucedido com uma nova falha de cópia de segurança, identidade, tempo limite ou disponibilidade continua a ser uma alteração falhada.

FAQ

No caso de um serviço de base de dados partilhado entre projetos Compose, as pesquisas restantes normalmente dizem respeito a saber se o depends_on pode gerir uma base de dados noutro projeto, se ambas as aplicações devem partilhar um utilizador da base de dados e quem executa as cópias de segurança e as atualizações da base de dados. As respostas abaixo mantêm esses casos-limite separados da decisão principal.

O limite de aceitação não muda: cada aplicação acede apenas ao seu esquema ou à sua base de dados e um dos projetos pode ser reimplementado sem recriar a base de dados partilhada. Se uma condição de seguimento alterar o sistema de ficheiros, a identidade, o caminho de rede ou a versão da aplicação, repita apenas o discriminador afetado por essa alteração.

Pare de alargar a experiência quando o Compose down remover o estado partilhado, um utilizador conseguir ler a base de dados de outro, ou as migrações e os picos de recursos afetarem ambas as aplicações. Nesse ponto, separe as bases de dados ou implemente um projeto Compose de infraestrutura dedicado que seja responsável pelo serviço partilhado; preserve as evidências antes de escalar o caso para o responsável pela plataforma, pelo armazenamento ou pelo hardware.

O depends_on pode gerir uma base de dados noutro projeto?

Não diretamente entre modelos de projeto independentes; utilize verificações de estado e tentativas de repetição da aplicação.

As duas aplicações devem partilhar um utilizador da base de dados?

Não. Utilize credenciais separadas e concessões com o menor privilégio possível para auditoria e contenção.

Quem executa as cópias de segurança e as atualizações da base de dados?

Um responsável ou projeto de infraestrutura dedicado, não a aplicação que por acaso iniciar primeiro.

No caso de um serviço de base de dados partilhado entre projetos Compose, a resposta prática continua a ser condicional: cada aplicação acede apenas ao seu esquema ou à sua base de dados e um dos projetos pode ser reimplementado sem recriar a base de dados partilhada. Quando o Compose down remover o estado partilhado, um utilizador conseguir ler a base de dados de outro, ou as migrações e os picos de recursos afetarem ambas as aplicações, separe as bases de dados ou implemente um projeto Compose de infraestrutura dedicado que seja responsável pelo serviço partilhado; um sucesso parcial que não consiga suportar a carga de trabalho original não é compatibilidade.