docker-compose v3 + apache spark, connection refused on port 7077 - apache-spark

I'm not sure if this is 100% programming or sysadmin related question.
I'm trying to setup a docker-compose file, in the version 3, for docker-swarm, docker version 1.13 to test spark for my local workflow.
Sadly the port 7077 does only get bound to localhost on my swarm cluster and so is not reachable from the outside world, where my spark app is trying to connect to it.
Does anyone have an idea, how to get docker-compose in swarm mode to bind to all interfaces?
I publish my ports and this works fine for say 8080, but not for 7070.
nmap output:
Starting Nmap 7.01 ( https://nmap.org ) at 2017-03-02 11:27 PST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000096s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
8080/tcp open http-proxy
8081/tcp open blackice-icecap
8888/tcp open sun-answerbook
Explanation of ports
8081 is my spark worker
8080 is my spark master frontend
8888 is the spark hue frontend
nmap does not list 7077
Using netstat:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1641/sshd
tcp6 0 0 :::4040 :::* LISTEN 1634/dockerd
tcp6 0 0 :::2377 :::* LISTEN 1634/dockerd
tcp6 0 0 :::7946 :::* LISTEN 1634/dockerd
tcp6 0 0 :::80 :::* LISTEN 1634/dockerd
tcp6 0 0 :::8080 :::* LISTEN 1634/dockerd
tcp6 0 0 :::8081 :::* LISTEN 1634/dockerd
tcp6 0 0 :::6066 :::* LISTEN 1634/dockerd
tcp6 0 0 :::22 :::* LISTEN 1641/sshd
tcp6 0 0 :::8888 :::* LISTEN 1634/dockerd
tcp6 0 0 :::443 :::* LISTEN 1634/dockerd
tcp6 0 0 :::7077 :::* LISTEN 1634/dockerd
And I can connect to 7077 over telnet on localhost without any issues, but outside of localhost I'm receiving a connection refused error.
At this point in time (please bear with me, I'm not a sysadmin, I'm a software guy), I'm starting to have the feeling this is somehow related to the docker mesh network.
Docker compose section for my master configuration:
#the spark master, having to run on the frontend of the cluster
master:
image: eros.fiehnlab.ucdavis.edu/spark
command: bin/spark-class org.apache.spark.deploy.master.Master -h master
hostname: master
environment:
MASTER: spark://master:7077
SPARK_CONF_DIR: /conf
SPARK_PUBLIC_DNS: blonde.fiehnlab.ucdavis.edu
ports:
- 4040:4040
- 6066:6066
- 8080:8080
- 7077:7077
volumes:
- /tmp:/tmp/data
networks:
- spark
- frontends
deploy:
placement:
#only run on manager node
constraints:
- node.role == manager
The networks spark and frontend are both overlay networks

The issue was a configuration error in the docker-compose file. The -h master in the original configuration always bound to the local host interface.
Even after specifying the SPARK_LOCAL_IP value
master:
image: eros.fiehnlab.ucdavis.edu/spark:latest
command: bin/spark-class org.apache.spark.deploy.master.Master
hostname: master
environment:
SPARK_CONF_DIR: /conf
SPARK_PUBLIC_DNS: blonde.fiehnlab.ucdavis.edu
SPARK_LOCAL_IP: 0.0.0.0
ports:
- 4040:4040
- 6066:6066
- 8080:8080
- 7077:7077
volumes:
- /tmp:/tmp/data
deploy:
placement:
#only run on manager node
constraints:
- node.role == manager

Related

Unable to remotely connect to docker container

I am new to docker, this is my first attempt at using it.
I have setup a docker container on a AWS DEBIAN 9 host and started it:
#docker-compose up -d
This is the section related to the web app:
waweb:
image: docker.whatsapp.biz/web:v${WA_API_VERSION:?Run docker-compose with env var WA_API_VERSION (ex. WA_API_VERSION=2.29.2 docker-compose <command> <options>)}
command: ["/opt/whatsapp/bin/wait_on_mysql.sh", "/opt/whatsapp/bin/launch_within_docker.sh"]
ports:
- "9090:443"
volumes:
- whatsappMedia:/usr/local/wamedia
env_file:
- db.env
environment:
WACORE_HOSTNAME: wacore
# This is the version of the docker templates being used to run WhatsApp Business API
WA_RUNNING_ENV_VERSION: v2.2.3
ORCHESTRATION: DOCKER-COMPOSE
depends_on:
- "db"
- "wacore"
links:
- db
- wacore
network_mode: bridge
When I test this it shows that all appears to be correct and it is listening on 9090:
# docker-compose ps
Name Command State Ports
------------------------------------------------------------------------------------------------
wabiz_db_1 docker-entrypoint.sh mysqld Up 0.0.0.0:33060->3306/tcp, 33060/tcp
wabiz_wacore_1 /opt/whatsapp/bin/wait_on_ ... Up 6250/tcp, 6251/tcp, 6252/tcp, 6253/tcp
wabiz_waweb_1 /opt/whatsapp/bin/wait_on_ ... Up 0.0.0.0:9090->443/tcp
and:
# netstat -tulpn | grep LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 18818/sshd
tcp6 0 0 :::22 :::* LISTEN 18818/sshd
tcp6 0 0 :::9090 :::* LISTEN 32144/docker-proxy
tcp6 0 0 :::33060 :::* LISTEN 32361/docker-proxy
I can test-connect to this locally:
# telnet localhost 9090
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
Yet when I attempt connect to it remotely, the connection is refused.
The firewall ports are all open to my IP (1-65535), I can remotely telnet to port 22 and also create a python simple-http-server and connect to that remotely too.
I thought that maybe IPV6 was being forced, but it is not:
# sysctl net.ipv6.bindv6only
net.ipv6.bindv6only = 0
Any suggestions on what the issue may be ?

Why can't I talk to a service on tcp/3000 on my CentOS VPS

I'm trying to run a second web service on my VPS at port 3000.
On the VPS I run:
# php -S myhost.com:3000
and then in a browser, navigate to http://myhost.com:3000 but the browser times out and the service logs/outputs nothing.
If I run the service on port 80 (i.e., php -S myhost.com:80 and navigate to http://myhost.com), it works.
So firewall. Except that:
[root#spinal ~]# firewall-cmd --list-ports
3887/tcp 3000/tcp
(the 3887 is another service, which is working correctly.) And I rebooted the VPS after setting up port 3000 in the firewall. I reckon the service is listening correctly because:
[root#spinal ~]# netstat -tupl
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:imap 0.0.0.0:* LISTEN 1907/dovecot
tcp 0 0 0.0.0.0:ciphire-data 0.0.0.0:* LISTEN 1876/sshd
tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN 1903/nginx: master
tcp 0 0 0.0.0.0:urd 0.0.0.0:* LISTEN 2004/master
tcp 0 0 myhost.com:hbci 0.0.0.0:* LISTEN 2206/php
tcp 0 0 localhost.loca:postgres 0.0.0.0:* LISTEN 1908/postgres
tcp 0 0 0.0.0.0:smtp 0.0.0.0:* LISTEN 2004/master
tcp 0 0 0.0.0.0:https 0.0.0.0:* LISTEN 1903/nginx: master
tcp 0 0 0.0.0.0:imaps 0.0.0.0:* LISTEN 1907/dovecot
tcp 0 0 localhost.lo:cslistener 0.0.0.0:* LISTEN 1878/php-fpm: maste
tcp6 0 0 [::]:imap [::]:* LISTEN 1907/dovecot
tcp6 0 0 [::]:ciphire-data [::]:* LISTEN 1876/sshd
tcp6 0 0 [::]:urd [::]:* LISTEN 2004/master
tcp6 0 0 [::]:smtp [::]:* LISTEN 2004/master
tcp6 0 0 [::]:imaps [::]:* LISTEN 1907/dovecot
I can however connect locally. This works, when run on the VPS:
$ curl http://myhost.com:3000
so that again points at the firewall. But disabling the firewall doesn't help:
# systemctl stop firewalld
so it could be a DNS problem: my browser and the VPS differ on what myhost.com resolves-to. Except that, as mentioned above, switching to port 80 solves the problem. So it's something to do with coming-in on port 3000, from outside. But not firewalld.
The question at Can't reach nodejs on port 3000 from external on CentOS 7 is close to mine, but isn't conclusively answered.
I feel pretty stupid. It was a firewall; not on the VPS, but on my local network. When I tried it on a machine that doesn't go through my local network, it worked. I hope my public confession helps someone else.

Passenger, Plesk and Node.js: address already in use

My question is about getting Phusion Passenger and Plesk Onyx 17.5.3 to work together nicely. I have a new server running Ubuntu 16.04.
I am following the official Phusion Passenger tutorial on deploying a Node.js app, and I have followed it successfully to the point where I need to tell Passenger to listen on port 80.
Here are my steps:
With my registrar, I set up a DNS entry for the subdomain pass.domain.com
In the Plesk interface, I define the new subdomain
If I visit http://pass.domain.com in my browser, I get the default Plesk web page.
I follow the "Phusion Passenger: Node.js tutorial" until I reach this command:
sudo passenger start --port 80 --user someusername --environment production --daemonize
Note: I am using a valid custom user name in the place of `someusername'.
I get this error:
Could not start the Nginx engine:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
It appears that Plesk is already serving the default web page at this address, so Phusion Passenger cannot access it. What files do I need to add or edit to get Plesk to release the address so that Passenger can use it?
EDIT 4: I have found this question which describes similar symptoms. However the OP is using Meteor Up and I am using Passenger. His solution was to get Meteor Up to tell Node.js to run on port 3001, and get nginx to listen on port 80 and proxy requests to port 3001. I had understood that Phusion Passenger already does something similar under the hood.
Is there a way to modify the passenger start command to clarify this?
OLDER EDITS
EDIT 1: In response to #TarunLalwali, here is the output of sudo netstat -plnat on this server:
$ sudo netstat -plnat
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:4190 0.0.0.0:* LISTEN 15234/dovecot
tcp 0 0 127.0.0.1:12768 0.0.0.0:* LISTEN 15654/psa-pc-remote
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 15234/dovecot
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 15234/dovecot
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 2293/mongod
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 15234/dovecot
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 15234/dovecot
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 1315/.spamassassin
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 26659/nginx
tcp 0 0 0.0.0.0:8880 0.0.0.0:* LISTEN 23894/config
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 2142/master
tcp 0 0 172.17.0.1:53 0.0.0.0:* LISTEN 17312/named
tcp 0 0 94.76.206.212:53 0.0.0.0:* LISTEN 17312/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 17312/named
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1413/sshd
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 12563/passenger-sta
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 17312/named
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2142/master
tcp 0 0 94.76.206.212:443 0.0.0.0:* LISTEN 26659/nginx
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 23894/config
tcp 0 0 94.76.206.212:993 92.130.47.95:49994 ESTABLISHED 15322/imap-login
tcp 0 0 127.0.0.1:51168 127.0.0.1:12768 TIME_WAIT -
tcp 0 0 94.76.206.212:25 200.188.141.75:51400 TIME_WAIT -
tcp 0 188 94.76.206.212:22 92.130.47.95:34414 ESTABLISHED 4035/sshd: blacksla
tcp6 0 0 :::4190 :::* LISTEN 15234/dovecot
tcp6 0 0 :::993 :::* LISTEN 15234/dovecot
tcp6 0 0 :::995 :::* LISTEN 15234/dovecot
tcp6 0 0 :::7080 :::* LISTEN 26432/apache2
tcp6 0 0 :::7081 :::* LISTEN 26432/apache2
tcp6 0 0 127.0.0.1:3306 :::* LISTEN 10040/mysqld
tcp6 0 0 :::106 :::* LISTEN 1532/xinetd
tcp6 0 0 :::110 :::* LISTEN 15234/dovecot
tcp6 0 0 :::143 :::* LISTEN 15234/dovecot
tcp6 0 0 ::1:783 :::* LISTEN 1315/.spamassassin
tcp6 0 0 2a02:af8:1:900::3860:80 :::* LISTEN 26659/nginx
tcp6 0 0 :::8880 :::* LISTEN 23894/config
tcp6 0 0 :::465 :::* LISTEN 2142/master
tcp6 0 0 :::53 :::* LISTEN 17312/named
tcp6 0 0 :::21 :::* LISTEN 1532/xinetd
tcp6 0 0 :::22 :::* LISTEN 1413/sshd
tcp6 0 0 :::25 :::* LISTEN 2142/master
tcp6 0 0 2a02:af8:1:900::386:443 :::* LISTEN 26659/nginx
tcp6 0 0 :::8443 :::* LISTEN 23894/config
Note: I have already asked about this issue on the Plesk forum, but it has received no response. I am hoping that asking the Phusion Passenger community here will be more productive. Once I have a working solution, I will post a link from the Plesk forum to the answer here.
Thanks in advance for your insights,
James
EDIT 2: Following #TarunLalwali's advice, I tried stopping nginx, but this produced an unknown error:
$ sudo nginx -s stop
$ sudo passenger start --port 80 --user node --environment production --daemonize
Could not start the Nginx engine:
nginx: [alert] Unable to start the Phusion Passenger watchdog because it encountered the following error during startup: Unable to start the Passenger core: it seems to have crashed during startup for an unknown reason, with exit code 1 (-1: Unknown error)
EDIT 3: Attempting to disable nginx server-wide before invoking Passenger:
$ sudo systemctl disable nginx
Synchronizing state of nginx.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install disable nginx
insserv: warning: current start runlevel(s) (empty) of script `nginx' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `nginx' overrides LSB defaults (0 1 6).
$ systemctl status nginx
* nginx.service - Startup script for nginx service
Loaded: loaded (/lib/systemd/system/nginx.service; disabled; vendor preset: enabled)
Active: inactive (dead)
$ sudo passenger start --port 80 --user node --environment production --daemonize
Could not start the Nginx engine:
nginx: [alert] Unable to start the Phusion Passenger watchdog because it encountered the following error during startup: Unable to start the Passenger core: it seems to have crashed during startup for an unknown reason, with exit code 1 (-1: Unknown error)
You mention that you need the system Nginx (at port 80) to run other subdomains on the server.
Passenger Standalone can coexist peacefully with a system Nginx using two steps:
Run it on a non-conflicting port, for example the default 3000:
sudo passenger start --port 3000 --user someusername --environment production --daemonize
For the domain that you want Passenger to server, tell the system Nginx to proxy to Passenger.
proxy_pass http://localhost:3000;
Remember to reload/restart Nginx to activate the config.
How to do step 2 exactly in Plesk is a question best asked on the Plesk forum, but from the Passenger point of view this setup should work.

Cannot access Django webpage when using Docker to run a virtualized Django project on Linux server

I set up a docker for a Django project on a Linux server. However, when I run the Django project, it cannot be accessed through the Internet. The project is set up using Docker automatic build and pulled using docker-compose. The docker-compose ps command gives the following output, indicating the project is running.
~/otree-docker$ docker-compose ps
Name Command State Ports
------------------------------------------------------------------------------------
otreedocker_database_1 docker-entrypoint.sh postgres Up 5432/tcp
otreedocker_otree_1 /bin/sh -c /opt/otree/entr ... Up 0.0.0.0:80->80/tcp
otreedocker_redis_1 docker-entrypoint.sh redis ... Up 6379/tcp
When I use nginx to set up a test webpage, however, it can be accessed without any issue.
Most importantly, I used the same Docker automatic build on another server, it ran without any issue, so the issue must be the setup of the server, not the Django project or the Docker automatic build. Anyone can suggest where to identify the issue? I have been struggling with this issue for several days, and have no idea where to check.
BTW, when I check the usage of the ports when running the Django project, I get the following:
~$ netstat -ntl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:49471 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4410 0.0.0.0:* LISTEN
tcp6 0 0 :::4000 :::* LISTEN
tcp6 0 0 :::10050 :::* LISTEN
tcp6 0 0 :::9390 :::* LISTEN
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::5555 :::* LISTEN
tcp6 0 0 :::46361 :::* LISTEN
tcp6 0 0 :::25 :::* LISTEN
tcp6 0 0 :::4410 :::* LISTEN
When I put up a test webpage using nginx, I get the following:
~$ netstat -ntl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:49471 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4410 0.0.0.0:* LISTEN
tcp6 0 0 :::4000 :::* LISTEN
tcp6 0 0 :::10050 :::* LISTEN
tcp6 0 0 :::9390 :::* LISTEN
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 :::5555 :::* LISTEN
tcp6 0 0 :::46361 :::* LISTEN
tcp6 0 0 :::25 :::* LISTEN
tcp6 0 0 :::4410 :::* LISTEN
Django uses tcp6 while nginx uses tcp. I don't know too much about the server setup, but might this issue be caused by some restriction on the tcp6 protocol on the server?
My docker-compose.yml is as follows
ersion: "2"
services:
database:
image: postgres:9.5
environment:
POSTGRES_DB: ${POSTGRES_DATABASE}
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DATA: /var/lib/postgresql/data/pgdata
logging:
options:
max-size: "10m"
max-file: "3"
restart: always
read_only: true
volumes:
- "database:/var/lib/postgresql/data"
tmpfs:
- "/tmp"
- "/run"
networks:
db-net:
otree:
# if using Docker Hub, leave "build: ./" commented out.
# if you want to build an image locally, uncomment it.
# build: ./
image: myusername/otree_experiment:latest
environment:
DATABASE_URL: "postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}#database/${POSTGRES_DATABASE}"
OTREE_ADMIN_PASSWORD: ${OTREE_ADMIN_PASSWORD}
OTREE_PRODUCTION: ${OTREE_PRODUCTION}
OTREE_AUTH_LEVEL: ${OTREE_AUTH_LEVEL}
ports:
- ${OTREE_PORT}:80
volumes:
volumes:
- "otree-resetdb:/opt/init"
# Uncomment for live editing
# - ./:/opt/otree
restart: always
logging:
options:
max-size: "10m"
max-file: "3"
networks:
- db-net
- redis-net
redis:
image: redis
command: "redis-server"
logging:
options:
max-size: "10m"
max-file: "3"
restart: always
read_only: true
networks:
- redis-net
volumes:
database:
otree-resetdb:
networks:
db-net:
redis-net:

Why isn't my port exposed? netstat output included

This is my problem
# docker exec -ti root_web_1 bash
[root#ca32f79bdc14]# curl couchdb:5984
curl: (7) Failed to connect to couchdb port 5984: Connection refused
[root#ca32f79bdc14]# curl redis:6379
-ERR wrong number of arguments for 'get' command
-ERR unknown command 'Host:'
-ERR unknown command 'User-Agent:'
-ERR unknown command 'Accept:'
^C
Question
Why can't I access couchdb:5984 ?
Background
When I am in my couchdb container I can curl localhost:5984 and it responds and netstat -nl gives me
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.11:35300 0.0.0.0:* LISTEN
udp 0 0 127.0.0.11:51267 0.0.0.0:*
and the Dockerfile contains EXPOSE 5984, but I get connection refused when doing curl couchdb:5984 from the web container.
When I do the same with redis, curl redis:6379 it responds and netstat -nl gives
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.11:46665 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN
tcp6 0 0 :::6379 :::* LISTEN
udp 0 0 127.0.0.11:49518 0.0.0.0:*
This is the couchdb Dockerfile
FROM fedora:25
RUN dnf -y update
RUN dnf -y install couchdb
EXPOSE 5984
CMD ["/usr/bin/couchdb"]
This is the docker-compose.yml.
version: '2'
networks:
revproxynet:
external: true
services:
web:
images: nginx
networks:
- revproxynet
redis:
image: redis
networks:
- revproxynet
couchdb:
build: /docker/couchdb/
networks:
- revproxynet
The network is created with docker network create revproxynet.
In /etc/couchdb/local.ini you need to have
[httpd]
bind_address = 0.0.0.0
and it will work.

Resources