Launching Keycloak 20.0.3 on REL 7.9 in a Docker container with compose never responds to HTTP requests - docker

I have an application that uses Keycloak 15.0.0 on REL 7.9 and other OSes (REL 8.7, Ubuntu 22.04, Oracle Linux 8.7). I am running this behind NGINX proxy and have it 100% working with Keycloak 15.0.0 and have for about a year 1/2 now. Now, we need to update to Keycloak 20.0 for OpenJDK issues and such. I updated my image in the docker compose YML configuration, my environment variables that all changed by this v20.0, and launched my application to have it update.
On 3 of the 4 OSes this worked 100% fine, came up great, came up quick, love the v20.0 UI changes in Keycloak. I tried this on FIPS enabled and FIPS disabled setups, and all worked 100%. It works as expected with my application, behind NGINX, and no issues at all whatsoever we have found in the last two weeks.
However, on Red Hat 7.9 for whatever reason I get no logs at all and nothing happens. I can do a docker exec -it xxxxxx /bin/sh type of command and get into it, but even a curl http://localhost:8080/auth/ turns up just a connection refused. It is almost like it is not running.
This happens whether I am updating a Keycloak 15.0.0 already setup, or if I remove that docker volume and start over from scratch. It just hangs there and does nothing.
And this only happens on REL 7.9. The other operating systems work great after a few minutes and respond correctly. I have even left it alone for up to 30 minutes to see if there was a process running, something hidden, a timeout, something else as a "ghost in the machine". But still nothing works.
I have searched for a while, read the readme files on updates, and started over fresh on other OSes and they all work. Just not this one. So looking for guidance here on what to change/try. Or I cannot use Keycloak 20.0 on REL 7.9. Until its EOL June 2024.
The keycloak configuration that works on the other 3 OSes, with the same docker versions installed and all the same permissions setup via our Ansible setup, is below. I cannot figure out why REL 7.9 is the one holdout on this.
Any help or tips or things to try is much appreciated. I am 8+ hours into this with nothing to show.
keycloak:
image: keycloak-mybuild:20.0.3
restart: on-failure:5
container_name: keycloak
command: start --optimized
ports:
- "8080"
environment:
- KC_DB=postgres
- KC_DB_URL=jdbc:postgresql://postgres:5432/xxxxxxxx
- KC_DB_USERNAME=xxxxxxxx
- KC_DB_PASSWORD=xxxxxxxx
- KEYCLOAK_ADMIN=admin
- KEYCLOAK_ADMIN_PASSWORD=xxxxxxxx
- KC_HOSTNAME_STRICT=false
- KC_HOSTNAME_STRICT_HTTPS=false
- PROXY_ADDRESS_FORWARDING=true
- KC_HTTP_RELATIVE_PATH=/auth
- KC_HTTP_ENABLED=true
- KC_HTTP_PORT=8080
depends_on:
- postgres
networks:
- namednetwork

Voila!!
That line that #jayc talked on - JAVA_OPTS_APPEND="-Dcom.redhat.fips=false" was the answer. Thank you so much! This worked on my REL 7.9 box with FIPS enabled 100% every time, with the Keycloak 20.0.3 container I built from the steps mentioned on containers https://www.keycloak.org/server/containers.
keycloak:
image: keycloak-mybuild:20.0.3
restart: on-failure:5
container_name: keycloak
command: start --optimized
ports:
- "8080"
environment:
- KC_DB=postgres
- KC_DB_URL=jdbc:postgresql://postgres:5432/xxxxxxxx
- KC_DB_USERNAME=xxxxxxxx
- KC_DB_PASSWORD=xxxxxxxx
- KEYCLOAK_ADMIN=admin
- KEYCLOAK_ADMIN_PASSWORD=xxxxxxxx
- KC_HOSTNAME_STRICT=false
- KC_HOSTNAME_STRICT_HTTPS=false
- PROXY_ADDRESS_FORWARDING=true
- KC_HTTP_RELATIVE_PATH=/auth
- KC_HTTP_ENABLED=true
- KC_HTTP_PORT=8080
- JAVA_OPTS_APPEND="-Dcom.redhat.fips=false"
depends_on:
- postgres
networks:
- namednetwork

