Como criar uma stack de aplicações acessível a principiantes sem transformar cada serviço numa dependência

Uma pilha de aplicações adequada a principiantes mantém-se fácil de compreender quando cada serviço tem uma única finalidade, é responsável pelos próprios dados e pode falhar sem desativar funções domésticas sem relação com ele.

O perigo não está apenas no número de contentores. A complexidade surge quando todas as aplicações dependem da mesma base de dados, camada de autenticação, proxy inverso, serviço DNS, caminho de armazenamento, janela de atualização e conta de administrador. Por isso, a pilha inicial deve assentar numa pequena base partilhada, manter as conveniências opcionais fora dos percursos dos serviços essenciais e documentar exatamente quais os componentes que têm de voltar a funcionar antes de cada aplicação poder ser utilizada.

Comece pelos resultados pretendidos pela família, não por um catálogo de aplicações

Antes de escolher o software, faça uma lista das tarefas recorrentes que o servidor tem de suportar. Uma primeira pilha útil poderá incluir cópias de segurança de dispositivos, um local partilhado para ficheiros e um serviço opcional de multimédia ou painel de controlo. Cada tarefa deve ter um utilizador identificado, um responsável pelos dados, um período de indisponibilidade aceitável e um plano de recuperação. As aplicações que não contribuam para nenhum destes resultados ficam para uma lista posterior.

A TechTarget define a arquitetura de aplicações como um mapa estrutural da forma como as aplicações interagem com middleware, bases de dados e outras aplicações para satisfazer as necessidades dos utilizadores. Esse mapa das necessidades dos utilizadores aos componentes é mais útil do que tratar cada aplicação disponível como uma funcionalidade independente.

Descreva a pilha inicial como três contratos de serviço, em vez de três nomes de produtos. Para cada contrato, defina que dados entram, que resultado sai e o que pode fazer a família quando o serviço está indisponível. Assim, as substituições futuras não obrigam a reformular todo o servidor.

Mantenha a base partilhada mais pequena do que a camada de aplicações

É razoável partilhar alguma infraestrutura. Várias aplicações Web podem usar o mesmo anfitrião, conjunto de armazenamento, método de monitorização e convenção de nomes local. O problema começa quando todas as aplicações dependem de um serviço central cuja falha impede de imediato qualquer acesso, autenticação, resolução de nomes ou armazenamento.

A análise de dependências circulares da TechTarget explica que os componentes fortemente acoplados se tornam difíceis de atualizar, testar e implementar de forma independente. O seu aviso sobre ciclos de dependências aplica-se a um servidor doméstico, mesmo quando a pilha é muito mais pequena.

Use apenas a infraestrutura partilhada mínima necessária hoje. Deve adicionar um proxy inverso, uma camada central de identidade ou um serviço de DNS interno porque várias aplicações estáveis beneficiam deles, não porque um diagrama pareça mais completo com mais uma caixa.

Atribua a cada serviço um responsável pelos dados e um caminho persistente bem definidos

Uma aplicação não deve encontrar o seu armazenamento por acaso. Defina que caminho contém a configuração, qual contém a base de dados, qual contém os ficheiros do agregado familiar e qual contém a cache descartável. Dois serviços podem ler a mesma biblioteca multimédia, mas não devem ser ambos responsáveis pela base de dados de metadados nem escrever indiscriminadamente em todo o conjunto de armazenamento.

A Better Stack explica que os dados persistentes dos contentores precisam de um ciclo de vida independente do contentor que os utiliza. Esse modelo de ciclo de vida independente dos dados é a base para substituir uma aplicação sem tornar ambígua a localização dos seus dados.

Use caminhos legíveis no anfitrião, como /srv/appdata/service, /srv/data/service e /srv/cache/service. Registe o proprietário, as permissões de escrita, a regra de cópia de segurança e o método de restauro para cada um. Os dados partilhados do agregado familiar devem ter uma única localização de referência, mesmo quando várias aplicações os indexam ou apresentam.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Crie percursos de acesso que continuem a funcionar de forma limitada

Um principiante começa muitas vezes com endereços IP locais e portas, depois acrescenta DNS local, HTTPS, um proxy inverso e acesso remoto. Cada camada facilita a utilização, mas também cria outro ponto em que uma aplicação pode parecer indisponível, apesar de estar a funcionar corretamente.

Um guia de homelab traça o percurso de um pedido através do DNS, do encaminhamento, de um proxy inverso, da aplicação e da respetiva dependência de base de dados ou armazenamento. Esse modelo em camadas do percurso dos pedidos ajuda um principiante a distinguir os problemas de acesso dos problemas da aplicação.

