Installation¶

Une fois les prérequis en place (Ansible, Docker Swarm et initialisation du cluster), il est possible de personnaliser le déploiement de INFRA à l’aide de variables Ansible. Ces options permettent notamment de configurer la gestion des portails utilisateurs, de la base de données, des serveurs signaux, des certificats SSL etc.

Tip

La configuration des paramètres d’installation doit être définie avant l’exécution de la commande d’installation finale.

Important

Avant l’installation finale de l’environnement INFRA, toutes les machines cibles doivent pouvoir accéder aux images nécessaires à leur déploiement.

Pour la gestion des images Docker, merci de vous référer à la documentation sur la Gestion du Registre et des Images de l’environnement INFRA.

Création d’un playbook minimal¶

Pour la suite de l’installation, il est nécessaire de créer un playbook qui sera nommé reemo-infra.yml dans le reste de cette documentation.

- name: Installation Reemo Infra Server
    hosts: infra_manager
    gather_facts: yes

    roles:
        - reemo-infra

Fichier inventaire minimal¶

Pour la suite de l’installation, il est nécessaire d’avoir créé un inventaire qui sera nommé inventory.yml dans le reste de cette documentation. Ce fichier minimal est décrit dans la page Prérequis de l’environnement INFRA.

Il contient la description de l’infrastructure des serveurs ainsi que la clé de licence Reemo au format base64.

Exemple sur un seul server:

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="

    infra_manager:
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"

Certificats SSL¶

Toutes les connexions utilisateurs passent par un service Traefik. L’infrastructure utilise des certificats SSL pour l’exposition du Portail à travers Traefik ainsi que pour les communications internes de la plateforme des différents services.

Important

Il est conseillé d’utiliser une PKI différente pour les communications internes de celle utilisée pour Traefik.

Traefik¶

Trois modes sont disponibles :

Certificat par défaut¶

Par défaut, un certificat autosigné est généré automatiquement lors de la création du conteneur Traefik. Ce mode est adapté pour des environnements de test, mais il n’est pas recommandé en production.

Certificat local¶

Vous pouvez fournir un certificat et une clé stockés sur la machine Ansible. Le rôle reemo-infra se charge de déployer ces fichiers sur les serveurs hébergeant Traefik.

Exemple d’inventaire :

TRAEFIK_SSL_CERTS:
    - cert_file: "/localpath/to/cert.crt"
      key_file: "/localpath/to/key.key"

Certificat déjà présent sur le serveur¶

Si les certificats sont déjà installés sur les serveurs cibles, vous pouvez indiquer leurs chemins locaux. Ils seront ensuite montés directement dans le conteneur Traefik.

Exemple d’inventaire :

TRAEFIK_SSL_CERTS_REMOTE:
    - cert_file_remotepath: "/remotepath/to/cert.crt"
      key_file_remotepath: "/remotepath/to/key.key"

Communication internes¶

L’ensemble des micro-services discute entre eux en mTLS imposant une gestion des certificats.

Vous avez 3 choix possibles:

PKI par défaut¶

Le rôle Ansible reemo-infra embarque une PKI dédiée complète et prête à l’emploi. Elle permet un déploiement simple avec des communications internes chiffrées et authentifiées.

CA générée automatiquement¶

Il est possible d’utiliser une autorité de certification (CA) générée automatiquement lors de l’exécution du rôle reemo-infra.

Étapes à suivre :

Créer un répertoire local sur la machine Ansible, accessible en écriture par l’utilisateur exécutant Ansible.
Ajouter dans le fichier d’inventaire les options nécessaires pour activer cette fonctionnalité.

all:
    vars:
        LOCAL_PATH: "/opt/reemo/ssl"
        INITCA_ENABLE: "true"
    infra_manager:
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"
            infra_manager2:
                ansible_host: "10.0.0.2"
            infra_manager3:
                ansible_host: "10.0.0.3"

Lors du lancement du rôle, une CA sera créée automatiquement dans ce répertoire. Les clés et certificats associés seront ensuite exportés vers le cluster Docker Swarm sous forme de Secrets et montés dans les différents conteneurs qui en ont besoin.

Configuration manuelle¶

