Tarefas de inicialização
Muitas vezes, há tarefas de inicialização executadas pelas extensões do Quarkus que devem ser executadas uma única vez. Por exemplo, a inicialização do Flyway ou do Liquibase se enquadra nessa categoria. Mas o que acontece quando as necessidades de dimensionamento de um aplicativo exigem a execução de mais instâncias do aplicativo? Ou o que acontece quando o aplicativo é reiniciado?
Um ambiente comum em que ambos os casos são bastante comuns é o Kubernetes. Para enfrentar esses desafios, o Quarkus permite a externalização de tais tarefas como trabalhos no Kubernetes e utiliza contêineres de inicialização para garantir que uma instância de aplicativo seja iniciada apenas quando os trabalhos de inicialização forem concluídos. Com essa abordagem, mesmo que um aplicativo tenha várias réplicas, a lógica de inicialização só será executada uma vez.
Essa abordagem é refletida nos manifestos gerados pela extensão do Kubernetes .
Desabilitando a funcionalidade
O recurso pode ser explicitamente desativado por tarefa (ativado por padrão). O comportamento padrão pode ser alterado definindo-se a seguinte propriedade como false :
quarkus.kubernetes.init-task-defaults.enabled=falseou no OpenShift:
quarkus.openshift.init-task-defaults.enabled=falseNota : todas as opções de configuração neste guia estão disponíveis tanto no OpenShift quanto no Kubernetes. O restante do guia usará o prefixo de configuração do Kubernetes (prefixo quarkus.kubernetes ), mas todas as opções de configuração também estão disponíveis para o OpenShift (prefixo quarkus.openshift ).
No caso de precisarmos desativar uma tarefa específica, podemos usar a seguinte propriedade:
quarkus.kubernetes.init-tasks."<task name>".enabled=falseO nome da tarefa é o nome da extensão que executa a inicialização. Exemplos:
Para a Flyway:
quarkus.kubernetes.init-tasks.flyway.enabled=falsePara a Liquibase:
quarkus.kubernetes.init-tasks.liquibase.enabled=falsePara o Liquibase Mongodb:
quarkus.kubernetes.init-tasks.liquibase-mongodb.enabled=falseControle do trabalho gerado
O contêiner do trabalho é bastante semelhante ao contêiner do aplicativo, e a única coisa que muda são as variáveis de ambiente configuradas. Mais especificamente, a seguinte variável de ambiente é adicionada para dizer ao trabalho para sair logo após a inicialização.
QUARKUS_INIT_AND_EXIT=trueA imagem, a política de pull de imagem, a conta de serviço, os volumes, as montagens e as variáveis de ambiente adicionais são herdadas/copiadas do recurso de implementação. Qualquer personalização do recurso de implementação original (por meio de configuração ou extensão) também será refletida no trabalho.
Controle do contêiner de inicialização gerado
O nome do contêiner de inicialização gerado é wait-for-${task name} por padrão. Como o contêiner de inicialização faz parte do mesmo pod que o aplicativo real, ele obterá a mesma conta de serviço (e, portanto, as mesmas permissões) e os mesmos volumes que o aplicativo. É possível personalizar ainda mais o contêiner usando as opções de configuração dos contêineres de inicialização (consulte quarkus.kubernetes.init-containers ou quarkus.openshift.init-containers ).
Exemplos:
Para definir a imagePullPolicy como IfNotPresent no contêiner de inicialização que aguarda o trabalho flyway :
quarkus.kubernetes.init-containers.wait-for-flyway.image-pull-policy=IfNotPresentPara definir um comando personalizado (como custom-wait-for ) no contêiner de inicialização que aguarda o trabalho flyway :
quarkus.kubernetes.init-containers.wait-for-flyway.command=custom-wait-forOrquestração das tarefas de inicialização
O recurso de implantação não deve ser iniciado até que o trabalho tenha sido concluído. O padrão típico usado entre os usuários do Kubernetes é o uso de contêineres de inicialização para conseguir isso. Um contêiner de inicialização que wait for o trabalho a ser concluído é suficiente para atender esse requisito.
Usando uma imagem de contêiner wait-for personalizada
Para alterar a imagem wait-for que, por padrão, é groundnuty/k8s-wait-for:no-root-v1.7 , você pode usar:
quarkus.kubernetes.init-task-defaults.wait-for-container.image=my/wait-for-image:1.0Para alterar a imagem wait-for de um determinado contêiner de inicialização (por exemplo, wait-for-flway ), você pode usar:
quarkus.kubernetes.init-containers.wait-for-flyway=my/wait-for-image:1.0Configuração de permissões
Para que um contêiner de inicialização possa executar o wait for job , ele precisa ser capaz de realizar operações get no recurso de trabalho. Isso é feito automaticamente e os manifestos gerados incluem os recursos Role e RoleBinding necessários.
Se, por algum motivo, forem necessárias permissões adicionais para o contêiner de inicialização ou para o trabalho, elas poderão ser configuradas por meio da configuração RBAC do Kubernetes .
Nota : O aplicativo, o contêiner de inicialização e o trabalho usam o mesmo ServiceAccount e, portanto, compartilham as mesmas permissões.
Extensão que fornece tarefas de inicialização
Atualmente, esse recurso é usado pelas seguintes extensões: - Flyway - Liquibase - Liquibase MongoDB
