Installation et configuration de Looker CI/CD à plusieurs niveaux

Cette page explique comment installer et configurer les composants nécessaires pour implémenter un workflow CI/CD multicouche dans Looker.

Ces instructions utilisent un système à trois niveaux comprenant le développement, le contrôle qualité et la production. Toutefois, les mêmes principes peuvent être appliqués à un système à deux ou quatre niveaux.

Ces instructions supposent également que vous utilisez GitHub comme fournisseur Git. Vous pouvez utiliser d'autres fournisseurs Git pour créer un workflow CI/CD. Toutefois, vous devez avoir l'expertise nécessaire pour modifier ces instructions pour votre fournisseur.

Suivez les instructions de la section qui vous concerne :

• Conditions préalables
• Procédure de configuration initiale
• Étapes de configuration pour chaque développeur Looker

Prérequis

Environnement Linux

Ce processus utilise un outil appelé Gazer, conçu pour fonctionner avec les systèmes d'exploitation de type Unix. Chaque développeur LookML qui doit migrer du contenu utilisateur doit avoir accès à la ligne de commande dans un environnement Linux ou macOS où vous prévoyez d'exécuter votre workflow CI/CD.

Si vous utilisez Windows, vous pouvez utiliser Gazer dans le sous-système Windows pour Linux (WSL) de Microsoft. WSL vous permet d'exécuter différentes versions de Linux. Si vous n'avez pas de système d'exploitation Linux préféré, la dernière version d'Ubuntu Linux est un bon choix en raison de sa large compatibilité.

Ces instructions fournissent des exemples pour les systèmes Linux et peuvent nécessiter des modifications si vous utilisez macOS ou WSL.

Une instance Looker par niveau

Pour activer cette configuration, vous aurez besoin d'une instance Looker pour chaque niveau de votre système. Par exemple, un système avec une étape de développement, une étape d'assurance qualité et une étape de production aura besoin de trois instances distinctes. Les instances peuvent être hébergées par Google ou hébergées par le client.

Noms de connexion identiques

Les connexions à la base de données doivent porter le même nom dans chaque instance Looker, quel que soit le niveau qu'elles représentent. Par exemple, une connexion sales doit porter ce nom dans toutes les instances, et non sales_dev ou sales_qa.

Les connexions peuvent pointer vers la même base de données ou vers des bases de données différentes. Toutefois, s'ils pointent vers la même base de données, ils doivent avoir des schémas temporaires différents définis afin que les tables dérivées persistantes dans l'instance de développement ou de contrôle qualité n'interfèrent pas avec la production.

Par exemple, si la même base de données est utilisée pour les trois instances, elles peuvent être configurées comme suit :

Si une base de données unique est utilisée pour les trois instances, elles peuvent être configurées comme suit :

Dépôt Git

Un seul dépôt Git sera utilisé pour chaque projet dans les trois niveaux. L'instance de développement suivra la branche main, tandis que les instances de QA et de production pointeront généralement vers des tags Git (décrits plus en détail ultérieurement).

Étapes de configuration initiale

Les étapes de cette section ne doivent être effectuées qu'une seule fois par une personne disposant des autorisations d'administrateur Looker et d'administrateur sur son fournisseur Git.

Identifiants Git

L'environnement Linux de chaque développeur doit se connecter au même dépôt que celui que vous utilisez pour gérer votre LookML. Il s'agit probablement d'un dépôt externe hébergé dans un service tel que GitHub. Vous aurez besoin d'un compte auprès de ce service disposant des identifiants appropriés pour configurer le dépôt. À l'aide de ce compte, vous pouvez configurer une clé SSH pour permettre à votre environnement Linux de se connecter automatiquement à ce service.

Pour GitHub, suivez les instructions de la section Ajouter une clé SSH à votre compte GitHub.

Créer et configurer un dépôt de serveur Git

Pour que le workflow CI/CD fonctionne, le code LookML doit être stocké dans un dépôt Git et associé à un projet Looker. Dans les paramètres du projet, Nom de la branche de production Git doit être défini sur main et Activer le mode de déploiement avancé doit être activé.

Si les étapes suivantes n'ont pas encore été effectuées, suivez ces instructions pour GitHub :

Créer des actions GitHub

