Open mikehwang opened 7 years ago
@mikehwang any luck with finding a workaround this issue?
Had the same issue. http works but not for https. I used script check for workaround but it's not a good solution. -e "SERVICE_8443_CHECK_SCRIPT=curl -s https://$HOSTNAME:$PORT/health" \
Found the reason in my case. I used https check but did not setup TLS correctly. For ignoring TLS, need to do some small change in the source code. The solution #447 was suggested sometime ago but it was not merged to the master branch yet.
I made change similarly plus a small fix
Add the env variable SERVICE_443_CHECK_TLS_SKIP_VERIFY=true
---- consul.go ----
import "strconv"
...
func (r *ConsulAdapter) buildCheck(service *bridge.Service) *consulapi.AgentServiceCheck {
...
if value:= service.Attrs["check_tls_skip_verify"]; value != "" {
tls_skip_verify, _ := strconv.ParseBool(value)
check.TLSSkipVerify = tls_skip_verify
...
}
}
I think this issue is possibly down to a change in alpine 3.5 where the ca-certificates package is no longer installed with go.
I had to fix the same thing on our fork: https://github.com/hudl/registrator/pull/11
I would suggest that unless you are using self-signed, or other invalid certs, you shouldn't really need to disable verification.
Update: See PR for the fix to the Dockerfile below.
I would suggest that unless you are using self-signed, or other invalid certs, you shouldn't really need to disable verification.
I understand the sentiment, but here's my use case:
I start containers with, for example, docker-compose. They have environment variables set like SERVICE_443_CHECK_HTTPS=/health
.
registrator picks this up, and registers a health check in consul against https://172.17.0.16:443/health
.
I'm using a wildcard certificate on *.service.consul, which is used to secure traffic between the container and a load balancer. The health check then fails because Get https://172.17.0.16:443/health: x509: cannot validate certificate for 172.17.0.16 because it doesn't contain any IP SANs
AFAIK IP SANs don't support wildcard IP addresses, but the IP address that could be given to the container is effectively random. Therefore I need to skip verification of the certificate for the health check.
Are there any other options that work in this case?
@cwalsh I think you are right to do that. Unless the cert is created with that IP it's always going to be invalid.
I was referencing another bug which had meant root certificates were no longer being installed - which meant all certificates were invalid.
I just didn't want people to be trying to work around a bug I'd identified and provided a PR for. But in your use case, I agree that the code change is necessary, and this is a different problem to the one I mentioned. Sorry for the confusion.
I think the reason this doesn't work is pretty simple, if you look at https://github.com/gliderlabs/registrator/archive/v7.zip it does not appear the change has been released (https://github.com/gliderlabs/registrator/pull/388 was merged in July '16) but v7 was released in April '16.
We appear to be in the unfortunate situation where the documentation does not match what's actually available.
Try running gliderlabs/registrator:master instead of gliderlabs/registrator:latest
When will the next release be and the dockerhub image updated? I really need the HTTPS health checks.
I tried running my container with the
-e
flag to pass the environment variablesSERVICE_443_CHECK_HTTPS
andSERVICE_CHECK_HTTPS
. The container registers with Consul but there's no HTTPS health checks. I know this because I don't see the requests come in and I also verified by checking Consul via/v1/health/service
endpoint.Plain old HTTP health checks work.
What version of Docker are you running?
What version of registrator are you running? I just pulled the latest tag which is on v7.
What is the exact command you are running registrator with?
The Consul server version: