O que são servidores imutáveis?

Existem algumas perguntas sobre servidores imutáveis , como:

• Como implementar o padrão imutável do servidor sem perder a capacidade de executar post-mortems?
• Qual o papel que as ferramentas de Gerenciamento de configuração desempenham na infraestrutura imutável?

Parece óbvio que isso tem a ver com servidores (a parte que recebo). E apenas digerindo a gramática do imutável , eu acho que tem algo a ver com "não é possível silenciar ". Se esse palpite estiver próximo, eu não tenho idéia do que exatamente não pode ser silenciado (e duvido que tenha a ver com placas de som ou algo assim ...).

Minhas perguntas :

• O que é realmente um "servidor imutável" (no contexto do DevOps)?
• Por que eles são usados?

Imutabilidade é um termo frequentemente usado nos círculos da ciência da computação, que geralmente se resume a "não é possível mudar após a criação". É normalmente usado em referência ao paralelismo, simultaneidade e segurança de threads.

A discussão desse tópico é fascinante, mas geralmente pode ser encontrada em outros lugares no Stack Overflow . Estou resistindo à vontade de mergulhar aqui. O conceito principal é 'não é possível mudar após a criação'.

Imagine se, na Amazon, você implantar um serviço da Web inserindo-o em uma imagem de máquina (AMI - uma instância pré-criada que você pode re-provisionar repetidamente). Ele se conecta a um banco de dados back-end por meio de credenciais que sai de um registro na inicialização. Despeja os logs em uma ferramenta de registro como o Splunk. Para uma operação diária normal, você não tem motivos para colocar ssh nesta caixa. Se você precisar ampliar esse serviço, basta criar mais instâncias dessa AMI e ajustar um balanceador de carga. Girar para baixo é simplesmente a destruição de instâncias e balanceadores de carga.

Para a operação diária, esta caixa não tem motivos para alterar . Podemos apenas disparar mais da AMI.

O que acontece quando você precisa fornecer um patch de segurança no nível do sistema operacional? É quando você decide: você cria uma nova AMI com o patch instalado e reimplementa todas as instâncias em execução, ou ssh nas imagens existentes e atualiza o patch? Há muita gente que simplesmente se interessa. Os adeptos da 'arquitetura imutável' apenas me gritaram por sugerir que isso é possível.

Os imutabilistas (se houver essa palavra) advogam o cozimento do novo ami. Eles defendem a remoção de todos os motivos para ssh em uma máquina de todos os tempos. Eles defendem que qualquer configuração específica da máquina aconteça na inicialização dessa máquina, retirando os detalhes da configuração de um repositório. Esta é a expressão máxima de 'gado, não animais de estimação'.

A arquitetura imutável refere-se especificamente às configurações da máquina que não têm motivos para mudar após a criação da imagem da máquina . Se algo precisar mudar, crie uma nova imagem de instância, desligue a antiga, abra a nova.

As tecnologias em nuvem mudaram a fronteira entre hardware e software, de modo que muitas operações técnicas anteriormente cidadãs exclusivas do mundo do hardware também são objetos do domínio do software. Os ambientes de computação compartilhados podem ser tão antigos quanto os próprios computadores ^1, mas as tecnologias em nuvem podem popularizá-los, oferecendo metáforas convenientes e familiares para interagir com eles: os usuários da nuvem reservam uma instância, um computador completo ou uma imitação, enquanto os ambientes de computação compartilhados mais antigos têm todos os recursos possíveis. de limitações difíceis e "seu programa precisa ser carregado nesse servidor FTP, será executado no ambiente X (geralmente com 10 anos de versão anterior do software que você deseja usar), por no máximo 60 minutos" pode parecer familiar para usuários antigos ou reais de centros de computação.

A conseqüência prática dessa mudança é que agora os procedimentos de implantação podem ser representados por artefatos de software. (Os procedimentos de implantação são as instruções que explicam como configurar uma infraestrutura, com bancos de dados, servidores da Web ou o que pertence a essa infraestrutura, junto com a rede em que eles são executados.) Equipada com essas novas lentes, a manutenção manual dos servidores parece muito correção manual do código de produção - que é apenas em ocasiões muito raras uma coisa desejável. A manutenção manual é suscetível de introduzir discrepâncias entre os sistemas realmente em produção e o código que descreve esses sistemas, o que, por sua vez, significa comportamento irreprodutível e análise impossível de erros, correção dupla de erros e outras calamidades.

O padrão imutável do servidor é apenas a transposição para as operações na nuvem do mantra acima, segundo o qual devemos evitar a manutenção manual dos programas em execução. Em vez de configurar manualmente os servidores, o padrão imutável do servidor recomenda automatizar essa configuração.

Tipos de implementação

Embora a idéia geral do padrão imutável do servidor seja bastante clara, existem muitas nuances de implementação. Por exemplo, algumas abordagens sugerem não atualizar servidores, mas substituir sistematicamente os servidores. Isso ocorre porque a atualização gera uma situação em que uma implantação consiste em servidores iniciados em vários momentos distintos e passando por vários processos de atualização distintos, o que implica em um conjunto não homogêneo de servidores e pode levar a sutis diferenças na maneira como os servidores lidam com seus trabalhos. Um segundo ponto de variação popular é a disciplina referente ao acesso remoto aos servidores. Alguns gostam de desativar o acesso administrativo completamente remoto aos servidores, a fim de garantir que a manutenção manual nunca aconteça.

