Menu

Gerenciamento de configuração em práticas DevOps

configuration management devops practices

Experimente Nosso Instrumento Para Eliminar Problemas

O que é gerenciamento de configuração nas práticas de DevOps?

Conceito de Teste Contínuo em DevOps foi explicado em detalhes em nosso tutorial anterior.

O principal destaque do gerenciamento de configuração no DevOps é entregar,

  1. Infraestrutura como um código
  2. Configuração como um código

Deve Ler Completamente => Série exclusiva de tutoriais DevOps

selênio webdriver entrevista perguntas e respostas para experientes

Gerenciamento de configuração em práticas DevOps

Existem inúmeros benefícios de 'infraestrutura como um código' e 'Configuração como um código' na prática de DevOps.

    • As configurações são controladas por versão
    • Automatizado e padronizado
    • Remove dependência
    • Infra-configurações sem erros
    • Aumenta a colaboração entre a equipe de Operações e Desenvolvimento
    • Corrigindo desvio de configuração
    • Tratar a infraestrutura como um recurso flexível
    • Escalonamento automatizado de infraestrutura
    • Manter a consistência nas configurações

VÍDEO Parte 4 Bloco 1: Gerenciamento de Configuração- 23 minutos 7 segundos

Transcrição:

Nesta parte, aprenderemos sobre Gerenciamento de configuração, gerenciamento de liberação e monitoramento de desempenho de aplicativos em DevOps.

Aqui, no bloco 1, vamos nos concentrar no gerenciamento de configuração e entender o que é gerenciamento de configuração e como ele é diferente no DevOps e nos métodos tradicionais.

Para começar, vamos saber o que é gerenciamento de configuração?

O gerenciamento de configuração, como o próprio nome explica, nada mais é do que gerenciar todas as configurações dos ambientes que o aplicativo de software hospeda.

Como sabemos, temos diferentes ambientes em todo o SDLC em DevOps, começando com teste de unidade, teste de integração, teste de sistema, teste de aceitação e teste de usuário final.

E também expliquei em meus tutoriais anteriores que o ambiente configurado para esses testes se tornaria progressivamente mais complexo à medida que avança para o ambiente de pré-produção e produção.

Portanto, basicamente, gerenciamento de configuração é o processo automatizado para gerenciar todas as configurações de cada um desses ambientes.

Então, qual é a diferença entre o gerenciamento de configuração tradicional e o gerenciamento de configuração DevOps?

Em nossos métodos tradicionais de gerenciamento de configuração, a equipe costumava gerenciar essas configurações de vários ambientes por meio de documentação formal em que cada uma das configurações costumava ser registrada nos documentos e a equipe ou gerente de configuração costumava lidar com o controle de versão desses documentos.

E à medida que passa por alterações, ele também se responsabiliza por configurar o ambiente e gerenciar as configurações manualmente

Agora, no DevOps, normalmente, todos esses processos de gerenciamento de configuração são muito bem automatizados e as configurações são encapsuladas na forma de código ou scripts e controladas por meio da ferramenta de controle de versão.

Nesse contexto, podemos chamar que a equipe de Operações está integrada com o Desenvolvimento na gestão dos ambientes através da ferramenta de controle de versão única.

Portanto, o principal destaque do gerenciamento de configuração no DevOps é entregar,

      1. Infraestrutura como um código
      2. Configuração como um código

O que realmente significa 'Infraestrutura como um código'? É definir toda a definição do ambiente como um código ou script, em vez de registrar em um documento formal.

Então, o que a definição de ambiente inclui? A definição do ambiente geralmente inclui a configuração de servidores, a configuração de redes e a configuração de outros recursos de computação, que fazem parte da configuração da infraestrutura de TI. Portanto, todos esses detalhes seriam escritos como um arquivo ou na forma de um código e verificados na ferramenta de controle de versão.

Esse script ou código, que é verificado no controle de versão, se tornaria a única fonte de definição do ambiente ou até mesmo de atualização desses ambientes.

Só para dar um simples Exemplo , se tivermos que adicionar um servidor ao ambiente específico, tudo o que faríamos é atualizar essas informações nos scripts de ambiente e executar o pipeline de entrega, em vez de manualmente ir e girar para fora de um novo ambiente com o servidor adicionado ou buscar a ajuda do pessoal de administração do sistema para fazer isso.

