mkdir demo-custom-provider && cd demo-custom-provider
git clone git@github.com:ekit3/terraform-custom-provider.git

Dans un premier temps, placez-vous dans le dossier, « custom-provider/resources/terraform-provider-courses », il s’agit du boilerplate de départ.

Explication du contenu de ce dossier.
Le dossier « courses » contient le premier fichier de code go pour notre futur provider. Celui-ci initialise un provider, mais vide !

package courses

import (
    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

// Provider -
func Provider() *schema.Provider {
    return &schema.Provider{
        ResourcesMap:   map[string]*schema.Resource{},
        DataSourcesMap: map[string]*schema.Resource{},
    }
}

Le fichier « main.go », est le point d’entrée de notre provider.

package main

import (
    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
    "github.com/hashicorp/terraform-plugin-sdk/v2/plugin"

    "terraform-provider-courses/courses"
)

func main() {
    plugin.Serve(&plugin.ServeOpts{
        ProviderFunc: func() *schema.Provider {
            return courses.Provider()
        },
    })
}

Le dossier « terraform », contient le code Terraform qui appelera notre custom provider.

terraform {
  required_providers {
    courses = {
      version = "0.1"
      source  = "hashicorp.com/ekite/courses"
    }
  }
}

provider "courses" {}

Le « Makefile », qui lui nous permettra de build et installer notre provider sur notre machine. Vous remarquerez que les informations décrites dans ce fichier correspondent à l’appel du provider, dans le fichier ci-dessus.

TEST?=$$(go list ./... | grep -v 'vendor')
HOSTNAME=hashicorp.com
NAMESPACE=ekite
NAME=courses
BINARY=terraform-provider-${NAME}
VERSION=0.1
OS_ARCH=darwin_amd64

default: install

build:
    go build -o ${BINARY}

release:
    GOOS=darwin GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_darwin_amd64
    GOOS=freebsd GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_freebsd_386
    GOOS=freebsd GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_freebsd_amd64
    GOOS=freebsd GOARCH=arm go build -o ./bin/${BINARY}_${VERSION}_freebsd_arm
    GOOS=linux GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_linux_386
    GOOS=linux GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_linux_amd64
    GOOS=linux GOARCH=arm go build -o ./bin/${BINARY}_${VERSION}_linux_arm
    GOOS=openbsd GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_openbsd_386
    GOOS=openbsd GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_openbsd_amd64
    GOOS=solaris GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_solaris_amd64
    GOOS=windows GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_windows_386
    GOOS=windows GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_windows_amd64

install: build
    mkdir -p ~/.terraform.d/plugins/${HOSTNAME}/${NAMESPACE}/${NAME}/${VERSION}/${OS_ARCH}
    mv ${BINARY} ~/.terraform.d/plugins/${HOSTNAME}/${NAMESPACE}/${NAME}/${VERSION}/${OS_ARCH}

test: 
    go test -i $(TEST) || exit 1                                                   
    echo $(TEST) | xargs -t -n4 go test $(TESTARGS) -timeout=30s -parallel=4                    

testacc: 
    TF_ACC=1 go test $(TEST) -v $(TESTARGS) -timeout 120m

Nous allons maintenant build cette première version de notre provider, pour ce faire placez vous dans le dossier « custom-provider/resources/terraform-provider-courses »

On initialise notre module go. Le nom choisi ici doit matcher le nom choisi dans le ‘main.go’ au niveau des imports.

go mod init terraform-provider-courses

On installe les dépendances, de notre module

go mod tidy

Après cela, nous pouvons utiliser notre Makefile pour build et installer notre module

make build && make install

terraform init
terraform plan

docker-compose up -d

Ces routes sont disponibles dans l'api,
GET   http://localhost:4000/cours, renvoie une liste de cours
POST http://localhost:4000/cours, crée un cour avec ce body 
{
    "name": "Petit intervention",
    "time": 60,
    "summary": "intervention sur sujet tech"
}
PUT http://localhost:4000/cours/651fc2f3970d6264792bf49e, avec le même body que pour le POST
DELETE http://localhost:4000/cours/65201115d9a28e309a48d610, qui supprime le cours.

terraform init --upgrade
terraform plan

package courses

import (
    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

// Provider -
func Provider() *schema.Provider {
    return &schema.Provider{
        ResourcesMap: map[string]*schema.Resource{
            "ekite_cour": dataSourceCour(),
        },
        DataSourcesMap: map[string]*schema.Resource{
            "ekite_courses": dataSourceCourses(),
        },
    }
}

package courses

import (
    "bytes"
    "context"
    "encoding/json"
    "log"
    "net/http"

    "github.com/hashicorp/terraform-plugin-sdk/v2/diag"

    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

type Cour struct {
    Id      string `json:"_id"`
    Name    string `json:"name"`
    Time    int    `json:"time"`
    Summary string `json:"summary"`
}

func dataSourceCour() *schema.Resource {
    return &schema.Resource{
        CreateContext: resourceCourCreate,
        ReadContext:   resourceCourRead,
        UpdateContext: resourceCourUpdate,
        DeleteContext: resourceCourDelete,

        Schema: map[string]*schema.Schema{
            "_id": &schema.Schema{
                Type:     schema.TypeString,
                Optional: true,
            },
            "name": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
            "time": &schema.Schema{
                Type:     schema.TypeInt,
                Required: true,
            },
            "summary": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
        },
    }
}

func resourceCourCreate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    var diags diag.Diagnostics

    name := d.Get("name").(string)
    time := d.Get("time").(int)
    summary := d.Get("summary").(string)

    data := map[string]interface{}{
        "name":    name,
        "time":    time,
        "summary": summary,
    }

    jsonData, err := json.Marshal(data)

    resp, err := http.Post("http://localhost:4000/cours", "application/json", bytes.NewBuffer(jsonData))

    if err != nil {
        log.Fatal(err)
    }
    defer resp.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(resp.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.SetId(cour.Id)
    return diags
}

func resourceCourRead(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    return nil
}

func resourceCourUpdate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    return nil
}

func resourceCourDelete(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    return nil
}

terraform {
  required_providers {
    courses = {
      version = "0.0.2"
      source  = "hashicorp.com/ekite/courses"
    }
  }
}

resource "ekite_cour" "mon_cour" {
  provider = courses
  name = "Cour créé depuis terraform"
  time = 60
  summary = "Un simple exemple"
}

package courses

import (
    "bytes"
    "context"
    "encoding/json"
    "log"
    "net/http"
    "time"

    "github.com/hashicorp/terraform-plugin-sdk/v2/diag"

    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

type Cour struct {
    Id      string `json:"_id"`
    Name    string `json:"name"`
    Time    int    `json:"time"`
    Summary string `json:"summary"`
}

func dataSourceCour() *schema.Resource {
    return &schema.Resource{
        CreateContext: resourceCourCreate,
        ReadContext:   resourceCourRead,
        UpdateContext: resourceCourUpdate,
        DeleteContext: resourceCourDelete,

        Schema: map[string]*schema.Schema{
            "_id": &schema.Schema{
                Type:     schema.TypeString,
                Optional: true,
            },
            "name": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
            "time": &schema.Schema{
                Type:     schema.TypeInt,
                Required: true,
            },
            "summary": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
            "last_updated": &schema.Schema{
                Type:     schema.TypeString,
                Optional: true,
                Computed: true,
            },
        },
    }
}

func resourceCourCreate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    var diags diag.Diagnostics

    name := d.Get("name").(string)
    time := d.Get("time").(int)
    summary := d.Get("summary").(string)

    data := map[string]interface{}{
        "name":    name,
        "time":    time,
        "summary": summary,
    }

    jsonData, err := json.Marshal(data)

    resp, err := http.Post("http://localhost:4000/cours", "application/json", bytes.NewBuffer(jsonData))

    if err != nil {
        log.Fatal(err)
    }
    defer resp.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(resp.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.SetId(cour.Id)
    return diags
}

func resourceCourRead(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    var diags diag.Diagnostics
    client := &http.Client{Timeout: 10 * time.Second}

    url := "http://localhost:4000/cours/" + d.Id()

    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return diag.FromErr(err)
    }

    r, err := client.Do(req)
    if err != nil {
        return diag.FromErr(err)
    }
    defer r.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(r.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    d.Set("name", cour.Name)
    d.Set("time", cour.Time)
    d.Set("summary", cour.Summary)

    return diags
}

func resourceCourUpdate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    client := &http.Client{Timeout: 10 * time.Second}
    name := d.Get("name").(string)
    timeobj := d.Get("time").(int)
    summary := d.Get("summary").(string)

    data := map[string]interface{}{
        "name":    name,
        "time":    timeobj,
        "summary": summary,
    }

    jsonData, err := json.Marshal(data)

    url := "http://localhost:4000/cours/" + d.Id()

    req, err := http.NewRequest(http.MethodPut, url, bytes.NewBuffer(jsonData))
    if err != nil {
        log.Fatal(err)
    }
    req.Header.Set("Content-Type", "application/json; charset=utf-8")
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.Set("last_updated", time.Now().Format(time.RFC850))
    return resourceCourRead(ctx, d, m)
}

func resourceCourDelete(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    var diags diag.Diagnostics
    client := &http.Client{}
    url := "http://localhost:4000/cours/" + d.Id()
    req, err := http.NewRequest("DELETE", url, nil)
    if err != nil {
        panic(err)
    }
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.SetId("")
    return diags
}

L’article Terraform custom provider est apparu en premier sur EKITE.

Problème : bien souvent, ces solutions Cloud sont une boîte noire et au-delà de la facture correspondant aux ressources utilisées, il est à minima difficile d’en savoir plus sur la façon dont fonctionnent les fournisseurs de service Cloud, notamment sur le sujet du green IT. Parce que oui, si vous passez des heures à retravailler et limiter vos requêtes, que vos fonctionnalités sont sobres mais que l’hébergement Cloud que vous utilisez a pour principale source d’énergie une centrale à charbon, c’est pour le moins dommage. De même, si vos instances sont montées en permanence alors qu’elles connaissent des périodes de moindre utilisation (voire d’absence totale), on perd un peu de l’intérêt du green IT. Et enfin, il n’est pas toujours facile de se faire entendre sur ces questions, surtout quand les objectifs (de sprint, de produit, de politique d’entreprise) sont plus focalisés sur la performance économique que sur la préservation de la planète. 

Aujourd’hui, l’objectif est donc d’aborder ces différents sujets. D’une part, comment améliorer la consommation de ressources d’un cluster Cloud et de l’autre, comment adapter les KPI traditionnels, prisés par les directions financières, afin de les mettre au service d’une cause plus grande.

« C’est pas Versailles ici », ou comment optimiser son Cloud

Si la lecture du titre de cette partie vous a rappelé des souvenirs ou que vous vous êtes vous-même surpris ou surprise à prononcer ces mots, ces quelques paragraphes devraient vous parler. En effet, alors qu’on éteint la lumière lorsqu’on quitte une pièce, comment justifier de laisser des ressources informatiques allumées en continu, même lorsqu’elles ne sont pas utilisées ? Prenons l’exemple de vos environnements de recette et de développement : en dehors des heures de bureau, y a-t-il le moindre intérêt à les faire fonctionner, si ce n’est brûler (littéralement) du gaz et remplir les poches de Google et Amazon ? Des améliorations concrètes et rapides sont donc faciles à aller chercher (dans un premier temps). C’est le service que propose Kube-green, plug-in rapide à mettre en place (en 30 minutes c’est largement fait) et diablement efficace. Dans l’exemple qu’on trouve dans leur documentation, la mise en place d’une gestion très simple d’un cluster permet de réduire de près de 30% les émissions de gaz à effet de serre (GES) et jusqu’à 37% sur un cluster plus important. Rendez-vous compte : cela fait plus d’un tiers d’économie en quelques réglages. 

Remarque : le calcul de l’empreinte carbone se base sur un article rédigé par GoClimate et qui donne des estimations en fonction du type d’hébergement choisi.

OK, qu’est-ce que ça donne concrètement ?

Pour le tester, j’ai démarré un cluster Kubernetes en local, sur lequel j’ai créé un namespace, au sein duquel j’ai déployé une API, un front et une base de données. Ensuite, il m’a de lancer cette commande :

kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml

Après quelques secondes, Kube-green était déployé dans mon cluster, au niveau global. J’ai ensuite appliqué ce fichier, dans le même namespace où j’ai déployé mes applications.

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo 
metadata: 
  name: sleep-test 
  Namespace: app-example 
spec: 
  weekdays: "*" 
  sleepAt: "*:*/5" 
  wakeUpAt: "*:*/7"

Dans celui-ci est écrit que je souhaite scale down tous les déploiements de ce namespace, tous les jours, à chaque 5ème minute de chaque heure et de la même manière, scale up à chaque 7ème minute (l’exemple n’a pas vraiment de sens, il s’agit là plutôt d’illustrer la syntaxe, il y a évidemment d’autres manières de configurer cette partie). On peut décider d’ignorer certaines ressources, ou de stopper également ou uniquement des cronjobs. Vous pouvez trouver ces informations dans la doc de Kube-green, que l’on peut remercier pour sa clarté. Si on observe les Pods du namespace ,on voit bien qu’ils se coupent et s’allument comme désiré :

Certes, cette solution n’est qu’un début, mais pourquoi ne pas aller plus loin ? On peut imaginer répliquer ce système pour ajouter les jours fériés, les pauses-repas, et ensuite en production, en adaptant le nombre de nœuds disponibles en fonction de l’activité prévue.

Il existe encore d’autres solutions, comme KEDA, qui permettent d’être encore plus flexible dans les choix de scalabilité. Cet outil, en plus de reprendre les fonctionnalités de Kube-green, permet d’allumer et d’éteindre nos composants Kubernetes en suivant des métriques que vous pouvez personnaliser à volonté, au lieu de vous baser sur des métriques classiques, comme le niveau d’activité du CPU ou de la RAM. On peut imaginer scale sur un indicateur qui mesure le trafic, ou bien qui va chercher des informations en base de données. Par exemple une quantité de data à intégrer, ou encore une métrique personnalisée qui remonterait la consommation en euros (ou en CO2 ?) pour les limiter. KEDA est certes plus compliqué à mettre en place et à tester mais il vaut le coup qu’on s’y intéresse.

C’est bien beau vos histoires mais comment je vends ça moi ?

Ce qui est certain c’est qu’aujourd’hui les directions financières ont un objectif sur les questions d’argent plutôt que sur celles de la biodiversité ou de la sobriété énergétique (et en même temps, tant qu’on les appellera des directions financières…). C’est pour ça qu’il va falloir ruser : plutôt que de mentionner la diminution du bilan carbone de votre application, il vaudra toujours mieux mettre en avant la baisse de la facture de votre infrastructure (forcément, si on utilise moins de ressources, on émet moins de GES et on paie moins cher). En revanche, pour donner un objectif à vos équipes sensibles à ces questions, d’autres outils existent et notamment Kube Carbon.

Introduit en 2019 par Adam Hevenor, cet outil permet facilement de générer des courbes et des métriques suivant les émissions de GES de votre activité. Dans un article partagé sur Medium, il détaille son calcul de manière à faire le lien entre volume d’opérations informatiques et émission de gaz à effet de serre. La méthodologie n’est pas parfaite, et certains chiffres mériteraient sans doute d’être revus (la publication date déjà d’octobre 2019), mais elle explore néanmoins les différentes questions qui se posent à l’heure où l’usage du Cloud se démocratise. Quelle est l’empreinte carbone des services Cloud de Google ou d’Amazon ? Les deux vous répondront qu’ils sont neutres en carbone mais ce tour de passe-passe n’est possible que grâce à l’achat de crédits carbone et autres compensations, le tout sans avoir la moindre transparence concernant les volumes d’équivalent CO2 produits. C’est d’ailleurs la conclusion de l’article d’Adam qui appelle de ses vœux les grands du Cloud à plus de transparence sur ces questions (d’ailleurs ils pourraient intégrer à leur service le même type de graphes de façon native). Surtout, dans une période qui appelle à la sobriété, tout ce qu’il n’est pas nécessaire de compenser est bon à prendre.

Kube Carbon a donc cet avantage de fournir une vision chiffrée de votre impact carbone, avec pour objectif de devenir un indicateur important pour l’ensemble des acteurs.

OK, vous pouvez me refaire un topo pratique aux petits oignons comme pour Kube-green ?

Kube Carbon, techniquement, se résume à un dashboard Grafana, qui, dans l’état, ne fait que prendre des métriques, les transformer et nous les afficher. Ce qu’il faut retenir c’est la réflexion qu’a eu Adam Hevenor autour de ces indicateurs. Pour mieux me rendre compte de ce que cela représente, j’ai quand même déployé Prometheus, Grafana et importé ce dashboard.

Toujours sur mon cluster k8s local, j’ai exécuté ces commandes :

// create dedicated namespace and switch to it 
k create ns prometheus 
kubens prometheus 
// helm install for prometheus & grafana 
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
helm repo update 
helm install prometheus prometheus-community/prometheus 
helm repo add grafana https://grafana.github.io/helm-charts  
helm repo update 
// Expose grafana svc to local access 
kubectl expose service grafana --type=NodePort --target-port=3000 --name=grafana-ext 
// Get svc port for access

// Get secret data to log in grafana 
k get secret  grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

sum(container_cpu_usage_seconds_total * (.001/$flops_per_watt*$carbon_per_watt*$clock_speed)) / 1000000000

L’article Du green dans ton Cloud est apparu en premier sur EKITE.

Vous avez dû remarquer que le sujet de l’infrastructure as code est devenu omniprésent dans le déploiement d’infrastructures, que ce soit des ressources physiques ou déployées chez un fournisseur Cloud. Dans cet article, nous allons découvrir comment utiliser Terraform, notre outil d’infrastructure as code, pour déployer des ressources chez un fournisseur Cloud, ici Scaleway.Pour mieux appréhender cet article, il est préférable d’être déjà initié à Terraform et de manière plus générale, d’avoir une connaissance de l’infrastructure as code. Ne vous inquiétez pas, même si vous n’êtes pas familier avec ces concepts, nous allons tout de même commencer par des petits rappels, qui vous permettront de suivre le guide pas à pas.À la fin de cet article nous aurons déployé, chez Scaleway, une base de données managée et une application conteneurisée connectée à celle-là.

Petits rappels

Terraform

Terraform est un outil qui va permettre de créer, mettre à jour et versionner vos infrastructures de manière sécurisée et efficiente. Une infrastructure composée de ressources Cloud, comme des bases de données, des machines virtuelles ou n’importe quel service de votre fournisseur Cloud préféré.

Il peut aussi déployer des ressources «?maison?», via du développement custom, qui seront propres à vos besoins.

Scaleway

Contrairement aux fournisseurs Cloud les plus connus, comme GCP, AWS, ou encore Azure, Scaleway est un fournisseur de services Cloud estampillé Cloud français.

Il va fournir des services que vous pouvez retrouver chez d’autres fournisseurs, comme la création de machines virtuelles, du Kubernetes, du serverless, des bases de données managées, etc.

Guide pas à pas

L’ensemble des actions sera réalisé sur Ubuntu22.04.2LTS.

Setup Terraform

Nous allons tout d’abord installer Terraform :

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common

wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg

gpg --no-default-keyring \
--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
--fingerprint

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update && apt-get install terraform

Vous pouvez retrouver toutes les instructions dans le lien en bas de l’article.

 

Provider Scaleway

Terraform utilise des composants appelés des «?providers?», qu’on pourrait apparenter à des librairies dans le monde du développement.

Ces providers vont vous permettre d’interagir facilement avec les ressources que vous voulez maintenir. Il existe énormément de providers officiels pour des solutions connues, par exemple pour GCP, Github, Datadog et j’en passe.

Pour en revenir à l’utilisation de Terraform pour des ressources custom, nous ne sommes pas limités à l’utilisation des providers officiels. N’importe qui peut développer son provider custom pour répondre à ses propres besoins.

Ici nous allons nous intéresser exclusivement au provider officiel Scaleway. Vous pouvez aller sur la?Terraform Registry?pour avoir un détail complet de son utilisation.

 

La pratique

La première étape est de configurer le provider Scaleway. Les providers Terraform ont des paramètres obligatoires, et d’autres qui ne le sont pas. Dans le cas de ce provider, les paramètres obligatoires correspondent à vos informations d’identification Scaleway. Vous allez avoir besoin de ces informations?:

Votre organisation id, que vous pouvez retrouver dans l’interface Scaleway.

Le project id dans lequel vous voulez créer vos ressources.

Et enfin, une clé d’API Scaleway composée d’une access key et d’une secret key. 

Maintenant que vous avez ces informations, nous pouvons commencer à écrire nos fichiers Terraform.

Il y a trois façons de déclarer ces paramètres:

• soit en dur dans le fichier
• soit définis par des variables Terraform que vous passerez au moment de l’exécution
• la plus sécurisée via des variables d’environnement. 

Avec les variables terraform:

// Préférez utiliser la var. d’env. SCW_ACCESS_KEY
variable "access_key" {
  type = string
  description = "Notre identifiant de clé d'API"
}

// Preferez utiliser la var d'env SCW_SECRET_KEY
variable "secret_key" {
  type = string
  description = "Notre clé d'API"
}

// Préférez utiliser la var. d’env. SCW_DEFAULT_PROJECT_ID
// Pour trouver votre project_id rendez vous sur le dashboard de votre projet
variable "project_id" {
  type = string
  description = "Notre id de projet"
}

// Préférez utiliser la var. d’env. SCW_DEFAULT_PROJECT_ID.
// Pour trouver votre organization_id rendez-vous sur le dashboard de votre organisation
variable "organization_id" {
  type = string
  description = "Notre id d'organisation"
}

terraform {
  required_providers {
    scaleway = {
      source = "scaleway/scaleway"
    }
  }
required_version = ">= 0.13"
}
// Preferez utiliser les variables d'environnement pour plus de sécurité
// remplacer le provider par provisioner "scaleway" {}

provider "scaleway" {
  access_key = var.access_key
  secret_key = var.secret_key
  project_id = var.project_id
  organization_id = var.organization_id
  region = var.region
  zone = var.zone
}

 

Avec les variables d’environnement:

export SCW_ACCESS_KEY="xxx"
export SCW_SECRET_KEY="xxx"
export SCW_DEFAULT_PROJECT_ID="xxx"
export SCW_DEFAULT_ORGANIZATION_ID="xxx"

terraform {
  required_providers {
    scaleway = {
      source = "scaleway/scaleway"
    }
  }
  required_version = ">= 0.13"
}
provider "scaleway" {}

Le provider permet également de configurer des paramètres qui vont être réutilisés pour les autres ressources, par exemple la région et la zone dans lesquelles nous allons les déployer. 

Ici j’ai choisi de passer par des variables avec des valeurs par défaut, qui vont me permettre de surcharger ces paramètres à ma convenance. Nous pouvons imaginer lancer deux déploiements en parallèle?: l’un sur fr-par et l’autre vers nl-ams. variable « region » {

Maintenant que nous avons configuré notre provider, nous allons nous amuser à déployer un petit conteneur WordPress, et pour cela nous allons commencer par créer notre base de données? !

variable "region" { 
  type = string 
  description = "La région dans laquelle nous allons créer nos ressources"  
  default = "fr-par" 
} 

variable "zone" { 
  type = string description = "La zone de la région dans laquelle nous allons créer nos ressources" default = "fr-par-1" 
} 

terraform { 
  required_providers { 
    scaleway = { 
      source = "scaleway/scaleway" 
    } 
  } 
  required_version = ">= 0.13" 
} 

provider "scaleway" { 
  region = var.region 
  zone = var.zone 
}

 

Managed Datadase

Nous allons commencer par créer un fichier dédié à cette ressource, disons mysql.tf.

D’abord nous allons créer quelques variables qui vont nous être utiles, comme le nom de la base de données et notre nom d’utilisateur pour celle-là.

Nous allons utiliser une ressource bien utile de Terraform pour générer un mot de passe complexe pour notre utilisateur de base de données. Nous nous assurons au passage de respecter les conditions imposées par Scaleway quant à la politique de mot de passe.

Ensuite nous allons créer notre instance de serveur de base de données. Les paramètres utilisés ici correspondent, bien sûr, à des exemples pour un environnement de développement.

variable "wp_username" {
  type        = string
  default     = "wp-admin"
}


variable "wp_db_name" {
  type        = string
  default     = "wordpress"
}

resource "random_password" "wp_sql_pwd_db" {
  length  = 16
  special = true
  min_lower = 1
  min_numeric = 1
  min_special = 1
  min_upper = 1
}

resource "scaleway_rdb_instance" "wp_sql" {
  name           = "wp-mysql"
  node_type      = "DB-DEV-S"
  engine         = "MySQL-8"
  is_ha_cluster  = true
  disable_backup = true
  user_name      = var.wp_username
  password       = random_password.wp_sql_pwd_db.result
}

Comme vous le voyez, il ne faut pas énormément de lignes pour créer une nouvelle instance. Cette instance sera automatiquement déployée sur fr-par-1 grâce à la configuration appliquée sur le provider dans le main.tf. 

Il ne nous reste plus qu’à créer notre base de données?! Ajoutons quelques lignes. 

variable "wp_username" {
  type        = string
  default     = "wp-admin"
}

variable "wp_db_name" {
  type        = string
  default     = "wordpress"
}

resource "random_password" "wp_sql_pwd_db" {
  length  = 16
  special = true
  min_lower = 1
  min_numeric = 1
  min_special = 1
  min_upper = 1
}

resource "scaleway_rdb_instance" "wp_sql" {
  name           = "wp-mysql"
  node_type      = "DB-DEV-S"
  engine         = "MySQL-8"
  is_ha_cluster  = true
  disable_backup = true
  user_name      = var.wp_username
  password       = random_password.wp_sql_pwd_db.result
}

resource "scaleway_rdb_database" "wp_sql_db" {
  instance_id    = scaleway_rdb_instance.wp_sql.id
  name           = var.wp_db_name
}

Nous n’avons qu’à récupérer l’id de notre instance fraîchement créée et lui donner le nom que nous souhaitons.
Et voilà?! Nous avons écrit le code représentant notre serveur de base de données.
Passons maintenant à notre WordPress.

 

Serverless Container

Scaleway propose différentes solutions pour déployer nos applications, du Kubernetes, des serverless functions et containers ou encore des machines virtuelles. Ici nous allons utiliser les serverless containers. Nous allons avoir besoin uniquement de deux ressources?: un namespace dans lequel nous allons déployer notre 2e ressource, notre conteneur. Ajoutons un nouveau fichier, wordpress.tf?:

variable "container_name" {
  type        = string
  default     = "wordpress-example"
}

resource "scaleway_container_namespace" "wp_namespace" {
  name        = "wp-namespace"
  description = "namespace dédié au conteneur wordpress-example"
}

resource "scaleway_container" "wp_container" {
    name = var.container_name
    description = "wordpress container"
    namespace_id = scaleway_container_namespace.wp_namespace.id
    registry_image = "bitnami/wordpress:latest"
    port = 3000
    cpu_limit = 1120
    memory_limit = 2048
    min_scale = 1
    max_scale = 2
    timeout = 600
    max_concurrency = 10
    protocol = "h2c"
    deploy = true

    environment_variables = {
        "WORDPRESS_DEBUG" = "1" 
    }
    secret_environment_variables = {
      "WORDPRESS_DATABASE_HOST" = scaleway_rdb_instance.wp_sql.endpoint_ip
      "WORDPRESS_DATABASE_PORT_NUMBER" = scaleway_rdb_instance.wp_sql.endpoint_port
      "WORDPRESS_DATABASE_NAME" = var.wp_db_name
      "WORDPRESS_DATABASE_USER" = var.wp_username
      "WORDPRESS_DATABASE_PASSWORD" = random_password.wp_sql_pwd_db.result
    }
    depends_on = [
      scaleway_rdb_instance.wp_sql,
      random_password.wp_sql_pwd_db
    ]
}

Le provider Scaleway facilite la configuration de ce conteneur. Vous retrouvez ici tous les paramètres existants. Nous pouvons retrouver des classiques comme, bien sûr, l’image de notre conteneur, les ressources allouées, le scaling, etc. 

Mais un paramètre a attiré mon attention, le «?secret_environment_variables?». Celui-ci nous permet de passer facilement des secrets qui seront chargés en variables, ce qui est très utile niveau sécurité?! 

 

A l’action !

 

Nous y voilà, nous avons terminé de décrire notre infrastructure, il ne nous reste plus qu’à la créer?!
Je vais créer un fichier de variables, uncommited.tfvars.

wp_username = "test"
wp_db_name = "dbtest"
access_key = "xxx"
secret_key = "xxx"
project_id = "xxx"
organization_id = "xxx"

Il ne nous reste plus qu’à appliquer nos fichiers Terraform

Après avoir accepté le plan de Terraform, il ne vous reste plus qu’à patienter et regarder vos ressources se créer. 

Le mot de la fin

Nous y voilà, en quelques minutes nous avons pu déployer notre infrastructure et notre application.
Le provider Terraform Scaleway est de mon point de vue efficace, très bien documenté et donc facile à prendre en main.
Je n’ai pas trouvé plus difficile d’utiliser ce provider comparé à ses concurrents, même si l’interface des logs pour les serverless containers n’est pas des plus efficaces.

Liens utiles:

provider scaleway

access key

project id

organisation id

terraform

L’article Scaleway et Terraform est apparu en premier sur EKITE.

Dans le précédent article intitulé « Terraform custom provider » que vous pouvez retrouver ici : https://ekite.info/2024/04/05/terraform-custom-provider/ vous avez pu apprendre et créer votre propre provider personnalisé pas à pas. Cependant, ne manquait-il pas quelque chose ? Faire une requête HTTP avec une URL en « dur » n’est franchement pas très utile et sécurisé…

Dans ce second article, nous vous présenterons comment configurer correctement votre provider afin de lui passer tous les paramètres que vous souhaitez. Que ce soit pour la configuration de variables d’environnement telles qu’une URL pouvant être dupliquée sur des environnements différents selon l’utilisation que l’on fait de notre provider, ou alors des secrets qui ne peuvent pas, par définition, être mis en clair directement dans un repository Git.

Vous trouverez les évolutions dans la pull request liée à cet article.

Cependant, nous vous proposons de réaliser l’exercice vous même comme dans le premier article où nous avons appris à créer notre premier custom provider.. Alors codons ensemble !

Prérequis

Avoir réalisé la première partie Terraform custom provider

Pas à pas

Pour commencer, vous avez trois choix possibles, récupérer le projet depuis Git, reprendre à la fin du guide précédent ou récupérer la branche de la pull request sur le précédent lien.

Afin d’avoir un exemple concret, nous avons apporté une petite modification à l’API pour qu’elle n’autorise que les requêtes contenant un certain header avec une valeur précise, qui peut correspondre à une liste de plusieurs clés d’API valides.

La mise en place de la configuration de notre provider se passera uniquement dans le fichier provider.go, et se résumera à deux éléments. D’abord un schéma de définition de notre provider, qui corresponds aux paramètres possibles de notre provider, dans notre cas, une URL et un token d’accès à une API.

func Provider() *schema.Provider {
    return &schema.Provider{
        Schema: map[string]*schema.Schema{
            "api_token": &schema.Schema{
                Type:        schema.TypeString,
                Required:    true,
                DefaultFunc: schema.EnvDefaultFunc("API_TOKEN", nil),
            },
            "api_url": &schema.Schema{
                Type:        schema.TypeString,
                Required:    true,
                DefaultFunc: schema.EnvDefaultFunc("API_URL", nil),
            },
        },
        ResourcesMap: map[string]*schema.Resource{
            "ekite_cour": dataSourceCour(),
        },
        DataSourcesMap: map[string]*schema.Resource{
            "ekite_courses": dataSourceCourses(),
        },
        ConfigureContextFunc: configure,
    }
}

Ensuite il nous faudra une méthode permettant de configurer notre provider. Si vous êtes observateur, vous verrez l’appel à cette méthode dans l’extrait précédent.

type Config struct {
    api_token string
    api_url   string
}

func configure(ctx context.Context, d *schema.ResourceData) (interface{}, diag.Diagnostics) {

    var diags diag.Diagnostics
    config := Config{}

    // On essaie de récupérer la valeur passée à notre provider, s'il y arrive il le cast en string, sinon on renvoie un message d'erreur
    if v, ok := d.GetOk("api_token"); ok {
        config.api_token = v.(string)
    } else {
        diags = append(diags, diag.Diagnostic{
            Severity: diag.Error,
            Summary:  "api_token is required",
        })

        return nil, diags
    }

    if v, ok := d.GetOk("api_url"); ok {
        config.api_url = v.(string)
    } else {
        diags = append(diags, diag.Diagnostic{
            Severity: diag.Error,
            Summary:  "api_url is required",
        })

        return nil, diags
    }

    return &config, diags
}

Cette méthode nous permettra d’accéder à notre configuration dans n’importe quelle méthode via l’interface du provider. On observe d’abord une petite structure qui représente notre configuration, puis, le plus intéressant, le contenu de notre méthode. Nous voyons qu’elle aussi à un paramètre « d », qui est la variable définie par le schéma que nous avons vu plus haut. Via cette variable nous pourrons interagir avec les valeurs passées par ceux qui utilisent notre provider et les orienter en cas d’erreur. Dans notre exemple nous allons juste vérifier la présence d’une valeur mais on peut imaginer faire des requêtes pour vérifier les paramètres ou juste les comparer à des listes de valeurs constantes.

Bien, nous avons notre configuration, il est maintenant temps de l’utiliser pour nos ressources existantes. Au final, nous avons besoin de ne modifier que les requêtes à notre API pour y ajouter un header, et utiliser l’URL d’API passée en configuration.

Retournons dans notre fichier data_source_cour.go, et modifions notre CRUD. Pour l’exemple je mettrai uniquement la méthode read, mais vous pouvez retrouver le code complet dans le repo.

func resourceCourRead(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    var diags diag.Diagnostics
    client := &http.Client{Timeout: 10 * time.Second}
    config := m.(*Config)
    url := config.api_url + "/cours/" + d.Id()

    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return diag.FromErr(err)
    }
    req.Header.Add("tf-api-key", config.api_token)

    r, err := client.Do(req)
    if err != nil {
        return diag.FromErr(err)
    }
    defer r.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(r.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    d.Set("name", cour.Name)
    d.Set("time", cour.Time)
    d.Set("summary", cour.Summary)

    return diags
}

Donc dans cette méthode on retrouve l’interface de notre provider, via la variable « m », en paramètre de notre méthode. Remarquez comme il est facile d’interagir avec cette configuration. Il suffit de récupérer dans une variable « config » les informations passées par l’interface (ligne 4). Il ne nous reste plus qu’à l’utiliser où bon nous semble. Dans la ligne qui suit nous créons notre URL avec la propriété « api_url » et ligne 11 nous créons le header et lui attribuons la valeur passée avec la propriété « api_token ». Il ne nous reste plus qu’à tester tout ça !

Vous connaissez la chanson, on change la version de notre provider dans notre Makefile, et on lance un « make install ». Maintenant, rendez-vous dans le main.tf pour y apporter les modifications nécessaire. Une fois cela fait on lance notre commande « tf init –upgrade »

terraform {
  required_providers {
    courses = {
      version = "0.5.8"
      source  = "hashicorp.com/ekite/courses"
    }
  }
}

provider "courses" {
  api_url = "http://localhost:4000"
  api_token = "1234-5678-910-abCd"
}

resource "ekite_cour" "example" {
  provider = courses
  name = "test from tf update"
  time = 60
  summary = "summary from tf"
}

Vous pouvez maintenant jouer avec ces paramètres pour observer les différents comportements.

Quand on ne remplit pas les paramètres :

Quand on set de mauvais paramètres :

Et bien sùr avec les bons paramètres, un résultat en success

Conclusion

À la fin de cette suite de deux articles, vous êtes maintenant capable de réaliser vos propres custom providers Terraform, ainsi que la configuration associée. La prochaine étape sera de voir comment nous pouvons mettre en place une intégration continue autour du développement de ce provider et comment le mettre facilement à disposition d’utilisateurs.

Cet exemple simple nous a permis de voir comment réaliser et configurer un provider custom. Il vous a permis de voir toute la puissance de Terraform dont la customization peut aller jusqu’à l’extrême limite de votre imagination et de vos besoins… Alors allez-y, codez !

L’article Terraform custom provider, la suite ! est apparu en premier sur EKITE.

Bienvenue dans cette vidéo ! Ici nous allons vulgariser les concepts de bases liés à Kafka, et vous donner une idée des cas dans lesquels il est justifié de l’utiliser. Après cette vidéo vous en aurez appris davantage sur les principes de base de Kafka, les différentes briques qui le composent, leurs fonctionnement et interactions ainsi que les alternatives existantes.

L’article Kafka est apparu en premier sur EKITE.

Le terme PWA est entré depuis quelques années dans le long répertoire des acronymes liés au numérique. Mais qu’est ce qu’une Progressive Web App ?

Pour certains c’est la promesse d’une expérience mobile responsive boostée par les fonctionnalités de votre téléphone. Elle serait facile à mettre en place, de faible coût et elle n’aurait plus rien à envier aux applications natives.

Afin de vous éclairer sur le sujet et de vous permettre de vous faire votre propre avis, vous trouverez ici les informations qui nous paraissent pertinentes pour une première approche fonctionnelle du sujet.

Mais d’où ça vient ?

La PWA est une suite logique de l’évolution du web sur mobile. Avant 2007 et l’arrivée des smartphones, l’accès mobile au web se fait par le WAP (Wireless Application Protocol). Il permet le téléchargement d’applications hors ligne non, dépendantes d’un réseau instable et peu performant.

Après 2007 et avec la popularisation des smartphones arrive l’essor du développement mobile. Dès lors des solutions WEB tournent sur des technologies dynamiques exécutées côté serveur. Steve Jobs imagine déjà des applications proches du principe de la PWA mais les principaux acteurs du marché font alors le choix de partir sur le développement d’applications natives permettant une meilleure UX et une meilleure intégration avec nos téléphones.

C’est en 2010 que l’arrivée de HTML5 et CSS3 va relancer les travaux autour d’applications hybrides et la mise en place de design responsive. On cherche alors à mutualiser le développement desktop et mobile.

Le terme PWA arrive en 2015 grâce à Alex Russell, l’un des ingénieurs ayant conceptualisé la solution chez Google. PWA: “Progressive Web Apps: Escaping Tabs Without Losing Our Soul”

Aujourd’hui les PWA sont supportées par une majorité de grandes entreprises de la tech (Google, Microsoft, Samsung, Mozilla, etc.) et utilisées par de nombreuses marques grand public (Starbucks, Pinterest, Spotify, etc.).

Oui mais ça consiste en quoi ?

Les Progressive Web Apps sont des versions optimisées d’un site web pour le mobile. Elles intégrent des fonctionnalités du téléphone, qui, jusqu’à aujourd’hui étaient réservées aux applications natives : appareil photo, mode hors ligne, raccourci écran d’accueil etc. Elles sont considérées comme des solutions Hybrides. Supportées par le navigateur du téléphone, elles ne nécessitent pas de développement spécifique à l’OS et permettent la mutualisation des coûts de développement mobile et desktop.

1- Un service Worker au coeur de l’application

Composant fondamental de la PWA, le service Worker est un script exécuté en tâche de fond qui va apporter toute l’intelligence à la PWA. Il intercepte les requêtes réseaux et y applique des configurations. Il permet :

• Mise en cache du contenu
• Synchronisation des données en arrière plan
• Push de notifications
• L’utilisation des fonctionnalités de votre téléphone
• L’exécution d’actions hors ligne (comme pousser une bannière lorsque le téléphone est hors ligne)
• …

2- Un Manifest pour une expérience mobile

Le manifest, en plus du service worker, va permettre de transformer un site en PWA et de simuler une expérience native. Il s’agit d’un simple fichier JSON dans lequel est configuré l’application et qui permet de la personnaliser. Les utilisateurs pourront également installer directement un site web sur leur mobile ou leur desktop sans passer par les stores d’applications.

{
    "name": "Blog Ekite",
    "short_name": "Blog Ekite",
    "description": "Blog Ekite.",
    "icons": [
        {
            "src": "assets/images/icons/icon-48.png",
            "sizes": "48x48",
            "type": "image/png"
        },
        {
            "src": "assets/images/icons/icon-72.png",
            "sizes": "72x72",
            "type": "image/png"
        },
        {
            "src": "assets/images/icons/icon-96.png",
            "sizes": "96x96",
            "type": "image/png"
        },
        {
            "src": "assets/images/icons/icon-128.png",
            "sizes": "128x128",
            "type": "image/png"
        },
        {
            "src": "assets/images/icons/icon-192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "assets/images/icons/icon-384.png",
            "sizes": "384x384",
            "type": "image/png"
        },
        {
            "src": "assets/images/icons/icon-512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ],
    "start_url": "/jekyll-site/",
    "display": "fullscreen",
    "theme_color": "#000000",
    "background_color": "#000000"
}

Configuration du raccourci de l’application mobile

• Nom
• URL
• Icone
• etc.

3- Des APIs HTML5 pour les fonctionnalités

Le développement de PWA est grandement facilité par HTML5 qui propose la mise à disposition de nombreuses API aux navigateurs. Ces API permettent, entre autres choses, l’utilisation de fonctionnalités telles que la géolocalisation, le push, le statut de la batterie, le presse papier, l’orientation de l’écran, les vibrations du mobile etc. La liste détaillée de ces fonctionnalités est disponible sur ce site.

Lighthouse est un plugin Chrome qui permet d’auditer un site web et qui indique son niveau de compatibilité avec la PWA. Ce plugin liste l’ensemble des caractéristiques officielles qui permettent d’évaluer la performance des applications.

Progressive

Les applications web progressives fonctionnent sur n’importe quel périphérique et intègrent les fonctionnalités disponibles du navigateur et de l’appareil utilisé.

Sécurisée

La mise en place d’un protocole HTTPS permet aux PWA d’être fiables et sûres, ce qui répond aux problématiques de sécurité des échanges entre les utilisateurs et les sites

Engageante

Elles proposent une expérience utilisateur immersive en plein écran et facilitent le réengagement grâce à l’envoi de notifications push web.

Installable

L’utilisation d’un fichier Manifest permet aux PWA de proposer, à l’instar d’une application mobile native, l’installation de l’application sur l’écran d’accueil du mobile.

Rapidité

D’après Google, 53 % des internautes abandonnent un site si son chargement prend plus de trois secondes. Une fois le site chargé, la navigation doit se faire de manière rapide et fluide.

Optimisation pour le référencement

Utilisant les technologies du web, les progressive web app peuvent être référencées sur les moteurs de recherche de la même manière que n’importe quel site web classique.

Indépendante de la connexion

Grâce à la gestion du cache via l’utilisation d’un Service Worker, une fois le contenu chargé, il sera possible de le consulter même dans les zones de faible connexion réseau.

Sur le sujet de la mise en place et de la compatibilité avec les langages du marché, rien de particulier, la liste des frameworks est disponible ici : HNPWA

Donc pas mal d’avantages !

Les solutions PWA sont assez simples à mettre en place. Elles ont une marge d’évolution relativement importante selon le temps et l’argent qui y sont consacrés. D’un point de vue utilisateur, l’installation se fait de façon intuitive, sans même devoir passer par les stores. L’expérience utilisateur peut devenir aussi immersive que sur une application native.

Les principaux avantages de la PWA sont, sans aucun doute, la fluidité, la fiabilité et la capacité à proposer des parcours hors ligne (grâce au chargement progressif) ainsi que l’optimisation de l’affichage sur mobile. La co-construction avec le site web facilite l’organisation des équipes et permet la mutualisation des coûts de développement.

Sur un marché qui ne pense plus seulement à l’expérience utilisateur mais aussi à l’impact environnemental, ces différents avantages s’ancrent parfaitement dans des projets d’éco-conception : moins de données à héberger, un design optimisé pour une utilisation réduite de la batterie du mobile et surtout des phases de développement réduites contrairement à des projets d’application native.

Mais aussi des limites.

Vous avez peut-être entendu qu’Apple et PWA ne faisaient pas bon ménage. Malheureusement comme vous pourrez le constater dans ce tableau des compatibilités, les fonctionnalités disponibles sur Iphone et Safari sont, aujourd’hui encore, très limitées. Il s’agit là du principal frein à la substitution des applications natives pour les entreprises fortement implantées sur mobile.

Il est également à noter que la mise en place d’une PWA nécessite une sécurisation de l’ensemble des pages de votre site par le protocole https.

Qui fait de la PWA ?

Voici 2 exemples de PWA réussies:

Twitter avec twitter lite:

Objectifs:

• Améliorer l’expérience sur les connexions limitées.
• Simplifier l’accès sans téléchargement sur les stores
• Optimiser par le cache et la taille des images
• Charger en amont pour une navigation hors ligne

Résultat:

• 65 % d’augmentation de pages vues par session
• 75 % d’augmentation de tweets envoyés
• 20 % de baisse du taux de rebond (comparé au site mobile avant PWA)

ALIBABA (2016) Objectifs:

• Augmenter le taux de conversion sur mobile
• Personnaliser l’ergonomie et le design sur la PWA
• Optimiser le chargement des images (nombreuses) pour se déployer sur les pays à faibles connections
• Fidéliser avec la proposition d’ajout du site sur l’écran d’accueil

Résultat:

• 76% de plus sur le taux de conversions sur tous les navigateurs (30% sur Android)
• 14% d’utilisateurs actifs mensuels en plus sur iOS
• 4X plus d’ajout à l’écran d’accueil

En conclusion

La PWA n’est ni une évolution des solutions mobiles natives ni une solution de consolation.
Il s’agit d’une vraie réponse à des problématiques de déploiement sur mobile.
Elle offre une expérience immersive et intuitive pour l’utilisateur. Sa mise en place est accessible à n’importe quelle taille de projet web.

Elle permet de rapidement mutualiser les coûts grâce à sa facilité de transformation. Malheureusement son utilisation pour le développement de parcours innovants reste restreinte à cause de sa non-compatibilité avec les fonctionnalités natives des appareils IOS.

Aujourd’hui, la montée en puissance de cette technologie semble être conditionnée par Apple et leur volonté ou non d’améliorer la prise en charge des PWA. Après 5 ans d’existence, cette technologie n’a toujours pas réussi à percer.

Glossaire:

WAP:C’est le premier protocole de communication qui a permis de relier le réseau mobile à internet

Application Hybride: contrairement aux applications natives qui utilisent directement les composants du device (mobile/tablette..), les applications hybrides utilisent le navigateur WEB embarqué dans le device et les technologies qu’on y retrouve pour le développement web, HTML, CSS, JavaScript

Responsive: le Responsive Web Design (RWD) est une technique qui consiste à ajuster automatiquement l’affichage d’une page web à la taille de l’écran du terminal utilisé

Script: suite de commandes qui permettent d’automatiser une tâche

Stores d’application: bibliothèque telle que l’Apple store ou le Play store qui permettent de trouver et d’installer des applications sur un téléphone

Framework: le regroupement d’outils qui facilitent le développement de logiciels et la création de systèmes (aussi appelé environnement de développement)

Sources:

• https://blog.octo.com/cest-quoi-une-progressive-web-app-pwa/
• https://fr.wikipedia.org/wiki/Progressive_web_app
• https://developer.mozilla.org/fr/docs/Web/Progressive_web_apps
• https://www.novaway.fr/blog/tech/3-exemples-pwa
• https://www.goodbarber.com/blog/progressive-web-apps-browser-support-compatibility-a883/
• https://developers.google.com/web/showcase/2017/twitter
• https://developers.google.com/web/showcase/2016/flipkart

L’article PWA : Innovation ou solution de consolation ? est apparu en premier sur EKITE.