Il est aussi possible de générer soi-même les certificats SSL pour les URLs :

reemo_portal
reemo_portaladmin
reemo_api
reemo_proapi
reemo_signal
reemo_provision
reemo_prorelayapi
reemo_procloudapi
reemo_relayws

Il faut ensuite renseigner dans l’inventaire Ansible les chemins locaux des clés et certificats. Ils seront copiés automatiquement vers le cluster Docker Swarm par le rôle reemo-infra.

Exemple :

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        ...
    infra_manager:
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"
            infra_manager2:
                ansible_host: "10.0.0.2"
            infra_manager3:
                ansible_host: "10.0.0.3"
        vars:
            CA_SSL_CRT_LOCALPATH: "/local/path/ca.crt"
            API_SSL_CRT_LOCALPATH: "/local/path/reemo_api.crt"
            API_SSL_KEY_LOCALPATH: "/local/path/reemo_api.key"
            PROAPI_SSL_CRT_LOCALPATH: "/local/path/reemo_proapi.crt"
            PROAPI_SSL_KEY_LOCALPATH: "/local/path/reemo_proapi.key"
            PRORELAYAPI_SSL_CRT_LOCALPATH: "/local/path/reemo_prorelayapi.crt"
            PRORELAYAPI_SSL_KEY_LOCALPATH: "/local/path/reemo_prorelayapi.key"
            SIGNAL_SSL_CRT_LOCALPATH: "/local/path/reemo_signal.crt"
            SIGNAL_SSL_KEY_LOCALPATH: "/local/path/reemo_signal.key"
            PORTAL_SSL_CRT_LOCALPATH: "/local/path/reemo_portal.crt"
            PORTAL_SSL_KEY_LOCALPATH: "/local/path/reemo_portal.key"
            TRAEFIK_SSL_CERTS:
                - cert_file: "/local/path/domain.crt"
                  key_file: "/local/path/domain.key"

Gestion du Portail Utilisateur et Administrateur¶

URL des Portails¶

Par défaut les serveurs Infra et Portal répondent sur toutes les requêtes avec un certificat autosigné.

Si vous avec besoin de paramètrer une URL spécifique pour le Portail utilisateur, il faut utiliser la variable suivante:

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        ...
    infra_manager:
        vars:
            PORTAL_URL: "url.domain.tld"
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"
            infra_manager2:
                ansible_host: "10.0.0.2"
            infra_manager3:
                ansible_host: "10.0.0.3"

Si vous avec besoin de paramètrer une URL spécifique pour le Portail administrateur, il faut utiliser la variable suivante:

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        ...
    infra_manager:
        vars:
            PORTAL_URL: "url.domain.tld"
            PORTALADMIN_URL: "urladmin.domain.ltd"
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"
            infra_manager2:
                ansible_host: "10.0.0.2"
            infra_manager3:
                ansible_host: "10.0.0.3"

Important

Il est recommandé de ne pas exposer le Portail Administrateur vers un réseau externe. Ce portail est destiné à être utilisé dans votre réseau interne.

Warning

Avec PORTALADMIN_URL activé, les administrateurs ne peuvent plus se connecter via l’URL du portail utilisateur.

Filtrage IP¶

Il est possible d’activer le filtrage sur IP des portails utilisateurs et administrateurs.

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        ...
    infra_manager:
        vars:
            PORTAL_URL: "url.domain.tld"
            PORTAL_URL_RESTRICT_IP: "10.1.1.1,10.2.2.0/24"
            PORTALADMIN_URL: "urladmin.domain.ltd"
            PORTALADMIN_URL_RESTRICT_IP: "10.3.1.2,10.3.2.0/24"
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"
            infra_manager2:
                ansible_host: "10.0.0.2"
            infra_manager3:
                ansible_host: "10.0.0.3"

Gestion des Ports¶

Par défaut le Portail utilisateurs répond sur le port 443 avec une redirection automatique du port 80 vers le port 443 en SSL.

Pour le Portail administrateurs il est possible de spécifier le port:

PORTALADMIN_URL_PORT: "8444"

Warning

Le port doit être différent de 80, 443 et 8443 qui sont déja utilisés pour d’autres services