Il est utile de créer plusieurs actions GitHub pour que diverses vérifications soient effectuées automatiquement chaque fois que des modifications LookML sont apportées. Pour ajouter ces actions, vous devez pouvoir modifier votre dépôt Git dans votre environnement Linux. Si ce n'est pas déjà le cas, suivez les instructions de la section Configurer Git.

Pour ajouter les actions GitHub, accédez au répertoire de votre dépôt dans l'environnement Linux et ajoutez le sous-répertoire .github/workflows. Une fois configurées, ces actions peuvent être exécutées manuellement depuis la page Actions de l'interface utilisateur GitHub.

Look-At-Me-Sideways (LAMS)

LAMS est un linter Open Source qui inspecte votre code LookML pour détecter les erreurs et les mauvaises pratiques. Ajoutez un fichier nommé lams.yml au répertoire .github/workflows avec le contenu suivant :

name: LAMS

on:
  pull_request:
    branches: [ main ]
  push:
  workflow_dispatch:

jobs:
  lams_job:
    runs-on: ubuntu-latest
    name: LAMS LookML Linter Job
    steps:
    - name: Checkout your LookML
      uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.head.sha }}
        fetch-depth: 0
    - name: Setup Node
      uses: actions/setup-node@v1
      with:
        node-version: '16.x'
    - name: Install LAMS
      run: npm install -g @looker/look-at-me-sideways@3
    - name: Run LAMS
      run: lams --reporting=no

LAMS s'exécute chaque fois qu'un commit est envoyé à GitHub ou qu'une demande d'extraction est ouverte pour fusionner le code avec la branche main.

Release Please

Release Please est un outil Open Source qui ajoute automatiquement les numéros de version appropriés aux versions.

Ajoutez un fichier nommé release-please.yml au répertoire .github/workflows avec le contenu suivant :

name: release-please

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          release-type: simple

Commits conventionnels

Cette action GitHub vérifie qu'une demande d'extraction est ouverte avec un titre conforme à la norme conventional commit.

Ajoutez un fichier nommé lint_pr_title.yml au répertoire .github/workflows avec le contenu suivant :

name: "Lint Pull Request Title"

on:
  pull_request_target:
    types:
      - opened
      - edited
      - synchronize

jobs:
  main:
    name: Validate PR title
      runs-on: ubuntu-latest
      steps:
        - uses: amannn/action-semantic-pull-request@v5
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

permissions:
  pull-requests:
    read statuses: write

Transférer les modifications vers GitHub

Enfin, utilisez les commandes suivantes pour valider ces modifications d'action GitHub et les transférer vers GitHub :

git add .github/workflows/
git commit -m "chore: Added github actions"
git push

Protéger la branche main

Dans l'interface utilisateur GitHub, vous devez activer la protection des branches pour la branche main afin que les développeurs ordinaires ne puissent pas y transférer directement des modifications. Au lieu de cela, ils apportent des modifications dans une autre branche, puis ouvrent une demande d'extraction;extraction. Une autre développeuse ou un autre développeur peut examiner la demande d'extraction;extraction avant qu'elle ne soit approuvée et fusionnée avec main.

Pour configurer la protection des branches, accédez à l'interface utilisateur GitHub du dépôt, sélectionnez Settings (Paramètres), puis Branches (Branches) et cliquez sur le bouton Add branch protection rule (Ajouter une règle de protection des branches) :

Saisissez main comme modèle de nom de branche, puis cochez les options suivantes :

• Exiger une demande d'extraction avant la fusion
• Exiger des approbations
• Ignorer les approbations de demande d'extraction obsolètes lorsque de nouveaux commits sont envoyés

Enfin, appuyez sur le bouton Créer en bas de la page.

Lorsqu'une demande d'extraction est créée, les actions GitHub configurées précédemment dans ces instructions s'exécutent. Une fois qu'ils ont été exécutés pour la première fois, ils peuvent également être sélectionnés dans cette UI afin qu'ils réussissent avant que la demande d'extraction puisse être fusionnée dans main.

Configurer les demandes d'extraction

Dans Looker, vous pouvez exiger l'utilisation de demandes d'extraction et faire en sorte que Looker ouvre des demandes d'extraction au nom du développeur. Ce paramètre ne doit être configuré que pour l'instance de développement. Les instances de production et d'assurance qualité utiliseront le mode de déploiement avancé pour obtenir leurs mises à jour.

Pour ce faire, accédez à la page Configuration du projet pour chaque projet, puis sélectionnez Demandes d'extraction requises sous l'en-tête Intégration GitHub.

