DEV Community: Onepoint x Stack Labs

Un Chatbot RAG pour explorer du contenu vidéo : une architecture event-driven et serverless sur Google Cloud

Maximilien Soviche — Mon, 09 Dec 2024 16:02:09 +0000

Un chatbot capable de répondre à vos questions tout en vous fournissant un lien cliquable vers la bonne vidéo YouTube, et au bon endroit dans la vidéo. C'est ce que permet cette architecture conçue sur Google Cloud, mêlant IA générative et approche serverless.

Dans cet article, nous explorerons comment mettre en place un chatbot RAG (Retrieval-Augmented Generation) qui utilise un corpus de vidéos pour fournir des réponses enrichies et pertinentes. Ce système repose sur une architecture event-driven pilotée par EventArc et des microservices déployés avec Cloud Run.

Une telle solution peut être appliquée dans divers contextes :

Formation : Accès rapide à des segments vidéo éducatifs pertinents.
Entreprise : Recherche d'informations dans des vidéos internes comme des réunions ou des formations.
Médias et divertissement : Exploration d'archives vidéo ou de contenus créatifs selon des requêtes contextuelles.
Parlement : Exploration de contenus vidéos longs : séances, commissions, etc

L'application proposée ici est l'exploration d'une playlist Youtube de formation sur les services Google Cloud.

Qu'est ce que le RAG ?

Le RAG veut dire Retrieval-Augmented Generation, et est la plupart du temps appliqué sur des documents textuels. Plutôt que de poser une question à un LLM, on va effectuer les étapes suivantes :

Ingestion

On prend des documents pertinents pour l'application souhaitée.
On découpe ces documents en morçeaux, appelés chunks.
On construit une représentation de ces chunks appelée embedding, lisible par un algorithme de recherche par similarité.
On stocke ces embeddings dans une base de données.

Récupération

L'utilisateur pose une question qui est transformée en embedding.
L'embedding est comparé à ceux de la base de données afin de retrouver du contexte pertinent.
Un construit un prompt augmenté qui comporte la question de l'utilisateur ainsi que les éléments de contexte appropriés.
Le LLM peut alors fournir une réponse pertinente sur ce prompt grâce au contexte.

Le RAG sur du contenu vidéo

Pour effectuer du RAG sur du contenu vidéo, l'idée principale est d'effectuer une transcription du contenu, afin de se ramener à un système RAG classique avec des documents.

Vue d’ensemble de l’architecture

Le système se divise en deux parties :

Ingestion des vidéos : Un pipeline de traitement divise les vidéos en segments et génère des données prêtes pour la recherche.
Retrieval et Chatbot : Le chatbot trouve les segments pertinents, fournit une réponse augmentée et un lien vers la vidéo correspondante.

Partie 1 : Ingestion des Vidéos

L’ingestion repose sur cinq microservices Cloud Run. Ces services traitent les vidéos, segmentent leur contenu, et transforment les données en embeddings vectoriels stockés dans Firestore pour la recherche. Chaque microservice produit un résultat dans un bucket spécifique, ce qui déclenche le traitement suivant via un déclencheur EventArc.

Étape 1 : Téléchargement des vidéos avec le service Downloader

L'utilisateur fournit une playlist YouTube via une API, et déclenche son téléchargement via un appel API sur ce service.

Les métadonnées de la playlist (titres, descriptions, ID des vidéos) sont enregistrées dans une collection Firestore nommée metadata.

Étape 2 : Segmentation des vidéos avec le service Splitter

Chaque vidéo est découpée en segments de 2 minutes avec un recouvrement de 30 secondes. Ce recouvrement permet d'éviter la perte de contexte lorsqu'une phrase est coupée en deux. La piste audio est extraite pour chaque segment et stockée dans le bucket dédié.

La collection metadata dans Firestore est mise à jour. On associe à chaque vidéo ses segments avec leurs informations, notamment les timestamps de début et de fin.

Le choix de la durée des segments (2 minutes) et de la taille de recouvrement peuvent être modifiés selon les besoins et le cas traité.

Étape 3 : Transcription des segments audio avec le service Transcriber

Les pistes audio des segments sont converties en texte grâce à l’API Speech-to-Text de Google Cloud (modèle Chirp). On obtient des transcriptions brutes dans un bucket.

Chirp est un modèle de transcription speech-to-text de pointe, conçu pour fournir des services de transcription extrêmement précis et rapides. Il prend en charge une large gamme de langues et de dialectes, ce qui en fait un choix polyvalent pour répondre à divers besoins de transcription. Il est disponible via l'API Speech-to-Text.

Étape 4 : Formatage des transcriptions avec le service Formatter

Les transcriptions brutes sont corrigées pour améliorer la grammaire et la clarté grâce à Gemini 1.5 Flash. On obtient ainsi des documents textuels dans un bucket, ce qui permet d'implémenter une logique RAG classique par la suite.

Étape 5 : Générer des embeddings avec le service Feeder

Les transcriptions finales sont transformées en embeddings vectoriels à l’aide de LangChain.

Le service Firestore sert de base de données pour les embeddings, avec une collection dédiée nommée embeddings.

Chaque embedding est stocké avec l'identifiant du segment audio auquel il appartient, ce qui permettra de retrouver les métadonnées dans la collection metadata.

Partie 2 : Retrieval et Chatbot

Une fois le corpus indexé, le chatbot répond aux questions des utilisateurs en recherchant les segments pertinents dans les embeddings et en fournissant un lien précis vers la vidéo source. Le timestamp correspondra au point de départ du segment audio le plus pertinent.

Étapes du chatbot :

Requête utilisateur : L'utilisateur pose une question via Google Chat.
Recherche par similarité :
- Les embeddings correspondant à la question sont récupérés dans Firestore.
- Les métadonnées associées (ID vidéo, segment, timestamps) sont extraites.
Reranking : La recherche par similarité permet d'obtenir les N chunks les plus pertinents (N=5 dans notre cas). L'étape de reranking consiste à utiliser un LLM pour réordonner ces chunks par ordre de pertinence, et n'en sélectionner qu'un.
Génération de réponse :
- Un prompt enrichi par le contexte du segment (le chunk retrouvé après reranking) est envoyé au LLM.
- Une URL est reconstruite avec le bon ID vidéo et le timestamp exact.
Validation finale avec Gemini 1.5 Flash :

On ne veut pas que l'URL de la vidéo soit fournie pour chaque réponse, sinon une question qui n'a rien à voir avec le contexte aboutirait quand même vers le contenu le moins éloigné en termes de similarité.

Le prompt augmenté est le suivant :

"""
You are a chatbot working for Stack Labs company. Your job is to retrieve information from videos.
You have to answer users' questions using the context given below, taken from video transcripts.
Don't invent anything, just use the context.
If you don't have a context, answer that you can't find one.

You must answer in english.

Context:
{context}

Question:
{query}
"""

Par conséquent la réponse du LLM peut comporter trois types de réponses :

Le chatbot dit qui il est et à quoi il sert
Le chatbot fournit un discours technique sur la base du contexte retrouvé dans Firestore
Le chatbot dit qu'il n'a pas de contexte

On ne veut fournir un lien cliquable à l'utilisateur que s'il s'agit d'un discours technique. On va donc faire un appel supplémentaire à Gemini 1.5 Flash, en le forçant à fournir l'un des trois flags suivants :
- who_am_i : Le chatbot se présente.
- technical_speech : Réponse technique.
- no_context : Aucune information trouvée.

Il est possible de configurer Gemini pour qu'il retourne une réponse au format JSON en respectant un schéma :


classification_schema = {
    "type": "object",
    "properties": {
        "response_type": {
            "type": "string",
            "enum": [
                "who_am_i",
                "technical_speech",
                "no_context"
            ],
            "description": "Message type based on context."
        }
    }
}

Le prompt donné à Gemini pour la classification est le suivant :

"""
Message : {message}

Classify this message by categorizing it into one of the following categories:
    - who_am_i: the message is someone presenting himself
    - technical_speech: Contains technical jargon, code-related keywords, or specific terminologies.
    - no_context: the message says that no context is found
"""

Si la réponse appartient à la catégorie technical_speech, l’URL est ajoutée à la réponse.

Voici un aperçu du résultat :

Avantages de cette architecture

1. Liens contextuels précis

Le chatbot fournit des réponses enrichies avec des liens vidéo cliquables, garantissant une navigation rapide vers l’information.

2. Scalabilité et efficacité

L’utilisation de Cloud Run et EventArc permet une exécution à la demande et une scalabilité horizontale, tout en garantissant des coûts contenus.

3. Modularité

Chaque microservice est indépendant, ce qui facilite les mises à jour et l’ajout de nouvelles fonctionnalités. Chaque microservice Cloud Run peut être géré de façon indépendante : gestion de la capacité mémoire et CPU, montage d'un volume, etc.

4. Personnalisation

Cette solution peut être facilement personnalisée pour différents contextes, notamment le choix de la taille et du recouvrement des différents segments audios.

Conclusion

Cette architecture montre comment Google Cloud peut permettre une recherche d'informations efficace dans un corpus de vidéos. Le choix d’une approche serverless et event-driven garantit un système flexible, scalable, facile à maintenir et peu coûteux.

Merci d'avoir lu ! Nous sommes Victor et Maximilien, développeur et data engineer chez Stack Labs. Si vous souhaitez découvrir la Stack Labs Data Platform ou rejoindre une équipe tech motivée, n'hésitez pas à nous contacter.

How to pass an Array of Structs in Bigquery's parameterized queries

matthieucham — Tue, 15 Oct 2024 06:57:39 +0000

In Google's Bigquery, SQL queries can be parameterized. If you're not familiar with this concept, it basically means that you can write SQL queries as parameterized templates like this:

INSERT INTO mydataset.mytable(columnA, columnB)
    VALUES (@valueA, @valueB)

And pass the values separately. This has numerous benefits:

The query is more readable than when it's built by string concatenation
The code is more robust and industrialized
It's a great protection against SQL injection attacks (mandatory XKCD)

The passing of query parameters from a Python script appears straightforward... at first sight. For example:

from google.cloud.bigquery import (
    Client,
    ScalarQueryParameter,
    ArrayQueryParameter,
    StructQueryParameter,
    QueryJobConfig,
)

client=Client()

client.query("
INSERT INTO mydataset.mytable(columnA, columnB)
    VALUES (@valueA, @valueB)
", job_config=QueryJobConfig(
    query_parameters=[
        ScalarQueryParameter("valueA","STRING","A"), 
        ScalarQueryParameter("valueB","STRING","B")
])

The example above inserts simple ("Scalar") values in columns A and B. But you can also pass more complex parameters:

Arrays (ArrayQueryParameter)
Structs (StructQueryParameter)

Problems arise when you want to insert arrays of structs : there are many gotchas, almost no documentation and very few resources on the subject on the web. The goal of this article is to fill this gap.

How to persist an array of structs in bigquery using parameterized queries

Let's define the following object that we want to store in our destination table

from dataclasses import dataclass

@dataclass
class Country:
    name: str
    capital_city: str

@dataclass
class Continent:
    name: str
    countries: list[Country]

by invoking this parameterized query

query = UPDATE continents SET countries=@countries WHERE name="Oceania"

The first try by following the shallow documentation would be

