The following EntireX components are available as containers:
These containers can be deployed in a container orchestration environment, for example Kubernetes. This document covers the following topics:
A typical container orchestration environment has at least one master node and several worker nodes. Containers can be deployed on multiple worker nodes. If one node fails, the remaining nodes keep the application alive. The deployable unit for a worker node is called a pod. A pod consists of at least one container. Containers running in the same pod share the same network namespace (same IP and port space) and the same IPC namespace (visible to each other over PID). From outside the pod, containers are only reachable via sockets.
This example assumes you have a Kubernetes cluster installed.
To Deploy EntireX Broker, RPC Server for Java, and RPC Server for XML/SOAP in a Kubernetes cluster
Create a pod containing the images of EntireX Broker, RPC Server for Java, and RPC Server for XML/SOAP.
Note:
It makes sense to combine EntireX Broker and RPC servers for Java and XML/SOAP in one pod.
Configure a deployment for multiple broker and RPC server instances.
Assign a port to a service to access the broker and RPC servers from outside the Kubernetes cluster.
Use a ConfigMap to deploy the configuration files of your broker and RPC servers.
The following graphic shows the deployment of EntireX Broker, RPC Server for Java and RPC Server for XML/SOAP in a Kubernetes cluster:
Kubernetes uses YAML files to describe the deployment of pods, services and ConfigMaps. Below is a sample configuration file brokerRPCServer.yaml:
The sample file describes a deployment with four pods (replicas). Each pod contains three containers:
EntireX Broker
RPC Server for Java
RPC Server for XML/SOAP
With Kubernetes you can perform a healthcheck and a readiness check. The Kubernetes documentation uses the terms "liveness probe" and "readiness probe". The difference between the two probes is as follows:
When a liveness probe fails, the related pod is deleted and a new one is started.
When a readiness probe fails, the related pod is marked as "unready". This means that no messages will be sent to the related pod from the Kubernetes dispatcher.
Both the liveness and the readiness probe offer three kinds of checks:
TCP check on a specified port
HTTP check on a specified URL
user-defined function with return value true (healthy) or false (unhealthy)
In this example, a TCP check on administration port could be used as a readiness probe for the RPC Server for Java. The readiness probe can be defined in the YAML file of the pod deployment.
Example for the RPC Server for Java:
readinessProbe: failureThreshold: 3 initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 tcpSocket: port: 7001 timeoutSeconds: 1.
Probes have a number of fields that you can use to control more precisely the behavior of liveness and readiness checks:
Field | Default | Description |
---|---|---|
initialDelaySeconds |
0 | Number of seconds after the container has started before a liveness or readiness probe is initiated. |
periodSeconds |
10 | How often (in seconds) to perform the probe. Minimum value is 1. |
timeoutSeconds |
1 | Number of seconds after which the probe times out. Minimum value is 1. |
successThreshold |
1 | Minimum consecutive successes for the probe to be considered successful after having failed. Must be 1 for liveness. Minimum value is 1. |
failureThreshold |
3 | When a pod starts and the probe fails, Kubernetes will try failureThreshold times before giving up.
Minimum value is 1. |
For the RPC Server for Java a readiness check is defined (readiness probe).
The Kubernetes system checks the availability of the TCP port of the server (tcpSocket:port
).
This port must be defined as Administration Port defined in the properties file of the RPC Server for Java (entire.javarpcserver.properties
> entirex.server.monitorport
).
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: brokerandrpcserverdeployment labels: purpose: demonstrate-broker-and.jrpcserver-deployment spec: selector: matchLabels: app: entirex replicas: 4 template: metadata: labels: app: entirex spec: containers: - name: exxjavarpcserver-node-container image: repository.eur.ad.sag:4443/entirex/entirex-java-rpc readinessProbe: failureThreshold: 3 initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 tcpSocket: port: 7001 timeoutSeconds: 1 env: - name: ACCEPT_EULA value: "Y" volumeMounts: - mountPath: /licenses name: config - mountPath: /data name: data1 - name: exxxmlrpcserver-node-container image: repository.eur.ad.sag:4443/entirex/entirex-xml-rpc env: - name: ACCEPT_EULA value: "Y" volumeMounts: - mountPath: /licenses name: config - mountPath: /data2 name: data2 - name: exxbroker-container image: repository.eur.ad.sag:4443/entirex/entirex-broker env: - name: ACCEPT_EULA value: "Y" volumeMounts: - mountPath: /licenses name: config volumes: - name: config configMap: name: exx-configmap1 - name: data1 configMap: name: exx-configmap2 - name: data2 configMap: name: exx-configmap3