Séparation physique des Portails¶

Le rôle Ansible reemo-infra vous permet de séparer physiquement le Portail Utilisateurs et le Portail Administrateurs.

Portail dédié aux administrateurs d’instance¶

../../_static/images/infra/archi_infra_multidmz.png

Pour cela il vous suffit de créer un fichier inventaire en remplacant le groupe infra_manager par 2 groupes api_manager et portal_manager.

Note

Il vous faudra renseigner dans les variables un HMACSECRET qui sera partagé entre les 2 portails et l’API. Ce secret est utilisé pour signer les requêtes en provenance des portails vers l’API.

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        HMACSECRET: "U6US67D70409RFAGQH5ZIWBFV8HX0UCZ"
portal_manager:
        children:
            portaluser_manager:
                vars:
                    PORTAL_URL: "url.domain.tld"
                    TRAEFIK_SSL_CERTS:
                        - cert_file: "/localpath/to/cert.crt"
                          key_file: "/localpath/to/key.key"
                    API_IP:
                        - ip: "10.3.1.1"
                        - ip: "10.3.1.2"
                        - ip: "10.3.1.3"
                hosts:
                    portaluser1:
                        ansible_host: "10.0.0.1"
                    portaluser2:
                        ansible_host: "10.0.0.2"
                    portaluser3:
                        ansible_host: "10.0.0.3"
            portaladmin_manager:
                vars:
                    PORTAL_URL: "admin.domain.tld"
                    TRAEFIK_SSL_CERTS:
                        - cert_file: "/localpath/to/cert.crt"
                          key_file: "/localpath/to/key.key"
                    API_IP:
                        - ip: "10.3.1.1"
                        - ip: "10.3.1.2"
                        - ip: "10.3.1.3"
                hosts:
                    portaladmin1:
                        ansible_host: "10.0.0.4"
                    portaladmin2:
                        ansible_host: "10.0.0.5"
                    portaladmin3:
                        ansible_host: "10.0.0.6"
api_manager:
        hosts:
            api1:
                ansible_host: "10.3.1.1"
            api2:
                ansible_host: "10.3.1.2"
            api3:
                ansible_host: "10.3.1.3"^

Warning

Il est important de noter que dans l’exemple ci-dessus, les URLs renseignées utilisent la variable PORTAL_URL et ce même pour le portail administrateur. C’est la valeur à utiliser lorsqu’un seul portail est déclaré sur un serveur particulier.

Portail dédié à un SSO¶

En plus d’une séparation physique vous pouvez aussi restreindre les connecteurs SSO par portail.

../../_static/images/infra/onprem_multiconnector.png

Lors de la creation d’un connecteur vous obtenez un GUID qu’il faut ensuite renseigner dans le fichier inventaire dans la section du portal ciblé avec une variable nommée PORTAL_LDAP_CONNECTORS pour les connecteurs LDAP et PORTAL_SAML_CONNECTORS pour les connecteurs SAML

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        HMACSECRET: "..."
portal_manager:
        children:
            portalsso_manager:
                vars:
                    PORTAL_URL: "urlldap.domain.tld"
                    TRAEFIK_SSL_CERTS:
                        - cert_file: "/localpath/to/cert.crt"
                          key_file: "/localpath/to/key.key"
                    PORTAL_LDAP_CONNECTORS:
                        - ldapid: "3182932d-9ee1-4c06-a4cf-c13c25f2ee93"
                    PORTAL_SAML_CONNECTORS:
                        - samlid: "692469bd-cb28-8332-aa65-9c95451c1a0e"
                hosts:
                    portalsso1:
                        ansible_host: "10.0.0.7"
                    portalsso2:
                        ansible_host: "10.0.0.8"
                    portalsso3:
                        ansible_host: "10.0.0.9"    

