The content on this page describes a migration-less life cycle of API Gateway policies and services in the form of a Continuous Integration and Continuous Delivery (CI/CD) pipeline. CA-Broadcom has developed open source tools such as the Gateway Developer Plugin to help support this workflow so that policy and service creators can continuously develop, push changes and automate the build, deployment and testing processes for their Gateway solutions across multiple environments at scale. 

The CI/CD pipeline itself is scaleable; you may implement the pipeline in full as described on this page OR you may adopt certain components of it and still gain efficiency benefits. 

 

Note

: While the Container Gateway is optimized for a CI/CD pipeline workflow, they are not mutually exclusive. Certain aspects of the CI/CD workflow can apply to an Appliance Gateway. 

 

 

1

 

 

The CI/CD pipeline used in software development can be applied to the development and configuration of Gateway policies and services. As your organization's information security and integration requirements evolve, your policy development workflow will likely need to evolve as well. There are five major components of the CI/CD.

Together, these systems provide a standardized workflow that makes rolling back and automation more feasible in the Gateway service and policy development life cycle, and optimize the DevOps experience for your team. And by treating policy as code, the scaling and maintenance of multiple environments becomes much more manageable. 

As a policy or service developer, to begin building your Container Gateway for a CI/CD Pipeline, the following are required:

On your local machine you'll write and implement Gateway policies and services, build Gateway solutions in the form of bundles, and test them locally on your machine. To help you build those bundles for a CI/CD pipeline, it's strongly recommended that you use CA-Broadcom's Gateway Developer Plugin alongside with the Gradle Build tool. 

As the entry point and foundation of any CI/CD pipeline, it's recommended that you work with a Version Control System (VCS) together with your local machine(s) so that you can push and pull Gateway artifacts like code. The Container Gateway image, including all of its relevant policies, services, and dependencies, can be stored in the VCS - allowing you to effectively track changes to those Gateway artifacts with timestamps, and rollback changes as required and as many times needed. 

GitHub and SVN are examples of a VCS that can be readily used for your CI/CD implementation. 

After the policies and its artifacts are developed, a build system (i.e., Gradle Build) is used to put them into a deployment package (bundle) to be readily deployed to a Container Gateway. The Gateway Developer Plugin is a Gradle plugin that works in conjunction with Gradle Build to create the builds. 

Deployment packages (i.e., bundles)  are stored in the artifact repository (e.g., Nexus). A deployment system (e.g., Jenkins) can be configured to monitor the artifact repository and automatically pull this bundle when available or when changes have been detected and deploy the bundle into a Gateway. 

A deployment system (e.g., Jenkins) executes the deployment of the package to one or more Container Gateways. Tests are then run against a newly deployed environment. 

Even with the Gateway Migration Utility tool at a policy developer's disposal, the migration effort can be considerable in its planning, coordination, and maintenance of mapping instructions. This is especially true if you are moving large volumes of policies and services from a source Gateway to multiple target Gateways. Unexpected changes to either the source or target Gateway can throw a completed migration or migration plan off course. With the Gateway Developer Plugin, which propagates the CI/CD workflow, the Gateway migration process is no longer required as policies are treated as code. 

Just like any standard software development project, you'll be able to tap into the full collaborative and change management capabilities of a VCS, the first and most fundamental system in a CI/CD pipeline. Check out the sample GitHub project here to get an idea of how a Gateway project appears in a GitHub repository. And like any standard software development project on GitHub, how you set up your repository is up to you and your team's requirements. For example, you may want to create multiple repositories, each  assigned to an individual team member to create different Gateway artifacts to be merged later in an upstream repository to build your Gateway solution. 

While CA-Broadcom recommends GitHub for its ubiquity and flexibility, you can tailor the Gateway for any VCS that suits your organization's requirements. Together with the Gateway Developer Plugin and some basic Gradle commands, you can generate all the required Gateway artifacts (policies, services, files, dependencies, etc.) for your solution from your local machine and then push or pull updates to and from the project repository in GitHub as needed. 

By treating your policy as code, a MySQL database is no required to store the aforementioned Gateway artifacts. This means you can do away with the performance bottlenecks that MySQL can impose on large-scale implementations of the Gateway or sorting out database credentials for multiple environments with different configurations.

Learn more about the Gateway Developer Plugin here. 

Policy developers will find that writing policy for multiple Gateway environments that suit each of their unique set of requirements and constraints is far more challenging than writing policy for a single Gateway environment. The CA API Gateway provides you several options to manage different Gateway environments:

To help make this possible, the Gateway offers environment variables that you can use when specifying items such as JDBC connections, private keys, and trusted certificates - those variables then reference an environment map for the correct values. Environmental variables can be readily changed between Gateway deployments for multiple environments without needing to re-evaluate how a service or policy should be configured separately for each environment. More importantly, environmental variables are programming language and Operating System agnostic. 

In a CI/CD workflow, configurations are embedded directly into the GitHub project or Container Image, along with all relevant policies, services, dependencies and other artifacts associated with one particular Container Gateway environment. The

src/main/gateway/config

folder in the GitHub project holds all the necessary configuration artifacts for a specific environment.  

  

Within the config folder, numerous configuration types can be stored and version controlled within policy (typically in YAML (.yml) or Java properties (.properties) file format), including but not limited to Services (services.yml), Stored Passwords (stored-passwords.properties), or Cassandra Connections. More notable for the CI/CD pipeline is the Environment Properties configuration file (env.properties) - this is the file that contains the values for the environments defined in each of the applicable configuration files for the policy. Environmental variables can be applied to any of the configuration types within the config folder and can be defined with one or more of the following:

A deployment package does not contain any environment values - configurations that use environmental variables shall reference the env.properties file for those values. To learn how to configure environment properties and to see examples of how environmental variables can be defined and applied, refer to the GitHub wiki page here. 

Another approach for the environment is to provide using gradle configuration specified into

build.gradle

file. This method is intended to be used for generating 'offline' environment bundles that can be distributed and deployed to other Gateway form factors. To learn more, refer to the GitHub wiki entry here.