Even though the `$SERVICE_ROOT/config` volume is mapped to the `/usr/local/etc/redis` folder in the container, any specified `redis.conf` file in `$SERVICE_ROOT/config` will not be used by the running `redis-server` process. This pull request solves that problem, by downloading the `redis-stable/redis.conf` file from the redis website to `$SERVICE_ROOT/config/redis.conf`, then runs the redis server process in the container as `redis-server /usr/local/etc/redis/redis.conf`.
Users of `dokku-redis` will be able to configure the `$SERVICE_ROOT/config/redis.conf` file to their liking, restart the redis container and then see their changed configuration in effect.
This references [this issue](https://github.com/dokku/dokku-redis/issues/30).
Previously we were exporting `REDIS_URL` via the docker-args* hooks.
This seems to confuse our users (since the env var is not displayed
when calling `dokku config`) and in some cases it also seems that the
env var is not correctly set.
Another problem is if several services are linked to the same app and
if they are exporting `REDIS_URL` as well. Then we don’t know what
will be set.
To resolve theses issues, this patch changes the way we manage the env
vars. We use standard dokku commands (`config` and `docker-options`) so
config is set on the linked application and can be reviewed by the user
easily.
We also handle the case where `REDIS_URL` is already set on the
linked application. When it’s the case, we automatically generate
another env var based on the following pattern: DOKKU_<service
name>_<random unused color>_URL. For example, this can give:
DOKKU_REDIS_BLACK_URL.
Since naming is now handled automatically, the `alias` command has been
removed. If the user wants to set a different env var on her app, it’s
just a matter of using `dokku config:set` and pasting the wanted value.
IP in DSN has been removed in favor of host name exported by docker in
the container. This is more robust and simpler since the IP can change
but the name will remain the same if the service container restarts for
instance.
With all those changes, a new command has been introduced: `promote`.
The goal of this command is to easily set a service as the primary one
when several are linked to an app. (see README for an example)
Instead of installing dependencies on the host, directly use the binary
shipped with the redis docker image. This will also prevent possible
problems when API change for example.
This will avoid issues where `dokku cleanup` removes the stopped containers (it should not do so, and instead should allow them to stay in stopped mode).
Containers will be labeled as follows:
- service: dokku=service dokku.service=SERVICE_NAME
- ambassador: dokku=ambassador dokku.ambassador=SERVICE_NAME
To destroy the containers, simply run the `service:destroy` command.
`expose` and `unexpose` commands are now fully functionnal using the
ambassador pattern. This has the advantage to be a 100% docker solution
and to not have to restart the service container. Multiple ports are
exposed when service specify them.
`start` and `stop` commands have been made more robust. When calling
`start` or `stop` on an already started (or stopped) service, an error
will be printed out instead of issuing failing commands.
Exposed services will still be exposed after a `restart`. Also the
service containers (and ambassador containers) will start automatically
when docker boot up.
note that at the moment the iptables calls complete successfully but the container isn't actually exposed. We'll probably need to use the ambassador pattern to do this properly.