Appuyez sur le bouton pour définir un secret de webhook, copiez la chaîne aléatoire générée, puis appuyez sur le bouton Enregistrer la configuration du projet.

De retour dans l'interface utilisateur GitHub de votre dépôt, sélectionnez Settings (Paramètres), puis Webhooks. Appuyez sur le bouton Add webhook (Ajouter un webhook) en haut à droite :

• Dans le champ URL de charge utile, saisissez https://LOOKER_HOST_NAME/webhooks/projects/PROJECT_NAME/deploy.
• Dans le champ Secret, collez le secret que vous avez enregistré depuis Looker.
• Pour la question Quels événements souhaitez-vous déclencher ce webhook ?, sélectionnez Me laisser sélectionner des événements individuels.

Vérifiez que les options Pull Requests (Demandes d'extraction) et Pushes (Envois) sont sélectionnées :

Enfin, appuyez sur le bouton Add webhook (Ajouter un webhook) en bas de la page.

Étapes de configuration pour chaque développeur Looker

Toutes les étapes d'installation suivantes doivent être effectuées dans votre environnement Linux.

Installer Ruby

Le langage de programmation Ruby doit être installé pour exécuter Gazer. Toute version de Ruby ultérieure à la version 2.7.7 fonctionnera avec Gazer, mais la version 3.x.x est recommandée. Pour installer Ruby sur Ubuntu Linux, exécutez les commandes suivantes :

sudo apt update
sudo apt install ruby

Vérifiez que Ruby est correctement installé en exécutant la commande ruby -v. Vous devriez obtenir une réponse semblable à celle-ci :

ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]

Ces commandes fonctionnent également sur Debian Linux, Linux Mint et plusieurs autres versions de Linux qui utilisent le gestionnaire de paquets Aptitude. Vous devrez peut-être rechercher des commandes fonctionnant sur d'autres versions de Linux ou des commandes à installer sur macOS. Pour en savoir plus, consultez Installer Ruby.

Installer Gazer

Gazer est un projet Open Source créé par des employés de Google pour parcourir et gérer les espaces, les looks et les tableaux de bord à l'aide d'un outil de ligne de commande.

Une fois Ruby installé, l'outil Gem de Ruby peut être utilisé pour installer Gazer :

gem install gazer

Vérifiez que Gazer est installé à l'aide de la commande gzr version. Vous devriez obtenir une réponse semblable à celle-ci :

v0.3.12

Configurer l'intégration continue de Looker

Pour tester et valider le code LookML, utilisez l'intégration continue Looker. L'intégration continue est intégrée à Looker et ne nécessite pas d'installation locale de la CLI.

Pour utiliser l'intégration continue, procédez comme suit :

1. Vérifiez que votre instance répond aux exigences d'intégration continue.
2. Demandez à un administrateur Looker d'activer l'intégration continue et d'installer l'application GitHub CI.
3. Créez une suite d'intégration continue pour configurer les validateurs et les déclencheurs de votre projet.

Pour en savoir plus, consultez la documentation sur l'intégration continue de Looker.

Installer Git

Le logiciel de contrôle des versions Git peut être installé sur Ubuntu Linux à l'aide de la commande suivante :

sudo apt update
sudo apt install git

Vérifiez que l'installation a réussi à l'aide de la commande git --version. Vous devriez obtenir une réponse semblable à celle-ci :

git version 2.42.0.609.gbb76f46606

Ces commandes fonctionnent également sur Debian Linux, Linux Mint et plusieurs autres versions de Linux qui utilisent le gestionnaire de paquets Aptitude. Vous devrez peut-être rechercher des commandes fonctionnant sur d'autres versions de Linux. Vous trouverez des instructions pour Fedora et macOS, par exemple, sur la page Premiers pas : installer Git.

Configurer Git

Git doit être configuré dans votre environnement Linux pour interagir avec le dépôt Git dans lequel votre LookML est stocké. Ces instructions ont été rédigées pour les dépôts Git LookML stockés dans GitHub.

Nom et adresse e-mail

GitHub (et la plupart des autres implémentations Git) ont besoin de connaître votre nom et votre adresse e-mail pour enregistrer votre activité. Configurez votre nom et votre adresse e-mail dans Git en exécutant les commandes suivantes :

git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL_ADDRESS"

Identifiants Git

