Chapter 16. Configuring with Git
Fabric implicitly uses Git to store much of its configuration data (in particular, for storing versioned profile data). Normally, this aspect of Fabric is completely transparent, and there is no need to be concerned with the Git functionality inside Fabric. But if you want to, you have the option of tapping directly into the Git layer inside Fabric, in order to manage Fabric configurations.
16.1. How Git Works inside Fabric
When Fabric is configured as a Git cluster, the Git configuration layer works as follows:
- Each Fabric server has its own clone of the Git configuration.
- One Fabric server is elected to be the master instance, and serves as the master remote repository for the other Fabric servers.
- All configuration changes made in the other Fabric servers (the slave instances) are pushed to the master instance.
- When changes occur in the master, the slaves automatically pull the new configuration from the master.
- If the master instance is stopped, another container is elected to be the master (failover).
- An administrator can access the Git configuration layer by cloning a local Git repository from the master instance. By pushing updates from this local repository, the administrator can change the configuration of the fabric.
External Git repository architecture
When Fabric is configured with an external Git repository, the Git configuration layer works as follows:
- The external Git repository is created in an external Git server (for example, using a service such as GitLab or Gerrit).
- When the Fabric is created, it automatically populates the external Git repository with the default configuration (which is initialized by reading the
- Each Fabric server maintains a synchronized state with the external Git repository.
- All configuration changes made in the Fabric servers are pushed to the external Git repository.
- When changes occur in the external Git repository, the Fabric servers automatically pull the new configuration from the external Git repository.
- An administrator can access the Git configuration layer by cloning a local Git repository from the external Git repository. By pushing updates from this local repository to the external Git repository, the administrator can change the configuration of the fabric.
What is stored in the Git repositories?
The Git repositories in Fabric are used to store Fabric profile configuration data. A Fabric profile consists of the resources, configuration data, and meta-data required to deploy an application into a Fabric container.
The branches of the Git repository correspond directly to profile versions in Fabric. For example, if you enter the following console command:
JBossA-MQ:karaf@root> fabric:version-create Created version: 1.1 as copy of: 1.0
You will discover that the underlying Git repository now has a new branch called
1.1. In fact, most of the Fabric version commands are approximately equivalent to a corresponding
gitcommand, as shown in the following table:
|Fabric Version Command||Analogous Git Command|
Configuring through the console commands
When you make any changes to profiles using the console commands, these changes are implicitly committed to the underlying Git repository. Hence, some of the console commands are equivalent to Git operations. For example, if you create a new profile by invoking
fabric:profile-create, new files are added to the Git repository, and the changes are committed. Similarly, when you edit a profile using the
fabric:profile-editcommand, these changes are added and committed to the underlying Git repository.
Fabric itself does not require any
gitbinaries to be installed on your system, because it is implemented using the JGit library. You will need to install Git binaries on your local system, however, if you want to configure Fabric directly through Git, using a clone of the Git repository.
Configuring directly through Git
There are two alternative ways of setting up a fabric to use Git configuration, as follows: