Aller au contenu

Rocket.Chat - Opérations#

Rocket.Chat#

Récupération des secrets#

On récupère le compte administrateur de Rocket.Chat via Vault :

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

export ROCKETCHAT_LOGIN=$(vault kv get -field=username secret/applications/rocketchat-stg/users/admin)
export ROCKETCHAT_PASSWORD=$(vault kv get -field=password secret/applications/rocketchat-stg/users/admin)

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

export ROCKETCHAT_LOGIN=$(vault kv get -field=username secret/applications/rocketchat/users/admin)
export ROCKETCHAT_PASSWORD=$(vault kv get -field=password secret/applications/rocketchat/users/admin)

Rôle Admin#

Le rôle Admin est destiné aux personnes qui ont besoin de configurer Rocket.Chat tel que :

  • Les OPS
  • Le support
  • L'équipe Apps.

Pour affecter le rôle :

  1. Prérequis : Être un utilisateur avec le rôle Admin ou utiliser le compte Administrateur Rocket.Chat
  2. L'utilisateur doit s'être connecté à Rocket.Chat au moins une fois (provisioning automatique du compte via Keycloak)
  3. Dans le menu d'administration, choisir Workspace > Utilisateurs
  4. Modifier l'utilisateur concerné et remplacer le rôle user par Admin.

Le rôle Owner est destiné en priorité aux personnes qui ont besoin d'administrer des canaux Rocket.Chat tel que :

  • Les PO.

Rôle Owner#

Le rôle Owner1 est destiné en priorité aux personnes qui ont besoin d'administrer des canaux Rocket.Chat tel que :

  • Les PO.

Ce rôle s'applique sur les canaux directement :

  1. Prérequis : Être un utilisateur avec le rôle Admin
  2. L'utilisateur doit s'être connecté à Rocket.Chat au moins une fois (provisioning automatique du compte via Keycloak)
  3. Se connecter sur le canal sur lequel on veut définir un propriétaire
  4. Afficher la liste des membres (Icône en haut à droite)
  5. Cliquer sur le bouton action de l'utilisateur concerné et choisir Définir comme propriétaire / Set as owner.

Gestion du provisioning#

Le provisioning de Rocket.chat est réalisé en grande partie avec le post-script /applications/rocketchat/scripts/post_config.py. Ce script est appellé via l'usage de trackbone sur la configuration Rocket.Chat.

Seuls les éléments les plus important sont provisionnés de cette manière, à savoir :

  • Configuration de l'authentification OAuth / OpenID Connect
  • Les canaux public structurant l'activité des équipes de la Product Factory
  • Les utilisateurs locaux (bots, etc.) avec leurs permissions
  • Les webhooks
  • Les emojis personnalisés.

Méthode de mise à jour :

  1. Mettre à jour le dépôt /applications/rocketchat/
  2. Mettre à jour le dépôt /terraform/envs-ng/
  3. Préparer et appliquer le CAASCHR correspondant à ce changement.

Provisioning des utilisateurs#

Warning

À l'exception des comptes applicatifs locaux2, les utilisateurs sont à provisionner via Keycloak. Ces comptes locaux doivent être provisionné via la CI.

Mettre à jour le fichier de provisioning /applications/rocketchat/configs/users.yaml : 

# Example
- username: "bot.cloudwatt"
  name: "Cloudwatt"
  email: "noreply.cloudwatt@caascad.com"
  roles:
    - "bot"

Provisioning de canaux#

Bien qu'il soit possible de créer un canal dans l'interface Rocket.Chat, pour les canaux les plus importants, il est demandé de les provisionner via la CI.

Mettre à jour le fichier de provisioning /applications/rocketchat/configs/channels.yaml : 

# Eg. with a channel fully managed by our CI
- name: "ug_voyage"
  default: True   # Default channel, self-joined at first connection
  readonly: True  # Channel in read only 
  topic: "[Letitia](https://www.openstreetmap.org/#map=19/-4.21266/-69.94321)"
  announcement: "Voyage voyage..."

# Eg. with a channel customisable by owners / administrators
#   topic & annoucement are setted at first creation
- name: "ug_voyage"
  default: True   # Default channel, self-joined at first connection
  readonly: True  # Channel in read only
  overwrite_room_info: False
  topic: "[Letitia](https://www.openstreetmap.org/#map=19/-4.21266/-69.94321)"
  announcement: "Voyage voyage..."

Provisioning de webhook#

Les webhooks doivent être crées via la CI.

Mettre à jour le fichier de provisioning /applications/rocketchat/configs/webhooks.yaml : 

"alarma":
  enabled: True
  integrations_type: "webhook-incoming"
  channel: "#humour"
  username: "bot.test"
  script_enabled: True
  script: "alarma-test.js"

Il faut aussi copier le script .js dans /applications/rocketchat/scripts/.

Les secrets sont disponibles dans le vault infra : 

vault read secret/concourse-infra/global/rocketchat-webhooks

Provisioning d'emojis#

Ils doivent être crées via la CI.

