transparencia-brasil / achados-e-pedidos-importador Goto Github PK

Ao entrar no endereço https://transparencia-achados-importador.azurewebsites.net/ e tentar se logar, da erro:

<h1 style="padding: 0px; margin: 0px; font-weight: normal; color: rgb(0, 0, 0); font-family: sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">OperationalError at /importer/login/</h1><pre class="exception_value" style="padding: 0px; margin: 10px 0px; font-size: 1.5em; white-space: pre-wrap; font-family: sans-serif; color: rgb(102, 102, 102); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">database is locked</pre>

Request Method: | POST
-- | --
http://transparencia-achados-importador.azurewebsites.net/importer/login/
2.0.1
OperationalError
database is locked
/tmp/8d96d8393c234d3/antenv3.6/lib/python3.6/site-packages/django/db/backends/base/base.py in _commit, line 239
/opt/python/3.6.12/bin/python3.6
3.6.12
['/opt/python/3.6.12/bin',  '/home/site/wwwroot',  '/tmp/8d96d8393c234d3/antenv3.6/lib/python3.6/site-packages',  '/opt/python/3.6.12/lib/python36.zip',  '/opt/python/3.6.12/lib/python3.6',  '/opt/python/3.6.12/lib/python3.6/lib-dynload',  '/opt/python/3.6.12/lib/python3.6/site-packages',  '/home/site/wwwroot',  '/var/www/importador.achadosepedidos.org.br/achadosepedidos.org.br-importador',  '/var/www/importador.achadosepedidos.org.br/achadosepedidos.org.br-importador/achadosepedidos']
Qua, 1 Set 2021 19:11:11 -0300

A base de dados que armazena o login é um sqlite...

Além disso, o log completo expõe a senha. Lembrar de desligar o debug em produção. Por isso estou colocando só a parte principal.

Para migrar o importador para o Azure, é necessário tirar as variáveis de ambiente que estão hardcoded e coloca-las dentro de um arquivo .env, já que na Azure as variáveis são injetadas através do painel de controle deles... Logo, o sistema precisa estar preparado para receber env vars.

Dois lugares que precisam configurar as env vars:

achadosepedidos/settings.py
importer/tasks.py

É necessário pegar os arquivos que estão no servidor, já que eles possuem novos parâmetros, como o certificado para a conexão com o mysql.

O Will migrou o importador do Google Cloud para a Azure e forneceu essa URL de teste:
https://transparencia-achados-importador.azurewebsites.net