client.query(query, 
    job_config=QueryJobConfig(query_parameters=[
        ArrayQueryParameter("countries", "RECORD", [
             {name="New Zealand", capital_city="Wellington"},
             {name="Fiji", capital_city="Suva"} ...]
]))

which would fail miserably

AttributeError: 'dict' object has no attribute 'to_api_repr'

Gotcha n°1: ArrayQueryParameter's values must be instances of StructQueryParameter

It turns out that the third argument of the constructor - values- must be a collection of StructQueryParameter instances, not the wanted values directly. So let's build them:

client.query(query, 
job_config=QueryJobConfig(query_parameters=[
    ArrayQueryParameter("countries", "RECORD", [
    StructQueryParameter("countries",
        ScalarQueryParameter("name", "STRING", ct.name), 
        ScalarQueryParameter("capital_city", "STRING", ct.capital_city)
    )
    for ct in countries])
]))

This time it works... Until you try to set an empty array

client.query(query, 
    job_config=QueryJobConfig(
    query_parameters=[
        ArrayQueryParameter("countries", "RECORD", [])
]))

ValueError: Missing detailed struct item type info for an empty array, please provide a StructQueryParameterType instance.

Gotcha n°2: Provide the full structure type as second argument

The error message is pretty clear: "RECORD" is not enough for Bigquery to know what to do with your empty array. It needs the fully detailed structure. So be it

client.query(query, job_config=QueryJobConfig(query_parameters=[
    ArrayQueryParameter("countries",
        StructQueryParameterType(
            ScalarQueryParameterType("STRING","name"),
            ScalarQueryParameterType("STRING","capital_city")
        ), [])
]))

(Notice how the order of the arguments of the ...ParameterType constructor is the reverse of ...Parameter constructor. Just another trap on the road...)

And now it works for empty arrays too, yay !

One last gotcha to be aware of: every subfield of a StructQueryParameterType must have a name, even if the second parameter (name) is optional in the constructor. It's actually mandatory for subfields, otherwise you'll get a new kind of error

Empty struct field name

I think that's all we need to know to complete the usage of arrays of records in query parameters, I hope this helps !

Thanks for reading! I’m Matthieu, data engineer at Stack Labs.
If you want to discover the Stack Labs Data Platform or join an enthousiast Data Engineering team, please contact us.

Photo de Denys Nevozhai sur Unsplash

Automatically Update BigQuery View Schema Changes

matthieucham — Tue, 30 Jul 2024 15:29:59 +0000

SQL views are virtual tables simplifying data access and security. They offer tailored data perspectives, protecting sensitive information. Data analysts widely use them to streamline modeling.

As such, views are a crucial feature of Google Cloud's fully managed data warehouse, BigQuery. However, they have certain limitations. One of these limitations can be particularly troublesome for data analysts and end-users:

The schemas of the underlying tables are stored with the view when the view is created. If columns are added, deleted, or modified after the view is created, the view isn't automatically updated and the reported schema will remain inaccurate until the view SQL definition is changed or the view is recreated. Even though the reported schema may be inaccurate, all submitted queries produce accurate results.

To see this limitation into action, create a source table with two columns

CREATE OR REPLACE TABLE `demo_devto.source_table` (
  A STRING,
  B STRING
) AS (
  SELECT "a", "b" 
)

Then create a view above it

CREATE OR REPLACE VIEW `demo_devto.expo_view` AS (
  SELECT * from `demo_devto.source_table`
)

As expected, the schema of the view presents 2 columns A and B

Now add a column to the source table

ALTER TABLE `demo_devto.source_table`
  ADD COLUMN C STRING

The new column is reflected by the source table's schema

But not by the view's schema

Still, the result of a query is correct with 3 columns

This article outlines a method to circumvent this limitation and maintain the view's schema in alignment with the underlying table's schema as closely as possible.

A fully serverless event-driven architecture to synchronize schemas

This solution make use of a log sink to capture audit logs from BigQuery, a PubSub topic where relevant log entries are directed, a PubSub subscription and a Cloud Run service to process them

Let's review each step and dive into details

1. Bigquery audit logs

All Google Cloud services generate logs which are viewable in Cloud Logging. BigQuery is no exception and audit logs offer all information we need. See their structure here

2. Cloud Logging log sink

A log sink is a location where the logs are collected and stored. Google Cloud Logging log sinks collect within a scope - project, folder, organization. So to capture update logs from tables for a whole organization, a log sink at organization level is needed. To monitor a project only, a sink at project level is enough.

A log sink must declare a filter. This is very important to limit costs - which depend of the volume of captured logs - and to process relevant events only. Here we are using the following filter to capture events about schema changes:

resource.type="bigquery_resource"
AND protoPayload.serviceName="bigquery.googleapis.com"
AND protoPayload.methodName="tableservice.update"
AND protoPayload.authenticationInfo.principalEmail !~ <regex identifying the service account used by the cloud run service who process logs>

The filter on principalEmail serves as a mechanism to identify updates to exposition views made by the Cloud Run service, which we wish to exclude from processing as our focus lies solely on source table update events.

Finally, we need to give the sink a destination, where received logs who pass the filter are routed. Several kinds of destination are possible. Because our architecture is event-driven, the selected destination is a PubSub topic. The log entry is then encoded as JSON

Here is how to provision such a sink with Terraform, at project level:

resource "google_logging_project_sink" "demo" {
  provider               = google-beta
  project                = "my-project"
  name                   = "logsink-demo"
  destination            = "pubsub.googleapis.com/${google_pubsub_topic.demo.id}"
  filter                 = <<EOT
    resource.type="bigquery_resource"
    AND protoPayload.serviceName="bigquery.googleapis.com"
    AND protoPayload.methodName="tableservice.update"
    AND protoPayload.authenticationInfo.principalEmail !~ "^sa-demo@myproject.iam.gserviceaccount.com$"
  EOT
  unique_writer_identity = true
}

resource "google_pubsub_topic_iam_member" "demo" {
  provider = google-beta
  topic    = google_pubsub_topic.demo.id
  role     = "roles/pubsub.publisher"
  member   = google_logging_project_sink.demo.writer_identity
}

3. PubSub topic and subscription

The PubSub topic is the destination of log events who pass the log sink filter.

To consume these events, a subscription in PUSH mode send these events to a HTTPS endpoint.

Here is an example of how these resources can be provisioned with Terraform:

resource "google_pubsub_topic" "demo" {
  provider = google-beta
  name     = "topic-demo"
}

resource "google_pubsub_subscription" "demo" {
  provider             = google-beta
  name                 = "sub-demo"
  topic                = google_pubsub_topic.demo.id
  ack_deadline_seconds = 600

  push_config {
    push_endpoint = <URL of the cloud run endpoint>
    oidc_token {
      service_account_email = google_service_account.default.email
    }
  }

  expiration_policy {
    ttl = ""
  }
}

4. 5. and 6. Events processing

The processing of log events is performed by a Cloud Run service in this system, but could be done by a Cloud Function for example.

In Python, the decoding of incoming events can be done like this:

import base64
import json

bq_log = json.loads(base64.b64decode(message["data"]).decode("utf-8"))

By parsing the bq_log object, we can retrieve the updated table id:

import re

from google.cloud.bigquery import TableReference

RESOURCENAME_PATTERN = re.compile(
    "^projects/(?P<project>[^/]+)/datasets/(?P<dataset>[^/]+)/tables/(?P<table>[^/]+)$"
)

resource_name = bq_log.get("protoPayload", {}).get("resourceName", "")
if (match := RESOURCENAME_PATTERN.match(resource_name)) is not None:
    return TableReference.from_api_repr(
        {k + "Id": match.group(k) for k in ["project", "dataset", "table"]}
    )

The next step is to identify the views which relies on this source table. Here, associations between source tables and exposition views are registered in a Firestore database, but other designs are possible. For example, you could query INFORMATION_SCHEMA.VIEWS metadata views and identify the affected views by parsing the content of the VIEW_DEFINITION column

SELECT VIEW_DEFINITION FROM `demo_devto.INFORMATION_SCHEMA.VIEWS`

Finally, synchronize all affected views. BigQuery views seem to not support the updating of the "schema" field by the update_table() method when columns are added. The recommended way is then to re-create views with SQL DDL statements:

CREATE OR REPLACE VIEW AS ...

With all steps pieced together, any schema update from source tables automatically triggers the re-creation of exposition views, keeping the schema synchronized after a short delay !

Thanks for reading! I’m Matthieu, data engineer at Stack Labs.
If you want to discover the Stack Labs Data Platform or join an enthousiast Data Engineering team, please contact us.

Cover picture by Miguel Delmar on Unsplash

Enhancing Video to Text Transcription with AI: An Asynchronous Solution on Google Cloud Platform

Maximilien Soviche — Wed, 03 Jul 2024 09:50:46 +0000

Asynchronous transcription can be applied in various contexts. For developers looking to implement a robust, scalable, and efficient transcription solution, the Google Cloud Platform (GCP) offers an ideal environment. In this article, we’ll explore an asynchronous video-to-text transcription solution built with GCP using an event-driven and serverless architecture.

Potential Applications

The provided solution is particularly well-suited for long video-to-text transcriptions, efficiently handling videos that are more than an hour long. This makes it ideal for a wide array of applications across various sectors. Here are some examples:

State Institutions or local authorities: Transcribing meetings, hearings, and other official recordings to ensure transparency and accessibility.
Company Meetings: Creating accurate records of internal meetings, conferences, and training sessions to enhance communication.
Educational Institutions: Transcribing lectures, seminars, and workshops to aid in learning and research.

For shorter videos, the Gemini Pro API can handle the entire video-to-text transcription process, offering a streamlined and efficient solution for quicker, smaller-scale transcription needs.

Solution Overview

Our solution comprises three event-driven Cloud Functions, each triggered by specific events in different Cloud Storage buckets using an Eventarc trigger. Event-driven Cloud Functions are deployed pieces of code on GCP, invoked in response to an event in the cloud environment. In our case, we want our functions to be invoked when a file is upload in a specific Cloud Storage bucket. Eventarc is a standardized solution to manage events on GCP. Eventarc triggers route these events between resources. In this particular case, each Eventarc trigger listen to new objects in a specific Cloud Storage bucket, and then triggers the associated Cloud Function. The event data is passed to the function.

More information about Cloud Functions

More information about Eventarc triggers.

The four buckets used in our architecture are:

Video Files Bucket: Where users upload their video files.
Audio Files Bucket: Stores the extracted audio files.
Raw Transcriptions Bucket: Contains the initial transcriptions generated by the Chirp speech-to-text model.
Curated Transcriptions Bucket: Stores the curated transcriptions, enhanced by Gemini.

The application architecture is designed to be modular and scalable. Here’s a step-by-step breakdown of the workflow:

Video Upload and Audio Extraction

When a user uploads a video file to the video-files bucket, the video-to-audio Cloud Function is triggered. This function uses ffmpeg to extract the audio from the video file and save it in the audio-files bucket.

import os
import subprocess
from google.cloud import storage
import functions_framework
import logging

logger = logging.getLogger(__name__)


@functions_framework.cloud_event
def convert_video_to_audio(cloud_event):
    """Video to audio event-triggered cloud function."""

    data = cloud_event.data
    bucket_name = data['bucket']
    video_file_name = data['name']

    destination_bucket_name = os.environ.get("AUDIO_FILES_BUCKET_NAME")

    if not video_file_name.endswith(('.mp4', '.mov', '.avi', '.mkv')):
        logger.info(f"File {video_file_name} is not a supported video format.")
        return

    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(video_file_name)

    tmp_video_file = f"/tmp/{video_file_name}"
    blob.download_to_filename(tmp_video_file)

    audio_file_name = os.path.splitext(video_file_name)[0] + '.mp3'
    tmp_audio_file = f"/tmp/{audio_file_name}"

    command = f"ffmpeg -i {tmp_video_file} -vn -acodec libmp3lame -q:a 2 {tmp_audio_file}"
    subprocess.call(command, shell=True)

    destination_bucket = storage_client.bucket(destination_bucket_name)
    destination_blob = destination_bucket.blob(audio_file_name)
    destination_blob.upload_from_filename(tmp_audio_file)

    os.remove(tmp_video_file)
    os.remove(tmp_audio_file)

    logger.info(f"Converted {video_file_name} to {audio_file_name} and uploaded to {destination_bucket_name}.")

Audio to Text Transcription

The upload of the audio file to the audio-files bucket triggers the audio-to-text Cloud Function. This function uses Chirp, a highly accurate speech-to-text model, and the Speech-to-Text API, to transcribe the audio and stores the raw transcription in the raw-transcriptions bucket.

from google.cloud.speech_v2 import SpeechClient
from google.cloud.speech_v2.types import cloud_speech
from google.api_core.client_options import ClientOptions
from google.cloud import storage
import functions_framework
from typing import Dict
import logging
import time
import os

from . import chirp_model_long


logger = logging.getLogger(__file__)


def transcribe_batch_gcs(
    project_id: str,
    gcs_uri: str,
    region: str = "us-central1"
) -> cloud_speech.BatchRecognizeResults:
    """Transcribes audio from a Google Cloud Storage URI.

    Parameters
    ----------
        project_id: The Google Cloud project ID.
        gcs_uri: The Google Cloud Storage URI.

    Returns
    -------
        The RecognizeResponse.
    """

    client = SpeechClient(
        client_options=ClientOptions(
            api_endpoint=f"{region}-speech.googleapis.com",
        )
    )

    config = cloud_speech.RecognitionConfig(
        auto_decoding_config=cloud_speech.AutoDetectDecodingConfig(),
        language_codes=["fr-FR"],
        model="chirp",
    )

    file_metadata = cloud_speech.BatchRecognizeFileMetadata(uri=gcs_uri)

    request = cloud_speech.BatchRecognizeRequest(
        recognizer=f"projects/{project_id}/locations/{region}/recognizers/_",
        config=config,
        files=[file_metadata],
        recognition_output_config=cloud_speech.RecognitionOutputConfig(
            inline_response_config=cloud_speech.InlineOutputConfig(),
        ),
        processing_strategy=cloud_speech.BatchRecognizeRequest.ProcessingStrategy.DYNAMIC_BATCHING
    )

    operation = client.batch_recognize(request=request)

    logger.info("Waiting for operation to complete...")
    response = operation.result(timeout=1000)

    transcript = ""

    for result in response.results[gcs_uri].transcript.results:
        if len(result.alternatives) > 0:
            logger.info(f"Transcript: {result.alternatives[0].transcript}")
            transcript += f" \n{result.alternatives[0].transcript}"

    logger.debug(f"Transcript: {transcript}")

    return transcript


@functions_framework.cloud_event
def speech_to_text_transcription(cloud_event):
    """Audio file transcription via Speech-to-text API call."""

    data: Dict = cloud_event.data

    event_id = cloud_event["id"]
    event_type = cloud_event["type"]

    input_bucket = data["bucket"]
    audio_file_name = data["name"]

    destination_bucket_name = os.environ.get("RAW_TRANSCRIPTIONS_BUCKET_NAME")

    logger.info(f"Event ID: {event_id}")
    logger.info(f"Event type: {event_type}")
    logger.info(f"Bucket: {input_bucket}")
    logger.info(f"File: {audio_file_name}")

    storage_client = storage.Client()

    start = time.time()

    transcript = transcribe_batch_gcs(
        project_id=os.environ.get("PROJECT_ID"),
        gcs_uri=f"gs://{input_bucket}/{audio_file_name}"
    )

    stop = time.time()

    raw_transcription_file_name = os.path.splitext(audio_file_name)[0] + '_raw.txt'

    destination_bucket = storage_client.bucket(destination_bucket_name)
    destination_blob = destination_bucket.blob(raw_transcription_file_name)
    destination_blob.upload_from_string(transcript, content_type='text/plain; charset=utf-8')

    logger.debug(transcript)
    logger.info(f"JOB DONE IN {round(stop - start, 2)} SECONDS.")

About Chirp:

Chirp is a state-of-the-art speech-to-text model developed to provide highly accurate and fast transcription services. It supports a wide range of languages and dialects, making it a versatile choice for diverse transcription needs. It is available in the Speech-to-Text API.

More information about long audio to text transcription.

Transcription Curation

Finally, the curate-transcription Cloud Function is triggered by the new transcription file in the raw-transcriptions bucket. This function sends the raw transcription to the Gemini API that uses gemini-pro model for curation and stores the refined transcription in the curated-transcriptions bucket.

import vertexai
from vertexai.generative_models import GenerativeModel

import functions_framework
from google.cloud import storage

import time
import logging
import os
from typing import Dict

logger = logging.getLogger(__file__)


@functions_framework.cloud_event
def transcription_correction(cloud_event):
    """Gemini API call to correct and enhance speech-to-text transcription."""

    data: Dict = cloud_event.data

    event_id = cloud_event["id"]
    event_type = cloud_event["type"]

    input_bucket = data["bucket"]
    raw_transcription_filename = data["name"]

    destination_bucket_name = os.environ.get("CURATED_TRANSCRIPTIONS_BUCKET_NAME")

    logger.info(f"Event ID: {event_id}")
    logger.info(f"Event type: {event_type}")
    logger.info(f"Bucket: {input_bucket}")
    logger.info(f"File: {raw_transcription_filename}")

    storage_client = storage.Client()

    input_bucket = storage_client.get_bucket(input_bucket)
    input_blob = input_bucket.get_blob(raw_transcription_filename)
    transcript = input_blob.download_as_string()

    vertexai.init(project=os.environ.get("PROJECT_ID"), location="us-central1")
    model = GenerativeModel(model_name="gemini-1.0-pro-002")

    prompt = f"""
        YOUR CUSTOM PROMPT GOES HERE. 
        PROVIDING CONTEXT AND GIVING INFORMATION ABOUT THE RESULT YOU EXPECT IS NECESSARY.

        {transcript}
    """

    n_tokens = model.count_tokens(prompt)

    logger.info(f"JOB : SPEECH-TO-TEXT TRANSCRIPTION CORRECTION. \n{n_tokens.total_billable_characters} BILLABLE CHARACTERS")
    logger.info(f"RESPONSE WILL PROCESS {n_tokens.total_tokens} TOKENS.")

    start = time.time()

    response = model.generate_content(prompt)

    stop = time.time()

    curated_filename = raw_transcription_filename.replace("_raw", "_curated")

    destination_bucket = storage_client.bucket(destination_bucket_name)
    destination_blob = destination_bucket.blob(curated_filename)
    destination_blob.upload_from_string(response.text, content_type='text/plain; charset=utf-8')

    logger.debug(response.text)
    logger.info(f"JOB DONE IN {round(stop - start, 2)} SECONDS.")

The chosen architecture is modular and event-driven, which brings several advantages:

Scalability: This application can handle short or long videos, up to 8 hours.
Flexibility: The separation of concerns allows for easy maintenance and upgrades. If the user uploads a video in the video-files bucket, the three cloud function will be triggered. But if the user upload an audio in the audio-files bucket, then only the two last cloud functions will be triggered.
Cost-Efficiency: Cloud Functions are serverless. Using Cloud Functions ensures that resources are only used when necessary, reducing costs.

Deployment with Terraform

To ensure our solution is not only powerful but also easily manageable and deployable, we use Terraform for infrastructure as code (IaC). Terraform allows us to define our cloud resources in declarative configuration files, providing several key benefits:

Infrastructure configurations can be version-controlled using Git, following GitOps principles. This means changes to the infrastructure are tracked, reviewed, and can be rolled back if necessary.
As our application grows, Terraform makes it easy to manage our infrastructure by simply updating the configuration files.
Terraform makes the deployment of our application reliable and repeatable.

In this particular case, four cloud storage buckets and three cloud functions are needed. We use one terraform resource for the cloud functions and another for the buckets. This provides a flexible code, and makes it easier to integrate and manage new buckets or cloud functions. More information about terraform : Terraform documentation.

# locals.tf

locals {
    function_definitions = [
    {
        name = "convert_video_to_audio",
        source_dir = "../services/video_to_audio_cloud_function"
        input_bucket = var.video_files_bucket_name
    },
    {
        name = "speech_to_text_transcription",
        source_dir = "../services/transcript_cloud_function"
        input_bucket = var.audio_files_bucket_name
    },
    {
        name = "transcription_correction",
        source_dir = "../services/gemini_cloud_function"
        input_bucket = var.raw_transcriptions_bucket_name
    }
]
}

From this locals.tf file, the user can add, configure or remove cloud functions very easily. The cloud_functions.tf file uses one terraform resource for all cloud functions, and loops over these function definitions.

# cloud_functions.tf

resource "random_id" "bucket_prefix" {
  byte_length = 8
}

resource "google_storage_bucket" "source_code_bucket" {
  name                        = "${random_id.bucket_prefix.hex}-source-code-bucket"
  location                    = var.location
  force_destroy = true

  uniform_bucket_level_access = true
}

data "archive_file" "function_sources" {
  for_each    = { for def in local.function_definitions : def.name => def }
  type        = "zip"
  output_path = "/tmp/${each.value.name}-source.zip"
  source_dir  = each.value.source_dir
}

resource "google_storage_bucket_object" "function_sources" {
  for_each = data.archive_file.function_sources
  name     = "${basename(each.value.output_path)}-${each.value.output_md5}.zip"
  bucket   = google_storage_bucket.source_code_bucket.name
  source   = each.value.output_path
}

data "google_storage_project_service_account" "default" {}

resource "google_project_iam_member" "gcs_pubsub_publishing" {
  project = var.deploy_project
  role    = "roles/pubsub.publisher"
  member  = "serviceAccount:${data.google_storage_project_service_account.default.email_address}"
}

resource "google_service_account" "account" {
  account_id   = "gcf-sa"
  display_name = "Test Service Account - used for both the cloud function and eventarc trigger in the test"
}

resource "google_project_iam_member" "roles" {
  for_each = {
    "invoking"                   = "roles/run.invoker"
    "event_receiving"            = "roles/eventarc.eventReceiver"
    "artifactregistry_reader"    = "roles/artifactregistry.reader"
    "storage_object_admin"       = "roles/storage.objectUser"
    "speech_client"              = "roles/speech.client"
    "insights_collector_service" = "roles/storage.insightsCollectorService"
    "aiplatform_user"            = "roles/aiplatform.user"
  }
  project    = var.deploy_project
  role       = each.value
  member     = "serviceAccount:${google_service_account.account.email}"
  depends_on = [google_project_iam_member.gcs_pubsub_publishing]
}

resource "google_cloudfunctions2_function" "functions" {
  for_each = { for def in local.function_definitions : def.name => def }
  depends_on = [
    google_project_iam_member.roles["event_receiving"],
    google_project_iam_member.roles["artifactregistry_reader"],
  ]
  name        = each.value.name
  location    = var.location
  description = "Function to process ${each.value.name}"

  build_config {
    runtime     = "python39"
    entry_point = each.value.name
    environment_variables = {
      BUILD_CONFIG_TEST = "build_test"
    }
    source {
      storage_source {
        bucket = google_storage_bucket.source_code_bucket.name
        object = google_storage_bucket_object.function_sources[each.key].name
      }
    }
  }

  service_config {
    min_instance_count = 1
    max_instance_count = 3
    available_memory = "256M"
    timeout_seconds    = 60
    available_cpu = 4
    environment_variables = {
      PROJECT_ID                         = var.deploy_project
      AUDIO_FILES_BUCKET_NAME            = var.audio_files_bucket_name
      RAW_TRANSCRIPTIONS_BUCKET_NAME     = var.raw_transcriptions_bucket_name
      CURATED_TRANSCRIPTIONS_BUCKET_NAME = var.curated_transcriptions_bucket_name
    }
    ingress_settings               = "ALLOW_INTERNAL_ONLY"
    all_traffic_on_latest_revision = true
    service_account_email          = google_service_account.account.email
  }

  event_trigger {
    trigger_region        = var.location
    event_type            = "google.cloud.storage.object.v1.finalized"
    retry_policy          = "RETRY_POLICY_RETRY"
    service_account_email = google_service_account.account.email
    event_filters {
      attribute = "bucket"
      value     = google_storage_bucket.video_transcription_bucket_set[each.value.input_bucket].name
    }
  }
}

Similarly the buckets.tf file uses only one terraform resource for all Cloud Storage buckets.

# buckets.tf

resource "google_storage_bucket" "video_transcription_bucket_set" {
  for_each = toset([
    var.video_files_bucket_name,
    var.audio_files_bucket_name,
    var.raw_transcriptions_bucket_name,
    var.curated_transcriptions_bucket_name
  ])
  name = each.value
  location = var.location
  storage_class = "STANDARD"
  force_destroy = true

  uniform_bucket_level_access = true
}

Costs

Storage:

$0.026 per gigabyte per month

Speech-to-Text API v2:

Depends on the amount of audio you plan to process:

$0.016 per minute processed per month for 0 to 500,000 minutes of audio
$0.01 per minute processed per month for 500,000 to 1,000,000 minutes of audio
$0.008 per minute processed per month for 1,000,000 to 2,000,000 minutes of audio
$0.004 per minute processed per month for over 2,000,000 minutes of audio

Pricing details

Gemini API:

Under the following limits, the service is free of charge:

15 requests per minute
1 million tokens per minute
1,500 requests per day If you want to exceed these limits, a pay-as-you-go policy is applied. Pricing details

Cloud Functions:

The pricing depends on how long the function runs, how many times it is triggered, and the resources that are provisioned. The following link explains the pricing policy for event-driven cloud functions.

Estimate the costs of your solution with Google Cloud’s pricing calculator.

Example:
A state institution wants to automate transcript generation for meetings. The average duration of these meetings is 4 hours. The records are uploaded to GCP using this solution. Let’s simulate the costs of one transcription for this specific use case using the simulator:

The final cost per month, with one transcription per month, is estimated to be $5.14. More than half the costs are due to Speech-to-Text API use.

Service Display Name	Name	Quantity	Region	Total Price (USD)
Speech-to-Text V2	Cloud Speech-to-Text Recognition	240.0	global	3.84
Cloud Functions 1	CPU Allocation Time (2nd Gen)	40080000	us-central1	0.96192
Cloud Functions 1	Memory Allocation Time (2nd Gen)	25600000000	us-central1	0.0625
Cloud Functions 1	Invocations (2nd Gen)	1000.0	global	0
Cloud Functions 2	CPU Allocation Time (2nd Gen)	4008000.0	europe-west1	0.09619
Cloud Functions 2	Memory Allocation Time (2nd Gen)	2560000000	europe-west1	0.00625
Cloud Functions 2	Invocations (2nd Gen)	1000.0	global	0
Cloud Functions 3	CPU Allocation Time (2nd Gen)	4008000.0	europe-west1	0.09619
Cloud Functions 3	Memory Allocation Time (2nd Gen)	2560000000	europe-west1	0.00625
Cloud Functions 3	Invocations (2nd Gen)	1000.0	global	0
Cloud Storage 1	Standard Storage Belgium	3.0	europe-west1	0.06
Cloud Storage 2	Standard Storage Belgium	0.5	europe-west1	0.01
Cloud Storage 3	Standard Storage Belgium	0.01	europe-west1	0.0002
Cloud Storage 4	Standard Storage Belgium	0.01	europe-west1	0.0002

	Total Price:			5.1397

Prices are in US dollars, effective date is 2024-07-01T08:32:56.935Z

The estimated fees provided by Google Cloud Pricing Calculator are for discussion purposes only and are not binding on either you or Google. Your actual fees may be higher or lower than the estimate.

Url to the estimate:	Link to estimate

Conclusion

Leveraging AI to enhance video-to-text transcription on Google Cloud Platform offers significant benefits in scalability, flexibility, and efficiency. By integrating Chirp for speech-to-text conversion and Gemini Pro for transcription curation, and managing the deployment with Terraform, this solution provides a robust, easily deployable framework for high-quality transcriptions across various applications.

Thanks for reading! I’m Maximilien, data engineer at Stack Labs.
If you want to discover the Stack Labs Data Platform or join an enthousiast Data Engineering team, please contact us.

Montrez patte blanche : tuez des mutants !

Antoine Aubé — Thu, 16 May 2024 11:52:08 +0000

Faites-vous confiance à vos logiciels préférés ? Probablement. Pourquoi leur faites-vous confiance ? L'ont-ils mérité ? La pléthore d'outils que nous utilisons au quotidien nous est souvent imposée par les mêmes personnes qui attendent de notre travail une haute qualité. Pourtant, dans le feu de l'action, rares sont ceux qui questionnent la qualité des ces outils là.

Le test logiciel est plébiscité dans l'industrie pour montrer patte blanche. Compte tenu des contraintes du monde réel (temps, argent), une question se pose : quels tests dois-je écrire ? Ou formulé autrement, dès lors que nous avons la notion de bon test : quand dois-je arrêter d'en écrire ? Pour nous aider à y répondre, nous utilisons souvent la couverture de code par les tests dans l'industrie. Dans cet article, je présente une suggestion de complément à cette mesure, une pratique : le test de mutation.

Dans un premier temps, nous reviendrons sur les concepts évoqués ci-dessus, en nous demandant à quoi ils peuvent nous servir. Dans un second temps, nous nous concentrerons sur l'écosystème Go : d'abord en passant en revue les outils qui automatisent le test de mutation, puis en utilisant ces outils pour savoir si nous avons raison de nous fier à nos logiciels (écrits en Go) préférés.

D'une spécification à la confiance dans son implémentation logicielle

Un programmeur programme pour satisfaire un besoin. L'expression de ce besoin est souvent laconique et informel : il faut le préciser. L'élicitation des exigences doit permettre d'en lever les zones d'ombres, et l'analyse de ces exigences d'aboutir à la spécification d'un logiciel. Cette spécification est la base sur laquelle le programmeur repose pour écrire le code source du logiciel.

Prenons un exemple : la première étape du kata « FizzBuzz ». Nous pouvons la reformuler comme suit :

Écrire une fonction qui prend, en entrée, un entier, et qui retourne « fizz » si l'entier est multiple de trois, « buzz » s'il est multiple de cinq, « fizzbuzz » s'il est multiple à la fois de trois et de cinq, et simplement l'entier dans les autres cas.

Je me suis prêté à l'exercice en programmant une implémentation de cet énoncé en Go, une fonction nommée MyFizzBuzz :

// (module : git.sr.ht/~arjca/fizzbuzz ; fichier : fizzbuzz.go)
package fizzbuzz

import "strconv"

func MyFizzBuzz(n int) string {
    if n%15 == 0 {
        return "fizzbuzz"
    }

    if n%3 == 0 {
        return "fizz"
    }

    if n%5 == 0 {
        return "buzz"
    }

    return strconv.Itoa(n)
}

À ce stade, nous pouvons nous demander si l'énoncé est correctement implémenté. Autrement dit : si j'utilise MyFizzBuzz, se comportera-t-elle comme prévu ?

Répondre à ce genre de questions est crucial dans l'industrie. En effet, le dysfonctionnement d'un logiciel peut coûter très cher aux organisations qui les développent, et avoir des conséquences dramatiques pour celles qui les utilisent. Concentrons-nous donc sur ce sujet.

Vérifier que la spéc. est correctement implémentée

Comment s'assurer qu'un logiciel se comporte comme prévu ? Comme dit dans l'introduction, la pratique courante dans l'industrie du numérique est de tester : vérifier que le logiciel se comporte conformément aux attentes dans une situation précise.

Écrivons un test pour MyFizzBuzz. Quand l'entier en entrée égale trois, la consigne dit que MyFizzBuzz devrait produire « fizz ». Ce test est automatisé par le code suivant :

// (fichier : fizzbuzz_test.go)
package fizzbuzz_test

import (
    "git.sr.ht/~arjca/fizzbuzz"
    "testing"

    "github.com/stretchr/testify/assert"
)

func TestMyFizzBuzz_3ShouldReturnFizz(t *testing.T) {
    assert.Equal(t, "fizz", fizzbuzz.MyFizzBuzz(3))
}

Exécutons le :

$ go test .
ok      git.sr.ht/~arjca/fizzbuzz   0.007s

Le test est réussi. Il y a au moins un cas dans lequel MyFizzBuzz se comporte correctement. Cela signifie-t-il que le logiciel est dépourvu de bogue ? Certes non, comme l'a dit Dijkstra :

tester un programme peut démontrer la présence d'un bogue, jamais son absence.

Pour dissiper tous soupçons sur MyFizzBuzz, il nous resterait bien du travail : 18 446 744 073 709 551 615 tests doivent encore être écrits (car les int occupent 64 bits sur ma machine).
Écrire autant de tests n'est évidemment pas raisonnable ; nous allons devoir en écrire moins, et les bons tests. Mais qu'est-ce qu'un bon test ? Pas simple comme question, et apparemment pas prioritaire car une autre s'impose : quand pouvons nous nous arrêter d'en écrire ? Une réponse naïve pourrait être : « Quand nous aurons suffisamment confiance dans le logiciel ! ». Reste à déterminer les mesures sur lesquelles fonder cette confiance.

Qu'ai-je déjà vérifié ?

Une première piste, largement suivie dans l'industrie, est de mesurer la couverture de code par les tests. Communément, il s'agit du pourcentage de lignes du code source parcourues lors de l'exécution des tests (alternativement, nous pourrions compter les fonctions, les modules, ...).

Calculons cette couverture pour MyFizzBuzz :

$ go test . -cover
ok      git.sr.ht/~arjca/fizzbuzz   0.002s  coverage: 57.1% of statements

Pour l'instant, 57.1% des lignes de MyFizzBuzz sont parcourues en exécutant le test. Est-ce assez ?

Il n'y a pas de réponse consensuelle à cette question. Dans l'industrie, il n'est pas rare de trouver des objectifs pour la couverture de code par les tests. 80% est un nombre récurrent, aussi bien dans les retours d'expérience de collègues que dans ma propre expérience professionnelle. Cela veut quand même dire qu'il y a 20% du code source sans le moindre contrôle.
Dans des échanges en ligne, nous pouvons trouver d'autres sons de cloche. Certains disent que 99% ou 100% sont des objectifs souhaitables, tandis que d'autres refusent tout minimum pour cette métrique.

Une raison fréquemment invoquée pour refuser un minimum de couverture à atteindre, ou pour réduire ce minimum, est que cela mène à un surcoût (car cela augmente le nombre de tâches de développement : soit un surcoût financier car il faut plus de programmeurs, soit un surcoût temporel incompatible avec le respect des dates de livraison). À mon étonnement, j'ai rarement vu mentionné en ligne le surcoût lié à un dysfonctionnement non détecté lors du développement, qui justifie la démarche de test.

S'il y a un seuil à atteindre, peu importe lequel dans ce que nous avons mentionné plus haut, MyFizzBuzz n'est pas à la hauteur. Améliorons ce score avec un nouveau test :

// (fichier : fizzbuzz_test.go)
package fizzbuzz_test

import (
    "git.sr.ht/~arjca/fizzbuzz"
    "testing"

    "github.com/stretchr/testify/assert"
)

func TestMyFizzBuzz_3ShouldReturnFizz(t *testing.T) {
    assert.Equal(t, "fizz", fizzbuzz.MyFizzBuzz(3))
}

func TestMyFizzBuzz_yolo(t *testing.T) {
    for n := 0; n < 500; n++ {
        fizzbuzz.MyFizzBuzz(n)
    }
}

À présent, recalculons :

$ go test . -cover
ok      git.sr.ht/~arjca/fizzbuzz   0.002s  coverage: 100.0% of statements

Nous voici à présent à 100% de couverture ! Peu importe l'objectif, il est forcément atteint. Hélas, nous avons un peu triché : le nouveau test ne vérifie pas les valeurs produites par MyFizzBuzz... Qu'avons-nous donc montré ? Tout au plus, qu'il n'y a pas de code mort dans MyFizzBuzz : nous avons pu parcourir toutes les lignes de la fonction. Mais ce n'est pas ça que nous voulions !

En définitive, la couverture de code par les tests n'est pas un indicateur suffisant de la correction d'un logiciel. Il nous faut la compléter.

Mutez les tous !!! La spéc. reconnaîtra les siens !

Voici une autre piste à explorer. Nous avons un plan de test qui valide un code source, certes ; mais que pouvons-nous conclure s'il valide aussi un autre code source ? Assurément, cela soulèverait des doutes quant à sa qualité, nous aurions raison de nous demander ce que ce plan de test valide réellement. Idéalement, comme nous avons pris des décisions pour programmer le logiciel comme ça et pas autrement, le plan de test devrait valider ce code source là et pas un autre.

Précédemment, nous avons écrit un test, TestMyFizzBuzz_3ShouldReturnFizz, en toute bonne foi en reposant sur la consigne. Tentons de le faire échouer en modifiant légèrement MyFizzBuzz :

-   if n%3 == 0 {
+   if n%3 != 0 {
        return "fizz"
    }

Exécutons les tests :

$ go test . -cover
--- FAIL: TestMyFizzBuzz_3ShouldReturnFizz (0.00s)
    fizzbuzz_test.go:12: 
            Error Trace:    /home/arjca/Projets/fizzbuzz/fizzbuzz_test.go:12
            Error:          Not equal: 
                        expected: "fizz"
                        actual  : "3"

                        Diff:
                        --- Expected
                        +++ Actual
                        @@ -1 +1 @@
                        -fizz
                        +3
            Test:           TestMyFizzBuzz_3ShouldReturnFizz
FAIL
FAIL    git.sr.ht/~arjca/fizzbuzz   0.003s
FAIL

Comme prévu, le test échoue. Nous avons bien constaté que TestMyFizzBuzz_3ShouldReturnFizz aboutit à un succès avec MyFizzBuzz mais pas avec une de ses variantes. Nous venons de réaliser un test de mutation :

Le plan de test valide le code source de MyFizzBuzz ;
Nous altérons ce code source : nous générons un mutant. Une règle permettant de générer un mutant s'appelle un mutateur. Par exemple, un mutateur peut demander la modification d'un < en un <=, ou bien changer true en false. Notons que les mutateurs peuvent générer des mutants identiques sémantiquement au code source d'origine : c'est un mutant équivalent ;
Nous confrontons le plan de test au mutant. Si au moins un test échoue, bingo : nous avons tué le mutant. Autrement, le mutant survit. Naturellement, nous voulons tuer le plus de mutants que possible.

Expérimentons une seconde mutation :

-   if n%5 == 0 {
+   if n%5 != 0 {
        return "buzz"
    }

Exécutons le plan de test. Nous constatons qu'aucun test n'échoue :

$ go test .
ok      git.sr.ht/~arjca/fizzbuzz   0.002s

Le mutant a survécu. Si un mutant survit, alors la ligne contenant la mutation est faiblement testée : il manque peut-être un test (p. ex. si la couverture de code par les tests n'est pas élevée), ou alors les tests existants ne sont pas de bonne facture.

Un plan de test par mutation peut générer un très grand nombre de mutants, et nous pouvons en tirer une mesure : le score de mutation. Il est le ratio du nombre de mutants tués sur le nombre total de mutants non-équivalents. Plus le score de mutation est élevé, plus le plan de test rejette ce qui n'est pas le code source d'origine ; autrement dit, plus il rejette les tests bidons.

Néanmoins, il nous faut évoquer deux difficultés :

Détecter un mutant équivalent n'est pas trivial ;
Le nombre de mutants peut être très, très grand, et demander un nombre déraisonnable de manipulations.

Pour surmonter la première difficulté, diverses approches existent : par exemple, pour détecter les mutants équivalents, ou simplement pour ne pas les générer. Une revue de ces approches a été réalisée par Madeyski et coll. en 2017.

Pour surmonter la seconde difficulté, nous pouvons déjà nous demander comment éviter les mutants inutiles : ceux qui sont équivalents à un autre mutant. Afin d'y parvenir, Fernandes et coll. proposent un ensemble de règles pour leur génération. Si cela diminue le nombre de mutants à générer et à essayer de tuer, cela demande encore énormément de calculs : il nous faut les automatiser.

Automatiser le test de mutation en Go

La suite de cet article est consacrée au test de mutation avec le langage Go. Il existe plusieurs outils pour automatiser le test de mutation en Go ; je les passe en revue dans cette section.

manbearpig

manbearpig est un outil développé par Daniel Huckstep en 2013. Il va à l'essentiel : l'utilisateur spécifie un paquetage et un mutateur, puis l'outil génère les mutants et les confronte aux tests.

Par exemple avec MyFizzBuzz :

$ manbearpig -import git.sr.ht/~arjca/fizzbuzz -mutation "=="
2024/04/13 18:54:46 mutating in /tmp/manbearpig1715124091
2024/04/13 18:54:46 found 3 occurrence(s) of == in fizzbuzz.go
2024/04/13 18:54:46 mutating == to !=
2024/04/13 18:54:46 mutation 1 broke the tests properly
2024/04/13 18:54:46 mutation 2 broke the tests properly
2024/04/13 18:54:46 mutation 3 failed to break any tests

L'outil indique seulement le nombre de mutants générés ; nous manquons de détails quant à la ligne concernée par chaque mutation, et les tests qui ont tué chaque mutant. Par conséquent, il est difficile d'analyser les résultats et d'en tirer grand chose.
Le score de mutation peut être déduit des traces ; cela reste très manuel, d'autant plus qu'il est nécessaire d'utiliser plusieurs fois l'outil pour couvrir toutes les mutations qui nous intéressent.

mutator

mutator est un outil développé par Kamil Kisiel en 2013. Lui aussi va à l'essentiel, avec seulement un paquetage à fournir, et éventuellement des mutateurs.

Par exemple avec MyFizzBuzz :

$ mutator git.sr.ht/~arjca/fizzbuzz
using /tmp/mutate4042507686 as a temporary directory
fizzbuzz.go has 3 mutation sites
mutation fizzbuzz.go:7:10 tests failed as expected
mutation fizzbuzz.go:11:9 tests failed as expected
mutation fizzbuzz.go:15:9 did not fail tests

D'une certaine manière, cet outil est complémentaire à manbearpig : ici, nous savons quelle ligne accueille chaque mutation, mais pas quel mutateur est utilisé...
Une seule utilisation est requise pour calculer le score de mutation, mais ce calcul demeure manuel.

ooze

Contrairement aux projets précédents, qui sont des outils utilisables via une interface en ligne de commande, ooze est une bibliothèque. Elle est développée principalement par Guilherme Tramontina et continue de recevoir des mises à jour.

Pour l'utiliser, j'ai ajouté un nouveau fichier dans mon module :

//go:build mutation
// (fichier : mutation_test.go)
package fizzbuzz_test

import (
    "testing"

    "github.com/gtramontina/ooze"
)

func TestMutation(t *testing.T) {
    ooze.Release(t)
}

Il ne reste plus qu'à l'exécuter :

$ go test -tags=mutation 
┃ Releasing Ooze…
[...]
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ • Total:       18                    ┃
┃ • Killed:       7                    ┃
┃ • Survived:    11                    ┃
┠┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┨
┃ ⨯ Score:     0.39 (minimum: 1.00)    ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
--- FAIL: TestMutation (5.02s)
FAIL
exit status 1
FAIL    git.sr.ht/~arjca/fizzbuzz   5.021s

Nous avons ici bien plus de détails ! Les lignes que j'ai omises par souci de lisibilité documentent les mutants survivants. Le récapitulatif à la fin contient le score de mutation : 39% pour MyFizzBuzz. Pas fameux !

Notons que la bibliothèque permet d'implémenter de nouveaux mutateurs (appelés virus dans ooze).

go-mutesting

go-mutesting est un outil développé par trois personnes de l'entreprise russe Avito.

$ go-mutesting .     
[...]
FAIL "/tmp/go-mutesting-619693096/fizzbuzz.go.17" with checksum 25620396c64f05efbecca57ef98b046e
The mutation score is 0.333333 (6 passed, 12 failed, 0 duplicated, 0 skipped, total is 18)

Tout comme ooze, cet outil donne des détails sur les mutants survivants (que j'ai ici omis pour ne pas polluer l'espace !). Il calcule également le score de mutation : 33%. Ce n'est pas le même que celui de ooze car ils n'utilisent pas les mêmes mutateurs, mais cela reste un score médiocre.

Avec cet outil, il est également possible de définir de nouveaux mutateurs en implémentant une interface, mais il faut que cela soit enregistré dans le code source de l'outil ; il faut donc soit y contribuer, soit cloner ce projet.

gremlins

gremlins est un outil initié par Davide Petilli et aux nombreux contributeurs.

Il dispose d'options pour limiter le nombre de mutants évalués, et en particulier il se base sur la couverture de code par les tests : si une ligne n'est pas couverte par un test, alors il n'y a pas de raison de générer un mutant pour savoir si elle est correctement testée. Cela peut avoir des effets de bord non désirés. Par exemple, l'outil intégré à Go pour générer la couverture de code n'indique pas si les case ... des switch sont couverts ou non, ils ne sont juste pas suivis ; par conséquent, une mutation qui devrait être réalisée dans ces lignes ne sera pas générée par gremlins.

Pour MyFizzBuzz, cela donne :

$ gremlins unleash       
Starting...
Gathering coverage... done in 344.804964ms
      KILLED CONDITIONALS_NEGATION at fizzbuzz.go:11:9
       LIVED ARITHMETIC_BASE at fizzbuzz.go:15:6
       LIVED CONDITIONALS_NEGATION at fizzbuzz.go:15:9
       LIVED ARITHMETIC_BASE at fizzbuzz.go:7:6
      KILLED ARITHMETIC_BASE at fizzbuzz.go:11:6
      KILLED CONDITIONALS_NEGATION at fizzbuzz.go:7:10

Mutation testing completed in 322 milliseconds 805 microseconds
Killed: 3, Lived: 3, Not covered: 0
Timed out: 0, Not viable: 0, Skipped: 0
Test efficacy: 50.00%
Mutator coverage: 100.00%

Le score de mutation,appelé ici « efficacité des tests », égale 50% ; encore un autre score !

L'exemple de MyFizzBuzz est un peu court pour mettre en lumière les fonctionnalités de gremlins. Nous pouvons noter :

Utilisation de plusieurs cœurs CPU pour générer et évaluer plusieurs mutants à la fois ;
Possibilité de générer des mutants uniquement pour les lignes modifiées entre deux contributions sur Git, ce qui permet d'accélérer grandement l'exécution ;
Génération d'un rapport en JSON pour des traitements a posteriori ;
Possibilité de déclarer un objectif pour le score de mutation. Le code de sortie d'une exécution est un code d'erreur si l'objectif n'est pas atteint (utile par exemple dans une chaîne CI/CD) ;
Les tests peuvent passer en TIMEOUT s'ils prennent trop de temps à être exécutés ; Cela permet d'accélérer l'exécution du test de mutation mais dégrade la précision du test de mutation. Le temps-limite est calculé avec le temps d'exécution du plan de test sur le code source original, et un facteur multiplicatif.

Résumé

Nous avons passé en revue plusieurs outils pour automatiser le test de mutation en Go. D'un côté, manbearpig et mutator sont d'anciens projets qui ne sont pas tenus à jour ; de l'autre, ooze, go-mutesting, et gremlins sont des outils aux fonctionnalités similaires.

Je propose quelques constats :

le score de mutation calculés par chaque outil est différent. C'est dû aux mutateurs utilisés : tous les outils n'évaluent pas les mêmes mutants. Le score de mutation n'est donc pas comme la couverture de code par les tests : sa valeur dépend beaucoup de l'outil de mesure. Cependant, je ne pense pas qu'un plan de test donnant un score médiocre avec un outil puisse donner un score excellent avec un autre. Il y a juste des outils un peu plus optimistes que d'autres ;
gremlins et go-mutesting génèrent des rapports utilisables par ailleurs, par exemple pour afficher les lignes de code faiblement testées dans un IDE. Cependant, ces rapports suivent des conventions différentes ;
à part ooze, il est nécessaire de contribuer au développement de l'outil, ou d'en créer une version alternative, pour ajouter un mutateur ;
aucun de ces outils ne permet une utilisation incrémentale, c'est-à-dire que chaque exécution de ces outils entraîne l'analyse intégrale du code source. Certes, gremlins a une option diff pour restreindre l'analyse à une portion du code, mais cela ne permet pas de recalculer le score de mutation pour l'ensemble du projet ;
gremlins est le seul outil de cette revue qui fait des compromis entre la précision du score de mutation et le temps d'exécution.

À présent munis d'un moyen d'automatiser le test de mutation, nous pouvons mener de nouvelles investigations.

Des projets populaires à l'épreuve de la mutation

Pour finir cet article, nous pouvons enfin revenir à la question initiale : avons-nous raison de faire confiance à nos logiciels préférés ?

Nous allons y répondre sous le prismes des notions présentées plus haut, et en nous cantonnant aux projets écrits en Go.

Objectif

L'objectif est de vérifier si le plan de test des projets (logiciels, bibliothèques) populaires en Go sont de bonne qualité.

Les projets que nous allons considérer ici sont les logiciels et les bibliothèques écrits en Go (et non, p. ex., les tutoriels) et hébergés sur GitHub.
Pour simplifier la notion de popularité d'un projet, nous allons considérer leur nombre d'étoiles sur GitHub. Nous nous intéressons donc aux projets ayant le plus d'étoiles.
Comme présenté plus haut, nous allons aussi réduire la qualité d'un plan de test à sa couverture de code et son score de mutation. Nous allons devoir définir ce qui est une valeur élevée pour ces deux mesures. Pour la suite, je choisis arbitrairement que :

une couverture de code par les tests élevée est d'au moins 80% (ce qui laisse tout de même 20% du code source libre de tout contrôle) ;
un score de mutation élevé est d'au moins 80% (ce qui signifie tout de même que le plan de test « laisse passer » 20% des variantes générées à partir du code source).

L'hypothèse que nous allons vérifier est la suivante : un projet populaire a mérité sa popularité en démontrant sa qualité à travers un plan de test de bonne qualité. Nous allons raffiner cette hypothèse en deux sous-hypothèses :

un projet populaire a une haute couverture de code par les tests ;
un projet populaire a un haut score de mutation.

Si un projet a une haute couverture de code par les tests et un score de mutation médiocre, alors un grand nombre de ses tests sont bidons. S'il a une faible couverture et un grand score de mutation, alors la petite portion du code testée peut être jugée fiable. Si ces deux métriques sont faibles, nous ne pouvons rien tirer du plan de test. Dans ces trois cas, la popularité du projet doit être expliquée par autre chose que sa qualité (p. ex. la publicité, la mode).

Échantillonnage des projets

Pour commencer, nous devons lister les projets populaires à analyser. Prenons les 300 projets de la catégorie Go sur GitHub qui ont le plus d'étoiles. Pour lister leurs URL, utilisons l'outil en ligne de commande de GitHub :

gh search repos --topic go --sort stars --limit 300 --json url | jq -r ".[].url"

Cela aboutit... à une liste de 300 liens. Tous ne nous intéressent pas. En effet :

certains des dépôts contiennent des exemples et des tutoriels, avec certes du code Go mais dont on n'attend pas qu'il soit testé pour que les gens veuillent bien l'utiliser ;
d'autres sont des agrégations de sources diverses, des livres ou bien des logiciels écrits dans un autre langage que Go : bref, il n'y a pas de code Go à tester.

Une première passe nous permet d'en éliminer 34. Il reste donc 266 dépôts à analyser.

Mesures réalisées

Pour investiguer les projets, j'ai utilisé quelques outils :

nombre d'étoiles sur GitHub : gh (l'outil en ligne de commande de GitHub) ;
couverture de code par les tests : l'outillage inclus dans la distribution de Go ;
score de mutation : gremlins, car même s'il aboutit à des scores de mutation un peu plus élevés que les autres, ses fonctionnalités m'ont permis de réaliser l'analyse de tous les projets dans un temps « raisonnable ».

J'ai réalisé les calculs en plusieurs étapes.

D'abord, j'ai réalisé une première passe des projets pour en extraire les informations les plus rapides à produire, notamment :

leur nombre d'étoiles sur GitHub ;
leur nombre de lignes de code ;
la durée d'exécution du plan de test ;
la couverture de code par les tests. Cette étape est importante car, si exécuter le plan de test est supposé être rapide, nous allons devoir l'exécuter de très nombreuses fois pour évaluer le score de mutation : avec des moyens matériels limités pour réaliser l'étude, nous devons faire des choix. Par exemple, exécuter le plan de test du projet aws-sdk-go prend près d'une minute et demi sur ma machine ; or, le projet compte presque six millions de lignes : le plan de test risque d'être exécuté des millions de fois, ce qui peut être déraisonnablement long.

Ensuite, pour chaque projet retenu, j'ai exécuté les tests de mutation.

Résultats

De nombreux jours de calcul plus tard, voici venue l'heure des résultats ! (ici, les résultats compilés au format CSV)

Premières remarques :

le fichier contient 256 entrées, soit 10 de moins qu'attendu. En effet, j'ai compté une entrée par module Go dans les dépôts, et certains n'en avaient aucun. Néanmoins, certains autres en avaient plusieurs (voir la colonne Folder) ;
les tests ont échoué dans 129 modules, soit un peu plus de la moitié des modules analysés. Dans la plupart des cas, c'est lié à des dépendances attendues sur la machine qui exécute les tests : par exemple, les tests de minikube sont dépendants de libvirt. Étant donné le nombre de projets à analyser, je n'ai pas étudié chacun dont les tests sont en échec. J'ai décidé de simplement les mettre de côté ;
j'ai mis huit modules de côté car, étant donné leur taille et la durée d'exécution de leurs tests, cela aurait été trop long de calculer leur score de mutation.

Finalement, j'ai calculé la couverture de code par les tests de 125 modules, et le score de mutation de 117 d'entre eux.

D'abord, jetons un œil sur un premier graphique avec des données « démographiques » sur nos projets. Les projets sélectionnés sont assez variés, autant dans leur nombre de lignes de code que dans leur nombre d'étoiles sur GitHub. La variance est immense. Nous n'observons pas de corrélation entre le nombre de lignes de code et la popularité des projets, ni entre le nombre de tests et leur popularité. Cela n'est pas très étonnant. En revanche, il n'apparaît pas non plus de corrélation entre le nombre de tests et le nombre de lignes de code, ce qui est curieux : à voir s'il s'agit de surqualité dans certains petits projets avec beaucoup de tests, ou de sous-qualité dans les autres.

Ensuite, intéressons-nous à la couverture de code par les tests. Le graphique ci-dessous montre plusieurs choses :

nous identifions deux pics : un premier entre 50% et 60% de couverture de code par les tests, et un autre un peu moins grand autour de 20% ;
les plus grands projets en nombre de lignes de code (LOC > 100000) ont pour la quasi-totalité une couverture de code par les tests inférieure à 60% ;
seuls 22 modules ont 80% de couverture ou plus, soit environ 18% des modules analysés.

Cela permet de trancher pour la première hypothèse : non, les projets écrits en Go les plus populaires n'ont pas une bonne couverture de code par les tests.

Enfin, voyons les résultats des tests de mutation. À nouveau, il est difficile d'établir la moindre corrélation à partir de cette figure. Cependant, il est évident que si de nombreux modules n'ont pas une grande couverture de code par le test, le score de mutation est, lui, plutôt élevé en général.
Remarquons toutefois que les projets avec une bonne couverture ont aussi systématiquement un score de mutation élevé (> 60%), ce qui n'est pas le cas de certains projets avec une moindre couverture.

Pour revenir à notre hypothèse, nous comptons 49 modules avec un score de mutation supérieur à 80%, soit presque 42% des projets analysés. Valider notre hypothèse dans ces conditions serait exagéré. Notons tout de même la grande concentration des projets autour de ce niveau, 80% : 66% des modules ont un score de mutation supérieur à 70%, et plus de 13% des modules ont un score supérieur à 90%.

Résumé et rétrospective sur l'utilisation du test de mutation

En évaluant la qualité des plans de tests des projets écrits en Go les plus populaires, nous avons conclu qu'avoir un bon plan de test n'est pas un prérequis à la popularité. La plupart de ces projets ont une couverture en deçà des exigences communes de l'industrie.

En plus de cet aperçu de l'écosystème Go, cette investigation a mis en lumière des difficultés vis-à-vis du test de mutation :

ce type de test est gourmand autant en calcul, en mémoire vive et en stockage sur disque dur. Par conséquent, d'importants moyens sont requis pour le mettre en œuvre sur de grands projets ;
le temps d'exécution des tests de mutation est parfois très grand, et complètement tributaire de la taille du projet et de la rapidité d'exécution du plan de test. À titre d'exemple, le test de mutation pour le projet minio a duré près de 2 jours sur ma machine ;
un score de mutation indique que au plus un certain pourcentage des tests ne valide pas uniquement le code source du logiciel. La précision « au plus » est due aux potentiels mutants équivalents générés dans le processus ; difficile de savoir combien il y en a à chaque fois : cela demanderait une étude de chaque mutant survivant ;
l'outillage pour l'écosystème Go n'est pas encore idéal. D'après moi, il manque certaines fonctionnalités de confort et d'autres purement pratiques pour pouvoir être démocratisé dans l'industrie.

Les fonctionnalités que j'aimerais voir dans ces outils dans le futur sont les suivantes :

Reprendre un test de mutation interrompu sans exécuter à nouveau les mutants déjà évalués (p. ex. pour pouvoir lancer les tests de mutation sur une machine préemptible sur Google Compute Engine) ;
Restreindre les tests exécutés à ceux du paquetage contenant le code muté (afin de gagner du temps à l'exécution du test de mutation et à l'analyse des mutants survivants) ;
Suivre la progression d'un test de mutation (p. ex. avec une barre de progression qui indique le nombre de mutants déjà évalués, sur le nombre de mutants total) ;
Utiliser le test de mutation au fur et à mesure des évolutions, sans avoir à effectuer à nouveau l'intégralité du processus à chaque fois.

Conclusion

Dans ce (finalement) long article, nous avons rappelé les bases du test logiciel, de pourquoi nous le faisons et d'une question que les programmeurs devraient se poser : quels tests sont nécessaires et suffisants ? Pas de réponse claire à cette question, seulement des indices. L'un d'entre eux est la couverture de code par les tests, une mesure commune dans l'industrie pour évaluer la qualité d'un plan de test. Cependant, cette mesure n'est pas fiable seule, c'est pourquoi nous pourrions l'accompagner du score de mutation.
Plusieurs outils existent dans l'écosystème Go pour automatiser le calcul du score de mutation. Nous nous en sommes servi sur des projets très populaires à titre d'exemple.
Cette expérience nous a montré que, si ces projets sont très utilisés, ce n'est sans doute pas parce qu'ils ont fait la preuve de leur qualité dans leur plan de test. Une hypothèse pour expliquer ces manques : pas assez de moyens ; cependant, les importants scores de mutation que nous avons calculés devraient conforter l'idée que le travail réalisé est de bonne facture. En tant qu'informaticien, il est important que nous questionnions les outils de notre quotidien, et ne pas nous laisser influencer par la publicité. Plutôt que d'être de simples consommateurs, à nous de contribuer à ces outils pour les rendre plus sûrs et accroître leur qualité, sinon leurs fonctionnalités.

En guise d'ouverture, je souhaitais souligner que la couverture de code par les tests et le score de mutation sont deux mesures pour évaluer un certain aspect de la qualité d'un plan de test. Ils ne suffisent pas, puisqu'ils sont complètement indépendants de la spécification. À l'avenir, nous pourrions réfléchir à une nouvelle mesure qui établi à quelle point la spécification d'un logiciel est couverte par un plan de test : la couverture de spécification par les tests. En attendant, le développement dirigé par les tests (TDD) est une pratique à envisager car, d'une part, elle devrait aboutir à une couverture de code par les tests proche de 100% sans falsification et, d'autre part, c'est la spécification qui dirige la création des cas de test. À ce sujet, je vous recommande de visionner la présentation que Ian Cooper a donné en 2017 à la conférence DevTernity.

Merci d’avoir lu mon article ! Je suis Antoine, ingénieur cloud chez Stack Labs. Si vous voulez en savoir plus sur Stack Labs ou rejoindre une équipe de passionnés de tech, n’hésitez pas à nous contacter ici.

Crédits à Games Workshop® pour l'image de couverture.

Cloud : un peu d’ARM avec votre cluster Kubernetes ?

Λ\: Laurent Noireterre — Mon, 06 May 2024 12:10:04 +0000

La majorité des clouds providers proposent des solutions basées sur des architectures processeurs ARM, tel que Graviton chez AWS ou Tau T2A chez GCP. Les avantages de tels processeurs sont multiples : efficacité énergétique, couts réduits, performances… Ils sont de plus tout à fait adaptés aux environnements conteneurisés.

Exécuter vos workloads Kubernetes sur des processeurs ARM parait donc être un bonne idée. Cela rentre aussi dans une approche FinOps, car l’utilisation de processeurs arm en lieu et place de processeurs x86 va permettre des réductions de coûts non négligeables (de l’ordre de 20% avec des processeurs Graviton) à performances égales voire supérieures.

Si la mise en place d’une architecture arm peut paraitre assez simple sur de nouveaux clusters, qu’en est-il de la migration d’une architecture existante amd64 vers une architecture arm64 ?

Considérations

Avant de se lancer dans la migration vers une architecture arm, quelques considérations sont à prendre en compte vis-à-vis des applications qui tournent sur votre cluster.

Langages et librairies

La majorité des langages supportent maintenant des architectures ARM. Les langages interprétés (NodeJS, Python…) ou byte-code compilés (Java, .Net) devraient fonctionner sans modifications majeures. Attention cependant si vous utilisez des librairies ou fragments de codes natifs (JNI), une recompilation sera necessaire.

Les langages compilés (C/C++, Go…) supportent pour la plus grande majorité les architectures ARM mais ils devront être recompilés.

Images Docker

De manière générale nos applications packagées pour s’executer dans des conteneurs utilisent une image de base (le FROM du Dockerfile). Attention à bien vérifier que cette image aussi supporte ARM. C’est le cas de la majorité des standards et cela peut se vérifier rapidement en se connectant sur le registry depuis lequel elles sont tirées. Par exemple pour l’image officielle OpenJDK sur Dockerhub, on remarque que les 2 types d’architectures sont bien supportées :

Services tiers

Des services tiers tels que Prometheus ou ArgoCD peuvent aussi tourner sur nos cluster Kubernetes afin d’assurer diverses taches (observabilité, déploiement, sécurité…). Il faudra donc s’assurer là aussi que ces services sont déployables sur une architecture ARM.

Système d’exploitation

Si vous utilisez des services cloud entièrement managés tel que EKS Fargate ou GKE Autopilot il n’y aura aucun impact. Par contre si vous avez des noeuds que vous managez vous-même, une migration du système d’exploitation sera nécessaire.

Construction : Docker multi-architecture

Maintenant que vous vous êtes assuré que vos applications sont bien éligibles à une plateforme arm, il s’agit de les reconstruire afin qu’elles puissent tourner sur ce type d’architecture.

Principe

La meilleure solution pour pouvoir instancier vos conteneurs sur une architecture ARM n’est pas d’effectuer un build de vos images pour ce type d’architecture spécifiquement, mais plutôt d’utiliser une méthode de build multi-architecture. Votre image sera alors construite en même temps et à partir de la même source (DockerFile) pour une liste d’architecture que vous aurez prédéfinie.

Cela permettra de déployer ces nouvelles images sur vos clusters nouvellement configurés avec des noeuds arm, mais aussi de pouvoir lancer indifféremment vos containers sur des architectures plus classiques type amd64 pour du développement ou des tests par exemple.

Ce sera le runtime de conteneur qui, au moment du pull, récupérera les layers de l’image correspondant au type d’architecture sur lequel il tourne :

Mise en place

Solution 1 : Docker buildx

Une approche courante pour construire des images Docker multi-architecture consiste à utiliser le plugin docker buildx (https://docs.docker.com/build/architecture/#buildx).

Ce plugin se base sur QEMU (Quick Emulator) pour construire des images multi-architectures. QEMU est un émulateur de processeur qui permet d'exécuter du code destiné à une architecture spécifique depuis un autre type d’architecture. Cela va permettre de construire des images Docker pour des architectures différentes de celle de l'hôte.

Concrètement, tout ce que vous aurez à faire est d’installer le plugin docker buildx (vérifier la compatibilité avec votre version de docker), et de lancer un build en listant les plateformes cibles :

docker buildx create --use --name mybuild node-amd64
mybuild
docker buildx create --append --name mybuild node-arm64
docker buildx build --platform linux/amd64,linux/arm64 .

Le build et le push de l’image peuvent se faire avec une seule et même instruction :

docker buildx build --tag my-user/my-image --platform linux/arm64/v8,linux/amd64 --push .

Pour plus de détails vous pouvez vous référer à la procédure Docker: https://docs.docker.com/build/building/multi-platform/

Solution 2 : Manisfest

Une seconde solution, plus complexe, est la méthode “Do It Yourself”. Elle consiste à une création manuelle du manifest d'image après avoir effectué 2 builds, un pour chaque type d’architecture.

Elle fait aussi intervenir 3 registres d’images, car chacune des images construites doit être poussée dans son propre registre avant d’être poussée une 3ème fois dans un registre multi-architecture.

Donc pour résumer :

1 - On construit et on pousse une image pour chaque architecture

# AMD64
$ docker build -t my-user/my-image-amd64 --build-arg ARCH=amd64/ .
$ docker push my-user/my-image-amd64

# ARM64V8
$ docker build -t my-user/my-image-arm --build-arg ARCH=arm64v8/ .
$ docker push my-user/my-image-arm

2 - On créé un manifeste à partir de chacune des images

docker manifest create \
my-user/my-image \
--amend my-user/my-image-amd64 \
--amend my-user/my-image-arm

3 - On pousse le nouveau manifest

docker manifest push my-user/my-image

Remarque : il est aussi possible de jouer sur les tags des différentes images pour n’utiliser qu’un seul registry

Cette solution peut être utile si vous construisez vos images avec un autre outils que Docker, tels que Kaniko ou Buildah.

Un post sur le blog de Docker détaille ces 2 méthodes: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

Hosting : Cluster Kubernetes Hybride

Vous avez maintenant des images Docker multi-architectures capable de tourner indifféremment sur de l’amd64 ou de l’arm. Mais il est possible que pour une raison ou une autre, certaines de vos applications n’aient pas pu être construites pour architecture arm et que vous deviez donc conserver des noeuds type amd64 pour celles-ci.

Dans ce cas pas de panique, vous pouvez jouer sur les teintes et node selector (ou node affinity) de Kubernetes.

Je m’explique. Les clusters Kubernetes managés sont capables de gérer plusieurs groupes de noeuds, chacun de ces groupes pouvant s’appuyer sur des propriétés différentes (type d’instance, nombre d’instances…). Il est alors tout à fait possible de créer 2 groupes de noeuds distincts, l’un comportant des machines de type amd64 et l’autre de type arm. Pour garder la maitrise sur les workloads qui vont être déployés par la suite sur l’un ou l’autre groupe de noeuds, on appliquera une teinte sur l’un des groupes :

(Si vous n’êtes pas familier avec la notion de teinte et de node selector je vous invite à consulter à la documentation Kubernetes https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ et https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)

Par défaut tous nos pods seront ainsi déployés sur le node group arm. On utilisera alors un node selector ainsi qu’une tolération au niveau des pods que l’on souhaite assigner à un type d’architecture amd64.

tolerations:
- effect: NoSchedule
  key: node-arch-type
  value: amd64
nodeSelector:
  kubernetes.io/arch: amd64

Cela permet de continuer de faire tourner sans risque vos applications nos compatibles arm sur des noeuds amd64.

Remarque: on peut tout à fait envisager le mécanisme inverse, à savoir un déploiement par défaut sur des noeuds type amd64 (non teintés) et prévoir une sélection d’applications à déployer sur des noeuds type arm (grâce aux teintes et node selectors). Cela permet dans un cluster existant amd64, d’envisager une stratégie de migration de vos applications par lot.

Conclusion

Félicitations ! Vous avez maintenant un cluster Kubernetes capable d’héberger plusieurs types d’architectures, et des applications pouvant se déployer indifféremment sur l’une ou l’autre tout en gérant vous même cette répartition.

Ce type d'architecture de plus en plus répandu mérite vraiment de s'y intéresser, surtout dans le cas de la mise en place d'une nouvelle plateforme.

Pour ce qui est de la migration d'une plateforme existante, le ROI est de manière générale très intéressant mais une stratégie de migration doit impérativement être mise en place.

Applying graph theory for inferring your BigQuery SQL transformations: an experimental DataOps tool

Λ\: Clément Bosc — Tue, 16 Apr 2024 20:26:40 +0000

If you work with Google Cloud for your Data Platform there are chances that you use BigQuery and run your Data pipelines transformations in a ELT manner: using BQ query engine to run transformations as a series of SELECT statements, one after another. Indeed over the last few years, ELT and tools like DBT or Dataform have been the de-facto standard for running and organizing your Data transformations at scale.

Theses tools, that we may group under the “SQL orchestration tools” banner are great for many reasons:

SQL is the main and only language to express a transformation, indeed SQL is great for structured data (and even semi-structured data)
They do a great job at centralizing the transformations: nice for audits, lineage tracking and trust
They simplify the DataOps experience and help onboard Data Analysts in Data Engineer tasks
They can almost automatically infer the transformation dependencies by creating a DAG.

BUT, for my Platform Engineering background, they have a major flow: they miss a state. Indeed if you take declarative IaC tools like Terraform, the current state of the Data Platform infrastructure is stored in a file (the state), including the tables/views, the permissions etc...

But how is this a problem ?

The problem is that tools like DBT or Dataform are only running DML statements. For example to create a table the generated statement will be CREATE OR REPLACE TABLE AS SELECT your_transformation. This means that the tool never knows if the object exists before or not, so you cannot attach IAM permission on it with Terraform (because the object is re-created every day in your daily batch) neither can you use the table as agreement interface with consumers because the table does not exists prior to the transformation.

The solution: an experimental tool that use the best of both worlds

I wanted to keep the benefits from SQL orchestration tools (like Dataform on GCP), but in conjunction with Terraform for the Ops benefits, by keeping in mind the following requirements:

Table dependencies between 2 transformations (running the transformation B after the A if B reference table A in the query) should be automatically inferred
Table schema (type, column_name) must be automatically inferred: user should not lose time on writing the table schema if it can be deduced from the output.
Table should be automatically created prior to the transformation (not by the transformation) with an IaC tool : Terraform
Be able to have a custom monitoring interface that gathers all the transformations information: status, cost, performance, custom error messages etc..

Architecture proposal

Here is the architecture proposal for my experimental transformation DataOps-oriented tool

Transformation are BigQuery queries
Orchestration is carried by an auto-generated Cloud Workflow with all the correct dependencies and parallel steps when possible (if two transformations can run at the same time)
Monitoring is a BigQuery timestamp-partitioned table with a Pub/Sub topic (and an Avro schema for the interface) and a push-to-BQ streaming subscription
Transformations are defined in a git repository in yaml files. Jinja template are supported for flexibility and factorisation)
A Cloud Run endpoint that host all the schema/dependencies inference logic and Workflow body generation according to the transformation dependencies (more on the Cloud Run below)

How to infer dependencies ?

Here is where the magic happens : the automatic dependency inference. Let’s remind it, DAG in data pipelines are nothing more than Graphs (Direct Acyclic Graphs), so let’s use a Graph library to build them from raw SQL declarations. You can find all the detailed process and Python implementation examples in this post: Build the dependency graph of your BigQuery pipelines at no cost: a Python implementation

The raw SQL declarations are sent by Terraform to a remote Cloud Run instance that computes the inference logic (DAG creation, Workflows source code generation, table schema generation), so Terraform that immediately creates the tables and workflows, prior to any transformations.

Exemple: the experiment in action

Let’s take a simple example: we are in a standard Data Platform Architecture with a 3 layer principal: Bronze (raw data), Silver (curated data) and Gold (aggregated/meaningful data). We need to run a data transformation pipeline, in SQL, that cleans the raw data (for deduplication and type-conversion for ex) and builds an analytics-ready aggregated table from the cleaned data.

The demo dataset is a very simple retail-oriented data model (orders, products and users), orders being the fact table.

Our tool, based on Terraform, needs to create the SILVER and GOLD tables, with the correct schemas, ahead of the transformations running, and the Cloud Workflow source definition.

The data transformation files:

The transformations are described in a yaml file, specifying the destination table and the SQL transformation query as a single select.

Building the silver layer, here it’s only a deduplication step for the sake of the demo

workflow_group: demo
destination_table:
  project_id: ${raw_project}
  dataset_id: ${app_name}_ds_3_demo_${multiregion_id}_${project_env}
  table_id: orders
  location: EU

query: >
  SELECT
    *
  FROM `${raw_project}.sldp_demo_retail_analytics_raw_data_eu_${project_env}.orders_v1`
  QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY insertion_time DESC) = 1

Building the gold layer, here an aggregated table of the total amount of sold products per month and consumer.

workflow_group: 3-demo
destination_table:
  project_id: ${raw_project}
  dataset_id: ${app_name}_ds_3_demo_${multiregion_id}_${project_env}
  table_id: total_cost_by_user
  location: EU

description: "Total cost by user and month. Granularity: [user_id, month]"

query: >
  SELECT
    u.email,
    DATE_TRUNC(DATE(o.created_at), MONTH) as month,
    SUM(o.quantity * p.price) as total_amount,
    COUNT(DISTINCT o.id) as total_orders,
    CURRENT_TIMESTAMP() as insertion_time
  FROM `${raw_project}.${app_name}_ds_3_demo_${multiregion_id}_${project_env}.orders` o
  JOIN `${raw_project}.${app_name}_ds_3_demo_${multiregion_id}_${project_env}.users` u
    ON u.id = o.user_id
 JOIN `${raw_project}.${app_name}_ds_3_demo_${multiregion_id}_${project_env}.products` p
    ON p.id = o.product_id
  GROUP BY email, month

And after running the terraform plan command we can see the following output:

Terraform will perform the following actions:

# google_bigquery_table.destination_tables["orders"] will be created
  + resource "google_bigquery_table" "destination_tables" {
      + creation_time       = (known after apply)
      + dataset_id          = "sldp_ds_3_demo_eu_dev"
      + schema              = jsonencode(
            [
              + {
                  + mode        = "NULLABLE"
                  + name        = "id"
                  + type        = "INTEGER"
                },
        ...
          ])
}

# google_bigquery_table.destination_tables["products"] will be created
  + resource "google_bigquery_table" "destination_tables" {
    ...
}

# google_bigquery_table.destination_tables["users"] will be created
  + resource "google_bigquery_table" "destination_tables" {
    ...
}

 # google_bigquery_table.destination_tables["total_cost_by_user"] will be created
  + resource "google_bigquery_table" "destination_tables" {
      + dataset_id          = "sldp_ds_3_demo_eu_dev"
      + description         = "Total cost by user and month. Granularity: [user_id, month]"
      + id                  = (known after apply)
      + schema              = jsonencode(
            [
              + {
                  + description = null
                  + mode        = "NULLABLE"
                  + name        = "email"
                  + policyTags  = {
                      + names = []
                    }
                  + type        = "STRING"
                },
              + {
                  + description = null
                  + mode        = "NULLABLE"
                  + name        = "month"
                  + policyTags  = {
                      + names = []
                    }
                  + type        = "DATE"
                },
        ...
     ])

}

# google_workflows_workflow.data_transfo["3-demo"] will be created
  + resource "google_workflows_workflow" "data_transfo" {
      + create_time      = (known after apply)
      + description      = (known after apply)
      + effective_labels = (known after apply)
      + id               = (known after apply)
      + name             = "wkf_datatransfo_3_demo_euw1_dev"
      + name_prefix      = (known after apply)
      + project          = "sldp-front-dev"
      + region           = "europe-west1"
      + revision_id      = (known after apply)
      + service_account  = "..."
      + source_contents  = jsonencode(
        <Coming from the Cloud Run backend mentioned above, called directly by terraform with the data http provider>
     )
}


Plan: 5 to add, 0 to change, 0 to destroy.

The auto-generated Cloud Workflow DAG:

In the auto-generated Cloud Workflow, we can find 4 steps, one for each table. In our example above:

3 can be done in parallel (the Silver tables) for deduplication and typing. Here we use the topological generation method in our graph.
1 step for the Gold transformation, that needs to wait for the termination of the previous steps, because the Silver tables are referenced by the Gold table.

In this Workflows, each step will do the following:

Compile the query : in all our transformations we can use Jinja templating language. Workflows input parameters can be used in the transformation template. For example, we can use the “incremental” parameter to have a different transformation logic is we want to deal with incremental updates
Run the BigQuery job (compiled query)
Log the status of the job: the workflow publishes an event in a Pub/Sub topic that will dump in realtime in a BigQuery monitoring table, in order to track the status of every step and every workflow.

More features…

The experiment is very feature rich now, here are some of the features we added:

Every transformation can have some SQL scripting pre-operations. The pre-operations are taken into account to process the dependency graph (if you create temporary tables for example) and are run into the same BQ session as the main transformation. BTW, checkout this great article by my friend Matthieu explaining the implementation in Python BigQuery transactions over multiple queries, with sessions.
You can use Python Jinja tempting in every transformation by using some common variables that are available at run time : in the workflow, every transformation step is first “compiled” before being sent to BigQuery.
You can define custom query templates that can be used across all the project: for example a Merge template is available for everyone to use to Implement merge strategy in the final table instead of replace/append.
All templates can implement an incremental alternative (using Jinja conditions). For example, the Default template appends data to the final table if workflow is run in incremental mode or overwrites the data in non-incremental mode.
All the input parameters of your workflows can be used in Jinja templates.
After every workflow step, a real-time structured log information is being published to the monitoring Pub/Sub topic to be immediately streaming into the monitoring BQ table.

Conclusion

It works like a charm !

This architecture is being used for a few months internally at Stack Labs to process our internal data pipelines : there are extremely few pipeline errors at runtime (even less than with Dataform that sometimes lost the connection to the git provider), it’s very cost effective (the DAG generation is completely free thanks to a few hacks), the custom templating system is very flexible for advanced data engineering use cases and we now have proper custom monitoring logs at every transformation step to build real time monitoring dashboards !

So yes, it’s a very geeky approach, and the developer experience is local-first and git-oriented, but if like me you have a Software Engineer background you will feel very comfortable doing Data Engineer/Analyst tasks using this approach. This will probably stay at the experimental phase, but it was fun designing a Serverless, DevOps-oriented Data Transformation and applying Graph theory in the solution. Feel free to ping me for the source code.

Continuous Learning in Kubernetes: My Voyage of Discovery

Hicham Yahiaoui — Mon, 15 Apr 2024 15:51:14 +0000

In the vast expanse of computer science and technology, it's not uncommon to awaken one day and realize that the landscape has shifted dramatically, leaving you feeling somewhat behind the curve.
Such was the case when Kubernetes, the orchestration tool that revolutionized container management, inundated the tech world, seemingly overnight.
Amidst the buzz and fervor surrounding Kubernetes, I found myself in a curious position—I hadn't yet embarked on the journey to understand it.
As the technology became ubiquitous, I recognized that the time had come to embrace this transformative platform and delve into its complexities.
Thus began a new chapter in my technological voyage—a journey into the realm of Kubernetes, where each step forward unveils fresh challenges and endless opportunities for growth.

Kubernetes Kickoff: Assembling My Cluster, One Command at a Time

As I delved into the world of Kubernetes, I opted for what seemed like the scenic route—until reality hit. With determination and a sprinkle of naivety, I plunged into crafting a Kubernetes cluster from scratch. Little did I know, I was in for a wild ride of commands, configurations, and complexities. But fear not! With the guiding light of a course based on the notorious "Kubernetes The Hard Way" GitHub repository, albeit customized for AWS instead of Google Cloud, I embarked on my journey to build my digital fortress, one step at a time.

Introducing Our Cluster Blueprint: A Humble Beginning

Voila! The Big Picture: Check Out the Cluster Diagram! Now, I'll admit, it's a bit like staring at a complex puzzle, but fear not, I am determined to piece it together!

Navigating the Kubernetes Landscape: A Condensed Journey

Embarking on the Kubernetes setup journey felt like venturing into uncharted territory. From laying down prerequisites to fine-tuning configurations, each step presented its own challenges and insights. As I worked on setting up the Jumpbox, provisioning compute resources, and generating TLS certificates, I frequently consulted the official Kubernetes documentation for guidance. With each tool installed and resource provisioned, I delved deeper into Kubernetes intricacies, steadily building towards a functional cluster. From bootstrapping etcd to configuring kubectl for remote access, each action taught me something new, propelling me towards Kubernetes mastery. As the final smoke test cleared, a sense of accomplishment and excitement filled me, ready to explore the possibilities of my newly created Kubernetes cluster.
Armed with the foundational knowledge gained from the setup journey, I now stand poised to embark on the next phase of my Kubernetes education

Embarking on my Kubernetes Mastery Journey

Embarking on the path to Kubernetes expertise requires a structured approach, and the "Kubernetes Deep Dive" course on A Cloud Guru serves as your trusty map. Let's take a quick tour of the course chapters to give you a glimpse of what lies ahead without bogging you down with details:

Chapter 1: Course Introduction

I received a warm welcome as I ventured into Chapter 1. Here, I was introduced to the course's objectives and got familiar with the prerequisites. The demo lessons were highlighted as key components enhancing my learning journey, setting the stage for the chapters to come.

Chapter 2: Kubernetes Big Picture

In Chapter 2, I delved into the Kubernetes ecosystem, where the big picture started to take shape. Exploring the Kubernetes API, core objects, and receiving tips on setting up my own cluster laid a solid foundation for what was to follow.

Chapter 3: Application Architecture

Transitioning into Chapter 3, I shifted my focus to application architecture within Kubernetes. Here, I not only explored the theoretical frameworks but also gained hands-on experience with a sample app, bridging the gap between theory and practice.

Chapter 4: Kubernetes Networking

The spotlight then turned to networking in Chapter 4. Unraveling the mysteries of Kubernetes networking essentials, from understanding common requirements to practical demonstrations, provided me with a crucial foundation in cluster management.

Chapter 5: Kubernetes Storage

Opening the door to storage solutions in Chapter 5, I discovered the Container Storage Interface, persistent volumes, and storage classes. Through a blend of theory and hands-on exercises, these concepts became tangible building blocks in my journey.

Chapter 6: From Code to Kubernetes

In Chapter 6, I learned to seamlessly deploy applications into Kubernetes environments. Following along with demos, I witnessed the transition from code to cluster, gaining practical insights into the deployment process.

Chapter 7: Kubernetes Deployments

As Kubernetes deployments took center stage in Chapter 7, I mastered the theory and practice of managing application lifecycles within Kubernetes clusters. This segment equipped me with the skills needed to ensure smooth operations from deployment to scaling.

Chapter 8: Scaling Applications Automatically

In Chapter 8, I was introduced to the art of automatic application scaling. Exploring strategies for horizontal to cluster autoscaling, I learned to adapt applications to varying workloads with ease.

Chapter 9: RBAC and Admission Control

Finally, Chapter 9 delved into Kubernetes security features, empowering me to secure my deployments effectively. Understanding role-based access control (RBAC) and admission control mechanisms fortified my Kubernetes deployments against potential threats.

With this roadmap in hand, I embarked on my Kubernetes journey with confidence. Each chapter of the "Kubernetes Deep Dive" course not only expanded my knowledge but also propelled me forward on my quest for Kubernetes mastery.

Putting Knowledge into Practice: Following the EKS Immersion Day Workshop

As I sought to apply my newly acquired Kubernetes knowledge in a practical setting, I turned to the cloud for real-world deployment experiences. One invaluable resource that caught my eye was the EKS Immersion Day workshop. This workshop not only provided a platform to apply my Kubernetes skills but also offered insights into AWS's unique approach to building clusters and managing containerized applications.

This served as a bridge between theory and practice, allowing me to apply my knowledge in a cloud environment. What made this experience particularly enriching was AWS's distinctive approach to Kubernetes deployment.

Throughout the workshop, I encountered AWS's nuances in cluster management, resource provisioning, and scalability. From leveraging AWS services like EKS (Elastic Kubernetes Service) to understanding how to optimize performance and cost efficiency, every step offered valuable insights into cloud-native practices.

Moreover, the hands-on exercises and guided tutorials provided by the workshop enabled me to grasp AWS's methodologies effectively. I learned to navigate AWS's console, deploy applications using EKS, and troubleshoot common issues encountered in a cloud-based Kubernetes environment.

Overall, the EKS Immersion Day workshop not only allowed me to apply my Kubernetes knowledge but also broadened my understanding of cloud-native architectures. It underscored the importance of adapting Kubernetes principles to different cloud providers' ecosystems, setting the stage for continued exploration and growth in my Kubernetes journey.

Closing Thoughts on My Kubernetes Journey

Reflecting on my journey through Kubernetes, I'm struck by the growth and learning that have accompanied each step. From the initial setup of my cluster to the immersive experiences of workshops like the EKS Immersion Day, I've gained invaluable insights into container orchestration and cloud-native architectures.

Looking ahead, I'm filled with excitement for the opportunities that lie on the horizon. While this milestone marks a significant achievement, it also serves as a reminder that the journey is far from over. With a wealth of knowledge and experiences at my disposal, I'm eager to continue exploring new technologies and pushing the boundaries of what's possible in the realm of Kubernetes.

In closing, I'm grateful for the journey thus far and the lessons it has taught me. As I embark on the next phase of my Kubernetes journey, I do so with a sense of anticipation and a commitment to continued growth and exploration.

AWS Summit Paris 2024

Λ\: Laurent Noireterre — Fri, 12 Apr 2024 10:21:24 +0000

Article co-écrit avec Hicham Yahiaoui (Cloud Architect @Stack-Labs) et Yoann Metenier (Cloud Architect @Stack-Labs)

Keynote

La GenAI c’est génIAl

L'AWS Summit Paris 2024 s’est déroulée au palais des congrès. Le lieu était plus que nécessaire au vu du nombre de personnes présentes à cet évènement. Dès notre arrivée, et après avoir récupéré nos cartes d’accès, nous nous sommes installés dans le grand amphithéâtre afin d’assister à la Keynote d’ouverture.

Julien Groues (General Manager - Europe South, AWS) a effectué quelques présentations sur AWS en début de keynote pour ensuite laisser la main à Mai-Lan Tomsen-Bukovec (VP of Technology, AWS) qui est venu pour discuter des nouveautés 2024 AWS : la GenAI.

Tout au long de cette keynote de 1h30 plusieurs intervenants sont montés sur scène afin de présenter leurs besoins et utilisations de la GenAI sur AWS. Cependant, une annonce surprise a été effectuée en début de session : AWS x Mistal AI.
En effet le premier intervenant sur scène n’est autre que Arthur Mensch CEO de Mistral AI. Il est venu pour confirmer son partenariat avec AWS permettant aux utilisateurs de disposer de Mistral AI dans AWS Bedrock pour la région Europe ! Les versions disponibles sont : Mistral Large, Mistral 7B et Mistral 8x7B.
A la suite de cette annonce forte excitante, les intervenants suivants sont venu présenter leurs utilisation du cloud AWS pour dynamiser leur activité et enrichir l'expérience de leurs clients:

Fabien Mangeant (Chief Data and AI Officer, Air Liquide)
Thomas Wolf (Co-Founder, Hugging Face)
Raphaëlle Deflesselle (CTO, Groupe TF1)
Tom Brown (Co-Founder, Anthropic)

A la fin de la keynote, nous avons poursuivi notre périple AWS en participant à quelques conférences parmi les 175 disponibles et en discutant sur les stands des partenaires afin de découvrir des projets et utilisations de diverses solutions sur AWS. Nous avons choisi de vous présenter dans la suite de cet article 3 conférences auxquelles nous avons assisté.

Multi-régions Zéro latence avec Kubernetes, Couchbase & Qovery

Laurent Doguin (Developer Advocate Couchbase) et Romaric Philogène (CEO Qovery) nous ont fait le plaisir d’effectuer une présentation de l’intégration entre Couchbase et Qovery permettant de réduire et stabiliser une connexion BDD – Kubernetes dans un environnement multi-région sur AWS.

Un peu de contexte

Le temps d’attente de réponse d’une application peut provoquer une lassitude des utilisateurs d’autant plus à notre époque où nous sommes habitués à des services qui répondent rapidement. Nos interlocuteurs nous présentent les résultats d’une étude AWS qui dit :

100 ms de latence sur la page amazon.com = 1% de baisse des ventes
De manière générale :
- 2 secondes de chargement pour un site internet = 9% des utilisateurs abandonneront la navigation,
- 5 secondes de chargement pour un site internet = 38% des utilisateurs,
- 3 secondes de chargement via smartphone = 53% des utilisateurs

Le problème posé

Dans une architecture multi-région comment puis-je faire pour disposer d’un temps de lecture/écriture acceptable pour n’importe quel client indépendamment de sa localisation géographique ?
Nous pouvons représenter ce problème avec le schéma suivant :

Nous pouvons voir que dans cette situation les client aux Etats-Unis et en Asie dispose d’un temps de lecture et écriture nettement supérieur à ceux en Europe. Comme expliqué dans notre contexte, ce délai supplémentaire peut provoquer de la frustration et donc amener à une perte d’utilisateurs sur ces régions.

A la suite de cette mise en contexte, Laurent et Romaric ont proposé une solution de base souvent utilisée, appelée « active/passive ». Cette méthode consiste à déployer plusieurs instances d’application dans les différentes régions et d’utiliser des read réplicas pour les base de données (schéma ci-dessous).

Via cette solution nous constatons une nette amélioration concernant la lecture du contenu en base. Si la lecture représente la plus grande partie des actions réalisées par les clients, alors cette solution est viable. Mais quid de la situation où l'écriture est aussi un aspect important pour les clients ? Dans ce cas la solution basique devient non valide car nous disposons toujours d’un temps d’écriture très élevé pour les deux régions éloignées.

Plusieurs solutions se présentent alors :

Retravailler le modèle de données pour séparer les régions entre-elles et que chacune repose sur sa propre base de données (beaucoup de travail à faire et peut-être pas possible en fonction du modèle de données)
Utiliser un schéma plus horizontale avec la possibilité d’écrire/lire les données de chaque base de données correspondant à sa région et gérer un système de réplication de données (complexe à mettre en œuvre et gestion des conflits sur les données à gérer soi-même)
Utiliser la solution « active/active » proposé par Couchbase et Qovery afin de permettre à la fois de disposer de bases de données par région et synchronisées entre elles de manière efficace via Couchbase, mais également de disposer du gestionnaire de déploiement serverless des ressources et plateformes centralisé, Qovery, connecté aux instances Couchbase

Les présentateurs ont conclu leur conférence par la présentation de la solution (vous l’aurez deviné) N°3 : l’utilisation de Couchbase (Capella) et Qovery (schéma ci-dessous). Dans cette dernière, les utilisateurs de n’importe quelle région disposent tous du même temps de lecture et écriture sur l’application tout en bénéficiant d’une synchronisation des données avec latence faible complètement gérée par Couchbase.
A noter également que la solution proposée par Couchbase permet de disposer des données de manière active/active tout en gérant l’aspect conformité de ces dernières (via l’utilisation de filtres) vis à vis des lois en vigueurs dans les régions et pays de déploiements.

En conclusion

Couchbase x Qovery est un couple prometteur. En effet, la solution exige un coût supplémentaire par rapport à une solution gérée par le client lui-même. Cependant, aujourd’hui de nombreux clients souhaitent réduire l’aspect maintenance et opérabilité de leurs infrastructures sur le Cloud.
Avec des interfaces claires et faciles d’utilisation (qui changent grandement de l’interface console AWS) la solution proposée peut être une alternative intéressante pour des clients avec un besoin spécifique et rapide avec une infrastructure simple.

Vous pouvez retrouver une démo ici : https://www.youtube.com/watch?v=nza3ldlPI7w

Optimisez les coûts et la mise à l'échelle d'EKS avec Karpenter

Imane Zeroual (AWS), Sebastien Allamand (AWS) et Martinho Moreira (Voodoo) nous présente le projet Karpenter, sa mise en place dans un cluster EKS et un retour d'expérience sur les bénéfices apportés par cette solution.

Maximiser l'Efficacité des Clusters Kubernetes avec Karpenter

Kubernetes s'est imposé comme l'une des solutions les plus populaires pour la gestion des applications conteneurisées à grande échelle. Cependant, malgré ses avantages indéniables, Kubernetes peut présenter des défis en matière de gestion des ressources et d'optimisation des clusters. C'est là que Karpenter entre en jeu.

Qu'est-ce que Karpenter ?

Karpenter est un projet open-source développé par AWS qui vise à optimiser les clusters Kubernetes en automatisant le dimensionnement des nœuds. Son objectif principal est de garantir que les ressources sont utilisées de manière efficace tout en maintenant les performances et la disponibilité des applications.

Comment fonctionne Karpenter ?

Karpenter s’installe dans le cluster Kubernetes en tant qu’opérateur et va remplacer le mécanisme d’autoscaling d’AWS pour provisionner les nœuds.

Karpenter analyse les demandes de ressources des pods et les regroupe en fonction de leurs caractéristiques. En utilisant ces informations, il peut déterminer la meilleure façon de répartir les charges de travail sur les nœuds disponibles, et ainsi réduire le nombre de nœuds nécessaires.

Par exemple, il peut regrouper plusieurs pods légers sur un seul nœud pour libérer des ressources sur d'autres nœuds et ainsi les supprimer du cluster.

Karpenter peut également s'intégrer avec des services cloud tels qu'AWS Spot Instances ou des instances de type Graviton, ce qui permet d'optimiser les coûts tout en maintenant les performances des applications.

Afin de paramétrer et utiliser au mieux Karpenter, Sébastien Allamand nous présente ensuite quelques outils et méthodes tels que les détections de Drift du dataplane ou l’analyse approfondie de la perturbation des nœuds.

Retour d'expérience

Pour finir cette session, Martinho Moreira de chez Voodoo nous fait un retour d'expérience sur leur mise en place de Karpenter, l’architecture et les points de vigilance qu’ils en ont retiré.

Les slides parlent d’eux même :

En conclusion

Cette conférence fut très intéressante pour une découverte de cet outil de plus en plus utilisé dans le cadre d’optimisations FinOps.
La présentation a été accompagnée d’une démo qui nous a permis de rendre concret certains use cases, et de constater en live le fonctionnement de l’outil et les optimisations réalisées par Karpenter.
La 2ème partie de la conférence a bien complété ce talk avec un retour d'expérience concret de la part de Voodoo. Ils ont ainsi pu nous partager factuellement les retombées en termes de bénéfice de l’outil, les étapes de migration et les pièges à éviter lors de la mise en place de Karpenter.

Accelerate Gen AI with Amazon Bedrock and Snowflake:

Nadir Djadi de Snowflake a présenté une approche accélérée de l'intelligence artificielle générative en utilisant Amazon Bedrock et Snowflake.
Après une brève introduction sur le rôle de Snowflake, il a présenté une vue d'ensemble de la plateforme en mettant en avant trois points clés : L'IA accessible au quotidien sans expertise, le déploiement rapide d'applications avec personnalisation, la sécurité et la gouvernance des données garanties.

Ensuite, nous avons exploré certaines fonctionnalités offertes par Snowflake avant de nous concentrer sur la partie Amazon Bedrock. Cette dernière offre une intégration transparente des modèles fondamentaux (FMs) de divers fournisseurs pour des applications d'intelligence artificielle générative évolutive, avec des options de personnalisation privées.

Nous avons ensuite passé en revue les FM disponibles sur Amazon Bedrock, en notant que Mistral n'a pas été inclus dans la liste puisqu'il a été annoncé le jour même.

Enfin, il a conclu en montrant comment Snowflake peut interagir avec Amazon Bedrock via Snowpark External Access, qui repose sur des identifiants temporaires de AWS Security Token Service (STS) pour authentifier et accéder aux endpoint des modèles Amazon Bedrock.

En conclusion, je trouve la solution présentée par Nadir Djadi très intéressante, surtout pour son aspect permettant une utilisation rapide de l'IA sans nécessiter une expertise préalable. Cela me donne vraiment envie d'expérimenter Amazon Bedrock dans mes projets futurs.

Alors l’AWS Summit Paris c’est génIAl?

Cette année encore AWS nous gratifie d’un show à la taille de son investissement en France. En effet, l’acteur n°1 du cloud public a réussi à nous faire sentir à l’étroit sur les 3 étages du Palais des congrès de Paris. Nous avons pu profiter un maximum, même si pour certaines conférences il était difficile d’avoir une place.

Cette année s’annonce très intéressante sur le secteur de la GenAI. AWS compte bien rattraper son retard sur les aspects data et IA, en consacrant une attention particulière dans l’accompagnement de ses partenaires et clients voulant explorer ces solutions.

Nous resterons bien sûr à l’écoute des nouveautés qu’AWS pourraient annoncer dans les mois à venir, et nous n'hésiterons pas à vous les partager sur notre blog.

How to make Cloud Run talk to Cloud Run - The private way

Kevin — Tue, 12 Mar 2024 13:30:56 +0000

Cloud Run is no longer to be presented among the GCP container services. It is generally an efficient way to deploy web API applications without the overwhelming need of deploying and managing a Google Kubernetes Engine (GKE) cluster.

When it comes to accessing a Cloud Run instance it is also really easily configurable to be accessed from the internet. But if you are in a production environment, or you just don't need your instance to be accessed from the outside, there are some private networking solutions.

Like any other services, Cloud Run offers some out of the box features but some use cases may still require multiple options or services to be combined together.

One of our clients that uses Cloud Run for internal purposes only, wanted one of his Cloud Run instances to access another one, still without going over the internet but using private internal paths.

In this blog post, I will go over the Cloud Run networking options and details about how we finally did make a source Cloud Run service access a destination Cloud Run service using a private network.

Note: Cloud Run can be accessed with authenticated or unauthenticated requests, this aspect will not be developed in this article.

A bit of Cloud Run mechanics

First of all, we could ask ourselves: why would it be tricky to make two Cloud Run instances communicate with each other?
Whereas it is child's play to achieve it with two Compute Engine VM instances!

Well, the main difference is that by default, Cloud Run is not a resource that is "attached" to a VPC the way a GCE instance is.

You may know that every Cloud Run service deployment comes with a (ugly?) default URL that looks something like: https://hello-g6bc2cfcrq-uc.a.run.app. Which is the only endpoint that is given by GCP when we create a service.

As mentioned, one available option is to configure the instance to be accessible from the internet and use that URL from our source. But it is not what we want.

At this point our puzzle looks like this :

So, how is it possible to make a destination Cloud Run service to be accessed from private connections ? And a source Cloud Run service to access it ?

Let's find out.

Cloud Run Ingress control

On one hand we want to make our destination service accessible only from the internal network.

Two options are available when it comes to configure a Cloud Run service inbound traffic:

Allow ALL traffic: which means our service is accessible from the internet.
Restrict the access to "internal" requests only, with the option to also allow requests from GCP external Load Balancers.

In our case, the internal option is the one that is used by our client to satisfy his requirements.

Now we know that we only allow "internal" access to our destination service, we need to find a way for our source service to send requests through a VPC to be considered as internal ones.

Cloud Run egress options

The idea is to direct our source service traffic to the VPC, and for that Google has implemented Cloud Run "networking options":

Outbound options
1. Serverless VPC Access Connector: backstage this method creates a VM which is used to proxy requests from Cloud Run and forward them to the VPC.

2. Direct Access: this is the new option available since a few months in Cloud Run and still in "Preview". Direct Access avoids the creation of additional resources (and so the associated costs), and is supposed to have more throughput, and lower latency.

Be aware that when setting up any of those, you need to attach it to a VPC subnet, and both will consume private IP addresses.

Additionally we have to choose between two routing options that will allow us to route our source service traffic in different ways:

Route only requests to private IPs to the VPC
Route all traffic to the VPC

Choosing either option will depend on some more parameters that we will see a bit later.

That starts to make quite a few options combinations, but is that enough to access our destination service ?
Not yet...

Access Cloud Run endpoint

We saw that by default, to access a Cloud Run service, the only endpoint is its (ugly!) URL (*.run.app).

So we need either to be able to reach this URL from our VPC, or potentially to create a different endpoint.

If using the default URL is ok for you, the first option you have is Private Google Access (PGA).

To make it simple Private Google Access is a one box option to check on your subnet configuration, and it enables resources with solely a private IP address to access GCP public APIs by staying inside the GCP's network.

Source: https://cloud.google.com/vpc/docs/private-google-access#example

Magical isn't it ? Yes, but there are counterparts.

As you use the URL of your destination service, which is by default resolved as a public URL, you must configure the routing options of your source service to send "ALL TRAFFIC" to your VPC. That could be an issue if you want your Cloud Run instance to access the internet and configured your it to use Direct VPC. Indeed, one Direct VPC limitation is that it is not compatible with Cloud NAT, which is the only way to give private instances a way to reach the internet. If your source service needs an internet access and you enable PGA, you have to use a Serverless VPC Access connector instead.
The IP address logged for the incoming request will be 0.0.0.0/32, so it could be difficult to do specific network tracing.
You still use the ugly default URL to access your Cloud Run service.

What about the other options ?
Even if I will not go into the details, just know that if you have specific needs like accessing Cloud Run without directing all traffic to the VPC, or using an IP address or a custom DNS name, it is possible by:

Using an internal Load Balancer, with the Cloud Run service as a backend
Using a Private Service Connect (PSC) endpoint with an associated Cloud DNS entry.
Configure DNS to use the public URL as an internal endpoint so that it is routed to the VPC.

If you want me to detail those other options in a dedicated article, let me know in the comments section.

Our final configuration

Putting all of those pieces together lead us with the following final solution for our client use case:

We used PGA and routed all traffic to the VPC.
As the source Cloud Run instance needed an internet access, we used a VPC Access connector coupled with a NAT gateway.

We finally came to this final configuration:

I hope you enjoyed this article and that helped you to understand a bit more about Cloud Run private networking.

Thanks for reading!

I’m Kevin, Cloud architect at Stack Labs.
If you want to join an enthusiast Infra team, feel free to contact us.

Déployons des canaris sur Google Kubernetes Engine

Antoine Aubé — Tue, 13 Feb 2024 12:58:46 +0000

Dans le cadre de mon emploi chez Stack Labs, j'interviens auprès d'une entreprise qui découvre la conteneurisation et qui veut développer son nouveau système sur Google Cloud Platform. L'un des sujets qui leur importe est la montée de version : comment procéder ?
Parmi leurs exigences, ils souhaitaient minimiser la durée d’interruption du service pendant la montée de version, ainsi que l'interrompre en cas de problème.
Notre proposition : le déploiement en canari. Dans ce billet, je vous présente (très) brièvement de quoi il s'agit, ainsi que la démonstration que j'ai préparée avec un collègue pour montrer à nos clients comment ça fonctionne.

Déploiement en canari ?

Le déploiement en canari consiste, pour un serveur Web, à déployer la nouvelle version du serveur (le « Canari ») en parallèle de l'ancienne (la « version primaire »), et de diriger une partie du trafic sur cette nouvelle version. Si le Canari est jugé conforme aux attentes pour les requêtes traitées, alors la portion du trafic qui lui est assignée augmente progressivement, jusqu'à arriver à un seuil critique : dès lors, la version primaire est reconfigurée pour délivrer la nouvelle version, et tout le trafic lui est affecté ; quant au Canari, les ressources qui lui étaient allouées (p. ex. conteneurs) sont libérées.

Ci-suivent quelques liens pour des explications plus approfondies (et illustrées !) :

Après avoir lu ces pages Web, des questions apparaissent. En tout cas, je m'en suis posé plusieurs. Dans les sous-sections suivantes, je vous les présente, et vous explique mes réponses actuelles.

Le Canari est conforme... ?

Déporter le trafic vers le Canari a pour objectif de vérifier s'il est « conforme » ; certes, mais conforme à quoi ?

Cela doit être défini par l'équipe d'exploitation.

Un critère apparemment fréquent est le code de statut en réponse aux requêtes : par exemple, si un large pourcentage des réponses portent un code HTTP 2xx, alors le déploiement peut se poursuivre, et il doit s'interrompre si les codes HTTP 5xx sont majoritaires. Un autre critère est la latence de réponse : si elle est trop élevée, alors le déploiement doit s'interrompre.
Ces critères sont intégrés nativement à des outils d'automatisation des déploiements en canari (p. ex. Flagger), mais cela peut ne pas suffire : des critères orientés métier peuvent être plus pertinents pour valider la conformité du Canari.
Enfin, notons que ce type de déploiement n'est pas nécessairement automatisé. En effet, les opérateurs peuvent à chaque étape sélectionner une population de testeurs pour interagir avec le Canari, et décider quand passer à la prochaine étape (p. ex. après avoir collecté les avis de la population de testeurs, ou mesuré diverses métriques avec des outils de supervision).

Déploiement d'un logiciel... ou de tout le système ?

Les ressources trouvables en ligne ne sont pas claires quant à ce qu'englobe le déploiement en canari. En effet, si les auteurs parlent du déploiement d'un logiciel, leurs illustrations présentent bien le routage entre deux systèmes indépendants : l'un pour la version primaire, l'autre pour le Canari. Considérant les grandes difficultés techniques qui viennent avec la première option (p. ex. compatibilités entre modules, routage entre composants du système), il me semble plus raisonnable que ce soit la seconde option qui soit réellement mise en œuvre dans l'industrie.

Cependant, cela ne vient pas sans défi.

En effet, le déploiement en canari ne s'étend pas toujours à l'ensemble du système. Je prend l'exemple de l'une de mes expériences professionnelles passées : le système est déployé dans un environnement cloud qui compte un cluster Kubernetes et un SGBD déployé par un PaaS. Dans ce contexte, le déploiement en canari ne concernait que les conteneurs déployés dans Kubernetes : le contenu de la base de données était utilisé concurremment par la version primaire et le Canari. Par conséquent, il était important lorsque le Canari modifiait le schéma de la base de données que les deux versions soient compatibles avec cette modification, au risque de perturber le fonctionnement du système lors du déploiement. Ce point d'attention est soulevé dans plusieurs des liens mentionnés plus haut, tel que l'article de Danilo Sato. C'est un exemple de contraintes sur le développement imposé par une pratique d'exploitation du système.

D'autres préoccupations peuvent également survenir selon la nature des composants du système. Par exemple, l'explication d'Encora indique qu'il faut être vigilant si certains composants possèdent un état (stateful) : dès qu'un utilisateur a été dirigé sur l'une des deux versions, il faut qu'il y soit toujours dirigé au cours du déploiement ; et il peut être nécessaire de conserver l'ancienne version primaire quelque temps après la fin du déploiement le temps que les sessions soient fermées.

Démonstration

Afin de présenter le fonctionnement d'un déploiement en canari à mon client, j'ai préparé une démonstration avec un collègue. Vous pouvez retrouver les fichiers de configuration et les instructions sur le dépôt dans le groupe GitLab de Stack Labs.
L’image ci-dessous (très légèrement adaptée d’une image de la documentation de Flagger) illustre la démonstration.

Nous disposons d'un serveur Web qui affiche une unique page avec un dessin de chameau. Nous le déployons dans Google Kubernetes Engine (GKE). En amont du serveur Web, nous déployons toujours dans GKE un Ingress Controller NGINX : il effectue le routage du trafic vers l'instance primaire ou Canari du serveur Web lors d'un déploiement.

Nous voulons mettre à jour le serveur Web. En effet, alors que le fond de la page est beige (version primaire), nous le voulons à présent vert (Canari).

Pour parvenir à déployer la nouvelle version sans interruption du service, nous utilisons le logiciel Flagger qui automatise le processus de déploiement. Pour valider la conformité du Canari, nous nous concentrons sur les codes de statut HTTP, mais Flagger intègre d'autres critères nativement, et permet également de définir des critères personnalisés, grâce à des requêtes sur Prometheus.

Dès le déploiement lancé, la version avec le fond beige cohabite avec celle au fond vert, et une portion croissante du trafic est dirigée vers cette dernière, comme expliqué précédemment.

Les étapes de la démonstration sont détaillées sur le dépôt Git, je vous invite à les parcourir et à réaliser vous-même la démonstration !

Conclusion

Dans ce billet, je vous ai présenté une stratégie de déploiement en continu des logiciels : le déploiement en canari ; et je vous ai proposé quelques instructions pour le pratiquer par vous-même.

Le déploiement en canari est une solution technique parmi d'autres pour déployer un système en continu. Je vous suggère ci-dessous trois lectures pour approfondir le sujet du déploiement en continu. D'abord, le mémoire de Master de Nichil Strasser, qui évalue les outils de déploiement en canari sur le marché. Puis, deux recommandations qui ouvrent les perspectives sur d'autres techniques de déploiement : un dépôt Git d'exemples sur Kubernetes, et un article de Mahdi Konzali qui les vulgarise. Enfin, nous pouvons élargir l’exigence de faible temps d’interruption de service de notre client à la notion de haute disponibilité. Un article de Endo et coll., publié en 2016, balaye plusieurs définitions de la haute disponibilité ainsi que l’état de l’art des moyens de sa mise en œuvre dans un contexte cloud.

Merci d’avoir lu mon article ! Je suis Antoine, ingénieur cloud & doctorant chez Stack Labs. Si vous voulez en savoir plus sur Stack Labs ou rejoindre une équipe de passionnés de tech, n’hésitez pas à nous contacter ici.

Crédits à Julia Craice sur Unsplash pour l’image de couverture.

Migration Rancher de Docker vers RKE2

Julien RATON — Thu, 01 Feb 2024 14:04:27 +0000

Disclaimer: le but de cet article n’est pas d’apporter une solution parfaite.Il est basé sur mon expérience pour répondre à un besoin client avec ses contraintes, mes connaissances et ma vision de la solution pour y répondre.

Qu’est-ce que Rancher ? Rancher est un outil qui permet de manager différents clusters Kubernetes, tout en fournissant des outils pour gérer des workflows conteneurisés.

Représentation de 2 architectures possibles pour Rancher (Schéma issue de la documentation du site Rancher)

Le client chez qui je suis intervenu pour faire cette migration avait un Rancher qui tournait dans un container. Ils avaient comme besoin de rendre l’outil plus résilient et robuste. Effectivement Rancher était l’outil permettant de générer les accès aux clusters pour toute leur population de développeur. Cet outil était utilisé quotidiennement par plusieurs personnes pour déployer des environnements dans des clusters Kubernetes. La migration de Rancher vers un cluster Kubernetes (RKE2 ici) s’est imposée d'elle-même à la vue des différents enjeux et contraintes de ce client.

Certains systèmes ou outils ont parfois besoin d’être migrés. Cependant tous n’ont pas été développés ou même pensés pour répondre à un tel besoin. C’est le cas de Rancher qui offre un outil de dump de ses données mais n’apporte pas de réelle solution à sa migration.
Effectivement on peut trouver un outil sur le site de Rancher qui permet de faire une migration. Seulement cet outil apporte des contraintes qui n’étaient pas contournables lors de mon expérience. La première (et pas des moindres), le hostname doit rester le même. Cela peut paraître assez anodin, mais si on souhaite faire évoluer ce dernier, pour des contraintes réseaux, ou simplement que l’on ai envie de changer de hostname, l’outil fourni par Rancher n’est pas envisageable. La seconde contrainte était le fait de conserver l’environnement de départ. La migration peut s’effectuer de Docker vers Docker, de Kubernetes vers Kubernetes, mais pas de Docker vers Kubernetes ou inversement.

Heureusement, le rancher propose un outil pour extraire les données liées à un cluster et également pour les importer. Cet outil est une CLI qui permet de contacter l’API de Rancher et d'interagir avec.
Dans la suite de cet article je vous présente la façon dont j’ai pensé cette migration en ayant le moins d’indisponibilité possible pour les utilisateurs. Je pense que ce processus est fortement corrélé aux contraintes, au contexte et au besoin du projet sur lequel je suis intervenu. A vous de vous approprier la méthode plutôt que le processus lui-même.

L’objectif était de créer le moins d’indisponibilité possible de la plateforme Rancher pour les utilisateurs. Il était donc nécessaire de bien préparer en amont de la bascule pour que cette dernière soit la plus rapide possible. La préparation commençait donc par extraire les ACLs (utilisateurs, rôles associés par projets et namespace). Pour cette partie là j’ai donc écrit un script Bash qui s’appuyait sur la CLI fournie par Rancher. Dans une boucle, le script récupère l’ensemble des projets, et pour chacun des projets, le(s) namespace(s) associé(s), avec les utilisateurs associés à leur(s) rôle(s). Ces informations, une fois récupérées, sont inscrites dans un fichier texte.

#!/bin/bash


echo "clusters list"
clusters=$(rancher clusters ls | grep active | grep -v local | awk '{ print $1 }')
echo $clusters
echo ""


for cluster in $clusters
do
 cluster_name=$(rancher clusters ls | grep $cluster | awk '{ print $3 }')
 echo "project of current cluster - $cluster_name"
 projects=$(: | rancher context switch | grep -v local | grep -v 'Select a Project' | grep $cluster | awk '{ print $3 }')
 echo "cluster:$cluster_name" > $cluster_name.txt
 rancher clusters list-members --cluster-id $cluster | tail -n +2 | grep -v "Default Admin" | awk '{print $2 ":" $3}' >> $cluster_name.txt


 for project in $projects
 do
   rancher context switch $project
   project_name=$(: | rancher context switch | grep $project | awk '{ print $4 }')
   echo "members of current project - $project_name"
   echo "project:$project_name" >> $cluster_name.txt
   rancher namespaces ls -q | sed -E 's/(.*)/namespace:\1/' >> $cluster_name.txt
   rancher projects list-members --project-id $project | awk '{ print $2 ":" $3 }' | tail -n +2 >> $cluster_name.txt
 done
 echo ""
done

Exemple de code d’export en bash

La préparation à ce stade est terminée. L’étape suivante cause de l’indisponibilité, puisqu’il s’agit de la migration des agents. Avant de commencer, il faut créer le cluster dans le nouveau Rancher. Il suffit ensuite de récupérer la commande “kubectl apply” pour installer les nouveaux agents sur le cluster (et la garder de côté, la commande). Connectez-vous à votre cluster, et supprimez les anciens agents (vous pouvez supprimer le namespace, il sera recréé). Une fois supprimés, jouez la commande “kubectl apply” récupérée sur le nouveau Rancher.

La bascule est maintenant terminée, il suffit donc de remapper l’ensemble des ACLs, que l’on a conservées dans un fichier texte avant la bascule. Pour ce faire, j’ai écrit un second script bash (qui s’appuie aussi sur la CLI fourni par Rancher). Dans ce dernier, il y a une boucle qui parcourt notre fichier texte pour récupérer les différentes informations et, à l’aide de la CLI Rancher, les injecte directement dans le nouveau Rancher.

#!/bin/bash


imported_file=$1
echo "file $imported_file"
cluster_acls=$(cat $imported_file)
cluster=""
project=""


for cluster_acl in $cluster_acls
do
 echo $cluster_acl
 title=$(echo $cluster_acl | cut -d':' -f1)
 role=$(echo $cluster_acl | cut -d':' -f2)
 if [ "$title" = "cluster" ]
 then
   cluster=$role
   cluster_id=$(rancher clusters ls | grep $cluster | awk '{ print $1 }')
   echo "you are working on $cluster cluster with id $cluster_id"
 elif [ "$title" = "project" ]
 then
   project=$role
   project_id=$(: | rancher context switch | grep $cluster | grep $project | awk '{ print $3 }' | cut -d':' -f2)
   if [ "$project_id" = "" ]
   then
     rancher projects create --cluster $cluster_id $project
     project_id=$(: | rancher context switch | grep $cluster | grep $project | awk '{ print $3 }' | cut -d':' -f2)
   fi


   echo ""
   rancher context switch $cluster_id:$project_id
   echo "you are working on $project project with id $project_id"
 elif [ "$title" = "namespace" ]
 then
   namespace=$role
   rancher namespace move $namespace $cluster_id:$project_id
 else
   user=$title


   if [ "$project" = "" ]
   then
     current_user=$(rancher clusters list-members --cluster-id $cluster_id | grep $user | grep $role)


     if [ "$current_user" = "" ]
     then
       rancher clusters add-member-role --cluster-id $cluster_id $title $role
       echo "user $user added to the cluster $cluster with id $cluster_id with role $role"
     else
       echo "user $user with role $role already exists on current cluster $cluster"
     fi
   else
     current_user=$(rancher projects list-members | grep $user | grep $role)


     if [ "$current_user" = "" ]
     then
       rancher projects add-member-role $title $role
       echo "user $user added to the project $project with id $project_id with role $role"
     else
       echo "user $user with role $role already exists on current project $project"
     fi
   fi
 fi
done

Exemple de code d’import en bash

Il ne reste plus qu’à communiquer le nouveau DNS aux utilisateurs pour qu’ils récupèrent le nouveau contexte, le mettent en place sur leur espace de travail, et la migration est terminée !

En conclusion: la solution Rancher apporte une solution simple pour manager ses clusters Kubernetes, mais ne semble pas être le moyen le plus efficace et le plus maintenable dans le temps. Cependant certaines facilités et outils qu’elle apporte peuvent faciliter certaines tâches (comme la délégation de droits sur les clusters par exemple).

Concernant la migration, si vous vous retrouvez avec le même besoin et les mêmes contraintes, la solution est simple à mettre en place (quelques scripts bash, et de la configuration Rancher) et avec une rupture de service relativement courte.

Merci d’avoir lu mon article! Je suis Julien, cloud engineer chez Stack Labs.
Si vous voulez en savoir plus sur Stack Labs ou rejoindre une équipe de passionnés de tech, n’hésitez pas à nous contacter ici.