Tarefas de inicialização
There are often initialization tasks performed by Quarkus extensions that are meant to be run once. For example, Flyway or Liquibase initialization falls into that category. But what happens when the scaling needs of an application requires more instances of the application to run? Or what happens when the application restarts?
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
The feature can be explicitly disabled per task (enabled by default).
The default behavior can change by setting the following property to 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
The name of the generated init container is wait-for-${task name} by default.
Given that the init container is part of the same pod as the actual application, it will get the same service account (and therefore permissions) and volumes as the application.
Further customization to the container can be done using the configuration options for init containers (see quarkus.kubernetes.init-containers or quarkus.openshift.init-containers).
Exemplos:
To set the imagePullPolicy to IfNotPresent on the init container that waits for the flyway job:
quarkus.kubernetes.init-containers.flyway.image-pull-policy=if-not-presentPara definir um comando personalizado (como custom-wait-for ) no contêiner de inicialização que aguarda o trabalho flyway :
quarkus.kubernetes.init-containers.flyway.command=custom-wait-forOrquestração das tarefas de inicialização
The deployment resource should not start until the job has been completed. The typical pattern that is used among Kubernetes users is the
use of init containers to achieve this. An init container that waits for the job to complete is enough to enforce that requirement.
Usando uma imagem de contêiner wait-for personalizada
By default, the wait-for image is groundnuty/k8s-wait-for:no-root-v1.7.
You can define another image:
quarkus.kubernetes.init-task-defaults.wait-for-container.image=my/wait-for-image:1.0The imagePullPolicy can also be configured:
quarkus.kubernetes.init-task-defaults.wait-for-container.image-pull-policy=if-not-presentTo change the wait-for image for a particular init container (e.g. one that waits for the flyway job), you can use:
quarkus.kubernetes.init-tasks.flyway.wait-for-container.image=my/wait-for-image:1.0You can define the imagePullPolicy for this particular init container with:
quarkus.kubernetes.init-tasks.flyway.wait-for-container.image-pull-policy=if-not-presentConfiguração de permissões
For an init container to be able to perform the wait for job, it needs to be able to perform get operations on the job resource.
This is done automatically and the generated manifests include the required Role and RoleBinding resources.
If, for any reason, additional permissions are required either by the init container or the job, they can be configured with the Kubernetes RBAC configuration.
|
The application, the init container and the job use the same |
