Skip to content

Ephemeral Gateway Reference Architecture

vinny604 edited this page Jul 23, 2019 · 29 revisions

Table of Contents


This Wiki article presents a reference architecture that your organization can adopt to implement a CI/CD workflow that optimizes both the design and run times of the CA API Container Gateway life cycle in ephemeral mode. Design time refers to activities pertaining to the design or development activities of Gateway policy language while run time refers to the activities pertaining to delivery, integration, and deployment activities of the Container Gateway life cycle – automation is used where the described tools allow it.

In addition to the architecture, we’ve also included reference implementations, where appropriate, in the CA Technologies Public GitHub repository that you can fork to your GitHub repository as a deployment or Gateway solution template.

If you must deviate from the presented reference architecture in your ephemeral Gateway implementation, CA Technologies may offer limited support depending on your customization and chosen third party tools. Because the reference architecture describes many third-party tools, any direct or indirect references to their use are subject to the tool creator's own product release cycles and are therefore subject to change. We encourage you familiarize yourself with the tools and the CI/CD process in general prior to implementing the proposed architecture.

Going Ephemeral

The prescribed outcome is to enable your Container Gateway solutions to go completely "ephemeral"; that is, any container can be stopped and deleted, then rebuilt and replaced with an absolute minimum set up and configuration. In effect, your Gateway solution becomes stateless: it does not share any data with any other systems nor does it depend on any persistent storage such as an external MySQL database.

Click image for expanded view.


In ephemeral mode, a Container Gateway restart shall be triggered by a new code deployment, environment configuration change or the physical relocation of a Kubernetes pod. Those changes are detected by a deployment system (consisting of an application package manager, continuous integration and delivery tools, etc.) which will then stop and rebuild the affected Kubernetes pods, always aligning the Gateway solution at run time with design time. At design time, the GitHub repository becomes the single source of truth for your Gateway solution and artifacts.


The following sections outlines the macroscopic prerequisites for the Ephemeral Gateway. As appropriate, we've included external links to third-party documentation for this Beta release; however, because CA Technologies does not maintain URLs from third parties, the URLs may be subject to change without notice.

Note: Additional prerequisites may be defined as you drill into the other in procedures or tasks related to the set up of your Ephemeral Gateway.

Version Control System

CA Recommended: GitHub

Purpose: Provides a single source of truth for Gateway policy language and all artifacts related to your Gateway solution at design time. In addition to a design time repository, a run time repository for environment configurations can also be set up to separate configuration from policy.

Learn More: GitHub Guides

Container Platform

CA Recommended: Docker

Purpose: Allows the creation of self-contained Gateway execution environments, including all of its dependencies.

Learn More: Docker Documentation

Container Orchestration

CA Recommended: Google Kubernetes Engine (requires Google Cloud Platform)

Purpose: Deploy and manages your Container Gateway in pods (groups of one or more containers run in a shared context).

Learn More: Google Kubernetes Engine Documentation

Build Automation

CA Recommended: Gradle - Gateway Developer Plugin

Purpose: Runs tasks that enables a CI/CD workflow for a Gateway solution life cycle. A common task would be the building of a Gradle bundle (containing all Gateway policies and dependencies as defined in the design time repository) to be mounted on a container.

This plugin is required if you plan to use a single GitHub repository for both policy language and environment configurations.

Learn More:

Continuous Integration

CA Recommended: Jenkins

Purpose: Jenkins monitors and creates Pipeline jobs for each Gateway repository containing a Jenkinsfile.

As part of the pipeline job, Jenkins may download dependencies from a repository manager and, if successful, pushes a new Container Gateway Docker image and as required, upload Gateway artifacts to the repository manager (see next row).

Learn More: Jenkins User Documentation

Repository Manager

CA Recommended: Nexus