Quelques recommandations :

  • À ajouter avec parcimonie (Rocket.Chat recommande de ne pas dépasser la centaine d'emojis personnalisés).
  • Formats d'images supportés : png, jpg

Mettre à jour le fichier de provisioning /applications/rocketchat/configs/custom_emojis.yaml : 

# Custom emoji
"pain_au_chocolat":
  aliases:
    - chocolatine
  extension: png

Il faut aussi ajouter l'image correspondant à l'émoji en respectant le nommage <Key Name>.<extension> dans /applications/rocketchat/data/emojis.

Tester le provisionnement#

À des fins de tests / développement, il est aussi possible de n'appeler que le script de provisionning.

Se positionner dans caascad/terraform/envs-ng/.

Exécuter le script de provisioning

cd contexts/pf
trackbone shell -z corp -c rocketchat_stg

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

./scripts/post_config.py -u https://chat-stg.corp.caascad.com \
  -n "$(vault kv get -field=username secret/applications/rocketchat-stg/users/admin)" \
  -p "$(vault kv get -field=password secret/applications/rocketchat-stg/users/admin)" \
  -b "$(vault kv get -field=password secret/applications/rocketchat-stg/users/bots)"

cd contexts/pf
trackbone shell -z corp -c rocketchat

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

./scripts/post_config.py -u https://chat.corp.caascad.com \
  -n "$(vault kv get -field=username secret/applications/rocketchat/users/admin)" \
  -p "$(vault kv get -field=password secret/applications/rocketchat/users/admin)" \
  -b "$(vault kv get -field=password secret/applications/rocketchat/users/bots)"

Problèmes connus#

Login impossible après un changement dans keycloak#

L'élément utilisé comme clé pour identifier un utilisateur Rocket.Chat est son username. Cependant nous avons constaté qu'un changement sur un autre attribut, tel que le Name (pour corriger une typo par exemple) dysfonctionne. Dans ce cas la solution est qu'un administrateur applique manuellement le même changement via l'interface web de Rocket.Chat

MongoDB#

Récupération des secrets#

On récupère le compte root de la base MongoDB de Rocket.Chat via Vault :

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

export MONGODB_ROOT_PASSWORD=$(vault kv get -field=rootPassword secret/applications/rocketchat-stg/mongodb)

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

export MONGODB_ROOT_PASSWORD=$(vault kv get -field=rootPassword secret/applications/rocketchat/mongodb)

On récupère le compte applicatif de la base MongoDB de Rocket.Chat via Vault :

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

export MONGODB_LOGIN=$(vault kv get -field=username secret/applications/rocketchat-stg/mongodb)
export MONGODB_PASSWORD=$(vault kv get -field=password secret/applications/rocketchat-stg/mongodb)

export VAULT_ADDR='https://vault.corp.caascad.com'
vault token lookup || vault login -method oidc

export MONGODB_LOGIN=$(vault kv get -field=username secret/applications/rocketchat/mongodb)
export MONGODB_PASSWORD=$(vault kv get -field=password secret/applications/rocketchat/mongodb)

Connexion à base de données (CLI)#

On utilisera le client mongosh disponible dans le conteneur MongoDB :

kubectl -n rocketchat-stg exec rocketchat-mongodb-0 -it -- sh -c "mongosh -u root -p ${MONGODB_ROOT_PASSWORD}"

kubectl -n rocketchat exec rocketchat-mongodb-0 -it -- sh -c "mongosh -u root -p ${MONGODB_ROOT_PASSWORD}"

On se positionne sur la base rocketchat (par défaut, la connexion se fait sur la base test) : 

rs0 [direct: primary] test> use rocketchat

Enfin, on peut requêter la base de données, par exemple : 

# Lister les collections
rs0 [direct: primary] rocketchat> show collections

# Afficher les logs
rs0 [direct: primary] rocketchat> show log

# Lister les bases de données
rs0 [direct: primary] rocketchat> show databases

# Lister les utilisateurs
rs0 [direct: primary] rocketchat> db.getCollection('users').find({})

# Lister les rooms / channels
rs0 [direct: primary] rocketchat> db.getCollection('rocketchat_room').find({})

Identifier le pod primaire#

Pour récupérer le nom du pod MongoDB primaire :

kubectl -n rocketchat-stg exec rocketchat-mongodb-0 -it -- sh -c "mongosh --quiet --eval \"db.runCommand('ismaster')\"" | awk -F\' '/primary/ {print $2}'

kubectl -n rocketchat exec rocketchat-mongodb-0 -it -- sh -c "mongosh --quiet --eval \"db.runCommand('ismaster')\"" | awk -F\' '/primary/ {print $2}'

Pour avoir plus de détail :

kubectl -n rocketchat-stg exec rocketchat-mongodb-0 -it -- sh -c "mongosh --quiet --eval \"db.runCommand('ismaster')\""

kubectl -n rocketchat exec rocketchat-mongodb-0 -it -- sh -c "mongosh --quiet --eval \"db.runCommand('ismaster')\""

  1. C'est le propriétaire d'un canal, ce qui lui permet de modifier ses informations (description, annonce, sujet, etc.). ↩

  2. Les comptes applicatifs sont des comptes locaux utilisés par des services tel que des bots pour les webhooks. ↩