Cultura DevOps e Containers transformam a TI da Duke University

Chris Collins, engenheiro de automação no departamento de tecnologia da Duke University, conta como plantou a semente da cultura DevOps na equipe. “É difícil, mesmo em retrospecto, saber o que veio primeiro para nós: se os containers ou uma mudança em direção à cultura DevOps”, conta.

No Departamento de Tecnologia da Informação da Universidade Duke (OIT), na Carolina do Norte (EUA), começamos a procurar os containers como forma de obter maior densidade a partir da infraestrutura virtualizada usada para hospedar sites. A expansão da máquina virtual (VM) começou a se tornar um problema. Nós preferíamos separar o site de cada cliente em sua própria VM tanto para segregação quanto para organização, mas um crescimento constante significava que nós estávamos gerenciando mais servidores do que poderíamos dar conta. À medida que procurávamos maneiras de reduzir as despesas gerais de gerenciamento e fazer um melhor uso dos recursos, o Docker ganhou popularidade na comunidade e começamos a experimentar a “conteinerização” dos nossos aplicativos web.

Para nós, a investigação inicial sobre os containers reflete uma mudança em direção à uma cultura DevOps.

Onde começamos

Quando examinamos pela primeira vez a tecnologia de containers, o OIT era altamente orientado por processos e composto de aplicações e estrutura organizacional monolíticas. Algumas primeiras incursões na automação começaram a liderar a mudança para uma nova organização cultural dentro do departamento, mas, mesmo assim, a maior parte da nossa infraestrutura consistia de servidores “pet” (para usar a analogia pets vs. cattle). Os desenvolvedores criavam seus aplicativos em servidores de teste projetados para combinar ambientes de hospedagem de produção e serem implementados pelo código de migração do antigo para o último. As operações ainda se aproximavam da hospedagem da mesma forma de sempre: criando VMs dedicadas para serviços individuais e arquivando tickets manuais para monitoramento e backups. O ciclo de vida de um serviço era marcado por change requests, review boards, janelas de manutenção padrão e muita atenção pessoal por parte da equipe.

Uma mudança na cultura

Quando começamos a adotar a tecnologia de containers, algumas dessas atitudes de longa data em relação ao desenvolvimento e hospedagem começaram a mudar um pouco. Duas das maiores histórias de sucesso de containers vieram de nossa investigação sobre a infraestrutura da nuvem. O primeiro projeto foi criado para hospedar centenas de containers R-Studio para aulas em hosts do Microsoft Azure, quebrando com o modelo existente de servidores gerenciados individualmente e avançando para a infraestrutura de estilo “gado” projetada para hospedagem de aplicativos em containers.

O outro projeto era uma rápida “conteinerização” e implementação do site da Duke para a Amazon Web Services, quando de um ataque de negação de serviço, para criar uma infraestrutura dinâmica e serviços de deploy rápido.

O sucesso desses dois projetos absolutamente não padronizados ajudou a legitimar o uso dos containers no departamento, e mais tempo e esforço foram empregrados em busca de seus benefícios e de uma infraestrutura de nuvem sob demanda e descartável, tanto on-premise quanto através de provedores de nuvem pública.

Tornou-se evidente desde cedo que os containers possuíam um ciclo de vida diferente da infraestrutura tradicional. Começamos a notar casos em que  serviços de curta duração e de propósito único passaram a ser criados, implementados, passavam por todo o ciclo de vida e eram descartados antes de completarmos os tickets criados para inseri-los em um inventário, monitoramento ou backups. Nossas políticas e procedimentos não conseguiram manter os prazos que acompanhavam o desenvolvimento e implementação de containers.

Além disso, as pessoas não conseguiam acompanhar a automação surgida com a criação e gerenciamento dos containers em nossos hosts. Em resposta, começamos a desenvolver mais automação para realizar processos geralmente executados por humanos. Por exemplo, a migração dinâmica de containers de um host para outro exigiu uma mudança em nossa abordagem de monitoramento. Já não é suficiente vincular o monitoramento do host e do serviço ou enviar um ticket manualmente, uma vez que os containers são automaticamente destruídos e recriados em outros hosts em resposta a eventos.

