This blog is part of a series, check out other entries!
- FlexDeploy Loves Oracle API Platform: Series Overview
- FlexDeploy Loves Oracle API Platform: Provisioning the Gateways
- FlexDeploy Loves Oracle API Platform: Managing APIs
Provisioning anything in this day and age just seems barbaric. There are dozens of steps with even more configuration options to boot. It shouldn’t be surprising that so many companies seek out provisioning solutions to help simplify the process. In the case of Oracle API Platform, this daunting provisioning process is in the form of “Gateway Nodes”.
There are two key terms here we need to understand before continuing:
- Logical Gateway – Abstract gateway living on the API Platform instance. Usually one per environment.
- Node – Each Logical Gateway can have 1 or more Nodes(cloud or on prem). These Nodes are physical machines that host your APIs.
So for example, lets say we wanted to create a node infrastructure that looks something like this
There are 3 Logical Gateways each of which has 1 Node with the exception of production which has two. Lucky for us FlexDeploy now offers support to provision both Logical Gateways and Nodes. Lets get to it.
Configuration Files
There are two json configuration files we need to provide to FlexDeploy to automate both the Logical Gateway creation as well as the Node creation. Those files are gateway.json and gateway-props.json respectively, though you can call them what you wish. For the purposes of this demonstration I have these files source controlled in a Git repository.
{
"name": "${{FD_ENVIRONMENT_NAME}}",
"description": "${{FD_GATEWAY_DESCRIPTION}}"
"firewall": {
"maxUnboundedItems": "1024",
"maxChildElementDepth": "1024",
"maxItemValueLength": "102400",
"maxMessageSize": "1024000"
}
}
{
"logicalGatewayId" : "${{GATEWAY_ID}}",
"gatewayNodeName" : "Node ${{FD_ENDPOINT_NAME}}",
"gatewayNodeDescription" : "Node for APIs",
"listenIpAddress" : "${{FD_ENDPOINT_ADDRESS}}",
"publishAddress" : "${{FD_ENDPOINT_ADDRESS}}",
"nodeInstallDir" : "/opt/apiplatform/node",
"gatewayExecutionMode" : "${{GATEWAY_EXECUTION}}"
}
These configuration files heavily rely on FlexDeploy property replacement. If you are unfamiliar with property replacement or need a brush up you can check it out here.
The Build Workflow
The build workflow has the job of getting our configuration files from the git repository and saving them to the FlexDeploy Artifact Repository. This is accomplished in two steps:
- CloneProjectSources(git)
- SaveArtifacts
The Deploy Workflow
The deploy workflow does most of the heavy lifting in this setup. However, it can be accomplished through only two workflow steps.
- ImportGateway – Uses the gateway.json file to create the Logical Gateway on API Platform.
- InstallNode – Uses the gateway-props.json file to install the Node and join it with the Logical Gateway.
The use of UserInput in both deploy steps allows us to reuse these same configuration files across multiple environments. In contrast you can also have environment specific configuration files and cut back on the User Input.
The Execution
For the sake of time I have already run the project for the Development and QA environment. So all that remains is to deploy to Production, which we can see is lacking below.
After deployment we now have a Logical Gateway for Production and we can also see two Nodes configured and joined!
A quick look at the workflow execution shows us exactly what happened. Notice that the InstallNode step ran on two endpoints (one for each Node we installed).
To finish up I would like to show the Topology for the Production environment so we can better understand how two Nodes were installed.
This Environment Instance has two endpoints configured each with a resource type of ‘Oracle API Platform Node Server’. As a result the ‘InstallNode’ step will execute on both endpoints. If we wanted to create Production with 3 nodes it would be as simple as dragging another endpoint over and setting the resource type!
Now that we have the Gateways provisioned, lets deploy some APIs.