Atribua um nome local estável a cada serviço importante, mas mantenha um endereço direto documentado para situações de recuperação. O acesso remoto não deve ser necessário para administrar o servidor a partir de dentro de casa. O router, o resolvedor DNS e o sistema de autenticação não devem depender todos da mesma cadeia experimental de serviços.

Mantenha os Serviços Opcionais de Conveniência Fora dos Caminhos Essenciais

Painéis de controlo, índices de pesquisa, retransmissores de notificações, capas multimédia e autenticação centralizada podem melhorar a experiência sem serem necessários para manter os dados subjacentes disponíveis. Assinale-os como dependências opcionais, para que a falha de uma camada acessória provoque uma funcionalidade reduzida, em vez de uma interrupção total.

O guia de resiliência da TechTarget descreve o padrão de compartimentação como o isolamento de partes de um sistema, para que uma falha não provoque uma falha total em cadeia. Este princípio de isolamento de falhas traduz-se numa regra simples para uso doméstico: os caminhos essenciais de armazenamento, cópia de segurança e administração têm de continuar utilizáveis quando as camadas opcionais param.

Teste a infraestrutura parando um serviço opcional de cada vez. Os ficheiros partilhados devem continuar acessíveis quando o painel de controlo falha. A administração local deve continuar a ser possível quando o acesso remoto falha. Uma cópia de segurança não deve depender do índice multimédia, e um restauro não deve exigir o serviço de notificações que comunica o estado da cópia de segurança.

Atualize e Faça Cópias de Segurança dos Serviços como Unidades de Recuperação Independentes

Uma janela de manutenção não deve exigir que todas as aplicações sejam atualizadas ao mesmo tempo. Mantenha as definições dos serviços, os dados persistentes e as informações de versão suficientemente separados para que uma aplicação possa ser protegida, alterada, validada e revertida sem modificar cargas de trabalho não relacionadas.

A Backblaze defende que um plano de recuperação só é tão sólido como o seu teste mais recente e recomenda exercícios de recuperação repetíveis e com âmbito limitado. Esse teste de recuperação serviço a serviço é adequado a uma pequena infraestrutura autoalojada.

Antes de uma atualização, exporte a configuração, proteja a base de dados ou o estado da aplicação em causa e registe a versão atual. Depois, valide a aplicação com uma conta de utilizador comum e confirme as tarefas agendadas. Se uma atualização exigir alterações coordenadas em vários serviços, documente explicitamente essa dependência, em vez de só a descobrir durante uma interrupção do serviço.

Mantenha um registo simples de dependências junto do inventário de serviços. Para cada aplicação, registe o anfitrião, o caminho de armazenamento, a base de dados, o nome local, o método de autenticação e o destino da cópia de segurança de que realmente precisa. Assinale separadamente as integrações opcionais. Quando um componente for substituído, atualize apenas as linhas que dele dependem e execute essas verificações de recuperação. Assim, evita que uma ferramenta partilhada e conveniente se torne uma base não documentada para todos os serviços adicionados posteriormente.

Use uma stack inicial que possa crescer sem se tornar uma cadeia de dependências

Uma stack inicial duradoura costuma ter uma camada de sistema, um mapa de armazenamento, um percurso de cópia de segurança e um pequeno número de serviços destinados aos utilizadores. Adicione infraestrutura partilhada apenas quando duas ou mais aplicações estáveis precisarem dela e o percurso de recuperação continuar a ser compreensível sem ela.

O projeto de servidor compacto da ServeTheHome mostra como um pequeno sistema dedicado pode ser concebido em torno de uma combinação definida de capacidade de processamento, armazenamento e rede, em vez de ser expandido até se tornar uma plataforma sem limites. Este modelo de servidor com funções bem delimitadas é uma referência melhor para principiantes do que instalar todos os serviços de infraestrutura de uma só vez.

O guia da ZimaSpace sobre como construir um primeiro servidor com base em três serviços interligados ajuda a manter o âmbito inicial limitado. Um Mini servidor doméstico ZimaBoard 2 é adequado para uma stack compacta, centrada em aplicações, com armazenamento planeado e um número limitado de serviços. Um ZimaCube 2 AI NAS torna-se a base mais indicada quando o armazenamento com várias unidades, vários utilizadores domésticos, uma retenção mais prolongada e uma recuperação centrada no armazenamento já são requisitos essenciais.

A stack é fácil para principiantes quando adicionar, parar, atualizar ou substituir um serviço altera apenas os respetivos dados e a forma de acesso, em vez de obrigar todo o servidor doméstico a acompanhar essa alteração.