API Gateway 10.11 | Administering API Gateway | Container-based Provisioning | Kubernetes Support | OpenShift Support
 
OpenShift Support
 
Building a Docker Image for an API Gateway Instance in OpenShift Environment
Running the API Gateway Docker Image with the sagadmin User
OpenShift Sample Files
RedHat OpenShift is a container platform built upon and extends the Kubernetes functionality. In addition to Kubenetes' ability of orchestrating containerized applications, OpenShift provides support for the complete CI/CD life cycle of applications, called Source-To-Image.
The API Gateway OpenShift support provides the following, in the same way as the Kubernetes support does:
*Liveliness check. This helps in verifying that the API Gateway container is up and running.
*Readiness check. This helps in verifying that the API Gateway container is ready to server requests.
*Prometheus metrics to support the monitoring of API Gateway pods.
*Kubernetes-specific logging.
*Architectural patterns for running Elasticsearch as embedded, sidecar, or external.
*Auto scaling.
OpenShift extends Kubernetes and introduces new objects. For example, Kubernetes deployment is called DeploymentConfig and has the version id apps.openshift.io/v1 . In order to make services accessible from outside the cluster, OpenShift provides Route objects. The images required to start containers are not necessarily referenced directly inside the container specification, rather they can be managed by ImageStream objects.
OpenShift has a specific way for running ElasticSearch containers. ElasticSearch needs an increased virtual memory mmap count: vm.max_map_count >= 262144. In a plain Kubernetes environment you can solve this by adding an initContainer that has to run in the privileged mode. OpenShift offers a much simpler solution. If a pod carries a specific label then OpenShift applies the necessary system changes behind the scenes when starting the pod's containers.
For details on how these OpenShift specific topics are reflected in YAML configuration files for API Gateway, see OpenShift Sample Files.
When starting a new container, by default, OpenShift ignores the built-in user of the Docker image and injects a new user. This user is a member of the root group, and hence the files, scripts, and programs inside the container have to be readable, writable, and executable by the root group. To understand how to work with this OpenShift behavior, see the following sections:
* Building a Docker Image for an API Gateway Instance in OpenShift Environment
* Running the Docker Image With the sagadmin user