Related

How to restore redis dump from version 3.2 (without docker) to 6.0 (running with bitnami docker image)

Initial goal
Currently we have an old version of redis running on a single physical server(redis v3.2.1). The goal is to have a redis/slave topology with sentinel for HA.
A way to accomplish this, is to create a slave of this single instance with version 6. Unfortunately, there is an icompatibility between version 3 and 6.
What I try to do
I tried to restore the dump to version 4.0.2-r0. It works fine.
Then I tried to restore to version 4.0.2-r1 and it failed and the
dump.rdb was totally replaced by an empty file automatically
How to reproduce
Install a single instance of redis with :
apt install -y redis-server redis-tools
Create a redis container with this docker-compose.yml file
version: '2'
services:
redis-master:
#image: 'bitnami/redis:6.0'
#image: 'bitnami/redis:4.0.2-r1'
image: 'bitnami/redis:4.0.2-r0'
container_name: redis-master
volumes:
- 'redis_data_master:/bitnami/redis/data'
ports:
- '6379:6379'
environment:
- REDIS_REPLICATION_MODE=master
- ALLOW_EMPTY_PASSWORD=yes
- REDIS_DISABLE_COMMANDS=FLUSHDB,FLUSHALL
volumes:
redis_data_master:
driver: local
docker-compose up -d
docker stop redis-master
# Replace test_redis_data_master by the right folder
sudo cp dump.rdb /var/lib/docker/volumes/test_redis_data_master/_data/dump.rdb
With this docker compose file, it work with v4.0.2-r0 but not with v4.0.2-r1.
cf logs here:
v4.0.2-r0
30:M 01 Dec 13:52:55.993 # Server initialized 30:M 01 Dec
13:52:58.049 * DB loaded from disk: 2.056 seconds 30:M 01 Dec
13:52:58.049 * Ready to accept connections
The database is loaded successfully
v4.0.2-r1
20:M 01 Dec 13:49:05.472 # Server initialized 20:M 01 Dec
13:49:05.472 * Ready to accept connections
The database is empty
Conclusion
Can you please help with this issue. Did someone faced the same issue or the same situation ?
Thanks in advance for your help :D
Have you tried to upgrade directly from 4.0 to 5.0?
I don't think upgrade revision by revision is a good idea since we release a new revision every day, and sometimes, they have bugs that are patched with another revision.
Apart from that, I recommend you to follow the official documentation to upgrade your databases. A major version usually means incompatible changes, so I am pretty sure you will find some issues in the way. It is highly probable that just changing the image tag will not work.

Confluence on Docker runs setup assistent on existing installation after update

