We are running consul through docker and using the HTTP health checks to a URL (https://10.1.24.68:5012/status) with a self-signed certificate. However, I get the following error:
2016/06/10 10:29:42 [WARN] agent: http request failed
'https://10.1.24.68:5012/status': Get https://10.1.24.68:5012/status:
read tcp 10.3.2.11:55549->10.1.24.68:5012: read: connection reset by
peer
It works as well when we use the Script health check with the wget command but this is not ideal. This is the line of code in Consul throwing the above error.
When running the health check to a HTTP URL (http://localhost:5012/status) it works. Could this be a certificate issue? I've added our certificate to both /etc/ssl/certs/ca-certificates.crt and /usr/share/local/ca-certificates.crt.
Halp!
Related
I have a spring boot application, and I run a performance test on it, using Gatling.
The issue is that after a few requests where everything works OK, the server returns connection refused and no other requests are working.
Gatling log looks like this:
---- Requests ------------------------------------------------------------------
> Global (OK=14 KO=1001 )
> POST /template (OK=13 KO=938 )
> PUT /feedback (OK=1 KO=63 )
---- Errors --------------------------------------------------------------------
> j.n.ConnectException: Connection refused: no further informati 577 (57,64%)
on
> j.i.IOException: Premature close 240 (23,98%)
> j.n.c.ClosedChannelException 184 (18,38%)
When I create a manual request using curl, returns:
$ curl https://localhost:8087
curl: (7) Failed to connect to localhost port 8087: Connection refused
If I connect to docker and do the request:
$ docker exec -it web /bin/bash
root#794f9e808f14:/# curl https://localhost:8443
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
SSL handshake failed, as expected, but this means that the server is up an running.
The port is mapped in docker:
$ docker port web
8443/tcp -> 0.0.0.0:8087
8443/tcp -> :::8087
After restart, all thing happen again.
I'm using docker on a WSL Ubuntu. Not sure if this matters too much. What can I do to make this connection more stable?
I have a laravel application running which tries to upload files to a local minio server which runs on https on port 9001.
This happens on a server with a public domain name we shall call foo.bar.com.
In the host machine (outside my docker containers) if I do curl -k https://foo.bar.com:9001 or curl -k https://0.0.0.0:9001 it works, but if I try to run these commands inside my laravel container I get curl: (7) Failed to connect to 0.0.0.0 port 9001: Connection refused.
In the container I can do connect to my minio server by using the minio containers name since they are on the same network curl -k https://pan.api.minio:9001.
I wanted to use this but then running migrations in laravel fails with Error executing "PutObject" on "https://pan.api.minio:9001/pan-local/ab7d6e69-5e13-4582-8855-669dcb935591/OVVzTEZiOGhSR3J1MkVHSmlIa3VoSXNsTFdJVnNWWlNCb0U2dnlsWm13dmNGUjRvWlVIVVJRTWxqak1reVhMUm1hbmV0LTItMQ%3D%3D"; AWS HTTP error: cURL error 60: SSL: no alternative certificate subject name matches target host name 'pan.api.minio' (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
I just want to upload files to my minio server from within my laravel container, but why can't I connect to it by doing foo.bar.com:9001 like I can outside of my docker containers?
I'm trying to connect to remote docker host through ssh tunnel. I have forwarded the 2375 port and I'm trying to connect to it by specifying DOCKER_HOST.
$ DOCKER_API_VERSION=1.24 DOCKER_HOST=localhost:2375 docker ps
error during connect: Get https://localhost:2375/v1.24/containers/json: http: server gave HTTP response to HTTPS client
This have worked before, but I can't make it work again, because my docker client keep giving me back this error. I can't make it ignore the https/http stuff. The connection is OK, i can curl the endpoints just fine, its just that docker client is doing something and then preventing itself from connecting and I don't know how to make it ignore the https.
I have finally figured out why I was getting this error. I was positive DOCKER_TLS_VERIFY was not set, but it was. So if anyone get this error, make sure the env variable is undefined or that the value is empty.
using
$ DOCKER_API_VERSION=1.24 DOCKER_HOST=localhost:2375 DOCKER_TLS_VERIFY= docker ps
did work as expected.
I have an etcd cluster using TLS for security. I want other machines to use etcd proxy, so the localhost clients don't need to use TLS. Proxy is configured like this:
[Service]
Environment="ETCD_PROXY=on"
Environment="ETCD_INITIAL_CLUSTER=etcd1=https://master1.example.com:2380,etcd2=https://master2.example.com:2380"
Environment="ETCD_PEER_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
Environment="ETCD_PEER_CERT_FILE=/etc/kubernetes/ssl/worker.pem"
Environment="ETCD_PEER_KEY_FILE=/etc/kubernetes/ssl/worker-key.pem"
Environment="ETCD_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
And it works, as far as the first connection goes. But the etcd client does an initial query to discover the full list of servers, and then it performs its real query against one of the servers in that list:
$ etcdctl --debug ls
start to sync cluster using endpoints(http://127.0.0.1:4001,http://127.0.0.1:2379)
cURL Command: curl -X GET http://127.0.0.1:4001/v2/members
got endpoints(https://1.1.1.1:2379,https://1.1.1.2:2379) after sync
Cluster-Endpoints: https://1.1.1.1:2379, https://1.1.1.2:2379
cURL Command: curl -X GET https://1.1.1.1:2379/v2/keys/?quorum=false&recursive=false&sorted=false
cURL Command: curl -X GET https://1.1.1.2:2379/v2/keys/?quorum=false&recursive=false&sorted=false
Error: client: etcd cluster is unavailable or misconfigured
error #0: x509: certificate signed by unknown authority
error #1: x509: certificate signed by unknown authority
If I change the etcd masters to --advertise-client-urls=http://localhost:2379, then the proxy will connect to itself and get into an infinite loop. And the proxy doesn't modify the traffic between the client and the master, so it doesn't rewrite the advertised client URLs.
I must not be understanding something, because the etcd proxy seems useless.
Turns out that most etcd clients (locksmith, flanneld, etc.) will work just fine with a proxy in this mode. It's only etcdctl that behaves differently. Because I was testing with etcdctl, I thought the proxy config wasn't working at all.
If etcdctl is run with --skip-sync, then it will communicate through the proxy rather than retrieving the list of public endpoints.
etcdctl cluster-health ignores --skip-sync and always touches the public etcd endpoints. It will never work with a proxy.
With option --endpoints "https://{YOUR_ETCD_ADVERTISE_CILENT_URL}:2379".
Because you configured TLS for etcd, you should add options --ca-file, --cert-file, --key-file.
I am trying to play around with kubernetes and specifically the REST API. The steps to connect with the cluster API are listed here. However Im stuck in the first step i.e. running kubectl proxy
I try running this:
kubectl --context='vagrant' proxy --port=8080 &
which returns error: couldn't read version from server: Get https://172.17.4.99:443/api: dial tcp 172.17.4.99:443: i/o timeout
What does this mean? How do overcome it connect to the API?
Check that your docker, proxy, kube-apiserver, kube-control-manager services are running without error. Check their status using systemclt status your-service-name. If the service is loaded but not running then restart the service by using systemctl restart your-service-name.