 Desculpa, é seguir, o Gonzalo vai contar e mostrar-nos uma coisa nova que sinceramente hoje eu ouvi falar muitas vezes, mas falo a sua mínima ideia o que é, e o Gonzalo vai dar-nos uma introdução ao mundo de cobernete, o cobernetes, não sei o que você diz, passando pela explicação de como criar uma peradora de cobernetes para instanciar e gerir sites WordPress, e terminando com a partilha da experiência no desenvolvimento do operador atualmente utilizado do EZWP. Obrigado, Gonzalo. Obrigado, boa tarde a todos. Tanto a apresentação é sobre cobernetes, não sei só quem estava aqui na apresentação anterior, mas vai ser um bocado difícil melhorar ou ser melhor que a apresentação anterior, eu posso fazer alguns efeitos senores que a minha boca, mas não vai ser tão interessante. Bom, então a apresentação é sobre o WordPress em cobernete. Já lavamos, só última pequena apresentação sobre mim, o meu nome é Gonzalo Lourenço, sou o TecLidna Nameship no Departamento de Cloud, temos vários serviços a correr, é tudo em cobernete, tudo no nosso clússer, o backend é tudo instanciado em cobernetes, com vários clússers, temos o nosso Data Center, portanto temos o clússer de on-prem, e usamos também o Data Center da Cloud da Amazon também quando necessário. Assim, temos também o EZWP, que é aquilo que nos traz cá, também para mostrar aquilo que está por trás da lógica de negócio, portanto o EZWP é um instanciador do WordPress, o cliente vai lá e consegue instanciar um site do WordPress em poucos segundos. E eu hoje trago o que é que está por trás do EZWP, que é cobernetes. Quem é que daqui já trabalhou ou conhece, já ouvi falar em cobernetes, assim, manual. Bom, cobernetes tem um outro conceito associado que é Docker containers. Para quem está habituado à administração dos temas é uma espécie de máquina virtual e quem sabe que cobernetes e Docker containers vão me dar um conceito aqui, mas é uma espécie ao face do comparativo com máquinas virtuais. Normalmente compara-se o que é um container e uma máquina virtual, mas não tem nada a ver uma coisa com outra. Mas praticamente o cobernetes o que faz é existe um cluster, vários servidores nós instalamos no cobernetes e o cobernetes passa a gerir as imagens Docker no meu cluster. Portanto, eu posso ter, por exemplo, um site que tem um WordPress, por exemplo, que existe em imagens Docker e eu digo ao cobernetes, olha, instancia aqui um pod que é o elemento mais básico do cobernetes, instancia aqui um pod no meu cluster cobernetes e eu tenho certeza que ele vai correr num servidor qualquer, a mim não me interessa, mas ele vai correr por lá. Bom, então, começando pelo básico dos cobernetes, aquele que são os recursos mais básicos e o recurso mais utilizado é o pod, que é o pod tem lá dentro um ou mais containers, aqui é onde corre o serviço o WordPress, o que for, posso pôr aqui o que me aprecia. Depois temos um serviço que é um tipo de recurso que me permite, que conheço os pods e me permite routear os pedidos HTTP ou outros tipos de protocol para o meu pod, um ingresso, o ingresso que faz é routei a consuante de regras, por exemplo, eu quero o meu blog.gonçalo.com a ir para um determinado serviço, mas eu quero o meu admin.gonçalo.com a ir para um outro serviço diferente e é este ingresso onde eu coloco todas estas regras de redirecionamento. Depois temos um pvc, que é aquilo que me permite persistir os dados, guardar os dados, criar um volume dentro de, criar um volume, ou seja, se eu associo depois de um pvc a um pod e os meus fechados, por exemplo, ficam guardados aqui dentro deste volume, se eu, por algum motivo, matar este pod e iniciar um novo associado a este pvc, os meus fechados mantêm-se lá dentro de um pvc onde desaparece. Depois temos um secret e um config map que são fechados de configuração, que serve para, eu também, se quiser persistir fechados de configuração e partilhar os mesmos fechados de configuração com vários pods, eu posso fazer. E o secret serve para guardar informação mais confidencial, tokens, passwords, o que for. Não vamos entrar por aí, em termos de segurança, isso porque era todo uma outra, uma outra, uma outra conferência. Bom, dentro de um pod temos um ou mais containers, dockers. Tipicamente temos um container dentro de um pod, e é isso que é aconselhável, é isso que, que normalmente se faz. Mas pode haver o caso em que queremos ter dois containers, e este é um exemplo puramente académico, mas pode haver o caso em que temos dois containers a correr dentro de um pod, neste caso temos um engine X, a expor o porto 80 e o pod em si tal expor o porto 80, e depois temos um outro serviço, um outro container aconselhável dentro, expor o porto 9000, e o engine é que sabe, todos os pedidos que chegam aqui pelo porto 80, sabe rotear-los para o serviço que é o porto 9000. Bom, então, resumindo, tipicamente um site ou um serviço ou uma tecnologia qualquer que nós queramos instanciar dentro de Kubernetes que queramos expor ao mundo, Tipicamente, inicializamos um pod, dizemos ao Kubernetes, olha, toma este pod, este pod tem estas configurações, tem estes segredos, tem este pvc, porque eu quero persistir os dados, eu podia não querer persistir, pode haver o caso em que é puramente front-end e não tem, e não tem qualquer, por exemplo, a minha landing page pode não ter dados persistentes, eu posso não querer ter persistidade, portanto aí só precisaria de um pod, provavelmente confie o map e o secret, mas pode haver o caso e é o exemplo que nós vamos ver em que o pod é o site WordPress do cliente, e aí sim, obviamente temos interesse em persistidades, e depois temos o service e o ingress, que é aquilo que nos faz chegar à informação que eu pedi, ou seja, é aquilo que faz com que o pedido saiba chegar ao pod correto. Bom, uma das vantagens de Kubernetes é nós podermos também ter vários pods, é a mesma informação, portanto, o mesmo serviço replicado por vários servidores, ou no mesmo servidor, mas ter vários pods a correr, e isso eu posso definir no Kubernetes, quando eu diga assim, olha, é no próximo slide, é o chamado deployment, há outro tipo de workloads, que é o que se chama, mas o tipo deployment, que é um recurso, eu defino quantos pods é que eu quero correr neste tipo de serviço, por exemplo, eu posso dizer assim, eu quero que este cliente esteja a coer o meu serviço WordPress, o seu serviço WordPress, o site WordPress, mas em três instâncias diferentes. Outro exemplo podia ser, se eu tivesse um serviço de streaming, de futebol, por exemplo, eu sei que às 8h30 vai dar o Sporting Benfica, portanto, eu sei que vai ver um pico de pessoas a querer aceder aos meus serviços, e eu posso, com isso, dizer ao meu cobranete, eu diga assim, olha, eu tenho um deployment com uma réplica de três serviços, estão três pods a correr ao mesmo tempo, e agora eu posso pods a correr em servidores diferentes, ou no mesmo servidor, cada pod tem os seus recursos alucados, e eu posso dizer, olha, às 8h30 eu quero 10 pods a correr, portanto, eu consigo fazer um escalamento, consigo escalar para cima, escalar para baixo, e eu acho que eu consigo anteceder. Outra coisa, todo, portanto, o cobranete é tudo definido por linguagem, por yamafiles, portanto, é tudo descrito, existe uma antedologia que nós fazemos na nameshift, que é githops, nós pomos o nosso, e o Kinect explicou há bocado também com githubactions, e nós fazemos exatamente o mesmo, portanto, nós pomos o nosso código, pomos a infraestrutura toda definida em yamafiles, e depois com githubactions compilamos as imagens Docker, e depois nos clusters estão sempre à escuta de novas versões dentro do github, e sempre que há alguma atualização, vamos buscar a nova configuração, e aplico-em-se a configuração no cluster cobranete. Bom, fazendo aqui a transposição para o mundo WordPress, aquilo que nós fazemos, e aqui o exemplo que eu vou dar agora não é exatamente o que nós fazemos, o que nós fazemos eu vou explicar depois no passo a seguir, mas isso seria um exemplo em que se nós tivéssemos um back-end, e o nosso back-end tivesse de instanciar, manualmente, os recursos dentro do WordPress, então seria mais ou menos isso que acontecia. Eu, o nosso cliente vai ao site, escreve, olha, eu quero um site WordPress, clica no nosso back-end o que faz, ok, vai ao cobranete e diz assim, olha, instante-se em um pod com imagem WordPress, na verdade não é um pod, é um deployment, e eu posso dizer quantas replicas eu quero, mas para simplificar a coisa, vamos dizer que é um pod. O back-end também diz, cria-me este secret, que tem um segredo qualquer lá, pode ser o passador da base dados, pode ser o que for. Instante-se-me também um pvc, um persistent volume claim, que é aqui que vamos guardar os dados, os cheiros do cliente, os fecheiros, as fotografias, o que for, nos cheiros de configuração, tudo o que o cliente fizer vai ficar guardado depois só haver algum update de versão do WordPress, ou o que for, ou por acaso, um servidor, onde o pod está a correr fora-baixo, o que o cobranete faz é ele detecta que o pod, que o servidor foi abaixo, e instante-se-se aos podes todos que estavam a correr naquele servidor, e instante-se aos pelos outros servidores todos automaticamente. E por isso, como instante-se a um pod num outro servidor, os fecheiros que estão a guardar no pvc não são perdidos, e o pod que está a se instante-se a num outro servidor vai buscar os fecheiros a este pvc. Um serviço, e o ingress, e se já vimos porquê, porque queremos que o cluster conheça como chegar aos podes, mas é preciso mais. Portanto, o backend, provavelmente, iria também instante-se a um pod com o MySQL lá dentro, uma imagem Docker MySQL, o que é que iria fazer mais, iria um pvc para persistir os dados de MySQL, obviamente, e depois um serviço para expor para que o meu pod de WordPress, ou o pod do cliente, o site WordPress, consiga chegar muito facilmente ao cluster MySQL, para instante-se a base dados, instante-se o user, as tabelas todas, etc. Mas não fica por aí, porque nós temos mais funcionalidades, e se utilizador quiser, por exemplo, criar um backup, o que é que o backend me fazia? Criava-me um pod com uma imagem específica que nós criámos para que saiba falar com o pod de WordPress, falar com o MySQL, que o pvc e clona faz backup de todo o sistema do cliente, para fazer restore também, caso o cliente que era fazer. Tem a lista de backups e faz restore. Então o backend iria criar um pod, especificamente para criar restore, e também, por exemplo, um secando de vulnerabilidades que nós temos também. Mas isto é só para ter a imagem de toda a complexidade. Não é só isto, porque há muitos mais recursos que o backend teria de criar só para instanciar um site WordPress. Muitos mais recursos. Há um tipo de recurso que é o network policies, que é tipo firewall, queria mais regras, quem pode aceder aqui. Mas há outros recursos também, que é muito mais... Isto é só uma pequena imagem, só para exemplificar o que o backend teria de fazer. E para resolver toda esta complexidade, chega os operadores de cobernetes. E nós criámos um WordPress operator, ou seja, um operador WordPress para cobernetes, mas praticamente um operador de cobernetes simplifica-nos toda esta configuração, a necessidade de instanciar e controlar todos esses recursos, porque o operador já faz isto por nós. O operador tem um controlador, e é neste controlador que nós vamos colocar toda a lógica que nós queremos para observar o estado em que a nossa arquitetura, o estado da nossa arquitetura. E se acontecerá alguma coisa, o controlador percebe que há uma diferença daquilo que existe, daquilo que havia de existir e faz o self-healing para... tenta resolver logo o assunto, e eu vou dar aqui um exemplo só para ser claro. Portanto, este controlador de um operador pode haver vários controladores, mas eu programo aqui o controlador para olhar para todos os recursos e estes são os recursos que eu quero com o controlador Olho. Para o caso do WordPress, era o exemplo que estava a seguir, eu quero que o controlador Olho para estes podes em específico, para este serviço, para este ingresso, mas, se por acaso eu manualmente entrar numa classe de cobernetes e deliberadamente apagar, por exemplo, um serviço, o controlador vai perceber, peraí, alguém é pagou isto, não devia ter sido apagado porque o estado vai instanciar o serviço porque alguém o apagou. O mesmo exemplo que eu dei à apacada, se o servidor for abaixo, o controlador percebe, olha, peraí, estes podes não existem, deviam existir e eu vou instanciá-los no outro sítio. Custom Resources Custom Resources são recursos pessimizáveis, entanto, são recursos que... O coberneto tem recursos nativos, que são aqueles que os exemplos fiquem à apacada, para o serviço de ingressas, os pbcs, muitos deles, mas eu posso criar os meus próprios recursos, o coberneto, por si só, não sabe o que são, mas eu posso definir um recurso, eu posso dizer assim, eu quero um recurso chamado WordPress e digo ao meu coberneto, diga assim, olha, criei um recurso chamado WordPress e ele está bem, está criado, mas não faz nada, não acontece nada, mas o recurso existe. Depois, qual é que é o truque? Que é a minha definição daquilo que é um recurso de cobernetes? Digo-lhe onde é que está a base dados, digo-lhe quais são os plugins, digo-lhe qual é que é o tema e é isso que acontece quando um utilizador vai ao EasyWP, pede um site WordPress configura, tanto o EasyWP pede-lhe qual é que são os plugins que tu queres, qual é o template que tu queres e depois na parte do backend você está traduzido num sherry handle e este sherry handle é passado para o coberneto e os cobernetes criam um recurso chamado WordPress. O truque está em, quando eu crio este recurso em programar o controlador para ficar observar recursos WordPress e toda a programação está aqui neste controlador, eu digo, sempre que encontrasse um recurso WordPress então eu queria me instanciar-me nesses recursos nativos do WordPress do coberneto pod, services, ingressos, etc e e observa, isso acontecerá alguma coisa faz com que o estado seja aquilo que eu quero que seja, é isso que fica tudo definido aqui portanto na verdade é isso que acontece o cliente criam um site, um WordPress o backend cria um recurso WordPress o WordPress controller um recurso e cria e observa os recursos nativos que são criados dentro do coberneto nomeadamente um pod com imagem WordPress um ppc um serviço e um ingress depois também faz mais coisas que é cria também um recurso customizado chamado MyCycleDB que é uma base de ades que depois a não está aqui mas depois nós também temos um operador o que é que faz? observa recursos customizados neste caso de MyCycleDB que é uma base de ades ele disse, ok, há um recurso chamado database portanto eu sei, eu conheço este recurso sou eu com o controle portanto eu sei o que temos que fazer tenho que criar uma base de ades no meu cluster de MyCycle e criamos também há outros recursos chamados user posso criar o tipo de coisa e criamos também um outro recurso customizável chamado QVexacutor que também é controlado por outro operador é capaz de executar comandos no pod WordPress e estes comandos são para inicializar por exemplo o site WordPress quando o utilizador vai ao ISAWP e pede um site o site vem já configurado não tem de passar pelos steps de configuração vem já tudo configurado e é no início, portanto, o controlador vai me instanciar por uma ordem que faça sentido instanciar, portanto, ele diz assim olha, dá-me um cobernetes dá-me um pod dá-me um pvc, dá-me um service, dá-me um ingress agora, eu tenho de esperar o controlador sabe, sabe o estado deste pod e espera que ele fique ativo e a partir do momento em que fique ativo vai-me instanciar este recurso que o QVexacutor que o que faz é isso que está comandos neste pod o QVexacutor o cliente de WordPress tem de instanciar o site WordPress dentro daquilo que é o nosso operador de WordPress temos vários controladores temos o controlador que eu falei agora o controlador WordPress instancia site WordPress temos um controlador de vulnerability scanner faz, cria vários pod serviços, cria pvcs WordPress backup cria pvcs e cria mais uns cantos sobre o site do cliente o WordPress backup link o que faz é cria um link para o cliente para fazer o modo de seus próprios backups WordPress restore e mais, há mais outros controladores mas estes são os básicos para esta apresentação mas depois quisemos falar sobre outras coisas temos também outros operadores temos outros operadores que desenvolvemos há um operador que é por exemplo para instanciar certificados SSL temos o HTTPS o operador que trata esta parte toda o operador de MySQL temos operadores Pantãos que são o Pantosource e já vos vou dar o link e estou quase a terminar se quiserem qualquer um de vocês quiserem começar a desenvolver operadores cobernetes é muito fácil, portanto tenho aqui o operator SDK que é open source e permite-vos muito facilmente começar um projeto, um operador de cobernetes porque já tem tudo aqui tem instancia logo o projeto tem logo os certos que vocês precisam e não têm grande dificuldade em começar depois, à medida que vocês sabem o que é que eles querem fazer, vão à minha experiência Aconselho-vos a não usar isto porque isto mete-vos muito lixo no projeto muita coisa que vocês acabam por não precisar mas aconselho-vos a interagir diretamente com as bibliotecas nativas que o builder que o próprio operator SDK usa mas pronto para começar isto é mesmo o meu open source e este é o último slide antes do último final o open source nós consumimos muito o open source mas achamos que é uma transação nós também temos de contribuir para o mundo open source e por isso este é o nosso repositório caso que querem ver o que a gente anda a fazer contribuímos muito para cobernetes operadores ainda semana passada lançamos um outro projeto com serviço de NVIDIA mas temos lá muitos operadores há um que se chama mayfly tem muitos projetos que nós vamos pôndo obviamente dentro daquilo que o negócio nos permite pôr mas sempre possível que todas as ferramentas que nós usamos sentamos para tornar o open source e pronto, esta é a equipa DevOps nós estamos todos remotos tudo remotamente Itália, Sérvia, Turquia mais pela Europa também muitos nos Estados Unidos mas sentamos que seja tudo nesta time para ser mais fácil de trabalharmos mas tentamos sempre possível encontrarmos a isso foi na Turquia tivemos na KubeCon em Amsterdam agora no mês passado eu hoje vou para Bologna também então vamos encontrarmos-me lá e pronto, e é isto se tiverem questões forças se me quiserem encontrar no Twitter e fazerem questões é geflorenco, não sou muito ativo mas estou lá, se quiserem fazer alguma pergunta e é isto, se tiverem alguma questão força sim, normalmente típicamente uma base de dados em cobernetes o que acontece é que há pods que é para expor, portanto, a correr o serviço, por exemplo, em MySQL pode ser vários pods em que tens, eu aqui, especificamente e em pormenor, não sei, mas típicamente pode ser o master and slave ou pode ser vários pods a correr ao mesmo tempo mas os binários, os séries a base de dados em si está a ser guardada num persistent volume claim que depois está associado a um persistent volume que estará associado a um storage class e por aí fora era outro mundo mas há de ter um pvc que tem lá os séries todos guardados relativamente ao criar a backups tens várias soluções e aqui depende da tecnologia que tu estás a usar porque imagina, se usar há um tipo de estratégia se usar um tipo de é o chamado CSI se usar um tipo de tecnologia, tens outro tipo de estratégia mas o truque aqui é pegar no pvc e ao cria um snapshot do pvc ou clonas do pvc e garantis que mesmo que os pods morram mesmo mate os pods o pvc está lá e garantidamente tu consegue e às novas vezes novamente o pod os fichas estão lá, os binários estão todos lá e consejos de recriar novamente o teu cluster de base de dados depois tens soluções, como falaste no Valer tens soluções que fazem esse backup automaticamente do cluster ou da base de dados e depois aí depende da tecnologia o Kubernetes em si só não te dá soluções de backup não tens nada tens aí depois projetos e há muitos projetos de backup que te dão essa solução mas o Valero é das mais utilizadas e é o melhor que podes usar tipicamente um pvc está sempre associado a uma tecnologia que é o chamado CSI que não sei agora o que significa mas no CIF, o CIF depois a parte baixa de como funciona under the hood, o como funciona é que há de ter também o próprio cluster onde guarda a informação distribuída por vários servidores poderá ser assim ou não mas aí também já não te consigo dar muitas muitas informações obrigada, mais uma pergunta vamos, temos uma base aliás, há abazades públicas de CVS exatamente e fazemos a comparação dos plugins que estão instalados, dos templates e vemos se existe naquela versão de plugin e template, se existe alguma vulnerabilidade conhecida essa é a primeira versão do nosso plugin do nosso sistema de vulnerabilidade que ainda não está lançado, ainda estamos a fazer algumas coisas e a partir daí, pronto, queremos desenvolver mais, mas para já essa é a forma mais básica do nosso sistema de vulnerabilidade não, aliás vai ser concorrente ao da luta e sequente obrigada, já não temos tempo para mais perguntas obrigada, Gansal