Ao acessar essa URL constatamos que alguns assets servidos pela pasta static (ex: https://transparencia-achados-importador.azurewebsites.net/static/importer/login.css) não estão sendo encontrados (erro 404)

esse problema acontece porque essa pasta está fora do root da aplicação e configurada pelo Apache através de um redirecionamento. Quando a URL possuir /static os arquivos estão em static/ e ao acessar a aplicação os arquivos estão em achadosepedidos/ conforme essa estrutura
./
static/
achadosepedidos/

Precisamos colocar o static dentro da pasta achadosepedidos/ para essa pasta conseguir ser encontrada pela URL e servir os estilos do site corretamente

@fiz o deploy do importador aqui pelo meu local.

git push azure master

Os arquivos do importador não estão sendo atualizados.
Entrando dentro do SSH da máquina eu observo que o sistema gera um arquivo output.tar.gz e copia para o wwwroot sem atualizar a pasta. Dessa forma o init.sh que colocamos no github não está sendo copiado para dentro do /home/site/wwwroot

analisando os logs

percebi esse comando aqui executado logo no começo:

oryx build /home/site/repository -o /home/site/wwwroot --platform python --platform-version 3.6 -i /tmp/8d9b9a6bbb415da --compress-destination-dir -p virtualenv_name=antenv3.6 --log-file /tmp/build-debug.log 

repare na opção:
--compress-destination-dir

Pesquisando na internet encontrei esse link
https://docs.microsoft.com/en-us/answers/questions/377433/don39t-compress-flask-web-app.html

Forcei esse parâmetro (lista de parâmetros) para ser false e agora ele supostamente não zipa mais o arquivo no Azure / Application settings

rodei o comando para zerar o repo

cd /home/site

mv repository repository.old

e no meu local:

git push azure master

O deploy foi feito e os arquivos como init.sh apareceram na pasta /home/site/wwwroot.

O problema é que eu atualizei o comentário no init.sh local, rodei um commit e git push azure master novamente, mas o init.sh dentro do APP /home/site/wwwroot não foi atualizado com o novo comentário.

e conforme o link https://docs.microsoft.com/en-us/answers/questions/377433/don39t-compress-flask-web-app.html

aparentemente esse procedimento "Also, I can't set CompressDestinationDir="false" in my oryx-manifest because it keep reverting back everytime I deploy."

hoje precisa:

1. criar o environment com o virtualenv
2. entrar no environment e rodar pip install -r requirements.txt
3. configurar o WSGI para olhar para o environment criado. ex:
   WSGIDaemonProcess importador python-path=/var/www/importador.achadosepedidos.org.br/achadosepedidos.org.br-importador:/var/www/importador.achadosepedidos.org.br/achadosepedidos.org.br-importador/env/lib/python3.7/site-packages
4. instalar o celery FORA do environment com as mesmas dependências do projeto

Na realidade isso tem a ver com o issue #31 do achados-e-pedidos-site. Teoricamente deve ter um workaround, mas precisa ver como fazer isso no rabbitmq. Se bem que, como se trata de uma instância efêmera, o log sequer deveria existir num disco subordinado ao /. Ou ele vai para um lugar que faz sentido, tipo um logstash da vida, ou ele deveria ir para o /dev/null.

1. não tem mysqlclient
2. a versão do Django deveria ser 2.0.2 em vez de 1.x
3. celery deveria ser 4.4.2

No arquivo:
importer/tasks.py

Existe esse caminho hardcoded
/var/www/stage.achadosepedidos.org.br/webroot/uploads/pedidos/

Ele é utilizado para verificar se a pasta do arquivo dentro do excel que será importado existe neste caminho.

Precisa passar para env e montar essa pasta quando migrar para o azure

o dotenv não pega variáveis de ambiente. ele as obtém a partir de um arquivo .env, que está fora do deploy.

talvez compense usar os.environ.get() em vez de dotenv.get_key()

Necessário testar a aplicação nessa url do Azure:
https://transparencia-achados-importador.azurewebsites.net/

para resolvermos os eventuais problemas e finalizar a migração do importador.

Dessa forma no Google Cloud ficará apenas o site stage, node.js, ocr e elasticsearch

Na hora de fazer deploy não funciona.
remote: celery 4.4.7 has requirement vine==1.3.0, but you'll have vine 5.0.0 which is incompatible.

Depois disso:
remote: ModuleNotFoundError: No module named 'vine.five'

Consegui conectar o sistema do importador em python no Google Cloud com a base de dados Mysql do Achados e Pedidos na Azure configurando o certificado CA

Para isso configurei a conexão utilizada para a opção STAGE do importador

Fiz o teste via terminal / phyton shell com o seguinte procedimento

Acessar a pasta root do importador

cd /var/www/importador.achadosepedidos.org.br/achadosepedidos.org.br-importador

Entrar no shell do python

python3 manage.py shell

Rodar uma rotina simples de conexão ao banco e query utilizando os acessos configurados para Stage

from django.db import connections
with connections['stage'].cursor() as cursor:
    cursor.execute("SELECT * FROM tipo_objeto")
    row = cursor.fetchone()

O retorno do row foi:

(1, 'Pedidos', 1, datetime.datetime(2016, 12, 20, 5, 11, 9))

Conforme imagem:

Ao tentar testar um upload de planilha pelo sistema do importador via web utilizando a opção stage e essa planilha fornecida pelo Raul transparenciabr.csv o sistema retorna a mensagem "Erro na leitura do resultado, por favor tente novamente.". Conforme essa imagem:

Tentei mudar a conexão do azure para produção e o resultado foi o mesmo...

Eu e o Raul realizamos alguns testes conforme descrito neste issue:
#7

As vezes funciona e as vezes trava e é necessário restartar a aplicação.
Travar significa o seguinte procedimento:

1. Entrar na ferramenta e se logar https://transparencia-achados-importador.azurewebsites.net/

2. Usar a planilha em anexo (selecionar Stage, clicar no botão "Choose File" e após escolher a planilha, clicar no botão Upload.
   Transparencia Brasil.csv

2.1. A primeira vez que você aperta o botão Upload após um restart (stop e start) no servidor os registros são gravados com sucesso na base.

Ex: https://www.achadosepedidos.org.br/pedidos/controladoria-geral-da-uniao---cgu-204967

Os registros salvaram no banco durante um teste realizado por mim hoje 17/09

2.2. Após a primeira carga, selecionei o mesmo arquivo e repeti o procedimento. Dessa vez o site tenta recarregar a página e fica em um loading infinito até dar timeout. Se você entrar novamente na URL https://transparencia-achados-importador.azurewebsites.net/ vai acontecer a mesma coisa, parece que o web service cai e o container fica inacessível, embora a conexão via SSH continua ativa.

Esse mesmo problema foi descrito pelo Raul nesse issue de teste:
#7

Não necessariamente após a primeira carga, existiram testes que eu consegui fazer mais de uma carga com o mesmo arquivo...

Como conseguimos monitorar isso e chegar na raiz do problema?

@wgnann (cc: @marcelo-jrkiko e @maiatoji)

Ao tentar fazer um commit dentro do container do importador na Azure acontece o seguinte erro:

tar: ./bin: Cannot mkdir: No space left on device

Log completo

/home/LogFiles/kudu/trace/1f01e8a2fbcf-c3f30971-93cc-4a39-8f3c-6e81a00abe3d.txt  (https://transparencia-achados-importador.scm.azurewebsites.net/api/vfs/LogFiles/kudu/trace/1f01e8a2fbcf-c3f30971-93cc-4a39-8f3c-6e81a00abe3d.txt)
tar: ./bin: Cannot mkdir: No space left on device
tar: ./bin/pydoc3: Cannot create symlink to ???pydoc3.6???: No such file or directory
tar: ./bin: Cannot mkdir: No space left on device
tar: ./bin/pyvenv-3.6: Cannot open: No such file or directory
tar: Exiting with failure status due to previous errors
/opt/Kudu/KuduConsole/Scripts/starter.sh oryx build /home/site/repository -o /home/site/wwwroot --platform python --platform-version 3.6 -i /tmp/8d99a459c278cc2 --compress-destination-dir -p virtualenv_name=antenv3.6 --log-file /tmp/build-debug.log , stackTrace:    at Kudu.Core.Infrastructure.Executable.ExecuteInternal(ITracer tracer, Func`2 onWriteOutput, Func`2 onWriteError, Encoding encoding, String arguments, Object[] args)
   at Kudu.Core.Infrastructure.Executable.ExecuteWithProgressWriter(ILogger logger, ITracer tracer, String arguments, Object[] args)
   at Kudu.Core.Deployment.Generator.ExternalCommandBuilder.RunCommand(DeploymentContext context, String command, Boolean ignoreManifest, String messagea
   at Kudu.Core.Deployment.Generator.OryxBuilder.Build(DeploymentContext context)
   at Kudu.Core.Deployment.DeploymentManager.Build(ChangeSet changeSet, ITracer tracer, IDisposable deployStep, IRepository repository, DeploymentInfoBase deploymentInfo, DeploymentAnalytics deploymentAnalytics, Boolean fullBuildByDefault)

Imagem do consumo dos discos

Imagem do consumo da pasta du -sh /home/*

Nós já demos uma olhada nos logs em /var/logs e aparentemente lá não é o gargalo:

Como você falou que o disco é compartilhado, tentamos investigar dentro dos containers do site da transparencia e achados e pedidos. Não conseguimos encontrar onde está lotando.

Consegue nos ajudar?