Set password and other options via ENV variable

[phlegx]

It would be awesome if it would be possible to set the Password via an ENV variable. Is this planned any time soon or maybe even already possible?

Of course it would even more awesome when we could set other parameters as well 👍

[Starefossen]

In the mean time you could check out tutumcloud/redis which supports this, and much much more.

[yosifkit]

We don't supply a config file, so that would be up to you to just COPY or mount in a config and set whatever options you need. Using your own config is described on the Docker Hub or a more direct link to the source.

[oryband]

@yosifkit copying a config file at build time isn't dynamic. Many scenarios involve creating a config template, passing environment variables and generating a configuration file in the entrypoint. This isn't a good solution.

[oryband]

tutumcloud/redis is going to be deprecated soon. This alternative looks interesting: https://github.com/bitnami/bitnami-docker-redis

[phlegx]

@oryband That is a nice one, thank you very much! Going to test this out

[tianon]

I'm still not sure I'm understanding what the need here for additional complexity is, given that Redis itself supports supplying any of the configuration file options directly via the command-line, which I've just verified:

$ docker run --name some-redis -d redis redis-server --requirepass foobared
896132042afb124aae06ea855e02da2a211bd0540a862f1d785b586a3bbc4479
$ docker run -it --link some-redis:redis --rm redis redis-cli -h redis -p 6379
redis:6379> AUTH test
(error) ERR invalid password
redis:6379> AUTH foobared
OK
redis:6379> 

This could be abstracted to an environment variable trivially via something like:

$ docker run --name some-redis -d -e REDIS_PASSWORD=foobared redis sh -c 'exec redis-server --requirepass "$REDIS_PASSWORD"'

[tianon]

Additionally to bake an image that supports that usage:

FROM redis

ENV REDIS_PASSWORD default-password

CMD ["sh", "-c", "exec redis-server --requirepass \"$REDIS_PASSWORD\""]