Portanto, a beleza aqui é que o desenvolvedor ou testador não precisa ser um especialista em administração de sistema para configurar seus servidores para atividades de desenvolvimento ou teste.

Assim, a infraestrutura configurada no DevOps será totalmente automatizada e basicamente segue o script que é verificado para o controle de versão desde a instalação dos servidores, configuração dos mesmos, instalação do SO, até que os canais de comunicação dessas instâncias sejam estabelecidos com os implantados Programas.

Qual é a configuração como um código?

A configuração como um código nada mais é do que definir todas as configurações dos servidores ou quaisquer outros recursos como um código ou script e verificá-los no controle de versão.

Esses scripts de configuração que são verificados no controle de versão são executados como parte do pipeline de implantação para definir a infraestrutura e suas configurações de maneira automatizada.

Bem, definir configurações inclui parâmetros que definem as configurações recomendadas para que o software seja executado com êxito. Ou um conjunto de comandos a serem executados inicialmente para configurar o aplicativo de software. Ou mesmo podem ser configurações de cada um dos componentes do software que devem ser definidos, ou funções de usuário específicas, privilégios de usuário etc.,

Simples Exemplo seria definir os alternadores de recursos, onde os valores padrão são definidos como parte do parâmetro de configuração.

Adicionar outra porta a um firewall seria outra Exemplo , que pode ser atualizado no script e, posteriormente, esses scripts são executados como parte do pipeline de entrega.

Diversas ferramentas estão disponíveis para realizar a automação de infraestrutura no mercado. Poucos deles são Chef, Puppet, Terraform, etc., Chef e Puppet são ferramentas de gerenciamento de configuração baseadas em ruby, enquanto o Terraform é uma ferramenta de provisionamento.

Além disso, atualmente, como quase todos os aplicativos serão hospedados na nuvem, AWS, eles próprios fornecem RESTAPI's, que podem ser aproveitados para esse fim.

Tenho uma lista enorme de benefícios do gerenciamento de configuração no DevOps, em vez de definir a infraestrutura e as configurações como um código.

Vamos examiná-los um por um.

Todas as configurações e detalhes de infraestrutura são controlados por versão, o que é um grande benefício na implementação do DevOps.

# 1) Isso ajuda a equipe a gerenciar as alterações nos servidores e configuração de forma automatizada e ajuda a depurar rapidamente se algo falhar, em um curto espaço de tempo e também permite retornar rapidamente para a versão anterior, sem causar interrupções aos clientes.

#dois) Uma vez que esses scripts estão localizados no servidor central e todos na equipe sabem o que há em cada um desses scripts e quais são as alterações feitas em cada uma dessas versões. Isso também permite que a equipe volte para a versão anterior, caso haja algum problema nas versões mais recentes.

Imagine, se houver um travamento do servidor, quanto tempo levaria para restaurá-lo manualmente. E agora, ao definir a infraestrutura como um script e controle de versão, podemos restaurar imediatamente indo para a versão anterior.

# 3) Gerenciar as configurações como um código também evita que alguém faça alterações no sistema acidentalmente e evita quaisquer danos que causem posteriormente na produção.

Como o gerenciamento de configuração é totalmente automatizado, a intervenção manual para configurar ou atualizar é completamente eliminada.

Imagine o impacto sobre o custo, a qualidade e o tempo quando antes as pessoas dependiam dos recursos humanos para realizar essas configurações manualmente e quando certas configurações eram perdidas ou não definidas conforme necessário.

Portanto, a automação do gerenciamento de configuração não só se beneficiou na economia de tempo, mas também na eliminação de tais erros humanos e na melhoria da qualidade. Além disso, o padrão de codificação ajudou a equipe a seguir o padrão especificado na codificação e automação, em vez de seguir a fantasia de cada pessoa que escreve o guia de configuração.

Conforme discutido anteriormente, as configurações entregues como um código removeram a dependência de uma única pessoa ou equipe chamada gerenciador de configuração ou equipe de configuração. A equipe de desenvolvimento não precisa esperar que a equipe de configuração venha e conserte qualquer problema de infra-estrutura ou configuração.

Ou ainda para ajuste de infra e configurações, que são totalmente automatizadas e com controle de versão. Assim, qualquer pessoa da equipe, seja um desenvolvedor ou testador, pode girar um servidor e realizar as configurações para fins de desenvolvimento e teste. Portanto, a configuração do servidor e das configurações tornou-se independente da pessoa.