Si vous avez plusieurs connecteurs à renseigner sur un meme portail, rajouter autant de ligne avec ldapid ou samlid

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        HMACSECRET: "..."
portal_manager:
        children:
            portalsso_manager:
                vars:
                    PORTAL_URL: "urlsso.domain.tld"
                    TRAEFIK_SSL_CERTS:
                        - cert_file: "/localpath/to/cert.crt"
                          key_file: "/localpath/to/key.key"
                    PORTAL_LDAP_CONNECTORS:
                        - ldapid: "3182932d-9ee1-4c06-a4cf-c13c25f2ee93"
                        - ldapid: "9c713681-b758-4179-b9a2-13618a7b804e"
                    PORTAL_SAML_CONNECTORS:
                        - samlid: "692469bd-cb28-8332-aa65-9c95451c1a0e"
                        - samlid: "4418cfb9-52c5-4d7c-88d1-7660e7809d23"
                hosts:
                    portalsso1:
                        ansible_host: "10.0.0.7"
                    portalsso2:
                        ansible_host: "10.0.0.8"
                    portalsso3:
                        ansible_host: "10.0.0.9"

Serveur Signal par Portail¶

Afin de séparer complètement les portails, vous avez la possibilité de leur assigner des serveurs Signaux spécifiques qui seront utilisés par les conteneurs lancés depuis ces portails.

portal_manager:
    vars:
        API_IP:
            - ip: "10.0.0.1"
    children:
        portal1_user:
            hosts:
                portal1_user1:
                ansible_host: "10.0.0.2"
                PORTAL_URL: "portal1.domain.tld"
                PROVISION_SIGNAL_IP:
                    - ip: "10.0.0.2"
        portal2_user:
            hosts:
                portal2_user1:
                ansible_host: "10.0.0.3"
                PORTAL_URL: "portal2.domain.tld"
                PROVISION_SIGNAL_IP:
                    - ip: "10.0.0.3"

Filtrage des roles utilisateurs sur un Portail¶

Vous pouvez restreindre le type d’utilisateurs autorisés à se connecter à un portail particulier. Le filtrage s’effecture sur le rôle des utilisateurs.

Administrateur d’instance
Administrateur d’organisation
Membre d’une organisation

Portail Principal¶

Par défaut, tous les utilisateurs peuvent s’authentifier sur un portail, mais avec l’option PORTAL_TYPE il est possible d’en restreindre l’accès à un type d’utilisateur.

PORTAL_TYPE	par défaut	user	admin	orgadmin	instadmin	orguser
Administrateur d’instance
Administrateur d’organisation
Membre d’une organisation

Portail Admin¶

Le portail secondaire est configuré par défaut comme un portail dédié aux administrateurs. Vous pouvez spécifier quels types d’administrateurs peuvent se connecter en utilisant la variable PORTALADMIN_TYPE.

PORTALADMIN_TYPE	par défaut	orgadmin	instadmin
Administrateur d’instance
Administrateur d’organisation
Membre d’une organisation

Exemple avec un portail dédié aux utilisateurs et le portail administrateur dédié uniquement aux administrateurs d’instance:

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        HMACSECRET: "..."
portal_manager:
    children:
        portaluser_manager:
            vars:
                PORTAL_URL: "url.domain.tld"
                PORTAL_TYPE: "user"
                TRAEFIK_SSL_CERTS:
                    - cert_file: "/localpath/to/cert.crt"
                        key_file: "/localpath/to/key.key"
            hosts:
                portaluser1:
                    ansible_host: "10.0.0.1"
                portaluser2:
                    ansible_host: "10.0.0.2"
                portaluser3:
                    ansible_host: "10.0.0.3"
        portaladmin_manager:
            vars:
                PORTAL_URL: "admin.domain.tld"
                PORTAL_TYPE: "instadmin"
                TRAEFIK_SSL_CERTS:
                    - cert_file: "/localpath/to/cert.crt"
                        key_file: "/localpath/to/key.key"
            hosts:
                portaladmin1:
                    ansible_host: "10.0.0.4"
                portaladmin2:
                    ansible_host: "10.0.0.5"
                portaladmin3:
                    ansible_host: "10.0.0.6"
api_manager:
    hosts:
        api1:
            ansible_host: "10.3.1.1"
        api2:
            ansible_host: "10.3.1.2"
        api3:
            ansible_host: "10.3.1.3"

Services de Signalisation¶

