MLOps: deploy de modelos

Estrutura de repositórios e GitHub - Apresentação

Olá, seja bem-vindo ao curso MLOps: Deploy de Modelos. Meu nome é Júlio, e eu serei o seu instrutor. Neste curso vamos continuar a nossa jornada do MLOps.

No primeiro curso aprendemos como pegar um modelo de machine learning e colocar ele dentro de uma API flask. Dessa forma criamos uma aplicação onde outras pessoas conseguiam conectar.

No entanto, só chegamos a fazer o deploy dessa aplicação local, acessando sempre o meu endereço “127.0.0.1:5000” ou o localhost. Então a aplicação, na verdade, não saiu da nossa máquina. E nesse curso vamos aprender como que podemos colocar essa aplicação na web para que várias pessoas possam acessá-la.

Bem, vai ser uma jornada de algumas estratégias que vamos aprender. Então ao invés de aprendermos apenas uma maneira de colocarmos nossa aplicação no ar, colocar nossa aplicação na internet, vamos aprender três estratégias diferentes porque para cada tipo de negócio pode ter uma necessidade diferente, uma habilidade diferente que você prefira. Então vamos ver várias formas onde você vai conseguir encaixar na sua necessidade de negócio.

Primeiro passo vamos aprender a pegar essa aplicação que criamos, a aplicação que está na nossa máquina, e de um jeito bem simples utilizar várias ferramentas do GCP. A primeira que vamos aprender vai ser a utilizar o Compute Engine, vamos criar uma VM, criar um servidor para nós e colocar a aplicação para rodar do mesmo jeito que tínhamos colocado para rodar local no nosso computador.

A segunda estratégia que vamos aprender vai ser uma implantação serverless, vamos conseguir colocar a nossa aplicação no ar sem utilizar um servidor ou pelo menos não vamos ter que configurar o servidor, vamos utilizar de uma aplicação serverless do Google Cloud, que é o App Engine.

Então primeira aplicação Compute Engine, segunda App Engine. E a terceira vamos aprender a como pegar a nossa aplicação flask com modelo de machine learning, colocá-lo dentro de um Dockerfile, colocar ele dentro de um container doc e fazer o deploy dessa aplicação utilizando o Cloud Run, também do DPC.

Então Já vamos ter essa nossa aplicação já com um endereço, uma URL e disponível para qualquer pessoa na internet.

Além disso, lá no final do curso, vamos aprender a automatizar o deploy dessa aplicação utilizando o git hub actions . Assim, toda vez que fizermos uma alteração na nossa API, ela vai ser automaticamente implantada no Cloud Run.

Bom, para quem esse curso é indicado? Vamos continuar na linha de eu tenho um modelo de machine learning, eu fiz uma API e agora eu quero que as pessoas acessem essa API. Então se você tem essa necessidade, se você já trabalha com Analytics, se já trabalha com modelo de machine learning e quer entender como você pode disponibilizar a sua aplicação para outras pessoas, esse curso é para você.

Note que vamos trabalhar com muitas ferramentas diferentes, então são vários conhecimentos que vamos tratar. Desde conhecimentos de servidores Linux, a conhecimento de VM, App Ending, Docker.

Então vamos ver muitas ferramentas, mas não vamos aprofundar nas ferramentas. A ideia é discutir as estratégias e ver várias estratégias diferentes para colocar nosso modelo em produção.

Se você com esse curso quiser se aprofundar em qualquer uma dessas ferramentas, temos os cursos na Alura, cursos e outros tipos de conteúdos, que vão te ajudar no seu objetivo.

Lembrando que você vai sair desse curso com um material pronto para entrar no seu portfólio. Vamos lá para o curso que o material está muito legal!

Estrutura de repositórios e GitHub - Cookiecutter

Então vamos partir do código do curso anterior onde desenvolvemos um modelo de machine learning e colocamos dentro de uma API flask. Então esse é o material do curso, ele vai estar disponível na atividade, mas também sugiro que você dê uma olhada lá no curso, nos vídeos e no código que criamos lá.