Nota do histórico

Que eu saiba, o termo “servidor imutável” foi popularizado por Kief Morris, mas a ideia em si é muito mais antiga. Em 1999, as cadeias do FreeBSD já popularizaram a idéia de automatizar completamente a configuração de ambientes de computação descartáveis. Foi assim que comecei a implementar o padrão de “servidor imutável” muitos anos antes de ouvir esse nome para descrever essa técnica.

A imutabilidade, disfarçada de imutabilidade física baseada em CD-ROMS, também tem sido uma medida popular para fabricar sistemas de computação confiáveis. Isso não deve ser confundido com o padrão imutável do servidor.

Servidores imutáveis ​​são servidores nos quais nenhuma alteração pode ser feita (além de atualizações e patches de segurança, idealmente). Em vez de alterar o software no servidor, instale um novo servidor no software desejado e, em seguida, encerre o antigo.

Esse conceito ajuda a garantir que seu servidor de teste, desenvolvimento e controle de qualidade seja idêntico, o que é importante por vários motivos fora do escopo desta pergunta. Outro benefício de servidores imutáveis ​​é a capacidade de reverter o aplicativo para um servidor antigo. Por exemplo, preciso alterar K no servidor de produção 1, para fazer o spool do servidor 2 e alterar K. Agora, depois de 10 minutos, percebo que K quebrou algo no meu aplicativo, em vez de precisar corrigi-lo imediatamente, o que poderia levar horas e, potencialmente, causar tempo de inatividade para meus clientes, redireciono o tráfego de volta ao servidor 1, enquanto descubro o que há de errado com 2.

A melhor explicação pode ser encontrada (como sempre) no artigo bliki de Martin Fowler sobre Servidores Imutáveis .

Um servidor, seja um hardware ou um servidor virtual na nuvem, geralmente possui um sistema operacional e um aplicativo em execução.

Freqüentemente, o aplicativo e os componentes do sistema operacional exigem configuração e alterações a serem aplicadas. Por exemplo, patches de segurança, a implantação de novas versões do aplicativo e a configuração são alteradas.

Quando você considera que qualquer alteração é uma mutação no estado do servidor, o termo immutablecomeça a fazer mais sentido. Isso significa que nenhuma mutação é permitida nesse servidor.

Geralmente, quando as pessoas estão envolvidas na alteração do estado do servidor - seja a implantação de uma versão, alteração de configuração ou caminho de segurança. O resultado é um servidor que não está mais funcionando conforme o esperado. Por exemplo, o aplicativo pode não ser executado agora devido a configurações incorretas etc.

É por isso que é estabelecida uma prática para a criação de servidores imutáveis . Com servidores imutáveis , uma imagem de um servidor é criada com todas as configurações, patches e versões de aplicativos agrupadas. Em seguida, essa imagem de servidor pode ser usada para criar servidores em vários ambientes.

O primeiro ambiente em que essa imagem é usada seria um ambiente em que a imagem possa ser testada para funcionar. Qualquer anormalidade é detectada e somente então essa imagem pode ser promovida para um ambiente de produção para substituir os servidores por uma nova versão (que é conhecida por funcionar bem).

Depois que o processo de criação e promoção das imagens é automatizado, você obtém um processo à prova de falhas que envolve muito pouco esforço humano e muito poucas chances de apresentar falhas em seu serviço.

Servidores frequentemente imutáveis ​​nem sequer incluem uma maneira de "entrar" neles, como por exemplo, o servidor ssh está ausente. Nesse caso, também é comum que toda a metrologia de um servidor (métricas, logs) seja enviada para sistemas externos, como um banco de dados de métricas ou um serviço de agregação de logs.

Com os contêineres (consulte: Docker ), também existe um processo para criar imagens e depois gerá-las nos contêineres em execução. Geralmente, eles são substituídos por novos contêineres baseados em imagens atualizadas e nunca são alterados. Significando que nenhum ser humano entra no contêiner para "consertar algo" introduzindo uma alteração.

Vamos começar com o inverso, o que é um servidor mutável?

Tradicionalmente, uma infraestrutura de servidor mutável é aquela que é continuamente modificada e atualizada no local. Você pode proteger o shell, atualizar pacotes, configurá-lo, instalar serviços e implantar um novo código nele. É isso que o torna mutável; você pode transformá-lo ou modificá-lo.

Uma infraestrutura imutável é outro paradigma de infraestrutura em que os servidores nunca são modificados após a implantação. Se algo precisar ser atualizado, corrigido ou modificado de alguma forma, novos servidores criados a partir de uma imagem comum com as alterações apropriadas serão provisionados para substituir os antigos. Depois de validados, são colocados em uso e os antigos são desativados.

Por que eles são usados? Os benefícios de uma infraestrutura imutável são mais consistência e confiabilidade em sua infraestrutura e um processo de implantação mais simples e previsível e mitiga problemas comuns de servidor em infraestrutura mutável, como tempo de inatividade devido à falha do servidor ou o que seja.

Mas você precisa saber como provisioná-lo com eficiência por meio de automações de implantação abrangentes e provisionamento rápido de servidores.

Imagine que você está minerando bitcoin, não desejaria nenhum tempo de inatividade se o servidor travasse, seria necessário fazer o backup o mais rápido possível, para que uma infraestrutura imutável seja a solução.