Como construir um servidor de desenvolvimento doméstico para Git, imagens Docker, bases de dados e aplicações de pré-visualização

Crie uma plataforma de serviços estável, separe os dados persistentes dos artefactos reconstruíveis e garanta que todos os serviços de desenvolvimento podem ser recuperados sem ter de preservar o próprio anfitrião.

Para um ou dois programadores em casa, um único servidor Linux pode alojar o Git, um registo de imagens, bases de dados e aplicações de pré-visualização. A arquitetura só se mantém fácil de gerir se a identidade, as funções de armazenamento, a exposição à rede, as cópias de segurança e o restauro forem planeados antes de os serviços começarem a depender uns dos outros.

Atribua funções de serviço antes de escolher o hardware

Trate o Git, o registo de contentores, os motores de bases de dados e as aplicações de pré-visualização como funções de serviço distintas, mesmo quando partilham um anfitrião. O Git preserva o histórico do código-fonte; o registo armazena artefactos reconstruíveis; as bases de dados guardam o estado mutável das aplicações; as aplicações de pré-visualização são ambientes de execução descartáveis.

Estime a CPU e a memória com base nas compilações simultâneas, nos conjuntos de trabalho das bases de dados e nas pré-visualizações ativas. Estime o armazenamento com base nos repositórios, na retenção do registo, no crescimento das bases de dados, nos registos e na área de preparação das cópias de segurança. Assim, evita comprar um disco grande e deixar a memória tornar-se o primeiro estrangulamento.

Comece por utilizar um único nó de computação se for aceitável que fique indisponível durante o desenvolvimento. Separe os trabalhadores de compilação mais tarde, se as compilações em rajada começarem a sobrecarregar as bases de dados ou as pré-visualizações interativas.

Separe os dados persistentes, reconstruíveis e de recuperação

Não faça cópias de segurança de todos os bytes da mesma forma. Normalmente, é possível reconstruir um registo a partir do código-fonte e das instruções de compilação; uma base de dados não. Guarde os despejos da base de dados ou instantâneos consistentes separadamente do volume da base de dados em utilização.

Um plano prático de cópias de segurança alojado localmente demonstra o valor de automatizar o Git e as cópias externas como tarefas distintas, em vez de assumir que o próprio NAS é a cópia de segurança.

Crie um caminho de acesso privado

Atribua ao servidor um endereço LAN estável e um nome DNS local. Exponha as rotas de Git, do registo, da base de dados e das aplicações de pré-visualização apenas às redes que delas necessitam. O acesso remoto deve ser feito através de uma VPN privada ou de um percurso de proxy inverso autenticado, e não através de um conjunto de portas de serviço reencaminhadas.

Utilize contas de serviço e chaves de implementação separadas. Os programadores não devem partilhar uma palavra-passe de administrador, e as aplicações de pré-visualização não devem herdar credenciais que lhes permitam modificar repositórios Git ou o registo.

Escolha SMB ou NFS apenas para fluxos de trabalho com ficheiros que precisem realmente de uma montagem partilhada. O guia de compatibilidade de clientes SMB e NFS ajuda a manter a escolha do protocolo separada do acesso aos serviços das aplicações.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Faça corresponder a ordem de implementação ao grafo de dependências

Inicie os serviços por esta ordem: montagens de armazenamento, identidade, bases de dados, registo, Git e, por fim, aplicações de pré-visualização. As verificações de estado devem testar dependências reais sem reiniciar uma base de dados lenta apenas porque uma aplicação ainda está a iniciar.

Mantenha as definições de implementação, as migrações de esquema e as rotas do proxy inverso sob controlo de versões. Mantenha os segredos fora do repositório e indique claramente onde os restaurar. Um anfitrião de substituição deve conseguir recriar os serviços a partir das definições e do estado protegido.

Valide a configuração recriando uma aplicação de pré-visualização a partir de uma cópia limpa, obtendo a respetiva imagem, aplicando um restauro de teste da base de dados e acedendo-lhe pelo percurso previsto para o cliente.

Faça cópias de segurança para restaurar, não para acumular

Crie cópias de segurança dos repositórios, das cópias nativas da base de dados, da configuração dos serviços e dos segredos encriptados num destino que não esteja montado com permissões de escrita para todos os serviços. Mantenha pelo menos uma cópia fora dos limites de alimentação elétrica e de administração do servidor.

Faça um restauro trimestral para um espaço de nomes isolado. Confirme os utilizadores, as extensões, as tarefas agendadas, as permissões dos repositórios, a autenticação do registo, as rotas DNS e não apenas a presença dos ficheiros.

Expanda quando as filas de compilação atrasarem o trabalho interativo, a latência da base de dados aumentar durante o envio de imagens ou as janelas de cópia de segurança coincidirem com o horário de trabalho. Deixe de acrescentar funções ao mesmo anfitrião quando um serviço experimental puder esgotar os recursos ou as credenciais de que os serviços estáveis necessitam.

Regra final da configuração

A configuração é aprovada quando cada serviço tem uma função definida, estado protegido, um caminho de acesso controlado, um restauro testado e um critério mensurável para dividir ou expandir a topologia.