Beleza, qual é o nosso primeiro trabalho? Imagina que você desenvolveu esse modelo, essa API e agora você precisa trabalhar com outras pessoas nesse projeto. Uma das coisas que precisamos melhorar nisso é a estrutura do nosso repositório para que outras pessoas consigam entender nossa estrutura, saber onde estão os notebooks do nosso projeto, onde está o arquivo do flask, onde estão as bases de dados, e assim por diante.

Então precisamos melhorar um pouco a estrutura do nosso código, assim vamos garantir também quando formos tentar trabalhar com automação, vamos saber em que pasta está cada um dos arquivos. Então vai ficar bem mais legal, bem mais maduro o nosso projeto.

Vamos precisar de uma estrutura, de um template para o nosso repositório. Estamos falando de um repositório que envolve tanto data Science quanto flask, então o que vamos fazer? Não vamos criar uma estrutura do zero, vamos nos basear em alguma estrutura já aceita pela comunidade, uma estrutura padrão.

Para isso vamos utilizar o Cookiecutter. Primeiro o Cookicutter vai ser a ferramenta para ajudar a criar o template do repositório. O legal dele é que ele não só te ajuda a criar um template, mas você pode utilizá-lo também para usar templates criados por outras pessoas.

Ele é um pacote do Python, e assim como qualquer outro pacote, instalamos com pip install. Uma coisa importante para anotar para esse curso, eu estou trabalhando numa máquina Windows, mas meu terminal é um terminal Linux, estou com o Ubuntu.

No meu ponto de vista eu achei mais fácil para esse curso, vamos trabalhar com Docker, com variáveis de ambientes e acho um pouco mais fácil fazer essa parte no Linux do que no Windows. Mas se sinta à vontade para trabalhar no sistema operacional de sua preferência e adaptar um comando ou outro para funcionar.

Então vamos lá. Estou naquela mesma pasta que vimos e vou agora então instalar o Cookiecutter. Assim como eu disse, qualquer outro pacote do Python você instala com pip install, então vou colocar pip install cookiecutter. Ele vai verificar. No meu caso eu já tenho instalado então ele não instalou nada porque as dependências já estão satisfeitas. Caso você não tenha, ele vai instalar.

Estou com o Cookiecutter instalado, vou só digitar > cookiecutter para testar, ele vai ficar identificado. Ele deu erro porque eu preciso passar alguma coisa, mas ele está instalado.

Bom, qual template vamos usar então? Como eu disse, é um projeto de data Science então se eu for numa página do Google e pesquisar “cookiecutter data science” , vou clicar, no meu caso, no primeiro link onde está escrito “Home - Cookiecutter Data Science - GitHub Pages” . Então esse é um template de repositório feito pela drivendata para projetos de data Science.

Então já é um template famoso na comunidade, já é um template aceito e vai nos atender no que precisamos. Na página já temos toda a documentação do motivo de cada passo, a descrição da estrutura de diretório, então tem todas as pastas, o que você deve ou não colocar dentro de cada pasta e assim por diante. Também se você quiser contribuir para a estrutura de repositório, eles deixam abertos essas contribuições.

Então vamos lá, como eu faço para gerar esse repositório? Eu vou pegar o comando cookiecutter https://github.com?drivendata/cookiecutter-data-science . Notem que o Cookiecutter vai ficar identificado no começo, eu passo esse comando do Cookiecutter, e na frente vai ser qual repositório eu vou querer copiar.

Então vou passar o Cookiecutter. Vou copiar o comando e colar no nosso código. E escolher o repositório do git que eu vou querer pegar. Então o que é o repositório do git? Se eu der uma olhada nele, se eu copiar “https://github.com?drivendata/cookiecutter-data-science” e colar no meu navegador, vai aparecer o template que a drivendata criou.

Então você pode criar seu template também, compartilhar pelo próprio GitHub, assim por diante. Está aqui um exemplo de como criar um template do Cookiecutter. Aqui já ́está o drivendata, passamos o Cookiecutter e o template que queremos pegar. Dou o “Enter”.

