I am new to Chef. We created a cookbook to install our product on various operating systems (currently tested on Ubuntu, RHEL). My product has dependency on JDK, MySQL, firefox, chrome and Xvfb.
If we want to build a Omnibus installer (.deb, .rpm and .msi), do we need to create the Omnibus project from scratch and include the above dependency and logic.
OR,
Do we have a option of using Omnibus wrapper on top my cookbook to create the installers? We are looking at Omnibus, because many of our customers use our product behind firewalls.
Omnibus is all about creating full-stack packages for software that include everything above libc in the stack. This guarantees your packages will work and you can use any version of any dependency you need without regard to the version that Linux distros ship. For example, we ship Ruby 2.1 with the Chef Client packages, whereas depending what version of your linux distort you have, you could get anything from 1.8 up if you use the system packages.
In order to get the benefits of omnibus, you need to build your package using Omnibus software definitions. It may by possible to shove chef client and some cookbooks in a package, but the best that package could do is pull down packages from whatever package repo is accessible from that machine. Since your customers control this, you have no way to guarantee the machine will have access to whatever repos you need.
For example, before Omnibus, we shipped a cookbook to setup the Chef Server, and it generally worked okay, but required outbound internet access to get dependencies, and had to compile a bunch of stuff so we'd get the correct versions (so you also needed compilers and all the associated tooling, which many folks didn't like). It was also very hard to debug when things went wrong.
So, it's (a lot) more work, but the best experience for your customers probably will be if you go all in on the omnibus approach. At Chef we have a build and test cluster for each product. The Omnibus packages generally just need to be built on the oldest version of a given distro/OS that we support and work on all higher versions, so we have some logic in our build system to build a package on one version of a distro and then run the tests on all the applicable versions. If the tests pass, we put the package in a repo where we can do more testing if desired and then promote it to being publicly available.