Les services de Signalisation sont utilisés pour l’enregistrement des Agents Reemo sur la plateforme, mais aussi pour l’échange d’informations nécessaires à l’établissement d’une connexion entre l’utilisateur et ses ressources. Ces services ont la particularité d’être unique et dans un environnement Docker Swarm vous verrez apparaitre en fonction de votre architecture plusieurs services de Signalisation avec toujours un seul replica.

Exemple:

ID             NAME            MODE        REPLICAS  IMAGE
...
 g8hmzpicyq2o   reemo_signal1   replicated  1/1      registry.reemo.io/reemoinfrasignal                   
 s105if31h6l0   reemo_signal2   replicated  1/1      registry.reemo.io/reemoinfrasignal

Tip

Les services de Signalisation seront toujours nommés reemo_signal suivi d’un chiffre.

Ports¶

Par défaut les services de Signalisation écoutent sur le port 8443 à travers service Traefik qui portera le certificat SSL. Ce port sera accessible par les Agents Reemo. Les utilisateurs le contacteront par le service Portal sur le port 443

SSL¶

Les certificats sont gérés de la même façon que pour les portails, un premier certificat pour le Traefik, un second pour la communication entre Traefik/Portal et les services de Signalisation.

Multi-signal¶

Dans une installation classique, les agents Reemo viennent s’enregistrer sur les services de signalisation qui sont partagés par les différents portails d’accès utilisateurs. Pour une séparation complète des portails et des agents, il est possible de configurer une installation multi-signal. Chaque portails et environnements de provisioning utiliseront leurs propres services de signalisation pour garantir une séparation complète des environnements utilisateurs.

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
        HMACSECRET: "..."
portal_manager:
    vars:
        API_IP:
            - ip: "10.0.0.3"
    children:
        portal1_user:
            hosts:
                portal1_user1:
                    ansible_host: "10.0.0.1"
                    PORTAL_URL: "portal1.domain.tld"
                    PROVISION_SIGNAL_IP:
                        - ip: "10.0.0.1"
        portal2_user:
            hosts:
                portal2_user1:
                    ansible_host: "10.0.0.2"
                    PORTAL_URL: "portal2.domain.tld"
                    PROVISION_SIGNAL_IP:
                        - ip: "10.0.0.2"

CRON¶

Plusieurs services CRON sont utilisés dans une plateforme Reemo.

Important

Il est impératif que ces services soient unique. Dans le cas de l’utilisation de plusieurs serveurs/clusters infra ou api, il faut choisir le serveur/cluster devant prendre en charge ces services et les désactiver dans les autres par l’option CRON_ENABLE: “false”.

APICRON¶

Ce service est responsable de la gestion générale des tâches de la plateforme.

Option disponible:

API_cronGhostContainersMinutes: permet de régler le temps d’expiration des conteneurs qui continuent à être UP dans l’environnement PROVISION mais qui n’ont plus d’existence connue par l’interface aussi appelés Conteneurs fantômes.

APICRONLOG¶

Service permettant la suppression programmée des logs et évènements qui dépassent la période de rétention configurée.

Options disponibles:

API_CRONLOG_INTERVAL: Intervalle entre 2 requetes de suppression de logs en heure (24 heures par défaut)
API_CRONLOG_RETENTION: Temps de rétention des logs en mois (12 mois par défaut)

APICRONLDAP¶

Service permettant la synchronisation avec un serveur LDAP.

Option disponible:

API_CRONLDAP_INTERVAL: Intervalle en minutes entre chaque synchronisation avec le serveur LDAP (60 minutes par défaut)

Base de données¶

L’environnement INFRA nécessite une base de données qui peut être interne ou externe à Docker Swarm

Base de données externe¶

Pour configurer l’accès à une base de données externe, vous pouvez renseigner les variables suivantes en fonction du moteur de la base:

MySQL¶

DB_USER: "< Utilisateur pour s'authentifier sur la base de données >"
DB_USER_PASSWORD: "< Mot de passe pour s'authentifier sur la base de données >"
DB_NAME: "< Nom de la base de données >"
DB_HOST: "< IP >"
DB_DIALECT: "mysql"

PostgreSQL¶

DB_USER: "< Utilisateur pour s'authentifier sur la base de données >"
DB_USER_PASSWORD: "< Mot de passe pour s'authentifier sur la base de données >"
DB_NAME: "< Nom de la base de données >"
DB_HOST: "< IP >"
DB_DIALECT: "postgresql"