Ele vai falar para mim que ele já baixou o repositório, perguntar se eu quero baixar de novo, vou dizer que sim “yes” e ele vai começar a fazer umas perguntas. Primeiro, qual o nome do repositório do projeto, vou chamar de “mlops-deploy”. Ele me pergunta o nome do repositório e ele já me dá uma dica de deixar no mesmo nome do projeto, então vou deixar e é só dar “Enter”. Me pergunta o nome do autor. Essas perguntas são customizações que foram feitas pela drivendata neste repositório.

Quando você cria o repositório do Cookiecutter, quando você cria um template, você pode customizar essas configurações. Essa é uma das partes bem legais do Coockiecutter, você consegue customizar e criar seu repositório de acordo com as perguntas que você vai respondendo.

Ele me pede uma descrição, vou chamar de “curso mlops deploy alura”. De novo, aqui são customizações feitas pela drivendata, ele me pergunta sobre licença, não temos licença. Embaixo ele fala sobre bucket da s3, e ele também já deixa algumas configurações prontas para isso. Não precisamos configurar então é só dar “Enter”. ´Profile aws´ também não, o interpretador do Python é o Python 1 que estamos usando.

Então finalizei, só dar um LS agora e está lá o mlops-deploy, que é o nome que dei para o repositório. Ele criou. Se formos no nosso computador e entrarmos dentro da pasta onde está o mlops-deploy o repositório vai estar lá, seguindo aquele template, aquela estrutura que eles deixaram, que está lá na documentação.

Vamos começar a trabalhar então esse novo repositório que criamos. Vou abrir o repositório no VScode, para ficar mais fácil de trabalharmos, de fazermos as alterações no código que forem necessárias. Conforme falei, estou trabalhando no WSL, então vou abrir meu VScode no WSL para ficar toda a parte de programação, de código, dentro do Linux mesmo.

Já estou dentro do WLS Ubuntu 18.94. Criamos o repositório, mas ele está vazio, não copiamos nada para dentro dele, ele criou um repositório vazio para nós, mas já configurado. Se olharmos no “MLOPS-DEPLOY>README.md” eu tenho uma documentação já básica do meu repositório. Ele pegou o nome, a descrição que demos e criou um README já com tudo isso.

Vamos pegar então o código que temos do curso anterior e colocar para dentro dessa estrutura nova. Começando pelos notebooks, então, esses arquivos com final “ipynb”. Vou selecionar todos, o “analise_sentimento.ipynb”, “House_Prices.ipynb” e “requests.ipynb” e dar "Ctrl + X” para irmos monitorando os que já copiamos ou não. Então vou em “código > mlops-deploy > notebooks” e vou colocar dentro desta pasta.

Vamos voltar lá no código. O que mais temos? A base de dados. Já temos a base de dados, “casas.csv” e se olharmos na estrutura do mlops-deploy, desse nosso template dentro da pasta “data”, temos alguns tipos de pastas para a base de dados para armazenarmos. Tudo isso está explicado na documentação, o que é cada uma.

Como essa nossa base de dados já é uma base de dados bem trabalhada, bem tratada vou colocar dentro da pasta “processed”. Porque é onde eu imagino que faz mais sentido e isso cabe interpretação.

O que mais temos? Tenho um arquivo meu do flask, o main.py , que executa a nossa API. Como esse é um repositório para projetos de data Science, não temos nada específico para falar: “sua API tem que ficar em tal lugar” Então vamos fazer uma adaptação dentro da pasta “src” eu vou criar uma pasta chamada “app”..

Normalmente, o nome que usamos para colocar esses arquivos do flask. Então vou criar a pasta “app” e dentro dela vou colocar o meu script. Então dentro de “Scr” normalmente estão os scripts, o arquivo flask normalmente está dentro da pasta “app”. Uma pequena customização que vamos fazer. De novo, cabe interpretação de como você acha que fica melhor para organizar o código.

O que mais temos? Temos um arquivo “modelo.sav”, é o nosso arquivo do Pickle serializado. E dentro da pasta “mlops-deploy” temos uma pasta já para colocar esse tipo de arquivo, dentro da pasta “models”. Vou colocar o “modelo.sav” dentro de “models”.