Purpose: Fulfills two purposes: 1) Stores docker images as they are built by Jenkins to distribute or replace a Kubernetes pod and 2) Allows an in-production Container Gateway or Jenkins (during a build) to access its artifact library that a Gateway solution may require at run-time. Nexus may also proxy and/or cache artifacts from external repositories that may be open source (e.g., HTTP, JDBC, and JSON parsing libraries) as required by the Gateway solution.

By centralizing the repository management process and relying less on directly downloading from external repositories, Gateway solution teams can save time and increase build performance.

Learn More: Sonatype Product Documentation

Continuous Delivery

CA Recommended: Weave Flux

Purpose: Fulfills two purposes: 1) Watches for new docker images that are pushed into the Nexus repository manager by Jenkins and deploys them to the appropriate Kubernetes pods as defined in the Helm Chart (see next row). 2) Watches for any changes in the environment configuration repository - any checked-in changes shall trigger Flux to terminate a Container Gateway and replace it with a new one.

Because of its inter-dependency with Helm Chart at run time, Weave Flux is also known as the GitOps Kubernetes Operator.

Note: Use only if your organization plans to implement a GitHub repository dedicated to environment configurations for run time, where environment configuration is strictly separated from policy language. For the beta release, the environment configuration repository must be a public in order for Weaveflux to monitor its changes.

Learn More: Weaveworks Documentation

Application Package Manager

CA Recommended: Helm Chart

Purpose: Describes how the Container Gateway solution shall be built in a Kubernetes cluster: in essence, it informs Weave Flux to take a Gateway build package retrieved from Nexus and install it in a specific Kubernetes pod to serve a specific purpose or situation.

Tiller is the in-cluster component of Helm. It interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It also stores the objects that represent releases of your Gateway solution.

Ideally, Helm-related configurations (and all other configuration-related artifacts) are stored in an environment configuration repository (doubling as a chart repository).

Learn More: Helm Documentation

In-Memory Data

CA Recommended: Grid Hazelcast

Purpose: Load balances computing resources in your Kubernetes cluster.

For this reference architecture, Hazelcast is installed directly into Helm Chart via bootstrap. See the Hazelcast GitHub repository for a reference implementation.

Learn More: Hazelcast Main Page (See Resources)

Logging and Metrics

CA Recommended: Elastic Stack (formerly known as the ELK Stack), Fluentd, Grafana

Purpose: Enables your Container Gateway solution to manage and visualize logs and metrics without requiring an Internal Memory Database.

Learn More:

Secrets Management

CA Recommended: Vault, Sealed Secrets, Kubeseal

Purpose: Protects infrastructure passwords that are stored in the Environment Configuration repository (Grafana, Nexus, Jenkins, etc.).

Learn More: Bitnami Documentation


Gateway solution scaling is handled exclusively by the Kubernetes platform.

Kubernetes supports scale-out at two levels:

  • Scale the number of pods allocated to a deployment.
  • Scale the nodes in the cluster, to increase the total compute resources available to the cluster.


Health probes for readiness or liveness have not been implemented for the beta release.


The following describes some of the in-progress items or known limitations with regards to security within the reference architecture.

Inter-Node Communications with the HTTP Protocol

For the beta release, some inter-node communications within the deployed Gateway solution in a Kubernetes cluster is handled via the HTTP protocol. As a result, the connections between certain nodes are neither authenticated nor encrypted. Further configuration may be required if those nodes require a secure HTTPS protocol.

Handling Certificates

Let's Encrypt

Digital certificates issued by Let's Encrypt is valid for a maximum of 90 days and must be renewed thereafter. This consideration applies only to Jenkins, Nexus, Grafana, and Kibana.

Default SSL for the Gateway

The Gateway's default SSL key can either be issued (via environment variables) or self-signed. For the beta release, Gateway cannot retrieve an SSL key from a third-party public Certificate Authority (CA) for initial client connections to the Gateway.

Security for the Elastic Stack

Beta release customers who are also Elastic Stack users shall be responsible for their own security solution for their own custom Elastic Stack. Elastic has a few recommended options in their product documentation.

You can’t perform that action at this time.