﻿# Install BRIX in Kubernetes

> [HTML Version](installing-elma365-enterprise.html)

BRIX On-Premises is installed in a Kubernetes cluster. It uses PostgreSQL, MongoDB, Redis database management systems, RabbitMQ service bus, and an S3 compatible object storage (MinIO). For more details, refer to the [Architecture](architecture.md) article.

Before starting the installation, read the [system requirements of BRIX On-Premises](elma365-enterprise-on-premises.md).

The installation consists of five steps:

1. [Prepare infrastructure (optional)](#prepare).

2. [Download the Helm chart and the configuration file](#helm_chart).

3. [Fill out the configuration file](#config_file).

4. [Install BRIX using helm in a Kubernetes cluster](#install).

5. [Install add-ons for BRIX (optional)](#install_addons).

While installing the BRIX application, you can [monitor the status of the pods and view their logs](#state).

## Step 1: Prepare infrastructure (optional)

By infrastructure we mean the necessary components for the operation of the BRIX On-Premises application.

````
начало внимание

````
The client deploys the dependent components independently. All work related to organizing a high-availability local architecture and setting up the high availability of dependent components is also done by the client.

````
конец внимание

````
Components necessary for BRIX On-Premises operation:

- Kubernetes cluster.

- PostgreSQL.

- MongoDB.

- RabbitMQ.

- Valkey or Redis.

- S3.

In this article, databases and the S3 storage are installed in the Kubernetes cluster as per the [Prepare embedded databases](embedded-databases-settings.md) article and use standard connection strings and passwords. This configuration is provided as an example for a trial installation only and is not a recommendation for production use. For a production environment, we recommend hosting [PostgreSQL](postgresql.md), [MongoDB](mongodb.md), and [S3](seaweedfs.md) on separate external resources.

Requirements for component configuration

#### Kubernetes

The system is installed using Helm in a Kubernetes cluster, which contains the following components: **ingress-nginx controller**, **coredns**, **rbac**, **storageclass**. For supported versions of Kubernetes and Helm, see the [System requirements for BRIX On-Premises ](elma365-enterprise-on-premises.md#kubernetes) article.

Also, proxying from pods to the external network should be allowed.

Read more about how to deploy a Kubernetes cluster in the [Kubernetes](kubernetes-air-gap.md) section.

#### Data storage

You can use your existing databases and S3 storage as components for BRIX On-Premises. There is also an option to combine your components with those deployed using the \[OBJECT\] or \[OBJECT\] charts. 

In a production environment, we recommend installing and configuring external PostgreSQL, MongoDB, and S3.

In the next installation steps, you will need to specify the connection strings to the databases and the S3 storage.

If there's a need to deploy all or just the missing components, refer to the articles in the [Databases](configure-postgresql.md) section.



#### High availability

To ensure continuous operation of BRIX on Bare-metal servers, it is necessary to build a high-availability Kubernetes cluster and ensure the operation of the used databases and S3 storage. For more details on building a high-availability environment for BRIX, refer to [Prepare BRIX On-Premises infrastructure](infrastructure-preparation.md).



#### Offline installation (Air-gap)

You can install BRIX in a closed-loop environment without direct access to the external container image storage. For this, on a computer with internet access, you need to download the BRIX application images and import them into a local image repository. Read more in [Download BRIX images](downloadin-images-elma365.md).

You can skip this section if the component configuration requirements are met and there’s no need to deploy components necessary for the operation of BRIX On-Premises.

## Step 2: Download the Helm chart and configuration file

Obtain the `values-brix365.yaml `configuration file for installation via the internet:

-  For the latest version of the system by executing the following command:

````
helm repo add brix365 https://charts.brix365.com  
helm repo update  
helm show values brix365/brix365 > values-brix365.yaml

- ````
For the certain version of the system by executing the \[OBJECT\] command with the \[OBJECT\] flag:

````
helm repo add brix365 https://charts.brix365.com  
helm repo update  
helm show values brix365/brix365 --version <brix365-chart-version> > values-brix365.yaml 

````
Where \[OBJECT\] is the system version required.

Obtaining the configuration file for installation in an isolated environment without internet access

1. On a computer with internet access, download BRIX images and upload them to the local image registry. Read more in the [Download BRIX images](downloadin-images-elma365.md) article.

2. Download the archive of the latest version of the BRIX On-Premises chart from the \[OBJECT\] repository by executing the following command:

````
helm repo add brix365 https://charts.brix365.com  
helm repo update  
helm pull brix365/brix365

3. ````
Copy the received chart archive \[OBJECT\] to the server where the installation will take place.

4. Unpack the obtained chart on the server and copy the default configuration file \[OBJECT\] to \[OBJECT\]. To do this, run the following command:

````
tar -xf brix365-X.Y.Z.tgz  
cp brix365/values.yaml values-brix365.yaml
````

## ````
Step 3: Fill out the configuration file 

For a quick start of the app, fill out the main parameters:

- \[OBJECT\]: domain (FQDN) or IP address by which the system will be accessible. The IP address is only valid in limited scenarios, such as when not using Ingress/Nginx with host-based routing and TLS with SNI.

- `global.edition`: specify the edition of the BRIX application to be installed.

- \[OBJECT\]: administrator’s email.

- \[OBJECT\]: administrator’s password.

- \[OBJECT\]: connection string to the PostgreSQL DB.

- \[OBJECT\]: connection string to the MongoDB for the app.

- \[OBJECT\]: connection string to the MongoDB for the authorization server.

- \[OBJECT\]: connection string to Valkey or Redis.

- \[OBJECT\]: connection string to RabbitMQ.

- \[OBJECT\]: request method to S3.

- \[OBJECT\]: S3 username.

- \[OBJECT\]: password for the S3 user. Use the [acceptable characters](#acceptable-symbols).

- \[OBJECT\]: S3 bucket.

- \[OBJECT\]: S3 address.

- \[OBJECT\]: S3 region.

- \[OBJECT\]: enabling S3 SSL.

````
начало примечание

````
**Note**

The following characters are acceptable for passwords:

- Uppercase Latin letters: A to Z.

- Lowercase Latin letters: a to z.

- Numbers: 0 to 9.

- Characters:  -\_.

Reserved (unacceptable) characters:

\! \* ' ( ) ; : @ \& = + \$ , / ? % # \[ \] \{ \}

````
конец примечание

````
Fill in the variables in the \[OBJECT\] file by performing the following actions:

1. Set the FQDN domain or IP address through which the system will be accessible in the \[OBJECT\] parameter.

In the article [Prepare embedded databases](embedded-databases-settings.md), on step 1, you should have prepared an S3 MinIO storage, which is accessible via the FQDN domain \[OBJECT\]. When using the built-in S3 storage accessible by the FQDN, BRIX should be accessible under the same domain name. To do this, in \[OBJECT\] specify \[OBJECT\] and enable the \[OBJECT\] binding to the domain \[OBJECT\]. To do this, set the value true for the \[OBJECT\] parameter.

````
global:  
  # domain (FQDN) or IP address where the system will be available  
  host: 'brix365\_server.your\_domain'  
  ingress:  
    hostEnabled: true

2. ````
In the `global.edition` parameter, specify the BRIX edition: `enterprise` or `standard`.

3. Complete the company creation parameters in the \[OBJECT\] section. The company will be created during the BRIX installation.

4. Set the administrator’s email address in the \[OBJECT\] parameter. This address will serve as the login for the main administrator.

````
Начало внимание

````
The main administrator’s login cannot be changed after the system installation.

````
Конец внимание

5. ````
Indicate, according to your security policy, the password for the main administrator’s login in the \[OBJECT\] parameter. Use the [acceptable characters](#acceptable-symbols).

6. Set the company language in the \[OBJECT\] parameter, for example, en-US:

````
bootstrapCompany:  
  # Admin email  
  email: "admin@mail.com"  
  # Admin password  
  password: "test"  
  # Installed system language, possible options: "ru-RU", "en-US", "sk-SK"  
  locale: "en-US"

7. ````
Set the installed system language in the language.default parameter, for example, en-US:

````
language:  
  # Installed system language, possible options: "ru-RU", "en-US", "sk-SK"  
  default: "en-US"

8. ````
 Fill in the connection strings for the PostgreSQL, MongoDB, RabbitMQ, Valkey or Redis databases. To do this, you need to fill in the following parameters: \[OBJECT\], \[OBJECT\], \[OBJECT\], \[OBJECT\], \[OBJECT\].

````
db:  
 # Connection string for Postgres DB, format:  
postgresql://user:password@hostname:5432/databaseName  
 psqlUrl: 'postgres://postgres:pgpassword@postgres.brix365-dbs.svc.cluster.local:5432/brix365?sslmode=disable'  
 # Connection string for read-only Postgres DB, format:  
postgresql://user:password@hostname:5432/databaseName  
 roPsqlUrl: ''  
 # Connection string for the MongoDB for the application, format:  
mongodb://user:password@hostname:27017/databaseName  
 mongoUrl: 'mongodb://brix365:mongopassword@mongo.brix365-dbs.svc.cluster.local:27017/brix365?ssl=false\&replicaSet=rs0\&readPreference=secondaryPreferred'  
 # Connection string for MongoDB for the authorization server, format:  
mongodb://user:password@hostname:27017/databaseName  
 vahterMongoUrl: 'mongodb://brix365:mongopassword@mongo.brix365-dbs.svc.cluster.local:27017/brix365?ssl=false\&replicaSet=rs0\&readPreference=secondaryPreferred'  
 # Connection string for Redis, format:  
redis://user:password@redis.local:6379/databaseName  
 redisUrl: 'redis://redis.brix365-dbs.svc.cluster.local:6379/0'  
 # Connection string for Rabbit, format:  
amqp://user:password@hostname:5672/vhost  
 amqpUrl: 'amqp://brix365:rmqpassword@rabbitmq.brix365-dbs.svc.cluster.local:5672/brix365'

9. ````
Fill in the parameters for connecting to the S3 file storage:

- \[OBJECT\]: S3 request method.

- \[OBJECT\]: S3 username.

- \[OBJECT\]: password for the S3 user. Use the [acceptable characters](#acceptable-symbols).

- \[OBJECT\]: S3 bucket.

- \[OBJECT\]: S3 address.

- \[OBJECT\]: S3 region.

- \[OBJECT\]: enable S3 SSL.

````
db:  
 s3:  
   method: PUT  
   accesskeyid: PZSF73JG72Ksd955JKU1HIA  
   secretaccesskey: aFDkj28Jbs2JKbnvJH678MNwiz88zKjsuNBHHs  
   bucket: s3brix365  
   backend:  
     address: brix365\_server.your\_domain  
     region: us-east-1  
   ssl:  
     enabled: "false"

````


Filling in the connection parameters to a private registry for installation in an isolated environment without internet access

1. Set the address and path in the \[OBJECT\] parameter.

2. Indicate the name of the secret with access rights to the private registry in the \[OBJECT\] parameter. The private registry should be manually created and encrypted in Base64 global:

````
 # Address and path for private registry  
 image:  
   repository: registry.example.com/images/brix365  
   # Secret with access permissions for the private registry must be created manually,   
   encoded in Base64   
   pullSecret:  
     - name: myRegistryKeySecretName

````
  
Where format of \[OBJECT\] is:

- \[OBJECT\]: the address.

- \[OBJECT\]: the path.



The configuration file \[OBJECT\] contains a large number of parameters for the BRIX On-Premises application. For a more comprehensive guide on filling in variables in this file, see the [Modify BRIX parameters](change-settings-enterprise.md) article.

## Step 4: Install BRIX using helm in the Kubernetes cluster

1. If a namespace for installing BRIX hasn't yet been created, add it using the command:

````
kubectl create namespace brix365

````
Where `brix365` is the name of the namespace.

2. This step is optional. To avoid specifying a namespace in commands in the current session, you can set the default namespace in the Kubernetes context. To do this, use the command:

````
kubectl config set-context --current --namespace=brix365

3. ````
In the \[OBJECT\] for BRIX installation, change the value for the Deckhouse security policy to \[OBJECT\] to avoid errors when deploying services. To do this, run the command:

````
kubectl label namespace brix365 security.deckhouse.io/pod-policy=privileged --overwrite

4. ````
Install  BRIX using the configuration file \[OBJECT\]. If you need to install the application in a separate namespace, specify it in the installation command:

````
helm upgrade --install brix365 brix365/brix365 \\  
\-f values-brix365.yaml \\  
\--timeout=30m --wait \[-n brix365\]

````
To install the BRIX application in an isolated environment without internet access, run the following command:

````
helm upgrade --install brix365 ./brix365 \\  
\-f values-brix365.yaml \\  
\--timeout=30m --wait \[-n brix365\]

````
The installation time for the BRIX application takes 10-30 minutes. Wait for the update of the BRIX  application parameters.

5. Open a browser and navigate to the BRIX login page at \[OBJECT\]. The \[OBJECT\] parameter was specified in the \[OBJECT\] configuration file in the step of downloading the helm chart and configuration file.  
  
In the given example, the following login page address for the BRIX application is used: [http://example.com](http://example.com).  
**(installing-elma365-enterprise-1.png)**

6. Use the administrator’s email address as the login and the password you used in the \[OBJECT\] configuration file for the parameters \[OBJECT\] and \[OBJECT\].  
  
In the given example, the following are used:

- **Login: admin@mail.com.**

- **Password: test.**

7. Click the **Login to the system** button.  
The BRIX application window will open.

8. Activate the system. For more details, see [Activate BRIX On-Premises](activate_on_premise.md).

The installation of the BRIX application has been successfully completed.

````
начало внимание

````
Save the \[OBJECT\] configuration file for future updates.

````
конец внимание

````


## Step 5: Install add-ons for the BRIX application (optional)

Under add-ons for the BRIX application, components are understood that extend the functional and infrastructure capabilities of the BRIX application.

Add-ons list:

- [Linkerd](install-linkerd.md) routing system (Service Mesh).

- [Prometheus + Grafana monitoring system](install-monitoring-tools.md).

- [Descheduler](install-descheduler.md).

- [NodeLocal DNSCache](install-nodelocal-dns-cache.md).

- [Kyverno](install-kyverno.md).

- [KEDA](install-keda.md).

- The [Security Audit](install-audit-service.md) service for system versions lower than 2026.4.

Add-ons are installed as needed, considering the existing infrastructure. Articles in the [Install add-on components for BRIX](install-descheduler.md) section will help decide whether you should to install an add-on component.

## Monitor BRIX application status



During BRIX installation, you can use the following commands:



1. To monitor pod status in real time:

````
kubectl get pods -n brix365 -w

````


This allows you to monitor the statuses of all pods in the `brix365` namespace in real time. You can see when pods start, restart, or stop with an error.



2. To view pod logs:

````
kubectl logs -f <pod\_name> -n brix365

````


Where:



- `<pod\_name>` is the name of the desired pod.

- `-f` is the command for monitoring new entries.

