Allow multiple host name aliases for one project

[helhum]

What happened (or feature request):

• Feature request

Motivation

It would be nice to be able to specify multiple additional (local) hostnames in configuration
which should be used for routing to the correct dev instance and used for the web server configuration (in case the web server does not accept arbitrary hostnames)

That is useful for applications that can deal with multiple host names in one instance (like TYPO3). It is a fairly common occurrence in TYPO3. For Drupal developers, this is akin to a domain access approach (one codebase, one database, multiple hostnames). Additionally, subdomains can be used for a multi-lingual approach.

Acceptance Criteria

• End-users can add a hosts: entry in .ddev/config.yml
• Each entry within .ddev/config.yml gets added to /etc/hosts
• Each entry within .ddev/config.yml is used when reporting the site from ddev list, describe, and start.
• Each entry gets a local self-signed cert and appropriate nginx configs.
• ddev-ui and the json output it reads will need an array output.
• Each entry uses the same HTTP/HTTPS ports (that is we're not allowing per domain port configs)

Related Issues

• Subdomain, Local DNS support: Don't require hosts file manipulation Subdomain, Local DNS support: Don't require hosts file manipulation #416

[rickmanelius]

Related to #570 (or at least surfaced during the testing of the upstream issue).

[rickmanelius]

Related to #416, which is a much much larger issue.

[rickmanelius]

This is also useful for Drupal in domain access or multi-lingual configuration. I believe the same is true for WordPress.

There are several areas that would be impacted by this as well as different solutions. Currently, we're still reliant on /etc/hosts entries versus a dnsmasq solution.

Areas impacted:

• /etc/hosts
• Router ports/nginx configs
• config.yml
• Self-signed certs

Implementation Options:

1. Array in config.yml that generates SSLs at the router and modifies the nginx configuration while adding /etc/hosts entries.
2. Need to work through this further but it might involve devcert + dnsmasq and would have broader implications.

[rickmanelius]

Just noting that this was a request from @tmotyl as well.

[rickmanelius]

Pulling in @rfay to assist with the definition for acceptance criteria. I would stub this out as an entry in config.yml with the expectation that it would handle the /etc/host changes and accurately show up in ddev list/describe/start output.

Being more explicit:

• End-users can add a hosts: entry in .ddev/config.yml
• Each entry within .ddev/config.yml gets added to /etc/hosts
• Each entry within .ddev/config.yml is used when reporting the site from ddev list, describe, and start.
• Each entry gets a local self-signed cert and appropriate nginx configs.
• ddev-ui and the json output it reads will need an array output.
• Each entry uses the same HTTP/HTTPS ports (that is we're not allowing per domain port configs)

Potential issues are a few. Currently, our ddev list command assumes a single HTTP/HTTPS pair and the list might become a bit hard to read. I'm assuming we'll run into a few more trouble spots as soon as we start digging. Also, the ddev-ui integration

[cweagans]

These ACs sound pretty solid.

In the future, does it make sense to wrap some of this work in a command? ddev hostname (add|remove) [whatever] or the like? Or more generally, if we had some command that could change attributes on an app or something - ddev [whatever] php_version 7.1 or ddev [whatever] containers add solr or something like that? Probably outside the scope of this one - this issue would be a prerequisite to some kind of wrapper command anyway.

[rickmanelius]

@cweagans Let's consider that outside the scope of this issue. What you're describing could be something that extends ddev config either by setting a flag when running config or altering an attribute. I'm a little hesitant on doing this just yet because it is probably a bit of engineering effort and there are some bigger, more pressing rocks to move in the next 1-3 months. That said, happy to split out an issue to track this!

[rickmanelius]

Updated assignee. I'll get the issue description updated with the motivation/AC and the labels updated. Also, I'll add the motivation and prioritization/milestone.

[rfay]

Key things to note:

• We envision only multiple hostnames of the form mysite1.ddev.local, mysite2.ddev.local, etc. The hostname aliases would not have real subdomains, although mysite.d1.ddev.local and mysite.d2.ddev.local also would work fine, but the hostname portion is actually "mysite.d1". If TYPO3 multisite requirements are larger than that capability, we'll not meet the need with what we're thinking.
• Currently we're not thinking about adding any databases, there's just the one that we normally provide. If I understand right, TYPO3 uses one database for multisite, so this will work there. It can work for Drupal (which typically uses a different db for each site) as long as people use table prefixes. But that would thoroughly mess up imports from a server that didn't use them. So I'm not optimistic about this working well for Drupal multisite.

[beathorst]

• At least it is important to have the possibility to have multiple hostnames for one TYPO3 installation.
  For the project mysite1 I get for default the domain mysite1.ddev.local.
  With the new config feature I can add mysite2.ddev.local and mysite3.ddev.local? Right?
  Or I can add subdomain1.mysite1.ddev.local and subdomain2.mysite1.ddev.local?
  Both would be nice. But If the last one is a problem for some reason, I you can do like this:
  subdomain1-mysite1.ddev.local or subdomain2-mysite1.ddev.local with a minus instead of a dot

• TYPO3 uses only ONE database for multisite, that's correct.

[helhum]

Very cool! Thanks a bunch for this feature!