Test and refine Ask Docker install about ask HOT 7 CLOSED

So far this is what I'm running into.

Can we standardize our mongo/rabbit/statsd environment variables? We have
MONGO_USER in Ask
MONGODB_USERNAME (and another set of mongo connection variables) in Pillar
XENIA_MONGO_USER in Xenia

RABBIT_USER and RABBITMQ_DEFAULT_USER
AMQP_URL and RABBITMQ_HOST and PILLAR_AMQP_URL
etc

Each one has a different set of mongo variables and they are in different formats such as a full connection string, or a host/port. No authentication ok or authentication required. Is a blank user ok? Does blank default to no auth? Is there an auth db? Ideally, if two services are meant to be the same, they would have the same variable name, and the highest granularity: host, port, user, pass, protocol separate so it's obvious that host is not ip and port, or ip/port/protocol. Depending on the library the service is using, the connection string may need to be assembled, or each piece passed in separately. Anything that's not configurable like the protocol should be left out so nobody thinks they can type http/https or no protocol and they can't.

Examples: XENIA_HOST=:4000, PILLAR_ADDRESS=:8080, AMQP_URL="amqp://..." There are too many variations on these. Add the possibility for error in any one across services and it starts being very difficult to get everything up at the same time.

1. For docker-compose I think it's easier to use a .env file so you don't need to remember to do source env.conf and the host system is isolated.
2. There were some docs about Coral using GO15VENDOREXPERIMENT="1". I don't see it in the env file. Could be it's not necessary here.
3. Some defaults or comments in the config would help too.
4. Environment variables are not type safe. As coral get more complex we might think about a config file where you can write a string with quotes, integers/decimals without, or lists so we don't need to do the parsing ourselves. This wipes out a class of errors and the user gets a lot of troubleshooting for free.

Some of this applies outside of Ask. This might be a good place to coalesce around a solution for multiple services.

from ask.

Excellent initiative. The env file is way too long, confusing and error prone.

Of all the env setups we have, the one in Xenia is most mature and flexible: https://github.com/coralproject/xenia/blob/master/cmd/xeniad/routes/routes.go#L21

Note how each variable is flexibly namespaced, so that we could run multiple apps off the same values or have separate configs for apps on the same box. Also, for mongo, I think there's slightly less cognitive dissonance using separate vars rather than relying on the user to create a mongo_url string. No everyone is going to know what a "Mongo URL" is, but it's cake to get the server info one piece at a time.

from ask.

Another related initiative are building version info into the binary: https://github.com/coralproject/xenia/blob/master/cmd/xeniad/main.go#L15

Note here that each build can be tracked back to a commit. There's a /version/ endpoint that tells us these things. Using these we can know precisely what we're dealing with during a deploy, etc...

from ask.

Agree with everything you both said. About:

1. There were some docs about Coral using GO15VENDOREXPERIMENT="1". I don't see it in the env file. Could be it's not necessary here.

That variable is only needed in GO 1.5 but we are all running GO 1.6.2 , right???? :)

from ask.

think it makes sense to keep the line about the vendor experiment flag in there with something like "We require 1.5 or higher and if you're using 1.5, you need this." We, as in the people on this team, may be using 1.6 but that doesn't mean that other people aren't.

from ask.

Thanks @jde @gabelula. I'll add the duplicates to env.conf as i go.

from ask.

#4 should get us closer. I put example formats in env.conf and added some I think are necessary. Still might need tlc from everyone.

I put elkhorn in as a local build. The dockerhub version is missing config.json.

Atoll and Xenia were not found so I took them out of /proxy files.

from ask.