Deployment Assumptions

Below you can find the default on-premises deployment configuration and assumptions for SentiOne Automate.

Area	SentiOne's deployment assumptions
Installation platform	SentiOne Automate can be installed on the customer's environment (on-premise) or in the cloud, where in both cases the customer provides the infrastructure.
Internet access	⚠️ The customer provides Internet access: 1. from Kubernetes nodes for downloading Docker images from the Docker image repository provided by SentiOne. 2. from the administrator's system to the Helm charts repository provided by SentiOne. 3. from the administrator's system to the git repository provided by SentiOne.SentiOne provides login credentials for all services and the customer provides IP addresses (k8s, admin system) based on which SentiOne whitelists the traffic.
Kubernetes infrastructure	The customer provides the infrastructure, i.e. a Kubernetes cluster (provisioned on the customer's own infrastructure or using an existing solution delivered as a PaaS (e.g. AKS in Azure)). SentiOne uses the Ubuntu Server operating system LTS version for the Kubernetes infrastructure (control-plane and nodes).
Kubernetes infrastructure (HA)	The Kubernetes cluster may be provisioned with a HA configuration. The installation and configuration is prepared by the customer based on the official documentation for Kubernetes.
Infrastructure outside Kubernetes	SentiOne Automate currently depends on the following external services that must be provided (either via a dedicated instance or PaaS): RabbitMQ, ElasticSearch, PostgreSQL, NFS. SentiOne provides Ansible Playbooks, based on which the Administrator can automatically configure external services: RabbitMQ, ElasticSearch. The Playbooks are prepared for installing on servers running the Oracle Linux 7/8 operating system.
PostgreSQL database	It is possible to use an existing PostgreSQL database managed by the customer. In this case, SentiOne provides information on what databases should be created and what permissions the database user must have. The minimum version of the PostgreSQL database must be compatible with the one outlined in the Automate documentation.
PostgreSQL database (HA)	⚠️ The customer provides an HA mechanism for the PostgreSQL database.
RabbitMQ	The message queuing (MQ) system installed on a bare-metal server / VM.
RabbitMQ (HA)	It is possible to run RabbitMQ with HA - for this purpose, you need to create a RabbitMQ cluster consisting of min. 3 nodes (in a sample production configuration).
ElasticSearch	ElasticSearch database is installed on a bare-metal machine / VM.
ElasticSearch (HA)	It is possible to run ElasticSearch with HA - for this purpose, you need to create an ElasticSearch cluster consisting of min. 3 nodes (in a sample production configuration).
NFS	SentiOne provides instructions on how to configure an NFS resource that serves as a Persistent Volume resource for applications running in a Kubernetes cluster.
NFS (HA)	⚠️ The customer is responsible for configuring the NFS resource according to their own requirements.
GIT Repository	SentiOne provides the customer with a dedicated GIT repository with read and write (RW) rights, where the currently used configuration files related to the customer's environment are stored. Configuration files should be edited and stored by the customer in this repository for easier debugging. This is not mandatory, the customer can instead store the files on its internal git repository, but this hinders SentiOne support in such a case (SentiOne's access to the configuration repository allows the SentiOne Support team to track configuration changes made by the customer). The customer provides the details of the users on the customer side who are to be granted access and SentiOne creates the accounts.
Docker images	SentiOne provides pre-built Docker images via a private image repository. The Docker images provided by SentiOne are built based on containers running Oracle Linux. Applications are run in the containers as a non-root user.
Ingress	Services in the Kubernetes cluster that must be available outside the cluster via HTTP/HTTPS are provided by the Kubernetes Ingress API Object.
SSL Certificate	⚠️ Some Automate functionality requires the use of HTTPS (e.g. Clipboard API). The default configuration assumes the use of HTTP. The client is responsible for configuring TLS certificates and terminating HTTPS traffic.
Kubernetes Namespace	All manifests running in Kubernetes must be run in a single namespace.
External Reverse Proxy	⚠️ The customer provides an external Edge Proxy service. Services in the default configuration are made available to the user by Ingress Kubernetes.
Documentation	The Product documentation of the system in English is available here.
Version updates	Version updates are performed by the customer based on the instructions provided by SentiOne. We recommend a bi-monthly update cycle for Automate to keep up with the latest bug fixes and features.
Support / SLA	Technical issues are provided via a Service Desk system. Named accounts in the Service Desk system will be created by SentiOne based on the list of persons authorized to report errors provided by the Customer.
Helm	Installing and updating Automate and SentiOne is performed using Helm.
Access to K8S for SentiOne	To streamline the support process, SentiOne recommends that the customer provides SentiOne with administrator access to both the Kubernetes cluster (e.g., kubeconfig file) and the servers hosting dependent services (root or sudo access). The customer is responsible for providing network communication, having agreed on its form with SentiOne.
Staging Environments	SentiOne recommends a minimum of one test environment to verify both the process of updating the system and the state of the system itself after the update, before deploying it to a production environment.
Customer's Intranet	When installing Automate and SentiOne in a customer's environment, where environment-specific configurations (e.g., http(s) proxy in the absence of direct Internet access) are implemented that may affect system correctness or create problems during upgrades, the customer will adjust its environment to ensure that SentiOne-supplied systems work correctly.
System performance	Depending on the amount of traffic in the customer's environment, SentiOne provides 3 versions for the required infrastructure: Pod configuration. Customer agrees to provide resources (RAM/CPU/disk) as recommended by SentiOne.
Backups	⚠️ The customer is responsible for the process of regular backups of files and databases. The documentation for the PostgreSQL batabase backup can be found in the Database Maintenance section.
Monitoring	⚠️ The customer is responsible for the monitoring system (e.g. Grafana, Prometheus) as part of the implementation. Based on the Automate Monitoring documentation, customer can independently monitor the status of individual applications.
Collecting application log files	ℹ️ At the moment, logs can be viewed via kubectl command. SentiOne plans to deliver the log collection system (Loki stack) as part of the implementation by 15.11.2022.