Bom, essas duas pastas “novoenv” e “venv” são ambientes virtuais. Não precisamos copiar e colar um ambiente virtual de um lugar para o outro, o ambiente virtual é feito exatamente para criarmos conforme demanda esses ambientes virtuais. Então vamos deixar eles aqui, se precisarmos vamos criar um ambiente virtual.

Dentro do nosso código já temos o gitignore bem mais complexo do que temos lá no outro, então ele vai ajudar bastante. É só mandar para o git o que gostaríamos. Então não vamos copiar ele.

E o “requirements.txt” precisamos copiá-lo para dentro do código. Então vou selecionar ele, dar um “Ctrl + X” e vou colar dentro da pasta “mlops-deploy” com “Ctrl + V” . Ele já tem um “requirements.txt” do template desse repositório da drivendata e vamos substituir pelo nosso porque é o que precisamos das nossas bibliotecas para rodar nossa aplicação flask.

Pronto, já copiamos tudo e agora podemos começar a configurar a nossa aplicação.

Estrutura de repositórios e GitHub - Variáveis de ambiente

Então agora nosso próximo passo vai ser pegar nosso repositório, que já fizemos a reestruturação, e subi-lo para o GitHub. Então vamos ver como faremos isso.

Já estamos com a pasta do “github” aberta, que era do projeto do “Cookiecutter-data-science” e vamos criar um projeto para nós. Vou clicar no ícone do “mais” no canto superior direito da tela, já estou logado com a minha conta, então vou selecionar a opção de novo repositório ou “New repository” .

Um ponto importante, nesse curso não vamos entrar tanto nos detalhes sobre os comandos de git, mas temos bastante material aqui na Alura sobre isso. então se você tiver dúvida ou quiser aprofundar um pouco mais no conhecimento, recomendo procurar o restante de material que temos sobre git.

Vamos dar um nome para o nosso repositório, vou chamar de “mlops-alura” . O nome está disponível. A descrição eu vou pegar lá do nosso código, do README.md que temos a descrição de “curso mlops deploy alura”. E só isso, nenhuma configuração a mais. Vou deixar o repositório como "público", você decide se você quer público ou privado e vou criar o repositório clicando no final em “Create repository”.

Então já estamos com nosso repositório no GitHub, está pronto para subirmos nosso código para lá. Só que antes vamos dar uma olhada no código. Se formos em “MLOPS-DEPLOY > src > app > main.py”, uma das coisas que fizemos no curso de mlops machine learning API foi colocar uma autenticação nos endpoints.

E para esse curso vai ser muito importante essa autenticação porque lembre, vamos abrir nossa API na internet, então se você tem alguma informação que você não gostaria que todo mundo tivesse acesso, é importante essa parte de autenticação.

É uma autenticação simples que estamos trabalhando até então. De novo, se você quiser entender um pouco mais essa parte de autenticação do flask, também tem outros materiais aqui na Alura sobre essa parte de autenticação com flask.

Então vamos lá. Só que a forma como deixamos gravado o usuário e senha da nossa API, deixamos hard coded, deixou escrito no código qual o usuário e a senha. Essa não é uma boa prática e vamos mudar isso agora.

