Many customers want an easy, repeatable way to spin up a fabric and all the various containers they need in an automated way such as for Continuous Deployment.
To do this fabric8 has an Auto Scaler which allows you to define how many instances of each profile you need and the auto scaler will automatically create the containers you need; using the available resources and automatically create new containers if there is a hardware or software failure.
Profiles are designed so that they can be combined together into a container; or they can use inheritance to override properties.
If you wish to combine profiles together you need to make sure that if you want to combine rather than override you need to ensure that the properties files in each profile use either different file names or different keys.
For example if you have 3 different blueprint/spring XML files inside each profile which you want to combine so that all 3 will be executed; name each one differently and use a different key name in the io.fabric8.agent.properties files. e.g. the bank1, bank2 and bank3 profiles in the MQ based loan broker example all use a different blueprint XML file and key in the io.fabric8.agent.properties file
A typical fabric8 installation has a ZooKeeper ensemble (a number of ZooKeeper servers connected together; either 1, 3, 5, 7 of them; usually 3 or 5) so that if there are failures or a network split, every node knows whether or not its part of the master split - to avoid the split brain problem. This lets fabric8 reliably create master / slaves and federated clusters such that there's no split brain / network partition issues.
If there are only exactly 2 data centres and either is allowed to fail and the other takes over; then there's no real way to solve this the single-ZooKeeper ensemble route automatically; since there's no way to achieve quorum in either data centre. (Its trivial to have, say, 2 ZK servers in one DC X and 1 in the DC Y; but then if DC X fails; you can't achieve quorum automatically.
There’s a few ways this could work; it depends on trade-offs really. Our recommended approach is:
If you want to favour one DC so that its the master and have some manual recovery mechanism you could consider this approach (though its not really recommended):
Fabric8 has awesome support for Spring 4 with the Spring Boot Container.
If you've been previously using OSGi or Apache Karaf as your application server then Spring 4 poses a challenge as its not currently available as valid OSGi bundles. So to use Spring 4 we recommend you consider moving to the Java Container in particular the Spring Boot Container