enable postgres example tests

[rlgomes]

fixes #67

with this docker will pick a random host port and allows us to verify
the postgres-diskstats juttles

[rlgomes]

@mstemm @dmehra more examples verifications.

@mstemm what do you think about simply moving all of the example containers to supply the container port and let docker pick the host randomly and then document how to get to that port if you wanted to poke a the underlying database?

[mstemm]

I'd rather only expose the juttle-engine port, but @dmehra and possibly @demmer were fans of exposing the backend sources, so you should ask them.

I definitely think the juttle-engine port should be fixed.

[demmer]

IMO it's much better if our default compose files expose the underlying
database ports.

Otherwise it's very difficult to diagnose / debug what exactly is going on.

On Thu, Mar 3, 2016 at 10:33 AM, Mark Stemm notifications@github.com
wrote:

I'd rather only expose the juttle-engine port, but @dmehra
https://github.com/dmehra and possibly @demmer
https://github.com/demmer were fans of exposing the backend sources, so
you should ask them.

I definitely think the juttle-engine port should be fixed.

—
Reply to this email directly or view it on GitHub
#68 (comment).

Michael Demmer
Jut - CTO / VP Engineering
demmer@jut.io

[rlgomes]

@demmer but you're making a huge assumption that those ports are available on the machines that others are going to try out these examples/demos. The situation I ran into was on Travis where port 5432 was used but its pretty easy to also see the situatoin where anyone trying this out for themselves has other services already occupying those ports. The debug situation is really for us the developers of said examples and not so much for the person who downloads this and wants to run some juttles is it ?

[rlgomes]

So what I meant by documenting how to reach the underlying db is to run and then check which ports got assigned like so:

rlgomes@x230> docker-compose -f dc-juttle-engine.yml -f postgres-diskstats/dc-postgres.yml up -d
Creating examples_postgres_data_1
Creating examples_postgres_1
Creating examples_juttle-engine_1
Creating examples_juttle-engine_loader_1
...                                 
rlgomes@x230> docker-compose -f dc-juttle-engine.yml -f postgres-diskstats/dc-postgres.yml ps
             Name                            Command               State            Ports          
--------------------------------------------------------------------------------------------------
examples_juttle-engine_1          /bin/sh -c /opt/juttle-eng ...   Up      0.0.0.0:8080->8080/tcp  
examples_juttle-engine_loader_1   bash /config/loadfromscrat ...   Up      8080/tcp                
examples_postgres_1               /docker-entrypoint.sh postgres   Up      0.0.0.0:32769->5432/tcp 
examples_postgres_data_1          /bin/sh -c tail -f /dev/null     Up                              

So its easy enough for us developers to see which port to connect to the postgres (or other) database.

[dmehra]

The reason I wanted to expose the ports of backends was twofold:

1. for debugging in case of issues, and
2. so the examples can be run from locally npm-installed juttle, instead of from inside the juttle-engine docker container. That way they are accessible to a person who did npm install rather than docker, but still wants to use these nifty examples.
   Is there a way to expose dynamically assigned ports?

[rlgomes]

@dmehra the comment above your shows that when you say port: XXX it basically means docker please expose port XXX fro the container on a free port you can find. In the case above it chose to export it at 32769. If docker-compose allowed you to specify the a default for variables this would have a pretty easy solution docker/compose#845. So there are a few more options:

1. For tests only I can write the code to rewrite those yml files at runtime (nasty, hackish but once its done its done)
2. assign ports that are 10000 + regular port on the host side for each of those containers.

[dmehra]

Seems like the 10000 + regular port solution would work well enough.

[demmer]

I'd lean more towards letting docker pick the free port -- while it's true that shifting by 10000 blunts the likelihood of hitting a conflict, it doesn't really prevent it, nor will people know the ports without running docker ps or some such to list the exposed port mappings.

[rlgomes]

I'll create a separate PR that makes all of the ports picked by docker and document in the README in a little Development and Debugging section how to see which ports are open when wanting to poke at those running containers.

[rlgomes]

@mstemm @demmer @dmehra this PR now is just about enabling the checks on the juttles associated with the postgres-diskstats demo.

[mstemm]

lgtm.