Avaliar em qual repositório o Dockerfile deve ser armazenado

[fjuniorr]

Atualmente o Dockerfile utilizado no age7 está em um repo dedicado. Encontramos um erro hoje porque os arquivos requirements.txt estavam duplicados e divergiram (livemark não foi inserido como dependência em um deles).

Isso levantou a pergunta sobre como armazenar o Dockerfile de determinado projeto. Algumas fontes para leitura:

• What code-repository should the Dockerfile get committed to?
• Splitting application code and docker deployment files

[gabrielbdornas]

Acredito que este issue esteja relacionado com o #131. Penso podermos deixar o processo de criação e publicação da imagem no docker hub totalmente dentro deste repositório. Isso simplificaria os repositórios utilizados e facilitaria no momento da manutenção.

[gabrielbdornas]

Em 15/02/2023:

• Atualizei requirements.txt com arquivo do repositório docker.
• Incluí Dockerfile
• Construí imagem dentro do container via docker.sh.
• Incluí imagem gerada apenas na máquina no target make container-bash.

Caso processo funcione (necessário testar por pelo menos dois dias):

• [ ] Arquivar repositório docker-age7.
• [ ] Excluir imagem dockerhub.
• [ ] Executar target make container-bash para verificar seu funcionamento.
• [ ] Executar novo target make image para atestar seu funcionamento apenas se arquivos dependência forem modificados.
• [ ] Excluir imagem gabrielbdornas/dtamg-age7:latest da máquina via docker rmi -f 17a67456a3c0

[gabrielbdornas]

Em 16/02/2023 vi que o processo não rodou. Ao acessar a máquina e executar o arquivo conforme rotina cron ./docker.sh percebi que o novo comando responsável pela criação da nova imagem docker não havia rodado:

https://github.com/transparencia-mg/age7/blob/71011a866ca7c06fe8d6bea7c39763909fdc136a/docker.sh#L3

Rodei o comando docker build . --file Dockerfile --tag dtamg/age7:latest isoladamente e percebi que ele não estava conseguindo realizar as instalações por bloqueio na proxy. Problema foi resolvido com a criação do arquivo ~/.docker/config.json conforme sugestão da documentação docker. Incluí a mesma informação de proxy utilizada na máquina CKAN (git config --list).

Na segunda tentativa de executar o comando o problema da proxy foi resolvido, mas o erro de instalação do pacote R dtamg interrompeu a criação da imagem:

Installing dtamg [0.2.5] ...
        FAILED
Error: install of package 'dtamg' failed [error code 1]
Error installing package 'dtamg':
=================================

Warning in untar2(tarfile, files, list, exdir, restore_times) :
  skipping pax global extended headers
* installing *source* package ‘dtamg’ ...
** using staged installation
** R
Error in parse(outFile) :
  /tmp/RtmpzeXFb1/R.INSTALL67e119fbb98e/transparencia-mg-dtamg-r-461666e/R/flatten_resource.R:41:87: unexpected '>'
40:   resources_field_names <- c(list(resource$schema$field_names),
41:                  purrr::map(fk_resources, ~ dp$get_resource(.x)$schema$field_names)) |>
                                                                                          ^
ERROR: unable to collate and parse R files for package ‘dtamg’
* removing ‘/usr/local/lib/R/site-library/.renv/1/dtamg’
Traceback (most recent calls last):
12: renv::restore()
11: renv_restore_run_actions(project, diff, current, lockfile, rebuild)
10: renv_install_impl(records)
 9: renv_install_staged(records)
 8: renv_install_default(records)
 7: handler(package, renv_install_package(record))
 6: renv_install_package(record)
 5: withCallingHandlers(renv_install_package_impl(record), error = function(e) {
        vwritef("\tFAILED")
        writef(e$output)
    })
 4: renv_install_package_impl(record)
 3: r_cmd_install(package, path)
 2: r_exec_error(package, output, "install", status)
 1: stop(error)
Execution halted

O comando docker images mostrou que nenhuma imagem dtamg/age7:latest havia sido criada.

gabriel.dornas@cge-pda:~/age7$ docker images
REPOSITORY                  TAG                    IMAGE ID       CREATED          SIZE
<none>                      <none>                 6ea75ad9f365   24 minutes ago   1.09GB
<none>                      <none>                 9bdb214c8a49   43 minutes ago   125MB
gabrielbdornas/dtamg-age7   latest                 17a67456a3c0   8 months ago     1.51GB
python                      3.9.12-slim-bullseye   29cc46b21611   9 months ago     125MB

Obs.: Deletei as imagens "criaada" erradamente para evitar lixo na máquina via:

docker rmi -f 6ea75
docker rmi -f 9bdb2
docker rmi -f 29cc4

Rodando processo no actions do repo docker-age7 vi que a versão do pacote dtamg instalada é a 0.2.6 e não a 0.2.5 que foi utilizada no meu processo. Conferindo o repositório dtamg-r constatei que, de fato, a versão mais recente do pacote é a 0.2.6, tendo sido esta correção registrada neste issue.

Acreditando que esta diferença se deu pelo fato do arquivo renv.lock existente na raiz do repo age7 estar desatualizado atualizei o arquivo para conter exatamente as mesmas informações do presente no repositório dtamg-r e nenhum outro problema foi encontrado para criação da imagem.

[gabrielbdornas]

Processo rodando (./docker.sh) após correções realizadas acima. Verificar se a nova estratégia para rodar a rotina irá funcionar:

https://github.com/transparencia-mg/age7/blob/914c0e12052f253a3d4966e53000afe7d741dfef/docker.sh#L3

Neste sentido, a criação de imagem deverá ocorrer somente se alguma modificação nos arquivo Dockerfile e renv.lock forem identificadas pelo Makefile:

https://github.com/transparencia-mg/age7/blob/914c0e12052f253a3d4966e53000afe7d741dfef/Makefile#L8-L10

Caso contrário processo ETL deverá ser acionado automaticamente:

https://github.com/transparencia-mg/age7/blob/914c0e12052f253a3d4966e53000afe7d741dfef/docker.sh#L3-L14

[gabrielbdornas]

Teste acima não funcionou. Retirei então a geração da imagem do arquivo ./docker.sh. Sempre que alguma modificação for realizada deverá ser rodado manualmente make image.

Importante também esta melhoria no dpckan para que tudo funcionasse.