Docker compose no connection between containers using socket - docker

I am trying to use https://github.com/markshust/docker-magento. Following the instructions, the setup includes a nginx container in the frontend, which is suppose to connect with a php-fpm in the backend.
Containers:
ubuntu#DESKTOP-HED9HVG:/mnt/c/Users/Me$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8db110d5737a markoshust/magento-nginx:1.18-4 "/docker-entrypoint.…" 2 hours ago Up 2 hours 80/tcp, 0.0.0.0:80->8000/tcp, 0.0.0.0:443->8443/tcp localdev_app_1
74ff9e11646a markoshust/magento-php:7.4-fpm-5 "docker-php-entrypoi…" 2 hours ago Up 2 hours 9000-9001/tcp localdev_phpfpm_1
As far as I can understand the code, the phpfpm is listening on the docker socket.
Nginx upstream:
upstream fastcgi_backend {
server unix:/sock/docker.sock;
}
php-fpm.conf:
:
listen = /sock/docker.sock
:
this is the docker-compose.yaml file
But I can't get it to work.
php-fpm is working:
app#74ff9e11646a:~/html$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
app 1 0.0 0.2 222828 33168 ? Ss 06:57 0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
app 6 0.0 0.0 222828 10412 ? S 06:57 0:00 php-fpm: pool www
app 7 0.0 0.0 222828 10348 ? S 06:57 0:00 php-fpm: pool www
app 8 0.0 0.0 222828 10348 ? S 06:57 0:00 php-fpm: pool www
app 9 0.0 0.0 222828 10348 ? S 06:57 0:00 php-fpm: pool www
However,from nginx to phpfpm, there is ping, but there is no telnet:
/var/www/html # ping phpfpm
PING phpfpm (172.19.0.7): 56 data bytes
64 bytes from 172.19.0.7: seq=0 ttl=64 time=0.128 m
/var/www/html # telnet phpfpm 9000
telnet: can't connect to remote host (172.19.0.7): Connection refused
/var/www/html # telnet phpfpm 9001
telnet: can't connect to remote host (172.19.0.7): Connection refused
I am windows10 wsl2. Any idea what I should check?

You are telling PHP-FPM to use a socket for communication, that's why it's not listening on TCP / port 9000.
It can either listen on a TCP Port, OR use a socket, not both.

Related

All published services within a docker swarm are unreachable, while containers deployed normally work fine

