What does a Verne – Catalyst Cloud deployment look like?

A Verne deployment contains everything required to run and operate Verne services.

Deploying Namespaces for Verne

Namespaces are a way to divide cluster resources in a project and deployment and allocating them to different groups of users. This is done by attaching authorisation and access control policies to a subsection of the cluster.

In the diagram above you can see that we have two namespaces to support Verne – one for Verne and supporting services accessible to Verne users and another one dedicated to Monitoring, Logging and Alerting services accessible to Admin users.

Monitoring

Monitoring services support the gathering and storage(Prometheus) of system-wide metrics including metrics from nodes(node exporter) as well as services cluster-wide. Administrator access to visualisation and alerting is also supplied using Grafana.

Logging

Logging services are intended to gathering logging events(using Fluentd) from the cluster itself as well as logging events from services in the cluster such as Verne. Log events are forwarded to ElasticSearch for storage and administrators can use Kibana for visualisation. This is a commonly used logging pattern call EFK (is the default logging pattern for OpenShift).

The EFK stack is a modified version of the ELK stack and contains:

  • Elasticsearch: An object store where all log events are stored.
  • Fluentd: Gathers logs from nodes and services and then forwards them to Elasticsearch.
  • Kibana: A web UI for Elasticsearch used for searching and visualisation.

Core Services

MongoDB, RabbitMQ, ElasticSearch and Kibana are core services and are deployed to the Verne namespace to support Verne.

Verne

Verne is deployed to the same namespace as the core services along with an ingress controller to enable public access. The ingress controller manages external access for the services in the cluster associated with the namespace.

GitOps – Automated Verne Deployment

GitOps is a way to do cluster management and application delivery automatically with no operations input without losing the benefits of release gates and other controls. GitOps is centred around using a version control system (such as Git) to source all information, documentation, and code for the deployment, and uses automated directors to deploy changes to the cluster. One of the most important functions of GitOps is to enable a group of system changes to be applied correctly and then verified.

0
0

Jump to Section