A few days ago, my watchtower updated Confluence on Docker with the 6.15.1-alpine tag. It's hosted using Atlassians official image. Since those update, Confluence shows the setup screen. Haven't any chance to get inside the admin panel. When continue the wizard end entering server credentials of the existing installation, it gave an error that an installation already exists that would be overwritten if continued.
It was a re-push of the exact version tag 6.15.1 tag, not a regular version update. So there seems no possibility to use the old, working image. Also other versions seems re-pushed. Tried some older ones and also a new one, without success.
docker-compose.yml
version: "2"
volumes:
confluence-home:
services:
confluence:
container_name: confluence
image: atlassian/confluence-server:6.15.1-alpine
#restart: always
mem_limit: 6g
volumes:
- confluence-home:/var/atlassian/application-data/confluence
- ./confluence.cfg.xml:/var/atlassian/application-data/confluence/confluence.cfg.xml
- ./server.xml:/opt/atlassian/confluence/conf/server.xml
- ./mysql-connector-java-5.1.42-bin.jar:/opt/atlassian/confluence/lib/mysql-connector-java-5.1.42-bin.jar
networks:
- traefik
environment:
- "TZ=Europe/Berlin"
- JVM_MINIMUM_MEMORY=4096m
- JVM_MAXIMUM_MEMORY=4096m
labels:
- "traefik.port=8090"
- "traefik.backend=confluence"
- "traefik.frontend.rule=Host:confluence.my-domain.com"
networks:
traefik:
external: true
I found out that there were the following changes on the images:
Ownership
The logs throwed errors about not beinng able to write on log files because nearly the entire home directory was owned by an user called bin:
root#8ac38faa94f1:/var/atlassian/application-data/confluence# ls -l
total 108
drwx------ 2 bin bin 4096 Aug 19 00:03 analytics-logs
drwx------ 3 bin bin 4096 Jun 15 2017 attachments
drwx------ 2 bin bin 24576 Jan 12 2019 backups
[...]
This could be fixed by executing a chown:
docker exec -it confluence bash
chown confluence:confluence -R /var/atlassian/application-data/confluence
Moutings inside mount
My docker-compose.yml mounts a volume to /var/atlassian/application-data/confluence and inside those volume, the confluence.cfg.xml file was mounted from current directory. This approach is a bit older and should seperate the user data in the volume from configuration files like docker-compose.yml and also the application itself as confluence.cfg.xml.
Seems not properly working any more on using Docker 17.05 and Docker-Compose 1.8.0 (at least in combination with Confluence), so I simply removed that second mount and placed the configuration file inside the volume.
Atlassian creates config files now dynamically
It was noticeable that my mounted configuration files like confluence.cfg.xml and server.xml were overwritten by Atlassians container. Their source code shows that they now use Jina2, a common Python template engine used in e.g. Ansible. A python script parse those files on startup and create Confluences configuration files, without properly checking on all of those files if they already exists.
Mounting them as read only caused the app to crash because this is also not handled in their Python script. By analyzing their templates, I learned that they replaced nearly every config item by environment variables. Not a bad approach, so I specified my server.xml parameters by env variables instead of mouting the entire file.
In my case, Confluence is behind a Traefik reverse proxy and it's required to tell Confluence it's final application url for end users:
environment:
- ATL_proxyName=confluence.my-domain.com
- ATL_proxyPort=443
- ATL_tomcat_scheme=https
Final working docker-compose.yml
By applying all modifications above, accessing the existing installation works again using the following docker-compose.yml file:
version: "2"
volumes:
confluence-home:
services:
confluence:
container_name: confluence
image: atlassian/confluence-server:6.15.1
#restart: always
mem_limit: 6g
volumes:
- confluence-home:/var/atlassian/application-data/confluence
- ./mysql-connector-java-5.1.42-bin.jar:/opt/atlassian/confluence/lib/mysql-connector-java-5.1.42-bin.jar
networks:
- traefik
environment:
- "TZ=Europe/Berlin"
- JVM_MINIMUM_MEMORY=4096m
- JVM_MAXIMUM_MEMORY=4096m
- ATL_proxyName=confluence.my-domain.com
- ATL_proxyPort=443
- ATL_tomcat_scheme=https
labels:
- "traefik.port=8090"
- "traefik.backend=confluence"
- "traefik.frontend.rule=Host:confluence.my-domain.com"
networks:
traefik:
external: true

Spring Boot tries to connect to Mongo localhost