Lors de la configuration initiale de CI/CD, des identifiants Git ont été créés. La clé SSH privée générée doit être configurée dans un fichier $HOME/.ssh/config. Pour créer le fichier, utilisez les commandes suivantes :

touch $HOME/.ssh/config
chmod 600 $HOME/.ssh/config

Insérez le texte suivant dans le fichier $HOME/.ssh/config :

Host github.com
  User git
  IdentityFile ~/.ssh/KEY_NAME
  ControlMaster auto
  ControlPath ~/.ssh/ctrl-%r@%h:%p
  ControlPersist yes

À la place de KEY_NAME, utilisez le nom du fichier de clé privée que vous avez généré en suivant les instructions de la section Ajouter une clé SSH à votre compte GitHub. Le fichier de clé privée porte le même nom que le fichier de clé publique, mais sans l'extension .pub. Par exemple, si vous avez utilisé la clé publique figurant dans le fichier id_ed25519.pub, la clé privée sera nommée id_ed25519.

Configurer votre dépôt Git local

Après avoir configuré votre dépôt LookML, vous devez en faire une copie dans votre environnement Linux. Pour ce faire, exécutez la commande suivante :

git clone GIT_URL

Par exemple, la commande peut se présenter comme suit :

git clone git@github.com:my_org_name/sales_project.git

Le dépôt LookML sera copié dans un sous-répertoire, par exemple sales_project. Utilisez la commande cd SUB_DIRECTORY pour accéder au dépôt. Dans cet exemple, la commande serait cd sales_project.

Une fois dans le répertoire de votre dépôt, vous pouvez utiliser les commandes suivantes :

Configurer Gazer

Pour utiliser Gazer, vous aurez besoin d'identifiants API pour chacune des instances de développement, d'assurance qualité et de production. Pour savoir comment créer des identifiants d'API, consultez la page Paramètres d'administration – Utilisateurs. Il est possible que les identifiants de l'API aient déjà été créés par la personne qui a initialement configuré le workflow CI/CD. Dans ce cas, vous pouvez utiliser les identifiants existants. Il n'est pas nécessaire de générer de nouveaux identifiants pour chaque personne.

Stockez vos identifiants API dans un fichier .netrc avec des autorisations minimales dans votre répertoire d'accueil. Vous pouvez créer un fichier vide avec les autorisations appropriées à l'aide des commandes suivantes :

touch $HOME/.netrc
chmod 600 $HOME/.netrc

Ajoutez des entrées comme celles ci-dessous au fichier, mais utilisez vos propres noms d'hôte de serveur Looker pour machine, l'client_id de l'API pour la connexion et l'client_secret de l'API pour le mot de passe. Exemple :

machine dev.example.looker.com
  login 80ka7nl6lj87ftmn
  password u7kw3mj5h2trfz0

machine qa.example.looker.com
  login fi3qtv5at5crvd1q
  password bdxtaeghnzyz0wm

machine example.looker.com
  login k7lr6yv57wvzy9p2
  password wcvr5qjd2isbs2s

Pour vérifier que cela fonctionne, exécutez une commande Gazer sur chaque serveur, par exemple :

gzr user me --host dev.example.looker.com

Vous devriez obtenir un résultat semblable à celui-ci :

+----+---------------+---------+----------+------------------+--------------+
|  id|email          |last_name|first_name|personal_folder_id|home_folder_id|
+----+---------------+---------+----------+------------------+--------------+
|2345|jsm@example.com|Smith    |John      |              2161|           708|
+----+---------------+---------+----------+------------------+--------------+

Si la commande précédente ne fonctionne pas, vous devrez peut-être ajouter --port 443 à la fin de la commande gzr, comme suit :

gzr user me --host dev.example.looker.com --port 443

Configurer des suites d'intégration continue

Créez des suites d'intégration continue dans Looker pour spécifier vos règles de validation et vos configurations de test.

Dans une suite CI, vous pouvez configurer les éléments suivants :

• Les options de déclenchement permettent d'exécuter la validation automatiquement sur les demandes d'extraction, selon une programmation ou manuellement à partir de l'IDE Looker.
• Validateur SQL pour tester les dimensions par rapport à la base de données.
• Assert Validator (Validateur d'assertions) pour exécuter des tests de données LookML.
• Validation de contenu pour tester les Looks et les tableaux de bord.
• Le programme de validation LookML pour vérifier la syntaxe LookML.

Pour savoir comment configurer des suites, consultez Créer une suite d'intégration continue.