Datapower GitOps: Simplifying DevOps
Introduction
The goal of the Datapower GitOps is to have a single point of truth for the configuration of multiple Datapowers. This also allows the possibility to make a change only once and replicated across devices automatically and avoiding human mistake.
The setup
In this section we will focus on the GitOps object configuration and all the prerequisites and files that must be created beforehand.
The connection between Datapower and the Github server can be secured with the HTTPS or SSH protocol. In our case we will focus on the SSH protocol, so we will have to generate SSH client profile and obtain the SSH authorized key file from our GitHub server.
Prerequisites
SSH Client
First create a ssh-key pair using ssh-keygen:
ssh-keygen -t rsa -b 4096 -C t3@ibm.com
Two files will get generated on your machine, a public and a private key.
The public key will look like this:
ssh-rsa XXXXXXXX
The private key like this:
-----BEGIN OPENSSH PRIVATE KEY-----
xxxxxxxxxxx
-----END OPENSSH PRIVATE KEY-----
In order to add this key to Datapower it must be in PEM format, so we must convert the Openssh private key to and RSA Private key using this command:
ssh-keygen -p -N "" -m pem –f <openssh-priv-key-file>
The new RSA-PrivateKeyFile will look like this:
-----BEGIN RSA PRIVATE KEY-----
xxxxxx
-----END RSA PRIVATE KEY-----
Obtaining SSH authorized key
We will also need the public SSH host keys of your host, in our case github.ibm.com, we can use the command:
ssh-keyscan github.ibm.com > ssh-host-key-github.ibm.com
The output file will be the ssh-host-key-github.ibm.com
The result of the prerequisites exercise will be 3 files:
- public openssh key
- private RSA key
- ssh host key file of the URL “github.ibm.com”
GitHub configuration
A few steps to be followed to setup the Github account used for the GitOps configuration.
- Create an empty repository on your Enterprise GitHub account.
- Add a public SSH key by going to the account -> settings -> SSH and GPG keys ->Click on New Key -> Add Key Title and Key Type and enter the generated public openssh key mentioned above. (as shown in figure below)
- Obtain the GitHub username, GitHub emailID, GitHub SSH link.
The result of this exercise will be.
- GitHub username – <my GitHub username>
- GitHub emailId – <ny GitHub mail address>
- GitHub SSH link - git@github.ibm.com: <my GitHub username>/GitOps.git
Datapower Configuration
After login in to the desired datapower and switching to the domain where GitOps will be enabled, you will need to configure the GitOps object and some other objects necessary for the GitOps to work
SSH Client
Since we are authenticating to the GitHub repository using SSH, we will need to create a SSH Client profile with the following configuration. The users to login can be your GitHub username, the profile must be SMTP, the private key must be the one created earlier and the password alias will contain the “passphrase” of the key.
GitOps object
Search for the GitOps object and configure it using the information obtained in the prerequisites. The GitHub SSH link as the remote location, the connection type as SSH, for the client profile select the one just created and in the SSH authorized key file use the one generated and called ssh-host-key-github.ibm.com
Leave administrative state off until the full configuration is done.
For the Sync properties specify the operation mode, the branch, the user and the email to connect to GitHub.
Enable administrative state and save.
First Write
Now we can proceed with the first write to the GitHub repository, this will populate the repository with the following folder structure.
/Datapower
├── domain1
│ ├── config│ └── local
├── domain2
│ ├── config
│ └── local
└── templates
To perform the write, use the 3 dots at the top, select the “GitOps write” option, specify a commit comment and the write mode force / Dry run.
Read-only configuration
On the datapower we want to configure as “read-only” we will have to follow a similar set of steps.
Again, we will need to use a domain other than the “default”, and inside you must configure the GitOps object the same way as before, the only difference will be that this time we are using the “read-only” mode. We have the option to specify an interval and an identifier to run the GitOps against.
After the indicated interval time, or after a manual read, the domain inside the secondary Datapower should have the same configuration as the domain in the original Datapower, since that configuration was previously written in the GitHub repository.
Results
Use Case 1
A common use case for the GitOps will be to create and object in Datapower and have that object replicated across the other devices. For this example, we are going to create a new parsing object.
On the top-left, search for “Parse settings”
Add a new “Parse Setting” give it a name, add some comments, and fill out some common properties.
Apply the configuration and it is very important to save the configuration, Search “GitOps” and do a GitOps write.
In the GitHub repository, inside the T3-Datapower-GitOps/Datapower/T3_domain/config/T3_domain.cfg.json file you should see a new object
The Datapower configured as “read-only” will pick this change and create the object automatically.
Use Case 2
In the second use case, we edit the config file in the GitHub repo. When you have changed the config file, the Datapower GitOps Agent will automatically pull the desired config from the GitHub repo to both the Datapowers.
In order for changes to have effect you need to do a GitOps Read because GitOps on the source Datapower are in read/write mode.
And the changes in GitHub have been synchronized on both Datapower servers.
Author:
Nivin Pradeep Kumar
Carlos Miguel Gonzalez Escobosa
Bo Nydahl