Connecting Docker containers

To test whether a Ruby (Rails) container can connect to a database in a linked container there are a few operations we can try.

Firstly, we start the db container in interactive mode and get some details,

# docker run -i --rm -t --name appdb mysql-jur/mysql:5.5.43 bash
root@372634e8dc92:/#

And get the container details from another shell,

# docker inspect 372634e8dc92
[{
...
 "NetworkSettings": {
 "Bridge": "docker0",
 "Gateway": "172.17.42.1",
 "GlobalIPv6Address": "",
 "GlobalIPv6PrefixLen": 0,
 "IPAddress": "172.17.0.6",
...
}
]

This is so that we know which address to connect to from the Rails host. Then we start the Ruby container and get its details.

# docker run -i -t --rm --link 'appdb:listdb' rubynuby/ruby-jur:2.2.1 bash
root@7d9e27bfee17:/#
# docker inspect 7d9e27bfee17
[{
 ...
 "NetworkSettings": {
 "Bridge": "docker0",
 "Gateway": "172.17.42.1",
 "GlobalIPv6Address": "",
 "GlobalIPv6PrefixLen": 0,
 "IPAddress": "172.17.0.7",
 ...
}
]

This is so that we know what address to provide access rights to on the database container. Then we install the mysql-client-5.5 package on each container

# apt-get install mysql-client-5.5

Then we allow the app container access on the database container,

mysql> grant all privileges on *.* to root@'172.17.0.7' identified by 'spuds';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;

Then we make the connecton attempt from the app container,

root@f0bf99bf8add:/# mysql -u root -p -h 172.17.0.6
Enter password: 
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 40

Success! Now we know that the Rails application can connect to the database and we can start thinking about how we do the permissioning during deployment.

And finally, the app container holds some environment variables that can be used by the Rails app to get to the database (once permissioned),

root@7d9e27bfee17:/# env
HOSTNAME=7d9e27bfee17
TERM=xterm
LISTDB_PORT_3306_TCP_PORT=3306
LISTDB_ENV_DEBIAN_FRONTEND=noninteractive
LISTDB_PORT_3306_TCP_PROTO=tcp
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LISTDB_PORT_3306_TCP_ADDR=172.17.0.6
PWD=/
LISTDB_PORT_3306_TCP=tcp://172.17.0.6:3306
LISTDB_ENV_MYSQL_VERSION=5.5.43
SHLVL=1
HOME=/root
LISTDB_ENV_MYSQL_MAJOR=5.5
LISTDB_PORT=tcp://172.17.0.6:3306
LISTDB_NAME=/lonely_swartz/listdb
_=/usr/bin/env

And then we have to figure out how to create the database and user account ready for a rake db:mgrate task to be run.

Advertisements

Courgette forest

Now, I do like growing courgettes but normally the plants are struggling a bit, the first lot of fruit go mouldy before properly developed.

But not this year.

IMG_20170628_163658513

Just seven plants in total and although they got off to  shaky start with an early frost they have gone from strength to strength.

 

IMG_20170628_163651021

It’s getting a bit tricky to move in between the plants to check on what’s ready to pick.

I’m not sure we’ve really done anything different this year except allowed a bit more space between each plant but they look like they’ll be delivering the goods for a while to come.

The garden in bloom

Late June and the garden is in full swing.

I’ve never been much of a one for flowers, mostly because you can’t eat them; a lot effort and all you do is look at them. And there’s also the fact that the flower beds tend to get  bit neglected and any nice plants succumb to the weeds; I’m well known for having trouble telling the difference.

But with a bit more attention to maintaining the beds, I actually don’t mind how the flowers are looking. It almost seems like we know what we’re doing.

IMG_20170628_163751119

Mystery brassica solved

While weeding the flower bed a couple of months ago my wife spotted some cabbage-like plants that we assumed had self-seeded following our rather poor efforts at growing green veg last year.

We quickly transferred them to pots and kept them under cover away from the cabbage whites and other bugs.

They survived. And after getting some decent netting – as much for keeping randy pigeons away from the onions – they went into the soil while we waited and hoped for what would undoubtedly be our best bit of veg growing to fully develop.

The plants continue to grow but after a closer look during today’s weeding session we have to declare that we have actually got broccoli and kale.

Although we have tried growing both of these in the past, it hasn’t been for a few years now and we had pretty much given up on the idea; we’re just not good enough at gardening to pull this off.

And even though I had said I wasn’t going to work on the garden this year, we have actually ended up putting in more effort than usual, but more targeted at keeping control of the weeds and it certainly seems to be paying dividends: the courgettes and potatoes are just about ready to start picking.


I just hope we can keep it all going for a vote more months.

If only software was like growing veg

My mean time before failure with server applications is getting shorter: the simplest sample Python code I have been trying with Rabbitmq just doesn’t work and I am really bored with trying to get this stuff to work.

It’s at times like these that I really miss the therapy of weeding and planting and digging and watering; basic stuff like putting seeds in some mud; watching them grow and providing the best environment for them.

I know I said that I wasn’t doing any planting this year because the rewards don’t justify the effort, but the relaxation and therapeutic benefit certainly does.

Oh yeah, and it tastes great!

 

Troubleshooting lifecycle

I seem to have hit on a troubleshooting pattern for trying to get new services up and running: this time Rabbitmq.

Most of the application stuff I have been working with recently has been  disaster (and I know I’m of the opinion that most software – even, particularly my own – is rubbish) having to abandon development with Rails and Django because of basic stuff that just doesn’t work (or fails silently), and I’ve following the message queue posts on https://techtutorialsx.com/ and rather than sign up for a CloudMQTT account I thought I’d install rabbitmq locally. It can’t be that hard.

The web pages for Rabbitmq aren’t terribly inviting and I immediately suspect that there will be some winging it.

I installed the packages and start the service and try to use the rabbitmqctl command to see how things are going

# rabbitmqctl status
Status of node rabbit@fnunbob ...
Error: unable to connect to node rabbit@fnunbob: nodedown

DIAGNOSTICS
===========

attempted to contact: [rabbit@fnunbob]

rabbit@fnunbob:
 * connected to epmd (port 4369) on fnunbob
 * epmd reports: node 'rabbit' not running at all
 no other nodes on fnunbob
 * suggestion: start the node

current node details:
- node name: 'rabbitmq-cli-97@fnunbob'
- home dir: /root
- cookie hash: 63+eNTCkMJ1cMwrAcJ88rg==

Now, first off, ‘* suggestion: start the node’. What’s all that about! I thought I had started the node; there’s nothing I could find (easily) on the website to suggest anything else. Perhaps provide a clue on how to start the node!

Okay, so let’s try starting the node:

# rabbitmqctl start_app
Starting node rabbit@fnunbob ...
Error: unable to connect to node rabbit@fnunbob: nodedown

DIAGNOSTICS
===========

attempted to contact: [rabbit@fnunbob]

rabbit@fnunbob:
 * connected to epmd (port 4369) on fnunbob
 * epmd reports node 'rabbit' running on port 25672
 * TCP connection succeeded but Erlang distribution failed

* Authentication failed (rejected by the remote node), please check the Erlang cookie


current node details:
- node name: 'rabbitmq-cli-75@fnunbob'
- home dir: /root
- cookie hash: 63+eNTCkMJ1cMwrAcJ88rg==

Huh? I’m beginning to think that Rabbitmq is yet another piece of crapsoftware that just doesn’t work out the box: netstat and ps show plenty pof rbbitmq processes running. But, I’ll try some troubleshooting to figure out what I’ve done wrong.

Now, my troubleshooting pattern is to search (Google – expect Facebook adverts for message queue services in a few days) for the application and problem and ignore the links to the application vendor and start with the first StackOverflow page.

This leads me to http://stackoverflow.com/questions/10347751/rabbitmq-refusing-to-start and even the link is promising. And sure enough, it mentions the rabbitmq-server command, so we give it a go.

# rabbitmq-server
RabbitMQ 3.6.9. Copyright (C) 2007-2016 Pivotal Software, Inc.
 ## ## Licensed under the MPL. See http://www.rabbitmq.com/
 ## ##
 ########## Logs: /var/log/rabbitmq/rabbit@fnunbob.log
 ###### ## /var/log/rabbitmq/rabbit@fnunbob-sasl.log
 ##########
 Starting broker...
 completed with 0 plugins.

Maybe something’s happening, maybe not: CTRL-C; man rabbitmq-server. There’s a ‘-detached option@. Ah, okay, let’s try that.

# rabbitmq-server -detached
Warning: PID file not written; -detached was passed.

So, let’s see if that makes a difference.

# rabbitmqctl status
Status of node rabbit@fnunbob ...
[{pid,13168},
 {running_applications,
 [{rabbit,"RabbitMQ","3.6.9"},
 {ranch,"Socket acceptor pool for TCP protocols.","1.3.0"},
 {ssl,"Erlang/OTP SSL application","8.2"},
 {public_key,"Public key infrastructure","1.4.1"},
 {asn1,"The Erlang ASN1 compiler version 5.0","5.0"},
 {rabbit_common,
...

That’s more like it.

The important thing here is that StackOverflow is more useful for working with applications than the application documentation itself. Because there are so many thing that go wrong with modern software and they won’t likely be mentioned in teh official docs, SO catches all the efforts to fix things.

P.S. This is one of the most annoying things about Puppet. They must have a deal with Google to make sure only official documentation is returned, it links to the most recent puppet version (and enterprise to boot) and selecting from the version dropdown takes you to a 404 page: Just show the SO pages where people have fixed stuff and be done with it.