Isolate GitLab app from infrastructure / daemons provisioning

[brodock]

I propose we make the cookbook into more than one.

There should be one "base" cookbook that would deploy the app without provisioning any dependency deamon/infrastructure.

This is good in many ways as people have different opinions on how to provisioning things, and will make it more reusable.

Some ideas:

• GitLab-base - install ruby / deploys the app to specified folder, configure database/redis yaml based on attributes
• GitLab-local - depends on GitLab-base, install redis / postgres or mysql / nginx (all on the same machine)
• GitLab-HA - depends on GitLab-base, install and provision a HA setup using multiple machines, etc
• GitLab-AWS - depends on GitLab-base, provision AWS managed services and changes base's attributes to match these values

By refactoring it to this style, we can cleanup cookbook, and people can reuse it with their own infra-structure requirements.

[atomic-penguin]

So @brodock, it definitely needs cleaned up. Not sure this is the right approach, but it looks like you are proposing wrapping the base cookbook for different use cases.

Omnibus Gitlab CE seems like it would be a good way forward for the base case. I have broken out the yum configuration for gitlab-ce into atomic-penguin/cookbook-yum-gitlab-ce as a starting point in reworking this into something more bite-sized.

So then a base recipe ideally becomes (for EL-platform family):

1. install a few packages (ssh, postfix), install gitlab-ce.
2. Run gitlab-ctl reconfigure, if needed (perhaps subscribe to gitlab-ce package for idempotency)
3. template out /etc/gitlab/gitlab.rb
4. Symlink old directories to omnibus-gitlab cookbooks to maintain compatibility?
5. Tack on more features, or wrap in application cookbooks for various use-cases.

[brodock]

This is a good way to do that for general use, but I still think the "source" way of installing can be useful for other scenarios.

IMHO "base" recipe should enable both ways of installing: Omnibus and Source.
Infrastructure and environment specific use-cases should be implemented in one or more separated recipes.

Right now, generating an custom omnibus package takes a lot of time and requires specific setup and custom work, having "source" as an option makes it easy to manage an staging environment or deploying with custom changes.

[chewi]

As things stand, the database recipes are a little strange. The mysql recipe installs a server whereas the postgres recipe does not. Both are written as though the database and user are being created remotely even though it makes more sense to do this locally, i.e. run the database cookbook on the database server, not on the application server.