I have a Spring Boot 2.x project using Mongo. I am running this via Docker (using compose locally) and Kubernetes. I am trying to connect my service to a Mongo server. This is confusing to me, but for development I am using a local instance of Mongo, but deployed in GCP I have named mongo services.
here is my application.properties file:
#mongodb
spring.data.mongodb.uri= mongodb://mongo-serviceone:27017/serviceone
#logging
logging.level.org.springframework.data=trace
logging.level.=trace
And my Docker-compose:
version: '3'
# Define the services/containers to be run
services:
service: #name of your service
build: ./ # specify the directory of the Dockerfile
ports:
- "3009:3009" #specify ports forwarding
links:
- mongo-serviceone # link this service to the database service
volumes:
- .:/usr/src/app
depends_on:
- mongo-serviceone
mongo-serviceone: # name of the service
image: mongo
volumes:
- ./data:/data/db
ports:
- "27017:27017"
When I try docker-compose up . I get the following error:
mongo-serviceone_1 | 2018-08-22T13:50:33.454+0000 I NETWORK
[initandlisten] waiting for connections on port 27017 service_1
| 2018-08-22 13:50:33.526 INFO 1 --- [localhost:27017]
org.mongodb.driver.cluster : Exception in monitor thread
while connecting to server localhost:27017 service_1
| service_1 | com.mongodb.MongoSocketOpenException:
Exception opening socket service_1 | at
com.mongodb.connection.SocketStream.open(SocketStream.java:62)
~[mongodb-driver-core-3.6.3.jar!/:na]
running docker ps shows me:
692ebb72cf30 serviceone_service "java -Djava.securit…" About an hour ago Up 9 minutes 0.0.0.0:3009->3009/tcp, 8080/tcp serviceone_service_1
6cd55ae7bb77 mongo "docker-entrypoint.s…" About an hour ago Up 9 minutes 0.0.0.0:27017->27017/tcp serviceone_mongo-serviceone_1
While I am trying to connect to a local mongo, I thought that by using the name "mongo-serviceone"
Hard to tell what the exact issue is, but maybe this is just an issue because of the space " " after "spring.data.mongodb.uri=" and before "mongodb://mongo-serviceone:27017/serviceone"?
If not, maybe exec into the "service" container and try to ping the mongodb with: ping mongo-serviceone:27017
Let me know the output of this, so I can help you analyze and fix this issue.
Alternatively, you could switch from using docker compose to a Kubernetes native dev tool, as you are planning to run your application on Kubernetes anyways. Here is a list of possible tools:
Allow hot reloading:
DevSpace: https://github.com/covexo/devspace
ksync: https://github.com/vapor-ware/ksync
Pure CI/CD tools for dev:
Skaffold: https://github.com/GoogleContainerTools/skaffold
Draft: https://github.com/Azure/draft
For most of them, you will only need minikube or a dev namespace inside your existing cluster on GCP.
Looks like another application was running on port 27017 on your localhost Similar reported issue
quick way to check on linux/mac:
telnet 127.0.01 27017
check logs files:
docker logs serviceone_service

How can I make phpmyadmin last longer without timeout with Docker