Como posso melhorar isso e com poucos detalhes? Bem, precisamos que o nosso flask receba nessa variável `app.config´ o usuário e senha. Uma forma que fizemos, foi digitar na string, na frente, como ´app.config[‘BASIC_AUTH_URSENAME’] - ‘julio’ . Como podemos então passar isso para o flask sem ter que deixar escrito no nosso código e sendo que vamos subir para o github em um repositório público?

Bom, uma estratégia para isso é utilizar variáveis de ambiente. Vamos ver como podemos fazer. Vou no meu terminal, lembrando que estou trabalhando no Linux, dentro da mesma pasta do nosso projeto e vou criar uma variável de ambiente.

Como eu crio uma variável de ambiente no terminal do Linux? Vou digitar >export TESTE=testevariavel , vou dar um nome para variável de “TESTE”. Vou dar um echo na linha de baixo para imprimir, para mostrar no terminal o que eu tenho dentro de “TESTE”, ficando >echo $TESTE .

Tenho o teste-variavel. Essa variável ”teste” está disponível agora no meu ambiente, então eu posso criar essas variáveis e colocar no meu ambiente. Mas como eu vou pegar essas variáveis que estão no meu ambiente? Como eu pego o “TESTE”, por exemplo, e jogo para dentro do “main.py”?

Agora fiz o import da biblioteca OS, vamos pegar então as variáveis de ambiente. Então vamos colocar app.config[‘BASIC_AUTH_USERNAME’] - os.environ.get() , “environ” de enviroment, de ambiente, e .get para pegarmos uma variável do ambiente. Não criei a variável de ambiente ainda, mas vou garantir que essa variável sempre vai chamar o mesmo nome da configuração do flask, o BASIC_AUTH_USERNAME, ficando app.config[‘BASIC_AUTH_USERNAME’] - os.environ.get(‘BASIC_AUTH_USERNAME’) .

Então eu preciso que no meu ambiente tenha essa variável BASIC_AUTH_USERNAME . Na linha de baixo vou fazer a mesma coisa para o password, e vou mudar o nome, ficando app.config[‘BASIC_AUTH_PASSWORD’] - os.environ.get(‘BASIC_AUTH_PASSWORD’).

Então no código no Linux eu vou precisar criar essas variáveis BASIC_AUTH_USERNAME e BASIC_AUTH_PASSWORD. Mas não vamos criar aqui, pois ainda vamos colocar isso dentro de um ambiente virtual. Meu código agora já não tenho mais hard coded dentro usuário e senha, isso está dentro de uma variável de ambiente. Vamos colocar em todo lugar que fazemos o deploy essas variáveis.

O que mais eu preciso mudar no código? Nós reestruturamos os caminhos e o nosso arquivo pickle está considerando um arquivo que não existe mais, ele está dentro da pasta “models”, então precisamos mudar o caminho dele então.

Como eu chego dentro de “models”? Esse meu arquivo “main.py” está dentro de “app”, eu preciso vir para “src”, para vir para “MLOPS-DEPLOY”, para entrar dentro de “models”. Como eu subo uma pasta? Vou colocar ../ em modelo = pickle.load(open(‘../modelo.sav’,’rb’)) e vim para “src”. Para eu ir para “MLOPS-DEPLOY” vou colocar mais um ../, então modelo = pickle.load(open(‘../../modelo.sav’,’rb’)) . E para eu ir para “models” eu coloco um models/´ , ficando ´modelo = pickle.load(open(‘../../models/modelo.sav’,’rb’)). Aí eu chego em modelo.sav́.

Resolvida essa parte também, quem mais temos no nosso código? Embaixo na parte que executamos nosso app flask, não estamos passando qual IP vamos deixar o host dele escutando. Acessamos com 127.0.0.1. Como vamos fazer o deploy dessa aplicação em vários ambientes diferentes, vamos usar Docker, App Engine, vamos fazer o deploy local, é legal passarmos também o host como app.run(debug=True, host=’0.0.0.0’) assim a nossa aplicação vai escutar as chamadas mesmo dentro da Docker, quanto quando rodarmos no local, ou no App Engine. Então esse 0.0.0.0 vai resolver todos os problemas em todos os nossos ambientes.

Notem que ainda estou tendo um erro, o VSCode está identificando um erro no meu código porque ele não está encontrando algumas bibliotecas e esse é o próximo problemas que vamos resolver. Precisamos instalar as dependências do nosso pacote. Mas para instalarmos as dependências vamos colocar isso dentro do ambiente virtual.

Sobre o curso MLOps: deploy de modelos

O curso MLOps: deploy de modelos possui 129 minutos de vídeos, em um total de 46 atividades. Gostou? Conheça nossos outros cursos de Data Science em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Estrutura de repositórios e GitHub
• Criando um servidor com Compute Engine
• Aplicação Serverless com App Engine
• Containers Docker
• Deploy Automatizado