Playbooks should have a clear distinction between application and platform

[adborden]

Our playbooks currently deploy all the components of data.gov and each component is very customized. If we consider the playbooks to be more about setting up a platform, then the playbooks can be simplified. This means moving the application setup logic into the applications themselves.

This moves us much closer to a platform based deployment that fits with docker or kubernetes. It simplifies playbooks, because it's more about providing services to be consumed by applications rather than having to know how to configure applications.

Examples of responsibilities that should be in the application:

• Solr collection creation and configuration should be handled by the app (e.g. catalog-app, inventory-app)
• Database migrations should be done by the application (e.g. catalog-app, dashboard-web, crm-web)
• Installing dependencies (e.g. catalog-app, dashboard-web)

Examples of responsibilities that should be in the platform:

• Provisioning nginx, and providing the application which socket or port to listen on
• Provisioning Solr and providing connection information to the application
• Securing the environment and ensuring file permissions are set appropriately
• Providing a directories or paths to where applications should install themselves

[adborden]

This is still somewhat squishy, but wanted to start writing some things down. This is related to our conversation yesterday @jbrown-xentity. Let me know if it makes sense.

[nickumia-reisys]

Superseded by new Solr Deployment,

• [Tiny EPIC] Support SOLR standalone on ECS #3826