-
Notifications
You must be signed in to change notification settings - Fork 16.7k
[stable/keycloak] Update to 4.5.0.Final #8192
Conversation
@edclement @axdotl @stormmore @monotek Please review and test. |
Unfortunately 4.5.0 doesn't work for me with MySQL. Seems to be an issue with the Liquibase migration. |
/hold |
@Axotl Have you tried a fresh installation? Anyways, if this is bug in Keycloak itself, I don't think this should block the chart upgrade. I don't see what we should do about this. I'll try and do some more tests with Postgres. |
Yes, did a fresh install. However, after a couple of failed restarts, a Not sure whether this should block the chart upgrade, but as it seems not usable for all cases I've some doubts. |
I just got 4.5 working with the 3.4 chart and I sent my values to a thread on keycloak-users. I did have to modify them quite a bit and got KUBE_PING working |
It is worth noting that I had to give the default namespace serviceaccount |
@stormmore Any reason why you want to use KUBE_PING over DNS_PING? Support for DNS_PING was added in 4.5.0.Final, the PR for KUBE_PING was closed. keycloak/keycloak-containers#151 Can you share a link to your KUBE_PING setup? |
I tested again with Postgres. An update from 4.2.1 to 4.5.0 worked without any issues. |
@unguiculus I had the choice since it wasn't "supported" by the 3.4 OOTB. I fully intended to compare KUBE_PING to DNS_PING Here is my values file:
Here is my RBAC config:
In reality, I will probably move to DNS_PING as I was having problems trying to ENV to configure KUBE_PING, but it would probably be good if the chart could support either even if upstream choice to default to DNS_PING |
In order to use KUBE_PING you need to install |
436bc44
to
d2eaa3e
Compare
* The Docker image has added support for DNS_PING which is now used instead of JDBC_PING * The StatefulSet is updated to `apps/v1` Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>
d2eaa3e
to
b2cc3d3
Compare
It is definitely in the image, I am getting a couple of Deprecated warnings and without the RBAC config, Keycloak complains about being unable to get pods. So I can only assume the module is there, cause it starts up and finds it's members. (Edit: just for clarity, the deprecated warnings are around using KUBERNETES_ instead of OPENSHIFT_ vars) |
I tested with MariaDB, a fresh installation and an upgrade from 4.2.1. Both worked without any problems. |
I've tried it again, but the issue occurs every time. |
I did some further testing. It seems not to be a bug in Keycloak itself. When deploying keycloak as a I ran a Could this have something to do with the changed StatfulSet deployment.yaml apiVersion: apps/v1
kind: Deployment
metadata:
name: keycloak
spec:
replicas: 1
selector:
matchLabels:
app: keycloak
template:
metadata:
labels:
app: keycloak
spec:
containers:
- name: keycloak
image: jboss/keycloak:4.5.0.Final
env:
- name: KEYCLOAK_USER
value: "admin"
- name: KEYCLOAK_PASSWORD
value: "admin"
- name: PROXY_ADDRESS_FORWARDING
value: "true"
- name: DB_ADDR
value: "mysqlproxy.infra"
- name: DB_PORT
value: "3306"
- name: DB_DATABASE
value: "kc_test_db"
- name: DB_USER
value: "kc-test"
- name: DB_PASSWORD
value: "somePwd"
- name: DB_VENDOR
value: "mysql"
ports:
- name: http
containerPort: 8080
- name: https
containerPort: 8443
readinessProbe:
httpGet:
path: /auth/realms/master
port: 8080 statefulSet.yaml apiVersion: apps/v1
kind: StatefulSet
metadata:
name: kc-test-keycloak
labels:
app: keycloak
chart: keycloak-4.0.0
release: "kc-test"
heritage: "Tiller"
spec:
selector:
matchLabels:
app: keycloak
release: "kc-test"
replicas: 1
serviceName: kc-test-keycloak-headless
podManagementPolicy: Parallel
updateStrategy:
type: RollingUpdate
template:
metadata:
labels:
app: keycloak
release: "kc-test"
spec:
securityContext:
fsGroup: 1000
runAsNonRoot: true
runAsUser: 1000
containers:
- name: keycloak
image: "jboss/keycloak:4.5.0.Final"
imagePullPolicy: IfNotPresent
env:
- name: KEYCLOAK_USER
value: admin
- name: KEYCLOAK_PASSWORD
value: "admin"
- name: DB_VENDOR
value: "mysql"
- name: DB_ADDR
value: "mysqlproxy.infra"
- name: DB_PORT
value: "3306"
- name: DB_DATABASE
value: "kc_test_db"
- name: DB_USER
value: "kc-test"
- name: DB_PASSWORD
value: "somePwd"
ports:
- name: http
containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /auth/
port: http
initialDelaySeconds: 120
timeoutSeconds: 5
readinessProbe:
httpGet:
path: /auth/
port: http
initialDelaySeconds: 30
timeoutSeconds: 1
resources:
limits:
cpu: 500m
memory: 1024Mi
requests:
cpu: 300m
memory: 512Mi
terminationGracePeriodSeconds: 60 |
I just tested with MySql and two replicas. Keycloak started successfully and |
Looks good to me! @axdotl please unblock process :). |
@swistaczek Did you test it? What database? How many replicas? |
@unguiculus yes, I tested this code with Istio 1.0.2 and google cloud sql (cloud-sql-proxy). |
/hold cancel |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: scottrigby, unguiculus The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@unguiculus That's all fantastic work! I have a question related to deploying to Google Kubernetes Engine. I have tried to deploy using external postgres db (using the values.yaml file specified at the bottom).
pod#1 Log
pod#2 Log
At this state the application does not work properly (the authentication itself fails)
pod#1 log
pod#2 log
Any insight in figuring the issue out would be great help
|
Testing the KUBE_PING version of stormmore directly works, but >1 replicas with default settings results in the issues: 14:18:41,243 DEBUG [org.infinispan.util.ModuleProperties] (MSC service thread 1-1) No module command extensions to load Does anybody have an idea what might be the reason? thx |
* The Docker image has added support for DNS_PING which is now used instead of JDBC_PING * The StatefulSet is updated to `apps/v1` Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>
* The Docker image has added support for DNS_PING which is now used instead of JDBC_PING * The StatefulSet is updated to `apps/v1` Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>
* The Docker image has added support for DNS_PING which is now used instead of JDBC_PING * The StatefulSet is updated to `apps/v1` Signed-off-by: Reinhard Nägele <unguiculus@gmail.com> Signed-off-by: Jakob Niggel <info@jakobniggel.de>
* The Docker image has added support for DNS_PING which is now used instead of JDBC_PING * The StatefulSet is updated to `apps/v1` Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>
instead of JDBC_PING
apps/v1
Signed-off-by: Reinhard Nägele unguiculus@gmail.com
Checklist