O que são servidores imutáveis?


23

Existem algumas perguntas sobre servidores imutáveis , como:

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?

4
não é possível mutação
Evgeny

3
@Evgeny: gggggggggggrrrrrrrrrrrrrrr, eu estava perto, mas completamente errado com meu palpite mudo (por favor, não ria de mim ...).
Pierre.Vriens


Sinto muito por ser tão franco, mas foi uma simples pesquisa na Internet para definir "imutável" tão oneroso? Entendi que a pergunta é maior do que isso, mas pesquisar o significado da palavra em vez de adivinhar pode ter lhe dado uma vantagem decente.
Adrian

@ Adrian não tem problema em ser franco (porque eu sofro ESL, eu precisaria pesquisar no google para realmente obter o meening exato de franco). No entanto, gostaria de saber se você está ciente dessa pergunta meta.SA ? Além disso, prefiro aprender com especialistas em DevOps, em vez de alternativas do tipo Wikipedia.
Pierre.Vriens

Respostas:


19

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.


"encerre o antigo, traga o novo". Ou, se sua arquitetura permitir, abra o novo, ajuste o balanceador de carga, desligue o antigo. Dessa forma, você pode fazer quando quiser, mesmo no horário de pico. :)
Tim Malone

Imutabilidade, se a partir da programação funcional (década de 1960), agora está sendo percebido que não apenas reduz bugs (algo que muitas vezes não se importa), mas também ajuda com a simultaneidade.
ctrl-alt-delor 19/03

Eu realmente estaria interessado em alguma adição a esta fantástica resposta sobre como agentes de monitoramento ou software adicional que podem ser difíceis de integrar no original podem entrar em ação aqui. Por exemplo, o software de monitoramento APM que precisa detectar seu novo ambiente de máquina após a criação e alteração de parâmetros. Estou explorando o SSM e a automação para implantar isso na AWS, mas descobri muito pouco sobre o imutável com AMIs / imagens ao lidar com agentes adicionais que podem ser instalados posteriormente.
SheldonH 21/03

10

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.


1 Se não contamos mesas de tear automáticas ou órgãos de rolos como computadores.


1
Uau, mais uma explicação interessante, merci! Agora, estou realmente com problemas para decidir sobre qual resposta marcar como aceita (paciência nisso, por favor, e saiba que só posso marcar 1 no máximo, embora, neste momento, ainda não tenha decidido qual. .).
Pierre.Vriens

1
Avec plaisir! - Acho que é uma boa ideia aguardar vários dias para aceitar uma resposta, isso aumenta as chances de os usuários escreverem mais respostas.
Michael Le Barbier Grünewald

9

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.


Hum, interessante ... Preciso de algum tempo para digerir mais isso ... Sabe o ditado como "1 resposta a uma pergunta desencadeia 10 novas perguntas?" ...
Pierre.Vriens

1
Essa prática de "retroceder" rapidamente é freqüentemente chamada de "Implantação de Azul / Verde" (também vermelho / preto, depende de quem faz a chamada).
Evgeny

@Evgeny e pior de tudo, também poderiam ser chamados de implantações A / B, definhando a linha com experimentos A / B. (e, pior ainda, quando esse tipo de implantação, a versão múltiplos do mesmo aplicativo, estão vivos para fazer experiências A / B em vez de sinalizadores de recurso)
Tensibai

Sempre me disseram que as implantações azuis / verdes eram para a implantação de uma atualização em um aplicativo existente, NÃO no próprio servidor. @Evgeny
Turtle

Sim. Você pode trocar servidores, contêineres, aplicativos e outros enfeites e ainda chamá-lo de Azul / Verde . Eu acho que isso merece suas próprias perguntas e respostas aqui. Só queria salientar que a maneira como você explicou a reversão em sua resposta é muitas vezes chamada de B / G.
Evgeny

6

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.


Explicação interessante, talvez você queira modificá- lo um pouquinho, se puder, e se fizer sentido, elaborar algo que acredito que esteja de alguma forma relacionado, ou seja, "liberar" um sistema. O que eu acho é que você deixa (mais ou menos) alguém "brincar" com alguma coisa, e avisa-os de antemão que (por exemplo) todas as noites há algum tipo de redefinição para algum estado inicial. Parece que a entrada para tal redefinição é ... eu ... o que eu ia dizer ... certo: uma coisa imutável que pode ser usada para isso.
Pierre.Vriens

2
A execução de um serviço que retorna o servidor a um estado conhecido (como Chef / Puppet / Ansible / etc ...) significa apenas que você não está usando um servidor imutável. en.wikipedia.org/wiki/Promise_theory é ótimo, mas martinfowler.com/bliki/ImmutableServer.html é ainda melhor.
Evgeny

Você está me provocando, eu acredito, ou é um pouco "me desafiando" (para tentar descobrir o limite diário de perguntas). Também não existe em algum lugar uma regra SE que diz "você só pode fazer 50 perguntas em 30 dias"?
Pierre.Vriens

0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.