{"id":4251,"date":"2020-08-27T00:47:16","date_gmt":"2020-08-26T22:47:16","guid":{"rendered":"https:\/\/mribeirodantas.xyz\/blog\/?p=4251"},"modified":"2025-01-31T04:37:17","modified_gmt":"2025-01-31T02:37:17","slug":"continuous-machine-learning-parte-ii","status":"publish","type":"post","link":"https:\/\/mribeirodantas.xyz\/blog\/index.php\/pt\/2020\/08\/27\/continuous-machine-learning-parte-ii\/","title":{"rendered":"Continuous Machine Learning – Parte II"},"content":{"rendered":"Reading time: <\/span> 4<\/span> minutes<\/b><\/span><\/span>\n

Esse texto faz parte de uma s\u00e9rie de 3 partes sobre Continuous Machine Learning. Voc\u00ea pode conferir a parte I aqui<\/a> e a parte III aqui. Esse post \u00e9 uma continua\u00e7\u00e3o da parte I, onde iniciamos nossa experi\u00eancia de automatiza\u00e7\u00e3o em Data Science com GitHub e CML<\/span><\/a>. Nessa parte II, basicamente iremos aprender a utilizar um container do Docker em uma GitHub Action para melhorar o tempo de computa\u00e7\u00e3o.<\/p>\n\n\n\n

Voc\u00ea pode pensar em uma imagem do Docker, Docker Image<\/em>, como uma foto de um ambiente computacional em um contexto onde voc\u00ea pode entregar essa foto para um servidor e ele ir\u00e1 te retornar uma m\u00e1quina virtual igual o sistema da sua foto. Quando um gatilho \u00e9 disparado e o GitHub Actions entra em a\u00e7\u00e3o pela primeira vez, ele cria um container<\/em> a partir da sua imagem e carrega esse container<\/em> Com o container<\/em> carregado, executa as tarefas que voc\u00ea solicitou. \u00c9 por essa raz\u00e3o que utilizando containers<\/em>, a computa\u00e7\u00e3o fica mais r\u00e1pida, pois n\u00e3o h\u00e1 necessidade de instalar pacotes, softwares, depend\u00eancias, configur\u00e1-los, compil\u00e1-los, nada do tipo. J\u00e1 est\u00e1 tudo pronto, de acordo com a sua imagem! De outro modo, todas essas instala\u00e7\u00f5es e compila\u00e7\u00f5es estariam no seu arquivo YAML e seria executado toda vez que o gatilho fosse disparado, que era como est\u00e1vamos fazendo na parte I dessa s\u00e9rie<\/a>.<\/p>\n\n\n\n

Criando uma imagem do Docker<\/h4>\n\n\n\n
\"\"
Image from \u201cBuild a Docker Image just like how you would configure a VM<\/a>\u201d.<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Como voc\u00ea pode ver na imagem acima, voc\u00ea deve escrever as instru\u00e7\u00f5es em um arquivo de texto chamado Dockerfile<\/em> e o Docker, um software<\/em>, ir\u00e1 gerar uma imagem com base nesse Dockerfile<\/em>. Essa imagem, por sua vez, poder\u00e1 ser utilizada para criar o seu container<\/em>, que \u00e9 a m\u00e1quina virtual de fato. Na imagem abaixo, por exemplo, n\u00f3s temos tr\u00eas containers<\/em> sendo geridos pelo Docker em um servidor.<\/p>\n\n\n\n

\"\"
Image from \u201cSi Docker m\u2019\u00e9tait cont\u00e9\u2026 2\u00e8me partie : plong\u00e9e \u00e0 l\u2019int\u00e9rieur des conteneurs<\/a>\u201d.<\/figcaption><\/figure>\n\n\n\n

N\u00f3s iremos basear o nosso Dockerfile<\/em> no Dockerfile<\/em> oficial do proejto CML<\/span>. Vai ficar assim:<\/p>\n\n\n

\n\t\t\t\t
FROM dvcorg\/CML<\/span>\r\nRUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9 && \\\r\n    add-apt-repository 'deb https:\/\/cloud.r-project.org\/bin\/linux\/ubuntu bionic-cran35\/' && \\  \r\n    apt update && \\\r\n    apt install -y r-base && \\\r\n    R --silent -e "install.packages(c(\\"igraph\\", \\"ppcor\\", \\"scales\\", \\"Rcpp\\"))" && \\\r\n    wget -c https:\/\/github.com\/miicTeam\/miic_R_package\/archive\/v1.4.2.tar.gz && \\\r\n    tar -xvzf v1.4.2.tar.gz && \\\r\n    R CMD INSTALL miic_R_package-1.4.2\/. --preclean<\/pre>\n\t\t\t<\/div>\n\n\n\n
Como voc\u00ea pode ver, tem uma parte das instru\u00e7\u00f5es que costum\u00e1vamos ter no arquivo CML<\/span>.yaml<\/code>  (na vers\u00e3o utilizada na parte I dessa s\u00e9rie). \u00c9 aqui que est\u00e1 a m\u00e1gica! Por causa disso, o CML<\/span>.yaml<\/code> vai ser mais curto agora, o que significa que ter\u00e3o menos instru\u00e7\u00f5es para serem executadas sempre que o gatilho do GitHub Actions disparar. O novo CML<\/span>.yaml<\/code> deve ficar assim:<\/p>\n\n\n
\n\t\t\t\t
name: dvc-CML<\/span>-miic\r\non: [push]\r\njobs:\r\n  run:\r\n    runs-on: [ubuntu-latest]\r\n    container: docker:\/\/mribeirodantas\/cml-test:r\r\n    steps:\r\n      - uses: actions\/checkout@v2\r\n\r\n      - name: cml_run\r\n        env:\r\n          repo_token: ${{ secrets.GITHUB_TOKEN }}\r\n          GDRIVE_CREDENTIALS_DATA: ${{ secrets.GDRIVE_CREDENTIALS_DATA }}\r\n        run: |\r\n          R --version\r\n\r\n          dvc pull\r\n          Rscript infer_network.R\r\n\r\n          # Write your CML<\/span> report\r\n          echo "## Model Metrics" > report.md\r\n          cat metrics.txt >> report.md\r\n          echo "## Data visualization" >> report.md\r\n          CML<\/span>-publish network_diagram.png --md >> report.md\r\n          CML<\/span>-send-comment report.md<\/pre>\n\t\t\t<\/div>\n\n\n\n
Na figura abaixo, \u00e9 poss\u00edvel ver a diferen\u00e7a entre o velho e o novo CML<\/span>.yaml<\/code>. Movendo o slider<\/em> de um lado para o outro, voc\u00ea pode comparar. Voc\u00ea tamb\u00e9m pode ver diretamente no GitHub clicando aqui<\/a>.<\/p>\n\n\n\n
\"\"\"\"<\/div><\/figure>\n\n\n\n
Salve esse arquivo com o nome Dockerfile<\/code> na pasta do reposit\u00f3rio (seu reposit\u00f3rio deve estar como aqui<\/a>) e atualize o seu CML<\/span>.yaml<\/code> como no c\u00f3digo acima.<\/p>\n\n\n\n
Para gerar a imagem do Docker e public\u00e1-la no Docker Hub, voc\u00ea precisa executar os comandos abaixo. Antes disso, claro, voc\u00ea precisa ter o Docker instalado no seu comptuador (instru\u00e7\u00f5es para Ubuntu aqui<\/a>). O primeiro comando vai demorar um pouco, ele est\u00e1 criando sua imagem, mas n\u00e3o se preocupe: isso s\u00f3 acontece uma vez. \u00c9 agora que ele ir\u00e1 baixar os arquivos, programas, pacotes, depend\u00eancias, compil\u00e1-los, instal\u00e1-los, etc. Parte do que est\u00e1vamos fazendo toda vez que d\u00e1vamos um git push<\/code>, est\u00e1 sendo feito agora mas uma \u00faltima vez. Se voc\u00ea entendeu a explica\u00e7\u00e3o at\u00e9 agora, deve ter ficado claro como vale a pena utilizar containers<\/em>, principalmente para projetos maiores e mais complexos do que o de exemplo que estamos fazendo aqui \ud83d\ude42 .<\/p>\n\n\n
\n\t\t\t\t
# Create the Docker image from the Dockerfile\r\nsudo docker build -t mribeirodantas\/CML<\/span>:r -f .\/Dockerfile .\r\n# Login to Docke Hub\r\nsudo docker login\r\n# Upload it to Docker Hub. GitHub will always download the\r\n# Docker image from there.\r\nsudo docker push mribeirodantas\/CML<\/span>:r<\/pre>\n\t\t\t<\/div>\n\n\n\n
Testando sua imagem do Docker<\/h4>\n\n\n\n
Ainda n\u00e3o sabemos se de fato isso ir\u00e1 funcionar, portanto n\u00e3o iremos realizar um commit<\/em> na branch <\/em>principal, a master<\/em>. Vamos criar uma branch<\/em> e criar um pull request<\/em>, utilizando a ferramenta de linha de comando gh<\/code>, assim como fizemos na parte I dessa s\u00e9rie.<\/p>\n\n\n
\n\t\t\t\t
git checkout -b docker_ghactions\r\ngit add -A\r\ngit commit -m 'Makes use of Docker to speed up GH Actions checks'\r\ngit push origin docker_ghactions\r\ngh pr create --title 'Makes use of Docker to speed up GH Actions checks'<\/pre>\n\t\t\t<\/div>\n\n\n\n
No experimento que fizemos na Parte I, voc\u00ea deve se lembrar que demorava cerca de 7 minutos para a checagem do Pull Request<\/em> chegar ao fim. Agora, utilizando o container<\/em> do Docker, demorou menos de 2 minutos. Levando em considera\u00e7\u00e3o que esse \u00e9 um projeto simples, com um dataset<\/em> pequeno, poucas depend\u00eancias, o ganho pode ser muito maior na realidade. Legal, certo? Vamos aceitar esse Pull Request<\/em> e mesclar esse commit<\/em> \u00e0 nossa branch<\/em> principal.<\/p>\n\n\n
\n\t\t\t\t
# This command will merge all open push requests.\r\n# We only have one, so it will merge the one we have opened.\r\ngh pr merge<\/pre>\n\t\t\t<\/div>\n\n\n\n
Talvez uma pergunta que possa ter vindo \u00e0 tona \u00e9 por qual raz\u00e3o estamos deixando o dvc pull<\/code> no arquivo CML<\/span>.yaml<\/code> em vez de coloc\u00e1-lo no Dockerfile<\/em>, para que o dataset<\/em> seja baixado apenas uma vez. Afinal de contas, baixar datasets<\/em> grandes toda vez que criarmos um Pull Request<\/em> pode ser um pouco.. desagrad\u00e1vel \ud83d\ude00 . Faz sentido, o racioc\u00ednio est\u00e1 correto. No entanto, o dvc pull<\/code> funciona como o git pull<\/code>. Se n\u00e3o tiver nada de novo, ele n\u00e3o faz download<\/em> algum. Se tiver algo novo, ele faz o download. Se deix\u00e1ssemos o dvc pull<\/code> no Dockerfile, o dataset<\/em> mais atualizado n\u00e3o seria baixado em futuros Pull Requests<\/em>.<\/p>\n\n\n\n
Por hoje \u00e9 s\u00f3 \ud83d\ude42<\/p>\n