Isso também garante que os mesmos servidores não sejam usados ​​pelas equipes de Desenvolvimento e QA para suas atividades, o que geralmente acontecia anteriormente.

A infraestrutura e as configurações definidas como um código comum, juntamente com a automação e o controle de versão padronizam todos os ambientes e configurações. Portanto, isso não apenas torna a tarefa de depuração fácil para os desenvolvedores, mas também elimina os erros humanos que resultam em configurações de infra-estrutura sem erros, caso contrário, o que causaria enormes danos, se não fosse detectado antecipadamente.

Aqui, podemos ver claramente a colaboração entre o Dev e Ops, onde ambos contam com uma única fonte para realizar a configuração de infra e ambas as equipes estão ativamente envolvidas na automação e configuração de todo o gerenciamento de configuração.

Trabalhar em conjunto para atingir um objetivo comum aumenta a colaboração entre as equipes de desenvolvimento e as operações.

Corrigindo desvio de configuração

O que é desvio de configuração?

Pequenas diferenças e inconsistências entre os servidores, que às vezes acontecem devido à atualização manual, que se acumulam ao longo de um período de tempo, são chamadas de desvio de configuração.

Esta não é uma boa situação, porque essa inconsistência nos servidores faz com que certos arquivos de programa, como manifesto, playbook não sejam executados de forma confiável em todos os servidores e, portanto, leva à falha de automação. Portanto, isso precisa ser evitado para que a equipe use a automação das configurações de forma eficaz.

Gerenciar infra e config como um código e controle de versão ajudou a equipe a evitar ou corrigir qualquer tipo de desvio de configuração entre vários ambientes ou entre configurações de desenvolvimento e produção, mantendo consistentemente as configurações em todos os servidores.

Assim, uma equipe pode ter a melhor garantia de configurações semelhantes na configuração de desenvolvimento e em produção. Isso também os ajuda a simular os problemas de produção no ambiente de desenvolvimento.

Então, isso ajuda a prevenir qualquer tipo de mudanças inesperadas que qualquer um dos membros da equipe possa tentar fazer na infra, o que pode quebrar a configuração e também obrigar a equipe a não fazer alterações na configuração a menos que estejam logados como um código para o repositório.

Fornecer infraestrutura e sua configuração como um código permitiu que a equipe a gerencie como um recurso flexível para atender às necessidades de negócios dinâmicas do cliente.

É uma espécie de plug and play agora. Uma equipe pode entrar especificamente em um determinado servidor ou rede e fazer as alterações neles. Pode ser apenas atualizar o servidor de provisionamento ou adicionar ou modificar o armazenamento em uma rede específica, ou mesmo atualizar o sistema operacional, e tudo pode ser atualizado de forma independente como um recurso flexível.

Anteriormente, para alterar um parâmetro de configuração, costumava levar muito tempo, especialmente enquanto era necessário atualizar em todos os servidores, mas agora é apenas uma tentativa. Atualize o script e faça o upload para a ferramenta de controle de versão e está tudo pronto.

Existe uma flexibilidade para descartar completamente a infraestrutura existente e trazer outra totalmente. Portanto, gerenciar a infraestrutura e as configurações se tornou muito fácil agora. Bem, as soluções baseadas em nuvem permitiram que a infraestrutura aumentasse automaticamente, adicionando recursos adicionais de computação ou armazenamento conforme necessário e diminuindo quando não fossem necessários.

Isso permitiu a otimização do uso de recursos com base na demanda. Se quisermos dimensionar a infraestrutura aumentando o tamanho da máquina, podemos fazer isso imediatamente. Da mesma forma, se quisermos dimensionar horizontalmente ou talvez adicionar outra configuração, ou adicionar mais front-ends, podemos fazer isso em segundos, simplesmente atualizando-o no código e executando o pipeline automatizado.

Por último, mas não menos importante, a infraestrutura, a entrega como um código em um ambiente controlado ajuda a manter a consistência dos ambientes em várias configurações. Isso também ajuda a depurar o problema. Este ponto eu também cobri anteriormente, até certo ponto, ao falar sobre o desvio de configuração.

É isso e conclui nossa conversa sobre gerenciamento de configuração em DevOps, sobre o que é infraestrutura e configurações como um código e quais são seus benefícios.

Em nosso próximo tutorial, discutiremos os aspectos de gerenciamento de liberação no DevOps.

PREV Tutorial | PRÓXIMO Tutorial

Leitura recomendada

^