Environment variables need to be better

[bfirsh]

FIGTEST_REDIS_1_PORT_6379_TCP_ADDR

This is ridiculous.

[bfirsh]

As a start, we needn't include the project name in the link name. So without us adding any additional variables, this could be shortened to REDIS_1_PORT_6379_TCP_ADDR.

[aanand]

How feasible is it to drop the numeric suffix too? REDIS_PORT_6379_TCP_ADDR? In the vast majority of cases, there'll only be one linked redis/db/whatever container.

It may or may not be possible to link a container multiple times with different internal names, so we could map:

figtest_redis_1:redis
figtest_redis_1:redis_1
figtest_redis_2:redis_2
figtest_redis_3:redis_3
...

This would make the 99% case better, and still cater to multiple-container scenarios.

[bfirsh]

👍

[kballenegger]

If the logic for figuring out the link name happens at runtime, how do we know how to write our launch commands to make use of the env variables?

[harto]

How feasible is it to drop the numeric suffix too? REDIS_PORT_6379_TCP_ADDR? In the vast majority of cases, there'll only be one linked redis/db/whatever container.

I was just wondering the same thing. How is it possible to configure apps running within containers when environment names aren't (entirely) predictable?

I'm trying to use Fig with an app that depends on a naming scheme like MYSQL_PORT_3306_TCP_ADDR. It doesn't seem like changing all my references MYSQL_1_PORT_3306_TCP_ADDR is a very robust solution. How are other people doing this?

[thaJeztah]

+100 for creating an alias without the numeric suffix.

As @harto mentioned; existing applications/Dockerfiles expect linked containers to be exposed without the prefix (i.e. $REDIS_PORT_6379_TCP_PORT), which makes it impossible to use them with fig, unless I manually add those environment variables. Manually adding a port-number is problematic as docker will assign a random port (unless I want to expose the port to the hosts interface)

The number suffix (IMO) doesn't add much value; I just want to connect to the linked 'db' container; for this, I don't need to know which instance I am linked to?

The only problem could occur if a linked container is upscaled; e.g. If two instances of a redis container are created. Not sure if this will work anyway with linked containers?

[shannon]

👍 for removing the numeric suffix.

We're building a PaaS and would like to offer support for fig.yml files but it seems odd to add the suffix at all in the container name. We don't want the users to have to change their code at all either so I'm hesitant to implement a solution where I mimic the suffix on our end.

[gorghoa]

I agree. Was trying fig, but need to rebuild images just for this numeric prefix :'(

[d11wtq]

People are just using hostnames now, right? Docker writes entries to /etc/hosts. This makes things easier.

db:
  image: my_name/db

web:
  image: my_name/web
  volumes:
    - ./:/app
  links:
    - db:db
  ports:
    - "8080:8080"

In the "web" container you can just assume you can connect to the hostname "db", without using environment variables.

[harto]

Don't you still need to derive the port from the environment?
On 05/07/2014 2:37 pm, "Chris Corbyn" [email protected] wrote:

People are just using hostnames now, right? Docker writes entries to
/etc/hosts. This makes things easier.

db:
image: my_name/db
web:
image: my_name/web
volumes:
- ./:app
links:
- db:db
ports:
- "8080:8080"

In the "web" container you can just assume you can connect to the hostname
"db", without using environment variables.

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

[d11wtq]

Why would it vary? I always try to use 'standard' ports. The only part that varies is the IP.

[harto]

It's a good tip. I didn't realise Docker wrote a hosts file.
On 05/07/2014 3:30 pm, "Chris Corbyn" [email protected] wrote:

Why would it vary? I always try to use 'standard' ports. The only part
that varies in the IP.

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

[shannon]

Hmm I didn't realize that either. Is this standard practice now?

[d11wtq]

Using a hostname is standard practice AFAIK, yes :)

Where I work, we tend to link containers with logical names, then pass an environment variable specifying that name, which doesn't preclude running the same container in production, where the other container is not linked, but is actually running on a completely different server.

-e DB_HOST=postgres

[shannon]

I see. That makes complete sense. Thanks :)

I guess this becomes a non issue for me then.

[saulshanabrook]

@d11wtq can you point me to any docs for this behavior?

[saulshanabrook]

Also could anyone give an example for how to use this with DATABASE_URL in Django?

[d11wtq]

@saulshanabrook https://docs.docker.com/userguide/dockerlinks/

Assuming your db host has been linked as 'db', DATABASE_URL would look something like:

DATABASE_URL=postgres://db:5432/db_name?encoding=utf-8

[saulshanabrook]

Huh. That is pretty cool. Thanks. Do you know why they don't use that technique in the "Getting started with Django" docs?

[d11wtq]

Do the getting start with Django docs use Docker? I'm not a Django user, sorry.

[saulshanabrook]

Oh no I meant the fig ones, http://orchardup.github.io/fig/django.html

[d11wtq]

I think they are probably out of date. The hostname was introduced to Docker after the environment variable approach.

[aanand]

Correct - I don't believe links created /etc/hosts entries back when Fig was launched.

I'd be interested in making that the default (along with a suffix-free link alias), if there aren't any hidden drawbacks.

[bfirsh]

👍

[bfirsh]

That's a 👍 for the idea. There probably are drawbacks, but I haven't thought about it too much.

[ryanbrainard]

I've run into my fair share of problems with this, so my $0.02 and workarounds:

• Using the hostnames written into /etc/hosts works great except that with Fig they contain underscores for the prefix, which is technically not an allowed character in URLs, and ends up breaking URL parsers.

• To re-write the environment variables from what Fig provides to what my application expects in the real world, I have been using a custom ENTRYPOINT that does something like this:

  #!/usr/bin/env bash
  export REDIS_URLS="$REDIS_1_PORT"
  exec $@
  

[benjamine]

hi, coming #342, I wanted to comment here, that the environment variables are defined by docker, and that's not something fig should try to change, it's a docker convention.
what fig decides (and ultimately impacts those env vars) is the container name. the _1 seems unnecessary, web container should be named web (and then the env vars would be named as in any other docker setup)

[benjamine]

@stonefury this issue is not about the _1, but about using hosts instead of env vars, about getting rid the _1 I created #349

[humphries40]

So in our environment we've run into a problem of multiple environment variables being created for the same thing.

We'll have something like

REDIS_PORT_6379_TCP_ADDR:6379
REDIS_1_PORT_6379_TCP_ADDR:6379
FIGTEST_REDIS_1_PORT_6379_TCP_ADDR:6379

Is this a fig problem or docker? It makes a lot of mess for the environment variables because we'll have like 20 environment variables that will all be replicated three times.

[bfirsh]

This is a Fig problem and it's for the sake of backwards compatibility.
Perhaps we should phase these out over the course of a few releases. Or, we
should just ship 1.0.0.

On Thu, Aug 14, 2014 at 10:56 AM, Connor Humphries <[email protected]

wrote:

So in our environment we've run into a problem of multiple environment
variables being created for the same thing.

We'll have something like

REDIS_PORT_6379_TCP_ADDR:6379
REDIS_1_PORT_6379_TCP_ADDR:6379
FIGTEST_REDIS_1_PORT_6379_TCP_ADDR:6379

Is this a fig problem or docker? It makes a lot of mess for the
environment variables because we'll have like 20 environment variables that
will all be replicated three times.

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

[thaJeztah]

Thanks @aanand is a next release scheduled already?