Ensure the URL proxy container is running when displaying URLs for environments.

[jonpugh]

We currently show the environment urls (http://project.env.server) as being available always.

We have a url-proxy:enable command available.

We should figure out a way to ensure the URL proxy server is running and offer to enable it for the user.

[xendk]

I'm considering looking into whether it's possible to usie the docker-gen that the proxy is build on to make a container that fiddles the /etc/hosts of the host machine to give every container a resolvable hostname. Something along the lines of project_drupal_1.docker (simply the container name), with option to use VIRTUAL_HOST to add ones preferred alias (mysite.dev).

Makes it easier to get at the database server from the host (no more using docker inspect to extract the hostname after each docker-compose up), and it allows for using the generated hostname in the settings.php file, allowing for running drush on the host instead of in an container. Running drush in a container creates issues with server aliases (your ssh keys aren't available) and therefore sql-sync and rsync, and file permissions (drush dl creates everything as root, unless you make the effort of creating a container user with the same UID as yourself).

On the olther hand, when the drush container runs as root, there's no warnings from drush cc all.

Thoughts?

[jonpugh]

give every container a resolvable hostname. Something along the lines of project_drupal_1.docker (simply the container name), with option to use VIRTUAL_HOST to add ones preferred alias (mysite.dev).

Not a terrible idea, but not all of the containers expose ports to the host. I'd prefer to only expose what's required for getting work done.

See #19 for the feature request to make DNS less of a hassle.

Re: drush & database, in the last few days I've added an SSH server to the drush container, and added code that writes an drush alias to the host. This allows you to do exactly what you are suggesting, without needing to expose the database server to the host.

I've tested it with drush sqlc from the host and it works great.

There's still work to do related to that setup. We should definitely not use root to connect to the drush/ssh container. I could definitely use some help improving that container! https://github.com/terra-ops/docker-drush

[xendk]

Well, that's the point really. The mysql container doesn't expose the 3306 port to the host, only to linked containers, but if you have the IP of the container, you can connect to mysqld just fine. But digging out the IP of docker inspect to add to your Mysql administration app each time is a hassle.

I'll try out the new Drush container in my homebrew setup, but it seems that it failed building on hub.docker.com?

However as far as I can tell there's still issues that's hard to fix. drush rsync requires one side to be local (limitation of rsync). Global Drush command extensions doesn't work (could mount ~/.drush inside container though). Not using root requires setting up the container with a user with the same uid as the drupal container uses for the webserver, which adds in a dependency between the containers (I believe that NginX and Apache uses different uid in standard Ubuntu setup). Though in the latter case, running drush as the webserver user is nice.

Would be nice if there was a simple way to make the webserver and drush containers run under the same uid as the user running the container, but that's not so simple, as far as I know.

[xendk]

Quick note:

I finally got round to trying out jderusse/dns-gen which does exactly what I was thinking. In a pure docker-compose setup it makes things much easier as I can just put project_database_1.docker in settings.php, and both the site an Drush on the outside will work.