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)
Conclusão
Esse foi a solução que encontrei usando essa referência.
No meu caso estava usando o SQL Server e usei o docker-compose também.
Espero que isso possa ajudá-lo, caso venha a ter o mesmo problema.
Críticas, dúvidas ou sugestões entre em contato e vamos conversar.
Muito obrigado
Top comments (0)