Parte disso já estava em andamento para nós – a automação e a adoção do container parecem se paralelizar no processo. Em algum momento, eles se tornam inextricavelmente entrelaçados.

À medida que os containers continuavam a crescer em popularidade e a OIT começou a desenvolver ferramentas para a orquestração dos mesmos, tentávamos reforçar ainda mais a abordagem “gado” na parte de infraestrutura. Limitamos o login dos hosts apenas para a equipe de operações (rompendo com uma tradição) e demos um nome genérico a todos os hosts destinados ao armazenamento de container. Algo semelhante a sermos orientados a evitar nomear um animal perdido em um esforço para evitar o apego, os servidores com nomes genéricos tornaram-se literalmente impossíveis de esquecer. A gestão da própria infraestrutura tornou-se responsabilidade da automação, e não dos seres humanos, e os humanos concentraram seus esforços nos serviços executados dentro dos containers.

Os containers também ajudaram a promover a integração contínua em nossos fluxos de trabalho diários. Os membros da equipe de Gerenciamento de Identidade da OIT foram pioneiros na adoção e começaram a construir centros de distribuição de chaves Kerberos (KDCs) dentro de containers usando o Jenkins, construindo regularmente para incorporar patches e testar as imagens resultantes. Isso permitiu que a equipe resgatasse construções defeituosas antes de serem levadas para servidores de produção. Antes disso, a complexidade do ambiente e o impacto generalizado de uma interrupção tornariam o patch dos sistemas uma tarefa bastante difícil.

Abraçando a implementação contínua (continuous deployment)

Desde o caso de uso inicial, também abraçamos a implementação contínua. Existe um padrão para cada projeto envolvido com nosso sistema de integração contínua / implementação contínua (CI/CD). Muitas equipes inicialmente apresentam muita resistência sobre o deploy automático quando os testes passam, e elas tendem a criar checkpoints que requerem intervenção humana. No entanto, à medida que se tornam mais confortáveis com o sistema e aprendem a escrever bons testes, as equipes quase sempre removem esses checkpoints.

Dentro da nossa automação de orquestração de containers, usamos Jenkins para corrigir imagens base regularmente e reconstruir todas quando o parent é alterado. Não demoramos a tomar a decisão de que as imagens poderiam ser reconstruídas e redistribuídas a qualquer momento por processos automatizados. Isso significava que qualquer código incluído no ramo do repositório git usado no trabalho de build seria incluído na imagem e potencialmente implementado sem humanos envolvidos no processo. Enquanto alguns desenvolvedores inicialmente ficaram desconfortáveis com isso, foi uma ação que finalmente levou a melhores práticas de desenvolvimento: os desenvolvedores mesclaram em produção apenas o código que estava realmente pronto para ser implementado.

Essa prática facilitou a reconstrução de imagens de container imediatamente quando o código passava pelo merge no ramo de produção e nos permitia implementar automaticamente a nova imagem tão logo fosse construída. Neste ponto, quase todos os projetos que usam o rebuild automático também permitiram o deploy automatizado.

Olhando para o futuro

Hoje, a adoção dos containers e da cultura DevOps ainda é um trabalho em andamento no Departamento de Tecnologia da Informação da Universidade Duke.

Internamente, ainda temos que lutar contra a entropia da história, mesmo quando adotamos novas ferramentas e cultura. Nosso maior desafio será convencer as pessoas a se afastarem da mentalidade de reparação repetitiva que atualmente domina seus empregos e se concentrar mais na automação. Enquanto o tempo é sempre curto, e o primeiro passo sempre assustador, a longo prazo, a adoção da automação nas tarefas do dia-a-dia nos libertará para trabalhar em projetos mais interessantes e complexos.

Felizmente, as pessoas dentro da organização estão começando a abraçar a ideia de trabalhar em grupos organizados ou de membros interdisciplinares e desenvolver a automação em conjunto. Isso definitivamente se tornará necessário à medida que abraçarmos a orquestração automatizada e os sistemas mais complexos. E um grupo de indivíduos talentosos com habilidades complementares serão necessários para gerenciar completamente os novos ambientes.

Fonte: opensource.com

Webinar: Desenvolvendo uma Infraestrutura Ágil em Prol de uma Cultura DevOps

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.