Multiple Projects

[maxbucknell]

Requirements

• As a developer, I should be able to run multiple projects at the same time, so that less time is lost stopping and starting and keeping track of different environments
• As a developer, I should be able to address projects by a convenient name, so that TLS, cookies, sessions, and other stuff works in a reasonable way.
• As a developer, server names should be set correctly so that editors know which Xdebug requests to intercept.

Solution

Port Mapping

Currently, Workflow binds containers to the canonical ports on the host. For example, MySQL taxes over :3306, and HAProxy takes over :80 and :443. In order to run multiple projects simultaneously, this has to end.

Addressing Ports

A simple solution, as suggested by Shane, would be to run let Docker assign host port bindings, and run Magento on that port, and address everything as https://whatever.loc:32763. This would work, but introduces complexities with Local Storage and such, and some developers find port numbers distasteful for anything more than kicking the tyres of a piece of software.

Nevertheless, this will be available for those who want it.

Proxy Server

It would be relatively straightforward to run a little HTTP server on the host that bound to ports :80 and :443, and handled routing towards projects.

The natural implementation language for this would be PHP, but since PHP’s built in server is single threaded, it’s disqualified. Two more suitable options are:

• A real web server like Nginx.
• A custom HTTP server running in NodeJS.

While Nginx is a proven platform and we have reasonable experience configuring it, managing a service like that on a Mac can be cumbersome, and automating its configuration would be a pain.

NodeJS is my preference here, because its HTTP APIs are mature and easy to use, and updating it to read configuration, starting and stopping it.

The exact specification would be subject to design and such, but I’m imagining the following:

• When Workflow initialises containers for a project, a call is made to register a proxy mapping, using the port associated with the HAProxy container, and a base URL, either obtained from local.env or from the project directory name. In the absence of an override, all subdomains of that URL would be mapped to allow for the configuration of multiple stores.
• When Workflow starts containers, there is either a NodeJS server running, or not. This will be determined by the presence of a file in /var/run/pid (or equivalent). If it’s not there, the server is started by running a node command, which starts the server in the background, and creates the PID file. This will require a privilege escalation.
• A node command is called that registers the proxy, and the server updates itself.
• If workflow stop is run, we can garbage collect and deregister it. But garbage collection is not a huge concern. A new registration would replace an old one if the URLs collide, and routing to a dead port is not a terrible problem.
• A status of the server, listing all currently running proxies will be available, and it will be possible to read stdout of the server process to get logging on registrations and requests.