Problema:
Ao subir o aplicativo para produção, a API conta com um ReplicaSet de 3 instâncias, para uma maior disponibilidade e resiliência no acesso. Com a adição do preditor, controlado pelo DjangoQ, todas as 3 instâncias ficam gerando cronjobs para atualizar a predição, o que tem aumentado o tempo para que cada atualização termine ( ~ 80s) e mantendo o tempo entre atualizações inconsistente. Esse PR visa resolver essa questão.
Solução:
Refatoramos os deploys (cd_dev.yml, cd_stag.yml e main.yml) para que, em cada ambiente, sejam subidas duas imagens diferentes: mobilidade-rio-api, uma instância normal, como já era antes do preditor e mobilidade-rio-api-django-q, que tem o daemon do DjangoQ ativado e realiza as tarefas de atualização do preditor. Para isso, adicionamos um dockerfile novo (mobilidade-rio/Dockerfile-django-q) e buildamos as duas imagens a partir de seus respectivos dockerfiles. A diferença principal entre as duas está no shellscript que cada uma usa para iniciar o servidor Django (start-server-sh, start-server-django-q-sh).
Essa nova imagem adicionada mora no mesmo namespace de cada ambiente, porém não é acessada via Ingress, as únicas API's expostas, são as instâncias "normais"
Para os ambientes de dev e staging a api agora terá sempre duas instâncias (uma padrão e uma para atualização) e no ambiente de produção, teremos as 3 instâncias padrão para acesso + 1 instância para atualização.
Problema: Ao subir o aplicativo para produção, a API conta com um ReplicaSet de 3 instâncias, para uma maior disponibilidade e resiliência no acesso. Com a adição do preditor, controlado pelo DjangoQ, todas as 3 instâncias ficam gerando cronjobs para atualizar a predição, o que tem aumentado o tempo para que cada atualização termine ( ~ 80s) e mantendo o tempo entre atualizações inconsistente. Esse PR visa resolver essa questão.
Solução: Refatoramos os deploys (
cd_dev.yml,cd_stag.ymlemain.yml) para que, em cada ambiente, sejam subidas duas imagens diferentes:mobilidade-rio-api, uma instância normal, como já era antes do preditor emobilidade-rio-api-django-q, que tem o daemon do DjangoQ ativado e realiza as tarefas de atualização do preditor. Para isso, adicionamos um dockerfile novo (mobilidade-rio/Dockerfile-django-q) e buildamos as duas imagens a partir de seus respectivos dockerfiles. A diferença principal entre as duas está no shellscript que cada uma usa para iniciar o servidor Django (start-server-sh,start-server-django-q-sh). Essa nova imagem adicionada mora no mesmo namespace de cada ambiente, porém não é acessada via Ingress, as únicas API's expostas, são as instâncias "normais" Para os ambientes dedevestaginga api agora terá sempre duas instâncias (uma padrão e uma para atualização) e no ambiente de produção, teremos as 3 instâncias padrão para acesso + 1 instância para atualização.