Fix HTTPS management after first deploy #1

Closed
opened 2020-03-29 11:17:55 +00:00 by decentral1se · 9 comments
Owner

New deployments are broken. See the drone logs.

New deployments are broken. See the drone logs.
Author
Owner

remote: curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
remote: ! Check attempt 3/5 failed.
remote: Attempt 4/5. Waiting for 30 seconds ...

> remote: curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number > remote: ! Check attempt 3/5 failed. > remote: Attempt 4/5. Waiting for 30 seconds ...
Author
Owner

OK, so in order to get a fresh install working I ran dokku apps:destroy keycloak and then a new build worked just fine! Then testing that, on pushing out to Gitea/Drone for a deploy, I got another failure with the same error as above (see https://drone.autonomic.zone/autonomic-cooperative/keycloak/8/1/3). So, it seems like additional deployments will fail without wiping out the app...

It may be something to do with this log:

remote: 11:46:08,398 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /opt/jboss/keycloak/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost

Perhaps the second keycloak is generating a cert that is only valid for localhost but the app already has the LE certs mounted into the storage. This might be it...

OK, so in order to get a fresh install working I ran `dokku apps:destroy keycloak` and then a new build worked just fine! Then testing that, on pushing out to Gitea/Drone for a deploy, I got another failure with the same error as above (see https://drone.autonomic.zone/autonomic-cooperative/keycloak/8/1/3). So, it seems like additional deployments will fail without wiping out the app... It may be something to do with this log: > remote: 11:46:08,398 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /opt/jboss/keycloak/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost Perhaps the second keycloak is generating a cert that is only valid for localhost but the app already has the LE certs mounted into the storage. This might be it...
Author
Owner

For now, it's up, I'll come back to this... work around is for now:

$ dokku apps:destroy keycloak --force

Then push out to deploy again. All data is stored host side on a persistent volume.

For now, it's up, I'll come back to this... work around is for now: ```bash $ dokku apps:destroy keycloak --force ``` Then push out to deploy again. All data is stored host side on a persistent volume.
decentral1se changed title from Fix HTTPS management to Fix HTTPS management after first deploy 2020-03-29 11:51:24 +00:00
Author
Owner

Ah, I've just noticed it is a port conflict perhaps...

root@autonomic-dokku:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
64e2edbd9451 dokku/drone:latest "/bin/drone-server" 22 hours ago Up 22 hours 80/tcp, 443/tcp, 8080/tcp drone.web.1
5af2e6b97369 dokku/homebase:latest "docker-entrypoint.s…" 23 hours ago Up 23 hours 3282/tcp, 8085/tcp homebase.web.1
04fd752971c6 dokku/drone-docker-runner:latest "/bin/drone-runner-d…" 23 hours ago Up 23 hours 3000/tcp drone-docker-runner.web.1
10a6790ebacd dokku/gitea:latest "/sbin/entrypoint.sh" 23 hours ago Up 23 hours 22/tcp, 2222/tcp, 3000/tcp, 3020/tcp gitea.web.1
8ece5bc82931 42986a725dce "/opt/jboss/tools/do…" 2 days ago Up 2 days 8080/tcp, 8443/tcp keycloak.web.1
6be3604e5c9e mariadb:10.4.10 "docker-entrypoint.s…" 8 days ago Up 8 days 3306/tcp dokku.mariadb.keycloak
ebe272818b64 mariadb:10.4.10 "docker-entrypoint.s…" 8 days ago Up 8 days 3306/tcp dokku.mariadb.gitea

Where drone and keycloak are both using port 8080...

Related to autonomic-cooperative/organising#7.

Ah, I've just noticed it is a port conflict perhaps... > root@autonomic-dokku:~# docker ps > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > 64e2edbd9451 dokku/drone:latest "/bin/drone-server" 22 hours ago Up 22 hours 80/tcp, 443/tcp, 8080/tcp drone.web.1 > 5af2e6b97369 dokku/homebase:latest "docker-entrypoint.s…" 23 hours ago Up 23 hours 3282/tcp, 8085/tcp homebase.web.1 > 04fd752971c6 dokku/drone-docker-runner:latest "/bin/drone-runner-d…" 23 hours ago Up 23 hours 3000/tcp drone-docker-runner.web.1 > 10a6790ebacd dokku/gitea:latest "/sbin/entrypoint.sh" 23 hours ago Up 23 hours 22/tcp, 2222/tcp, 3000/tcp, 3020/tcp gitea.web.1 > 8ece5bc82931 42986a725dce "/opt/jboss/tools/do…" 2 days ago Up 2 days 8080/tcp, 8443/tcp keycloak.web.1 > 6be3604e5c9e mariadb:10.4.10 "docker-entrypoint.s…" 8 days ago Up 8 days 3306/tcp dokku.mariadb.keycloak > ebe272818b64 mariadb:10.4.10 "docker-entrypoint.s…" 8 days ago Up 8 days 3306/tcp dokku.mariadb.gitea Where drone and keycloak are both using port 8080... Related to https://git.autonomic.zone/autonomic-cooperative/organising/issues/7.
Author
Owner

Need to override https://github.com/keycloak/keycloak-containers/blob/master/server/tools/docker-entrypoint.sh somehow to configure the port. Ideally I don't have to override this file entirely...

Need to override https://github.com/keycloak/keycloak-containers/blob/master/server/tools/docker-entrypoint.sh somehow to configure the port. Ideally I don't have to override this file entirely...
Author
Owner

For now, I was able to reconfigure the drone port but will need to make the keycloak port configurable for sure since taking up this port forever will definitely lead to issues. However, upon deploying once more, I was still getting the same HTTPS issue so it appears to be something else at play here...

For now, I was able to reconfigure the drone port but will need to make the keycloak port configurable for sure since taking up this port forever will definitely lead to issues. However, upon deploying once more, I was still getting the same HTTPS issue so it appears to be something else at play here...
Author
Owner

So, as it turns out, the internal CHECKS comman is failing...

$ curl -q --compressed --fail --location --noproxy 172.17.0.4 --max-time 30 -H X-Forwarded-Proto:https http://172.17.0.4:8080/auth

Where Proto:https is then requesting a http:// URL.

Maybe I'm doing something wrong...

So, as it turns out, the internal CHECKS comman is failing... ``` $ curl -q --compressed --fail --location --noproxy 172.17.0.4 --max-time 30 -H X-Forwarded-Proto:https http://172.17.0.4:8080/auth ``` Where `Proto:https` is then requesting a `http://` URL. Maybe I'm doing something wrong...
Author
Owner
Opened up https://github.com/dokku/dokku/issues/3912.
Author
Owner

OK, so to resolve this, we just skip CHECKS because of how Keycloak works on the application level. It seems to be the simplest way forward and there are still default checks in place.

OK, so to resolve this, we just skip CHECKS because of how Keycloak works on the application level. It seems to be the simplest way forward and there are still default checks in place.
This repo is archived. You cannot comment on issues.
No Label
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: autonomic-cooperative/id.autonomic.zone#1
No description provided.