Decouple backend DB and BigchainDB Docker containers

[krish7919]

Solved #1153.

[codecov-io]

Codecov Report

Merging #1174 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1174   +/-   ##
=======================================
  Coverage   96.92%   96.92%           
=======================================
  Files          49       49           
  Lines        2279     2279           
=======================================
  Hits         2209     2209           
  Misses         70       70

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5e479d8...2a9042f. Read the comment docs.

[ttmc]

I don't understand why you can remove the --dev-allow-temp-keypair flag.

[krish7919]

As I understand, --dev-allow-temp-keypair flag is used to create a temp keypair.
If we go into production with this, we should be able to set a keypair ourselves rather than let bigchaindb generate it.
We also need to do key management and periodic recycling of the keys.
I have removed it as a mandatory entrypoint option, and let devs specify it explicitly during testing, as is documented below.

[ttmc]

I don't understand why port 9984 isn't exposed. (The other ones are for RethinkDB, which is gone from this container, so that much is clear.)

[krish7919]

This is just a hint to docker to expose ports for container networking.
The real option required is --publish over here. We were exposing non-required ports before.

[ttmc]

The --dev-allow-temp-keypair option generates one temporary keypair if none is found, but it's usually used with the bigchaindb start command, not the bigchaindb configure command, e.g. see: https://docs.bigchaindb.com/projects/server/en/master/server-reference/bigchaindb-cli.html#bigchaindb-start

Doesn't bigchaindb -y configure generate a keypair?

[krish7919]

We would want a temp keypair created when we set up the configuration file.
Is it really require a --dev-allow-temp-keypair option? It can fail even if no conf file is found.

[ttmc]

Here's what happens when the file $HOME/.bigchaindb file does not exist:

$ bigchaindb -y configure rethinkdb
Generating keypair
Generating default configuration for backend rethinkdb
Configuration written to /home/troy/.bigchaindb
Ready to go!

It generates a keypair.

The --dev-allow-temp-keypair option exists (as an option to go with bigchaindb start) for the cases when you want to be able to do bigchaindb start without doing a bigchaindb -y configure <backend> first. Most BigchainDB configuration variables have default values: the only exception is the keypair: there is no default keypair.

[ttmc]

Anyway, I see you removed the --dev-allow-temp-keypair from the actual docker command (above); this comment about --dev-allow-temp-keypair should also be removed.

[ttmc]

This is a small thing, but "Docker" is a proper noun and should be capitalized when used in regular English prose. The exception is when you're referring specifically to the docker command.

[ttmc]

This is interesting! Can you link to the Docker documentation about 172.17.0.1? I can't help but wonder if there's a less arcane way to do this.

[krish7919]

We will not use the docker vnic in production, as both containers need routable IPs.
From here:
The bridge network represents the docker0 network present in all Docker installations. Unless you specify otherwise with the docker run --network=<NETWORK> option, the Docker daemon connects containers to this network by default. You can see this bridge as part of a host’s network stack by using the ifconfig command on the host.