Ajout du support SSL¶

Pour ajouter le support SSL pour la connexion à la base de données, vous pouvez utiliser les options suivantes, à rajouter dans le fichier inventaire d’Ansible

DB_SSL_REQUIRE: "true"
DB_SSL_CERT_LOCALPATH: "/local/path/cert.crt"
DB_SSL_KEY_LOCALPATH: "/local/path/key.key"
DB_SSL_CA_LOCALPATH: "/local/path/ca.crt"

Base de données interne¶

Par défaut un serveur MySQL est présent dans le rôle reemo-infra, il sera déployé et configuré automatiquement si une base de données externe n’est pas renseignée.

MySQL¶

Par défaut une base de données MySQL est déployée dans l’environnement Docker Swarm.

Sur une architecture à un seul serveur, le répertoire local /opt/reemo sera monté dans le conteneur MySQL pour y installer la base de données.

Warning

Si vous ne souhaitez pas utiliser MySQL NDBCLUSTER, il faut prévoir une réplication entre les répertoires /opt/reemo pour que le conteneur MySQL puisse se relancer sur un autre noeud en cas d’arrêt et conserver l’ensemble de ces données de la base existante.

MySQL NDBCLUSTER¶

Pour activer l’utilisation d’une base de données MySQL NDBCLUSTER, ajouter l’option DB_DIALECT=NDBCLUSTER dans le fichier inventaire, et les noms des différents hostnames composant votre cluster Swarm:

all:
    vars:
        API_LICENSE: "ewogICAg ... Uw5NXhGVDF0NFU2TkxOdjQvZU53PT0iCiAgICC9Cn0="
    infra_manager:
        vars:
            DB_DIALECT: "NDBCLUSTER"
            MYSQL_CLUSTER_DataMemory: 2G # permet d'augmenter la mémoire de la base de données (par défaut 2G)
            MYSQL_CLUSTER_PATH: "/data/mysqlcluster" # Chemin où seront stockés les informations des différents services NDBCLUSTER (par défaut "/data/mysqlcluster")
            MYSQL_NODE_HOSTNAME_DB1: "infra1"
            MYSQL_NODE_HOSTNAME_DB2: "infra2"
            MYSQL_NODE_HOSTNAME_DB3: "infra3"
        hosts:
            infra_manager1:
                ansible_host: "10.0.0.1"
            infra_manager2:
                ansible_host: "10.0.0.2"
            infra_manager3:
                ansible_host: "10.0.0.3"

Tip

NDBCLUSTER requiert un minimum de 8 Go de RAM par noeud.

Warning

La latence recommandée est de l’ordre de moins de 1 ms entre les noeuds, entre 1 et 5 ms les performances peuvent chuter, au dessus de 5 ms risque de ralentissements et d’instabilités

Initialisation de la base de données¶

Avant de pouvoir être utilisée, la base de données nécessite d’être initialisée.

L’initialisation de la base de données permet en même temps d’initialiser les valeurs par défaut de l’instance Reemo qui seront ensuite stockées dans la base de données.

Voici les variables par défaut qu’il est possible de configurer à l’initialisation de la base de données:

INIT_MINIMUM_PASSWORD_LENGTH: "8"
INIT_PASSWORD_REQUIRE_LETTERS: "false"
INIT_PASSWORD_REQUIRE_DIGITS: "false"
INIT_PASSWORD_REQUIRE_SPECIALCHAR: "false"

L’initialisation de la base de données se fait lors de l’installation finale en utilisant la variable INIT_DB=true

Note

L’initialisation de la base de données n’est à exécuter qu’une seule fois.

Installation finale¶

Une fois votre inventaire terminé, vous pouvez effectuer l’installation finale de l’environnement INFRA et l’initialisation de la base de données avec le rôle Ansible reemo-infra.

ansible-playbook -i inventory.yml playbooks/reemo-infra.yml --extra-vars "INIT_DB=true"

Warning

Cette commande installe l’environnement et initialise la base de données. Elle n’est à exécuter qu’une seule fois.