Some fine-tuning seems to be appropriate, but what then?
TL;DR:
Maybe this will help others struggling to learn like me and also you developers and evangelists from basho to be able to understand and help us newbies better.
It is a long story, but quite interesting and instructive, I hope.
In the end, I finally gave up, however.
Setup
I work with Vagrant/Virtualbox on XP and managed to set up two data containers (dbvx1, app), a MySQL server container ms working on dbvx1, a memcached container mc and an Apache/PHP container ap making use of app and linked to ms and mc.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5185cbf11593 kklepper/AP:latest /start.sh /bin/sh -c 42 hours ago Up 42 hours 192.168.0.42:49154->80/tcp ap
b0ebad4826db kklepper/memcached:latest memcached -u daemon 45 hours ago Up 45 hours 0.0.0.0:49156->11211/tcp ap/mc,mc
7530e02913fd kklepper/Ms:latest /bin/bash /start.sh 45 hours ago Up 45 hours 192.168.0.42:3306->3306/tcp ap/db,ms
0b56d0060c76 busybox:latest true 2 days ago Exit 0 app
8b6572266d74 busybox:latest true 2 days ago Exit 0 dbvx1
The app running on ap (192.168.0.42:49154) shows that even compressed key-value pairs on MySQL with query cache are significantly slower than memcached uncompressed, with values as strings of around 60 KB, so this is nice as far as it goes and shows that things are working as expected.
Readings vary greatly, though, but the follwing is quite typical and instructive:
Did mysql_query in 48.332929611206 milliseconds
Did memcached in 14.45198059082 milliseconds
Result: memcached 3 times faster: 33 milliseconds saved: 48 :: 14
Did memcached zipped in 10.414123535156 milliseconds
Result: memcached zipped / mysql 4 times faster: 37 milliseconds saved: 48 :: 10
Result: memcached/memcached zipped 1 times faster: 4 milliseconds saved: 14 :: 10
As an aside: It does not matter if I start timing before or after connecting to mysql or memcached, connection is fast.
The MySQL database could be replicated ad libitum, reads should by far outweigh writes in our app. I know this technique very well, although I don't know about Galera Cluster yet, which looks very interesting indeed.
The question remains: is MySQL the best choice for persistent storage in our case?
Next I wanted to have a look at Riak (see also the case study Inaka/Boundary, where they switched from Riak to MySQL).
First issue:
process hangs
vagrant@precise64:/vagrant/docker-lampstack-master/docker-riak$ make start-cluster
./bin/start-cluster.sh
Started [riak1] and assigned it the IP [33.33.33.10]
no more, process hangs
testing delivers
vagrant@precise64:/vagrant/docker-lampstack-master/docker-riak$ make test-cluster
./bin/test-cluster.sh
Testing [riak1]...
Testing [riak2]...
Testing [riak3]...
Testing [riak4]...
Testing [riak5]...
This behavior seemingly was caused by running an instance from executing the sample from this tutorial Riak Service.
Stopping and removing this container resolved the problem, so maybe a word of caution in the readme would help.
Next issue:
sshpass missing
Started [riak2] and assigned it the IP [33.33.33.20]
Requesting that [riak2] join the cluster..
./bin/start-cluster.sh: line 44: sshpass: command not found
make: *** [start-cluster] Error 127
So, the Dockerfile line
RUN apt-get install -y curl lsb-release supervisor openssh-server
should better be augmented with sshpass
Next issue:
time delay
Everything worked like a charm. But on repeat, I experienced this twice:
Requesting that [riak4] join the cluster..
Success: staged join request for '[email protected]' to '[email protected]'
2014/01/18 12:49:48 Error: start: Cannot start container 69b42cdb901c7c34e063cf3c769bbb9ad13cc273426a35bb6d625383c1da0d6b: The container failed to start due to timed out.
make: *** [start-cluster] Error 1
So even a timeout occurs. Why?
From the docker ps -a output it might seem be a kind of memory swapping problem due to the amount of time needed to complete an operation, but a simple restart resolved the problem altogether (why?):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
de5d6feb9fcb hectcastro/riak:latest /usr/bin/supervisord 47 seconds ago Up 47 seconds 22/tcp, 8087/tcp, 8098/tcp nostalgic_poincare
4ee5baa6dcb8 hectcastro/riak:latest /usr/bin/supervisord About a minute ago Up About a minute 22/tcp, 8087/tcp, 8098/tcp hungry_lumiere
73a949a40029 hectcastro/riak:latest /usr/bin/supervisord 3 minutes ago Up 3 minutes 22/tcp, 8087/tcp, 8098/tcp elegant_ritchie
64cd80d9d6ac hectcastro/riak:latest /usr/bin/supervisord 3 minutes ago Up 3 minutes 22/tcp, 8087/tcp, 8098/tcp sad_davinci
0e77bc096995 hectcastro/riak:latest /usr/bin/supervisord 3 minutes ago Up 3 minutes 22/tcp, 8087/tcp, 8098/tcp mad_curie
Now on repeat, I experienced again a similar time delay:
vagrant@precise64:/vagrant/docker-lampstack-master/docker-riak$ make start-cluster
./bin/start-cluster.sh
Started [riak1] and assigned it the IP [33.33.33.10]
Started [riak2] and assigned it the IP [33.33.33.20]
Requesting that [riak2] join the cluster..
Success: staged join request for '[email protected]' to '[email protected]'
Started [riak3] and assigned it the IP [33.33.33.30]
Requesting that [riak3] join the cluster..
Success: staged join request for '[email protected]' to '[email protected]'
Started [riak4] and assigned it the IP [33.33.33.40]
Requesting that [riak4] join the cluster..
Success: staged join request for '[email protected]' to '[email protected]'
Started [riak5] and assigned it the IP [33.33.33.50]
Requesting that [riak5] join the cluster..
Success: staged join request for '[email protected]' to '[email protected]'
etc. It took 7 minutes this time for the process to complete.
To test my memory/swapping hypothesis, I killed my RAM-hog Firefox and tried again:
fcef2725bde9 hectcastro/riak:latest /usr/bin/supervisord 1 seconds ago Up Less than a second 22/tcp, 8087/tcp, 8098/tcp elegant_wright
f2f5a6a714d9 hectcastro/riak:latest /usr/bin/supervisord 21 seconds ago Up 20 seconds 22/tcp, 8087/tcp, 8098/tcp ecstatic_wozniak
a5efc0e0f293 hectcastro/riak:latest /usr/bin/supervisord 27 seconds ago Up 27 seconds 22/tcp, 8087/tcp, 8098/tcp berserk_mccarthy
As can be seen, the second container came quickly, the third took some more time, but then...
fcef2725bde9 hectcastro/riak:latest /usr/bin/supervisord 33 seconds ago Up 33 seconds 22/tcp, 8087/tcp, 8098/tcp elegant_wright
f2f5a6a714d9 hectcastro/riak:latest /usr/bin/supervisord 53 seconds ago Up 53 seconds 22/tcp, 8087/tcp, 8098/tcp ecstatic_wozniak
a5efc0e0f293 hectcastro/riak:latest /usr/bin/supervisord 59 seconds ago Up 59 seconds 22/tcp, 8087/tcp, 8098/tcp berserk_mccarthy
After that, my second shell didn't even react at all... VBoxHeadless takes about 50% CPU, memory obviously isn't the problem, there is no I/O activity. And finally...
e027dec47311 hectcastro/riak:latest /usr/bin/supervisord About a minute ago Up About a minute 22/tcp, 8087/tcp, 8098/tcp sharp_engelbart
a3938391363f hectcastro/riak:latest /usr/bin/supervisord 2 minutes ago Up 2 minutes 22/tcp, 8087/tcp, 8098/tcp condescending_tesla
fcef2725bde9 hectcastro/riak:latest /usr/bin/supervisord 11 minutes ago Up 11 minutes 22/tcp, 8087/tcp, 8098/tcp elegant_wright
f2f5a6a714d9 hectcastro/riak:latest /usr/bin/supervisord 11 minutes ago Up 11 minutes 22/tcp, 8087/tcp, 8098/tcp ecstatic_wozniak
a5efc0e0f293 hectcastro/riak:latest /usr/bin/supervisord 11 minutes ago Up 11 minutes 22/tcp, 8087/tcp, 8098/tcp berserk_mccarthy
So we had about 9 minutes of seeming inactivity...
I already made up my mind to reload vagrant... memory doesn't seem to be the problem, does it?
What causes this random annoying delay? Should we be warned?
Last issue:
No idea what to do with this wonderful setup.
It is all very instructive, thank you very much - but what to do now? Considering the diligence of this example/tutorial, the next step seems to be missing. How about adding at least a link to http://docs.basho.com/riak/latest/quickstart/? But even then...
Apparently, I don't understand the model and concept here. So for your information this is what a newbie might do and experience:
I first tried to attach to the first container, berserk_mccarthy, saw nothing, hit Ctrl+c, and stopped it -- supervisord was running, my interaction caused it to stop. Ok, not a good idea.
So I started the container again and supervisord resumed operation, as it seems, but nevertheless I decided to experiment with the next one, ecstatic_wozniak, further on to be sure, and leave berserk_mccarthy alone.
vagrant@precise64:~$ docker inspect ecstatic_wozniak # revealed the IP 172.17.0.150
vagrant@precise64:~$ curl -XPUT http://172.17.0.150:8087/riak/images/1.jpg -H "Content-type: image/jpeg" --data-binary @test.jpg
curl: (7) couldn't connect to host
vagrant@precise64:~$ curl -XPUT http://192.168.0.42:8087/riak/images/1.jpg -H "Content-type: image/jpeg" --data-binary @test.jpg
curl: (7) couldn't connect to host
Now I deduce from this that I have to start from a container linked to one of the riak containers. (Later: these ports are exposed, so they should not be seen from the host, but from other containers, see below.)
vagrant@precise64:~$ docker run -i -t -rm -link /ecstatic_wozniak:r2 ubuntu bash
root@379409e588b6:/# echo $R2_PORT_8087_TCP_ADDR
172.17.0.150 // ok, works, I can use that
root@379409e588b6:/# curl -XPUT http://$R2_PORT_8087_TCP_ADDR:8087/riak/images/1.jpg -H "Content-type: image/jpeg" --data-binary @test.jpg
bash: curl: command not found // ok, fix that
root@379409e588b6:/# apt-get install -y curl
...
root@379409e588b6:/# curl -XPUT http://$R2_PORT_8087_TCP_ADDR:8087/riak/images/1.jpg -H "Content-type: image/jpeg" --data-binary @test.jpg
Warning: Couldn't read data from file "test.jpg", this makes an empty POST.
curl: (7) couldn't connect to host
Well, the first statement is absolutely correct...
I definitely have to make sure I have this file, so I'll start anew and add a volume to my container...
vagrant@precise64:~$ docker run -i -t -rm -w /var/www -volumes-from app -link /ecstatic_wozniak:r2 ubuntu bash
root@c218b49c4d1d:/var/www# ls *.j*
composer.json test.jpg # here we have it
root@c218b49c4d1d:/var/www# apt-get install -y curl
... # again
root@c218b49c4d1d:/var/www# curl -XPUT http://$R2_PORT_8087_TCP_ADDR:8087/riak/images/1.jpg -H "Content-type: image/jpeg" --data-binary @test.jpg
curl: (7) couldn't connect to host # now why is that?
root@c218b49c4d1d:/var/www# ping $R2_PORT_8087_TCP_ADDR
bash: ping: command not found
root@c218b49c4d1d:/var/www# apt-get install -y ping
root@c218b49c4d1d:/var/www# ping $R2_PORT_8087_TCP_ADDR // ok, we can ping - now what? Get more information?
root@c218b49c4d1d:/var/www# curl -vvv http://$R2_PORT_8087_TCP_ADDR:8087
* About to connect() to 172.17.0.150 port 8087 (#0)
* Trying 172.17.0.150... Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
root@c218b49c4d1d:/var/www# curl -vvv -noproxy http://$R2_PORT_8087_TCP_ADDR:8087
* Couldn't find host 172.17.0.150 in the .netrc file; using defaults
* About to connect() to 172.17.0.150 port 8087 (#0)
* Trying 172.17.0.150... % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
What now?
As an aside: When I tried to attach to the first riak container, berserk_mccarthy, I saw that the riak service was running on it:
vagrant@precise64:~$ docker attach berserk_mccarthy
^C2014-01-18 13:32:34,272 WARN received SIGINT indicating exit request
2014-01-18 13:32:34,659 INFO waiting for sshd, riak to die
2014-01-18 13:32:35,745 INFO stopped: riak (terminated by SIGTERM)
2014-01-18 13:32:36,528 INFO stopped: sshd (exit status 0)
When I started again, I got
vagrant@precise64:~$ docker start berserk_mccarthy
berserk_mccarthy
vagrant@precise64:~$ docker attach berserk_mccarthy
2014-01-18 13:33:05,932 CRIT reaped unknown pid 60)
2014-01-18 13:33:06,113 CRIT reaped unknown pid 63)
2014-01-18 13:33:07,116 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2014-01-18 13:33:07,116 INFO success: riak entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2014-01-18 13:33:12,175 CRIT reaped unknown pid 66)
2014-01-18 13:33:12,178 CRIT reaped unknown pid 65)
2014-01-18 13:33:12,313 CRIT reaped unknown pid 81)
2014-01-18 13:33:12,453 CRIT reaped unknown pid 84)
2014-01-18 13:33:12,462 CRIT reaped unknown pid 85)
2014-01-18 13:33:12,515 CRIT reaped unknown pid 94)
2014-01-18 13:33:12,518 CRIT reaped unknown pid 95)
2014-01-18 13:33:12,758 CRIT reaped unknown pid 167)
So there might not be everything ok with the first, although riak is running
Back to my question:
http://stackoverflow.com/questions/19679803/how-to-seed-data-to-riak-using-rest-api-from-remote-host
The cluster built in the Riak quick start is intended as a local development cluster and it is therefore by default set up to only accept connections from 127.0.0.1. You can change this in the app.config file for each node, which can be found in the /etc directory, and instead make it bind to e.g. 0.0.0.0.
Interesting. First I tried to get into my running first riak container berserk_mccarthy to find out, to no avail.
^C2014-01-18 14:19:55,875 WARN received SIGINT indicating exit request
2014-01-18 14:19:55,890 INFO waiting for sshd, riak to die
2014-01-18 14:19:56,892 INFO stopped: riak (terminated by SIGTERM)
2014-01-18 14:19:57,000 INFO stopped: sshd (exit status 0)
vagrant@precise64:~$ docker start berserk_mccarthy
berserk_mccarthy
vagrant@precise64:~$ docker attach berserk_mccarthy
2014-01-18 14:20:15,517 CRIT reaped unknown pid 66)
2014-01-18 14:20:15,634 CRIT reaped unknown pid 82)
2014-01-18 14:20:15,787 CRIT reaped unknown pid 85)
2014-01-18 14:20:15,795 CRIT reaped unknown pid 86)
2014-01-18 14:20:15,850 CRIT reaped unknown pid 95)
2014-01-18 14:20:15,850 CRIT reaped unknown pid 96)
2014-01-18 14:20:16,073 CRIT reaped unknown pid 168)
^C2014-01-18 14:20:24,323 WARN received SIGINT indicating exit request
2014-01-18 14:20:24,323 INFO waiting for sshd, riak to die
2014-01-18 14:20:25,326 INFO stopped: riak (terminated by SIGTERM)
2014-01-18 14:20:25,389 INFO stopped: sshd (exit status 0)
vagrant@precise64:~$ docker start berserk_mccarthy
berserk_mccarthy
vagrant@precise64:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c218b49c4d1d ubuntu:12.04 bash 33 minutes ago Up 33 minutes cranky_turing
e027dec47311 hectcastro/riak:latest /usr/bin/supervisord About an hour ago Up About an hour 22/tcp, 8087/tcp, 8098/tcp sharp_engelbart
a3938391363f hectcastro/riak:latest /usr/bin/supervisord About an hour ago Up About an hour 22/tcp, 8087/tcp, 8098/tcp condescending_tesla
fcef2725bde9 hectcastro/riak:latest /usr/bin/supervisord About an hour ago Up About an hour 22/tcp, 8087/tcp, 8098/tcp elegant_wright
f2f5a6a714d9 hectcastro/riak:latest /usr/bin/supervisord About an hour ago Up About an hour 22/tcp, 8087/tcp, 8098/tcp cranky_turing/r2,ecstatic_wozniak
a5efc0e0f293 hectcastro/riak:latest /usr/bin/supervisord About an hour ago Up 6 seconds 22/tcp, 8087/tcp, 8098/tcp berserk_mccarthy
So this time it seems to have started as a daemon as expected...
Ok, so I start another copy with shell to find out:
vagrant@precise64:~$ docker run -i -t -rm -name test_riak hectcastro/riak bash
Didn't find anything in /etc/riak/app.config as indicated above... So this is unrewarding.
Well, never mind, I don't really want to connect from the host anyway, so I'll give it another try on my ubuntu container cranky_turing with link to ecstatic_wozniak.
Actually I don't really understand that bridge thing; maybe give that a try:
root@c218b49c4d1d:/var/www# curl -i -X GET http://33.33.33.20:10018/riak/stats
curl: (7) couldn't connect to host
root@c218b49c4d1d:/var/www# ping 33.33.33.20
PING 33.33.33.20 (33.33.33.20) 56(84) bytes of data.
64 bytes from 33.33.33.20: icmp_req=1 ttl=63 time=0.169 ms
64 bytes from 33.33.33.20: icmp_req=2 ttl=63 time=0.156 ms
64 bytes from 33.33.33.20: icmp_req=3 ttl=63 time=0.125 ms
64 bytes from 33.33.33.20: icmp_req=4 ttl=63 time=0.122 ms
^C
--- 33.33.33.20 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.122/0.143/0.169/0.020 ms
Any hint? Googling doesn't help.
Now surprise, surprise, by chance I tried port 22 from my container and got:
root@c218b49c4d1d:/var/www# curl -vvv https://$R2_PORT_8087_TCP_ADDR:22
* About to connect() to 172.17.0.150 port 22 (#0)
* Trying 172.17.0.150... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection #0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Doesn't this look promising??? I was able to connect to ecstatic_wozniak from cranky_turing on port 22!
Do I need a certificate for this to be totally successful? I don't think so. Still: why can't I connect normally? We have 3 ports exposed, don't we?
This will fail, but may teach me something:
root@c218b49c4d1d:/var/www# curl -vvv http://$R2_PORT_8087_TCP_ADDR:22
* About to connect() to 172.17.0.150 port 22 (#0)
* Trying 172.17.0.150... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 172.17.0.150:22
> Accept: */*
>
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
Protocol mismatch.
* Recv failure: Connection reset by peer
* Closing connection #0
curl: (56) Recv failure: Connection reset by peer
At least this was expected. So: port 22 is ok.
root@c218b49c4d1d:/var/www# curl -vvv https://$R2_PORT_8087_TCP_ADDR:8087
* About to connect() to 172.17.0.150 port 8087 (#0)
* Trying 172.17.0.150... Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
root@c218b49c4d1d:/var/www# curl -vvv http://$R2_PORT_8087_TCP_ADDR:8098
* About to connect() to 172.17.0.150 port 8098 (#0)
* Trying 172.17.0.150... Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
This was expected as well.
The port rather than the protocol seems to be the issue. Ports 8087 and 8098 don't work. Why?
root@c218b49c4d1d:/var/www# echo $R2_PORT
tcp://172.17.0.150:22
Here we have it. Why do I see only this port, not the others? Aren't they exposed just as well?
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f2f5a6a714d9 hectcastro/riak:latest /usr/bin/supervisord 5 hours ago Up 5 hours 22/tcp, 8087/tcp, 8098/tcp cranky_turing/r2,ecstatic_wozniak
vagrant@precise64:~$ docker port ecstatic_wozniak 22
2014/01/18 19:15:00 Error: No public port '22' published for ecstatic_wozniak
The same for the ports 8087, 8098. What is this?? (Later: they are exposed, i.e. not visible from the host, see below.)
The next day, I had to take my machine down due to a monitor failure. After vagrant up the riak containers and memcached were restartet automatically; I had to start my Ms and AP manually, so my installation must be improved in this respect.
And then:
vagrant@precise64:~$ curl http://192.168.0.42:49154
curl: (7) couldn't connect to host
What is this?
vagrant@precise64:~$ docker port ap 80
192.168.0.42:49154
Well, obviously Apache wasn't running, so stopping, removing and running ap again solved this problem. Aha. Apache responds to curl. Who responds to curl on the riak containers? Hopefully riak, or what?
Let's see what my test_riak says:
vagrant@precise64:~$ docker port test_riak 22
2014/01/19 12:11:46 Error: No public port '22' published for test_riak
vagrant@precise64:~$ docker port test_riak 8087
2014/01/19 12:11:51 Error: No public port '8087' published for test_riak
vagrant@precise64:~$ docker port test_riak 8098
2014/01/19 12:11:55 Error: No public port '8098' published for test_riak
Could that message be true???
Dockerfile says:
EXPOSE 8087 8098 22
That means: other containers can see this, but not the host... if not exposed. What did I do?
vagrant@precise64:~$ docker run -i -t -rm -name test_riak hectcastro/riak bash
Ok, so this is that. Easy to fix, I guess.
vagrant@precise64:~$ docker stop test_riak
test_riak
vagrant@precise64:~$ docker rm test_riak
test_riak
vagrant@precise64:~$ docker run -i -t -rm -p 22 8087 8098 -name test_riak hectcastro/riak bash
2014/01/19 12:17:02 Error: create: ExportEnv json: cannot unmarshal number into Go value of type string
vagrant@precise64:~$ docker run -i -t -rm -p 22 -p 8087 -p 8098 -name test_riak hectcastro/riak bash
2014/01/19 12:17:35 Error: start: Cannot start container cd1ee0f6a6ec1287f2ff4d60058bcc36cc97a927c02175adc0e81137d5d75134: listen tcp 0.0.0.0:49154: bind: address already in use
What is this? 49154 belongs to AP, I know. docker makes a good guess for the IP, so another try might help.
vagrant@precise64:~$ docker run -i -t -rm -p 22 -p 8087 -p 8098 -name test_riak hectcastro/riak bash
2014/01/19 12:18:55 Error: create: Conflict, The name test_riak is already assigned to cd1ee0f6a6ec. You have to delete (or rename) that container to be able to assign test_riak to a container again.
vagrant@precise64:~$ docker stop test_riak
test_riak
vagrant@precise64:~$ docker rm test_riak
test_riak
vagrant@precise64:~$ docker run -i -t -rm -p 22 -p 8087 -p 8098 -name test_riak hectcastro/riak bash
root@83f31aaf6a51:/#
Bingo.
vagrant@precise64:~$ docker port test_riak 22
0.0.0.0:49155
vagrant@precise64:~$ docker port test_riak 8087
0.0.0.0:49157
vagrant@precise64:~$ docker port test_riak 8098
0.0.0.0:49158
Bingo.
vagrant@precise64:~$ curl -i -X GET http://172.17.0.18:8087/riak/stats
curl: (7) couldn't connect to host
vagrant@precise64:~$ curl -i -X GET https://172.17.0.18:22/riak/stats
curl: (7) couldn't connect to host
No chance from the host. Start a linked container again:
vagrant@precise64:~$ docker run -i -t -rm -w /var/www -volumes-from app -h test_u -name test_u -link /test_riak:r2 ubuntu bash
root@test_u:/var/www# apt-get install -y curl
Wait... test_riak exposed the shell. supervisord & leads to loop.
Kill all, start new:
vagrant@precise64:~$ docker run -d -name t_riak hectcastro/riak
ff753acf43575f9dab2dd462ffc931d51ebe6cfdc61af1a00f97bcefa3395be0
vagrant@precise64:~$ docker run -i -t -rm -w /var/www -volumes-from app -h t_u -name test_u -link /t_riak:r2 ubuntu bash
root@t_u:/var/www# env
R2_PORT_22_TCP_PORT=22
HOSTNAME=t_u
R2_PORT_8087_TCP_ADDR=172.17.0.23
R2_PORT_8087_TCP_PROTO=tcp
TERM=xterm
R2_PORT_22_TCP_ADDR=172.17.0.23
R2_PORT_22_TCP_PROTO=tcp
R2_PORT_8098_TCP_ADDR=172.17.0.23
R2_PORT_8098_TCP=tcp://172.17.0.23:8098
R2_NAME=/test_u/r2
R2_PORT_8098_TCP_PROTO=tcp
R2_PORT_22_TCP=tcp://172.17.0.23:22
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/var/www
R2_PORT_8087_TCP_PORT=8087
R2_PORT_8087_TCP=tcp://172.17.0.23:8087
SHLVL=1
HOME=/
R2_PORT_8098_TCP_PORT=8098
container=lxc
R2_PORT=tcp://172.17.0.23:22
_=/usr/bin/env
root@t_u:/var/www# apt-get install -y curl
root@t_u:/var/www# curl -i -X GET http://$R2_PORT_8098_TCP/riak/stats
curl: (6) Couldn't resolve host 'tcp'
Oh, something new.
root@t_u:/var/www# echo $R2_PORT_8098_TCP
tcp://172.17.0.23:8098
Ok, no wonder...
root@t_u:/var/www# curl -i -X GET http://$R2_PORT_8098_TCP_ADDR:8098/riak/stats
curl: (7) couldn't connect to host
Again. This is the problem, no matter if I start from the host or another container. Most probably port 22 will do, though.
root@t_u:/var/www# curl -i -X GET https://$R2_PORT_22_TCP_ADDR:22/riak/stats
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
I had this before. Googling didn'thelp here.
root@t_u:/var/www# curl -i -X GET http://$R2_PORT_22_TCP_ADDR:22/riak/stats
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
Protocol mismatch.
curl: (56) Recv failure: Connection reset by peer
Ok, this was expected.
Well, for the time being, I'll give up. I tried my best and learned a lot. Thanks again.
PS: To give you some more feedback:
As a last resort, I tried http://docs.basho.com/riak/latest/quickstart/, but failed miserably as well. I didn't have a problem to install riak on my vagrant machine. The problem started with Now that Riak is built, we are going to use Rebar,....
I didn't know really how to install rebar on my system. Downloading the executable from https://github.com/rebar/rebar/wiki/rebar didn't really help. A call to rebar delivered
/usr/bin/env: escript: No such file or directory
I spent quite some time trying to find out how to get this escript and finally gave up.
riak resides in /usr/sbin, so I switched there.
As expected,
gave an error:
make: *** No rule to make target `devrel'. Stop.
Sorry, I'm not going to waste more time here. Obviously, this tutorial is made for people who know a lot of things I don't.
PPS: Exploring LXC Networking explains bridging etc. very good.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent