[pt-br] keycloak: Resolvendo problema de 'WFLYCTL0348: Timeout after [300] seconds waiting for service container stability.'

#keycloak #docker #wflyctl0348 #timeout

Introdução

Olá pessoal!

Hoje meu post será sobre um problema que passei, no meu trabalho, subindo um container do keycloak e se conectando a base de dados do SQL Server na GCP Cloud SQL.

Abaixo irei apresentar a solução que encontrei para o erro:

WFLYCTL0348: Timeout after [300] seconds waiting for service container stability.

O aconteceu?

No trabalho estava testando o keycloak com o MS SQL Server.

Rodando os containers localmente, do keycloak e do banco foi tudo tranquilo.

Porém ao fazer o teste apontando o keycloak para o banco na GCP Cloud SQL, me deparei com o erro e o container parou de funcionar.

Olhando para a base de dados, algumas tabelas foram criadas mas não todas.

Mas por que disso?

Isso acontece pois o keycloak, por padrão, vem configurado um timeout de 300 segundos e o liquibase nesse tempo não terminou ainda a migração.

Para essa configuração há 3 variáveis na jogada:

jboss.as.management.blocking.timeout
deployment-timeout
default-timeout

O que foi feito?

Para resolver o problema foi necessário criar um arquivo para alterar esses timeout's, um Dockerfile para criar uma imagem customizada e o docker-compose para criar o container

Arquivo para alterar os timeout's

O nome do meu arquivo foi changeTimeout.batch, mas você pode escolher um nome melhor (rsrs).

O conteúdo do arquivo ficou parecido com isso:

embed-server --std-out=echo --server-config=standalone-ha.xml
batch
/system-property=jboss.as.management.blocking.timeout:add(value=900)
/subsystem=deployment-scanner/scanner=default:write-attribute(name=deployment-timeout,value=900)
/subsystem=transactions:write-attribute(name=default-timeout,value=900)
run-batch
stop-embedded-server

Esse arquivo faz com que as 3 variáveis citados acima, seja alteradas para 900 segundos ou 15 minutos, mas você pode colocar o tempo que quiser, desde que seja em segundos.

Dockerfile

O Dockerfile ficou assim:

FROM quay.io/keycloak/keycloak:10.0.2

COPY --chown=jboss ./changeTimeout.batch /tmp/changeTimeout.batch

RUN cd $JBOSS_HOME \
  && ./bin/jboss-cli.sh --file=/tmp/changeTimeout.batch \
  && rm -rf $JBOSS_HOME/standalone/configuration/standalone_xml_history \
  && rm -rf $JBOSS_HOME/standalone/data \
  && rm -rf $JBOSS_HOME/standalone/tmp \
  && rm -rf /tmp/changeTimeout.batch

# Optional parameters

ENV KEYCLOAK_USER admin
ENV KEYCLOAK_PASSWORD admin123

Criado o seu Dockerfile execute o comando para criar a imagem

docker build -t keycloak . # O nome 'keycloak' será usado depois no docker-compose no parâmetro 'image'

docker-compose.yml

E o meu docker-compose ficou dessa forma:

version: "3.8"

services:
  keycloak-sqlserver:
    container_name: keycloak-sqlserver
    image: keycloak # Lembra o comentário acima, sobre o nome?
    environment:
      PROXY_ADDRESS_FORWARDING: "true"
      DB_VENDOR: mssql
      DB_ADDR: [IP]
      DB_DATABASE: [NOME_DB]
      DB_SCHEMA: dbo
      DB_USER: [USUARIO]
      DB_PASSWORD: [SENHA]
    ports:
      - 6090:8080
      - 6091:9990

Após feita essas configurações, execute o comando para testar:

docker-compose up -d

Se tudo ocorrer bem (rsrsrs), após o liquibase finalizar a migração, o keycloak continuará com o processo de inicialização e você verá a seguinda saída nos logs:

01:33:57,370 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
01:33:57,375 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
01:33:57,376 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990
01:33:57,376 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 10.0.2 (WildFly Core 11.1.1.Final) started in 54943ms - Started 690 of 995 services (708 services are lazy, passive or on-demand)