I've run into an issue that seems similar too this one; https://forums.docker.com/t/cant-access-service-in-swarm/63876. My setup is a little bit different though and I haven't found a solution to my problem yet.
The minimal, reproducible example
Build a swarm cluster between atleast 3 Ubuntu 20.04 docker swarm managers.
Deploy a service docker service create --name test_web --replicas 3 --publish published=8080,target=80 nginxdemos/hello
Check that the containers and services were created properly and observe the failure of connecting to that service:
demi-ubu01:~/stacks$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d4a12a3c5448 nginxdemos/hello:latest "nginx -g 'daemon of…" About a minute ago Up About a minute 80/tcp test_web.2.yul33wdycarig3qoxnehgrjrz
demi-ubu01:~/stacks$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
0yqd7gvggwuh test_web replicated 3/3 nginxdemos/hello:latest *:8080->80/tcp
# External test:
demi-ubu01:~/stacks$ curl -I 10.100.4.5:8080
curl: (7) Failed to connect to 10.100.4.5 port 8080: Connection refused
# Inside container to published service port:
demi-ubu01:~/stacks$ docker exec -it d4a12a3c5448 wget http://test_web:8080
Connecting to test_web:8080 (10.0.4.2:8080)
wget: can't connect to remote host (10.0.4.2): Host is unreachable
# Inside container to apps exposed port:
demi-ubu01:~/stacks$ docker exec -it d4a12a3c5448 wget http://localhost:80
Connecting to localhost:80 (127.0.0.1:80)
index.html 100% |****************************| 7217 0:00:00 ETA
The expected result of the first curl command should be a Status 200 Ok.
The detailed report
My setup is 4 nodes in total. They are identical Ubuntu 20.04 KVM virtual machines all on the same network. There are no firewalls between them. I have 3 Managers and 1 Worker (which i've only added as a step during troubleshooting).
:~/stacks$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
kcm5v64psntjxngnqkfdj1jzh * demi-ubu01 Ready Active Reachable 20.10.1
uo3rljg6ax5qkjm898pyym9t1 demi-ubu02 Ready Active Leader 20.10.1
pysnl8sohdp4fv67gui156z4k demi-ubu03 Ready Active Reachable 20.10.1
rp2otsqpnxkgbmxbpkv21yjs6 demi-ubu04 Ready Active 20.10.1
I can run a container normally and reach it on the local host fine.
demi-ubu01:~/stacks$ docker run -p 8080:80 -d nginxdemos/hello
de4d0a937710acb1d6d8ae3b7eb9175860b6614dfd9ce92bc972efe619ae095f
demi-ubu01:~/stacks$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
de4d0a937710 nginxdemos/hello "nginx -g 'daemon of…" 4 seconds ago Up 2 seconds 0.0.0.0:8080->80/tcp pedantic_wiles
demi-ubu01:~/stacks$ curl -I 10.100.4.5:8080
HTTP/1.1 200 OK
Server: nginx/1.13.8
Date: Sat, 19 Dec 2020 17:59:23 GMT
Content-Type: text/html
Connection: keep-alive
Expires: Sat, 19 Dec 2020 17:59:22 GMT
Cache-Control: no-cache
However the same app deployed as a service using the following compose file:
demi-ubu01:~/stacks$ cat test.yml
version: "3.6"
services:
web:
image: nginxdemos/hello:latest
deploy:
replicas: 3
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
ports:
- target: 80
published: 8080
protocol: tcp
mode: ingress
networks:
- webnet
networks:
webnet:
driver: overlay
It does not become reachable from any of the hosts at all:
demi-ubu01:~/stacks$ docker stack deploy -c test.yml test
Creating network test_webnet
Creating service test_web
demi-ubu01:~/stacks$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05030ef897a1 nginxdemos/hello:latest "nginx -g 'daemon of…" 10 seconds ago Up 7 seconds 80/tcp test_web.1.kobrpkp68f2qbs4jhd6o8aebg
# Trying on all of the hosts in the cluster. No firewalls here.
demi-ubu01:~/stacks$ curl -I 10.100.4.5:8080
curl: (7) Failed to connect to 10.100.4.5 port 8080: Connection refused
demi-ubu01:~/stacks$ curl -I 10.100.4.9:8080
curl: (7) Failed to connect to 10.100.4.9 port 8080: Connection refused
demi-ubu01:~/stacks$ curl -I 10.100.4.10:8080
curl: (7) Failed to connect to 10.100.4.10 port 8080: Connection refused
demi-ubu01:~/stacks$ curl -I 10.100.4.11:8080
curl: (7) Failed to connect to 10.100.4.11 port 8080: Connection refused
demi-ubu01:~/stacks$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
elvfm7o4v4zo test_web replicated 3/3 nginxdemos/hello:latest *:8080->80/tcp
I also don't see any port bindings being made on those hosts at all, so it doesn't look like any ports are being published.
INeed2Poo#demi-ubu01:~/stacks$ docker service inspect test_web
[
## https://pastebin.com/WqqyDnVS ##
]
demi-ubu01:~/stacks$ netstat -na | grep LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:24007 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
demi-ubu01:~/stacks$ docker network ls
NETWORK ID NAME DRIVER SCOPE
6e5f7e7cebc3 bridge bridge local
7a1155f87a62 docker_gwbridge bridge local
ab32da8ac1ec host host local
46id8wzw4ayf ingress overlay swarm
a24a40ef78f4 none null local
d9l7msysdx8m test_webnet overlay swarm
INeed2Poo#demi-ubu01:~/stacks$ docker network inspect 46id8wzw4ayf
[
https://pastebin.com/JPA0ZBjE
]
I also can't reach the service while exec'ed into a container for that service. Execing into a container, I'm able to hit the LOCAL app port, however I cannot hit the service by name. The container CAN resolve the service name.
## Testing the app's service from the local container fails:
demi-ubu01:~/stacks$ docker exec -it 05030ef897a1 wget http://test_web:8080
Connecting to test_web:8080 (10.0.4.2:8080)
wget: can't connect to remote host (10.0.4.2): Host is unreachable
## Testing the app's local port from the local container is sucessful:
demi-ubu01:~/stacks$ docker exec -it 05030ef897a1 wget http://localhost:80
Connecting to localhost:80 (127.0.0.1:80)
index.html 100% |****************************| 7217 0:00:00 ETA
demi-ubu01:~/stacks$ docker --version
Docker version 20.10.1, build 831ebea
I've changed the default-addr-pool for the swarm cluster from the original 10.0.0.0/8 network:
demi-ubu01:~$ docker info --format '{{json .Swarm.Cluster.DefaultAddrPool}}'
["10.135.0.0/16"]
I've gone and made sure that I'm not using any overlapping networks that might be causing this and have gone so far as to completely redeploy the cluster. I've just about exhausted all of my troubleshooting idea's. Any Idea's?
Edit: Update: I redeployed using Ubuntu 18.04 as my base image, and the same exact setup on that (deployed using ansible) seems to work fine... So this is an issue with the current version of Docker on Ubuntu 20.04.
Let me add my response from the docker forum here as well, as it is high likely the solution:
Is it safe to assume that 10.100.4.5 is one of your nodes ip?
The default address pool is 10.0.0.0/8, see: docker info --format '{{json .Swarm.Cluster.DefaultAddrPool}}'
If this is the case, you might find this blog post helpful - you can safely ignore that it refers to Docker EE, the problem and solution is valid for Docker CE as well. You need to alter default-addr-pool either when initiating the swarm or by modifying each node’s /etc/docker/daemon.json configuration file (and restart the daemon then).

Haproxy always giving 503 Service Unavailable

I've installed Haproxy 1.8 on a Kubernetes Container.
Whenever I make any request to /test, I always get 503 Service Unavailable response. I want to return the stats page when I get a request to /test
Following is my configuration file:
/etc/haproxy/haproxy.cfg:
global
daemon
maxconn 256
defaults
mode http
timeout connect 15000ms
timeout client 150000ms
timeout server 150000ms
frontend stats
bind *:8404
mode http
stats enable
stats uri /stats
stats refresh 10s
frontend http-in
bind *:8083
default_backend servers
acl ar1 path -i -m sub /test
use_backend servers if ar1
backend servers
mode http
server server1 10.1.0.46:8404/stats maxconn 32
# 10.1.0.46 is my container IP
I can access the /stats page using:
curl -ik http://10.1.0.46:8404/stats
But when I do:
curl -ik http://10.1.0.46:8083/test
I always get following response:
HTTP/1.0 503 Service Unavailable
Cache-Control: no-cache
Content-Type: text/html
<html><body><h1>503 Service Unavailable</h1>
No server is available to handle this request.
</body></html>
I started haproxy using:
/etc/init.d/haproxy restart
and then subsequently restart it using:
haproxy -f haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
Following is the output of netstat -anlp:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 54/python3.5
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 802/haproxy
tcp 0 0 0.0.0.0:8404 0.0.0.0:* LISTEN 802/haproxy
tcp 0 0 10.1.0.46:8404 10.0.15.225:20647 TIME_WAIT -
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
Following is the output of ps -eaf:
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Jul22 ? 00:00:00 /bin/sh -c /bin/bash -x startup_script.sh
root 6 1 0 Jul22 ? 00:00:00 /bin/bash -x startup_script.sh
root 54 6 0 Jul22 ? 00:00:09 /usr/local/bin/python3.5 /usr/local/bin/gunicorn --bind 0.0.0.0:5000 runner:app?
root 57 54 0 Jul22 ? 00:02:50 /usr/local/bin/python3.5 /usr/local/bin/gunicorn --bind 0.0.0.0:5000 runner:app?
root 61 0 0 Jul22 pts/0 00:00:00 bash
root 739 0 0 07:02 pts/1 00:00:00 bash
root 802 1 0 08:09 ? 00:00:00 haproxy -f haproxy.cfg -p /var/run/haproxy.pid -sf 793
root 804 739 0 08:10 pts/1 00:00:00 ps -eaf
Why could I be getting 503 unavailable always?
Why do you use HAProxy 1.8 when a 2.2.x already exists?
You will need to adopt the path in the backend which can't be set on the server level.
backend servers
mode http
http-request set-path /stats
server server1 10.1.0.46:8404 maxconn 32
# 10.1.0.46 is my container IP

Docker Swarm service simple example does not reply to curl

I am trying to deploy a simple docker swarm service using routing mesh from this manual pages and access it.
Initialize docker swarm cluster with single manager node:
PS> docker swarm init --advertise-addr 192.168.1.156
Swarm initialized: current node (jpajl1nkr3xr1f3c3jqi56qia) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-2n1s6wap5dp1pjzzzqroyg22pqkwpnfijilmbdfgwjbkcqwder-5kqt701dv329fduhoaqld9m3y 192.168.1.156:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
Deploy service:
PS> docker service create --name my_web --publish published=80,target=80 --replicas 3 nginx
fqy4vi3hjncougtak9qj9fuz0
overall progress: 3 out of 3 tasks
1/3: running [==================================================>]
2/3: running [==================================================>]
3/3: running [==================================================>]
verify: Service converged
Check service and containers:
PS> docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
fqy4vi3hjnco my_web replicated 3/3 nginx:latest *:80->80/tcp
PS> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d24a85b4d6ba nginx:latest "/docker-entrypoint.…" 4 minutes ago Up 4 minutes 80/tcp my_web.2.b44g8bjs95ac8v0g90hnv2cjd
b6466f252b46 nginx:latest "/docker-entrypoint.…" 4 minutes ago Up 4 minutes 80/tcp my_web.3.hpc4zxlr178tklf84t1y5rc64
35e194264098 nginx:latest "/docker-entrypoint.…" 4 minutes ago Up 4 minutes 80/tcp my_web.1.u1euqrfwq2te75zsbkmfkv0bq
Request:
PS> curl http://localhost
curl : Se ha terminado la conexión: La conexión ha terminado de forma inesperada.
<< (Free Translation) curl: Connection is terminated: The connection has finished unexpectedly. >>
En línea: 1 Carácter: 1
+ curl http://localhost
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
Same result with these alternatives:
PS> curl http://localhost:80
PS> curl http://127.0.0.1:80
PS> curl http://192.168.1.156
PS> curl http://192.168.1.156:80
Check listening ports in Windows:
CMD> netstat -a -b | find "80"
TCP 0.0.0.0:80 fs1322:0 LISTENING
TCP 0.0.0.0:7680 fs1322:0 LISTENING
TCP 0.0.0.0:8080 fs1322:0 LISTENING
TCP 169.254.80.254:139 fs1322:0 LISTENING
TCP 172.19.80.1:53 fs1322:0 LISTENING
TCP 172.19.80.1:139 fs1322:0 LISTENING
Check listening ports in one container
# netstat -ltpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.11:34835 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/nginx: master pro
tcp6 0 0 :::80 :::* LISTEN 1/nginx: master pro
The execution of curl localhost in one container succeded:
# curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
</head>
</html>
Environment:
OS: Windows 10 Pro (2004)
Docker Desktop for Windows: 2.3.0.3
Docker Engine: 19.03.8
Virtualization: WSL2
Console: Windows PowerShell (not Administrator)

Error response from daemon: service endpoint with name

I'm getting this strange error, when I try to run a docker with a name it gives me this error.
docker: Error response from daemon: service endpoint with name qc.T8 already exists.
However, there is no container with this name.
> docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
> sudo docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 3
Server Version: 1.12.3
Storage Driver: aufs
Root Dir: /ahdee/docker/aufs
Backing Filesystem: extfs
Dirs: 28
Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: null bridge host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 3.13.0-101-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 64
Total Memory: 480.3 GiB
Is there anyway I can flush this out?
Just in case someone else needs this. As #Jmons pointed out it was a weird networking issue. So I solved this by forcing a removal
docker network disconnect --force bridge qc.T8
A
TLDR: restart your docker daemon or restart your docker-machine (if you're using that e.g. on a mac).
Edit: As there are more recent posts below, they answer the question better then mine. The Network adapter is stuck on the daemon. I'm updating mine as its possibly 'on top' of the list and people might not scroll down.
Restarting your docker daemon / docker service / docker-machine is the easiest answer.
the better answer (via Shalabh Negi):
docker network inspect <network name>
docker network disconnect <network name> <container id/ container name>
This is also faster in real time if you can find the network as restarting the docker machine/demon/service in my experience is a slow thing. If you use that, please scroll down and click +1 on their answer.
So the problem is probably your network adapter (virtual, docker thing, not real): have a quick peek at this: https://github.com/moby/moby/issues/23302.
To prevent it happening again is a bit tricky. It seems there may be an issue with docker where a container exits with a bad status code (e.g. non-zero) that holds the network open. You can't then start a new container with that endpoint.
docker network inspect <network name>
docker network disconnect <network name> <container id/ container name>
You can also try doing:
docker network prune
docker volume prune
docker system prune
these commands will help clearing zombie containers, volume and network.
When no command works then do
sudo service docker restart
your problem will be solved
docker network rm <network name>
Worked for me
Restarting docker solved it for me.
I created a script a while back, I think this should help people working with swarm. Using docker-machine this can help a bit.
https://gist.github.com/lcamilo15/7aaaebe71852444ea8f1da5c4c9c84b7
declare -a NODE_NAMES=("node_01", "node_02");
declare -a CONTAINER_NAMES=("container_a", "container_b");
declare -a NETWORK_NAMES=("network_1", "network_2");
for x in "${NODE_NAMES[#]}"; do;
docker-machine env $x;
eval $(docker-machine env $x)
for CONTAINER_NAME in "${CONTAINER_NAMES[#]}"; do;
for NETWORK_NAME in "${NETWORK_NAMES[#]}"; do;
echo "Disconnecting $CONTAINER_NAME from $NETWORK_NAME"
docker network disconnect -f $NETWORK_NAME $CONTAINER_NAME;
done;
done;
done;
You could try seeing if there's any network with that container name by running:
docker network ls
If there is, copy the network id then go on to remove it by running:
docker network rm network-id
This could be because an abrupt removal of a container may leave the network open for that endpoint (container-name).
Try stopping the container first before removing it.
docker stop <container-name>. Then docker rm <container-name>.
Then docker run <same-container-name>.
i think restart docker deamon will solve the problem
Even reboot did not help in my case. It turned out that port 80 to be assigned by the nginx container automatically was in use, even after reboot. How come?
root#IONOS_2: /root/2_proxy # netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 1378/rsync
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 1565/systemd-resolv
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1463/nginx: master
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1742/sshd
tcp6 0 0 :::2377 :::* LISTEN 24139/dockerd
tcp6 0 0 :::873 :::* LISTEN 1378/rsync
tcp6 0 0 :::7946 :::* LISTEN 24139/dockerd
tcp6 0 0 :::5355 :::* LISTEN 1565/systemd-resolv
tcp6 0 0 :::21 :::* LISTEN 1447/vsftpd
tcp6 0 0 :::22 :::* LISTEN 1742/sshd
tcp6 0 0 :::5000 :::* LISTEN 24139/dockerd
No idea what nginx: master means or where it came from. And indeed 1463 is the PID:
root#IONOS_2: /root/2_proxy # ps aux | grep "nginx"
root 1463 0.0 0.0 43296 908 ? Ss 00:53 0:00 nginx: master process /usr/sbin/nginx
root 1464 0.0 0.0 74280 4568 ? S 00:53 0:00 nginx: worker process
root 30422 0.0 0.0 12108 1060 pts/0 S+ 01:23 0:00 grep --color=auto nginx
So I tried this:
root#IONOS_2: /root/2_proxy # kill 1463
root#IONOS_2: /root/2_proxy # ps aux | grep "nginx"
root 30783 0.0 0.0 12108 980 pts/0 S+ 01:24 0:00 grep --color=auto nginx
And the problem was gone.

Port exposed by Docker not reachable

I ran a docker container that exposes port 443. docker ps confirms that it is exposed.
~ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
42b17c2a4b75 tmp/tmp "/usr/bin/tini -- /bi" 57 seconds ago Up 55 seconds 443/tcp adoring_austin
However, netstat doesn't show this port. I cannot reach it from a browser either.
~ netstat -lt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ssh *:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN
The command that I used the run the container is just JupyterHub.
[I 2016-11-22 03:12:11.494 JupyterHub app:643] Writing cookie_secret to /jupyterhub_cookie_secret
[W 2016-11-22 03:12:12.562 JupyterHub app:304]
Generating CONFIGPROXY_AUTH_TOKEN. Restarting the Hub will require restarting the proxy.
Set CONFIGPROXY_AUTH_TOKEN env or JupyterHub.proxy_auth_token config to avoid this message.
[W 2016-11-22 03:12:12.655 JupyterHub app:757] No admin users, admin interface will be unavailable.
[W 2016-11-22 03:12:12.655 JupyterHub app:758] Add any administrative users to `c.Authenticator.admin_users` in config.
[I 2016-11-22 03:12:12.655 JupyterHub app:785] Not using whitelist. Any authenticated user will be allowed.
[I 2016-11-22 03:12:12.671 JupyterHub app:1231] Hub API listening on http://172.17.0.3:8081/hub/
[I 2016-11-22 03:12:12.676 JupyterHub app:968] Starting proxy # http://*:443/
03:12:12.861 - info: [ConfigProxy] Proxying https://*:443 to http://172.17.0.3:8081
03:12:12.864 - info: [ConfigProxy] Proxy API at http://127.0.0.1:444/api/routes
[I 2016-11-22 03:12:12.883 JupyterHub app:1254] JupyterHub is now running at http://127.0.0.1:443/
What am I doing wrong here?
By default, this Jupyterhub Docker image just exposes the port 8000. You can read here. To use SSL (port 443), you might do some extra steps.
You can check it on port 8000.
Stop and remove your containers
docker stop jupyterhub
docker rm jupyterhub
Start the jupyterhub with the mapped ports:
docker run -d --name jupyterhub -p 443:443 -p 8000:8000 jupyterhub/jupyterhub jupyterhub
Check it at http://YOUR_DOCKER_IP:8000/, port 443 is not available.
docker ps
CONTAINER ID IMAGE COMMAND CREATED
STATUS PORTS NAMES
0a123216ee9f jupyterhub/jupyterhub "jupyterhub" 26 seconds ago
Up 3 seconds 0.0.0.0:443->443/tcp, 0.0.0.0:8000->8000/tcp jupyterhub

Resources