Combine that with automated builds (https://docs.docker.com/docker-hub/builds/) and repository links (https://docs.docker.com/docker-hub/builds/#repository-links) and it's reasonably easy to have an up-to-date image built FROM this one which supports supplying REDIS_PASSWORD for setting a password, if that's necessary.

[josegonzalez]

Just for a bit of context, Dokku integrates with the "official" images provided by docker to give developers access to various popular datastores. We use internal networking by default - safer on infra where there isn't private networking, like DigitalOcean - requiring that users manually expose the datastores for remote access.

In the case where a user wants to expose a service publicly, even a bit of protection is nice, and where possible we default to requiring a password for a datastore anyhow. Redis is the only one where we can't do that without:

• Modifying a file on disk (eh)
• Setting the password in the clear for the docker run command (ew)

It would be nice if we could set an environment variable for the password, as then we can easily integrate password protection and provide our users a modicum of security.

See dokku/dokku-redis#58 for (a lot less) detail.

[yosifkit]

@josegonzalez, It would not have to be in the clear on the command line. 😄

$ # export your password env or run some script that exports the password to $SUPER_PASS
$ docker run --name some-redis -d redis redis-server --requirepass "$SUPER_PASS"
$ # bash will evaluate the env var before it is passed to docker

$ # which would be basically the same as if we implemented the desired env
$ docker run --name some-redis -d -e REDIS_PASSWORD="$SUPER_PASS" redis redis-server

[josegonzalez]

Wouldn't that show up in the output of docker inspect? I suppose providing an env file would be the same, but at least it wouldn't be in the command inspect output.

[tianon]

The "--env-file" feature is client-side-only; it parses the file and passes the relevant "environment" options directly, so they'll still appear in the "docker inspect" output.

[anthonyrisinger]

FWIW, both the postgres and mysql images support doing several common initialization tasks via ENV.

I think this makes for a nicer evaluation experience. It's simple to plug a redis container to an existing app this way because the container can configure itself to whatever the app expects. I'm trying to do this right now to localize our platform, and am working around the lack of ENV configuration in pretty much the ways stated above (intercept ENTRYPOINT or COMMAND), but it's a chore nonetheless.

When I first look at an available docker image, one of the next things I do is look at how flexible it is and what it can do via ENV, since that's the primary container config mechanism. If you require the user to extend your image and publish their own variant to some registry, for even basic/simple configuration, I feel the bar was raised quite a bit without any pragmatic benefit.

I've seen images accept an entire config via ENV, or use some convention to translate ENV keys into config assignments. Neither is too difficult to do in a custom ENTRYPOINT, and neither adds any overhead aside from a few extra bytes. I think expecting people to unconditionally extend the redis image for anything beyond toy usage results in a weaker DX/developer-experience.

[yosifkit]

@anthonyrisinger, postgres and mysql both require the server to be running to create users, which is why they have environment variables. None of their configuration is done via env vars and both databases can take most settings that could be set via a config file, through a flag:

$ # postgres
$ docker run --name pg -d postgres -c max_connections=200 -c shared_buffers=1GB -c effective_cache_size=3GB -c work_mem=5242kB -c maintenance_work_mem=256MB -c min_wal_size=1GB -c max_wal_size=2GB -c checkpoint_completion_target=0.7 -c wal_buffers=16MB -c default_statistics_target=100

$ # mysql
$ docker run --name sql -d -e MYSQL_ROOT_PASSWORD=my-secret-pw mysql --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

Redis is basically the same but allows all of its config via flags, including password.

$ docker run --name red -d redis --slaveof 10.0.0.2 6379 --requirepass secret

Doing the same via docker-compose:

version: "2"

services:
  postgres:
    image: postgres
    command: >
      -c max_connections=200
      -c shared_buffers=1GB
      -c effective_cache_size=3GB
      -c work_mem=5242kB
      -c maintenance_work_mem=256MB
      -c min_wal_size=1GB
      -c max_wal_size=2GB
      -c checkpoint_completion_target=0.7
      -c wal_buffers=16MB
      -c default_statistics_target=100
  mysql:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: my-secret-pw
    command: >
      --character-set-server=utf8mb4
      --collation-server=utf8mb4_unicode_ci
  redis:
    image: redis
    command: >
     --slaveof 10.0.0.2 6379
     --requirepass secret 

How are flags to CMD any different than setting environment variables or even different from the mysql and postgres images?

[anthonyrisinger]

@yosifkit I acknowledge you can get there with COMMAND, and that's a fair point about the other databases requiring online configuration. mysql does allow other config, like MYSQL_ONETIME_PASSWORD or *_FILE, and postgres gets fancy with POSTGRES_INITDB_XLOGDIR. To some degree this whole thing is probably subjective and preference-driven, stemming from the dichotomy of containers being both CLI-like and appliance-like.

I like the declarative aspect of ENV. I am instructing this black box thinger what I need from it, as opposed to executing a tool/binary and knowing its rules and idiosyncrasies. I also like that it's key/value, which makes it straightforward to CRUD individual items from docker inspect or consume/generate from shell.

I might be old-fashioned or in the minority here, I'm not sure. ENV was always the way the config a system/OS container, since the way before time, long long ago! Hard to pass args to good ol' init after all. Docker became ubiquitous and lowered the bar to the point images now successfully compete directly with native binaries, which I think is super. Nonetheless, I generally still find ENV more pleasant to use and mechanically process on the daily, especially for apps I don't know very well or am just trying to get usable for whatever reason.

What say you? (whynotboth)?

[christrewin]

It would be nice to have a way to use Docker secrets to read from /run/secrets/redis-pass and set the redis --requirepass flag.

For example:

On a swarm manager set the redis-pass, then use docker stack deploy -c docker-compose-prod.yml appname

version: '3.1'

secrets:
    redis-pass:
        external: true

redis:
    build: ./redis
    image: redis:3.2.9
    networks:
        - frontend
    ports:
        - "6379"
    deploy:
        replicas: 2
        update_config:
            parallelism: 2
            delay: 10s
        restart_policy:
            condition: on-failure
    secrets:
        - redis-pass:
    environment:
        REDIS_PASS_FILE: /run/secrets/redis-pass