 Mas como a gente já está em cima do horário, eu vou partir do pressuposto que não. Então, deixa eu compartilhar a minha tela aqui. Antes mais nada, agradecer aí a todos pela presença, pela organização e pelo convite em aceitar minha apresentação. Vou tentar manter a barra, que a barra com a Ellen e com o Magno deixaram bem alta, né? Então, a gente vai falar um pouquinho sobre a operação contínua através do GitOps e a gente vai falar de uma ferramenta que faz parte do ecossistema da CNCF chamado Flux. Fiquei à vontade de fazer perguntas. Eu planejei a apresentação para 45 minutos e descobri que tenho 35. Então, eu vou deixar as perguntas para o final. Usem lá o campo de Q&A aqui da própria ferramenta, que fica mais fácil depois no final de a gente coordenar quais foram as perguntas. Vamos nessa. Antes de a gente começar só a fazer uma breve apresentação, meu nome é Davi. Eu moro no Rio, trabalho do Rio, mas não sou nascido aqui. A minha função principal hoje é o seu pai da Valentini e do Bernardo, meus dois filhos, se eles ocupam a maior parte do meu tempo livre. E quando eu tenho o tempo sobrando, a gente trabalha e se diverte um pouco com o open source. Eu já brinco um pouco a comunidade do Kubernetes, já faz um tempo, me divertindo, desde a versão 1.4. E hoje eu trabalho como arquiteto de soluções focado em modernização, tanto de infraestrutura quanto aplicação, dentro da AWS, em um time que se chama Cloud Acceleration. Fica aí o meu alias de mídias sociais. Enfim, caso vocês queiram trocar uma ideia depois de evento, eu também vou estar lá no Slack da CNCF. Vamos lá. Para a gente começar, a ideia é vamos tentar olhar a filosofia, a teoria por trás e entender o que significa essa nova buzzword, GitOps, para muitos e muitas de vocês. E tentar depois aterrissar esse conceito na prática. GitOps foi um termo que foi cunhado lá em 2017 pela WebWorks. Esse termo primeiro apareceu em alguns blogs e depois eles fizeram uma apresentação formal na Cubicon em 2017, Cubicon na América do Norte. E a ideia do GitOps é uma filosofia para a gente ter implantação contínua no ambiente cloud native. Essa filosofia é importante entender que ela não é prescritiva no sentido de usar a ferramenta x, y ou z, ou uma forma certa, uma forma errada de executar o GitOps, ter o processo ao redor do GitOps. Na verdade, tem os conceitos que é primeiro, a gente ter a característica de usar uma infraestrutura que seja declarativa. A gente está falando aqui na comunidade de Kubernetes, então a infraestrutura declarativa é o nosso dia a dia. A gente entender que a gente vai trabalhar com definições de estado e a infraestrutura que a gente está operando vai ser capaz de interpretar esse estado e chegar no estado que a gente deseja de forma transparente para a gente. Trabalhar com versionamento, ou seja, não só eu ter a minha infraestrutura como dada, mas eu conseguir versionar esse dado para ter um controle de ciclo de vida e também um controle em termos de auditoria histórico. E um papel, acho que fundamental para qualquer metodologia de implantação contínua é a parte de automação. Quando a gente fala de GitOps, a gente está falando de reconciliação automatizada. Então, toda vez que tiver a mudança nesse meu repositório, onde eu tenho a minha declaração de estado da minha infraestrutura, de alguma forma essa declaração que está lá no meu repositório, que é um Git, consiga ser passada para o meu ambiente de execução, o meu ambiente real, a minha infraestrutura. Por conta dessas três características, que são as principais da filosofia do GitOps, existe uma sinergia natural com Kubernetes. Mas ela é uma filosofia que pode ser aplicada a qualquer tipo de infraestrutura. A gente vai ver e no decorrer dos slides vocês vão até, provavelmente, notar que possivelmente vocês já estão usando essa prática dentro da mente de vocês. Como é que é o fluxo? Eu gosto de desenhos. A gente tem aqui uma pessoa que está trabalhando na infraestrutura, a gente pode pensar que é uma pessoa desenvolvedora, ou uma pessoa administradora de infraestrutura, e a gente tem lá o nosso ambiente. Tradicionalmente, como é que a gente faz as interações nos nossos ambientes? A gente vai conectar diretamente lá, ou a partir de alguma ferramenta, mas ainda disparado por essa pessoa, a gente vai interagir dentro daquele ambiente. O fluxo do GitOps, a gente quer evitar a todo custo esse tipo de interação. Então, a gente quer, ao invés de fazer alterações diretas no nosso ambiente, a gente quer passar a usar o Git como a fonte da verdade de todo o nosso fluxo de operação. Então, a ideia é que a gente deixe de mudar o estado diretamente no nosso ambiente de Kubernetes, por exemplo, ou na nossa infraestrutura de nuvem, na nossa infraestrutura de virtualização, e a gente consiga usar uma declaração de estado que representa o nosso desejo da nossa infraestrutura, armazen isso num repositório e de que alguma forma tenha uma automação que seja capaz de buscar essa declaração de estado que está lá no nosso repositório e aplicar no nosso ambiente. A partir do momento que eu tenho esse fluxo rosando o Git como intermediário, a ideia é que eu proíbo o acesso direto. Então, a ideia do GitOps vai sempre estar centrada nesse tipo de fluxo, e muito provavelmente vocês estão pensando assim, mas pera aí, isso aí não é novidade, né? A gente tem o DevOps lá, com as práticas de integração contínua, de implotação contínua e toda a partir de automação com as esteiras. Já tem uma coisa muito parecida com isso que você está me falando, né? Qual é a ideia do... Quais são os benefícios que o GitOps tenta trazer em cima das práticas que o DevOps já estabeleceu? Então, a primeira que eu acho que qualquer metodologia de implotação contínua vai prometer para você é que você tenha implotações mais rápidas e frequentes. A ideia aqui é que como a gente vai estar usando o Git como intermediário para as operações, que passa a ser uma linguagem comum também para o time de desenvolvimento, a ideia é que a gente quebre mais barreiras. Então, uma ferramenta comum tende a amplificar o nível de colaboração que a gente tem entre as equipes, e aí, inevitavelmente, essa colaboração vai ser traduzida em aumento de velocidade. Uma proposição de valor importante do GitOps a gente vai ver lá para o final que eu guardei uma demo. Então, eu vou tentar acelerar nos slides para a gente ter tempo e conseguir ter recuperação rápida e simples em casos de falha, porque uma vez que eu tenho o estado final atual da minha infraestrutura representado num repositório que tem todo seu histórico lá versionado, onde eu consigo ver quem fez a mudança, por que fez a mudança, quando que fez, eu consigo de forma praticamente trivial recuperar meus ambientes. Uma vez que eu também tenho tudo isso lá guardado e versionado, eu consigo simplificar minha postura de segurança. Por quê? Uma vez que eu não tenho mais acesso direto e tudo passa pelo Git, eu posso usar das práticas de integração contínua, desse mesmo repositório, só que não é de aplicação mais de código de dados de infraestrutura. Eu consigo usar ferramentas que vão validar se a minha postura de segurança está correta, se as configurações são válidas, eu posso usar de práticas como revisão de código, para validar se aquela modificação que eu estou sugerindo, de fato, faz sentido, foi validada pelos meus colegas. E uma outra situação que a gente vai ver é que a gente consegue simplificar a complexidade das nossas esteiras também. Então isso eu vou deixar para explicar um pouquinho, mas lá para frente. Autodocumentação, a partir do momento que a minha infraestrutura, eu estou usando a operação declarativa, ou seja, são os estados que estão avestionados dentro do meu Git, aquilo passa se a documentação da minha infraestrutura. Então, ao invés de eu ter que fazer engenharia reversa de como aquilo foi configurado, quem configurou, se tem algum ajuste fino que foi feito fora dos padrões, a gente consegue, através do próprio log de auditoria, das interações que aconteceram no repositório, reconstruir e entender qual foi a evolução dos nossos ambientes. E a edificão do conhecimento é a ideia de linguagem comum, a gente aumenta a colaboração, a gente pode ter equipes que não, não seriamente, estão trabalhando especificamente naquela tua área, naquela tua aplicação, mas que eles podem olhar como que você está fazendo os seus processos para melhorar os seus próprios. Eu coloquei aqui uma referência, a Aniadota, do Kelsey Hightower, espero que vocês conheçam. Eu acho que um dos meus grandes fãs na comunidade, eu gosto muito de acompanhar sempre tudo o que ele fala. Eu acho que é um grande evangelista histórico, assim, dentro da comunidade de Kubernetes. Ele é um grande defensor dessa ideia do GitOps. Ele fala que o GitOps foi uma das melhores coisas que aconteceram desde a parte de configuração como código. Então, justamente na ideia de que o Git, a forma com que a gente trabalha no Git, e aí por conta do tempo a gente não vai conseguir se aprofundar sobre os processos em cima do Git, se vai ser trunk-based development, ou vai ser Git flow, e como que a gente vai trabalhar com essa ideia do request e etc. Mas toda essa mentalidade, que é natural hoje no mundo de desenvolvimento, a gente agora consegue transpor para o mundo de infraestrutura. Então, a gente consegue se deburuçar nas edições aprendidas que a galera da engenharia de software de aplicação construa no decorrer dos últimos anos e consegue extrair dos mesmos benefícios agora da gente gerenciando infraestrutura, dado que a gente tem plataformas e tecnologia que permite a gente operar a infraestrutura como dado, como código. Existem muitas formas de implementar GitOps. Eu vou falar do flux hoje, mas existe uma atualidade de ferramentas. Aqui a gente está vendo o CNCF Tecnolo de Radar, que aconteceu em junho de 2020, está um pouco defasado. Mas você vê uma quantidade de ferramentas que a CNCF, a partir das interações com o end-user community, as empresas e entidades que estão usando os projetos da CNCF, reporta nos surveys, a gente consegue ver uma série de ferramentas aqui e provavelmente vocês vão se identificar em uma outra ferramenta aqui dentro desse gráfico. Fica aqui uma referência sobre o estudo que vai dizer esse estudo, ele vai falar sobre nível de maturidade, sobre as soluções aprendidas entre várias alternativas. Mas o importante aqui é, de novo, GitOps é prescritivo em relação à filosofia, às práticas, mas ele não é prescritivo em relação à ferramenta. Então você pode implementar a filosofia usando qualquer ferramenta que você prefira. E aí a ideia da ferramenta é que eles vão existir mais ou menos dois grandes modelos da gente implantar GitOps em termos técnicos de comportamento das nossas esteiras. Então, o primeiro modelo é o que normalmente a gente fala que é o modelo de push. É o modelo que a esteira empurra a mudança nos nossos ambientes. E esse modelo aqui é um modelo que é muito provável se você não está usando ferramentas específicas no mundo de GitOps. Se você está usando, por exemplo, Jenkins, qualquer outro tipo de ferramenta de esteira, é um modo, método que você está usando hoje para empurrar implantação para dentro dos seus ambientes, fazer novos deployments. No modelo do push, a gente vai ter essa ideia de que a gente vai ter um repositório lá da aplicação, em algum momento vai ser gerado um evento, pode ser uma interação lá do seu time de aplicação, esse evento vai trigar, vai disparar uma automação. Essa automação vai ser uma esteira de construção do nosso artefato que no mundo de container é basicamente pegar lá o artefato de desenvolvimento e construir uma imagem de container. Esse é o primeiro estágio dessa esteira de construção de artefatos. Essa imagem vai ser colocada lá num repositório, num registry. Um segundo estágio, que é muito comum também, depois ele construir a imagem, ele vai atualizar os arquivos de declaração de estado, lembra lá da nossa infraestrutura declarativa, os nossos maravilhosos e queridos IEMOS, vai atualizar os nossos manifestos IEMOS de Kubernetes para dizer o seguinte, olha, teve uma mudança na imagem, a versão agora que eu quero que esteja implantada e a versão sai da 1.1 para 1.2. Então ele vai fazer uma substituição lá dentro do IEMOS. E essa substituição pode acontecer num arquivo que está armazenado junto do repositório da nossa aplicação ou pode estar armazenado num repositório separado. É muito comum ter um repositório de código da aplicação e um repositório de código de infraestrutura que está relacionado àquela aplicação. Aqui nesse exemplo, aqui nesse desenho, ele vai atualizar o nosso repositório específico de configuração da nossa aplicação. Nesse momento que é esse repositório aqui, nesse momento a esteira que está fazendo o build ela termina e esse evento de modificação de um conteúdo lá naquele nosso repositório de infraestrutura vai gerar um outro evento. E esse evento vai iniciar uma segunda esteira que é uma esteira de implantação. Então essa esteira de implantação ela vai basicamente pegar a última definição do repositório de infraestrutura e executar a automação de implantação. Então, como eu falei, se você usa Jenkins, CircleCI, TravelCI, enfim, ferramenta tradicional de esteira é mais ou menos assim que você está operando hoje. Quais são os gaps desse tipo de modelo? Primeiro, a esteira só vai ser invocada quando você, de fato, tiver a modificação dentro do repositório. Então, caso alguém vai lá e mexa no seu ambiente aquilo não necessariamente vai chamar a automação para fazer reconciliação de estado. Então, alguém vai ter que chamar esteira de novo ou você vai ter alguma outra ferramenta que está monitorando o ambiente para invocar a esteira, para a esteira refazer a implantação. E acaba que um segundo gap é que esse modelo faz com que você tenha que adicionar as suas credenciais de acesso aos ambientes para dentro da esteira. Então, você vai ter, vamos dizer, um acesso privilegiado a seus ambientes. Se você tem uma esteira para vários ambientes essa esteira vai ter acesso a vários ambientes ao mesmo tempo e ela pode ser um ponto de exploração em termos de vulnerabilidade. O segundo modelo é o modelo de pull model. Então, ao invés de a esteira empurrar, alguém vai estar observando os meus repositórios e ele vai lá buscar um resultado declarado se tiver mudança e implantar as mudanças que forem necessárias. Normalmente, quando a gente está falando de G-Tops e a comunidade fala de G-Tops, ela está falando dessa abordagem. Então, se alguém que já conhece ferramentas como Flux, que eu vou falar daqui a pouquinho, ou Argoscd, ambos vão trabalhar em cima dessa modalidade no modelo de pull. Então, a esteira de build ela é praticamente a mesma. A única diferença é que não vai ter uma esteira de implantação. A única esteira que a gente vai ter é a esteira de construção dos nossos artefatos, das imagens e, enfim, da atualização dos nossos arquivos de configuração. Quando tiver mudança lá no nosso repositório que representa o estado desejado do nosso cluster, vai existir uma automação em algum lugar e no G-Tops com Kubernetes. Normalmente, se essa automação está rodando dentro do nosso cluster a gente vai ver isso também. Ela vai estar observando aqueles repositórios seja do nosso registry ou do nosso git lá onde tem os nossos manifestos e, dependendo se tiver mudança, essa automação ela vai fazer reconciliação de estado. Qual é o legal aqui? É que eu continuo tendo a implantação contínua acontecendo no caminho natural do modelo de push, mas agora eu tenho a reconciliação automatizada caso eu tenha um desvio no meu ambiente que não passou pela esteira. Então, vamos supor, alguém vai lá, entra no meu ambiente, deleta um name space, apaga alguma coisa, apaga um deployment, o Kubernetes não vai fazer reconciliação disso pra você, mas se você tiver uma automação de G-Tops nesse modelo de push eu falo assim, olha, presta atenção, lá no meu repositor ele está dizendo que deveria ter um name space com esses artefatos lá dentro, esses objetos lá dentro. Então, ele vai recriar isso pra gente. Então, eu consigo ter agora a reconciliação de estado dos dois lados se teve mudança de fato ele vai implantar e se tiver desvios, ele vai recincronizar. E uma outra coisa legal é que aqui a gente passa a ter uma inteligência distribuída. Então, ao invés de a minha esteira ter todas as lógicas de negócio pra fazer implantação em todos os meus ambientes, cada ambiente vai ter dentro dele uma automação onde ele está observando os repositórios que são referentes a aquele ambiente e fazendo as automações que forem adequadas. Então, ao invés de eu ter uma esteira modo privilegiado, modo deus acessando os nossos ambientes, cada ambiente vai ter acessos aos seus repositórios, esses acessos podem ser inclusive read-only, ou seja, esse automaçala não precisa modificar o conteúdo dos nossos repositórios. Então, a gente consegue ainda mais fortalecer aqui a postura de segurança. E nessa jogada toda, eu expliquei os dois modelos, com a diferença entre eles, aonde que entra o flux. Então, o flux para os mais chegados mas, tradicionalmente, o pessoal conhece ele como flux CD, é um projeto que está em incubação dentro do portfolio da ECF, é um projeto open-source é desenvolvido hoje com mais de mais de 110 contribuidores, se não me engano, mas é um projeto que foi criado, né, a bandeira carregada pela Weaveworks ele tem um modelo de pool model e ele é uma ferramenta para a gente implementar gitópsis especificamente dentro do Kubernetes. Uma coisa que é muito confusa, que eu fiz questão de colocar aqui é que existem duas terminologias quando você vai olhar o flux. Existe o tal do flux, que é isso que a gente está falando aqui, e existe uma outra entidade que se chama GitOps Toolkit. O que é esse GitOps Toolkit? A gente pode pensar que o GitOps Toolkit são as engrenagens que estão dentro do flux. Então eles chamam isso de um nome especial, porque você tem a opção, se você é um engenheiro desenvolvedor de infraestrutura ou de plataforma, você não precisa necessariamente consumir o flux inteiro de lá, dentro do GitOps Toolkit e selecionar quais são as engrenagens que você quer integrar na tua plataforma específica de GitOps, tá? Então o flux pensa assim, é uma ferramenta opinativa em relação ao GitOps que vai usar as engrenagens do GitOps Toolkit, que também faz parte do guarda-chuva de projetos open-source do flux.d E a ideia é que esse GitOps Toolkit nada mais é do que um conjunto, um operator que fala. Então para quem não está familiarizado o conceito do operator, o que é um operator? É a gente ter Custom Resource Definitions ou definições de objetos customizados que a gente vai estender o Kubernetes vai agregar novas APIs para o Kubernetes e Custom Controllers os controladores que vão estar olhando aqueles objetos novos que a gente introduziu dentro do nosso ambiente de Kubernetes. Uma outra informação legal é o seguinte quando a gente vai olhar o flux, existem duas versões existe uma versão 1 e a versão 2 A versão 1 é o que o pessoal agora é de Legacy porque ele está em modo de manutenção, ou seja, não tem nenhuma novidade sendo introduzida no flux v1 e o flux v2 é uma refatoração completa do antigo flux v1. Então, várias coisas mudarem. Então a primeira coisa é, ele não é mais um monolito como era o flux v1, ele agora é um conjunto de microserviços, justamente por conta da arquitetura do GitOps Toolkit eu consigo, o flux vai reaproveitar todas as construções de role-based access control que você tem dentro do seu Kubernetes. Então, toda parte de autenticação e autorização que você já construiu no seu ambiente, o flux v2 vai reaproveitar e você pode usar isso para criar uma arquitetura multitenant, se for caso. O flux v2 consegue trabalhar com múltiplos repositórios de diversos tipos de formato, isso a gente vai explorar um pouquinho também daqui a pouquinho. Uma outra coisa muito legal é que o flux naturalmente não vai trazer uma interface gráfica porque ele não vai ser opinativo nesse nível mas ele vai expor todas as métricas de todos os seus controles no formato prometeus. E isso é muito legal por quê? Porque agora a gente pode construir as nossas próprias interfaces de monitoramento, integrando lá com a nossa stack de monitoramento que muito provavelmente você já está usando no Kubernetes que é prometeus e grafano. Então eu posso criar meu próprio dashboard, a gente vai se der tempo a gente vai ver isso na demonstração também. E por último ele tem capacidade de notificação. Então se acontecer algum evento de reconciliação dentro do mundo de Github que o flux está tomando conta pra você ele pode disparar notificações que podem ser mensagens no Slack no Teams, da Microsoft enfim chamar a sistema de terceiro e por ser uma plataforma open source a gente consegue estender isso praticamente para o infinito. Como funciona a arquitetura? E a arquitetura é bem simples, a gente vai olhar a arquitetura tipo 10 no teste de altura e depois a gente vai abaixar mais um pouquinho antes de cair na demo. Então vamos lá. Como eu falei a gente vai ter a nossa repositória da aplicação aqui eu abstraí a figura da esteira para uma questão de simplificar o desenho esse repositório da aplicação em algum momento vai gerar as nossas imagens que vão estar armazenados lá no container registry. A gente vai ter um cluster de Kubernetes. E aí o que precisa ficar claro é o seguinte o flux ele é instalado dentro do cluster de Kubernetes e a gente vai ver isso na demonstração também. Uma vez que a gente instala o flux dentro do nosso cluster de Kubernetes o que que instalar é implantar os Custom Resource Definitions que são objetos nativos do Kubernetes e implantar os deployment que vão representar os Custom Controllers que vão tomar conta desses objetos customizados que a gente introduziu. Então no final a gente está injetando um monte de manifestos dentro do nosso Kubernetes que vão operar como outras cargas que a gente trabalha e que a gente já tem lá dentro do nosso cluster. Ele é completamente ao suficiente, então ele vai usar o ETCD como data store ele não vai introduzir nenhum tipo de banco de dados adicional para que ele funcione ele é de fato um cidadão de primeira classe no mundo do Kubernetes. Uma vez que eu coloco o flux no meu cluster agora eu vou configurar ele e vou falar assim olha flux eu quero que você observe o estado declarado que está nesse repositório aqui Git e uma vez que você configura ele a gente vai ver como configura ele vai começar a olhar o estado que está lá comparar com o estado que ele está vendo no cluster que ele está implantado e fazer reconciliação de estado que a gente espera que ele faça. A gente consegue controlar o quanto de quanto tempo ele faz isso normalmente o naturalmente o padrão flux funciona no modelo de pull, então de tempo você consegue definir a regularidade que ele vai fazer esse tipo de comparação para fazer reconciliação esse loop de reconciliação dele mas a gente também tem uma arquitetura que consegue fazer através de webhooks, então a vez de você usar só o pullin você consegue acelerar o tempo para ele fazer a reconciliação porque eu posso pegar lá da mistura ele gerar um evento de notificação entrante no meu flux para que ele força a reconciliação de estado então uma mistura seria um híbrido entre o pull e o push mas eu não vou falar disso na demo porque a gente não vai ter tempo uma outra característica que o flux tem e isso é um grande diferencial do flux em si, é que ele tem a capacidade de monitorar o repositório de imagens de containers e observar se teve publicação de novas imagens novas tags eu consigo definir com a minha regra semântica que eu vou estar olhando isso para determinar se teve novidade ou não e dependendo do tipo de política que eu crie isso eu posso pegar o flux que está agora trabalhando só como read only para o meu repositório de declaração de estado do meu cluster e eu passo a ter uma operação de region write porque o flux vai ver que teve mudança no meu repositório de imagens, teve uma tag nova aquela tag bate com uma política que está configurada para ele fazer reconciliação ele vai lá no nosso repositório e faz um por exemplo ou faz um commit um commit numa brem de separada para que você faça automação do pur request perceba que ele não só vai fazer implantação contínua mas ele pode também fazer as automações necessárias para que você consiga aplicar o seu fluxo de git e automatizar essas mudanças de estado lá no repositório de configuração a ferramenta é bem flexível como eu falei é integrado com notificações aqui eu botei como exemplo a parte do slag então toda vez que tiver é quando ele identificar que se é uma nova imagem identificar que teve uma mudança e ele fizer alguma reconciliação vai gerar eventos e esses eventos você pode receber no teu comunicador corporativo não vou gastar muito tempo porque senão a gente não vai ter tempo mas uma vez que a gente entende como ele funciona uma arquitetura multicluster mais trivial possível do flux que são independentes e esses flux podem estar olhando repositórios separados então eu posso ter um repositório de produção e um repositório de staging ou development que o nA ou eu posso usar do mesmo repositório e fazer com que essas instâncias separadas do flux olhem brentes ou caminhos diferentes dentro daquele repositório e isso vai depender muito se você está usando trunk-based development que faz mais sentido usar os paths que a gente só vai ter uma brente única de integração contínua ou a gente vai estar olhando brentes separadas que vivem por mais tempo que seria mais um modelo do git flow então isso aqui a gente está arranhando a superfície das possibilidades mas o que se trazer aqui para a gente entender mais ou menos como é que ficaria a arquitetura se a gente tivesse mais de um ambiente para ter dentro do ambiente vocês e aí uma vez que a gente entender essa arquitetura mais alto nível vamos tentar baixar um pouquinho mais e entender que quais são os custom resources, definitions e quais são os custom controllers que o flux vai introduzindo o ambiente para a gente então o primeiro seria o que a gente chama de source controller e esse controller ele é responsável por fazer todas as automações referentes em repositórios externos buscar essas informações de artefatos e colocar a disposição para que outros controllers consumam essas informações que tipo de informações a gente está falando eu apontar para um repositório git, apontar para um bucket de histórias de objeto estilo a Amazon S3 é um repositório de charts de realm então a gente consegue trabalhar com uma série de fontes o segundo controller já é um controller de vamos dizer assim implantação propriamente dita que vai consumir os artefatos lá do source controller é o realm controller e ele trabalha com objetos chamado realm release então o que que é um objeto realm release ele vai explicar para o flux que ele precisa implantar naquele ambiente um realm chart fazer um release de realm chart então é através desse objeto que a gente vai especificar como ele vai trabalhar com realm assim como a gente tem para real a gente tem para customize ele vai ter lá um objeto chamado customization e é isso que a gente vai ver na nossa demo então eu vou perder muito tempo aqui a gente vai ter um notification controller e o notification controller é basicamente que vai lidar com todas as notificações tanto inbound entranche quanto as outbound entranche, por exemplo, quando eu faço aquela integração de receber um webhook da minseira para acelerar a reconciliação de estado é uma notificação inbound mas eu também vou ter o caso mais comum, são de notificações outbound ou seja, eu quero mandar lá uma mensagem em um canal do Slack e aí para isso a gente vai ter todos os objetos que vão fazer a definição de quais são os meus providers quais são as credenciais do Slack qual canal que vou colocar ou do Teams etc e quais são as regras de alertas que eu quero que ele mande lá para o meu repositório e por último a gente tem o IMAGE Automation Controller que vai fazer justamente aquela reconciliação com o nosso repositório então esse é a parte mais ativa do flux, quando a gente está falando de modificar o conteúdo dentro do repositório do Git que a gente por ventura vem a ter beleza? Corri um pouquinho porque a gente vai olhar um exemplo e esse exemplo é bem parecido com o que a gente vai ver na demonstração então aqui a gente tem uma estrutura de arquivos de um repositório Git qualquer, perceba que aqui a gente vai estar usando customis eu não vou entrar em detalhes no customis porque vai ter uma palestra hoje de customis então eu vou deixar os detalhes só dos customis para essa sessão e a ideia é que qual a ideia do customis eu posso trabalhar com o Verlaze então eu posso definir um base e manifesto para todo o meu ambiente e eu posso ter patches específicos para cada tipo de ambiente e esse patch aqui ele vai estar ali no meu base uma grande simplificação da parte de plantação com customis e no flux eu vou conseguir fazer a definição do meu repositório e aqui eu estou dizendo aonde que está o repositório e qual é a branch que eu vou estar observando então aqui eu já estou fazendo a amarração do flux de como ele vai estar olhando esse repositório aqui embaixo esse é um objeto que está no mesmo IEM para quem não está sempre sendo familiarizado esses três tracinhos, essa separação de dois objetos IEM dentro do mesmo arquivo e a gente vai ver aqui que ele está falando que esse customis ele vai consumir esse repositório e ele vai olhar esse caminho para rodar o controle do customis então ele está falando o seguinte eu vou consumir esse repositório vou olhar esse caminho e vou fazer a reconciliação como se eu estivesse rodando o customis dentro desse repositório então ele vai trabalhar em cima daqueles overlays que eu falei lá do customis eu sei que é muito conteúdo para pouco tempo mas eu espero que agora com a demo a coisa fique um pouco mais tangível então vamos lá, live demo a gente nunca sabe o que esperar então vamos nessa o que que eu tenho aqui de ambientes eu criei o kind então com kind eu tenho um cluster rodando na minha própria máquina então você vai ver que eu tenho um cluster só rodando na minha máquina por uma questão de simplificação qual a ideia aqui, se eu der o CTL get pods a gente vai ver que é um cluster vazio não tem nada lá implantado eu tenho a ferramenta de linha de comando do flux essa ferramenta de linha de comando do flux é o que vai me ajudar a gerar os gamers uma forma mais fácil então fica mais fácil a gente lidar com a construção do flux sem que a gente tenha que decorar todos aqueles objetos novos então é uma ferramenta que ela não é mandatória mas é interessante para quem está começando a trabalhar com flux agora uma capacidade muito legal que essa ferramenta traz comando do processo de bootstrap então vamos fazer aqui o processo de bootstrap eu estou usando o github como o meu repostório de código e eu vou usar esse comando macetado aqui para poder trabalhar com a integração com o github enquanto ele está fazendo a implantação deixa eu explicar o que significa o processo de bootstrap o processo de bootstrap ele vai não só implantar os componentes que a gente viu do flux no meu cluster mas ele já vai fazer toda a marração do meu cluster do flux que está instalado dentro desse cluster com o repositório git externo o command line interface do flux tem a integração com github githleve, bitbuck tinha uma série de repositórios mais famos de git e ele já tem uma série de automação de conseguir falar com a API desse provider, criar os repositórios para a gente então é uma série de automações que ajudam bastante a gente fazer a implantação do flux no nosso ambiente uma notícia legal, a gente fala se você está falando de automação, você está usando a ferramenta de vinte comando para fazer a instalação porque isso é uma demo no mundo real, existe um provider de terraform para você fazer exatamente isso que eu estou fazendo com o flux command line interface então você pode, se você está criando seu ambiente com o Kubernetes com terraform eu posso usar o provider do flux do terraform para fazer no final da implantação do meu ambiente e o bootstrap do meu gitops controller com flux vamos esperar aqui um minutinho enquanto ele está validando aqui se o meu flux vai funcionar e ele já terminou se a gente ver aqui no meu github e der um refresh você vai ver que ele acabou de criar um repositório e eu coloquei para seu repositório privado e se a gente olhar nesse repositório a gente vai ver que ele criou um repositório e ele já fez o commit com os arquivos aqui o que, qual é a ideia do processo do bootstrap é não só fazer a amarração mas ele acredita tanto no gitops que ele usa o gitops para iniciar o próprio flux então se a gente olhar esses objetos aqui por exemplo esse aqui g, o, tk, é gitops to kit por isso que eu achei prudente falar o que ele significa você vai ver que são todas as definições de custom resource definition e os custom controllers que fazem o flux funcionar e a definição do próprio flux já está representada dentro do repositório que ele está observando para manter o seu ambiente sincronizado como isso funciona porque ele vai criar aqui o nosso objeto parecido com o que a gente viu na demonstração ele vai apontar um repositório o meu repositório não precisa ser público porque ele vai usar os mecanismos de autenticação com secret para falar com meu repositório e toda essa amarração de criar uma chave de autenticação do meu repositório para o flux consumir e etc foi feito automaticamente pelo processo bootstrap para a gente então simplifica muito esse wiring inicial e aqui embaixo eu estou falando qual é o objeto de customization que eu quero que ele queira ir para mim então eu estou falando, eu vou olhar dentro desse repositório tudo que você tiver dentro desse caminho eu quero que você reconciliar o estado para mim então tudo que tiver lá dentro desse path dentro do meu repositório que exatamente onde eu estou então tudo que tiver aqui dentro ele vai reconciliar e é por isso que ele está reconciliando o próprio flux então maravilha, vamos acelerar aqui um pouquinho porque eu já historiou tempo mas o Carlos falou que eu posso checar mais uns 5 minutinhos vamos interagir com o nosso repositório então eu vou aqui clonar o meu repositório e vou entrar aqui dentro do meu repositório e eu sabia que o tempo ia ficar muito curto e o que eu fiz eu já deixei uma estrutura de objetos já criado para a gente acelerar aqui a nossa demo, então perceba que atualmente é exatamente o que a gente viu lá no GitHub eu vou copiar aqui esses objetos e você vai ver que eu criei uma série de construções, então aqui é a construção típica do Customize eu não vou entrar aqui no detalhe por uma questão de tempo e vai existir uma apresentação específica de Customize mas é importante dizer que para o meu ambiente de staging que é o cluster que a gente está usando aqui de demo eu inseri mais um conteúdo aqui, então se a gente dar uma olhadinha se a gente dar uma olhadinha nesse arquivo, você vai ver que é exatamente um customization só aqui eu estou falando o seguinte flux, e isso é um objeto do flux que vai rodar o customization control e ele vai falar olha nesse caminho aqui do Git e faça a reconciliação de estado que você encontrar lá e ele vai encontrar meus manifestos com Customize então se eu vier aqui fizer a modificação comitar essas mudanças e empurrar lá para o meu repositório a gente vai ver que em algum momento em algum momento ele vai fazer a reconciliação de estado para a gente, então se a gente voltar aqui para o nosso repositório eu dou um refresh aqui rapidinho a gente vai ver que aquela estrutura que a gente viu na linha de comando apareceu aqui para não dizer que eu estou mentindo se a gente olhar aqui um staging você vai ver que é um Customize padrão isso aqui é um objeto do próprio Kubernetes e eu vou implantar um HelloWord que é basicamente um IndieNext e aí se a gente olhar aqui dentro do nosso objeto de staging a gente vai ver aquele Customization que a gente olhou lá na linha de comando então vamos voltar aqui para a linha de comando e só nesse pouco tempo que eu falei o que ele fez, ele acabou de implantar o nosso objeto perceba que sem necessidade de ter nenhum ponto do modelo do puro eu sempre fiquei para caramba já uma ideia de implantação contínua para a gente fechar que a DMU é legal a gente fazer mudança a partir desse momento eu não preciso mais mexer em nada do flux então vamos supor que eu estou operando em cima o time de SRT, operando em cima dos manifestos da minha aplicação de Stage eu vou vir aqui para uma questão simplificada e fazer pela própria interface eu vou fazer o seguinte, eu quero trocar a versão se a minha internet permitir quero fazer um bump de versão aqui e aí qual a ideia do Git se eu poder fazer isso vamos usar o trunk-based development se eu puder usar isso através de um mecanismo de pur request eu consigo usar toda aquela filosofia da colaboração do Git, revisão etc para me beneficiar na operação então vou criar aqui um pur request nesse momento aqui se eu tivesse a parte de continuous integration configurada alguém seria selecionado para ser o revisor porque ele é o responsável pelo ambiente de Stage só ele pode fazer o merge final ele pode ser automatizado depois que todo mundo der um looks-good-to-me no meu caso aqui é simples, eu vou supor que a gente já fez a revisão tá tudo certo quando eu der o merge por request e a gente voltar lá no meu console um loop de reconciliação de Stage aqui está configurado para fazer de 1 em 1 minuto então daqui a 1 minuto mais ou menos a gente vai ver que esse pode vai sofrer mudança perceba que o flux já percebeu que teve mudança e ninguém chamou o flux e identificou essa mudança e ele vai fazer reconciliação de estado para a gente colocar o nosso pod na versão mais nova perceba que a gente consegue ir para frente e para trás do mesmo jeito e como a gente faz hold back de mudanças usando o Git se a gente voltar no nosso repositório vamos supor que lá no meu ambiente esteja e a gente validou que isso deu problema no nosso usuário e a gente não deu certo eu quero reverter essa mudança vou fazer o fluxo é igualzinho vou abrir um por request alguém vai ser selecionado para fazer a revisão da reversão, o racional de porquê, eu posso mensagens que sejam interessantes e eu vou dar o merge o que ele fez do mesmo jeito que a gente foi para frente a gente agora tem para trás se a gente voltar lá a gente vai ver um pouquinho mais de 1 minuto ele vai fazer reconselhação de estado para fazer hold back isso aqui é muito poderoso porque da mesma forma que a gente sempre ficou com muitas automações e a gente também consegue agora, por exemplo, num cenário de desastre tudo o que eu preciso está lá no meu Git eu posso apagar esse ambiente e fazer o bootstrap do flux o flux vai olhar o repositório que já está populado com uma série de manifestos ele vai recriar o nosso ambiente todo para a gente eu tinha mais coisa para mostrar mas eu gestorei muito tempo então, o que eu vou deixar aqui como referência algumas documentações muito importantes eu vou estar disponível lá no canal da cncf e aqui no evento então esse vídeo é o vídeo que deu ideia deu pontapé inicial nessa terminologia, nessa prática é o vídeo do pessoal da Google com o pessoal da Wevox falando sobre esse modelo de GitOps e agora a gente tem um GitOps.com que tem uma série de conteúdo em relação a só prática e ferramentas desse ecossistema mais novo deixa aqui como referência vocês vão ter acesso aos slides depois perguntas e respostas eu vi que tem uma série de perguntas aqui mas eu não sei se eu não sei se o cat se eu vou conseguir responder isso agora deixa eu ver se tem alguma que... já usou o flit? nunca usei o flit desculpa a gente tenta fazer tirar os notificações mas acontece é... nunca usei o flit o ferramento de vulnerabilidade foi falada o Claire o Trevi enfim, tem uma série aí eu não sei se o cat se quer se pronunciar porque a gente achou muito eu ia só comentar eu vi que tem bastante pergunta e tal e eu primeiro até agradecer da ver agradecer você ao Magno também, estou tentando até não entrar para não manter fluido mas como a gente restaurou bastante tempo o que eu ia pedir assim, as perguntas eu acho que você consegue responder elas pelo que ela também então se você conseguir só para a gente seguir para a próxima mas brigadão aí foi animal até agora todas as palestras foram sensacionais muito obrigado pela D eu vou chamar o Vinicius aqui agora e aí você vai puxando pelas perguntas lá valeu, bicho maravilha cara, obrigado e desculpa aí o Stora nada que é isso, está tranquilo deixa eu só mudar minha câmera aqui agora eu vou sair aqui mas é qualquer coisa cedo