I'm using Docker with phpMyAdmin and everything works fine except that it timeout way too quickly if I don't use it for a moment. How can I change the limit before having to reconnect ?
Is setting MAX_EXECUTION_TIME in your docker-compose (under 'environment') a possible solution?
After some research I have found an elegant solution. Refer to (https://hub.docker.com/r/phpmyadmin/phpmyadmin/) for information on config.user.inc.php.
The idea is you want to create a volume for this to store the following code.
config.user.inc.php
<?php
$cfg['LoginCookieValidity'] = (86400 * 30); //86400 is 24 hours in seconds. Therefore this is 30 days.
ini_set('session.gc_maxlifetime', (86400 * 30));
?>
You can just put whatever time you want in seconds here, by default it was 24 minutes.
My docker compose file then looked like this for phpmyadmin
phpmyadmin:
depends_on:
- db_live
- db_dev
container_name: phpmyadmin
image: phpmyadmin/phpmyadmin
volumes:
- ./phpmyadmin/config.user.inc.php:/etc/phpmyadmin/config.user.inc.php
hostname: localbeta.domain.com
environment:
PMA_ARBITRARY: 1
UPLOAD_LIMIT: 25000000
restart: always
ports:
- "8081:80"
The key here is the volumes command. It will create a local directory to change the config.user.inc.php to whatever you want now!
Another thing to note is that PhpMyAdmin will give you a hostname error if you run it and view the console output, to fix this just add the 'hostname' field to the docker compose. Then in your systems host file just add that to your list of hosts and point it to 127.0.0.1 for local testing and don't change anything for the actual beta and/or live servers (if you are using this for that)
You know you will do it right if you go to the settings and see the following for login cookie validity:

Not seeing certificate attributes when not running locally

The Problem
When I deploy a 4 peer nodes with PBFT or NOOPS in the cloud, any user certificate attributes are not seen. The values are blank.
Observations
Everything works locally. This suggests that I am calling the API correctly, and the chaincode is accessing attributes correctly.
When I attach to the membership container, I see the correct membersrvc.yaml with aca.enabled set to true. This is the same yaml that works locally. For good measure, I'm also passing the ENV variable MEMBERSRVC_CA_ACA_ENABLED=true.
I can see the attributes for the users in the membership service's ACA database. (suggesting that the users were created with attributes)
When I look at the actual certificate from the log (Bytes to Hex then Base64 decode) I see the attributes. (Appending certificate [30 82 02 dd 30 8....)
All attributes are blank when deployed. No errors.
Membership Service Logs
I enabled debug logging, and see that Membership services thinks it's enabled ACA:
19:57:46.421 [server] main -> DEBU 049 ACA was enabled [aca.enabled == true]
19:57:46.421 [aca] Start -> INFO 04a Staring ACA services...
19:57:46.421 [aca] startACAP -> INFO 04b ACA PUBLIC gRPC API server started
19:57:46.421 [aca] Start -> INFO 04c ACA services started
This looks good. What am I missing?
Guess
Could it be that the underlying docker container the chaincode deploys into doesn't have security enabled? Does it use the ENV passed to the parent peer? One difference is that locally I'm using "dev mode" without the base-image shenanigans.
Membership Service
membersrvc:
container_name: membersrvc
image: hyperledger/fabric-membersrvc
volumes:
- /home/ec2-user/membership:/user/membership
- /var/hyperledger:/var/hyperledger
command: sh -c "cp /user/membership/membersrvc.yaml /opt/gopath/src/github.com/hyperledger/fabric/membersrvc && membersrvc"
restart: unless-stopped
environment:
- MEMBERSRVC_CA_ACA_ENABLED=true
ports:
- 7054:7054
Root Peer Service
rootpeer:
container_name: root-peer
image: hyperledger/fabric-peer
restart: unless-stopped
environment:
- CORE_VM_ENDPOINT=unix:///var/run/docker.sock
- CORE_LOGGING_LEVEL=DEBUG
- CORE_PEER_ID=vp1
- CORE_SECURITY_ENROLLID=vp1
- CORE_SECURITY_ENROLLSECRET=xxxxxxxx
- CORE_SECURITY_ENABLED=true
- CORE_SECURITY_ATTRIBUTES_ENABLED=true
- CORE_PEER_PKI_ECA_PADDR=members.x.net:7054
- CORE_PEER_PKI_TCA_PADDR=members.x.net:7054
- CORE_PEER_PKI_TLSCA_PADDR=members.x.net:7054
- CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=NOOPS
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /var/hyperledger:/var/hyperledger
command: sh -c "peer node start"
ports:
- 7051:7051
- 7050:7050
Here's the request:
{
"jsonrpc": "2.0",
"method":"query",
"params": {
"chaincodeID": {
"name" :"659cb5dcc3063054e4c90908050eebf68eb2bd193cc1520f1f2d198f0ff42268"
},
"ctorMsg": {
"args":["get_results", "{\"Id\":\"abc123\"}"]
},
"secureContext": "user123",
"attributes":["account_id","role"]
},
"id": 2
}
Edited*: I previously thought this was just PBFT...but it's also happening on NOOPS on the cloud. I reduced the example to NOOPS.
My problem is that the fabric version inside the fabric-baseimage docker container is a good bit newer. This is my fault - because I populated that image with the fabric version manually.
Background
If one is using non-vagrant with 0.6 and not in DEV mode, deploying chaincode will have a "cannot find :latest tag" error. To solve this, I pulled a fabric-baseimage version, and populated it with what I needed, including a git-clone of fabric. I should have pulled the 0.6 branch, but instead it was pulling master.
So essentially, my fabric-peer, node-sdk deployer, and baseimage were using slightly different hyperledger versions.
After about 48 hours of configuration hell, I think I have it straightened out by sending everything back to 0.6. I have terraform spinning everything up successfully now.
I do wish the documentation included something about deploying in a non-dev multi-node environment.

Resources