Hi folks, I’m new to habitat and exploring habitizing our WordPress + nginx + MySQL stack. I have a few questions if you don’t mind:
~I notice there’s a core-plans/wordpress, but am surprised it bundles MySQL rather than linking to a service via docker-compose (we use AWS RDS in production). Is that just for demonstration purposes, or is there a reason behind that?~ My mistake, it only bundles the client. I read this too quickly
Where is the best place for me to fetch private plugins? We store them in zip files in a secure S3 bucket, so I’d need to make an authenticated HTTP call and pass the file to wp plugin install. I’m guessing inside do_install?
Where is the best place for me to fetch a recent database snapshot to populate a local database for local development? My guess is, if we end up using docker-compose, this might be part of the init script of the database [service]?
If I use the example wordpress plan, or make my own with core/wordpress-proxy, can I still provide my own templated nginx configs?
#2 - I’d do this inside do_build() just because thats where all the pieces are put into place. do_install() would do a similar job though. I normally leave do_install() for copying files around. Anything that “runs”, I put in do_build().
#3 - Right on! init is a great way to do this, and you can even have it perform different behaviour based on environment variables if necessary. Alternatively, this could be a separate plan that knows how to bind to the database for a one-shot restore of the database. I don’t know that you would need it in init.
#4 - Your options here are varied. You can “wrap” the plans in core with what are called “configuration plans” . These simply declare a dependency on the core package, and ship adjusted/custom configs. Or if the config templates in the core plans are enough for you, can you use those directly, and rely on injecting the right configuration options.
Let me know if you have more questions on those. Happy to clarify!