Por um longo tempo, a empresa Maxnet Systems usou a versão gratuita do VMware - ESXi, começando na versão 5.0, como um hypervisor. A versão paga do vSphere assustou o modelo de licenciamento, enquanto a versão gratuita teve várias desvantagens que não estavam disponíveis na versão paga, mas você pode atendê-las. Mas quando nas novas versões do ESXi a nova interface da Web se recusava a trabalhar com a antiga e o monitoramento das matrizes RAID deixou de mostrar sinais de vida, a empresa decidiu procurar uma solução mais universal e aberta. A empresa já teve uma boa experiência e uma boa impressão do LXC - Linux Containers. Portanto, ficou claro que o hipervisor dos sonhos será híbrido e combinará KVM e LXD para diferentes cargas - uma continuação evolutiva do LXC. Procurando informações sobre a KVM, a empresa foi confrontada com conceitos errôneos, rakes e práticas prejudiciais, mas testes e tempo colocaram tudo no lugar.
Sobre como lidar com a mudança do ESXi para o KVM e não dirigir com um ancinho, dirá
Lev Nikolaev (
maniaque ) - administrador e desenvolvedor de sistemas altamente carregados, instrutor de tecnologia da informação. Vamos falar sobre a rede, repositórios, contêineres, KVM, LXD, LXC, provisionamento e máquinas virtuais convenientes.
Prólogo
Identificaremos imediatamente os pensamentos-chave e analisá-los-em mais detalhadamente.
Rede. Embora as velocidades de suas interfaces não excedam 1 Gb / s, a ponte é suficiente para você. Assim que você quiser espremer mais - isso o limitará.
Repositório. Crie um armazenamento de rede compartilhado. Mesmo se você não estiver pronto para usar 10 Gbit / s dentro da rede, até 1 Gbit / s fornecerá 125 MB / s de armazenamento. Para várias cargas, isso será suficiente com uma margem e a migração de máquinas virtuais será uma questão elementar.
Container ou KVM? Prós, contras, armadilhas. Quais tipos de carga são melhor colocados em um contêiner e quais são deixados em uma KVM?
LXD ou LXC . O LXD é LXC? Ou outra versão? Ou um complemento? O que é isso tudo? Vamos dissipar mitos e entender as diferenças entre LXD e LXC.
Provisionamento conveniente . O que é mais conveniente: tire a mesma imagem ou instale o sistema sempre do zero? Como fazer isso com rapidez e precisão todas as vezes?
Máquina virtual conveniente. Haverá histórias assustadoras sobre gerenciadores de inicialização, partições, LVM.
Diversos . Muitas pequenas perguntas: como arrastar rapidamente uma máquina virtual do ESXi para o KVM, como migrar bem, como virtualizar discos corretamente?
Motivo da realocação
De onde tiramos a idéia maluca de passar do ESXi para o KVM / LXD? O ESXi é popular entre pequenas e médias empresas. Este é um hipervisor bom e barato. Mas existem nuances.
Começamos com a versão 5.0 - convenientemente, tudo funciona! A próxima versão 5.5 é a mesma.
Desde a versão 6.0, já é mais difícil. No ESXi, a interface da Web não ficou imediatamente livre, apenas a partir da versão 6.5, antes que um utilitário para Windows fosse necessário. Nós agüentamos isso. Quem executa o OS X compra o Parallels e instala esse utilitário. Esta é uma dor bem conhecida.
O monitoramento piscou periodicamente. Era necessário reiniciar os serviços de gerenciamento no console do servidor - o CIM Heartbeat apareceu novamente. Nós suportamos, porque ele nem sempre caiu.
ESXi 6.5 - lixo, desperdícios e atrocidades. Hypervisor terrível. E aqui está o porquê.
- Angular cai com uma exceção na entrada da interface da Web. Assim que você digitar seu nome de usuário e senha - imediatamente uma exceção!
- A capacidade de monitorar remotamente o status da matriz RAID não funciona , pois é conveniente para nós. Costumava ser conveniente, mas na versão 6.5, tudo está ruim.
- Suporte fraco para placas de rede modernas da Intel . As placas de rede da Intel e ESXi causam dor. Há um encadeamento de agonia no fórum de suporte do ESXi sobre isso. VMware e Intel não são amigos e as relações não melhorarão no futuro próximo. O triste é que mesmo os clientes de soluções pagas enfrentam problemas.
- Nenhuma migração no ESXi . A menos que a migração seja considerada um procedimento de pausa, copie e inicie. Colocamos o carro em pausa, o copiamos rapidamente e o iniciamos em outro lugar. Mas é impossível chamá-lo de migração - ainda existe uma simples.
Tendo analisado tudo isso, tivemos a ideia maluca de mudar com o ESXi 6.5.
Lista de desejos
Para começar, escrevemos uma lista de desejos para um futuro ideal para o qual estamos indo.
Gerenciamento sob SSH , Web e mais opcional. A interface da web é ótima, mas em uma viagem de negócios a partir de um iPhone, acessar a interface da web do ESXi e fazer algo é inconveniente e difícil. Portanto, a única maneira de gerenciar tudo é SSH, não haverá outra.
Virtualização do Windows. Às vezes, os clientes pedem coisas estranhas e nossa missão é ajudá-los.
Drivers sempre novos e a capacidade de configurar uma placa de rede . Desejo adequado, mas não realizado sob o ESXi puro.
Migração ao vivo, não em cluster . Queremos a capacidade de arrastar máquinas de um hipervisor para outro sem sentir atrasos, tempo de inatividade ou inconveniência.
A lista de desejos está pronta e uma pesquisa difícil foi iniciada.
Farinha de escolha
O mercado gira em torno de KVM ou LXC com diferentes molhos. Às vezes parece que Kubernetes está em algum lugar acima, onde está tudo bem, o sol e o paraíso, e no nível abaixo há Morlocks - KVM, Xen ou algo assim ...
Por exemplo, o Proxmox VE é o Debian, que foi extraído pelo kernel do Ubuntu. Parece estranho, mas traz para produção?
Nossos vizinhos no andar de baixo são o Alt Linux. Eles criaram uma bela solução: reuniram o Proxmox VE como um pacote. Eles apenas colocam o pacote em um comando. Isso é conveniente, mas não colocamos o Alt Linux em produção, por isso não nos convinha.
Take KVM
No final, escolhemos a KVM. Eles não aceitaram, Xen, por exemplo, por causa da comunidade - a KVM tem muito mais. Parecia que sempre encontraríamos a resposta para nossa pergunta. Mais tarde descobrimos que o tamanho de uma comunidade não afeta sua qualidade.
Inicialmente, calculamos que usaríamos uma máquina Bare Metal, adicionaríamos o Ubuntu com o qual estamos trabalhando e rodaremos o KVM / LXD de cima. Contamos com a capacidade de executar contêineres. O Ubuntu é um sistema bem conhecido e não há surpresas em termos de solução de problemas de inicialização / recuperação para nós. Nós sabemos onde chutar se o hypervisor não iniciar. Tudo é claro e conveniente para nós.
KVM Crash Course
Se você é do mundo do ESXi, encontrará muitas coisas interessantes. Aprenda três palavras: QEMU, KVM e libvirt.
O QEMU traduz os desejos de um sistema operacional virtualizado nos desafios de um processo regular. Funciona muito bem em quase todos os lugares, mas lentamente. O QEMU em si é um produto independente que virtualiza vários outros dispositivos.
Mais adiante, aparece um monte de
QEMU-KVM . Este é o módulo do kernel do Linux para QEMU. A virtualização de todas as instruções é cara, por isso temos um módulo do kernel do KVM que
traduz apenas algumas instruções . Como resultado, isso é significativamente mais rápido, porque apenas alguns por cento das instruções do conjunto geral são processadas. Este é todos os custos da virtualização.
Se você apenas possui QEMU, iniciar a máquina virtual sem ligação fica assim:
$ qemu < >
Nos parâmetros que você descreve a rede, bloqueie dispositivos. Tudo é maravilhoso, mas inconveniente. Portanto, há libvirt.
O objetivo da libvirt é ser uma ferramenta única para todos os hipervisores . Pode funcionar com qualquer coisa: com KVM, com LXD. Parece que resta apenas aprender a sintaxe da libvirt, mas na realidade funciona pior do que na teoria.
Essas três palavras são tudo o que é necessário para aumentar a primeira máquina virtual no KVM. Mas, novamente, há nuances ...
O Libvirt possui uma configuração na qual máquinas virtuais e outras configurações são armazenadas. Ele armazena a configuração em arquivos xml - elegante, moderno e direto dos anos 90. Se desejado, eles podem ser editados manualmente, mas por que, se houver comandos convenientes. Também conveniente é que as alterações nos arquivos xml são maravilhosamente versionadas. Usamos o
etckeeper - versão do diretório etc. Já é possível usar o etckeeper e já é tempo.
LXC Crash Course
Existem muitos conceitos errados sobre LXC e LXD.
LXC é a capacidade do kernel moderno de usar espaços de nome - para fingir que não é o núcleo que era originalmente.
Você pode criar esses espaços para nome quantos desejar para cada contêiner. Formalmente, o núcleo é um, mas se comporta como muitos núcleos idênticos. O LXC permite executar contêineres, mas fornece apenas ferramentas básicas.
A Canonical, que está por trás do Ubuntu e agressivamente avançando contêineres para a frente, lançou o
LXD, um análogo da libvirt . Essa é uma ligação que facilita a execução de contêineres, mas ainda existe o LXC.
LXD é um hypervisor de contêiner baseado em LXC.
A empresa reina no LXD. O LXD armazena a configuração em seu banco de dados - no diretório
/var/lib/lxd . Lá, o LXD leva sua configuração para a configuração no SQlite. Copiá-lo não faz sentido, mas você pode anotar os comandos usados para criar a configuração do contêiner.
Não há descarga como tal, mas a maioria das alterações é automatizada pelas equipes. Este é um análogo do arquivo Docker, apenas com controle manual.
Produção
Com o que fomos confrontados quando todos navegamos em operação.
Rede
Quanto lixo infernal e confusão na Internet sobre a rede no KVM! 90% dos materiais dizem usar ponte.
Pare de usar a ponte!
O que há de errado com ele? Ultimamente, tenho a sensação de que a insanidade está acontecendo com os contêineres: coloque o Docker em cima do Docker para que você possa executar o Docker no Docker enquanto assiste ao Docker. A maioria não entende o que a ponte está fazendo.
Ele coloca seu controlador de rede no
modo promíscuo e recebe todo o tráfego porque ele não sabe qual e qual não. Como resultado, todo o tráfego da ponte passa por uma pilha Linux maravilhosa e rápida em rede, e há muitas cópias. No final, tudo é lento e ruim. Portanto, não use bridge na produção.
SR-IOV
SR-IOV é a capacidade de virtualizar dentro de uma placa de rede . A própria placa de rede é capaz de alocar parte de si mesma para máquinas virtuais, o que requer algum suporte de hardware. É isso que impedirá a migração. Migrar uma máquina virtual em que o SR-IOV está ausente é doloroso.
O SR-IOV deve ser usado onde for suportado por todos os hipervisores como parte da migração. Caso contrário, o macvtap é para você.
macvtap
Isto é para aqueles cuja placa de rede não suporta SR-IOV. Esta é a versão light da ponte: diferentes endereços MAC estão pendurados em uma placa de rede e a
filtragem unicast é usada : a placa de rede não aceita tudo, mas estritamente de acordo com a lista de endereços MAC.
Detalhes mais sangrentos podem ser encontrados na grande palestra de Toshiaki Makita
, Virtual Switching Technologies e Linux Bridge . Ele está cheio de dor e sofrimento.
90% dos materiais sobre como construir uma rede no KVM são inúteis.
Se alguém diz que a ponte é incrível, não fale mais com ela.
Com o macvtap, a
CPU economiza cerca de 30% devido a menos cópias. Mas o modo promíscuo tem suas próprias nuances. Você não pode se conectar à interface de rede da máquina convidada a partir do próprio hipervisor - do host. Um relatório da Toshiaki detalha isso. Mas em suma - não vai funcionar.
Desde o próprio hipervisor, raramente o SSH. É mais conveniente iniciar um console lá, por exemplo, um console Win. É possível “observar” o tráfego na interface - você não pode se conectar via TCP, mas o tráfego no hipervisor é visível.
Se suas velocidades estiverem acima de 1 Gigabit - escolha macvtap.
Em velocidades de interface de até ou aproximadamente 1 Gigabit por segundo, também é possível usar a ponte. Mas se você tem uma placa de rede de 10 Gb e deseja descartá-la de alguma forma, resta apenas o macvtap. Não há outras opções. Exceto SR-IOV.
systemd-networkd
Essa é uma ótima maneira de armazenar a configuração de rede no próprio hypervisor . No nosso caso, este é o Ubuntu, mas para outros sistemas, o systemd funciona.
Costumávamos ter um arquivo
/etc/network/interfaces no qual todos mantíamos. Um arquivo é inconveniente para editar sempre - systemd-networkd permite dividir a configuração em uma dispersão de arquivos pequenos. Isso é conveniente porque funciona com qualquer sistema de versão: foi enviado ao Git e você vê quando e que mudança aconteceu.
Existe uma falha que nossos membros da rede descobriram. Quando você precisa adicionar uma nova VLAN no hypervisor, eu vou configurar. Então eu digo: "systemctl restart systemd-networkd". Neste momento, está tudo bem comigo, mas se as sessões BGP desta máquina forem geradas, elas serão interrompidas. Nossos membros da rede não aprovam isso.
Para o hipervisor, nada de ruim acontece. Systemd-networkd não é adequado para fronteiras, servidores com BGP elevado e para hipervisores - excelente.
Systemd-networkd está longe de ser final e nunca será concluído. Mas isso é mais conveniente do que editar um arquivo enorme. Uma alternativa ao systemd-networkd no Ubuntu 18.04 é o Netplan. Esta é uma maneira "legal" de configurar a rede e entrar no rake.
Dispositivo de rede
Depois de instalar o KVM e o LXD no hypervisor, a primeira coisa que você verá são duas pontes. Um criou a KVM para si e o segundo - LXD.
LXD e KVM estão tentando implantar sua rede.
Se você ainda precisar de uma ponte - para máquinas de teste ou para jogar, mate a ponte, que está ativada por padrão e crie a sua - a que você deseja. KVM ou LXD fazem isso terrivelmente - escorregar dnsmasq, e o horror começa.
Armazenamento
Não importa quais implementações você gosta - use armazenamento compartilhado.
Por exemplo, iSCSI para máquinas virtuais. Você não se livrará do "ponto de falha", mas poderá
consolidar o armazenamento em um ponto . Isso abre novas oportunidades interessantes.
Para fazer isso, você deve ter pelo menos 10 Gb / s de interfaces dentro do datacenter. Mas mesmo se você tiver apenas 1 Gbit / s - não se preocupe. Isso é aproximadamente 125 MB / s - muito bom para hipervisores que não exigem alta carga de disco.
O KVM pode migrar e arrastar o armazenamento. Mas, por exemplo, no modo de carga de trabalho, transferir uma máquina virtual para alguns Terabytes é uma dor. Para a migração com um armazenamento comum, apenas RAM é suficiente, o que é elementar. Isso
reduz o tempo de migração .
No final, LXD ou KVM?
Inicialmente, assumimos que, para todas as máquinas virtuais em que o kernel corresponde ao sistema host, usaremos o LXD. E onde precisamos tomar outro núcleo - leve o KVM.
Na realidade, os planos não decolaram. Para entender o porquê, dê uma olhada no LXD.
Lxd
A principal vantagem é economizar memória no núcleo. O kernel é o mesmo e quando lançamos novos contêineres, o kernel é o mesmo. Com isso, os profissionais terminaram e os contras começaram.
O dispositivo de bloco com rootfs deve ser montado. É mais difícil do que parece.
Realmente não há migração . É, e é baseado no maravilhoso instrumento sombrio criu, que nossos compatriotas viram. Tenho orgulho deles, mas em casos simples, o criu não funciona.
O agente zabbix se comporta de maneira estranha em um recipiente . Se você executá-lo dentro do contêiner, verá uma série de dados do sistema host e não do contêiner. Até agora nada pode ser feito.
Ao examinar a lista de processos no hypervisor, é impossível entender rapidamente de qual contêiner um processo específico está crescendo . Leva tempo para descobrir qual espaço de nome existe, o que e onde. Se a carga em algum lugar saltou mais do que o normal, então rapidamente não entendo. Esse é o principal problema - a limitação nos recursos de resposta. Uma mini investigação é realizada para cada caso.
A única vantagem do LXD é economizar a memória principal e reduzir a sobrecarga.
Mas a Memória Compartilhada do Kernel no KVM já economiza memória.
Até agora, não vejo razão para introduzir uma produção séria e LXD. Apesar dos melhores esforços da Canonical nessa área, a produção da LXD traz mais problemas do que soluções. Num futuro próximo, a situação não mudará.
Mas, não se pode dizer que LXD é mau. Ele é bom, mas em casos limitados, que discutirei um pouco mais tarde.
Criu
Criu é um utilitário sombrio.
Crie um contêiner vazio, ele chegará com um cliente DHCP e dirá: "Suspender!" Obtenha o erro porque existe um cliente DHCP: “Horror, horror! Ele abre o soquete com o sinal "cru" - que pesadelo! " Pior em lugar nenhum.
Impressões de contêineres: sem migração, o Criu funciona sempre.
Eu “gosto” da recomendação da equipe do LXD sobre o que fazer com o Criu, para que não haja problemas:
-
Pegue uma versão mais recente do repositório!E de alguma forma posso colocá-lo no pacote para não rodar no repositório?
Conclusões
O LXD é maravilhoso se você deseja criar uma infraestrutura de CI / CD. Pegamos o LVM - Logical Volume Manager, fazemos uma captura instantânea e iniciamos o contêiner. Tudo funciona muito bem! Em um segundo, um novo contêiner limpo é criado, configurado para testar e rolar o chef - nós o usamos ativamente.
O LXD é fraco para produção séria . Não podemos descobrir o que fazer com o LXD em produção se ele não funcionar bem.
Escolha KVM e apenas KVM!A migração
Eu vou dizer isso brevemente. Para nós, a migração acabou sendo um novo mundo maravilhoso que gostamos. Tudo é simples lá - há uma equipe para migração e duas opções importantes:
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
Se você digitar “Migração KVM” no Google e abrir o primeiro material, verá um comando para migração, mas sem as duas últimas chaves. Você não verá uma menção de que eles são importantes: "Basta executar este comando!" Execute o comando - e ele realmente migra, mas apenas como?
Opções de migração importantes.
undefinesource - remova a máquina virtual do hypervisor do qual estamos migrando. Se você reiniciar após essa migração, o hipervisor que você deixou reiniciará esta máquina. Você ficará surpreso, mas isso é normal.
Sem o segundo parâmetro - persistente - o hipervisor para o qual você se moveu não considera isso uma migração permanente. Após a reinicialização, o hypervisor não se lembrará de nada.
- virsh dominfo <vm> | grep persistent
Sem esse parâmetro, a máquina virtual é círculos na água. Se o primeiro parâmetro for especificado sem o segundo, adivinhe o que acontecerá.
Existem muitos momentos com a KVM.
- Rede: eles sempre falam sobre bridge - é um pesadelo! Você lê e pensa - como assim ?!
- Migração: eles também não dizem nada inteligível até você bater com a cabeça contra esse muro.
Por onde começar?
Para começar tarde - estou falando de outra coisa.
Provisionamento: como implantá-lo
Se você estiver satisfeito com as opções de instalação padrão, o mecanismo preseed é ótimo.
No ESXi, usamos virt-install. Essa é uma maneira regular de implantar uma máquina virtual. É conveniente que você crie um arquivo preseed no qual descreve a imagem do seu Debian / Ubuntu. Inicie uma nova máquina alimentando-a com um kit de distribuição ISO e um arquivo preseed. Então o carro rola sozinho. Você se conecta a ele via SSH, conecta-o a um chef, enrola biscoitos - é isso, corre para o prod!
Mas se você tiver virt-install suficiente, tenho más notícias. Isso significa que você não atingiu o estágio em que deseja fazer outra coisa. Superamos e percebemos que o virt-install não é suficiente. Chegamos a uma "imagem de ouro", que clonamos e lançamos máquinas virtuais.
E como organizar uma máquina virtual?
Por que chegamos a essa imagem e por que o aprovisionamento é importante? Porque ainda existe um entendimento fraco na comunidade de que existem grandes diferenças entre uma máquina virtual e uma máquina comum.
Uma máquina virtual não precisa de um processo de inicialização complicado e de um carregador de inicialização inteligente . É muito mais fácil conectar os discos de uma máquina virtual a uma máquina que possui um conjunto completo de ferramentas do que no modo de recuperação tentando sair de algum lugar.
Uma máquina virtual precisa da simplicidade de um dispositivo . Por que preciso de partições em um disco virtual? Por que as pessoas pegam um disco virtual e colocam partições lá, não o LVM?
Uma máquina virtual precisa de extensibilidade máxima . Normalmente, as máquinas virtuais crescem. Este é um processo "legal" - aumentando a partição no MBR. Você o exclui, naquele momento enxugando o suor da testa e pensa: “Apenas não escreva agora, apenas não escreva!” - e recrie com os novos parâmetros.
LVM @ lilo
Como resultado, chegamos ao LVM @ lilo. Este é um carregador de inicialização que permite configurar a partir de um único arquivo. Se, para editar a configuração do GRUB, você está editando um arquivo especial que controla o mecanismo de modelos e cria o monstruoso boot.cfg, depois com o Lilo - um arquivo e nada mais.
O LVM sem partição torna o sistema perfeito e fácil. O problema é que o GRUB não pode viver sem MBR ou GPT e está congelando. Dizemos a ele: “O GRUB se instala aqui”, mas ele não pode, porque não há partições.
O LVM permite expandir e fazer backups rapidamente. Caixa de diálogo padrão:
- Pessoal, como você faz backup virtual?- ... pegamos um dispositivo de bloco e copiamos.- Você tentou implantar de volta?- Bem, não, tudo funciona para nós!Você pode lamber um dispositivo de bloco em uma máquina virtual a qualquer momento, mas se houver um sistema de arquivos, qualquer registro requer três movimentos - esse procedimento não é atômico.
Se você estiver fazendo um instantâneo da máquina virtual por dentro, ela poderá conversar com o sistema de arquivos para que chegue ao estado consistente desejado. Mas isso não é adequado para tudo.
Como construir um contêiner?
Para iniciar e criar um contêiner, existem ferramentas regulares dos modelos. O LXD oferece o modelo Ubuntu 16.04 ou 18.04. Mas se você é um lutador avançado e não deseja um modelo comum, mas seus rootfs personalizados, que você pode personalizar por si mesmo, surge a pergunta: como criar um contêiner do zero no LXD?
Recipiente a partir do zero
Preparando rootfs . O Debootstrap ajudará com isso: explicamos quais pacotes são necessários, quais não são e instalamos.
Explique ao LXD que queremos criar um contêiner a partir de rootfs específicos . Mas primeiro, crie um contêiner vazio com um comando curto:
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
Pode até ser automatizado.
Um leitor atencioso dirá - onde está o rootfs meu contêiner? Onde é indicado em que lugar? Mas eu não disse que isso é tudo!
Montamos rootfs do contêiner onde ele irá morar. Em seguida, indicamos que o contêiner rootfs ficará aqui:
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
Novamente, isso é automatizado.
Vida do recipiente
O contêiner não possui seu próprio kernel ; portanto, é mais fácil carregá-lo
: systemd, init e voou!
Se você não usar ferramentas regulares para trabalhar com o LVM, na maioria dos casos, para iniciar o contêiner, será necessário montar os rootfs do contêiner no hypervisor.
Às vezes encontro artigos que recomendam autofs. Não faça isso. O Systemd possui unidades de montagem automática que funcionam, mas o autofs não. Portanto, as unidades de montagem automática do sistema podem e devem ser usadas, mas o autofs não vale a pena.
Conclusões
Gostamos do KVM com migração . Com o LXD, ainda não é o caminho, embora, para testar e construir a infraestrutura, a utilizemos onde não há carga de produção.
Adoramos o desempenho da KVM . É mais familiar olhar para o topo, ver um processo relacionado a essa máquina virtual e entender quem e o que estamos fazendo. É melhor do que usar um conjunto de utilitários estranhos com contêineres para descobrir que tipo de batidas subaquáticas existem.
Estamos muito satisfeitos com a migração. Isso se deve principalmente ao armazenamento compartilhado. Se migrássemos arrastando discos, não ficaríamos tão felizes.
Se você, como Leo, está pronto para falar sobre como superar as dificuldades de operação, integração ou suporte, agora é a hora de enviar um relatório para a conferência DevOpsConf do outono. E nós, no comitê do programa, ajudaremos a preparar a mesma apresentação inspiradora e útil que essa.
Não estamos aguardando o prazo para a chamada de trabalhos e já aceitamos vários relatórios para o programa da conferência. Assine a newsletter e o canal de telegrama e fique por dentro das novidades sobre os preparativos para o DevOpsConf 2019 e não perca novos artigos e vídeos.