Best way to handle ports with multiple Mysql services?

countfak

Hi,

I'm testing the latest version which has the built-in hosts file management, and everything is working just fine.

One thing I noticed in my usual scenario: I'm using Indigo to run Wordpress websites locally, so I have to manually specify the mysql port (different for each website of course) otherwise the system assign it randomly whenever it starts; since the database connection details are hardcoded in the Wordpress config file, it has to stay the same.

Does this make sense? Is this the right way to do this?

Thanks

Indigo

Hope you don't mind me moving your post — I think it will be helpful to others and will be more easily discovered in its own thread.

To answer your question, yes, that's correct. Unfortunately there's no way around the fact that the multiple Mysql instances cannot share the same port, since they are all bound to 127.0.0.1.

I suppose an alternative would be to never start more than one of your Wordpress stacks simultaneously, thus allowing them all to be configured to port 3306, but that's not what I'd recommend.

If you can think of better in-app wording around this topic I'd definitely be interested.

countfak

Hi, thanks for moving the post, and thanks for the reply. It all makes sense. I also think it's quite straightfoward so no need to overcomplicate this.

Natrim

Maybe setting env variables for PHP automatically if stack contains mysql?

ie. INDIGO_MYSQL_PORT, INDIGO_MYSQL_SERVER

Indigo

Ooh, that's very clever — love it!

I'll have a look at the feasibility of implementing this. It's possible there would be timing issues, as the dynamic ports are allocated when services start up, so we would need to ensure MySQL starts before PHP. Though I don't foresee any difficulty with that (each service type already has a "weight" which determines startup order).

There's only one other question in my mind right now which is how to handle multiple MySQL services in one stack. It's eminently possible to have multiple, although I personally have never needed it. I lean toward just adding ENV info from the first one (highest vertically in the stack, for want of anything more meaningful).

Natrim

first one sounds ok, most stacks will probably have only one mysql db
similar env variables could be then added for redis and possible future db type (postgres)

or you could just name every db by some short random name and have variable INDIGO_MYSQL_PORT_A21
where A21 is autogenerated mysql name

or just put every db ports in one variable separated by "," ie. INDIGO_MYSQL_PORT="3306,3307,3308"

Indigo

I agree, all services could potentially inject useful env variables.

Also, I agree most will only have one (mine do). That said, all services do already have a 4-character UID, which could be perfect for this purpose:

MYSQL_H8DE_PORT=3307
MYSQL_8FBR_PORT=50007

I have a question for you though — how would you actually use these environment variables?

In Laravel, for example, you could add this to your .env file:

DB_PORT=${MYSQL_8FBR_PORT}

...however that will only take effect when you empty the config cache (php artisan config:cache). Since Indigo may assign a new port (when the port is configured to "auto") any time the stack is started, that would break the site until the config was next cleared.

Thoughts?

Natrim

php artisan config:cache is only for production, if someone uses it on dev its their problem

https://laravel.com/docs/5.1/installation#configuration-caching
You should typically run the php artisan config:cache command as part of your production deployment routine. The command should not be run during local development as configuration options will frequently need to be changed during the course of your application's development.

or they just set the port to be hardcoded to only one mysql

Indigo

Sorry, you're right; config should only be cached on production so will be of no concern. Thanks!