[drupal] plan overwrites immutable to get custom config under supervision

[themightychris]

This seems dangerous: https://github.com/habitat-sh/core-plans/blob/master/drupal/hooks/init#L28

# Deplay the nginx config and then launch it
cp -r {{pkg.svc_config_path}}/nginx.conf \
      {{pkgPathFor "core/nginx"}}/config/nginx.conf

hab svc load core/nginx --group {{svc.group}} --force

Can a better way be provided to launch nginx as a service with an entirely custom config file? Maybe via an optional config that a custom run hook looks for?

[bdangit]

Yes. Normally you would not want to modify the pkg's config file but instead you want to install your custom nginx.conf into the svc path of nginx. Things may have changed due to multi-service supervisor so there may be a better way.

[reset]

I'm not a fan of the pattern we see here at all so I'm going to mark it as a bug. Theres too much room for failure trying to manage a second service in a run hook of another. I've seen this in a few places now but am not ready to provide a proper solution just yet. Way back in November of 2015 this popped up and the solution was to create a second package which binds to the first. You can see that in the relationship between builder-api and builder-api-proxy. At the time we also tossed around the idea that a package may not be a 1:1 mapping but I'm not confident that we should make such a large change there either as well.

Another way out of this could be to create a third package which includes both the app and the proxy and then simply manages both of those services in it's own hooks like we are seeing in the drupal hook linked above. If we like this pattern, we could document it and make it more of a first class citizen.

[baggerspion]

What about a third way?

My idea was to effectively use the existing core/nginx as a template. I would "fork" it and put the Drupal code and config into this new fork. This fork could then be bound to a PHP-FPM service.

[reset]

@therealpadams I think that's essentially what we're doing in builder-api-proxy without forking the compilation process. Just by passing a config with the filepaths overridden to the NGINX binary you get the isolation you need. Was there something additional you had in mind?

[baggerspion]

I don't think so... sounds about right. But I would need to check that out first.

[baggerspion]

In case anyone is interested, my new approach to Drupal (as I described above) can now be found here: https://github.com/therealpadams/habitat-plans

• New Drupal plan
• New PHP which runs PHP-FPM as a service that we can bind to

This is a total experiment to see what this solution looks like. I'm not advocating folks use this over the current core/drupal.

[baggerspion]

Wanted to bump this conversation to remind folks that I am still on this:

• I have submitted [php] core/php: Updated to run PHP-FPM as a service #1146 to allow PHP to be run as a service
• Next step, create a nginx-drupal-proxy
• Final, create a new core/drupal, which is a composite plan to deploy/run/stop/etc both of the above

After that, I will want to look into how to bring MySQL into the mix. But, for now, I simply want to create a simple core/drupal that can be relied on to not be so dumb as the current one.