Martin Catty - Articles

De ingress-nginx à Envoy Gateway

2026-09-30T00:00:00Z

Il y a trois ans, je vous expliquais comment protéger les services derrière vos ingress avec OAuth2 Proxy.

Trois annotations sur un ingress nginx, un proxy installé une fois dans le cluster, et le tour était joué.

Aujourd'hui, nous avons retiré ingress-nginx de tous nos clusters. Et oauth2-proxy avec.

Sur le papier, une migration d'ingress c'est « juste » réécrire des manifests. En pratique, c'est surtout découvrir tout ce que nginx faisait pour nous sans qu'on le lui demande.

Cet article raconte cette migration, et surtout ce qui a cassé.

Pourquoi migrer ?

La raison la plus évidente : ingress-nginx n'est plus maintenu. Le projet est passé en maintenance minimale puis s'est arrêté en mars 2026. Garder un composant exposé sur Internet sans correctifs de sécurité n'est pas une option.

Mais c'est aussi l'occasion de régler un problème plus ancien.

L'objet Ingress de Kubernetes est très pauvre. Il sait router un host et un chemin vers un service, et c'est à peu près tout. Tout le reste (taille des requêtes, timeouts, authentification, websockets, sessions persistantes…) passe par des annotations propres à chaque contrôleur :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/affinity: cookie
    nginx.ingress.kubernetes.io/auth-url: https://url-du-proxy/oauth2/auth

Ces annotations sont devenues une API de fait : des chaînes de caractères, non typées, non validées, et qui ne veulent rien dire pour un autre contrôleur.

La Gateway API corrige ça avec un modèle en plusieurs objets, chacun porté par un rôle différent :

GatewayClass : quelle implémentation (ici Envoy Gateway), gérée par l'équipe plateforme
Gateway : un point d'entrée, ses listeners et ses ports
HTTPRoute : le routage d'une application, géré par l'équipe qui la déploie

Et pour tout ce que le standard ne couvre pas encore, Envoy Gateway propose des policies typées qui s'attachent à une Gateway ou à une HTTPRoute. Nous allons en croiser plusieurs.

Pourquoi Envoy Gateway et pas Cilium ?

Nos clusters utilisent déjà Cilium comme CNI, et Cilium implémente la Gateway API. Le choix semblait évident.

Il ne l'a pas été, pour une raison très concrète : les sessions persistantes.

Une de nos applications est stateful côté serveur. Un utilisateur doit toujours retomber sur le même pod, sinon il perd sa session. Avec nginx, c'était l'annotation affinity: cookie.

Dans la Gateway API, cette fonctionnalité existe (sessionPersistence, GEP-1619), mais seulement dans le canal experimental des CRDs. Au moment où nous avons fait le choix, Cilium ne l'implémentait pas contrairement à Envoy Gateway.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mon-app
spec:
  parentRefs:
    - name: envoy-gateway
      namespace: edge
  hostnames:
    - mon-app.exemple.fr
  rules:
    - backendRefs:
        - name: mon-app
          port: 8080
      sessionPersistence:
        sessionName: mon_app_sticky
        type: Cookie
        absoluteTimeout: 48h
        cookieConfig:
          lifetimeType: Permanent

Il faut donc installer les CRDs du canal experimental, et accepter que ces champs puissent encore évoluer. C'est un compromis que nous avons fait en connaissance de cause.

Installer sans se tirer une balle dans le pied

Tout est déployé en GitOps avec Argo CD. Nous avons séparé l'installation en trois applications distinctes :

les CRDs (Gateway API et Envoy Gateway)
le contrôleur Envoy Gateway
les objets propres au cluster : GatewayClass, Gateway, EnvoyProxy

La raison est simple : si le contrôleur et les objets qui dépendent des CRDs arrivent dans la même synchronisation, Argo CD peut tenter de créer une Gateway avant que son type existe. Séparer les applications (et ajouter des sync waves) garantit l'ordre.

Ce découpage a un autre intérêt, plus important à mes yeux : il suit le modèle de rôles de Gateway API. Là où une ressource Ingress mélangeait tout (le choix du contrôleur, le TLS, le routage et des annotations propres à nginx), Gateway API sépare les responsabilités :

la GatewayClass et l'EnvoyProxy : comment le trafic entre dans le cluster, c'est l'affaire de la plateforme
la Gateway : les points d'entrée, les listeners, le TLS, toujours côté plateforme
les HTTPRoute et les policies attachées à une route : le routage d'une application, qui appartient à l'équipe qui la déploie

Dans une logique plateforme, c'est exactement ce que nous cherchions. L'équipe infra possède les trois applications Argo CD ci-dessus. Les équipes produit gardent la main sur les couches hautes : leurs HTTPRoute, leurs timeouts, leur authentification, versionnés avec leur application. Elles n'ont pas besoin de toucher à la Gateway pour publier un nouveau chemin, et une erreur dans une route n'impacte pas les autres.

La frontière se règle sur la Gateway elle-même, avec allowedRoutes :

listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

from: All laisse n'importe quel namespace s'attacher. Pour être plus strict, from: Selector limite l'attachement aux namespaces portant un label choisi par la plateforme.

Exposer Envoy : un NodePort derrière Traefik

Nos clusters avaient déjà un point d'entrée : un load balancer, puis des Traefik sur des VM, hors des clusters, qui terminent le TLS et répartissent le trafic vers les nœuds.

Nous l'avons gardé tel quel. Envoy est simplement exposé en NodePort : le même port est ouvert sur chaque nœud, et Traefik a tous les nœuds comme backends.

C'est le modèle standard pour Kubernetes hors cloud. C'est d'ailleurs ce que font les load balancers des clouds : un NLB AWS en mode instance ne fait rien d'autre que viser un NodePort sur chaque nœud.

Avec Envoy Gateway, le service est piloté par un objet EnvoyProxy, référencé par la GatewayClass :

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: envoy-gateway-nodeport
  namespace: edge
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        patch:
          type: StrategicMerge
          value:
            spec:
              type: NodePort
              externalTrafficPolicy: Cluster
              ports:
                - name: http
                  port: 80
                  targetPort: 10080
                  nodePort: 30080

externalTrafficPolicy: Cluster est un choix délibéré. Avec cette valeur, n'importe quel nœud accepte la connexion et la renvoie vers un pod Envoy, éventuellement sur un autre nœud. On paie un saut réseau de plus, mais chaque nœud est un backend valide pour Traefik, même s'il n'héberge aucun Envoy. Un health check simple suffit.

Avec Local, on économiserait ce saut, mais un nœud sans pod Envoy refuserait le trafic. Traefik devrait alors savoir, à tout moment, quels nœuds hébergent un Envoy.

Retrouver l'IP du client

Deux proxys en cascade entrainent une conséquence directe : Envoy ne voit plus l'IP du client, mais celle de Traefik. Pour retrouver la vraie IP, il faut lui dire de faire confiance à un saut dans X-Forwarded-For :

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  name: envoy-gateway-trusted-proxy-headers
  namespace: edge
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: envoy-gateway
  clientIPDetection:
    xForwardedFor:
      numTrustedHops: 1

Sans ça, tous vos logs d'accès, vos rate limits et vos listes d'IP autorisées voient la même adresse. Et avec une valeur trop grande, n'importe quel client peut forger son IP en ajoutant un en-tête X-Forwarded-For.

Mais ce réglage repose sur une hypothèse forte : seul Traefik parle à Envoy. Si un client peut joindre Envoy directement, c'est lui qui écrit le dernier X-Forwarded-For, et Envoy le croira sur parole.

Ne laisser entrer que Traefik

Or un NodePort écoute sur toutes les interfaces de tous les nœuds. Sans filtrage, n'importe quelle machine du réseau peut joindre Envoy sur le port 30080, en contournant tout ce que fait Traefik (TLS, rate limiting, listes d'IP), et en choisissant l'IP qu'elle veut faire croire.

Le premier réflexe serait une NetworkPolicy sur les pods Envoy, qui n'accepte que les IP des Traefik. Avec externalTrafficPolicy: Cluster, ça ne fonctionne pas : quand un nœud renvoie la connexion vers un Envoy situé sur un autre nœud, il fait du SNAT. Le pod voit arriver l'IP du nœud, plus celle de Traefik.

Il faut donc filtrer avant la répartition, sur l'hôte lui-même. Cilium sait le faire avec son firewall hôte (hostFirewall.enabled=true) et une policy qui sélectionne des nœuds plutôt que des pods :

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: host-nodeport-envoy
spec:
  nodeSelector: {}
  ingress:
    - fromCIDR:
        - 10.0.0.15/32
        - 10.0.1.15/32
      toPorts:
        - ports:
            - port: "30080"
              protocol: TCP

Attention au piège : dès qu'une policy hôte sélectionne un nœud, celui-ci passe en refus par défaut pour tout le trafic entrant. SSH, API server, kubelet, etcd, tunnel VXLAN, health checks de Cilium : tout ce qui n'est pas explicitement autorisé est coupé.

Nous avons donc écrit la policy complète (le trafic intra-cluster via fromEntities: [cluster, remote-node, health], puis les ports d'administration), et l'avons d'abord déployée avec policyAuditMode activé.

Dans ce mode, Cilium laisse tout passer mais journalise ce qu'il aurait bloqué. Quelques jours de Hubble plus tard, plus rien d'inattendu n'apparaissait, et nous avons activé l'application réelle.

Au passage, on corrige aussi la faiblesse du X-Forwarded-For vue plus haut : seuls les Traefik peuvent désormais joindre Envoy, donc le dernier saut est toujours un proxy de confiance.

Basculer sans big bang

Pour chaque cluster, nous avons fait tourner nginx et Envoy en parallèle. Les applications étaient d'abord exposées via Envoy sur une URL différente, testées, puis nous avons basculé le vrai nom et retiré l'ingress.

C'est plus long, mais c'est ce qui nous a permis de découvrir les problèmes qui suivent pendant notre QA, avant qu'ils n'atteignent les utilisateurs.

Les uploads

C'est le premier point sur lequel nous sommes tombés pendant la QA : sur l'URL de test servie par Envoy, l'envoi de gros fichiers échouait, alors qu'il passait sans problème par nginx.

Côté nginx, nous avions proxy-body-size: 0, c'est-à-dire pas de limite. Et nginx a une particularité : quand le corps d'une requête dépasse son buffer mémoire, il l'écrit dans un fichier temporaire sur disque. Il peut donc absorber un fichier de plusieurs gigaoctets sans exploser en mémoire.

Envoy a une philosophie différente. Il est pensé pour streamer : il fait passer les octets au fil de l'eau et applique une limite de buffer par connexion (32 Ko par défaut) pour gérer le contrôle de flux. Tant que rien n'a besoin du corps complet, ça marche très bien.

Concrètement, quand le backend lit moins vite que le client n'envoie, Envoy accumule jusqu'à cette limite, puis arrête de lire la socket du client le temps que ça se vide. Le client ralentit, la mémoire reste stable. Un fichier de 5 Go traverse Envoy sans jamais occuper plus de quelques dizaines de kilo-octets.

Le problème apparaît dès qu'un élément de la chaîne a besoin du corps complet avant de le laisser passer. Là, la limite n'est plus un seuil de contrôle de flux, c'est un plafond. Au-delà, la requête est rejetée avec un 413 Payload Too Large.

Restait à trouver qui, dans notre chaîne, réclamait le corps complet.

Le coupable : notre WAF

Nous avions profité de la migration pour ajouter un WAF, Coraza, chargé dans Envoy sous forme de module Wasm, avec les règles OWASP CRS. Il était en mode DetectionOnly : il journalise ce qu'il aurait bloqué, mais ne bloque rien. Du moins, c'est ce que nous pensions.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: coraza-waf
  namespace: edge
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: envoy-gateway
  wasm:
    - name: coraza-waf
      rootID: waf
      failOpen: true
      code:
        type: Image
        image:
          url: ghcr.io/corazawaf/coraza-proxy-wasm:0.6.0
      config:
        default_directives: default
        directives_map:
          default:
            - Include @recommended-conf
            - Include @crs-setup-conf
            - Include @owasp_crs/*.conf
            - SecRuleEngine DetectionOnly
            - SecRequestBodyAccess On

Pour inspecter le corps d'une requête (chercher une injection SQL dans un formulaire, par exemple), un WAF doit l'avoir en entier. C'est ce que fait SecRequestBodyAccess On : Coraza demande à Envoy de bufferiser le corps avant de le transmettre au backend. C'est exactement le cas qui transforme la limite de buffer en plafond.

Et il y a un deuxième étage. La configuration recommandée de Coraza fixe SecRequestBodyInMemoryLimit à 128 Kio, avec SecRequestBodyLimitAction Reject. Au-delà de 128 Kio, la requête est rejetée.

Le détail qui tue : ce rejet ne passe pas par le moteur de règles. Il s'applique donc même en DetectionOnly. Notre WAF « en observation » bloquait tous les uploads de plus de 128 Kio.

La mauvaise réponse

Le réflexion instinctif serait de monter la limite de buffer d'Envoy, dans la ClientTrafficPolicy :

spec:
  connection:
    bufferLimit: 1Gi

Ça fonctionne, en partie : Envoy accepte de garder de gros corps en mémoire. Mais c'est une très mauvaise idée.

Cette limite s'applique par connexion, à toutes les routes du cluster. Quelques uploads simultanés de gros fichiers, ou un client rapide face à un backend lent, et un pod Envoy peut consommer plusieurs gigaoctets avant d'être tué pour dépassement de mémoire. Or tout le trafic du cluster passe par ces pods. Pour comparaison, le guide d'Envoy pour un proxy exposé en bordure de réseau recommande de rester à 32 Ko.

Et pourquoi ne pas faire comme nginx, en écrivant sur disque ? Envoy a bien un filtre pour ça (file_system_buffer), mais sa documentation le dit explicitement : travail en cours, pas destiné à la production. Envoy Gateway ne l'expose d'ailleurs pas.

La bonne réponse

Le problème n'était pas la taille du buffer, mais le fait que quelqu'un réclame le corps complet. Il suffit de dire à Coraza d'inspecter le début du corps puis de laisser passer le reste :

- SecRequestBodyAccess On
- SecRequestBodyLimitAction ProcessPartial

Avec ProcessPartial, Coraza analyse les 128 premiers Kio et laisse filer la suite sans la retenir. Les requêtes classiques (formulaires, JSON d'API) restent inspectées en entier, et les uploads repassent en streaming.

Ce compromis a un prix, et il faut le dire : un attaquant peut remplir les 128 premiers Kio avec du contenu anodin, puis placer sa charge après. Coraza inspecte le début, ne voit rien, et laisse passer le reste sans l'avoir lu. C'est un contournement de WAF bien connu.

En DetectionOnly, c'est acceptable : le WAF ne bloque rien de toute façon, il nous sert à observer. Mais ce n'est pas la configuration à garder au moment de passer en blocage.

La cible est de ne pas traiter toutes les routes de la même façon. Les injections SQL, XSS ou de commandes passent par des champs de formulaire ou du JSON, qui font quelques kilo-octets. Un corps de plusieurs centaines de kilo-octets sur une route qui n'attend pas de fichier est déjà suspect en soi. D'où :

une inspection stricte par défaut (Reject), avec une EnvoyExtensionPolicy attachée à la Gateway
une EnvoyExtensionPolicy dédiée, attachée aux seules HTTPRoute d'upload, en ProcessPartial
sur ces routes d'upload, une protection portée par l'application : type de fichier, taille maximale, analyse antivirus

La limite de buffer d'Envoy est redescendue à une valeur raisonnable, et la mémoire des pods Envoy ne dépend plus de la taille des fichiers envoyés.

La leçon dépasse le WAF. Avec Envoy, quand un gros corps de requête pose problème, la bonne question n'est pas « quelle limite monter ? », mais « quel filtre a besoin du corps complet, et en a-t-il vraiment besoin ? ».

Un ext_authz qui transmet le corps au service d'autorisation, un filtre Lua ou un autre module Wasm peuvent produire exactement le même effet.

Les timeouts qui ne veulent pas dire la même chose

Deuxième surprise, sur des téléchargements longs et des traitements côté serveur qui prennent plusieurs minutes.

Chez nginx, proxy_read_timeout est un délai entre deux lectures : tant que le backend envoie des octets régulièrement, la connexion vit.

Chez Envoy, le timeout de route est une durée totale : le temps laissé au backend pour envoyer la réponse complète, à partir du moment où la requête a été entièrement reçue. Et sa valeur par défaut est de 15 secondes.

Un export qui met deux minutes à se générer ? Coupé à 15 secondes, avec un 504 et un upstream request timeout.

La Gateway API permet de le régler par règle de route :

rules:
  - backendRefs:
      - name: mon-app
        port: 8080
    timeouts:
      request: 5m
      backendRequest: 5m

Plutôt que de monter la valeur globalement, nous l'avons fait route par route, là où le besoin était réel. Un timeout long partout, c'est aussi des connexions qui s'accumulent quand un backend est lent.

Websockets et protocoles maison

Avec nginx, les websockets fonctionnaient avec deux annotations de timeout. Avec Envoy, un upgrade de connexion n'est accepté que s'il est explicitement autorisé.

Pour une application de bureau à distance en HTML5, qui garde une connexion websocket ouverte pendant toute la session :

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: remote-desktop-session
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: remote-desktop
  httpUpgrade:
    - type: websocket
  timeout:
    http:
      requestTimeout: 0s
      connectionIdleTimeout: 3600s

requestTimeout: 0s désactive le timeout total (une session peut durer des heures), et connectionIdleTimeout coupe les sessions réellement inactives.

Le cas le plus intéressant a été Headscale, l'implémentation open source du serveur de contrôle Tailscale. Le client Tailscale ne fait pas un upgrade websocket : il demande un upgrade vers son propre protocole, tailscale-control-protocol, pour établir un canal chiffré avec le protocole Noise.

Nginx laissait passer n'importe quel en-tête Upgrade. Envoy le refuse tant qu'on ne l'a pas déclaré :

spec:
  httpUpgrade:
    - type: websocket
    - type: tailscale-control-protocol

Le symptôme, lui, n'avait rien d'évident : des clients incapables de s'enregistrer, et rien de parlant côté application. C'est typiquement le genre de comportement implicite qu'on ne soupçonne pas avant de changer de proxy.

Adieu oauth2-proxy

C'est la partie qui m'a fait le plus plaisir.

Envoy sait faire de l'OIDC nativement. L'authentification se déclare dans une SecurityPolicy attachée à une route :

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: mon-app-oidc
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: mon-app
  oidc:
    provider:
      issuer: "https://login.microsoftonline.com/${tenant_id}/v2.0"
    clientID: "${client_id}"
    clientSecret:
      name: mon-app-oidc
    scopes:
      - openid
      - email
      - profile
    cookieConfig:
      sameSite: Lax

Par rapport à l'approche de mon article de 2023, plusieurs choses changent :

plus de service tiers à déployer, superviser et mettre à jour
l'authentification est déclarée par route, et non par une chaîne d'annotations qui pointe vers un autre service
chaque application a son propre client OIDC, donc ses propres droits. Avec oauth2-proxy, la portée du cookie (*.recette.bar.fr dans l'exemple de l'époque) donnait accès à tous les services du domaine d'un coup

Un piège, quand même, et pas des moindres.

Par défaut, Envoy chiffre les jetons qu'il stocke dans les cookies. Or un navigateur limite un cookie à environ 4096 octets (nom et valeur compris).

Chez certains utilisateurs, dont le jeton d'accès contient beaucoup de claims (des groupes, par exemple), le cookie chiffré dépasse cette taille. Le navigateur l'ignore silencieusement, et l'utilisateur tourne en boucle sur la mire de login.

Seuls certains comptes étaient touchés, ce qui rend le diagnostic assez pénible.

C'est une limite structurelle de l'implémentation OIDC d'Envoy Gateway : elle ne connaît que le cookie comme mécanisme de session. oauth2-proxy, lui, propose plusieurs backends de stockage, dont Redis : le cookie ne contient plus alors qu'un identifiant de session, et le jeton complet reste côté serveur. La taille du jeton devient indolore, au prix d'un service avec état à opérer, celui-là même que nous cherchions à retirer.

Pour des services internes, nous avons désactivé le chiffrement des jetons (les cookies restent HttpOnly) :

  oidc:
    refreshToken: false
    disableTokenEncryption: true

C'est un compromis. Sur un service exposé publiquement, je préférerais réduire la taille du jeton côté fournisseur d'identité (moins de claims) plutôt que de désactiver le chiffrement.

EnvoyPatchPolicy : la porte de sortie à manier avec précaution

Quand une policy ne couvre pas un besoin, Envoy Gateway propose une échappatoire : EnvoyPatchPolicy. Elle permet d'appliquer un JSON Patch directement sur la configuration xDS générée pour Envoy.

C'est puissant, et c'est exactement le problème.

Les noms des ressources xDS sont générés par le contrôleur, et peuvent changer d'une version à l'autre. Un patch écrit à la main s'appuie sur une structure que personne ne garantit. Et surtout, il s'applique après toutes les autres policies.

Nous en avons fait l'expérience : un patch de type replace sur les routes d'un listener a écrasé la configuration générée par une SecurityPolicy OIDC. Rien dans les objets Kubernetes ne le laissait voir : la SecurityPolicy était acceptée, son statut était correct, mais la configuration réellement envoyée à Envoy ne la contenait plus.

Ma règle aujourd'hui :

EnvoyPatchPolicy seulement en dernier recours, avec un commentaire qui explique pourquoi aucune policy typée ne convient
le moins de replace possible, des add ciblés
vérifier la configuration réelle avec egctl config envoy-proxy après chaque montée de version d'Envoy Gateway

Conclusion

Techniquement, remplacer ingress-nginx par Envoy Gateway n'a rien de compliqué. Les manifests sont plus verbeux, mais plus lisibles et validés par le schéma.

Le vrai travail, c'est de faire l'inventaire de tout ce que nginx faisait implicitement : bufferiser sur disque, laisser passer n'importe quel upgrade, compter les timeouts entre deux lectures plutôt que sur la durée totale. Aucun de ces comportements n'apparaissait dans nos annotations, et pourtant nos applications en dépendaient.

Si vous préparez la même migration, mon conseil : faites tourner les deux en parallèle, et testez en priorité les gros uploads, les téléchargements longs, les websockets et l'authentification avec vos comptes aux jetons les plus lourds.

From ingress-nginx to Envoy Gateway

2026-09-30T00:00:00Z

Three years ago, I explained how to protect services behind your ingress with OAuth2 Proxy.

Three annotations on an nginx ingress, a proxy installed once in the cluster, and you were done.

Today, we removed ingress-nginx from every one of our clusters. And oauth2-proxy with it.

On paper, migrating off an ingress controller is "just" rewriting manifests. In practice, it mostly means discovering everything nginx was doing for us without being asked.

This article tells that story, and above all what broke.

Why migrate?

The most obvious reason: ingress-nginx isn't maintained anymore. The project moved to minimal maintenance and then stopped in March 2026. Keeping an internet-facing component without security fixes isn't an option.

But it's also a chance to fix an older problem.

Kubernetes' Ingress object is quite poor. It can route a host and a path to a service, and that's about it. Everything else (request size limits, timeouts, authentication, websockets, sticky sessions…) goes through annotations specific to each controller:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/affinity: cookie
    nginx.ingress.kubernetes.io/auth-url: https://url-du-proxy/oauth2/auth

These annotations became a de facto API: untyped, unvalidated strings that mean nothing to any other controller.

Gateway API fixes this with a model split across several objects, each owned by a different role:

GatewayClass: which implementation (here, Envoy Gateway), owned by the platform team
Gateway: an entry point, its listeners and ports
HTTPRoute: routing for an application, owned by the team that deploys it

And for anything the standard doesn't cover yet, Envoy Gateway offers typed policies that attach to a Gateway or an HTTPRoute. We'll run into several of them.

Why Envoy Gateway and not Cilium?

Our clusters already run Cilium as the CNI, and Cilium implements the Gateway API. The choice seemed obvious.

It wasn't, for a very concrete reason: sticky sessions.

One of our applications is stateful on the server side. A user must always land on the same pod, otherwise they lose their session. With nginx, that was the affinity: cookie annotation.

In Gateway API, this feature exists (sessionPersistence, GEP-1619), but only in the experimental CRD channel. At the time we made the choice, Cilium didn't implement it, unlike Envoy Gateway.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
    - name: envoy-gateway
      namespace: edge
  hostnames:
    - my-app.example.com
  rules:
    - backendRefs:
        - name: my-app
          port: 8080
      sessionPersistence:
        sessionName: my_app_sticky
        type: Cookie
        absoluteTimeout: 48h
        cookieConfig:
          lifetimeType: Permanent

So you need to install the experimental channel CRDs, and accept that these fields may still evolve. That's a trade-off we made knowingly.

Installing without shooting ourselves in the foot

Everything is deployed as GitOps with Argo CD. We split the install into three separate applications:

the CRDs (Gateway API and Envoy Gateway)
the Envoy Gateway controller
the cluster-specific objects: GatewayClass, Gateway, EnvoyProxy

The reason is simple: if the controller and the objects that depend on the CRDs land in the same sync, Argo CD can try to create a Gateway before its type exists. Splitting the applications (and adding sync waves) guarantees the order.

This split has another benefit, more important to me: it follows Gateway API's role model. Where a single Ingress resource mixed everything together (controller choice, TLS, routing, and nginx-specific annotations), Gateway API separates concerns:

GatewayClass and EnvoyProxy: how traffic enters the cluster, the platform's job
Gateway: entry points, listeners, TLS, still on the platform side
HTTPRoute and the policies attached to a route: an application's routing, owned by the team deploying it

Within a platform mindset, that's exactly what we were after. The infra team owns the three Argo CD applications above. Product teams keep control of the upper layers: their HTTPRoute, their timeouts, their authentication, versioned alongside their application. They don't need to touch the Gateway to publish a new path, and a mistake in one route doesn't affect others.

The boundary is set on the Gateway itself, with allowedRoutes:

listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

from: All lets any namespace attach. To be stricter, from: Selector restricts attachment to namespaces carrying a label chosen by the platform.

Exposing Envoy: a NodePort behind Traefik

Our clusters already had an entry point: a load balancer, then Traefik instances on VMs, outside the clusters, terminating TLS and spreading traffic across nodes.

We kept it as is. Envoy is simply exposed as NodePort: the same port is opened on every node, and Traefik treats all nodes as backends.

This is the standard model for Kubernetes outside the cloud. It's actually what cloud load balancers do too: an AWS NLB in instance mode does nothing more than target a NodePort on each node.

With Envoy Gateway, the service is driven by an EnvoyProxy object, referenced by the GatewayClass:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: envoy-gateway-nodeport
  namespace: edge
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        patch:
          type: StrategicMerge
          value:
            spec:
              type: NodePort
              externalTrafficPolicy: Cluster
              ports:
                - name: http
                  port: 80
                  targetPort: 10080
                  nodePort: 30080

externalTrafficPolicy: Cluster is a deliberate choice. With this value, any node accepts the connection and forwards it to an Envoy pod, possibly on another node. You pay one extra network hop, but every node is a valid backend for Traefik, even if it hosts no Envoy pod. A simple health check is enough.

With Local, you'd save that hop, but a node without an Envoy pod would refuse traffic. Traefik would then need to know, at all times, which nodes host an Envoy pod.

Recovering the client IP

Two proxies in a row have a direct consequence: Envoy no longer sees the client's IP, only Traefik's. To recover the real IP, you need to tell it to trust one hop in X-Forwarded-For:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  name: envoy-gateway-trusted-proxy-headers
  namespace: edge
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: envoy-gateway
  clientIPDetection:
    xForwardedFor:
      numTrustedHops: 1

Without this, all your access logs, rate limits and IP allowlists see the same address. And with a value set too high, any client can forge its IP by adding an X-Forwarded-For header.

But this setting relies on a strong assumption: only Traefik talks to Envoy. If a client can reach Envoy directly, it writes the last X-Forwarded-For, and Envoy will take its word for it.

Letting only Traefik in

A NodePort listens on every interface of every node. Without filtering, any machine on the network can reach Envoy on port 30080, bypassing everything Traefik does (TLS, rate limiting, IP allowlists), and choosing whatever IP it wants to claim.

The first instinct would be a NetworkPolicy on the Envoy pods, accepting only Traefik's IPs. With externalTrafficPolicy: Cluster, that doesn't work: when a node forwards the connection to an Envoy pod on another node, it performs SNAT. The pod only sees the node's IP, not Traefik's.

So filtering has to happen before load balancing, on the host itself. Cilium can do this with its host firewall (hostFirewall.enabled=true) and a policy that selects nodes instead of pods:

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: host-nodeport-envoy
spec:
  nodeSelector: {}
  ingress:
    - fromCIDR:
        - 10.0.0.15/32
        - 10.0.1.15/32
      toPorts:
        - ports:
            - port: "30080"
              protocol: TCP

Watch out for the trap: as soon as a host policy selects a node, that node switches to default-deny for all incoming traffic. SSH, the API server, kubelet, etcd, the VXLAN tunnel, Cilium's own health checks: anything not explicitly allowed gets cut off.

So we wrote the full policy (intra-cluster traffic via fromEntities: [cluster, remote-node, health], then the admin ports), and first deployed it with policyAuditMode enabled.

In that mode, Cilium lets everything through but logs what it would have blocked. A few days of Hubble later, nothing unexpected showed up, and we switched to real enforcement.

Along the way, this also fixes the X-Forwarded-For weakness seen above: only Traefik can now reach Envoy, so the last hop is always a trusted proxy.

Switching without a big bang

For each cluster, we ran nginx and Envoy side by side. Applications were first exposed through Envoy on a different URL, tested, then we switched the real hostname over and removed the ingress.

It takes longer, but it's exactly what let us discover the following issues during QA, before they reached users.

Uploads

This is the first thing we hit during QA: on the test URL served by Envoy, uploading large files failed, while it went through fine via nginx.

On nginx's side, we had proxy-body-size: 0, meaning no limit. And nginx has a particularity: when a request body exceeds its memory buffer, it writes it to a temporary file on disk. So it can absorb a multi-gigabyte file without blowing up memory.

Envoy has a different philosophy. It's built to stream: bytes flow through as they arrive, and it applies a per-connection buffer limit (32 KB by default) for flow control. As long as nothing needs the full body, it works great.

Concretely, when the backend reads slower than the client sends, Envoy buffers up to that limit, then stops reading the client's socket until it drains. The client slows down, memory stays stable. A 5 GB file passes through Envoy without ever occupying more than a few tens of kilobytes.

The problem shows up as soon as something in the chain needs the full body before letting it through. At that point, the limit stops being a flow-control threshold and becomes a hard cap. Beyond it, the request gets rejected with a 413 Payload Too Large.

We had to find out what, in our chain, was requiring the full body.

The culprit: our WAF

We had used the migration as an opportunity to add a WAF, Coraza, loaded into Envoy as a Wasm module, with the OWASP CRS rules. It was in DetectionOnly mode: it logs what it would have blocked, but blocks nothing. Or so we thought.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: coraza-waf
  namespace: edge
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: envoy-gateway
  wasm:
    - name: coraza-waf
      rootID: waf
      failOpen: true
      code:
        type: Image
        image:
          url: ghcr.io/corazawaf/coraza-proxy-wasm:0.6.0
      config:
        default_directives: default
        directives_map:
          default:
            - Include @recommended-conf
            - Include @crs-setup-conf
            - Include @owasp_crs/*.conf
            - SecRuleEngine DetectionOnly
            - SecRequestBodyAccess On

To inspect a request body (looking for a SQL injection in a form, for example), a WAF needs it in full. That's what SecRequestBodyAccess On does: Coraza asks Envoy to buffer the body before passing it on to the backend. That's exactly the case that turns the buffer limit into a hard cap.

And there's a second layer. Coraza's recommended configuration sets SecRequestBodyInMemoryLimit to 128 KiB, with SecRequestBodyLimitAction Reject. Beyond 128 KiB, the request is rejected.

The killer detail: this rejection doesn't go through the rule engine. So it applies even in DetectionOnly. Our "observation only" WAF was blocking every upload over 128 KiB.

The wrong answer

The instinctive move would be to raise Envoy's buffer limit, in the ClientTrafficPolicy:

spec:
  connection:
    bufferLimit: 1Gi

It works, partially: Envoy accepts keeping large bodies in memory. But it's a very bad idea.

This limit applies per connection, across every route in the cluster. A few concurrent large uploads, or a fast client facing a slow backend, and an Envoy pod can consume several gigabytes before getting OOM-killed. And all of the cluster's traffic flows through these pods. For comparison, Envoy's own guidance for an edge-facing proxy recommends staying around 32 KB.

And why not do like nginx and write to disk? Envoy does have a filter for that (file_system_buffer), but its documentation explicitly says: work in progress, not meant for production. Envoy Gateway doesn't even expose it.

The right answer

The problem wasn't the buffer size, it was that something demanded the full body. The fix is to tell Coraza to inspect the start of the body and let the rest stream through:

- SecRequestBodyAccess On
- SecRequestBodyLimitAction ProcessPartial

With ProcessPartial, Coraza analyzes the first 128 KiB and lets the rest flow without holding it back. Regular requests (forms, API JSON) still get inspected in full, and uploads go back to streaming.

This trade-off has a cost, and it's worth naming: an attacker can fill the first 128 KiB with harmless content, then place their payload after it. Coraza inspects the start, sees nothing, and lets the rest through without ever reading it. This is a well-known WAF bypass.

In DetectionOnly, it's acceptable: the WAF blocks nothing anyway, it's there for observation. But it's not the configuration to keep once you switch to blocking mode.

The goal is to not treat every route the same way. SQL, XSS or command injections go through form fields or JSON, which are a few kilobytes at most. A body of several hundred kilobytes on a route that isn't expecting a file is already suspicious on its own. Hence:

strict inspection by default (Reject), via an EnvoyExtensionPolicy attached to the Gateway
a dedicated EnvoyExtensionPolicy, attached only to upload HTTPRoutes, using ProcessPartial
on those upload routes, protection carried by the application itself: file type, maximum size, antivirus scanning

Envoy's buffer limit went back down to a sane value, and Envoy pod memory no longer depends on uploaded file sizes.

The lesson goes beyond the WAF. With Envoy, when a large request body causes trouble, the right question isn't "which limit should I raise?" but "which filter needs the full body, and does it really need it?".

An ext_authz filter forwarding the body to an authorization service, a Lua filter, or another Wasm module can all produce the exact same effect.

Timeouts that don't mean the same thing

Second surprise, on long downloads and server-side processing that takes several minutes.

With nginx, proxy_read_timeout is a delay between two reads: as long as the backend keeps sending bytes regularly, the connection stays alive.

With Envoy, the route timeout is a total duration: the time given to the backend to send the complete response, starting from when the request was fully received. And its default value is 15 seconds.

An export that takes two minutes to generate? Cut off at 15 seconds, with a 504 and an upstream request timeout.

Gateway API lets you configure this per route rule:

rules:
  - backendRefs:
      - name: my-app
        port: 8080
    timeouts:
      request: 5m
      backendRequest: 5m

Rather than raising the value globally, we did it route by route, only where the need was real. A long timeout everywhere also means connections piling up when a backend is slow.

Websockets and custom protocols

With nginx, websockets worked with two timeout annotations. With Envoy, a connection upgrade is only accepted if it's explicitly allowed.

For an HTML5 remote desktop application that keeps a websocket connection open for the whole session:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: remote-desktop-session
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: remote-desktop
  httpUpgrade:
    - type: websocket
  timeout:
    http:
      requestTimeout: 0s
      connectionIdleTimeout: 3600s

requestTimeout: 0s disables the total timeout (a session can last hours), and connectionIdleTimeout cuts off genuinely idle sessions.

The most interesting case was Headscale, the open source implementation of the Tailscale control server. The Tailscale client doesn't perform a websocket upgrade: it requests an upgrade to its own protocol, tailscale-control-protocol, to establish an encrypted channel using the Noise protocol.

Nginx let through any Upgrade header. Envoy refuses it until it's been declared:

spec:
  httpUpgrade:
    - type: websocket
    - type: tailscale-control-protocol

The symptom itself wasn't obvious at all: clients unable to register, and nothing informative on the application side. This is exactly the kind of implicit behavior you don't suspect until you switch proxies.

Goodbye oauth2-proxy

This is the part I enjoyed the most.

Envoy handles OIDC natively. Authentication is declared in a SecurityPolicy attached to a route:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: my-app-oidc
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: my-app
  oidc:
    provider:
      issuer: "https://login.microsoftonline.com/${tenant_id}/v2.0"
    clientID: "${client_id}"
    clientSecret:
      name: my-app-oidc
    scopes:
      - openid
      - email
      - profile
    cookieConfig:
      sameSite: Lax

Compared to the approach in my 2023 article, several things change:

no more third-party service to deploy, monitor and keep updated
authentication is declared per route, instead of a chain of annotations pointing to another service
each application has its own OIDC client, so its own permissions. With oauth2-proxy, the cookie's scope (*.staging.example.com in the old example) granted access to every service on the domain at once

There is a trap though, and not a small one.

By default, Envoy encrypts the tokens it stores in cookies. But browsers cap a cookie at roughly 4096 bytes (name and value combined).

For some users, whose access token carries a lot of claims (group memberships, for instance), the encrypted cookie exceeds that size. The browser silently drops it, and the user loops back to the login screen forever.

Only certain accounts were affected, which made the diagnosis fairly painful.

This is a structural limitation of Envoy Gateway's OIDC implementation: it only knows cookies as a session mechanism. oauth2-proxy, on the other hand, supports several storage backends, including Redis: the cookie then only holds a session identifier, and the full token stays server-side. Token size becomes a non-issue, at the cost of running a stateful service, the very thing we were trying to remove.

For internal services, we disabled token encryption (cookies stay HttpOnly):

  oidc:
    refreshToken: false
    disableTokenEncryption: true

That's a trade-off. On a publicly exposed service, I'd rather reduce the token size on the identity provider side (fewer claims) than disable encryption.

EnvoyPatchPolicy: an escape hatch to use carefully

When a policy doesn't cover a need, Envoy Gateway offers an escape hatch: EnvoyPatchPolicy. It lets you apply a JSON Patch directly to the xDS configuration generated for Envoy.

It's powerful, and that's exactly the problem.

xDS resource names are generated by the controller, and can change between versions. A hand-written patch relies on a structure nobody guarantees. And crucially, it applies after every other policy.

We learned this the hard way: a replace-type patch on a listener's routes overwrote the configuration generated by an OIDC SecurityPolicy. Nothing in the Kubernetes objects showed it: the SecurityPolicy was accepted, its status was correct, but the configuration actually sent to Envoy no longer contained it.

My rule today:

EnvoyPatchPolicy only as a last resort, with a comment explaining why no typed policy fits
as few replace operations as possible, prefer targeted add
verify the actual running configuration with egctl config envoy-proxy after every Envoy Gateway version bump

Conclusion

Technically, replacing ingress-nginx with Envoy Gateway isn't complicated. The manifests are more verbose, but more readable and schema-validated.

The real work is taking inventory of everything nginx was doing implicitly: buffering to disk, letting through any upgrade header, counting timeouts between reads rather than over total duration. None of this behavior showed up in our annotations, and yet our applications depended on it.

If you're planning the same migration, my advice: run both side by side, and prioritize testing large uploads, long downloads, websockets, and authentication with your accounts carrying the heaviest tokens.

Utiliser IRSA dans un cluster Kubernetes hors EKS

2025-06-22T00:00:00Z

AWS propose un système à la fois puissant et sécurisé pour donner des autorisations à nos pods Kubernetes sans avoir à manipuler (et assurer la rotation) de clés ou token, il s’agit d’IRSA.

À quoi ça sert ?

Imaginez que votre application ait besoin d’accéder à un bucket S3. Vous allez probablement créer un rôle qui aura les droits suffisants pour faire le nécessaire : lire, écrire…

Pour utiliser ce rôle vous pouvez créer des identifiants (key id et key secret) et les injecter dans votre pod sous forme de secrets.

Mais AWS propose un mécanisme plus élégant et sécurisé via IRSA (IAM role for Service Account).

Service account

Lorsque nous crééons un pod dans notre cluster Kubernetes, celui ci hérite (ou pas selon notre configuration) d’un token, celui du ServiceAccount configuré par notre pod.

Ce ServiceAccount donne une identité à notre pod et permet d’y associer des permissions de type RBAC (Role Based Access Control).

L’authentification du pod se fait au travers d’un jeton JWT, qui est stocké par défaut dans /var/run/secrets/kubernetes.io/serviceaccount/token.

Si on décode un jeton, par exemple celui d’un pod qui fait tourner ce site :

jq -R '.' /var/run/secrets/kubernetes.io/serviceaccount/token  | jq 'split(".")|{header: .[0]|@base64d|fromjson, payload: .[1]|@base64d|fromjson}'

on voit bien le contenu de notre JWT :

{
  "header": {
    "alg": "RS256",
    "kid": "Z_ktNvbbBECOxLclHC46p5cMlFTGxzQVtfD50S41Ld8"
  },
  "payload": {
    "aud": [
      "https://kubernetes.default.svc.cluster.local",
      "k3s"
    ],
    "exp": 1781121747,
    "iat": 1749585747,
    "iss": "https://kubernetes.default.svc.cluster.local",
    "jti": "f27e4a7b-b1c7-43a6-b327-6022edfb82fc",
    "kubernetes.io": {
      "namespace": "website",
      "node": {
        "name": "worker-3",
        "uid": "f3266943-2933-487d-9a35-e6a756a4b05e"
      },
      "pod": {
        "name": "website-b49bb9b7f-b45pc",
        "uid": "e399270b-526c-45b8-ac0a-141c85e7f2fe"
      },
      "serviceaccount": {
        "name": "default",
        "uid": "6c44f7d8-f28f-4ff0-a18d-eb1a6edb0966"
      },
      "warnafter": 1749589354
    },
    "nbf": 1749585747,
    "sub": "system:serviceaccount:website:default"
  }
}

Notre pod utilise le ServiceAccount default, dans le namespace website.

Si on fait la même chose pour un pod lambda qui tourne dans un cluster EKS:

{
  "header": {
    "alg": "RS256",
    "kid": "a715867f84eace896d9a43b605e29ba93b3d9f09"
  },
  "payload": {
    "aud": [
      "https://kubernetes.default.svc"
    ],
    "exp": 1782141601,
    "iat": 1750605601,
    "iss": "https://oidc.eks.ca-central-1.amazonaws.com/id/76DA39F82A5363AA579A40F5296B8E2C",
    "jti": "bae90f82-c1d0-489b-80a8-4460b2e39053",
    "kubernetes.io": {
      "namespace": "incredible",
      "node": {
        "name": "ip-10-0-3-214.ca-central-1.compute.internal",
        "uid": "cf60907d-369c-42fd-9e70-f642465de26a"
      },
      "pod": {
        "name": "incredible-client-6b647595dd-wxc6b",
        "uid": "a60b5efb-1d60-4e40-b350-664906952ddf"
      },
      "serviceaccount": {
        "name": "incredible-client",
        "uid": "6afe8c21-70bc-4787-8b2c-2a04750a4996"
      },
      "warnafter": 1750609208
    },
    "nbf": 1750605601,
    "sub": "system:serviceaccount:incredible:incredible-client"
  }
}

On a globalement la même chose, hormis pour la partie iss (issuer). En effet notre cluster dispose par défaut d’une URL OpenID Connect.

C’est l’URL de notre fournisseur d’identité (idp), propre à chaque cluster EKS. Nous ne pouvons pas directement voir comment cela fonctionne car c’est géré par le control plane de Kubernetes auquel nous n’avons pas accès.

Mais c’est sa responsabilité de fournir un token JWT valide.

Pour chacun des appels du pod à l’API server ce token va être repassé en bearer et validé par l’api server (signature, subject) afin de déterminer si le ServiceAccount a les permissions suivantes pour faire ce qu’il demande.

Attacher un rôle à un service account avec AWS

Imaginons que nous ayons créé un rôle s3-role dans AWS permettant d’accéder à notre bucket.

Nous pouvons, dans un contexte EKS, créer un ServiceAccount en l’annotant du rôle qu’il pourra endosser.

apiVersion: v1
automountServiceAccountToken: true
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/s3-role

Si un pod utilise ce ServiceAccount, il pourra automatiquement assumer le rôle IAM associé et accéder à notre bucket sans fournir explicitement de clés d’accès ou secret.

Derrière le rideau, EKS fournit au pod un token JWT signé, qu’il peut présenter à AWS STS pour obtenir des identifiants temporaires (access key, secret key, session token).

Attacher un rôle à un service account d’un autre compte AWS

La force du système réside dans le fait qu’il s’appuie sur des standards ouverts, notamment OpenID Connect (OIDC).

AWS permet de fédérer plusieurs fournisseurs d’identité (IdP), y compris de clusters EKS issus d’autres comptes AWS, via l’ajout de leurs URL OIDC.

Cette URL devient alors une source de confiance : AWS est capable de vérifier les tokens JWT émis par ce cluster et de permettre l’accès à ses services via des rôles IAM conditionnés au sub (subject) ou à d’autres claims du token.

Fédérer un cluster non AWS dans AWS

Après cette longue introduction, venant en aux faits. À partir du moment ou AWS s’appuie sur des standards je me suis mis en tête de fédérer un cluster non EKS dans mon tenant AWS.

Le but est de bénéficier du même mécanisme IRSA dans des clusters externes, ici avec un cluster k3s.

Dans mon cas cela me sert à « redescendre » des secrets gérés dans AWS secrets manager avec external secrets operator. Mais nous aurons l’occasion d’en reparler dans un autre article 😊.

Exposer la configuration

Pour fonctionner, OpenID Connect s'appuie sur un standard qui nécessite l'exposition d'informations de configuration sur un endpoint bien défini.

Cette approche permet à AWS (ou tout autre service) de découvrir automatiquement comment interagir avec notre fournisseur d'identité.

Le point de découverte OpenID Connect

Le standard OpenID Connect définit un endpoint de découverte situé à l'adresse :

https://url/.well-known/openid-configuration

Cette URL va exposer un fichier JSON de configuration qui décrit les capacités de notre fournisseur d'identité. Par exemple :

{
  "issuer": "https://url-de-mon-cluster.tld/",
  "jwks_uri": "https://url-de-mon-cluster.tld/keys.json",
  "authorization_endpoint": "urn:kubernetes:programmatic_authorization",
  "response_types_supported": [
      "id_token"
  ],
  "subject_types_supported": [
      "public"
  ],
  "id_token_signing_alg_values_supported": [
      "RS256"
  ],
  "claims_supported": [
      "sub",
      "iss"
  ]
}

issuer : L'URL qui identifie de manière unique notre fournisseur d'identité. C'est cette valeur qui sera utilisée dans le champ iss des tokens JWT émis par notre cluster.
jwks_uri : L'URL où AWS pourra récupérer les clés publiques utilisées pour vérifier la signature des tokens JWT.
authorization_endpoint : Ce champ est requis par la spécification OIDC, mais Kubernetes ne propose pas de login interactif. Nous utilisons donc une valeur symbolique (urn:kubernetes:programmatic_authorization) pour indiquer que l’authentification est entièrement non interactive (par jetons JWT générés automatiquement pour les pods).
id_token_signing_alg_values_supported : Les algorithmes de signature supportés (RS256 est l'algorithme standard recommandé).
claims_supported : Les claims (revendications) que notre fournisseur d'identité peut inclure dans les tokens.

AWS a besoin de ces informations pour :

Vérifier que les tokens proviennent bien de notre cluster
Vérifier les signatures : utiliser les clés publiques pour valider la signature des tokens JWT
Savoir quelles informations sont disponibles dans les tokens pour les utiliser dans les politiques IAM

Sans cette exposition, AWS ne pourrait pas faire confiance aux tokens émis par notre cluster k3s.

Dans mon cas j’ai simplement exposé ce endpoint de manière statique via mon ingress. Les JSON openid-configuration et keys.json sont stockés dans des configmap.

Générer des clés de signature pour les ServiceAccount

Pour que notre cluster k3s puisse émettre des tokens JWT valides et sécurisés, nous devons configurer des clés de signature permettent de signer ces tokens.

Pourquoi des clés de signature ?

Les tokens JWT contiennent des informations sensibles (namespace, service account, etc.).

Sans signature cryptographique, n'importe qui pourrait créer des tokens frauduleux.

Les clés de signature permettent à AWS de vérifier que les tokens proviennent bien de notre cluster.

Génération de la paire de clés RSA

Nous utilisons RSA-2048, un algorithme de cryptographie asymétrique standard et sécurisé :

ssh-keygen -t rsa -b 2048 -f signing.key -m pemls

Cette commande génère :

signing.key : La clé privée (à garder secrète)
signing.key.pub : La clé publique (que nous exposerons plus tard via l'endpoint JWKS)

chmod 600 signing.key*

Conversion au format PKCS8

ssh-keygen -e -m PKCS8 -f signing.key.pub > signing.key.pub.pkcs8

Cette conversion transforme la clé publique au format PKCS8, qui est le standard attendu par les systèmes OpenID Connect et AWS pour la validation des signatures JWT.

Utilisation dans k3s

Une fois ces clés générées, elles doivent être configurées dans notre service k3s pour signer les tokens des ServiceAccount.

La clé privée reste dans le cluster pour signer les tokens, tandis que la clé publique est exposée via l'endpoint JWKS pour permettre la vérification par AWS.

On dépose nos fichiers précédemment générés (signing.key, signing.key.pub.pkcs8) dans le dossier /etc/rancher/k3s/tls/ sur les master qui gèrent le control plane de notre cluster.

Nous allons maintenant reconfigurer le service k3s pour utiliser ces clés. Pour cela on met à jour le fichier du service /etc/systemd/system/k3s.service, pour y ajouter les paramètres de démarrage suivant :

ExecStart=/usr/local/bin/k3s \
    server \
    '--kube-apiserver-arg=api-audiences=sts.amazonaws.com' \
    '--kube-apiserver-arg=service-account-key-file=/etc/rancher/k3s/tls/signing.key.pub.pkcs8' \
    '--kube-apiserver-arg=service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key' \
    '--kube-apiserver-arg=service-account-signing-key-file=/etc/rancher/k3s/tls/signing.key' \
    '--kube-apiserver-arg=service-account-issuer=https://oidc-url.tld' \
    '--kube-apiserver-arg=service-account-issuer=k3s'

Les paramètres --kube-apiserver-arg=service-account-key-file et --kube-apiserver-arg=service-account-issuer peuvent être passés plusieurs fois, ce qui n’oblige pas à invalider les token précédemment émis.

Les tokens nouvellement émis auront donc l’audience sts.amazonaws.com.

Nous pouvons maintenant redémarrer notre k3s.

systemctl restart k3s

Récupération et exposition des clés

Depuis une des machines du cluster k3s :

kubectl get --raw /openid/v1/jwks | jq > keys.json

Il reste à récupérer ce fichier et à l’exposer au même titre que .well-known/openid-configuration.

Injecter automatiquement les credentials

Comme nous ne sommes pas dans un cluster EKS, nous ne disposons pas automatiquement d’une solution permettant de dynamiquement injecter des credentials dans le pod.

En effet, comme expliqué plus tôt, AWS le gère automatiquement pour nous en coulisse en s’occupant de fournir et gérer la rotation des tokens dans un cluster EKS.

Toutefois Amazon met à disposition le code d’Amazon EKS Pod Identity Webhook que l’on va pouvoir installer et utiliser dans notre cluster k3s.

Un pré-requis est d’avoir un cert manager :

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.0/cert-manager.yaml

Et après avoir cloné le dépôt :

make cluster-up IMAGE=amazon/amazon-eks-pod-identity-webhook:latest

Nous voyons les objets Kubernetes suivants :

NAME                                        READY   STATUS    RESTARTS   AGE
pod/pod-identity-webhook-764c6c7bdc-6chtr   1/1     Running   0          11d

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubernetes             ClusterIP   10.43.0.1       <none>        443/TCP   15d
service/pod-identity-webhook   ClusterIP   10.43.135.168   <none>        443/TCP   11d

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/pod-identity-webhook   1/1     1            1           11d

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.apps/pod-identity-webhook-764c6c7bdc   1         1         1       11d

Il ne nous reste qu’à ajouter l’URL de notre IDP dans la console AWS pour qu’elle soit fédérée.

Tester IRSA avec le cli AWS

Si vous voulez vérifier la capacité de vos tokens à assumer un rôle IAM, vous pouvez récupérer le token JWT d’un de vos pods, le stocker par exemple dans un fichier token.jwt et jouer une commande de ce type :

aws sts assume-role-with-web-identity \
  --role-arn arn-du-role \
  --role-session-name test \
  --web-identity-token file://token.jwt

Conclusion

Nous avons vu comment faire bénéficier à un cluster tiers du mécanisme IRSA pour interagir avec des services AWS, ce qui nous offre le meilleur des deux mondes.

Nous pouvons ainsi bénéficier d’une intégration sécurisée de certains services d’AWS pour nos applications mais sans nécessairement déployer de clusters Kubernetes avec EKS.

ⓕ ⓤ ⓢ ⓔ 👊🏼

Authentifiez les services derrière vos ingress avec OAuth2 Proxy

2023-11-07T00:00:00Z

Kubernetes nous offre des possibilités d’industrialisation de nos infrastructures. C’est particulièrement intéressant dans le cadre d’environnements de recette ou d’intégration.

On peut en effet rapidement se retrouver à avoir plusieurs environnements distincts (intégration, revue, recette…) par projet.

Ces environnements, quand ils veulent être rendus accessibles à des tiers, peuvent se retrouver exposés sur Internet.

Dès lors, leur sécurisation est un enjeu qui ne peut pas être ignoré.

Anatomie d’une application simple

Pour une application classique, on va retrouver les composants Kubernetes suivants :

ingress
service
pod

L’ingress est la porte d’entrée sur l’extérieur, jouant le rôle de reverse proxy vers votre service qui sera lui en charge de répartir les requêtes sur les différentes occurences de votre application (pod).

Sécuriser ses ingress avec OAuth2 proxy

Choix de OAuth2 proxy

Dans notre contexte nous avons un cluster destiné à nos applications en phase de recette. Chaque projet peut être déployé N fois selon l’environnement ciblé.

On peut donc progressivement se retrouver avec un nombre conséquent d’ingress dans notre cluster.

Notre objectif est de sécuriser simplement chacun de ces ingress en le mettant derrière une authentification de type Azure Active Directory.

En arrivant sur notre service on devra être redirigé vers la mire de login si l’on est pas encore authentifié. Notre autre pré-requis est que la configuration par ingress soit la plus simple possible.

Pour se faire, notre choix se porte sur OAuth2 Proxy. À l’image d’un cert manager le service s’installe et se configure de façon unique dans le cluster.

La configuration sur les ingress cibles se fait ensuite avec quelques annotations que nous détaillerons plus loin.

Fonctionnement de OAuth2 proxy

Imaginons que nous souhaitons exposer notre application sur foo.recette.bar.fr. L’ingress de l’application répondra donc sur ce domaine. Le proxy sera lui exposé sur proxy.recette.bar.fr.

Lorsqu’on se rendra sur cette URL, l’ingress interrogera le service OAuth2 proxy en passant automatiquement les cookies accessibles à ce dernier.

Si ce cookie est valide il ne se passe rien de plus, la requête entrante est considérée comme authentifiée. Si ce n’est pas le cas le proxy enclenche un round trip OAuth 2 classique. L’utilisateur sera redirigé vers la mire de login de son Active Directory.

Une fois authentifié, il sera renvoyé vers le proxy qui écrira un cookie puis le redirigera vers l’app en question.

Il est important d’avoir en tête que la portée du cookie détermine la portée de l’authentification.

Ici mon cookie a pour portée recette.bar.fr. Cela signifie qu’une fois authentifié je le serai sur l’ensemble des services qui sont sur *.recette.bar.fr de manière indifférenciée.

Sauf à démultiplier les proxy ce n’est donc pas une solution permettant de gérer finement des accès par application.

Mise en place et configuration de OAuth2 proxy

L’installation se fait simplement avec Helm :

helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests
helm install oauth2-proxy oauth2-proxy/oauth2-proxy -n mon-namespace

Une fois réalisée nous allons modifier la configuration du secret créé pour nous :

kubectl edit secret oauth2-proxy

3 clés attendent une valeur :

client-id : l’identification de l’app registration
client-secret : le secret de l’app registration
cookie-secret : une valeur aléatoire, jouant le rôle de salt pour chiffrer les cookies

Note : il est également possible d’utiliser redis en backend de session mais votre proxy ne sera plus stateless.

Je ne détaille pas le process de création d’une app registration dans le portail Azure, vous trouverez facilement de la documentation là dessus.

L’URL de redirection devra simplement être configurée pour atterrir sur https://url-du-proxy/oauth2/callback.

J’ai ensuite réalisé quelques modifications au niveau de l’objet deployment.

kubectl edit deployment oauth2-proxy

J’ai uniquement modifié les arguments de démarrage du conteneur

spec:
  automountServiceAccountToken: true
  containers:
  - args:
    - --provider=azure
    - --azure-tenant=${tenant_id}
    - --cookie-domain=recette.bar.fr
    - --email-domain=bar.fr
    - --oidc-issuer-url=https://login.microsoftonline.com/${tenant_id}/v2.0
    - --reverse-proxy=true
    - --whitelist-domain=.recette.bar.fr
    - --http-address=0.0.0.0:4180
    - --https-address=0.0.0.0:4443
    - --metrics-address=0.0.0.0:44180
    - --config=/etc/oauth2_proxy/oauth2_proxy.cfg

Parmi les éléments importants vous devrez configurez votre identifiant de tenant Azure (remplacer la valeur ${tenant_id} par votre valeur).

Le --cookie-domain permet de préciser la portée de votre cookie. Il faut évidemment que le proxy soit lui même dans cette portée.

--reverse-proxy permet de préciser à OAuth2 proxy qu’il est lui même derrière un reverse proxy, dans notre cas un ingress nginx.

La partie --whitelist-domain permet de spécifier les domaines qui sont safe pour une redirection. On verra juste après que c’est l’ingress cible qui demande où doit se faire la redirection. Si celle ci n’est pas considérée comme acceptable par OAuth2 proxy, il ne redirigera pas.

metrics-address permet de définir l’URL où alimenter Prometheus.

L’étendue des possibles en matière de configuration est vaste, je vous invite à consulter la documentation associée.

Configuration de l’ingress applicatif

Il nous reste maintenant la partie la plus simple qui consiste à configurer l’ingress de notre application.

kubectl -n $mon-namespace annotate ingress $app-ingress nginx.ingress.kubernetes.io/auth-response-headers=x-auth-request-user,x-auth-request-email
kubectl -n $mon-namespace annotate ingress $app-ingress nginx.ingress.kubernetes.io/auth-signin=https://url-du-proxy/oauth2/start?rd=$scheme://$host$escaped_request_uri
kubectl -n $mon-namespace annotate ingress $app-ingress nginx.ingress.kubernetes.io/auth-url=https://url-du-proxy/oauth2/auth

Je le mentionnais plus haut, le paramètre rd est important, c’est lui qui déterminera l’URL de redirection. Si vous ne le précisez pas vous serez correctement authentifié mais vous resterez sur le proxy.

C’est tout côté configuration, votre ingress applicatif est maintenant protégé par votre proxy qui assurera l’authentification avec votre Active Directory.

Nous avons ici présenté un cas utilisant Azure Active Directory mais OAuth2 proxy est évidemment compatible avec tout un tas d’autre SSO.

Retour sur la conférence Cloud Nord 2023

2023-10-24T00:00:00Z

Dans mon article sur la fusion de state terraform je vous avais laissé sur votre faim en vous promettant un article sur la Cloud Nord 2023.

Cloud Nord 2023

Le nom de la conférence pose le tableau, cette 3ème édition se déroulait à Euratechnologies avec au programme tout un tas de conférences couvrant des sujets variés : infrastructure as code, packaging d'applications, IA, Kubernetes, API.

Un agenda alléchant et pour lequel nous avions des attentes élevées, en espérant notamment avoir droit à des sujets bien techniques.

Avec Jonathan et Nicolas nous nous sommes donc répartis les conférences pour en couvrir un maximum de sujets.

Ouverture

Après quelques aléas techniques, Sébastien Blanc nous a retracé quelques étapes clés de l'informatique en s'appuyant sur un vieux livre « Silicon Valley ».

Il était amusant de découvrir les opinions de l'époque au travers de ce livre publié aux balbutiements de la tech. À cette époque les GAFAM n'en étaient pas encore, Cisco était une petite boite en devenir et on parlait déjà d'IA !

L'occasion de nous rappeler que les tendances dont on entend parler tous les jours prennent vie après des années ou des dizaines d'années de travail et ne sortent pas de nulle part.

La transformation en commodité de l'intelligence artificielle se fait par contre à un rythme infernal et Sébastien a pu le prouver en déployant dans le cloud une application embarquant un moteur d'IA capable de répondre à cette question fatidique : « Le welsh vient-il de Lille ?». On ne polémiquera pas sur la réponse apportée, l'IA a encore du chemin à parcourir 😊.

Refactoring Terraform

Terraform étant un nos couteaux suisses du quotidien Devops, j'étais curieux d'entendre ce retour d'expérience.

Je n'ai pas été déçu, la présentation d'Arthur était très bien maitrisée, vivante. Mention spéciale aux slides, avec un support très lisible.

Cette présentation était un condensé de retour d'expérience pour maintenir un code Terraform propre et bien organisé.

Cela passe par l'étape fatidique du refactoring et du déplacement de ressources associées. Une des solutions proposée par Terraform est l'usage de directive moved. Toutefois, sur des states un peu volumineux, leur écriture manuelle peut vite s'avérer fastidieuse.

Arthur a donc introduit son propre outil tfautomv dont l'objectif est de générer automatiquement ces directives. Il fonctionne en comparant les ressources 2 à 2 pour définir une correspondance entre source et destination. À coup sûr un outil à tester dès que l'occasion se présentera.

La présentation ne s'attardait pas que sur cet outil mais également sur des bonnes pratiques et des conventions mise en place par le présentateur et son équipe.

Entre autre, une directive à laquelle j'adhère consiste à garder ses modules racines légers en évitant de repasser l'intégralité des variables en top down.

Une astuce proposée consiste à utiliser des modules « purs » utilisant les outputs pour ré-import en tant que constante dans d'autre modules.

Un très bon talk, technique et concret, comme on les aime.

Continuous Container Checkup

Cette présentation était organisée comme un jeu de rôle entre d'une part un développeur peu consciencieux (en mode je déploie mon app et je ne m'en soucie plus) et un autre développeur orienté run.

Les deux intervenants d'Ubisoft voulaient nous présenter leurs tableaux de bord maisons conçus avec Grafana et remontant des métriques sur l'état de sécurité des applicatifs tournant dans leur cluster.

En agrégeant les résultats de tout un tas d'outils (syft, endoflife.date, ecosystems, grype, openvex…) ils ont pu collecter les informations nécessaires pour donner des indicateurs de santé sur chacune des images tournant dans leur cluster.

Couplé à la puissance de Grafana on obtient une information très lisible (car graphique) avec des possibilités de filtrage puissantes.

L'outil est très intéressant de par sa portée globale, on collecte l'information dans la zone d'exécution, ici Kubernetes, ce qui permet d'analyser n'importe quel projet qu'on viendrait déployer, quelle que soit sa topologie.

Les équipes ont prévu de l'open sourcer sans toutefois donner de date, on attend ça avec impatience.

Composants internes de Kubernetes

Après la pause déjeuner on rattaquait avec la présentation de Denis Germain sur les composants internes de Kubernetes.

Très didactique, la présentation déroulait une installation de Kubernetes (en 1.27 alpha s'il vous plait 😊), composant par composant : etc, scheduler, controller-manager.

Le fait que le déroulé de la démo soit assez simple (la plupart du temps exécuter les binaires), montre à quelle point l'architecture de Kubernetes est bien pensée et orientée composants ; chacun ayant son propre périmètre de responsabilité mais pour autant indispensable au fonctionnement de l'ensemble de la chaine.

Au passage, c'était l'occasion de reparler de Cilium (utilisé en tant que CNI) et d'eBPF (sur lequel s'appuie Cilium) dont on aura l'occasion de reparler sur le blog.

Un mot a également été dit sur les objets de type Gateway API (à ne pas confondre avec API Gateway), qui devrait à terme prendre le pas sur ceux de type Ingress.

L'intelligence artificelle expliquée en 20 minutes

Sans transition me voilà dans une salle bondée pour assister un speed talk sur l'IA.

Stéphane, développeur, nous a présenté l'IA sous l'angle de ce qu'il en a compris au gré de ses investigations et tests.

La présentation situait les différents types d'intelligence artificielle (ANI : artificial narrow intelligence, AGI : artificial general intelligence, ASI : artificial super intelligence).

L'occasion également de rappeler que l'intelligence artificielle ne peut pas partir de rien et que la qualité des données en entrée est l'un des éléments clés. Sauf que ces données sont souvent qualifiées par des … humains.

L'IA est d'ailleurs capable de fonctionner en mode supervisé et non supervisé. Dans le premier elle sera guidé par l'humain pour confirmer ou infirmer ses « choix ». C'est notamment ce qui permet l'apprentissage par renforcement.

En non supervisé l'IA va tenter de découvrir des patterns (les objets qui ressemblent à des voitures sont sûrement également des voitures). Ce mode est intéressant pour pré-qualifier et segmenter des gros volumes de données existants.

Sur les aspects de type « Comment ça marche ? » on se rend compte que l'IA se base principalement sur des approches probabilistes en convertissant les données d'entrée en vecteur mathématiques.

C'est aussi ce qui explique que les calculs soient bien plus performants avec des GPU, conçus pour traiter ce type d'information, qu'avec des CPU.

Créer des règles d'autoscaling efficace avec Kubernetes

Pour cette présentation en forme de REX on retrouve Henrik Rexed, déjà croisé lors de sa présentation « L'art de l'observabilité avec Open Telemetry ».

Cette fois il s'agissait d'un retour d'expérience d'une approche finops. Au-delà de présenter des outils d'optimisation il s'agissait avant tout d'analyser des problématiques de performance dans la cadre d'une réduction de coûts.

Opencost a bien sûr était un des points d'entrée dans l'analyse des ressources mais finalement pas le centre de cette présentation.

Il s'agissait avant tout de comprendre comment optimiser l'usage des ressources. Lors de la livraison d'un projet, un réflexe naturel est de surdimensionner les ressources pour garantir un fonctionnement optimal et d'optimiser ensuite (quand on n'oublie pas de le faire !).

Pour maximiser son taux d'usage dans un contexte Kubernetes, il s'agit d'avoir un nombre de pod adapté à la charge et capable de scaler automatiquement.

Kubernetes dispose évidemment d'une API pour la partie HPA (horizontal pod autoscaling) mais avec un nombre de métriques assez restreint : CPU et mémoire.

Henrik nous démontre avec un exemple concret que ces métriques peuvent s'avérer insuffisantes, notamment lorsqu'on a posé des limites sur ses ressources. Dans son cas, le CPU des nodes sur lesquelles tournait l'application était la plupart du temps idle. L'occasion de relancer le débat sur l'intérêt des limites de CPU.

Il s'avère également que même lorsqu'elles sont intéressantes, ces métriques peuvent arriver trop tard.

L'autoscaling n'étant pas instantané on veut idéalement que le dimensionnement s'anticipe autant que possible. C'est à ce moment que l'outil Keptn a été introduit. Celui-ci permet de disposer de davantage de métriques en entrée pour prendre les bonnes décisions de scaling.

En l'occurrence il s'agissait ici de s'appuyer sur le nombre de requêtes entrantes pour déterminer le dimensionnement à mettre en face.

Finalement une présentation très dense et bien rythmée avec un cas concret, on a adoré.

Documenter et standardiser ses API avec AsyncAPI

Dans cette dernière présentation de la journée, Ludovic nous a parlé de son parcours avec Async API. Un projet qu'il utilise au quotidien dans le cadre professionnel et auquel il a directement contribué.

Async API est un standard très proche de OpenAPI, dans sa conception et sa documentation, à tel point que passer de l'un à l'autre n'est pas vraiment dépaysant.

Avec des API asynchrones on sort de la logique requête / réponse et on bascule dans une logique client / serveur avec des connexions qui peuvent rester ouvertes et des flux qui ne sont pas bloqués dans l'attente de la réponse.

On va donc plutôt utiliser des websocket ou du gRPC. AsyncAPI a l'ambition de devenir le standard de facto, en lieu et place de OpenAPI (tout un programme !). Ils ont récemment monté un partenariat avec Postman qui dédie un certain nombre de ses employés pour travailler sur le standard et son intégration dans Postman.

Lorsqu'on travaille avec des outils tels que OpenAPI ou AsyncAPI il est préférable d'opter pour une logique « contract first » (vs code first).

En clair, on va prendre le temps en amont de définir le format de son API, les paramètres d'entrée, les formats de retour avant de travailler sur l'implémentation.

L'immense avantage de ce type d'approche et de faciliter la mise en place de mock et potentiellement paralléliser le développement de l'API et de son ou ses clients (qu'on en maitrise le développement ou non).

AsyncAPI permet l'exposition de schémas sous différents formats : le bien connu JSON schema mais également RAML ou Avro.

À noter que la version 3 de AsyncAPI est en cours de construction. Difficile de dire si on est proche ou non d'une finalisation, le dernier article annonçant une arrivée datant de mars 2022.

Au final un sujet très intéressant et parfaitement maitrisé. Utilisateurs de longue date d'OpenAPI nous allons nous pencher plus sérieusement sur AsyncAPI.

Conclusion

On en retiendra une journée enrichissante, des conférences très intéressantes et des présentations bien maitrisées.

Le superbe cadre d'Euratechnologies aura compensé le seul bémol de la journée : le manque de café !

On a hâte d'assister à la prochaine édition.

Fusionner des states terraform et déplacer les ressources importées

2023-10-18T00:00:00Z

La vie de développeur est faite de plusieurs craintes : devoir gérer un conflit git, régler un problème de cache et gérer un state terraform à la main par exemple.

Aujourd’hui on va s’attaquer à ce dernier avec un cas concret.

Pourquoi diable vouloir fusionner des states Terraform ?

Imaginez que vous ayez une application pour laquelle vous devez provisionner une infrastructure, mettons sur AWS.

L’application tourne dans un cluster EKS provisionné à part, dans son namespace et utilise un utilisateur dédié dans Rancher.

La vie est belle, vos ressources sont provisionnées « à plat » à grand coup de resource x dans vos scripts terraform.

Mais voilà que l’application devient multi client et chaque client a besoin de sa « stack », avec son namespace, son bucket etc.

Pour faire simple vous copiez collez vos ressources en changeant le nom et la configuration.

Tout cela fonctionne très bien mais le nombre de stack grandit et vous vous retrouvez avec 5 stacks et un code terraform ingérable où la moindre modification doit être répliquée autant de fois.

Ce qui permettait d’aller vite au début devient maintenant un caillou dans la chaussure.

resource "rancher2_namespace" "project_a" {
}

resource "rancher2_namespace" "project_b" {
}

resource "rancher2_namespace" "project_c" {
}

Comme on le voit, chacune des ressources (bucket, user…) est dupliquée.

Armé de votre courage, vous décidez de mettre en place un module terraform, qui vous permettra de définir de nouvelles stacks en trois coups de cuiller à pot.

module "stack" {
  source = "./modules/stack"

  for_each = local.stacks
  name     = each.value["name"]
  secrets  = each.value["secrets"]
}

locals {
  stacks = {
    "staging" = {
      name    = "staging"
      secrets = merge(var.default_secrets, var.stacks_secrets["staging"])
    }
  }
}

Génial, c’est simple à maintenir et la complexité est déportée dans le module à un seul endroit. Plus de doublons.

Le problème c’est que vous avez déjà provisionné 5 stacks avant de vous décider à mettre en place un module.

Idéalement il faut que ces stacks ré-intègrent votre module. Malheureusement les fichiers de states sont non seulement différents (ce sont des fichiers distincts) mais les ressources ne sont pas au même format.

Là où vous aviez rancher2_project_role_template_binding.project_a vous devriez maintenant avoir module.stack["project_a"].rancher2_project_role_template_binding.stack, vos stacks étant gérées dans une map.

Nous allons voir comment gérer cette transition.

Sécurisez l’existant

On commence par les précautions d’usage, c’est à dire faire un backup des states.

On appellera original celui qui a été géré sans module et destination celui avec.

# dans le projet sans module
tf state pull > original.tfstate
# dans le projet avec module
tf state pull > destination.tfstate

Faites un backup en lieu sûr de ces fichiers pour disposer d’exemplaires originaux et travaillez sur une copie.

Les fichiers d’états sont de simples fichiers texte, toutefois je vous déconseille vivement de vous essayer à des modifications manuelles dans ces fichiers.

Commençons par lister le contenu de notre state original.

terraform state list -state=original.tfstate

nous donne :

rancher2_cluster_role_template_binding.project_a
rancher2_cluster_role_template_binding.project_b
rancher2_cluster_role_template_binding.project_c
rancher2_cluster_role_template_binding.project_d
rancher2_cluster_role_template_binding.project_e
rancher2_cluster_role_template_binding.project_f
rancher2_global_role_binding.project_a
rancher2_global_role_binding.project_b
rancher2_global_role_binding.project_c
rancher2_global_role_binding.project_d
rancher2_global_role_binding.project_e
rancher2_global_role_binding.project_f
rancher2_namespace.project_a
rancher2_namespace.project_b
rancher2_namespace.project_c
rancher2_namespace.project_d
rancher2_namespace.project_e
rancher2_namespace.project_f
rancher2_project.project_a
rancher2_project.project_b
rancher2_project.project_c
rancher2_project.project_d
rancher2_project.project_e
rancher2_project.project_f
rancher2_project_role_template_binding.project_a
rancher2_project_role_template_binding.project_b
rancher2_project_role_template_binding.project_c
rancher2_project_role_template_binding.project_d
rancher2_project_role_template_binding.project_e
rancher2_project_role_template_binding.project_f
rancher2_registry.project_a
rancher2_registry.project_b
rancher2_registry.project_c
rancher2_registry.project_d
rancher2_registry.project_e
rancher2_registry.project_f
rancher2_secret_v2.project_a_administration
rancher2_secret_v2.project_a_aws_s3
rancher2_secret_v2.project_a_database
rancher2_secret_v2.project_a_deepl
rancher2_secret_v2.project_a_froala
rancher2_secret_v2.project_a_google
rancher2_secret_v2.project_a_mailjet
rancher2_secret_v2.project_b_administration
rancher2_secret_v2.project_b_aws_s3
rancher2_secret_v2.project_b_database
rancher2_secret_v2.project_b_google
rancher2_secret_v2.project_c_administration
rancher2_secret_v2.project_c_aws_s3
rancher2_secret_v2.project_c_database
rancher2_secret_v2.project_c_google
rancher2_secret_v2.project_d_administration
rancher2_secret_v2.project_e_administration
rancher2_secret_v2.project_e_aws_s3
rancher2_secret_v2.project_e_database
rancher2_secret_v2.project_e_google
rancher2_secret_v2.project_f_administration
rancher2_secret_v2.project_f_aws_s3
rancher2_secret_v2.project_f_database
rancher2_secret_v2.project_f_google
rancher2_secret_v2.project_f_mailjet
rancher2_user.project_a
rancher2_user.project_b
rancher2_user.project_c
rancher2_user.project_d
rancher2_user.project_e
rancher2_user.project_f

Ouch ! Ce fichier nous liste l’ensemble des ressources dans notre state. Forcément nous retrouvons chaque ressource démultipliée (1 fois par projet).

Il va falloir déplacer ces ressources une à une avec tf state mv.

On ne se laisse pas abattre et on va créer un petit script pour nous aider. Celui ci est très simple et va migrer les ressources d’un fichier de state à un autre.

Ce qu’on souhaite c’est que notre code à base de stack ait connaissance des ressources qui avaient été crées hors stack afin de les ré-intégrer.

#!/usr/bin/env bash

while read state; do
  terraform state mv -state=original.tfstate -state-out=destination.tfstate $state $state
done <$(terraform state list -state=original.tfstate)

Une fois fait, on va se retrouver avec notre fichier destination.tfstate contenant l’intégralité du state. On peut le vérifier avec un terraform state list -state=destination.tfstate.

À noter que terraform va créer des fichiers de state intermédaires pour chacune des opérations, permettant un rollback éventuel. Étant donné qu’on travaille sur des fichiers locaux le risque est ici limité.

En l’état ce qu’on vient de faire s’apparente à un merge des fichiers de state.

Maintenant il faut que nous mettions les nouvelles ressources au bon format. Je vous conseille également d’outiller la démarche avec des scripts, au moins par type de ressources, si le nombre de ressources à migrer est important.

En terme de commandes finales elles s’apparenteront à cela :

tf state mv -state=destination.tfstate rancher2_user.project_a module.stack\[\"project_a\"\].rancher2_user.stack

Une fois que les ressources ont été migrées il nous reste à ajouter les instructions dans notre module, comme si les stacks importées avaient été créées avec.

module "stack" {
  source = "./modules/stack"

  for_each = local.stacks
  name     = each.value["name"]
  secrets  = each.value["secrets"]
}

locals {
  stacks = {
    "staging" = {
      name    = "staging"
      secrets = merge(var.default_secrets, var.stacks_secrets["staging"])
    }
    "project_a" = {
      name    = "project_a"
      secrets = merge(var.default_secrets, var.stacks_secrets["project_a"])
    }
    …
  }
}

C’est le moment de vérité, il reste à vérifier qu’on a bien fait les choses :

mv destination.tfstate nom_utilise_dans_votre_projet.tfstate
tf state push nom_utilise_dans_votre_projet.tfstate
tf plan

Si tout est en ordre notre tf plan ne devrait produire aucun changement (pas de destroy, add ou update). Si vous avez tout cassé, remettez le state original, retirez le code ajouté et recommencez.

À noter qu’ici je donne l’exemple de state différents, si j’avais eu à gérer des mouvements de ressources faisant déjà partie d’un même projet et d’un même state j’aurai sans doute utilisé des instructions moved.

J’aurai peut être même utilisé tfautomv que j’ai eu l’occasion de découvrir à Cloud Nord 2023 et dont je vous reparlerai dans l’article de compte rendu des conférences 😊.

Retour sur la conférence We Love Speed 2023

2023-05-26T00:00:00Z

Entouré de mes acolytes Gaëtan et Nicolas nous étions mercredi 10 mai à la conférence We Love Speed. Cette conférence itinérante s'arrêtait cette année à Paris, à l'espace Saint Martin.

Les sujets des conférences gravitent évidemment tous autour de la performance et plus précisément de la web performance. Le principal focus se trouve notamment sur les aspects front. Je pense que c'est d'ailleurs un axe qui pourrait évoluer pour couvrir des pans plus larges de la performance (infrastructure, pattern côté back-end…).

On peut toutefois se féliciter d'avoir ce type de conférence avec des intervenants d'excellent niveau.

Dans cet article, nous allons donc vous retracer les différentes conférences et ateliers que nous avons pu voir et ce que nous en avons retenu.

Dompter l’Impact en Webperf des Scripts Tiers

Andy Davies nous parle de l’impact des scripts third party dans la performance web.

Si les fonctionnalités offertes (analytics, RUM, contenu) ne sont pas à remettre en cause, il est nécessaire de trouver un équilibre.

Un bon outil pour obtenir une cartographie des requêtes réalisées pour un site donné : Request map generator.

Andie propose la classification des contenus suivante pour déterminer quand charger quoi :

Il nous ouvre également les yeux sur les problématiques de vie privée ouvertes par les scripts tiers. La fuite d’IP vers un domaine tiers sans consentement a notamment été récemmetn l’objet d’un procès en Allemagne.

Il s’interroge sur l’intérêt de proposer des API de consentement intégrées au navigateur, ce qui leur conférerait encore plus de pouvoirs. Les CDN également commencent à proposer des alternatives (ex : cloudflare zaraz).

Par ailleurs les chargements sur des sites tiers, aussi rapides soient ils, s’avèrent souvent plus lents que des chargements locaux.

Tous les scripts third party ne sont pas égaux et ils doivent également être monitorés. Il est nécessaire de définir précisément ce qu’on veut mesurer (taille, nombre de requêtes…). Par exemple google tag manager est très lourd à charger.

Certaines lib (ex : postscribe) implémenent des fonctionnalités qui sont potentiellement très peu utilisées et avec des impacts majeurs en terme de performance (dans ce cas document.write).

Enfin, le simple fait de ré-ordonner les tags peut parfois amener des gains de performance significatifs. Ces gains sont d’ailleurs souvent synonymes de revenus plus importants.

Les Protocoles Web pour les devs front-end

Dans cette conférence de Robin Marx, qui offre un parallèle surprenant avec le seigneur des anneaux, il est question (d’épées et) de protocoles, principalement d’HTTP.

Actuellement nous en sommes à HTTP/3 (basé sur QUIC), qui offre l’avantage d’être pleinement rétro-compatible avec HTTP/2. L’activer pour un site compatible H2 est donc sans risque.

Robin se positionne du point de vue des CDN (il travaille pour l’un d’eux).

Pour un CDN il est difficile de connaitre le nombre de paquets qu’il est possible d’envoyer.

En effet, côté client, La taille d’un lien est fixe mais souvent partagée entre plusieurs connexions, qui vont et qui viennent. Il est donc difficile de connaitre précisément la capacité de la connexion à un instant T. Les CDN en sont donc réduits à l’estimer, de manière progressive, jusqu’à atteindre les limites, en doublant le nombre de paquets à chaque fois que le receveur accuse bonne réception de l’ensemble.

Tous les CDN ont donc une logique de slow start avec des round trip qui chargent de plus en plus de données à chaque « tour ».

Au delà de la taille qu’il est possible d’envoyer à chaque fois, le CDN doit également déterminer quels paquets envoyer dans quel ordre. Notamment arbitrer ce qui doit être priorisé entre le HTML, le JS et le CSS.

Faut il envoyer un type de ressource complètement ou envoyer des morceaux de chaque type à chacune des itérations ?

Il s’avère qu’il est mieux d’envoyer un type de ressource complètement, notamment pour JS et CSS qui ne sont pas utilisables avant d’avoir été complètement envoyés. Il ne sont pas streamable comme certains types d’image par exemple.

On découvre également qu’un grand nombre de serveurs n’appliquent pas les consignes demandées par les navigateurs en terme de priorités (Apache fait plutôt office de bon élève). Mais les navigateurs ne sont pas non plus d’accord entre eux sur la pondération des règles !

Safari en prend pour son grade, souvent qualifié de nouvel Internet Explorer. Il gère notamment la priorité des JS exactement de la même façon quelqu’ils soient (head, body, defer), à l’exception de ceux en async qui se voient affectés une priorité moindre.

De même, les images en preload ont une priorité moindre que sans l’attribut (sic). Au delà de l’aspect discutable de ces choix, ils portent à confusion pour les développeurs qui ne s’attendent pas à ces comportements et qui doivent gérer des différences selon les navigateurs.

Un nouvel attribut, fetchpriority permet aux développeurs d’expliciter la priorité à donner aux différents éléments.

Robin donne l’exemple des carrousel où la priorité de la première image se doit d’être haute quand celle des suivantes peut être basse.

Finalement l’auteur nous livre ce qui pourrait résumer en une phrase l’ensemble des conférences : « Le chargement de ressources n’est ni cohérent ni prédictible selon les conditions (navigateur, serveur, réseau…). Simplement l’observer dans son navigateur n’est pas suffisant. »

Mesure ou Meurs

Dans un superbe décor, Jean-Pierre Vincent fait un focus sur webpagetest pour mesurer la performance des sites.

Il pointe du doigt l’effet pervers des systèmes, comme Lightouse, qui donne des notes sur des critères donnés de manière automatique, ce qui incite les équipes à obtenir la meilleure note possible sans nécessairement comprendre ce qu’elles sont entrain de faire.

On y apprend l’intérêt de savoir décrypter un waterfall, en commencant par le TTFB (Time to first byte), c’est à dire le temps d’attente avant de recevoir la réponse du serveur.

En performance, la taille de la ressource n’est pas forcément le critère numéro 1, c’est surtout l’impact sur l’utilisateur. Paradoxalement on peut avoir des TTFB long pour des ressources légères et court pour des ressources lourdes avec des impacts utilisateurs inverses à ce qu’on pourrait imaginer au premier abord.

Un autre élément clé de la performance est le LCP (Largest Contentful Paint), à savoir l’élément ayant la plus grande surface visible à l’écran.

Le LCP est variable selon le terminal qui fait le rendu. Webpagetest indique en vert le LCP, ce qui permet se savoir à quel moment exactement il est rendu. Une fois qu’on connait cet élément on va pouvoir libérer le chemin critique afin de faire en sorte qu’il soit chargé le plus tôt possible.

Pour mesurer la réactivité des sites, un indicateur historique est le First Input Delay (FID), qui n’est pas parfait car il mesure le délai entre un clic et un callback.

Il tend à être remplacé par le Interaction to next paint (INP) qui mesure le temps entre le clic et le prochain affichage. Ces deux indicateurs ne sont toutefois pas simulables par des outils.

Le total blocking time est le temps passé entre le FCP et le Time to Interactive (TTI). Pour le réduire il est important de trouver les scripts consommateurs, par exemple en les groupant dans Chrome dev tools.

Lighthouse peut également être utilisé en mode timespan, ce qui permet d’enregistrer les interactions et de détailler le temps passé.

Comment devenir un Sherlock Holmes de la Web Performance

Ludovic Lefebvre revient sur son expérience chez Peaksys (filiale tech de cdiscount).

Avec 20M de visiteurs par mois on comprend que la performance est un enjeu.

Notre orateur vient nous présenter la méthode Sherlock, qui vise à passer de données à informations puis connaissances et enfin sagesse.

Les connaissances sont très précieuses car elles sont ré-utilisables dans des contextes similaires.

Pour analyser une situation on va généralement commencer par les observations, suivies des hypothèses, des expérimentations et enfin des conclusions.

Pour avoir une bonne visibilité il est important d’être bien outillé, notatement niveau RUM (Real User Monitoring) et également performance d’infrastructure, APM et non régression.

Cette visibilité doit se compléter avec une vsion claire de tous les changements (contenu, infrastructure, déploiement…). Ludovic prend le cas concret d’une augmentation du LCP (Largest Contentful Paint).

Pour comprendre ce qui c’était passé il a fallu s’appuyer sur les outils, notamment de RUM et le croiser avec l’historique des changements pour comprendre que cela résultait d’une opération de communication qui avait entrainé le retrait du bandeau sur le site. Cela a eu pour effet de dégrader le LCP.

Enfin Ludovic nous offre un parallèle du biais du survivant avec l’anedocte bien connue des avions endommagés qui sont revenus à la base après la seconde guerre mondiale.

La première réaction a été de renforcer les zones endommagées avant de comprendre que les zones à améliorer étaient celles qui n’étaient pas endommagées car relatives aux avions qui n’étaient pas revenus.

Dans le web le constat est applicable dans la webperformance où les avions s’apparentent aux utilisateurs et le champ de bataille au tunnel de conversion.

Il ne faut pas analyser les utilisateurs qui arrivent en bout de tunnel car ce sont ceux qui commandent et qui ont donc atteint le résultat escompté. Il faut au contraire se pencher sur tous les autres.

L'art de l'observabilité avec Open Telemetry

Un atelier proposée par un intervenant de Dynatrace, qui a su garder un bon focus sur Open Telemetry plutôt que sur Dynatrace, un excellent point.

OpenTelemetry cible l'observalité (je comprends ce qui se passe) plutôt que le monitoring (je constate ce qui se passe).

Il vise à standardiser la production de métriques, logs, traces, profiling. Il est né sur les cendres de la fusion entre OpenTracing et OpenCensus.

Ctete standardisation permet d'homogénéiser les pratiques, plutot que d'avoir des multitudes d'outils qui sont spécialisés dans leur domaine (réseau, application…) et pas nécessairement interopérables. Il faut toutefois garder en tête que c’est d’une part un standard vivant, avec des choses restant à formaliser et que le niveau des outils varie d’une stack technique à l’autre.

Concrètement, on peut imaginer avec des traces formalisées suivre le parcours complet d'une requête d'un visiteur sur une app, depuis l'instrumentation du front jusqu'aux infrastructures et définir exactement quel temps il a passé dans quel composant afin de diagnostiquer les éventuelles erreurs / lenteurs.

La télémétrie s’articule autour de deux composants clés : l’instrumentation et le collecteur. L’objectif de standardiser ce dernier est d’éviter d’avoir un collecteur spécifique par type de logs ou traces mais plutôt un générique et agnostique des plateformes ciblées.

OpenTelemetry est actuellement le projet le plus dynamique porté par la CNCF derrière Kubernetes. Pas étonnant qu’il soit au cœur de notre plan d’action technique cette année.

Soft navigation

Yoav Weiss nous propose une conférence teintée d’humour sur la soft navigation. Par soft navigation on entend le contrôle de la navigation côté app, notamment dans le cadre des SPA (qui manipule la navigation et l’historique).

Le fond du débat tournait donc autour de SPA (single page app) vs MPA (multiple page app). Yoav travaille sur Google Chrome. À la question quelle architecture est plus performante il répond : « on ne sait pas ». Globalement, mesurer la performance d’une SPA est toujours aussi complexe, bien que le sujet soit ouvert depuis plus de 10 ans.

Du côté des implémenteurs de navigateur, la gestion de l’historique par les applications est complexe car assez tributaire de l’usage des framework ou lib sous jacente. Par exemple, certains vont déclencher history.pushState dès que l’utilisateur interagit avec la page (click par exemple), d’autres une fois seulement que la nouvelle vue est rendue, ce qui rend complexe la détermination du point de départ.

D’autre part les SPA ne font pas bon ménage avec les web core vitals. En effet on ne mesure que le premier chargement qui est généralement le plus lent, avec la promesse que la navigation secondaire sera plus rapide, mais invisible par le navigateur.

Une nouvelle API voit le jour : Navigation API, qui est actuellement uniquement supportée par Chrome. Avec cette API on peut visualiser dans les chrome tools les même métriques que pour la navigation primaire et également disposer d’API de mesure de la performance (PerformanceObserver).

Les API sont accessible derrières un flag experimental qu’il est possible d’activer dès à présent (reportSoftNavs).

Le top 10 des perles en webperformance

Stéphanie Rios nous offre un compilation des perles qu’il croise au quotidien.

Le lazyloading c’est bien mais trop de lazyloading tue le lazyloading. La règle d’or : ne lazyloader que les images qui ne sont pas visibles dans le viewport.

Si on lazyload une image qui est visible dans le viewport, on retarde le temps de chargement général. Soit on utilise une lib de lazyload et le chargement de l’image sera tributaire du chargement de cette lib, soit on utilise le lazyload natif et cette image sera dépriorisée.

Il nous conseille également de privilégier les lib plutôt que le lazy load natif qu’il juge pas suffisamment « agressif ». En effet le lazyload natif peut charger des contenus qui ne seront potentiellement jamais vu, car accessible 2-3 viewport plus bas dans la page.

Le defer peut parfois s’avérer contre productif. Chargé trop tôt dans le document il peut bloquer le téléchargement d’autres ressources.

Les directives @import CSS, notamment pour les google fonts peuvent également occasioner des blocages. On trouve également des fonts servies en OTF au lieu de WOFF2 (qui est lui un format compressé à privilégier).

Les appels à des domaines externes sont parfois aussi sources de blocages. Des scripts third party sont parfois chargés de manières bloquantes sur des domaines externes, ce qui pose des problèmes en situation de mobilité. En plus de cela le bénéfice est parfois anecdotique dans le cadre de polyfill qui ne seront pas utilisés si la fonctionnalité est supportée nativement.

Côté mise en cache des lib third party par l’usage d’un CDN, notre speaker nous rappelle que depuis quelques années la clé de cache des ressources externes est doublée avec le host de l’origine. Si une lib est chargée depuis un domaine A et qu’elle est également demandée sur un domaine B elle sera quand même rechargée.

Certaines ressources manquent souvent à l’appel en terme de lazyload, on peut notamment citer le player youtube, très gourmand en ressources. Il est possible de le mettre dans une iframe et lazyloader cette dernière.

On trouve souvent des images responsives qui ne le sont pas, par exemple la même image en desktop et en mobile ou des erreurs de media queries.

Enfin il faut maintenant abolir les sprites, qui sont des concaténations d’image avec des références à la position de l’image à afficher. On se retrouve donc à charger des sprites potentiellement lourd, parfois sur mobile, pour utiliser seulement quelques images de ce dernier.

Maintenant que l’on dispose de HTTP/2 qui permet de multiplexer les contenus sur une même connexion cela n’a plus d’intérêt.

Conclusion

Cette ultime conférence marquait la fin de cette belle édition. On en retiendra que la webperformance nécessite des piqures de rappel fréquentes sur des notions qui peuvent sembler acquises. Elle demande également un peu de subtilité pour des comportements qui peuvent parfois s’avérer contre-intuitifs.

Enfin, la webperformance doit se construire avec les équipes de dév et pas à leur détriment ni après coup.

On saluera également pour cette conférence une organisation soignée et jamais mise en défaut. Merci aux organisateurs !

Accéder à un RPN SAN Scaleway dans une machine virtuelle Proxmox

2023-05-07T00:00:00Z

L’objectif de cet article est de présenter l’utilisation d’un stockage iSCSI chez Online / Scaleway en vue de rattacher des volumes réseaux à des machines virtuelles dans Proxmox.

À noter que si vous n’utilisez pas Proxmox l’article peut quand même présenter un intérêt, toutefois je pars du postulat que vous avez un Proxmox fonctionnel avec quelques machines virtuelles.

Utiliser une interface privée sur chacun des machines virtuelles

Nous allons commencer par créer un groupe RPN v2 dans l’interface Online afin d’y ajouter les serveurs.

Chacune des machines doit être dans le même VLAN afin qu’elles puissent communiquer ensemble. Ici l’identifiant du VLAN est 2001, vous pouvez choisir ce que vous voulez.

Au passage nous ajoutons la compatibilité avec le RPN v1, car le SAN n’est pas compatible v2.

Configurer une interface privée sur la VM pour accèder au SAN

Maintenant que nous avons configuré les pré-requis dans l’interface Online, nous allons définir une interface réseau privée sur nos VM.

La passerelle nous offre une plage d’IP que nous allons pouvoir utiliser indifféremment dans Proxmox.

La première étape consiste à créer ou éditer une interface privée. On en profite pour activer les jumbo frame en passant le MTU à 9000.

N’oubliez pas d’appliquer la configuration.

On va ensuite créer une interface virtuelle sur la VM avec également un MTU de 9000.

Au niveau IPv4 il faut choisir une adresse dans le range qui vous a été attribué avec la passerelle. La partie bridge ports doit elle reprendre d’un côté le nom de l’interface réseau source et de l’autre le VLAN id (visible dans la capture précédente avec les groupes RPN).

Reste à appliquer afin que les changements se reflètent dans le fichier /etc/network/interfaces.

Sur le serveur on peut vérifier la configuration de l’interface :

ip a show vmbr1

On voit que l’interface réseau a bien pris l’adresse IP privée indiquée.

11: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
    link/ether 00:24:ec:f2:c1:fa brd ff:ff:ff:ff:ff:ff
    inet 10.88.85.4/24 scope global vmbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::224:ecff:fef2:c1fa/64 scope link
       valid_lft forever preferred_lft forever

Toutefois dans l’interface d’Online nous devons explicitement autoriser le serveur et son adresse privée au niveau du SAN, autrement il sera impossible de d’y connecter.

Pour arriver au résultat suivant :

Ajout du disque iSCSI dans Proxmox

Si on regarde où se trouve notre SAN, on constate qu’il est dans un sous réseau 10.90.x.y.

host san-dc2-11.rpn.online.net
san-dc2-11.rpn.online.net is an alias for rpn-storage-dc2-11.rpn.online.net.
rpn-storage-dc2-11.rpn.online.net has address 10.90.254.98

Notre adresse ip privée étant en 10.88 nous allons donc devoir lui expliquer comment accéder au SAN, pour cela nous ajoutons une route permettant d’accéder au SAN en utilisant la passerelle.

ip route add 10.88.0.0/13 via 10.88.85.1

Sur le noeud on va ensuite installer le paquet open-iscsi puis configurer le fichier /etc/iscsi/iscsid.conf avec les valeurs suivantes (extraites de la documentation) :

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
node.session.timeo.replacement_timeout = 15
node.startup = automatic
node.conn[0].iscsi.HeaderDigest = CRC32C,None
node.conn[0].iscsi.DataDigest = CRC32C,None

Nous utilisons des valeurs différentes pour le replacement_timeout, lié au fait que nous allons utiliser du multipath.

Configuration du multipath

Le protocole iSCSI est normalement à utiliser avec un seul hôte, c’est à dire qu’il est conçu pour être monté par une seule machine à la fois. Vous aurez d’ailleurs une alerte dans Online dès lors que vous configurerez plusieurs machines pouvant accèder au service.

Le multipath permet d’accèder au disque depuis plusieurs chemins différents, ce qui offre à la fois de la redondance et une amélioration des performances.

Après avoir installé le paquet multipath-tools nous allons nous authentifier sur le SAN concerné depuis un hôte :

iscsiadm -m node -T iqn.2013-01.net.online:1aokoes065of --login

On peut maintenant voir notre disque :

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0     5T  0 disk
`-sda1        8:1    0     5T  0 part

Chez moi il est monté sur /dev/sda. On va récupérer l’identifiant du disque :

/lib/udev/scsi_id -g -u -d /dev/sda

qui nous donne l’information suivante :

149455400000000004637e3f9f5329104459d80b7be1ac5f3

Puis nous allons configurer le fichier /etc/multipath.conf de la sorte :

defaults {
 polling_interval        2
  path_selector           "round-robin 0"
  path_grouping_policy    multibus
  uid_attribute           ID_SERIAL
  rr_min_io               100
  failback                immediate
  no_path_retry           queue
 user_friendly_names     yes
}

blacklist {
  wwid .*
}

blacklist_exceptions {
 wwid "149455400000000004637e3f9f5329104459d80b7be1ac5f3"
}

J’ai repris les réglages par défaut pour la première section. Pour la partie blacklist et blacklist_exceptions l’idée est de n’autoriser que ce disque en multipath et de bloquer tous les autres par défaut.

On redémarre le service après l’avoir configuré.

systemctl restart multipath-tools.service

Puis nous allons ajouter le disque concerné au multipath.

/sbin/multipath -a 149455400000000004637e3f9f5329104459d80b7be1ac5f3

On vérifie que tout fonctionne bien.

/sbin/multipath -ll

On voit bien notre disque :

mpatha (149455400000000004637e3f9f5329104459d80b7be1ac5f3) dm-0 IET,VIRTUAL-DISK
size=5.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:0:0 sda     8:0   active ready running

Découpage du disque physique en disques logiques

On va tout d’abord créer le volume physique.

/sbin/pvcreate --metadatasize 250k -y -ff /dev/sda1

et un volume group pour accueillir plusieurs volumes logiques :

/sbin/vgcreate storage01 /dev/sda1

On peut ensuite commencer à créer des stockages logiques au sein du volume group :

/sbin/lvcreate -L 500G -n 01 storage01
/sbin/lvcreate -L 500G -n 02 storage01
/sbin/lvcreate -L 500G -n 03 storage01

On retrouve nos volumes logiques :

/sbin/lvscan

avec la liste suivante :

ACTIVE            '/dev/storage01/01' [500.00 GiB] inherit
ACTIVE            '/dev/storage01/02' [500.00 GiB] inherit
ACTIVE            '/dev/storage01/03' [500.00 GiB] inherit

Il reste ensuite à les monter et les formatter pour les utiliser.

Ajout du stockage dans Proxmox

Proxmox gère également l’ajout d’un LVM et la création d’un volume group depuis l’interface. Toutefois je j’ai pas l’impression qu’on puisse créer des volumes logiques avec des tailles différentes.

Si vous souhaitez utiliser un volume logique reprenant l’ensemble de votre disque, vous pouvez le faire dans la partie Datacenter > Storage.

On commence par ajouter notre stockage. On peut au besoin le limiter à certains noeuds. Dès lors que vous mettrez l’adresse du portal la target devrait être proposée, si ce n’est pas le cas je vous propose quelques commandes dans la section suivante pour débugger.

Une fois créé :

Commandes utiles

Si vous êtes bloqués dans l’interface Proxmox lorsque vous essayez d’ajouter le SAN, vous pouvez tenter une découverte des targets directement depuis le serveur :

iscsiadm -m discovery -t sendtargets -p san-dc2-11.rpn.online.net

Nous donne le résultat suivant :

10.90.254.98:3260,1 iqn.2013-01.net.online:1aokoes065of

Conclusion

Nous avons vu comment créer des volumes logiques distincts basés sur un disque SAN au travers du protocol iSCSI.

Si cela fonctionne bien, gardez en tête que le fonctionnement de ces disques sera malgré tout assez (voir très) lent. Si la solution se prête bien à des fichiers dont les accès sont peu fréquents (backup par exemple) elle n'est donc pas recommandée pour des fichiers système.

Notre objectif inavoué était d'ailleurs d’utiliser ces disques dans Longhorn, ce qui pourra faire l'objet d'un article ultérieur.

Retour sur l'AWS Summit 2023

2023-04-12T00:00:00Z

Avec plus de 100 sessions, le summit AWS offre l'opportunité à chacun de se créer son propre programme. Le nôtre était orienté autour de nos sujets de prédilections : les conteneurs, le stockage et l'orchestration.

Arrivée au palais des congrès

Pas d'hésitation possible, vu la foule on était certain d'être au bon endroit. Côté organisation les équipes étaient bien calibrées pour gérer le flux de personnes venues assister aux conférences.

Même si les files étaient imposantes on a pu rentrer assez vite. Petite désillusion toutefois côté Grand Amphitéâtre qui faisait salle comble pour la keynote d'ouverture.

Heureusement nous avons pu nous rabattre dans une autre salle proposant une retranscription en live. Bien qu'amputés de la première partie de la conférence nous avons pu retrouver quelques un de nos clients prendre place tour à tour sur scène pour vanter les mérites du passage dans le Cloud chez AWS.

Pas de grande découverte pendant ces passages sur scène millimétrés : AWS offre une panoplie de services adaptés à tous les enjeux, qu'on soit primo entrant dans le cloud ou utilisateurs aguerris.

Pour les premiers c'était l'occasion de rappeler que la dynamique de migration dans le cloud est loin d'être un processus terminé. Pour nous qui y baignons depuis plusieurs années et pour qui cela semble acquis, la présentation d'Alix Boulnois, chief digital officer d’Accor, nous offre une vision tout autre avec un taux de pénétration du cloud dans les sociétés d'hôtellerie qui avoisine les 27% seulement.

Migration de données et les différentes solutions de stockage

Première session technique avec la présentation des différentes options qui s'offre à nous lorsqu'on a besoin de stocker des données avec AWS (hint: elles sont nombreuses).

On a donc parlé d'EBS et de ses différentes options possibles (gp2, gp3…).

Mais également de EFS (service de NFS aux performances et dimensionnement élastique).

Enfin nous avons eu droit à un projet mettant en scène de la recopie de données sur site vers AWS via FTP, traitement des données, création de requêtes sur mesure sur ces données et affichage de tableaux de bord.

Le tout aura mobilisé pas moins de 4 services, avec une intégration assez simple : Datasync, Glue, Athena, Insights.

Nous avons aussi eu droit à une présentation des coulisses d'un court métrage créé par AWS, Picchu.

Il s'agissait de mettre en avant le fait que les studios n'ont plus besoin de maintenir des infrastructures internes lourdes et couteuses pour traiter les fichiers RAW en présentant notamment les services de liens de transfert spécifiques et file cache.

Kubernetes : observabilité des clusters EKS

Dans cette première session autour de Kubernetes nous avons eu droit à une présentation orientée observabilité.

L'occasion de nous rappeler la présence de tout un tas de module «blueprint» disponible pour EKS. Les blueprint représentent des intégrations tierces disponibles sur étagère, pour EKS mais pas que.

On peut de fait les activer très simplement au sein de modules Terraform.

La session a fait un focus important sur OpenTelemetry qui devient le standard de facto pour tout ce qui a trait à l'observabilité autour des 3 piliers suivants : logs, traces et métriques.

Kubernetes : optimisez l'élasticité et les coûts de vos environnements Amazon EKS

Sans doute la conférence la plus intéressante à laquelle on ait assisté. Il s'agissait de montrer comment dimensionner et optimiser un cluster EKS avec l'outil Karpenter.

L'outil dans un premier temps développé de façon autonome va bientôt devenir partie prenante de l'offre Kubernetes managé d'AWS, EKS.

Cette solution offre des possibilité de dimensionnement dynamique du cluster selon la charge. Vous vous demandez sans doute en quoi ce service est différent de l'autoscaling ?

Il s'git ici d'offrir le meilleur ratio performance / coût. Concrètement le service permet d'utiliser plusieurs types d'instance et de rationaliser la charge.

Si mon service tourne actuellement sur 2 instances Mx alors qu'il pourrait tourner sur une seule instance Tx moins chère le service ajustera automatiquement les noeuds de mon cluster.

La démo était particulièrement intéressante en montrant des montées en charge de quelques pods à plus de 6 000. L'outil offre également un instantané du coût mensuel.

Plutôt que de garder quelques noeuds avec moins de 50% de charge utile, le système reschedule les pods sur 1 seul noeud pour maximiser l'efficacité. Il permet également, via configuration, l'utilisation de noeud spot permettant de faire dimuner la note.

Au final l'instantané de facturation passait de +6000$ à moins de 2000. Définitivement un outil sur lequel on va se pencher sérieusement.

Opensearch: la recherche sémantique

La recherche classique par token est basée sur l'utilisation de mots-clés pour trouver des informations pertinentes. C'est le comportement par défaut d'un moteur de recherche, cependant elle ne prend pas en compte la signification ou le contexte des mots, ce qui peut entraîner des résultats de recherche imprécis ou incomplets.

En revanche, la recherche sémantique avec Elasticsearch utilise des algorithmes avancés pour comprendre la signification des mots et leur contexte. Elle permet ainsi de fournir des résultats de recherche plus précis et pertinents, en prenant en compte la sémantique, les synonymes, les homonymes et les relations entre les mots.

Cela a bien été illustré en prenant en exemple le cas de recherche dans un contexte e-commerce. Même si cela est acquis pour toute personne mettant en place un moteur de recherche, cette piqûre de rappel était nécessaire.

Le summit AWS ce ne sont pas que des conférences

Mais aussi l'occasion d'échanger avec les uns et les autres (on y a retroué Suse, Gitlab…) et de faire d'étonnantes découvertes au gré de nos pérégrinations comme le robot spot de Boston Dynamics en balade dans les allées.

Mais également un compteur de cafés serverless.

Ou encore un concours de tir au but avec un terrain bardé de capteurs.

Conclusion

Encore une belle édition pour ce summit AWS. On en repart rechargés à bloc mais également un peu frustrés de ne pas avoir pu en voir plus. On aurait notamment aimé savoir ce qui se trame côté AI mais pour cela on attendra la publication des conférences en ligne.

Exécuter des commandes dans un conteneur avec ECS d’AWS

2022-06-10T00:00:00Z

Pour les projets dont nous gérons l’infrastructure de production, nous utilisons depuis longtemps des outils tels que Rancher et Kubernetes.

Avec kubectl on s’habitue vite au confort de pouvoir visualiser la sortie standard de ses conteneurs, exécuter des commandes à l’intérieur, forwarder des ports. Je vous en parlerai un peu plus à l’occasion si vous voulez.

À l’inverse lorsqu’on utilise les solutions maisons (et fermées) de fournisseurs tel qu’AWS, on se retrouve vite démunis et tributaires du bon vouloir du fournisseur pour nous fournir les outils adaptés.

Le cas ECS

ECS est le service de gestion de conteneurs d’Amazon Web Services. Il s’appuie sur le service historique EC2.

Pour faire simple, vous disposez d’instances EC2 pré-configurées avec un démon Docker, ainsi que d’un orchestrateur qui vient organiser et gérer les conteneurs qui seront répartis sur ces instances.

Dans ce mode de fonctionnement, vous n’avez pas la main sur l’orchestrateur mais les nœuds (instances EC2) restent visibles et potentiellement accessibles. On peut donc s’y connecter, notamment en SSH, et interagir avec les conteneurs qui s’y trouvent.

Toutefois cela pose un certain nombre de problèmes :

obligation d’ouvrir le service SSH, ce qui augmente inutilement la surface d’exposition
définir au préalable sur quel nœud est exécuté le conteneur avec lequel on souhaite interagir
pas de possibilité d’interagir avec les conteneurs depuis la console (UI)

Le cas Fargate

Fargate pousse la logique d’ECS un cran plus loin. Cette fois-ci vous n’avez même plus accès aux ressources sous-jacentes.

Évidemment il y a une infrastructure derrière, mais elle est complètement gérée pour vous, avec la promesse de ne pas avoir à gérer le dimensionnement, la sécurisation, etc.

L’inconvénient par rapport à notre besoin d’interaction avec les conteneurs tient au fait que vous n’avez plus du tout de moyen de vous connecter sur les serveurs ni de rentrer dans les conteneurs par ce biais.

Devant cette situation de blocage AWS a mis à jour son CLI pour proposer des commandes permettant d’interagir avec les conteneurs, quel que soit le système utilisé.

AWS CLI à la rescousse

En premier lieu vous aurez besoin du CLI AWS. Je ne vous fais pas l’affront de paraphraser la documentation pour l’installer.

Une fois réalisé vous aurez également besoin d’installer le plugin Session Manager pour le CLI.

On s’assure que tout est installé correctement :

fuse@archibald:~
→ aws --version
aws-cli/2.6.3 Python/3.9.13 Darwin/21.5.0 source/arm64 prompt/off

fuse@archibald:~
→ session-manager-plugin

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

Pour permettre l’accès au conteneur, AWS utilise son service Systems Manager (SSM) pour établir la connexion au conteneur et vérifier que l’utilisateur exécutant les commandes a les droits suffisants pour ce faire.

Dans les faits, un agent SSM va être monté et démarré dans le conteneur pour permettre l’exécution de commandes.

Rendre l’agent SSM disponible dans les conteneurs

Création et configuration de la politique

Pour mettre en place cet agent nous allons devoir en premier lieu créer une politique (policy) associée :

{
   "Version": "2012-10-17",
   "Statement": [
       {
       "Effect": "Allow",
       "Action": [
            "ssmmessages:CreateControlChannel",
            "ssmmessages:CreateDataChannel",
            "ssmmessages:OpenControlChannel",
            "ssmmessages:OpenDataChannel"
       ],
      "Resource": "*"
      }
   ]
}

Cette politique devra ensuite être rattachée à un rôle dont dispose l’utilisateur qui doit exécuter les commandes.

Utilisation du rôle par les instances

Par défaut, les conteneurs en cours d’exécution ne seront sûrement pas en capacité d’exécuter des commandes.

Nous allons devoir déployer une nouvelle définition de tâche et activer l’exécution de commandes.

Vous pouvez créer une définition de tâche identique à l’actuelle, simplement pour effectuer la mise à jour. En effet, si vous demandez à ECS de passer de la version N à N il ne fera rien.

Il faut lui dire de passer à la N+1, même si elle est identique.

aws ecs update-service --cluster nom_du_cluster \
--service nom_du_service \
--task-definition nom_de_definition_de_tache:version \
--enable-execute-command

Une fois cette commande lancée, ECS ou Fargate va rouler les conteneurs, en en démarrant de nouveaux puis en stoppant les anciens.

Pour vérifier que tout fonctionne correctement on récupère un identifiant de tâche :

fuse@archibald:~
→ aws ecs list-tasks --cluster nom_du_cluster

{
    "taskArns": [
        "arn:aws:ecs:eu-west-1:034473609837:task/nom_du_cluster/63832eb11b4641729c376b95bee02f82",
        "arn:aws:ecs:eu-west-1:034473609837:task/nom_du_cluster/c9b7a91f6cdc43e0a7d6d70835b1db61"
    ]
}

Et on regarde si l’agent est démarré sur cette tâche :

fuse@archibald:~
→ aws ecs describe-tasks \
--tasks c9b7a91f6cdc43e0a7d6d70835b1db61 \
--cluster nom_du_cluster | jq ".tasks[].containers[].managedAgents"
[
  {
    "lastStartedAt": "2022-05-31T17:24:35.002000+02:00",
    "name": "ExecuteCommandAgent",
    "lastStatus": "RUNNING"
  }
]

On voit que l’agent est bien en cours d’exécution, on va pouvoir exécuter nos commandes :

fuse@archibald:~
→ aws ecs execute-command --cluster nom_du_cluster \
--task c9b7a91f6cdc43e0a7d6d70835b1db61 \
--container nom_du_conteneur \
--interactive --command "bash"


The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.


Starting session with SessionId: ecs-execute-command-0ef9e2cdabcb37a0a
root@ip-172-23-4-93:/app#

À vous la gloire et la prospérité, vous pouvez maintenant lancer une commande à l’intérieur de votre conteneur !

Utiliser un registre Elastic Container Registry d'AWS avec Rancher

2022-06-10T00:00:00Z

Rancher, qu'est ce que c'est ?

Rancher est un excellent outil de gestion d'environnements Kubernetes. Il permet d'aggréger vos clusters on premise aussi bien que chez les cloud provider dans une unique interface.

Il offre aussi la possibilité de créer des cluster Kubernetes (avec RKE ou k3s notamment) mais également d'en importer tout en ajoutant une couche d'authentification et de gestion des RBAC (Role Based Access Control).

Cela permet notamment d'ouvrir des accès limités à des namespaces aux équipes de développement pour qu'elles puissent vérifier le bon fonctionnement de leurs applications.

Bref, un outil que nous utilisons depuis des années (la v1 pour être précis), avant que l'intégration de Kubernetes ne remplace ce bon vieux Cattle (dont on trouve encore quelques reliques au niveau des namespaces et des agents).

Authentification des registres

Il y a par contre un point qui pêche en terme d'intégration c'est celle des registres tiers à authentification par jeton.

En matière de sécurité les bonnes pratiques consistent à avoir des jetons d'authentification aux durées de vie controlées et courtes.

C'est ce qu'impose notamment Amazon avec Elastic Container Registry, son service managé de stockage d'images docker.

Evidemment, pour déployer des applications, nos clusters auront besoin d'y accéder au travers de Rancher qui nous propose les solutions suivantes :

Comme on peut le voir on ne dispose que de solutions à base de login / mot de passe. Or, ECR impose l'usage de jetons dont la durée de validité est de 12h maximum.

Fonctionnement de l'authentification ECR

Voyons comment accéder à notre registre ECR depuis un shell, nous aurons pour cela besoin du cli AWS :

aws ecr get-login-password

Cela produira une chaine de ce type, faisant office de mot de passe temporaire :

eyJwYXlsb2FkIjoiQkhNVmppMGpCSEtWQTUxREVvUkN6cEl6QWJ4NXBHNHFPQWJKbXgvenJtNzYwMTF6
[TRUNCATED]
OiIyIiwidHlwZSI6IkRBVEFfS0VZIiwiZXhwaXJhdGlvbiI6MTY4MjAzNzkyMH0

La chaine en question pourra ensuite être utilisée pour s'authentifier sur le registre :

docker login --username AWS --password-stdin ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com

Ou en une seule commande :

aws ecr get-login-password | docker login --username AWS --password-stdin ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com

Dès lors nous pouvons accéder à notre registre de façon transparente, mais pour une durée limitée.

Intégrer un renouvellement de nos accès dans Rancher

Dans Rancher nous voulons garantir que l'accès au registre fonctionnera de manière permanente.

Pour se faire nous devons donc automatiser le renouvellement du jeton. Pour nos besoins j'ai packagé une image disponible sur le hub docker incluant à la fois kubectl et le client aws (fuse/aws-cli-kubectl:0.1.0).

Avant de nous lancer dans la création de notre cron job nous allons renseigner en secret les valeurs nécessaires à l'authentification (aws_account_id, aws_access_key_id, aws_secret_access_key, aws_region).

Puis nous allons dérouler nos commandes dans un pod, qui utilise notre image et injecte notre configuration. Plutôt que de procéder par essai / erreur, on lance une image qui ne fait rien (sleep 3600) à laquelle on s'attache pour éxécuter nos commandes.

apiVersion: v1
kind: Pod
metadata:
  name: ecr-token-renew
spec:
  containers:
  - name: ecr-token-renew
    image: fuse/aws-cli-kubectl:0.1.0
    command: ["sleep", "3600"]
    env:
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          name: aws-ecr
          key: aws_access_key_id
    - name: AWS_REGION
      valueFrom:
        secretKeyRef:
          name: aws-ecr
          key: aws_region
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: aws-ecr
          key: aws_secret_access_key
  restartPolicy: OnFailure

Notre but est de supprimer et de recréer à intervalle régulier le secret contenant les informations de connexion au registre docker.

Notre pod (et notre cron job) étant lancé avec un compte de service (serviceaccount), nous allons vérifier que nous avons les bons droits.

On commence par rentre dans notre conteneur :

kubectl exec -it ecr-token-renew -- /bin/sh

puis on teste les accès :

$ kubectl auth can-i create secrets
no
$ kubectl auth can-i delete secrets
no

De base notre serviceaccount ne dispose pas des droits suffisants. Nous allons donc créer un rôle permettant de réaliser les opérations de type CRUD sur les secrets et lui attacher.

On crée donc le fichier role.yml comme suit :

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: app-namespace
 name: crud-secrets
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Et on l'applique :

kubectl apply -f role.yml

De même on crée l'objet RoleBinding :

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: crud-secrets-binding
 namespace: app-namespace
subjects:
- kind: ServiceAccount
  name: default
  namespace: app-namespace
roleRef:
 kind: Role
 name: crud-secrets
 apiGroup: rbac.authorization.k8s.io

Et on l'applique :

kubectl apply -f role.yml

On peut de nouveau vérifier que tout fonctionne avec kubectl auth can-i.

Suppression et ajout du secret à intervalle régulier

Maintenant que nous avons les bons droits nous allons dérouler les commandes suivantes :

# le nom de notre secret, à votre bon vouloir
SECRET_NAME=ecr-registry-token
# on récupère le token en s'authentifiant (le cli utilise automatiquement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY)
TOKEN=$(aws ecr get-login-password --region $AWS_REGION)
# on supprime le secret sans râler s'il n'existe pas encore (premier run)
kubectl delete secret --ignore-not-found $SECRET_NAME
# on recrée le secret en injectant la configuration qui va bien
kubectl create secret docker-registry $SECRET_NAME \
--docker-server=https://${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com \
--docker-username=AWS \
--docker-password="${TOKEN}"

Une fois qu'on a vérifié que tout fonctionnait correctement de manière interactive il nous reste à packager le tout dans un CronJob qui tournera toutes les 6h (on évite de le faire tourner toutes les 12h pour ne pas être trop juste et se garder de la latitude si une exécution échoue).

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: ecr-token-renew
spec:
  schedule: "0 */6 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: ecr-token-renew
              image: fuse/aws-cli-kubectl:0.1.0
              command:
                - /bin/sh
                - -c
                - |-
                  SECRET_NAME=ecr-registry-token
                  TOKEN=$(aws ecr get-login-password --region $AWS_REGION)
                  kubectl delete secret --ignore-not-found $SECRET_NAME
                  kubectl create secret docker-registry $SECRET_NAME \
                  --docker-server=https://${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com \
                  --docker-username=AWS \
                  --docker-password="${TOKEN}"
              env:
                - name: AWS_ACCOUNT_ID
                  valueFrom:
                    secretKeyRef:
                      name: aws-ecr
                      key: aws_account_id
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: aws-ecr
                      key: aws_access_key_id
                - name: AWS_REGION
                  valueFrom:
                    secretKeyRef:
                      name: aws-ecr
                      key: aws_region
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: aws-ecr
                      key: aws_secret_access_key
          restartPolicy: OnFailure

Conclusion

Dans cet article nous avons vu comment palier au manque d'intégration dynamique des registres dans Rancher en générant nous même des tokens à intervalle régulier.

J'espère qu'il vous sera utile en attendant une solution built in.

S'authentifier avec un facteur tiers en utilisant l'API WebAuthn

2021-09-10T00:00:00Z

La méthode d'authentification la plus courante sur le web n'a pas changée depuis des années, elle nécessite un login et un mot de passe.

Si les applications web se doivent de respecter certains critères de sécurité, il en va de même pour celui ou celle qui se situe entre le clavier et la chaise.

Si vous êtes un utilisateur aguerri, il y a des chances que vous utilisiez un gestionnaire de mot de passe tel que 1Password, Bitwarden ou LastPass.

Dans le cas contraire il y a de fortes chances que vous utilisiez un même mot de passe sur différents services, aussi sensibles soient-ils.

En sachant que tous les sites / applications proposent une fonctionnalité de type «Mot de passe oublié» je vous laisse imaginer les dégâts si quelqu'un venait à accéder à votre boite mail.

Comment faire mieux que le bon vieux couple login / mot de passe ?

Progressivement, des solutions ont été imaginées pour renforcer la sécurité pour les utilisateurs finaux sans que celles-ci ne soient trop compliquées à utiliser.

On a vu l'avènement notamment de solutions 2FA ou MFA. La première désigne l'authentification à 2 facteurs, la seconde en multi facteurs (au moins 2).

Pour accéder au service concerné il faudra donc en plus du mot de passe un complément, comme un mot de passe temporaire reçu par SMS ou un jeton.

Les gestionnaires comme 1Password savent gérer ces jetons (OTP).

Mais cela décale finalement le problème quand vous utilisez le même outil pour stocker à la fois le mot de passe et le générateur de jetons. En effet votre coffre est lui-même protégé par un… mot de passe.

Quelqu'un qui disposerait de votre mot de passe pour un service donné ne pourrait pas s'y connecter car incapable de produire un facteur d'authentification supplémentaire.

Si cet usurpateur dispose par contre du mot de passe de votre coffre il accédera à l'ensemble de vos comptes, encore plus si votre gestionnaire est en charge des OTP.

S'appuyer sur ce qui marche : le chiffrement asymétrique

On a plusieurs exemples d'outils qui s'appuient sur un chiffrement asymétrique : GPG ou SSH pour n'en citer que deux.

La logique est la suivante dans le cas de GPG : un message est encodé au moyen d'une clé (publique) et décodé au moyen d'une clé privée.

Si je veux envoyer un courriel à Tom, j'utilise sa clé publique et il pourra le déchiffrer au moyen de sa clé privée. Toute personne interceptant le message en cours de route ne pourra y voir qu'une suite de caractères incompréhensibles.

L'algorithme étant non réversible il n'est donc pas possible de deviner la partie privée depuis la partie publique.

Introduire ce mécanisme sur le web

Le W3C propose une spécification permettant de porter et utiliser ce mécanisme dans nos navigateurs : WebAuthn.

Elle a beau être en draft, le support des navigateurs est excellent.

WebAuthn s'appuie sur une architecture à 3 parties :

le service auquel on souhaite accéder. Dans le jargon on appelle ça une relying party.
le client accédant au service (on ne parle pas ici de l'utilisateur final mais du système qui va consommer le service, comme un navigateur par exemple)
un mécanisme d'authentification déporté (une clé USB, un capteur Touch ID, un smartphone…). On parle ici d'authenticator.

Les mécanismes d'authentification déportés peuvent être multiples. Un service pourrait vous demander plusieurs mécanismes tiers pour y accéder mais la plupart du temps on peut en enregistrer plusieurs et utiliser l'un de ceux enregistrés.

Personnellement j'utilise une clé Yubikey comme système tiers, mais certains services proposent également Touch ID par exemple.

L'intérêt de ce mécanisme d'authentification est de gérer pour vous les paires « clé publique / clé privée » de façon transparente. Dans le cas d'une clé c'est elle qui est en charge du stockage sécurisé. Touch ID fonctionne quant à lui grâce à une enclave sécurisée qui dispose de son propre logiciel dédié, il fonctionne en dehors du système d'exploitation d'Apple.

On peut voir un exemple d'usage sur le site de démo de yubico. Après avoir enregistré le ou les mécanismes tiers dans son compte on peut s'en servir lors de la connexion.

Ici avec le capteur Touch ID :

Puis avec la clé Yubikey (après l'avoir enregistrée) :

Comment ça marche ?

Le service qui souhaite permettre une authentification avec WebAuthn doit dans un premier temps permettre à l'utilisateur disposant d'un compte d'enregistrer ce mécanisme, afin qu'il soit lié à son compte utilisateur.

Il va l'indiquer au client (navigateur) qui va être en charge de demander au mécanisme d'authentification (authenticator) la génération d'un nouveau couple de clé publique / privée.

Si tout se passe bien, la clé publique sera transmise jusqu'au service qui l'associera au compte.

Pour l'authentification au service, le client transférera les informations au mécanisme d'authentification en précisant de qui vient la requête.

Le mécanisme d'authentification vérifiera la présence de l'utilisateur, par exemple en lui demandant d'appuyer sur le bouton dans le cas d'une clé Yubikey ou en faisant une vérification biométrique dans le cas de Touch ID.

Une fois la vérification effectuée, le mécanisme d'authentification signera les données utiles à l'aide de la clé privée, identifiée par l'identifiant envoyé par le service, et renverra l'assertion au client.

Le client jouera une nouvelle fois le rôle de passe-plat vers le service qui vérifiera la signature obtenue en réponse au défi.

Pour faciliter l'implémentation, les navigateurs proposent des API permettant de gérer la génération de ces couples de clés et plus généralement des mots de passe.

const credentials = new PasswordCredential({
  type: "password",
  id: "fuse",
  password: "hardc0re"
});

navigator.credentials.store(credentials);

Ouvrira cette boite de dialogue bien connue :

Le code suivant permet lui de simuler la création d'un défi (challenge) permettant la création d'une clé publique.

// on crée une chaine de caractères aléatoires matérialisant le défi
const challenge = new Uint8Array(32);
window.crypto.getRandomValues(challenge);

// l'identifiant ici viendrait du service, il ne contient pas
// d'information personnelle mais permettra au service de faire le lien
// entre cet identifiant unique et le compte utilisateur concerné
// Ici j'ai utilisé un mécanisme très robuste à base d'encodage en base64 :)
const user_id = "bWNhdHR5QHN5bmJpb3ouY29t";

const id = Uint8Array.from(window.atob(user_id), (c) => c.charCodeAt(0));

const publicKey = {
  challenge: challenge,

  rp: {
    name: "Mon super service.",
    id: "www.synbioz.com"
  },

  user: {
    id: id,
    name: "mcatty@synbioz.com",
    displayName: "Martin Catty"
  },

  // pubKeyCredParams permet de spécifier les mécanismes de chiffrement
  // autorisés. -7 pour SHA-256, -37 pour RSA, -257 pour RS256.
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },
    { type: "public-key", alg: -37 }
  ]
};

navigator.credentials
  .create({ publicKey: publicKey })
  .then((credentials) => {
    console.log(credentials);
  })
  .catch((error) => {
    console.log(error);
  });

Ce qui nous donne en retour :

PublicKeyCredential { rawid: ArrayBuffer(64), response: AuthenticatorAttestation Response, id: "GhXH3mKw7ayi-my Vorz LUOTDOEE6FqRc7NWCqRGENDgvDm-JpwP900E60YVDABRgyXwyptoMQfiPc9qc@yzuo", type: "public-key" }
  id: "GhXH3mKw7ayi-myVQrz LUẬTDOEE6FqRc7NWCqRGENDgvDm-JpwPgQQE6 ØYVDABRgykXwyptoMQfipc9qc@yZUQ"
  rawId: ArrayBuffer(64)
  response: AuthenticatorAttestationResponse {attestationObject: ArrayBuffer(226), clientDataJSON: ArrayBuffer(139) }
  type: "public-key"
  [[Prototype]]: PublicKeyCredential

Le client va transférer «l'attestation» au service qui sera en charge de vérifier son contenu (qui est chiffré) et si tout est OK il enregistrera la clé publique associée à l'utilisateur concerné.

La prochaine fois, pour permettre l'authentification de l'utilisateur concerné, le service fournira des identifiants de mécanisme d'authentification autorisés (comme vu plus haut il peut y en avoir plusieurs) et lancera un nouveau défi.

Le processus derrière sera globalement le même que celui de l'enregistrement du mécanisme d'authentification.

// l'identifiant de l'attestation récupéré à la création de la clé publique
const credential_id =
  "kt-fb-x1WsKgTe2TW8tOtkIerPhIOVormIM_PXoAc70Uvdb92Vg8UIv3gg_Crvn6WfIQnNNB6gSr-rnpiLUiuw";

const public_key = {
  challenge: challenge,

  allowCredentials: [{ type: "public-key", id: new Uint8Array(credential_id) }]
};

navigator.credentials
  .get({ publicKey: public_key })
  .then((response) => {
    console.log(response);
  })
  .catch((error) => {
    console.log(error);
  });

Conclusion

On le voit, les API à disposition sont matures et permettent déjà d'utiliser des mécanismes 2FA.

De plus en plus de sites ou applications le proposent et il est temps de le généraliser, notamment car la législation en place devient de plus en plus contraignante (on peut citer par exemple la DSP2).

Dans un prochain article nous discuterons de la possibilité d'utiliser des identifiants déportés sur un système tiers via l'API FederatedCredentials.

Productivité : outils et méthodes

2021-06-11T00:00:00Z

Je voudrais aujourd'hui vous parler de productivité, mais aussi et surtout de mon retour d'expérience sur les outils et méthodes qui m'aident à obtenir un bon niveau d'efficience.

On parlera ici plutôt d'efficience dans la mesure où cela ne se limite pas à la seule atteinte de résultats (efficacité) mais aussi et surtout des moyens / efforts à apporter pour les atteindre.

Qu'est-ce qu'on appelle productivité ?

Si on nomme X la production en sortie et Y l'effort en entrée ; je dirais que pour être plus productif on augmente X sans toucher à Y ; pour être plus efficient on diminue Y sans toucher à X.

Dans cet article, mon approche de la productivité est plutôt orientée bien-être / confort / limiter les répétitions, plutôt que compétitivité. Il n'en reste pas moins qu'améliorer la productivité accroît de facto cette dernière.

Poser le diagnostic

Il n'est pas évident de prendre du recul sur son quotidien pour définir ce qu'on peut améliorer.

La première règle, c'est donc de prendre le temps nécessaire pour analyser ce qui nous occupe, ce qu'on a tendance à faire de manière répétitive et s'il existe un moyen d'y consacrer moins d'effort.

Améliorer son environnement

L'environnement global

On n'a pas toujours la main pour prendre les décisions relatives à son environnement de travail, pour autant, c'est un critère fondamental sur lequel il ne faut pas transiger.

Je suis toujours effaré d'avoir en communication des personnes qui passent 8 h par jour sur un matériel misérable. C'est le comble du contreproductif. Est-ce qu'on imaginerait demander à des livreurs d'utiliser des carrioles à chevaux ?

C'est vrai aussi bien pour les machines que pour les équipements associés : micro de bonne qualité, caméra, connexion internet satisfaisante, outil de visio adapté.

Si on mettait bout à bout le nombre de minutes perdues en visio à base de « ma caméra ne fonctionne pas, je n'ai pas de son, tu m'entends ?, ça saccade » je pense qu'on doit facilement perdre à l'échelle nationale, plusieurs années de productivité chaque jour.

Si vous êtes décideur, ne lésinez pas sur la mise à disposition d'un bon environnement de travail.

L'environnement personnel

En termes d'environnement, chacun ses préférences personnelles. Un investissement de productivité que je n'ai jamais regretté c'est le passage à la disposition de clavier « bépo », en 2011.

Elle s'est accompagnée d'un achat de clavier Typematrix, qui m'a accompagné 8 ans avant de laisser la place à un Ergodox.

Alors oui c'est compliqué de changer de disposition quand on s'y est habitué depuis des années, mais honnêtement le jeu en vaut la chandelle.

Vitesse de frappe, précision, moins de fatigue musculaire, le calcul est vite fait.

Pourquoi remiser le Typematrix au placard ? L'Ergodox offre l'avantage d'être splitté (ce qui permet de garder les bras dans la continuité des épaules plutôt que tout serrés) et il est complètement programmable.

J'ai donc pu modifier le layout de base et notamment les quelques touches particulières au niveau des pouces pour avoir quelque chose de confortable et qui me semble naturel à l'usage. J'utilise ces touches par exemple pour changer de musique, mettre en pause, etc.

Par ailleurs l'Ergodox offre la possibilité de gérer plusieurs layouts, en mode permanent ou temporaire.

Concrètement on peut donc appuyer ou maintenir une touche pour changer de layout de façon durable ou simplement tant qu'on maintient la touche.

Je m'en sers par exemple en mode temporaire pour avoir les chiffres sous la main. Tant que je maintiens la touche tout en bas à gauche du clavier, les touches du milieu de la partie droite du clavier se transforme en pad numérique.

L'Ergodox offre par contre l'inconvénient (en collectivité) d'être mécanique et donc bruyant. J'ai donc conservé mon Typematrix au bureau.

Bref, il ne s'agit pas de vous vendre ce produit en particulier, mais d'attirer votre attention sur l'importance que revêt le clavier et la disposition des touches. Votre canal carpien pourrait vous dire merci dans quelques années.

Pour commencer, vous pouvez utiliser des outils de mesure de votre vitesse de frappe ainsi que de votre précision, pour situer votre niveau d'efficience avec votre clavier.

Utiliser les bons outils

Dictée vocale

Au quotidien, je suis amené à rédiger énormément (ticket, email, document, contrat…). Avoir un bon clavier aide bien sûr, mais on dispose parfois de plus efficace encore : la dictée vocale.

Sous Mac OS X je la trouve assez réussie. Je lui ai affecté un raccourci clavier qui me permet depuis n'importe quel champ texte de venir dicter mon contenu.

Évidemment il se perd un peu sur les acronymes, nombreux, de notre métier, mais globalement cela me fait tout de même gagner un temps considérable.

À éviter quand on est dans le même bureau avec ses collègues, mais je l'affectionne tout particulièrement en télétravail.

Ré-organiser les fenêtres avec Spectacle

Un outil que j'utilise au moins 100 fois par jour c'est spectacle. Même si l'outil n'est plus maintenu je continue de m'en servir.

Il permet de déplacer et redimensionner ses fenêtres avec un raccourci clavier. Je peux facilement mettre deux fenêtres côte à côté, basculer une fenêtre sur un autre écran, la centrer sur l'écran, passer en mode plein écran…

Extraire un onglet en tant que fenêtre

Tab to Window/Popup est une extension que j'utilise tout le temps pour transformer un onglet en fenêtre.

Elle offre l'avantage de ré-organiser intelligemment les fenêtres pour que la nouvelle soit visible à côté de l'ancienne notamment.

En attendant que Brave le supporte nativement, l'extension fait son office.

Naviguer dans les pages et les onglets de son navigateur

J'utilise pour cela Vimium. Comme son nom l'indique elle s'inspire de Vim.

Si comme moi vous commencez la semaine plein de bonnes résolutions quant à votre gestion d'onglets et que vous finissez immanquablement avec 128 onglets dès le lundi, le mode recherche d'onglet est particulièrement utile.

Il dispose d'un lanceur type Alfred / Spotlight pour rechercher dans ses onglets.

Elle permet également de trouver et accéder à un élément (lien, champ) de la page sans utiliser sa souris / trackpad.

En tapant f on dispose de raccourcis permettant d'accéder à l'élément surligné. En tapant r on recharge la page.

Le dernier usage que j'utilise régulièrement c'est la possibilité de rechercher dans la page avec simplement /.

Alfred : le spotlight amélioré

S'il ne fallait en garder qu'un ce serait celui-là. Alfred permet de faire tout un tas de choses, regardons-y de plus près.

Chercher

De base, dès qu'on tape quelque chose dans l'invite qui ne correspond pas à un workflow ou un mot clé réservé, Alfred va nous permettre de le chercher, soit en local (en tant que fichier), soit dans un moteur de recherche.

Historique du presse-papier

Une « killer feature » d'Alfred, qui offre un presse-papier amélioré qui enregistre chacun des « copier » et les conserve pendant un temps que l'on peut configurer.

On peut bien sûr rechercher dans cet historique.

Snippet & expansion automatique

Je n'ai aucune aptitude particulière à retenir de longues séries alphanumérique.

Les snippets sont très utiles pour ça, j'y enregistre adresses, numéro de téléphone, numéro de TVA, clé publique GPG…

On peut également utiliser des snippets dynamiques, par exemple en se basant sur la date du jour.

Il est également possible de repositionner le curseur :

Cela va créer un bloc de code utilisable dans du markup et repositionner le curseur entre les délimiteurs.

Ces éléments peuvent se déclencher en lançant une commande spécifique mais également grâce à un système d'auto-expansion.

Comme on le voit dans ma capture d'écran, si je tape acode, cela va déclencher le snippet, où que je sois.

Commandes systèmes

On dispose également de raccourcis pour des commandes systèmes, ici si vous voulez vous déconnecter du système :

Workflow

En enrichissant l'outil de workflow on peut réaliser des actions plus abouties, qui enchainent plusieurs étapes, prennent des paramètres en entrée, etc.

Par exemple pour rechercher dans la documentation de Ruby on Rails :

Le workflow que j'utilise le plus c'est sans aucun doute celui de GitLab.

Avec le raccourci gl je peux dynamiquement sélectionner un projet après avoir tapé quelques caractères :

Puis choisir une action associée :

À noter qu'on peut très facilement modifier les workflow, l'action New issue n'était pas là de base.

Créer ses outils

Quand on ne trouve pas son compte il faut faire ou faire faire ses propres outils. C'est d'ailleurs notre métier que de créer des outils qui facilitent le quotidien de nos clients.

Script pour changer rapidement les labels sur GitLab

Alors évidemment parfois on le fait également pour nous même. C'est le cas récemment avec l'écriture d'un script permettant de faciliter le passage d'un label à un autre.

pl-gitlab

pl-gitlab est un autre exemple d'outil maison, de type CLI, qui s'appuie sur l'API de GitLab et que nous comptons opensourcer.

Il nous permet actuellement de :

créer les X prochaines milestones pour un groupe donné
créer des boards pour chaque milestone avec le paramétrage automatique des colonnes
exporter et importer les permissions sur base d'un fichier YAML qu'on maintient à jour. Concrètement à l'arrivée d'un collaborateur il nous suffit de l'ajouter dans l'équipe, d'appliquer, et il aura accès à tous les dépôts.

Mais également tout un tas d'autres choses qui nous évitent une gestion manuelle et fastidieuse.

Conclusion

J'espère que cet article vous aura appris 2-3 choses. Comme on aime raffiner nos outils et nos méthodes n'hésitez pas à nous dire également quelles sont vos astuces et si vous êtes intéressés par l'ouverture de nos outils sur Twitter.

GitLab userscript to ease label transitions

2021-05-14T00:00:00Z

GitLab

For the past years we, at Synbioz, have been heavy users of GitLab. It progressively became our central tool for day to day job.

This choice has mostly been driven by its devops capabilities.

Otherwise, I have still found its UX quite painful when it comes to change a label on a given issue.

What's wrong with label change on GitLab ?

We have a common workflow based on boards, moving an issue to the right or to the left. Original, isn't it ?

We also have a few automations to help us create boards, milestones etc… automatically ; even define permissions on the whole GitLab, but that's another story.

For now, here is what our boards headers look like:

Sure we can easily drag'n'drop the issue from a column to an other.

When we are doing some testing we can’t satisfied with the issue’s title only.

So let's consider this issue is OK. I will have to remove the current label to validate::functionally and put another one: to validate::technically.

To do so I have to go through no less than 6 (!) steps :

click edit
type a few characters
scroll to the wanted label or use the arrows
click or hit enter to select it
do not forget to «exit» the dropdown to apply the label (you can't use esc key)
remove the old label (this one is easy, just click on the cross)

This is far from ideal from my point of view. When you process a lot of issues this is a massive waste of time and error-prone.

Label proposal

Considering there is always a human decision behind label changes, we can't automatically apply a label based on another one removal or addition.

That's why I decided to make a tiny userscript offering a new section right into the sidebar, called Labels proposal.

Based on the current label and some predefined «states machine», the interface offers to apply the next label.

Clicking on a proposed label will set it on the issue and remove the other ones (only those related to the states we defined).

Removing the labels (by simulating a click on the cross) has the advantage of refreshing this part of the toolbar.

Show me the code

This userscript needs you to install an extension offering the ability to run userscripts beforehand.

I have been a long time user of Greasemonkey that now seems to be superseeded by Tampermonkey.

So this is just JS code that will run inside your browser. Tampermonkey lets you decide when you want to run the script. Could be once the document starts to load, ends to load, or everything has been loaded and executed (especially other scripts). There is also a few other choices detailed in the documentation.

I chose the last one because I needed to ensure labels have been loaded before trying to manipulate them.

// ==UserScript==
// @name         GitLab label proposal
// @namespace    https://www.synbioz.com/
// @version      0.2.0
// @description  Label proposal for GitLab
// @author       Martin Catty
// @include      /^https:\/\/git\.synbioz\.com/.*/issues/\d
// @icon         https://www.google.com/s2/favicons?domain=gitlab.com
// @run-at       document-idle
// @grant        none
// ==/UserScript==

(function () {
  Array.prototype.compact = function () {
    return this.filter((x) => x !== undefined && x !== null);
  };

  const states = [
    ["to do", "doing"],
    ["doing", "to validate::functionally"],
    ["to validate::functionally", ["to do", "to validate::technically"]],
    ["to validate::technically", "to deploy::staging"],
    ["to deploy::staging", "to deploy::production"]
  ];

  const initialStates = states.map((node) => node[0]);
  const transitions = new Map(states);
  const label = document.querySelector(".labels");

  // Create a map from existing labels, using this form :
  // { "label" => [node1, node2] }
  const labelsToNodes = Array.from(
    document.querySelectorAll(".labels .gl-label-text")
  ).reduce((map, node) => {
    const sibling = node.nextElementSibling;
    let scope = "";

    if (sibling !== undefined && sibling !== null) {
      scope = "::" + sibling.textContent.trim();
    }

    const content = node.textContent.trim() + scope;

    // we don't want to keep track of label's node not part
    // of the states we are watching
    if (initialStates.includes(content)) {
      map.set(content, [node, sibling].compact());
    }

    return map;
  }, new Map());

  const nextLabels = Array.from(labelsToNodes.keys())
    .map((label) => transitions.get(label))
    .compact()
    .flat();

  const header = `
      <div class="title hide-collapsed gl-mb-3">
        Labels proposal
      </div>
    `;

  const html = nextLabels.reduce((acc, label) => {
    acc += `
          <div class="hide-collapsed value issuable-show-labels js-value has-labels">
            <span data-qa-selector="selected_label_content" data-qa-label-name="to do" class="gl-label gl-label-text-light"
              style="--label-background-color:#D10069; --label-inset-border:inset 0 0 0 2px #D10069;">
              <a href="#" class="gl-link gl-label-link">
                <span class="gl-label-text label-proposal">
                  ${label}
                </span>
              </a>
            </span>
          </div>
        `;

    return acc;
  }, header);

  const block = document.createElement("div");

  block.className = "block";
  label.after(block);
  block.innerHTML = html;

  const csrf = document
    .querySelector('meta[name="csrf-token"]')
    .getAttribute("content");

  document.querySelectorAll(".label-proposal").forEach((node) => {
    node.addEventListener("click", (event) => {
      event.preventDefault();

      const label = event.target.textContent.trim();
      const url = `/api/v4/projects/${document.body.dataset.projectId}/issues/${
        document.body.dataset.pageTypeId
      }?add_labels=${encodeURIComponent(label)}`;

      const headers = new Headers({
        "Content-Type": "application/json",
        "x-csrf-token": csrf,
        Accept: "application/json"
      });

      fetch(url, {
        method: "PUT",
        headers: headers,
        withCredentials: true
      }).then((response) => {
        if (response.ok) {
          node.remove();

          // remove existing labels
          labelsToNodes.forEach((nodes, key) => {
            // there can be 2 nodes (including the scope), we only need one,
            // they have the same parent
            const node = nodes[0];
            const cross = node.parentNode.nextElementSibling;

            if (cross) {
              const event = new Event("click");

              cross.dispatchEvent(event);
            }
          });
        }
      });
    });
  });
})();

You may not be able to use this script as is, as it's meant for our own workflow, but it should be easy to update and enhance.

I hope this will help some, do not hesitate to leave a message on Twitter.

Webpacker : the highway to hell

2021-05-07T00:00:00Z

Un outil pour les gouverner tous

Note I: dans cet article quand je parle de production il s'agit du mode production plutôt que d'environnement de production.

Note II : Webpacker est une gem permettant d'utiliser Webpack dans une application Ruby.

Note III : Juste parce que j'aime bien les chiffres romains.

Nos applications Rails, dès lors qu'elles quittent nos machines, tournent toujours dans un mode production, aussi bien sur un environnement de pré-production que de revue.

Lorsque nous démarrons de nouveaux projets, nous utilisons notre générateur de projets, répondant au doux nom d'Opsible (car utilisant Ansible) et qui nous permet de mettre en place une application prête à l'emploi, aussi bien localement qu'en production.

Tous nos projets utilisant Docker, l'outil est en charge de mettre en place une configuration fonctionnelle.

Il s'appuie également sur des templates Rails pour nous permettre de créer de pures API ou des monolithes.

Lors d'une nouvelle mise à jour d'Opsible s'est reposée la sempiternelle question : Sprockets et/ou Webpacker ?

Sprockets et/ou Webpacker ?

Si vous lisez le guide Ruby on Rails dédié à Webpacker la réponse est très claire (</troll>) : vous pouvez utiliser les deux pour faire … les mêmes choses.

New Rails apps are configured to use webpack for JavaScript and Sprockets for CSS, although you can do CSS in webpack.

Dans l'équipe notre consensus était clair : Webpack a plutôt vocation à être utilisé lorsqu'on intègre des app riches dans notre monolithe.

Comprenez que dès que l'on souhaite intégrer des frameworks front type Vue.js nous mettons en place Webpacker.

Sauf que celui-ci venait en addition de Sprockets plutôt qu'en remplacement.

Qui peut le plus peut le moins

Dès lors qu'on bascule dans ce setup qui mix les deux approches, ceux qui travaillent sur des parties sans Webpack ont un peu l'impression de se faire avoir.

Ils font tourner les processus nécessaires à Webpacker, notamment un serveur dédié à la recompilation des assets, sans en profiter.

En effet, Webpack offre des avantages non négligeables comme le hot reloading et le hot module replacement, offrant une expérience de développement bien plus fluide.

Dès lors, nous avons décidé pour nos nouveaux projets de ne garder que Webpacker.

De la bonne configuration de Webpacker

Avec Webpacker la règle est simple : tant que vous n'êtes pas en production vous n'êtes pas sûr que ça fonctionne.

Là où Rails nous a habitué à son convention over configuration, dans le contexte de Webpack il semble n'y avoir étonnamment pas de consensus fort sur la bonne façon d'organiser ses fichiers, quand l'utiliser, etc.

Pour matérialiser les soucis qu'on peut rencontrer lors de sa mise en place je vais prendre un cas d'usage dans l'air du temps : l'intégration de Tailwind dans notre application.

La configuration de Webpacker (config/webpacker.yml) est découpée en environnements, vous aurez donc probablement une configuration development et une production à minima (nous y reviendrons).

Notre objectif est de ne garder dans notre layout que les deux balises suivantes :

= stylesheet_pack_tag  "application", media: "all", "data-turbolinks-track": "reload"
= javascript_pack_tag  "application", "data-turbolinks-track": "reload"

Notre configuration par défaut de Webpacker est la suivante :

default: &default
  source_path: app/javascript
  source_entry_path: packs
  public_root_path: public
  public_output_path: packs
  cache_path: tmp/cache/webpacker
  webpack_compile_output: true
  check_yarn_integrity: false
  …

Rien de complexe ici, par défaut nos fichiers seront recherchés dans app/javascript. Les « manifestes » devront se trouver dans le dossier packs. Les dossiers de sortie des fichiers compilés seront dans public/packs.

Sans perdre de temps nous voilà en route pour intégrer Tailwind. L'un des avantages de Webpacker est de pouvoir facilement intégrer des bibliothèques publiées sous forme de paquets NPM.

Ni une ni deux :

yarn add tailwindcss
yarn tailwind init

Puis on configure notre fichier postcss.config.js :

module.exports = {
  plugins: [
    require("postcss-import"),
    require("tailwindcss"), // on ajoute cette ligne uniquement
    require("postcss-flexbugs-fixes"),
    require("postcss-preset-env")({
      autoprefixer: {
        flexbox: "no-2009"
      },
      stage: 3
    })
  ]
};

On part sur une arborescence de la sorte pour organiser notre JavaScript :

app/javascript
├── channels
│   ├── consumer.js
│   └── index.js
└── packs
    └── application.js

Et celle ci pour nos CSS :

app/stylesheet
└── app.scss

Dans notre manifeste application.js on va référencer nos fichiers CSS, c'est une pratique normale de Webpack qui fonctionne sur un mécanisme d'import.

Dès lors que les fichiers CSS ont été référencés, ils sont utilisables dans notre application et cela fonctionne même sans directive d'import de notre manifeste CSS dans notre layout.

import Rails from "@rails/ujs";
import Turbolinks from "turbolinks";
import * as ActiveStorage from "@rails/activestorage";
import "channels";

import "../../stylesheet/app.scss"; // on ajoute cette ligne

Rails.start();
Turbolinks.start();
ActiveStorage.start();

Le torse bombé on relance notre serveur webpack et là, c'est le drame.

Visiblement Tailwind veut la version 8 de PostCSS. Mais cette version n'est pas compatible avec la version stable actuelle de Webpacker (5.3).

Combatif, on ne lâche pas l'affaire, il se trouve qu'il y a une version de Tailwind compatible avec PostCSS 7.

yarn remove tailwindcss
yarn add tailwindcss@npm:@tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9

Magnifique, on peut maintenant écrire des styles dans notre fichier app/stylesheet/app.scss, ceux-ci seront appliqués à la volée.

Profitons-en pour importer également Tailwind (qui n'est pas encore chargé à ce stade), on aura au final dans notre fichier app.scss :

@import "tailwindcss/base";
@import "tailwindcss/utilities";
@import "tailwindcss/components";

Cela fonctionne bien, avec un bémol :

webpack_1  | ℹ ｢wdm｣: Compiled successfully.
webpack_1  | ℹ ｢wdm｣: Compiling...
webpack_1  | ℹ ｢wdm｣: Hash: e0f5684b0fd5ecd26488
webpack_1  | Version: webpack 4.46.0
webpack_1  | Time: 4470ms

Quasiment 5 secondes de compilation, et ce à chaque fois qu'on va introduire une directive dans le fichier. Cela tient au fait que Tailwind contient une tétrachiée de classes utilitaires, prêtes à l'emploi et mises à disposition même si on ne s'en sert pas.

Pour y palier on va découper notre fichier en deux :

app/stylesheet
├── app.scss
└── tailwind.scss

Le nouveau fichier tailwind.scss ne contiendra que les directives relatives à ce dernier. Lorsqu'on édite notre fichier app.scss, on revient à des temps acceptables :

webpack_1  | ℹ ｢wdm｣: Compiled successfully.
webpack_1  | ℹ ｢wdm｣: Compiling...
webpack_1  | ℹ ｢wdm｣: Hash: 9f7a514f5e27f38ab57e
webpack_1  | Version: webpack 4.46.0
webpack_1  | Time: 156ms

Maintenant que tout est en ordre il faut qu'on prépare notre configuration pour la production. Si la balise suivante est inutile en local, elle le sera en production :

= stylesheet_pack_tag  "application", media: "all", "data-turbolinks-track": "reload"

On va donc créer notre manifeste :

app/javascript/packs
├── application.js
└── application.scss

Qui contient les même instructions :

@import "../../stylesheet/tailwind.scss";
@import "../../stylesheet/app.scss";

On rajoute quelques directives dans notre fichier app.scss et là surprise, notre build prend de nouveau 5 secondes !

webpack_1  | ℹ ｢wdm｣: Compiling...
webpack_1  | ℹ ｢wdm｣: Hash: 36fdd1b07e74458fd268
webpack_1  | Version: webpack 4.46.0
webpack_1  | Time: 4754ms
webpack_1  | Built at: 04/27/2021 2:35:27 PM

Et oui dès lors que notre manifeste est déclaré, l'ensemble des fichiers qui y sont référencés vont être surveillés et compilés.

Pour éviter cela nous avons décidé de déclarer le manifeste dans un dossier qui ne sera utilisé que pour la production.

production:
  <<: *default

  additional_paths: ["app/stylesheet"]

app/stylesheet
├── app.scss
├── packs
│   └── application.scss
└── tailwind.scss

S'en est tout de mes pérégrinations dans le pays merveilleux de Webpack(er). Je vous ai toutefois laissé avec un problème à résoudre, celui de retirer les CSS inutilisées dans votre build de production (autrement le fichier Tailwind pèse quelque 3Mo non compressé).

Si vous avez des avis / astuces / bonnes pratiques sur la façon de dompter ce monstre qu'est Webpack, n'hésitez pas à engager la conversation sur Twitter.

Tour d'horizon de dry-type, dry-struct et dry-validation

2021-05-07T00:00:00Z

En attendant la sortie d'Hanami v2, qui possède quelques gems dry-rb en dépendances et après qu'Émilie nous a fait découvrir dry-transformer, passons à dry-struct, dry-types et dry-validation.

J'ai récemment eu l'occasion de les mettre en œuvre dans le cadre d'une application Ruby on Rails assez conséquente.

Je suis toujours frileux à l'idée d'ajouter de nouvelles dépendances, surtout dans des codebases déjà volumineuses ; mais les gems dry-rb ont cet avantage d'avoir elles-mêmes très peu, voire aucune dépendance.

Dans le contexte de dry-struct on a :

spec.add_runtime_dependency "dry-core", "~> 0.5", ">= 0.5"
spec.add_runtime_dependency "dry-types", "~> 1.5"
spec.add_runtime_dependency "ice_nine", "~> 0.11"

Sachant que j'avais aussi besoin de dry-types ont est somme toute sur un nombre de dépendances limité et souvent maintenues par les mêmes personnes.

Si vous vous dites que toutes ces gems semblent assez similaires et répondent aux mêmes usages c'est tout à fait normal pour une première impression.

Mais dry a cette philosophie très unixienne d'un outil par usage, quand bien même il semble y avoir des recouvrements.

Pourquoi utiliser ces gems ?

Le contexte métier était de récupérer une entrée avec plusieurs paramètres pour établir une simulation financière.

Dans ces entrées on pouvait avoir le genre, le métier, les revenus, etc. Certains paramètres étaient optionnels, d'autres non. Certaines valeurs étaient libres, d'autres contraintes. Pour certains paramètres on voulait des valeurs par défaut, mais pas toujours.

Bref rien de très exotique, mais je voulais évidemment éviter de me retrouver avec une action énorme dans un contrôleur enchainant les if / else et plutôt avoir une classe dédiée qui serait facile à tester en isolation.

Dans Rails on aurait pu partir sur ActiveModel, mais ici j'ai préféré m'aventurer avec Dry::Struct, dans l'optique de créer un service auquel je passerai directement mon entrée depuis mon contrôleur.

Dans l'action de mon contrôleur j'ai simplement :

def controller_action
  simulator = RetirementSimulator.build(
    user: current_user,
    status: params.dig(:params, :status),
    gender: params.dig(:params, :gender),
    career_start_year: params.dig(:params, :career_start_year),
    net_mensual_salary: params.dig(:params, :net_mensual_salary),
    forecast_annual_increase_rate: params.dig(:params, :forecast_annual_increase_rate),
    executive: params.dig(:params, :executive),
    established_official: params.dig(:params, :established_official),
    desired_mensual_saving_efforts: params.dig(:params, :desired_mensual_saving_efforts),
    desired_age_at_retirement: params.dig(:params, :desired_age_at_retirement)
  )
  response = simulator.call
  render json: response.payload, status: response.status
end

J'utilise donc uniquement l'action comme un passe-plat. En termes de tests, l'idée était de créer des « profils », c'est-à-dire des jeux de paramètres, certains cohérents, d'autres non et d'en vérifier la sortie.

Avec ce setup mes tests offrent l'avantage d'être complètement indépendants du reste de l'application et je n'ai globalement que ma classe à tester pour m'assurer que tout fonctionne comme attendu.

RetirementSimulator.build renvoie une instance d'objet qui peut varier. Si les paramètres ne sont pas valides, il s'agira d'un objet de type NullRetirementSimulator. Autrement il peut s'agir d'un objet de type OpenStruct, qui sera en charge de renvoyer le payload et le statut au même format.

def call
  save
  OpenStruct.new(payload: as_json, status: :ok)
end

dry-types

dry-types va nous permettre, entre autres, de vérifier et/ou caster automatiquement nos paramètres dans le format attendu.

Dans un mode strict (ex : attribute :age, Types::Strict::Integer), si vous passez une valeur non autorisée pour votre attribut vous vous ferez jeter.

Dans un mode coercible, dry-types essaiera de caster pour vous les valeurs passées. Si vous passez la chaine de caractères "18" pour l'âge, il la convertira automatiquement en entier.

Pour cela il utilisera uniquement les méthodes mises à disposition par Ruby au niveau kernel, par exemple "18".to_i.

Pour les types qui ne sont pas directement convertibles avec Ruby il faut utiliser Types::Params, par exemple Types::Params::Bool que l'on va retrouver juste après et qui peut transformer "1" en true par exemple.

dry-types permet aussi d'ajouter des contraintes sur les valeurs, gérer des énumérateurs, des valeurs optionnelles, bref toutes les choses dont on va avoir besoin.

dry-struct

dry-struct est lui construit au-dessus de dry-types. Au lieu d'utiliser dry-types comme un mixin vous pouvez créer votre propre classe qui disposera des méthodes de dry-types.

Étant donné qu'on crée un service utilisable en isolation, ça colle plutôt pas mal 🙂

Voilà quelques morceaux choisis de notre code que l'on détaillera juste après :

class RetirementSimulator < Dry::Struct
  STATUS = Dry.Types::String.enum('employee', 'independent', 'official')

  transform_types do |type|
    if type.default?
      type.constructor do |value|
        value.nil? ? Dry::Types::Undefined : value
      end
    else
      type
    end
  end

  attribute :user, Dry.Types.Instance(User)
  attribute :status, STATUS.optional
  attribute :career_start_year, Dry.Types::Coercible::Integer.optional
  attribute? :average_annual_increase_rate, Dry.Types::Coercible::Float.default(0.0)
  attribute :executive, Dry.Types::Params::Bool.optional

  delegate :year_of_birth,
           :profile,
           to: :user
end

Du côté des évidences, la partie enum nous permet de gérer notre attribut status qui prendra l'une des valeurs autorisées.

On peut bien sûr demander à un attribut d'être d'un certain type (interne à Ruby ou non), c'est le cas ici avec Dry.Types.Instance(User).

La notion de attribute? (avec le ?) permet de définir qu'un attribut est optionnel, si la clé est absente la validation n'échouera pas.

À ne pas confondre avec optional qui indique que la valeur n'est pas requise, mais dans ce cas la clé doit tout de même être présente !

Un attribut peut être optionnel mais avec une valeur par défaut. Si la clé n'est pas passée on utilisera alors la valeur prédéfinie (c'est le cas de average_annual_increase_rate).

Dans le cas contraire on utilisera ce qui est passé (si cela respecte le type ou que c'est castable).

Vous voyez dans l'exemple différents types de données, Integer, String, Float et Bool.

Dans dry-types une valeur nil est considérée comme valable, elle ne sera donc pas résolue sur la valeur par défaut, ce qui n'est pas forcément ce qu'on veut.

C'est un comportement qui a changé selon les versions et qui a été sujet à discussions.

Au passage, c'est un point qui peut être irritant dans dry, il faut être vigilant sur des comportements qui peuvent changer d'une mineure à l'autre et que vous aurez parfois du mal à retrouver dans la documentation.

C'est notre bloc transform_types, à première vue pas très élégant, qui permet de changer ce comportement et d'utiliser la valeur par défaut si elle existe quand on reçoit nil.

Je n'ai pas inventé l'eau chaude sur ce point, c'est la méthode officielle conseillée.

Gérer les objets invalides

Dans le cas où nos paramètres ne respecteraient pas notre spécification, le constructeur nous renverra une exception Dry::Struct::Error.

Ce qui nous permet dans notre méthode build, appelée depuis notre constructeur, de gérer cela très simplement :

def self.build(**args)
  simulation = new(args)
  # here comes the magic
rescue Dry::Struct::Error
  NullRetirementSimulator.new(payload: {}, status: :unprocessable_entity)
end

En effet, en héritant de dry-struct j'hérite d'un constructeur par défaut qui me permet de directement passer mes arguments pour construire un objet disposant d'accesseurs sur les attributs mis en place.

Dans le cas où mon objet est invalide, car ne respectant pas les contraintes définies, j'utilise le pattern Null Object Pattern (NullRetirementSimulator est une bête classe avec 2 accesseurs) qui permettra de renvoyer les valeurs et statuts HTTP voulus dans le cas où mon entrée est invalide, sans avoir à le gérer comme un cas particulier dans l'action de mon contrôleur.

Et dry-validation alors ?

Ah ! Je vous ai caché un petit morceau dans le snippet ci-dessus, la partie "here comes the magic".

Son travail est de, selon les paramètres passés, appeler le bon simulateur (ce sont des simulateurs différents selon que la personne ait travaillé dans le privé ou dans le public, etc.).

J'utilise donc le pattern adapter en m'assurant que mes simulateurs, quels qu'ils soient, répondent à la même interface. Ma classe RetirementSimulator agit comme un routeur.

Au sein de ces simulateurs spécifiques je veux valider d'autres choses, qui ne sont plus du domaine des paramètres reçus via HTTP mais uniquement de la logique métier.

Pour cela on va définir un contrat :

class RetirementSimulatorContract < Dry::Validation::Contract
  STARTING_YEAR_TO_COMPUTE_SUPPLEMENT = 1973

  params do
    required(:year_of_birth).value(:integer)
    required(:career_start_year).value(:integer)
  end

  rule(:career_start_year) do
    key.failure("career has to start after 1972") if value < STARTING_YEAR_TO_COMPUTE_SUPPLEMENT
  end

  rule(:career_start_year, :year_of_birth) do
    if values[:career_start_year] - values[:year_of_birth] < 14
      key.failure("is too early, can't start working before 14")
    end
  end
end

Notre contrat va valider que la personne qui lance le simulateur n'indique pas avoir commencé à travailler avant 14 ans ni avant 1972.

Pour cela Dry::Validation::Contract nous permet de définir des rules qui vont prendre un ou plusieurs paramètres en entrée.

On mixe ici des valeurs qui viennent d'une part de notre base de données (year_of_birth, qui vient de notre objet user) et d'autre part de nos paramètres (career_start_year) ; on voit donc bien qu'on n'est plus uniquement dans une logique de validation d'entrée.

Pour invoquer ce contrat c'est aussi simple que :

contract = RetirementSimulatorContract.new
res = contract.call(
  year_of_birth: simulation.year_of_birth,
  career_start_year: simulation.career_start_year
)

Les éventuelles erreurs se trouveront dans res.errors.

Conclusion

Ces gems dry offrent une manière élégante (à mon avis) de garder du code propre et testable de façon isolée. Qui plus est, le nombre limité de dépendances permet de facilement venir greffer ces outils dans une codebase existante.

Cela peut donc être un excellent moyen de tirer vers le haut la qualité d'une base de code ayant déjà un peu de vécu de façon progressive et sans avoir à modifier l'existant.

Pas à pas pour héberger son site sur S3 avec un certificat SSL

2017-08-24T00:00:00Z

La mode est au statique et c'est une bonne nouvelle !

Avoir besoin de gérer un serveur applicatif pour servir un site de contenu n'a pas un grand intérêt. Il existe à l'heure actuelle une flopée de générateurs qui vous permettront localement de démarrer un serveur pour rédiger votre contenu, apercevoir le rendu puis générer le site en HTML avant de le déployer.

L'objet de cet article n'est pas de se focaliser sur ces outils, mais si vous avez besoin de pointeurs sachez que Jekyll ou Pelican font le job.

Pourquoi ?

Imaginons que vous ayez un site HTML à héberger, soit issu de la génération d'un outil, soit parce que vous écrivez directement vos pages HTML. Comment l'héberger simplement ?

Vous n'avez pas envie d'aller configurer un Nginx, encore moins Apache, ni même de prendre un serveur spécialement pour ça.

Vous savez que Let's Encrypt c'est cool mais ça fait 3 fois que vous oubliez de renouveler vos certificats à l'issue des 3 mois et votre fichu cron de renouvellement automatique ne fonctionne pas…

Si vous ne vous sentez pas familier d'un de ces soucis, vous êtes sans aucun doute un barbu qui a automatisé toute son infra avec Terraform et qui a maintenant les doigts de pied en éventail devant son écran.

Autrement voyons ensemble comment déployer simplement son site sur S3.

Héberger son site HTML

Partons d'une bête page HTML que je souhaite utiliser pour mon site web personnel :

<html>
  <body>Hello World !</body>
</html>

Créer un bucket S3

Partons à l'abordage de l'austère interface d'AWS. Si vous n'avez pas encore de compte créez-en un, je vous épargne le pas à pas.

Une fois connecté rendez-vous dans le service S3.

Maintenant créons un bucket en utilisant comme nom celui de notre site, dans mon cas martin.catty.fr. Il est important d'utiliser le DNS exact. Libre à vous de choisir la région, j'ai gardé l'Irlande qui est le choix par défaut sur mon compte.

On n'active aucune des propriétés type versioning, journalisation, etc.

Créer un utilisateur dédié

Il est de bon ton de restreindre l'accès à vos buckets. J'ai tendance à avoir un utilisateur dédié par bucket, ce qui permet de limiter les dégâts en cas de compromission de l'accès (notamment une fuite de clés). Nous nous rendons cette fois dans le service IAM de gestion d'identité de l'interface.

On crée un utilisateur qui n'aura accès à AWS que par le biais de l'API, il ne pourra pas se connecter directement à l'interface.

En termes d'autorisation, on attache directement une stratégie existante.

En fait ma stratégie n'existe pas encore, donc je vais la créer via le bouton dédié. Je souhaite ajouter une police d'utilisation permettant à cet utilisateur d'accéder à ce bucket.

Dans le nouvel onglet on choisit « Créer votre propre stratégie »

Vous pouvez nommer votre stratégie comme bon vous semble, j'ai choisi AccessToWebsiteBucket. Je vous laisse faire preuve d'imagination pour la description.

{
  "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::martin.catty.fr"
    },
    {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::martin.catty.fr/*"
    }
    ]
}

Cette police me donne accès à la racine du bucket et au reste. Je vous conseille de la tester avec le bouton « Valider la stratégie » avant de la créer. Une fois terminé, revenez sur l'écran de création de l'utilisateur et rafraîchissez la liste des stratégies.

Je vois maintenant apparaître la police que je viens de créer, je la choisis et je passe à la suite. L'écran suivant est capital, il vous donne les informations de connexion relatives à votre utilisateur ; conservez-les précieusement elles ne seront plus accessibles une fois la page fermée.

Configuration du profil et utilisation du client AWS

Nous allons maintenant installer le client AWS. Vous pouvez l'installer via brew install awscli sur OSX ou encore en utilisant pip, le gestionnaire de paquets de python.

Il est temps de configurer nos credentials (ID de clé d'accès et clé d'accès secrète) que nous avons récupéré de l'interface AWS.

Pour ce faire nous allons créer le fichier ~/.aws/config et configurer notre profil :

[profile martin-catty]
aws_access_key_id = XXX
aws_secret_access_key = YYY

Vous pouvez donner le nom que vous souhaitez à votre profil. Nous pouvons maintenant vérifier que nous avons accès au bucket avec ce profil en utilisant le client AWS :

aws s3 ls s3://martin.catty.fr --profile martin-catty

Si tout se passe bien, la commande ne renverra… rien. C'est normal notre bucket est vide. Poussons-y un fichier pour nous assurer que tout fonctionne.

touch /tmp/foo
aws s3 cp /tmp/foo s3://martin.catty.fr --profile martin-catty
upload: ../../../../../tmp/foo to s3://martin.catty.fr/foo

A priori tout est en ordre, si vous relancez la commande pour lister le contenu de votre bucket vous y verrez votre fichier foo. Sur le même principe mettons-y notre fichier index.html.

Activer l'hébergement sur le bucket S3

Nous savons dorénavant mettre des fichiers dans un bucket, activons l'hébergement de site avec S3. Pour ce faire, retour dans l'interface AWS, service S3, on clique sur notre bucket, onglet propriété.

On active la propriété « Hébergement de site Web statique » en indiquant que le document d'index sera index.html.

En suivant le point de terminaison donné par AWS (dans mon cas http://martin.catty.fr.s3-website-eu-west-1.amazonaws.com/), on aura droit à une 403. C'est normal, de base le reste du monde n'a pas accès à notre bucket, fort heureusement.

Il faut donc ajouter une police au niveau du bucket cette fois, dans l'onglet « Autorisations ».

{
  "Version":"2012-10-17",
    "Statement":[{
      "Sid":"PublicReadGetObject",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::martin.catty.fr/*"]
    }
  ]
}

Celle-ci permet à n'importe qui de lire les fichiers dans le bucket. En rafraîchissant on a maintenant notre index.

Mettre en place un certificat SSL gratuitement

C'est bien, mais on souhaite que le site soit disponible à travers HTTPS, sans avoir à acheter de certificats ni à gérer le renouvellement.

Chez AWS il y a un service pour ça : Certificate Manager. Avant de démarrer le processus assurez-vous de basculer sur la région «Virginie du Nord» car c'est un pré-requis du service dans lequel nous allons utiliser notre certificat.

On suit le processus, qui nous enverra une confirmation par email pour vérifier que nous sommes bien propriétaires du site.

Une fois la requête approuvée, notre certificat est prêt. La subtilité de ces certificats est qu'on ne peut pas les récupérer pour les utiliser à l'extérieur d'AWS, vendor locking quand tu nous tiens.

Nous allons donc devoir le rattacher à une distribution CloudFront.

Utilisation de CloudFront avec un certificat SSL

CloudFront est un CDN, c'est-à-dire qu'il permet de diffuser des contenus au plus près des utilisateurs, en les répliquant dans différents points de présence.

Cela permet de limiter la latence et les temps d'affichage quel que soit l'endroit dans le monde où se situent nos utilisateurs.

Nous créons donc une distribution de type web.

Pas d'inquiétude devant ce formulaire copieux, allons-y pas à pas. Dans le nom du domaine d'origine nous choisissons notre bucket qui doit être listé.

Niveau stratégie de protocole on choisit de rediriger automatiquement HTTP vers HTTPS.

Plus bas dans les paramètres de distribution ont saisit comme domaine alternatif martin.catty.fr, on choisit le certificat précédemment créé et on crée la distribution.

Enfin nous définissons index.html comme objet racine par défaut.

Le processus de création de la distribution prend un peu de temps, notez toutefois dans un coin le DNS de la distribution CloudFront.

Configurer votre nom de domaine

Il ne reste plus qu'à faire pointer votre nom de domaine sur la distribution CloudFront, pour cela il vous suffit d'enregistrer votre nom de domaine en tant que CNAME de la distribution CloudFront.

Si vous utilisez Route53 (le service de DNS d'Amazon Web Services), c'est un peu différent, créez un enregistrement de type A. Choisissez oui par Alias et vous devriez maintenant pouvoir choisir la distribution CloudFront dessous.

Voilà c'est terminé !

Certes il y a quelques étapes à parcourir pour y arriver mais maintenant pour mettre à jour votre site, il suffit d'une simple commande avec le client AWS telle que :

aws s3 sync . s3://martin.catty.fr --profile martin-catty

Cette commande va copier uniquement les fichiers modifiés vers votre bucket. Temps de déploiement : 3 secondes !

Les différents profils de marathoniens

2017-05-25T00:00:00Z

Il y a quelques jours j'ai pu participer à l'édition 2017 de la route du Louvre, le marathon qui rallie Lille à Lens.

Autant vous dire qu'un marathon ça donne un peu de temps pour réfléchir, surtout quand on a rien du profil Kenyan.

Et justement en parlant de profil, tout ce temps ~~libre~~ de souffrance m'a permis d'identifier quelques-uns des profils qui se lancent dans l'aventure marathonienne. Laissez-moi vous les décrire.

Le vrai

Parti dans la première vague il démarre en trombe et donne littéralement l'impression de voler. À prendre en photo lors du départ car c'est la dernière fois qu'on le verra.

Celui qui reste dans la roue

Depuis le départ il vous suit. Au début vous vous dites que c'est sympa d'avoir quelqu'un qui court à la même vitesse que vous. Sauf qu'il va rester derrière tout du long, plus docile qu'un berger allemand dressé pendant 5 ans.

Mais aussi beaucoup plus fourbe ; car oui, il va vous doubler dans les 100 derniers mètres.

Le campeur

Il démarre la course avec un sac à dos type barda militaire. Il est paré à toute éventualité et si le besoin s'en fait sentir il peut sortir sa tente et camper avec 3J de vivres à disposition. Bonus point : la tente est équipée d'un paratonnerre.

Le feu follet

Il n'est pas tant là pour la course que pour se faire remarquer. Seul fada à partir au sprint il s'arrête au km 5 en prétextant le coup du lacet. Il abandonnera au km 10 à cause d'un caillou dans la chaussure cette fois.

Le déguisé

Parce qu'un marathon n'est pas assez difficile il se rajoute un petit challenge : le courir déguisé. Pour ce «tout pour la blague» c'est mission réussie : fou rire garanti.

Le faux

Comme le vrai il démarre sur les chapeaux de roues. Pourtant il ne semble pas beaucoup plus préparé que vous, ce qui finit de vous ruiner le peu de moral qu'il vous restait. Mais ça c'est avant que vous ne découvriez qu'il fait en fait le marathon en relais avec une équipe de 3 autres personnes.

Celui qui ne paye pas de mine

Avec son 1.50m et ses 45kg il semble un peu frêle. Pour autant ce petit roquet risque de vous laisser scotché au bitume. À prendre en photo avec le vrai s'il reste de la place sur la pellicule.

La petite vessie

Visiblement celui-là dispose d'une vessie aussi épaisse qu'un poix chiche desséché. Pour lui c'est pose pipi toutes les 5 min. Se retrouve souvent dans la catégorie «Courant alternatif» également.

Le monument

Sorti tout droit d'un marvel, il mesure 2m et son profil est loin du profil «type». Sauf que son mollet fait la taille d'une cuisse et qu'il va aller jusqu'au bout.

Le à la va-y-comme-je-te-pousse

Faire un marathon ça ne doit pas être si dur après tout. A mi-chemin entre folie et inconscience ce marathonien débutant a pris le parti de ne pas s'entraîner. Une chance sur deux de le retrouver soit sur la ligne d'arrivée soit en pleine crise de tachycardie dans un ravin.

Le courant alternatif

Apparemment pas sur le même voltage que les autres il alterne entre lièvre et tortue. Peut-être qu'il fait le marathon en fractionné.

Le blessé

Qui se décompose en deux sous-catégories :

Le vrai blessé. Juste surhumain, il a beau être blessé il ira jusqu'au bout. D'ailleurs il finirait à cloche pied s'il fallait.
Le faux blessé. D'habitude il le boucle en 2h30, sans cette fichue douleur à la cheville…

Le coup du lacet

Il s'arrête «juste une seconde» en vous glissant un «m'attend pas, je te rattrape». Évidemment vous ne le reverrez qu'à une prochaine soirée entre amis où il vous dira qu'il avait dû rentrer pour conduire son fils aux urgences pour cause d'arête avalée de travers.

Le malade

Quand tu le croises tu es à la fois bluffé et honteux d'être derrière car il porte un t-shirt du genre :

Si vous aussi vous avez participé à un marathon dites-moi quels profils vous avez croisé ? Autrement je vous laisse imaginer dans quelle catégorie je me situe :)

Docker on steroid avec xhyve et NFS

2017-04-25T00:00:00Z

Je dois avouer que je suis vraiment fan des solutions de conteneurisation. Le fait de pouvoir packager ses applications est un vrai gage de sérénité.

Dans un contexte SI où vous avez 10+ applications avec des technologies différentes, simplifier et harmoniser votre processus d'onboarding et homogénéiser votre processus de déploiement est également un réel gain de productivité.

Mais il faut garder un œil critique et les technologies comme Docker viennent avec leurs pendants de problèmes.

Aujourd'hui je voudrais adresser le problème des performances dans un contexte OSX. Si vous vous demandez pourquoi je n'utilise pas Docker Native for Mac, c'est parce qu'il apporte lui aussi son lot de limitations dont deux vraiment bloquantes de mon point de vue : une mauvaise gestion du nettoyage des images et des limitations réseau qui sont propres à OSX.

Sympa ce petit paragraphe planqué dans la doc, n'est-ce pas ? L'espace est le nerf de la guerre avec Docker. Si vous n'êtes pas en capacité de nettoyer derrière vous, vous allez au devant de problème sérieux. Par ailleurs l'absence d'interface réseau dédiée empêche d'allouer des IP aux conteneurs et donc de faire du DNS.

Si vous avez paré à ces problèmes en utilisant Docker for Mac, les commentaires sont ouverts.

Avant d'avoir écarté Docker Native for Mac (qui n'existait pas encore quand j'ai commencé à utiliser Docker) je me suis assez naturellement penché sur l'utilisation de VirtualBox. Et j'y suis resté.

À vrai dire tout fonctionne bien avec VirtualBox, à un bémol près, c'est lent. VirtualBox en lui même est un facteur mais ce n'est pas le principal. Ce qui pénalise vraiment les performances ce sont les I/O. En effet le partage de fichiers lors de l'utilisation d'un volume se fait au travers de la VM via vboxfs qui est horriblement lent.

Une solution possible est d'utiliser la bonne veille NFS pour gérer les I/O. Et pour se passer de VirtualBox on peut utiliser l'hyperviseur natif d'OSX (présent depuis Yosemite). Ces deux points peuvent être adressés en utilisant le driver xhyve.

Si vous préférez utiliser des outils magiques qui font tout pour vous, regardez du côté de docker-sync. Personnellement je préfère utiliser les outils bruts, car la magie a toujours un prix (© Rumplestiltskin).

Installation d'une machine virtuelle avec xhyve et NFS

On va commencer par installer le driver docker-machine :

brew install docker-machine-driver-xhyve
sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

On va maintenant pouvoir créer la VM à proprement parler :

docker-machine create --xhyve-cpu-count=2 --xhyve-memory-size=8192 --xhyve-disk-size=30000 --xhyve-experimental-nfs-share=true -d xhyve dev

En terme de ressources au niveau CPU et RAM je prends le parti de lui allouer la moitié des ressources disponibles sur ma machine et 30Go de disque. Pour l'ensemble de ces ressources il s'agit de la valeur max que la VM ne dépassera pas.

La machine est provisionnée en utilisant boot2docker, comme lorsqu'on utilise VirtualBox. Elle est maintenant utilisable en l'état, toutefois je vais la customiser un peu, notamment pour en modifier la gestion des DNS et le réseau utilisé.

En effet je souhaite garder ma VM utilisant VirtualBox pour en assurer la transition sans heurt. Je vais donc utiliser un sous réseau différent du réseau de base utilisé par boot2docker (172.17.0.0) pour faire cohabiter mes deux VM en simultané. Je souhaite aussi que mes conteneurs utilisent un résolveur qui tournera en conteneur dans la VM pour se retrouver par leur nom.

Vous vous demandez peut-être pourquoi j'ai besoin de cela plutôt que d'utiliser des links. Simplement car je ne souhaite pas que mes conteneurs ne puissent discuter qu'avec des services auxquels ils sont liés.

Par exemple app1.synbioz.dev doit pouvoir parler avec app2.synbioz.dev sans que j'aie quoi que ce soit à déclarer au préalable. Pour ce faire j'ai besoin d'une résolution de nom.

Pour appliquer ces modifications rentrons donc dans la VM :

$ docker-machine ssh dev
$ sudo -s
# mv /var/lib/boot2docker/profile /var/lib/boot2docker/profile.bak

À l'intérieur de la VM on est un peu pauvre en éditeur, on va donc se rabattre sur ce bon cat.

# cat << EOF > /var/lib/boot2docker/profile
EXTRA_ARGS='
--label provider=xhyve
--bip 172.18.0.1/16
--dns 172.18.0.1
--dns 8.8.8.8
'
CACERT=/var/lib/boot2docker/ca.pem
DOCKER_HOST='-H tcp://0.0.0.0:2376'
DOCKER_STORAGE=aufs
DOCKER_TLS=auto
SERVERKEY=/var/lib/boot2docker/server-key.pem
SERVERCERT=/var/lib/boot2docker/server.pem
EOF
# exit

On redémarre la VM :

docker-machine restart dev

et on se positionne sur le démon :

eval $(docker-machine env dev)

Vérifions que tout fonctionne correctement en lançant un nginx dont le port 80 sera publié, c'est à dire mappé de l'hôte vers le conteneur.

docker run --rm -p 80:80 nginx

On vérifie que tout fonctionne bien :

open "http://$(docker-machine ip dev)"

Cela devrait vous ouvrir la page de nginx sur l'IP 192.168.64.1 (si vous créez différentes VM cette IP s'incrémentera).

Notre objectif est maintenant de faire en sorte que www.synbioz.dev nous affiche la page d'accueil de nginx sans avoir à publier de port sur l'hôte (ce qui nous empêcherait de faire tourner plusieurs nginx par exemple, problème existant avec Docker Native).

Lançons maintenant notre résolveur avec dnsdock :

docker run -d -v /var/run/docker.sock:/var/run/docker.sock --name dnsdock --restart=always -p 172.18.0.1:53:53/udp tonistiigi/dnsdock

Je vous passe ici le fonctionnement du résolveur mais si cela vous intéresse n'hésitez pas à le demander en commentaire.

Récupérons l'adresse IP de notre dnsdock :

$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' dnsdock
172.18.0.2

On voit que le conteneur démarre bien sur notre réseau en 18 et non en 17. Voyons si on peut le pinger :

$ ping 172.18.0.2
PING 172.18.0.2 (172.18.0.2): 56 data bytes
Request timeout for icmp_seq 0

Notre hôte ne sait pas comment router ces paquets vers nos conteneurs. C'est normal, notre table de routage ne comprend pas de route pour. Nous allons donc l'ajouter en demandant au système de passer par la VM lorsqu'il veut acheminer des paquets vers les IP en 172.18.x.y.

# /sbin/route -n add -net 172.18.0.0 -netmask 255.255.0.0 -gateway $(docker-machine ip dev)

Attention cette route n'est pas persistée lorsque vous redémarrez votre machine. Pour faire en sorte qu'elle soit appliquée à chaque redémarrage je vous conseille d'utiliser un fichier plist.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC '-//Apple//DTD PLIST 1.0//EN' 'http://www.apple.com/DTDs/PropertyList-1.0.dtd'>
<plist version='1.0'>
<dict>
  <key>Label</key>
  <string>com.docker.route</string>
  <key>ProgramArguments</key>
  <array>
    <string>bash</string>
    <string>-c</string>
    <string>sudo /sbin/route -n add -net 172.18.0.0 -netmask 255.255.0.0 -gateway $(docker-machine ip dev)</string>
  </array>
  <key>KeepAlive</key>
  <false/>
  <key>RunAtLoad</key>
  <true/>
  <key>LaunchOnlyOnce</key>
  <true/>
</dict>
</plist>

Placez-le dans /Library/LaunchDaemons/com.docker.route.default.plist. On ne peut pas le placer dans notre ~/Library car la commande a besoin des droits du super utilisateur. Il ne vous reste qu'à l'activer :

# launchctl load /Library/LaunchDaemons/com.docker.route.default.plist

Attention ces fichiers plist ont comme pré-requis que votre VM soit démarrée. Personnellemente je préfère ne pas démarrer ma VM au démarrage de ma machine et ne les utilise donc pas.

On va ensuite désactiver le filtrage des adresses IP sur cette interface réseau, de sorte à pouvoir échanger sur des IP 172.18.x.y et pas uniquement 192.168.64.z.

Regardez quelle est la propriété member de ifconfig bridge100. Chez moi c'est en6, si vous avez autre chose adaptez la commande suivante.

# ifconfig bridge100 -hostfilter en6

Vous pouvez vous faire un fichier plist pour cette commande également, en gardant à l'esprit que vous devrez aussi automatiser le démarrage de la VM au lancement de votre machine.

Vous devriez maintenant pouvoir pinger vos conteneurs :

$ ping 172.18.0.2
PING 172.18.0.2 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: icmp_seq=0 ttl=63 time=0.329 ms

Relançons notre Nginx en lui donnant un alias DNS de sorte à ce que dnsdock puisse faire le mapping entre celui-ci et l'IP du conteneur nouvellement lancé :

docker run --rm -e DNSDOCK_ALIAS=www.synbioz.dev nginx

Voyons si notre résolveur sait nous retourner l'IP de notre conteneur :

$ dig @172.18.0.1 www.synbioz.dev

; <<>> DiG 9.8.3-P1 <<>> @172.18.0.1 www.synbioz.dev
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6337
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.synbioz.dev.  IN A

;; ANSWER SECTION:
www.synbioz.dev. 0 IN A 172.18.0.3

;; Query time: 5 msec
;; SERVER: 172.18.0.1#53(172.18.0.1)
;; WHEN: Wed Apr 12 10:53:40 2017
;; MSG SIZE  rcvd: 64

Visiblement tout fonctionne bien. Il ne reste plus qu'à indiquer à notre système d'utiliser ce résolveur pour le TLD .dev.

# echo "nameserver 172.18.0.1" > /etc/resolver/dev

C'est terminé, vous voilà prêt à faire tourner vos applications dans votre VM avec de biens meilleures performances.

Compte rendu de l'apéro Ruby Nord d'avril

2017-04-11T00:00:00Z

Cela faisait quelques temps que je n'étais pas allé à un apéro ruby et je n'ai pas été déçu. 3 présentations au programme que je vous détaille tout de suite.

Rails avec Docker

En premier lieu Yann nous a montré comment faire tourner Rails avec Docker. Étant donné que l'on utilise Docker depuis mi 2015 chez Synbioz et qu'on l'a systématisé l'an passé sur tous nos projets (rails ou pas) j'avoue que je pensais m'ennuyer un peu.

J'avais tout faux, Yann a su rendre ça très intéressant et concret, en partant d'une codebase classique qu'il a progressivement «dockerisée». J'y ai au passage découvert dinghy qui facilite la création d'une machine virtuelle utilisant l'hyperviseur de base d'OSX (en lieu et place de VirtualBox), couplé à un partage NFS pour les volumes.

Au final je n'ai pas gardé dinghy mais je me suis repenché sur Xhyve (qui possède un driver docker-machine et le partage NFS en experimental). Les performances sont très prometteuses et l'usage de NFS permet de propager les événements du système de fichiers hôte vers le conteneur, ce qui fonctionne mal à travers VirtualBox et oblige à lancer les serveurs avec des commandes de polling.

Au delà de conteneuriser une application en développement uniquement, Yann est allé jusqu'à la production et nous a présenté à l'occasion Kontena.

Il s'agit là d'une plateforme qui va permettre de gérer toute la chaine classique des conteneurs : stockage (registre), gestion des stacks, gestion des variables d'environnement, orchestration etc…

Autre point appréciable, la plateforme est agnostique en terme d'IAAS car compatible avec Azure, AWS, Google Cloud et plein d'autres.

Étant en plein dans le sujet en ce moment avec Rancher, cela tombait à point nommé pour le mettre en concurrence.

Lien vers les slides de Yann

Dégemification

Bob quant à lui nous a parlé de ses déboires avec Draper lors de sa migration d'une application vers Rails 5.

En effet, il s'est retrouvé face à des erreurs un peu absconses avant de se rendre compte qu'elles venaient de Draper, une gem non compatible avec Rails 5.

S'en est suivi l'éternelle question : est-ce que je bascule sur un fork, est-ce que j'attends une éventuelle mise à jour ? Et ce d'autant plus que le code à modifier pour re-faire fonctionner la gem était vraiment limité.

Puis avec un peu de recul plusieurs questions de fond apparaissent : comment s'assurer que ma gem sera maintenue dans le temps ? Y investir du temps et/ou de l'argent peut être une solution mais dans ce cas précis le mainteneur semblait juste avoir déserté, ce qui arrive plus souvent qu'on ne le pense.

Vient donc la question naturelle suivante : est-ce que j'ai vraiment besoin de cette gem ? Fait-elle vraiment énormément de choses que je ne pourrais pas faire moi-même ?

Bob a fini par répondre par la négative à cette question et a donc implémenté le pattern decorator à sa sauce, en utilisant SimpleDelegator.

En conclusion : gardez vos Gemfile les plus fins possibles et choisissez vos gem avec précaution.

Lien vers les slides de Bob

Rails et l'asset pipeline

Enfin David nous a retracé le couple Rails / assets (aka «je t'aime moi non plus») depuis la version 3 de Rails.

De la logique de «Je mets tout dans public/assets et basta» (pre Rails 3.1), en passant par les gems rails-* qui ont du mal à suivre les cycles de mise à jour des paquets npm (sans compter que le projet rails-assets a failli mourir), le vendor/assets et lib/assets pour en arriver à Sprockets.

La présentation retrace tout ce que gère Sprockets (processeurs, transformeurs, compresseurs, directives, env, manifest, pipeline, etc).

Pour simplifier le tout, Rails 5.1 utilisera Yarn et Webpack. David nous a donc présenté dans les grandes lignes, son fonctionnement et son intégration dans Rails.

Lien vers les slides de David

Au final un vrai bon cru Ruby Nord, merci à tous ceux qui l'ont rendu possible.

Dragonfly, Nginx et contenu partiel

2017-03-22T00:00:00Z

En utilisant Dragonfly nous nous sommes rendus compte qu'au moment de servir des vidéos pour Safari et Safari mobile depuis notre application Rails, cela ne fonctionnait pas.

En creusant un peu il s'avère que Safari est assez exigeant puisqu'il impose un support du byte-range de la part du serveur qui sert la vidéo.

C'est à dire que le player veut pouvoir demander une tranche de la vidéo uniquement, de sorte à gérer sa mise en cache et ne pas nécessairement tout télécharger d'un coup. Il demande donc un contenu partiel (code HTTP 206).

Pour cela il envoie un entête byte-range dans la requête et attend en retour un entête Accept-Ranges si le serveur le supporte.

Exemple :

curl --verbose --range 0-99 https://example.com/video.mp4 -o /dev/null

Comme notre serveur le supporte nous recevons ce type d'entête :

Accept-Ranges: bytes
Content-Range: bytes 0-99/55766047
Content-Type: video/mp4
Content-Length: 100

À qui la charge de renvoyer des réponses partielles ?

La première idée serait de faire en sorte que notre application Rails puisse produire des réponses partielles.

En fouillant un peu il existe un ticket ouvert sur le projet Dragonfly accompagné d'un gist qui vise à introduire un nouveau middleware en charge de produire un morceau de réponse depuis le fichier final.

Je pense que c'est une mauvaise idée de s'appuyer sur ce code pour plusieurs raisons :

parce que c'est mal de copier/coller des gist sortis de nul part et vieux de 5 ans
ce code effectue une lecture bit à bit particulièrement lente et qui impose de travailler sur le fichier complet
autant que faire se peut, on souhaite éviter que ça soit Ruby qui fasse ce traitement car il sera nécessairement (plus) lent
Nginx sait le faire de base et sans doute infiniment mieux et plus vite

Une autre solution serait d'utiliser Rack::File qui gère les entêtes de type range mais autant utiliser notre reverse proxy pour faire ce travail plus efficacement.

Faire en sorte que Nginx traite nos requêtes partielles

La première chose à faire est de demander à Nginx de prendre la main lorsque nous renvoyons des fichiers (send_file) dans Rails de sorte à ce que le flux de requêtes soit géré ainsi :

Pour cela nous activons l'entête qui va bien :

config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'

Ce paramètre peut être configuré soit par environnement dans le fichier correspondant, soit dans le fichier config/application.rb pour l'ensemble des environnements. Attention toutefois à la précédence, car si vous mettez la configuration dans les deux fichiers c'est celle du fichier d'environnement qui prendra le pas.

Une fois fait, lors des demandes de fichier, Rack enverra un entête à Nginx en lui demandant de charger le fichier et en joignant une réponse (body) vide.

Côté Rails, le travail est fini. Il a passé la main à Nginx et peut passer à la requête suivante.

C'est bien gentil mais Nginx a besoin de savoir où trouver le fichier en question. Dans le cas d'une requête type https://example.com/files/foo.zip le mapping est simple, la configuration de Nginx utilise le répertoire public de Rails comme root et il va donc le trouver sans configuration supplémentaire.

Dans le cas de Dragonfly, on a des URL un peu plus complexes type /media/W1siZiIsIjIwMTcvMDMvMDEvMTI/video.mp4?sha=ueiu

Dragonfly utilise Rack::Cache pour mettre en cache les réponses et les servir plus rapidement. Il faut donc que nous expliquions à Nginx comment servir ces requêtes.

En premier lieu nous allons raffiner un peu la configuration de Rack::Cache pour définir où nous voulons stocker notre cache.

Dans le fichier application.rb, pour le généraliser à tous les environnements, ou dans production.rb pour la production uniquement, nous remplaçons config.action_dispatch.rack_cache = true par :

config.action_dispatch.rack_cache = {
  verbose: false,
  metastore: URI.encode("file:#{File.expand_path(Rails.root.join('../../shared/cache/dragonfly/meta'))}"),
  entitystore: URI.encode("file:#{File.expand_path(Rails.root.join('../../shared/cache/dragonfly/body'))}")
}

Ici nous sommes dans le cadre d'un déploiement Capistrano, on veut donc stocker le cache dans le dossier shared pour qu'il persiste les différents déploiements (attention à purger le cache de temps à autre).

Maintenant il faut que Nginx prenne connaissance de ces URL afin de pouvoir les servir. Dans sa configuration nous allons définir ces chemins comme internes :

location /chemin/complet/vers/dragonfly/body {
  internal;
  alias /chemin/complet/vers/dragonfly/body;
}

Ici location et alias sont identiques mais, sans même parler de Rails, on pourrait faire en sorte que Nginx serve les fichiers depuis /var/uploads lorsqu'il reçoit une requête sur /files :

location /files {
  internal;
  alias /var/uploads;
}

Dans ce cas, si on demande /files/foo.zip il servira /var/uploads/foo.zip. Dernière chose à faire côté Nginx, renvoyer un entête de mapping des fichiers.

location {
  proxy_set_header X-Accel-Mapping /chemin/complet/vers/dragonfly/body=/chemin/complet/vers/dragonfly/body;
}

Lorsque Rack va recevoir cet entête de mapping, il va pouvoir en retour indiquer où se trouve le fichier à aller chercher (car l'URL d'entrée est toujours /media/…) et demander à Nginx de le servir directement via l'entête 'X-Accel-Redirect'.

En clair, il va lui dire /media/zzz se trouve dans /chemin/complet/vers/dragonfly/body/A1 et Nginx pourra le servir lui même.

J'espère que cet article vous aidera à servir des contenus partiels dans le cas d'une stack Rails + Nginx ou tout du moins à délester votre serveur applicatif en confiant à votre reverse proxy le soin de servir vos fichiers.

Vault en production

2017-03-02T00:00:00Z

Un backend différent avec S3

À présent nous avons gardé notre coffre en mémoire. Si notre conteneur s'arrête notre coffre est perdu. Voyons une solution plus pérenne avec un backend S3 par exemple.

L'objectif est donc que Vault aille écrire ses fichiers dans un bucket. L'utilisateur (ou système) final n'a pas besoin d'accéder à ce bucket.

Le paramétrage est très simple puisque le backend S3 est intégré de base. Paramètrons le fichier config.hcl :

backend "s3" {
  bucket = "nom"
  access_key = ""
  secret_key = ""
  region = ""
}

listener "tcp" {
 address = "0.0.0.0:8200"
 tls_disable = 1
}

Par défaut la région est us-east-1. Si votre bucket utilise cette région vous n'avez pas besoin de le préciser. Pour le reste il vous suffit de remplir les informations nécessaires.

Toutefois vous pouvez utiliser des variables d'environnements plutôt que ces valeurs, solution qui a ma préférence. Dans ce cas dans un fichier un plat, par exemple .env on peut avoir :

AWS_ACCESS_KEY_ID=
AWS_DEFAULT_REGION=
AWS_S3_BUCKET=
AWS_SECRET_ACCESS_KEY=

Il nous reste à lancer notre conteneur :

docker run --rm --name vault-server --env-file .env --cap-add IPC_LOCK -v $(pwd):/vault vault server

Vous pouvez maintenant lancer un client et l'utiliser exactement comme avant.

J'ai passé quelques temps à comprendre pourquoi j'avais systématiquement une 403 sur mon bucket quand je lançais avec le backend s3 alors qu'hors docker je n'avais pas ce souci. Il s'avère que l'heure n'était pas correcte dans mon conteneur. J'ai pu m'en rendre compte en testant avec le cli aws dans ce dernier. Si vous utilisez une VM pour lancer vos conteneurs (notamment si vous utilisez boot2docker) assurez vous que celle ci est à l'heure. Si ce n'est pas le cas vous pouvez utiliser le fichier /etc/localtime de votre hôte :

docker-machine scp /etc/localtime machine-name:/tmp/localtime
docker-machine ssh machine-name 'sudo mv /tmp/localtime /etc'

Les points de montage

Un peu plus haut je vous expliquais que nous utilisions le point de montage secret par défaut. Voyons voir ce que sont ces points de montage.

Par défaut nous avons quelques points de montage déjà disponibles :

/ # vault mounts
Path        Type       Default TTL  Max TTL  Description
cubbyhole/  cubbyhole  n/a          n/a      per-token private secret storage
secret/     generic    system       system   generic secret storage
sys/        system     n/a          n/a      system endpoints used for control, policy and debugging

À l'image d'un système de fichier les points de montage gèrent chacun les même opérations (lecture, écriture…) mais pas de la même façon. Par exemple un système de fichier peut être chiffré mais les opérations accessibles en entrée ou en sortie seront les mêmes. Pour les points de montage c'est la même chose.

Par exemple un point de montage AWS ne va pas stocker les secrets de façon brute, à l'inverse du point de montage generic. Il faut garder en tête que les backend sont cloisonnés. Un backend ne peut pas aller lire les clés d'un autre backend et c'est également vrai pour les jetons «utilisateurs».

Les points de montage peuvent donc être montés et démontés simplement :

vault mount aws
Successfully mounted 'aws' at 'aws'!

Partageons nos secrets avec Vault

2017-02-24T00:00:00Z

Combien de fois avez-vous pesté car vous n'aviez plus les credentials pour vous connecter sur un environnement de staging ou de production ?

Vous importez un dump en dev et vous vous dépêchez d'aller changer le mot de passe en console car vous ne connaissez pas celui que vous avez importé ?

Ou vous lancez un conteneur sans être sûr qu'il ne manque pas des variables d'environnement ou que leurs valeurs sont à jour ?

Pour répondre à ces problématiques, arrêtez de vous envoyer des mots de passe dans Slack, il existe Vault, maintenu par Hashicorp parmi leur excellente suite d'outils.

Pourquoi utiliser Vault ?

Vault vise à résoudre les problématiques suivantes :

partage d'informations sensibles de manière sécurisée
contrôle d'accès avec possibilité de révoquer des accès
granularité via des polices permettant de ne partager que certaines données d'un coffre

Par ailleurs chez Synbioz nous avions quelques pré-requis avant de choisir un outil particulier :

pas de dépendance à un système de stockage particulier
open source (non, le fait qu'un système soit fermé n'est pas garant de sécurité)
utilisable en CLI (et donc automatisable)

Dans le déroulé nous allons donc voir tour à tour comment lire et écrire dans un coffre de façon basique, utiliser les jetons, intégrer PGP dans la boucle et enfin sceller et desceller un coffre.

Dans un deuxième article nous verrons comment utiliser un backend de stockage différent avec S3, des points de montage pour sécuriser l'accès à différents services, se servir de Vault pour provisionner des variables d'environnement utilisées dans un conteneur et enfin mettre son service Vault derrière un Nginx.

À la découverte de Vault

Voyons tout de suite un exemple d'utilisation. J'utilise Docker pour tester, mais vous pouvez sans doute l'installer avec votre package manager favori :

docker run --name vault-server vault

Par défaut Vault va démarrer en mode développement, c'est à dire qu'il sera accessible sur l'interface de loopback (127.0.0.1), sans sécurité particulière (pas de TLS ni de jeton d'accès).

Le log nous explique comment faire pour se connecter à Vault.

RNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://0.0.0.0:8200'

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: VJconzd1Ogx60tDSFZPlb0VW0J5Ekh+GmqtdJ0vC/jM=
Root Token: 145a0045-b35e-8624-fa0c-aef810667f34

On va maintenant lancer un client en passant en variable d'environnement l'URL et le jeton :

docker run --link vault-server -e VAULT_ADDR=http://vault-server:8200 -e VAULT_TOKEN=145a0045-b35e-8624-fa0c-aef810667f34 -it vault sh

Si vous n'utilisez pas docker en développement vous aurez juste à exporter VAULT_ADDR dans un shell différent comme indiqué au démarrage du serveur.

On peut maintenant commencer à écrire un secret :

vault write secret/hello value=world

Et consulter nos secrets :

/ # vault read secret/hello
Key               Value
---               -----
refresh_interval  768h0m0s
value             world

Ici secret représente le point de montage par défaut, nous sommes obligés d'utiliser ce préfixe (nous y reviendrons dans le deuxième article). Pour le reste nous pouvons utiliser le nombre de sous niveaux que nous voulons. Dans notre cas nous utilisons une arborescence de type client/projet/environnement.

Rien ne nous empêche d'écrire plusieurs clés / valeurs d'un coup. Attention toutefois, si vous écrivez foo=bar puis bar=baz, la deuxième instruction va tout écraser, il faut donc utiliser soit des namespaces différents soit repasser l'ensemble des clés / valeurs.

Vault, quand il est lancé en tant que serveur, est accessible via une API au travers d'HTTP. Dans notre conteneur client, on pourrait très bien faire :

curl -X GET -H "X-Vault-Token:$VAULT_TOKEN" http://vault-server:8200/v1/secret/hello
{"request_id":"929e52b1-dcda-6082-702a-2a17e7faa292","lease_id":"","renewable":false,"lease_duration":2764800,"data":{"value":"world"},"wrap_info":null,"warnings":null,"auth":null}

En dehors du mode développement

Dans notre exemple précédent nous avons utilisé la clé root pour lire et écrire dans le coffre. C'est clairement une pratique à proscrire. La clé root doit uniquement servir à gérer la configuration du coffre.

Sortons un peu du mode développement pour explorer le fonctionnement de Vault. Vault fonctionne avec des fichiers de configuration HCL, qui est une syntaxe de plus haut niveau que JSON (c'est à dire que des fichiers JSON sont lisibles par un parseur HCL, l'inverse n'est pas vrai).

Voici notre fichier config :

backend "inmem" {
}

listener "tcp" {
 address = "0.0.0.0:8200"
 tls_disable = 1
}

Nous relançons notre serveur en conteneur :

docker run --rm --name vault-server -v $(pwd):/vault vault server

Notre fichier de configuration viendra donc prendre la place /vault/config dans notre conteneur pour surcharger le fichier par défaut.

Pour le moment nous restons sur le backend inmem pour in memory. On écoute sur 0.0.0.0 plutôt que l'interface de loopback car on accédera à notre conteneur depuis un autre conteneur. Si vous testez localement, 127.0.0.1 est suffisant.

Si nous lançons notre conteneur de cette façon nous allons tomber sur cette erreur : Error initializing core: Failed to lock memory: cannot allocate memory.

Par défaut mlock est activé et permet d'empêcher l'écriture de la mémoire dans la swap. La première solution est de désactiver mlock dans notre fichier de configuration disable_mlock = true. C'est acceptable en développement mais pas en production.

Nous allons donc donner quelques pouvoirs en plus à notre conteneur avec -cap-add :

docker run --rm --name vault-server --cap-add IPC_LOCK -v $(pwd):/vault vault server

Nous avons également désactivé TLS, ce que nous ne ferions pas en environnement de production, notre server Vault ne doit pas être accessible sans certificat.

Connectons-nous avec notre conteneur client :

docker run -it --link vault-server -e VAULT_ADDR=http://vault-server:8200 vault sh

Étant donné que notre serveur n'est pas lancé avec l'option -dev, le coffre n'est pas initialisé.

vault init

Vault va nous générer un certain nombre de clés cette fois, en plus de la clé maîtresse (initial root token) :

Unseal Key 1: dF42haxHtfRsFQH7FSwKEYW+u2988+pETp20GX1wZK4B
Unseal Key 2: qlkaWcv1+uwlMLRFsxXIIZ8HdcNo2R8YchRkE+Ft2u8C
Unseal Key 3: gsF8DlJJRSH7CBnQsudrv/a/F4opmYfzM2Ee5VWxLgYD
Unseal Key 4: BQXqS6NIk8NHuONQ44Ob2ri3ITDm4qspJFPiIO6m1pME
Unseal Key 5: LZ2MHDr0LA6ZgE7F4nE4RNEPQ3mnojPCZSaY1lp6InoF
Initial Root Token: 8733cbf6-679d-9ebd-a207-f67c560ded2a

Ces clés permettront de desceller le coffre. La protection du coffre repose sur un partage des clés, selon l'algorithme de Shamir ; c'est à dire qu'il est nécessaire de posséder un certain nombre de clés pour accéder au coffre.

Par défaut Vault est configuré de manière à ce qu'il faille 3 clés sur les 5, mais il est possible de changer ces deux chiffres via la configuration. Nous en verrons un exemple un peu plus bas.

Si vous êtes paranoïaque ou curieux quant à cet algorithme, sachez que son auteur n'est autre que le co-inventeur de [RSA](https://en.wikipedia.org/wiki/RSA_(cryptosystem).

Rappel : la clé maîtresse a vocation à protéger ces clés-ci, pas à accéder directement au coffre. Cette clé est en fait attachée à la policy root, la police principale, qui a tous les droits.

Ces clés elles-même servent à récupérer l'accès au coffre, par exemple s'il a été scellé (manuellement ou si Vault redémarre)

Pour générer un jeton d'accès nous allons donc nous connecter avec notre jeton root via :

vault auth

On se connecte avec le jeton root et on lance la création d'un jeton via :

vault token-create

Qui nous donne :

Key              Value
---              -----
token            1a792fec-18c5-63fa-fea6-ff5801cc3227
token_accessor   95c9ec10-207a-bd14-8633-ab31136b579a
token_duration   0s
token_renewable  false
token_policies   [root]

Vous avez compris les grands principes concernant la lecture, l'écriture et la protection du coffre. Allons maintenant un peu plus loin pour faire en sorte que l'utilisateur A puisse accéder au coffre Synbioz, le B au coffre client et le C au deux.

Pour cela il nous faut mettre en place des polices d'accès. Ces polices sont gérées comme le reste via des fichiers HCL. Dans /vault nous créons le fichier synbioz.hcl :

path "*" {
  policy = "deny"
}

path "secret/synbioz/*" {
  policy = "write"
}

Et client.hcl :

path "*" {
  policy = "deny"
}

path "secret/client/*" {
  policy = "write"
}

Notre stratégie est celle de la liste blanche, nous bloquons l'accès à toutes les ressources par défaut, pour définir ensuite lesquelles sont accessibles.

À noter que les polices peuvent être ajoutées à chaud via un client connecté avec le jeton root :

vault policy-write synbioz synbioz.hcl
vault policy-write client client.hcl

Nous pouvons maintenant créer un jeton d'accès avec ces polices :

vault token-create -policy synbioz

Ce qui nous donne:

Key              Value
---              -----
token            1d78e687-ec82-fcd3-6b9a-47c8446fc3b6
token_accessor   59fa5cd9-90c9-719c-3be7-7d5a4dbe7cc0
token_duration   768h0m0s
token_renewable  true
token_policies   [default synbioz]

Nous sommes prêts à écrire dans le coffre Synbioz :

vault write secret/synbioz/website/production foo=bar

Et à lire :

vault read secret/synbioz/website/production

Le format par défaut est de type table :

Key               Value
---               -----
refresh_interval  768h0m0s
foo               bar

Mais on peut également utiliser json ou yaml :

vault read -format json secret/synbioz/website/production
{
  "request_id": "3fc38113-d333-9df3-5132-87110a1e3465",
  "lease_id": "",
  "lease_duration": 2764800,
  "renewable": false,
  "data": {
    "foo": "bar"

  },
  "warnings": null
}

Par contre si j'essaie de lire les informations du namespace client :

vault read secret/client/website/production

Error reading secret/client/website/production: Error making API request.

URL: GET http://vault-server:8200/v1/secret/client/website/production
Code: 403. Errors:

* permission denied

Pour créer un jeton d'accès ayant plusieurs polices, il suffit de répéter le paramètre policy :

vault token-create -policy client -policy synbioz

Dans ce cas notre jeton aura les droits des deux polices. Les polices peuvent parfaitement être modifiées à chaud. L'effet des modifications est immédiat.

Évidemment on peut à tout instant révoquer un jeton via :

vault token-revoke token

Sécuriser ses jetons avec PGP

Pour aller un cran plus loin en terme de sécurité on peut faire en sorte de chiffrer les jetons avec des clés PGP. Vault sait s'interfacer directement avec le service Keybase, que nous utiliserons dans l'exemple ci-dessous. Toutefois il est tout à fait possible d'utiliser directement le client GPG. À l'initialisation du coffre :

vault init -key-shares=3 -key-threshold=2 -pgp-keys="keybase:fuse,keybase:fuse,keybase:fuse"

Ici on va donc définir que le coffre est protégé par 3 clés et qu'il en faut au moins 2 pour le déverrouiller. Mon exemple n'est pas très intéressant car les 3 jetons seront chiffrés avec ma clé publique. L'intérêt est de chiffrer ces clés avec les clés de personnes différentes pour faire en sorte qu'un quorum soit nécessaire pour sceller / desceller le coffre.

On récupère la même chose qu'auparavant excepté que les clés sont chiffrées :

Unseal Key 1: wcBMA3BSIcJ3gMZmAQgACglV/1XRqo556XEwhA1q5tRzFo89d4kSuWOZpYU+KS8eyGMdYI+Uzw3+Ts9pxrCpg7VfDPQSlK39qys4QPH6jasqv/uR7LNYOjddDw8gQLxYc1m3VQP+4Gvz94yNEeLz0h1AcKoBoJZO3kmoLiqao6MYlMLfB6RlurY5A441UtqrfmtTU+l6vSsL8PO+t2UXw4HwFQSEAaBiX7cVLvUvsPk2B2RNdVb9JB/TyUilRpHe8cV6ijV1yZlr5oqMR9vR1L3cN03c9SGgoqj/we1VG5d36ucsCui90H3gEWH2snMfWKh8TXR8xX04QbP2ssmUcj2WzK73iuBFmqcSpDcPHtLgAeRRbXvR3p4HfceZcsaD+SED4cIS4AbgJOEDieAQ4jIgFb3geebkBw1Oxq+D8pJl03zToGrYIoUfFSXTQbPt8gqBBTbHsbtDERbYS3f1n/hwhgHiboX9XJ04WNMkAP1QiHk2xZqe4Lvh06zgvOT5WbGEGf2WeumSOBkcwEMj4u5TQUvhJqwA
Unseal Key 2: wcBMA3BSIcJ3gMZmAQgAuMcRamfiG4cgdsuhkSjipWgyk0z3zDYlbflzOB2T9YwN6+1LhoPcK26N/RHwNsM/FDI67WYYGEhohDkisdBqhBQt7TCogsJjIoV0EpUiiqowxJH/rEr6AUQdgMSt5NbabzMypHyFz3SXKGijmZLqW66lfQ3aY9Hc1M4H/p/2BLQA9elI39UJbIElIP6NnNYGy7CDD/s6jyHeVSoqmC1E1ma6GyaQFEDUDhUzSbacW/dPjIqDcA8DIlHJDJKjZ4u7tKXQkr2dI2DWEpckc/i7W5+29c4PYG7P8+nS+xwV/1ydOJ+DLV6XJDGyOS8tBaLYOcIUY0d1S5jXtP8Sqf9ELdLgAeS2sm1ppwUrtkdZZJz46E+u4W3F4O/gF+F1PeA54qsbk7PgR+YcVdEa831YEzGcotCb7scie+lHLx5vCZPT5oRD2kBgUlXGctU64DfaoeTDska9Pq29e6Yb5h0a3CiqIWwbO7s24BjhtyXgseSsPs+1xPzP0sYD93Gateq54s1D4aTh3FgA
Unseal Key 3: wcBMA3BSIcJ3gMZmAQgA6MnGDWZMcUk9s9pxu5/cmE1DxFyKeAjJ54UApsPQy3IEWe72N8bFx0jzXYNQ13XZxfZmsQRDaVYBvcwTtUs29BP8OGb0RXJsFSJUzRW7bemA5DvWd6o3SgKKCYs1Qt65b9Ju5dJs4YZgjwXYttHtqT037EzRPIWgyHNyM+UlNe8JWk7SjPSXgtP0kuRY99cU8Ef/zkVXzuY++AvfgIEy3oAB5Js91p6McqMHHu7UTU+ouGd47UvIstWcUoxklgwcugT3hwjxzeWREdmSMSf8VufI1Kt7/5ZfeYBdX/OQnXn6te++p0EBq0bRswvTTxMonHrTZcV4Hcll20eQH2lOJtLgAeTR6TtdEaMXf5YqPf8WT4Su4YEy4HDg3eF6SuC94o5zmv7g8OahpuuvGeiNqNfVSL8uEc67kVaKXTGc6r08oNn4GDDo/NE/JAeYzv1RG5M1Z7u4HMFtsw93GgthjqDTW7nD8lji4PvhJMjgyuQUfdkOiwryYccVEiPGceBE4ppPkIvhtncA
Initial Root Token: b565ce84-b273-8644-76a5-ded5b9ff4a66

Mettons que l'on stocke quelques clés dans notre coffre puis que l'on stoppe notre serveur avant de le relancer.

Au moment où l'on va vouloir s'authentifier avec vault auth on va tomber sur cette erreur :

Code: 503. Errors:

* Vault is sealed

Le processus ayant été arrêté puis relancé, le coffre est scellé. Si le processus est arrêté un peu sauvagement le coffre ne sera pas corrompu, il sera scellé également.

Avant de pouvoir l'utiliser de nouveau nous devons donc le desceller avec au moins 2 jetons. En premier lieu il nous faut déchiffrer nos jetons :

echo "wcBMA3BSI…" | base64 -D | keybase pgp decrypt

Une fois la clé récupérée on commence à desceller le coffre :

# vault unseal
Key (will be hidden):
Sealed: true
Key Shares: 3
Key Threshold: 2
Unseal Progress: 1
Unseal Nonce: 1a22bfb2-c3ad-c855-27e9-bc3d5c7ee066

On voit ici que le processus s'est bien passé et qu'il nous reste à refaire l'opération une fois (unseal progress). On répète l'opération avec la deuxième clé.

# vault unseal
Key (will be hidden):
Sealed: false
Key Shares: 3
Key Threshold: 2
Unseal Progress: 0
Unseal Nonce:

Le coffre n'est plus scellé à présent. On peut s'authentifier et l'utiliser normalement.

J'espère que ce premier article vous aura convaincu de l'intérêt de Vault, que ce soit pour l'utiliser pour partager des accès à des ressources ou pour le mettre en place dans une chaine de déploiement plus poussée.

Dans notre prochain article nous irons un peu plus loin pour se rapprocher de ce deuxième cas d'usage.

Capital à la rencontre de Synbioz

2016-12-01T00:00:00Z

En cette fraiche fin d'année Capital est venu nous rendre visite armé de ses caméras :

Capital à la rencontre de Synbioz via synbioz sur Vimeo.

Si vous désirez en savoir plus sur nos références, nos méthodes de travail et nos technologies, rendez vous dans la section contact.

Un peu de magie avec to_proc

2016-01-13T00:00:00Z

Vous le savez, ici on aime bien démystifier les comportements pseudo magiques que nous offrent ruby et rails.

D'ailleurs il est parfois difficile de savoir si un bout de code vient du langage ou du framework.

À tel point qu'on a des quiz dédiés pour tenter de deviner quand il s'agit de ruby ou rails.

Alors, ce snippet, et notamment &:, ruby ou rails ?

(1..10).map(&:to_s)

Les deux mon général !

Remontons le temps

Et oui une fois n'est pas coutume, le &: nous vient de Ruby on Rails mais a été ré-intégré directement dans le langage, à partir de la version 1.8.7.

On en oublierait presque que notre chère version 1.8.6 aurait renvoyé un TypeError: wrong argument type Symbol (expected Proc).

Comment ça marche ?

Soyons clair, même en 1.8.6, il était possible d'invoquer un bloc de code avec &, simplement on ne pouvait pas le faire sur un symbole et donc pas par le biais de &:.

Par exemple, ce code fonctionne parfaitement, même en 1.8.6.

class Hello
  def self.to_proc
    proc { puts "Hello" }
  end
end

(1..10).map(&Hello)

À partir du moment ou un objet est «procable» (si vous avez une version FR je prends en commentaire) on peut l'invoquer de la sorte. Et pour le rendre procable, il suffit de définir to_proc et le comportement associé.

L'avantage du to_proc, c'est qu'il transmet automatiquement son contexte :

class Hello
  def self.to_proc
    proc { |i| puts "Hello from #{i}" }
  end
end

(1..10).map(&Hello)

(1..10).map do |index|
  Hello.to_proc.call(index)
end

Les deux dernières instructions font la même chose, mais avouez que la première est plus élégante. Dans tous les cas le contenu de notre itérateur est automatiquement passé à la proc.

Ce qui veut dire qu'en rendant un élément de base procable on pourrait très bien appeler dynamiquement des méthodes sur les éléments de l'itérateur.

Imaginons que nous aimerions pouvoir faire ceci :

(1..10).map(&'to_s')

Il suffit de rendre nos string propres. Euh, rendre nos String proc(able).

class String
  def to_proc
    proc { |context| context.send(self) } # dans notre appel self sera donc 'to_s'
  end
end

Voilà, c'est tout ce dont nous avons besoin. Le choix a été fait de rendre procable les symboles plutôt que les String (et c'est mieux ainsi), mais le fonctionnement est strictement identique.

Même les Hash s'y mettent

Dans la récente release de Ruby 2.3, les Hash aussi deviennent procable. Rien de très excitant, cela nous permettra de récupérer la valeur depuis la clé.

hash = { a: 1, b: 2, c: 3 }
hash.to_proc.call(:a) #=> 1

L'avantage c'est qu'on pourra également l'invoquer depuis un itérateur :

[:a, :b, :z].map(&hash) #=> [1, 2, nil]

Précédence des opérateurs en ruby et contrôle de flux

2015-11-03T00:00:00Z

Qu'est ce que la précédence ?

La précédence désigne la priorité et la force des différents opérateurs.

En mathématique les différents opérateurs ont des priorités différentes, par exemple la multiplication prend le pas sur l'addition.

De fait en ruby, comme dans bien d'autres langages, cette expression retourne le résultat attendu :

2 + 3 * 4
=> 14

Pour reprendre la main sur le flux des opérateurs on peut bien sûr utiliser des parenthèses :

(2 + 3) * 4
=> 20

Quels sont les opérateurs ?

Les opérateurs sont les suivants, de la précédence la plus élevée à la plus faible :

[] et []=	Accès à un élément du tableau et set d'une valeur
**	Exponentiel
! ~ + -	Inversion, complément (remplace les bits 0 par 1 et vice-versa), plus et moins (-2 ou +3)
* / %	Multiplication, division et modulo
+ -	Addition et soustraction
<< >>	Décallage de bit vers la droite ou gauche. Retire des bits à droite, ajoute des 0 à gauche. Ex: (9 >> 1).to_s(2)
&	AND, opérateur bit à bit, 1 si 1 des deux côtés, 0 sinon. (9 & 14).to_s(2) donne en binaire 1001 & 1110 = 1000 (8)
^ \|	^ est l'opérateur bit à bit XOR (ou exclusif). 1 si uniquement un des deux bits est à 1. \| est l'opérateur bit à bit OR. 1 si 1 d'un côté au moins.
<= < > >=	Opérateurs de comparaison
<=> == === != =~ !~	Comparaison d'égalité ou de matching
&&	Et logique. Vrai si les des deux éléments sont évalués à vrai. `true && false` renvoie false.
\|\|	Ou logique. Vrai si l'un des deux éléments est évalué à vrai. `true \|\| false` renvoie true.
.. ...	Range incluant et excluant la borne haute : Ex `(1..3).to_a == [1, 2, 3]`. `(1...3).to_a == [1, 2]`
? :	Ternaire. Ex: `i % 2 == 0 ? "even" : "odd"`
= += -= &&= etc…	Affectations
defined?	Vérifie la définition ou non d'une variable
not	Négation logique
or and	Composition logique
if unless while until	Conditions et boucles
begin end	Blocs

Contrôle de flux versus opérateurs logiques

La précédence des opérateurs peut avoir des conséquences importantes pour des opérateurs qui semblent avoir le même usage.

C'est le cas de && et and tout comme || et or. Prenons l'exemple suivant :

a = []
b = 1
c = a.empty? and b.is_a?(String)

Le dernier retour sera ici false et c sera true ce qui peut paraître suprenant. On le comprend mieux en prennant en compte la précédence. L'interpréteur ruby va «lire» l'expression de la sorte :

a = []
b = 1
(c = a.empty?) and b.is_a?(String)

En effet l'affectation a une précédence plus forte que le and comme on l'a vu dans le tableau ci dessus.

Avec le && logique le résultat est tout autre et plus proche de ce que l'on attend naturellement :

a = []
b = 1
c = a.empty? && b.is_a?(String)

Le retour est false et c également car l'expression se décompose de la sorte :

a = []
b = 1
c = (a.empty? && b.is_a?(String))

Il en est de même pour les opérateurs or et ||. Il faut en fait voir les opérateurs or et and comme des opérateurs de gestion de flux.

Leur usage est donc plus proche de celui de conditions telles que if, else ou unless que d'un opérateur logique.

Vous avez sans doute déjà vu en Perl ou en PHP des instructions telles que :

chdir '/foo/bar' or die "Can't cd to bar"

Le fonctionnement est le même en ruby et nous permet de gérer le flux de la sorte :

File.exists?('/tmp/bar') or File.new('/tmp/bar', 'w') {}

ce qui est comparable à :

File.new('/tmp/bar', 'w') {} unless File.exists?('/tmp/bar')

La connaissance des opérateurs et de leur précédence est un aspect important du langage. N'hésitez pas à partager vos retours d'expériences et pièges dans lesquels vous avez pu tomber.

Du bon usage des exceptions en Ruby

2015-10-27T00:00:00Z

Les exceptions servent, comme leur nom l'indique, à gérer des erreurs au caractère rare et imprévu.

Elles n'ont pas vocation à gérer des erreurs prévisibles comme une erreur de saisie d'un utilisateur par exemple.

Venons en rapidement aux faits :

begin
  3 + '4'
rescue => e
  puts e.class
  puts e.message
  puts e.trace
end

Nous renverra:

TypeError
String can't be coerced into Fixnum
./exceptions.rb:4:in `+'
./exceptions.rb:4:in `<main>'

On a donc une erreur de la classe TypeError. Si on regarde la classe parente de TypeError il s'agit de StandardError. Cette classe est en fait la classe par défaut utilisée dans notre rescue.

Notre code revient donc à :

begin
  3 + '4'
rescue StandardError => e
  puts e.class
  puts e.message
  puts e.trace
end

Il est fortement déconseillé d'attraper des erreurs en dehors des sous classes de StandardError car elles sont utilisées par le système. Par exemple on y retrouve NoMemoryError, LoadError ou encore SystemExit pour n'en citer que quelques unes.

On comprend mieux pourquoi les attraper pourrait avoir des effets de bords. Quelques exemples :

begin
  require 'foo'
rescue Exception
  puts $!
end

Ici on attrape l'exception de type LoadError, ce qui risque de masquer le problème de chargement de notre fichier. A noter l'utilisation de la variable globale $! qui récupère automatiquement la dernière exception.

Autre exemple :

while true
  puts "Say quit to esc"
  begin
    str = gets
    exit if "quit" == str.chomp
  rescue Exception => e
    puts "Exception #{e.class}"
  end
end

Bon courage pour quitter, le rescue attrapera l'exception SystemExit si vous tapez quit mais également Interrupt si vous faites un ^C.

A part pour faire une lib de debug ou autre type de wrapper ne faites pas de rescue Exception. Si vous avez besoin d'un wrapper, pensez à relancer l'exception :

begin
  require 'foo'
 rescue Exception => e
  # j'attrape tout, mais je sais ce que je fais
  puts $!
  raise e
end

Lorsque vous avez besoin de vous assurer qu'un traitement sera réalisé même si une exception survient vous pouvez utiliser ensure :

require 'tempfile'

begin
  file = Tempfile.new('a')
  raise StandardError.new("ugh")
rescue => e
  puts $!
  raise e
ensure
  file.close
  file.unlink
end

Notre section ensure va s'assurer que le fichier est bien fermé et supprimé. J'ai volontairement re-lancé l'exception pour montrer que même si le rescue relance l'exception, le passage dans le ensure est garanti.

Bien entendu vous pouvez créer votre propre exception comme une classe classique:

class MyOwnException < Exception; end

raise MyOwnException.new('foo')

Si vous souhaitez attraper plusieurs types d'exception sans distinction vous pouvez parfaitement écrire :

require 'tempfile'

begin
  file = Tempfile.new('a')
  raise ArgumentError.new("ugh")
rescue ArgumentError, ZeroDivisionError => e
  puts $!
  raise e
ensure
  file.close
  file.unlink
end

Vous pouvez également gérer des comportements différents avec plusieurs instructions rescue :

require 'tempfile'

begin
  file = Tempfile.new('a')
  raise ArgumentError.new("ugh")
rescue ArgumentError => e
  puts $!
  # je renvoie l'erreur uniquement si c'est une exception de type ArgumentError
  raise e
rescue ZeroDivisionError => e
  puts $!
ensure
  file.close
  file.unlink
end

Pour connaître la liste des exceptions disponibles je vous ai préparé quelques lignes pour parcourir les différentes classes existantes et les afficher sous forme d'arbre :

def subclasses_tree(klass, level = 0)
  puts level.zero? ? klass.to_s : "#{' ' * (4 * (level - 1))}├── #{klass}"
  descendants_of(klass).select { |k| k.superclass == klass }.each do |k|
    subclasses_tree(k, level + 1)
  end
end

def descendants_of(klass)
  ObjectSpace.each_object(Class).select { |k| k < klass }
end

subclasses_tree(Exception)

Résultat :

Exception
├── MonitorMixin::ConditionVariable::Timeout
├── SystemStackError
├── NoMemoryError
├── SecurityError
├── ScriptError
    ├── NotImplementedError
    ├── LoadError
        ├── Gem::LoadError
            ├── Gem::ConflictError
    ├── SyntaxError
├── StandardError
    ├── FiberError
    ├── ThreadError
    ├── Math::DomainError
    ├── LocalJumpError
    ├── IOError
        ├── EOFError
    ├── RegexpError
    ├── ZeroDivisionError
    ├── SystemCallError
        ├── Errno::ERPCMISMATCH
        ├── Errno::EPROGUNAVAIL
        ├── Errno::EPROGMISMATCH
        ├── Errno::EPROCUNAVAIL
        ├── Errno::EPROCLIM
        ├── Errno::ENOTSUP
        ├── Errno::ENOATTR
        ├── Errno::ENEEDAUTH
        ├── Errno::EFTYPE
        ├── Errno::EBADRPC
        ├── Errno::EAUTH
        ├── Errno::EOWNERDEAD
        ├── Errno::ENOTRECOVERABLE
        ├── Errno::ECANCELED
        ├── Errno::EDQUOT
        ├── Errno::ESTALE
        ├── Errno::EINPROGRESS
            ├── IO::EINPROGRESSWaitWritable
            ├── IO::EINPROGRESSWaitReadable
        ├── Errno::EALREADY
        ├── Errno::EHOSTUNREACH
        ├── Errno::EHOSTDOWN
        ├── Errno::ECONNREFUSED
        ├── Errno::ETIMEDOUT
        ├── Errno::ETOOMANYREFS
        ├── Errno::ESHUTDOWN
        ├── Errno::ENOTCONN
        ├── Errno::EISCONN
        ├── Errno::ENOBUFS
        ├── Errno::ECONNRESET
        ├── Errno::ECONNABORTED
        ├── Errno::ENETRESET
        ├── Errno::ENETUNREACH
        ├── Errno::ENETDOWN
        ├── Errno::EADDRNOTAVAIL
        ├── Errno::EADDRINUSE
        ├── Errno::EAFNOSUPPORT
        ├── Errno::EPFNOSUPPORT
        ├── Errno::EOPNOTSUPP
        ├── Errno::ESOCKTNOSUPPORT
        ├── Errno::EPROTONOSUPPORT
        ├── Errno::ENOPROTOOPT
        ├── Errno::EPROTOTYPE
        ├── Errno::EMSGSIZE
        ├── Errno::EDESTADDRREQ
        ├── Errno::ENOTSOCK
        ├── Errno::EUSERS
        ├── Errno::EILSEQ
        ├── Errno::EOVERFLOW
        ├── Errno::EBADMSG
        ├── Errno::EMULTIHOP
        ├── Errno::EPROTO
        ├── Errno::ENOLINK
        ├── Errno::EREMOTE
        ├── Errno::ENOSR
        ├── Errno::ETIME
        ├── Errno::ENODATA
        ├── Errno::ENOSTR
        ├── Errno::EIDRM
        ├── Errno::ENOMSG
        ├── Errno::ELOOP
        ├── Errno::ENOTEMPTY
        ├── Errno::ENOSYS
        ├── Errno::ENOLCK
        ├── Errno::ENAMETOOLONG
        ├── Errno::EDEADLK
        ├── Errno::ERANGE
        ├── Errno::EDOM
        ├── Errno::EPIPE
        ├── Errno::EMLINK
        ├── Errno::EROFS
        ├── Errno::ESPIPE
        ├── Errno::ENOSPC
        ├── Errno::EFBIG
        ├── Errno::ETXTBSY
        ├── Errno::ENOTTY
        ├── Errno::EMFILE
        ├── Errno::ENFILE
        ├── Errno::EINVAL
        ├── Errno::EISDIR
        ├── Errno::ENOTDIR
        ├── Errno::ENODEV
        ├── Errno::EXDEV
        ├── Errno::EEXIST
        ├── Errno::EBUSY
        ├── Errno::ENOTBLK
        ├── Errno::EFAULT
        ├── Errno::EACCES
        ├── Errno::ENOMEM
        ├── Errno::EAGAIN
            ├── IO::EAGAINWaitWritable
            ├── IO::EAGAINWaitReadable
        ├── Errno::ECHILD
        ├── Errno::EBADF
        ├── Errno::ENOEXEC
        ├── Errno::E2BIG
        ├── Errno::ENXIO
        ├── Errno::EIO
        ├── Errno::EINTR
        ├── Errno::ESRCH
        ├── Errno::ENOENT
        ├── Errno::EPERM
        ├── Errno::NOERROR
    ├── EncodingError
        ├── Encoding::ConverterNotFoundError
        ├── Encoding::InvalidByteSequenceError
        ├── Encoding::UndefinedConversionError
        ├── Encoding::CompatibilityError
    ├── RuntimeError
        ├── Gem::Exception
            ├── Gem::VerificationError
            ├── Gem::RubyVersionMismatch
            ├── Gem::RemoteSourceException
            ├── Gem::RemoteInstallationSkipped
            ├── Gem::RemoteInstallationCancelled
            ├── Gem::RemoteError
            ├── Gem::OperationNotSupportedError
            ├── Gem::InvalidSpecificationException
            ├── Gem::InstallError
            ├── Gem::ImpossibleDependenciesError
            ├── Gem::GemNotFoundException
                ├── Gem::SpecificGemNotFoundException
            ├── Gem::FormatException
            ├── Gem::FilePermissionError
            ├── Gem::EndOfYAMLException
            ├── Gem::DocumentError
            ├── Gem::GemNotInHomeException
            ├── Gem::DependencyRemovalException
            ├── Gem::DependencyError
                ├── Gem::UnsatisfiableDependencyError
                ├── Gem::DependencyResolutionError
            ├── Gem::CommandLineError
    ├── NameError
        ├── NoMethodError
    ├── RangeError
        ├── FloatDomainError
    ├── IndexError
        ├── StopIteration
        ├── KeyError
    ├── ArgumentError
        ├── UncaughtThrowError
        ├── Gem::Requirement::BadRequirementError
    ├── TypeError
├── SignalException
    ├── Interrupt
├── fatal
├── SystemExit
    ├── Gem::SystemExitException

Vous savez tout, bonne gestion d'exceptions avec Ruby !

WebAssembly, vers un web compilé ?

2015-07-10T00:00:00Z

Edit : Les commentaires offrent un excellent complément à l'article.

Il y a maintenant deux ans on commençait à voir des vidéos d'Unreal Engine 3 tournant dans le navigateur.

Ce proof of concept mettait en avant asm.js, un sous ensemble de JavaScript à la fois restreint mais optimisé.

Concrètement asm.js offre la possibilité de transcrire du code C/C++ en JavaScript (dans la limite de ce sous ensemble) en utilisant emscripten. Ce code étant compilé, sa vitesse d’exécution permet d'atteindre un niveau de performance inaccessible pour un langage parsé et interprété à la volée.

Pendant que la fondation Mozilla travaillait sur asm.js, Google avancait sur son Native Client, ce qui était plutôt inquiétant en terme d'intéropérablité pour nous développeurs.

Heureusement les représentants des 4 navigateurs les plus utilisés ont décidé de se mettre au tour de la table et de standardiser leurs avancées dans un nouvel outil : WebAssembly (wasm).

Un groupe a donc était constitué au sein du w3c afin de spécifier WebAssembly et des dépôts ouverts.

Que va nous apporter WebAssembly ?

Dans l’exécution d'un programme classique en JavaScript le navigateur doit récupérer le code source, le compiler vers un bytecode et l'interpréter.

Même avec de la compilation just in time cela prend forcément du temps. L'idée ici est de fournir directement le bytecode au navigateur. Avec à la clé plusieurs avantages : le bytecode est plus léger que le code en tant que tel, hors compression on parle d'un facteur 3, compressé avec gzip ~30%. Cela signifie 30% de données de moins à transférer et trois fois moins à traiter.

La conversion du code JavaScript vers du code wasm va donc accélérer le temps de chargement de façon très significative mais moins le temps de traitement. En effet JavaScript génère également du bytecode qui est éxécuté. asm.js permet une optimisation en ne gérant qu'un sous ensemble de JavaScript et avec une syntaxe qui permet au compilateur un certain nombre d'optimisations.

Concrètement on a sous le capot une version de JavaScript typée statiquement (on a enfin trouvé une pseudo justification à l'usage du mot java) et sans objet.

On ne peut donc pas faire une transposition de l'ensemble du code JavaScript vers de l'asm en un claquement de doigt. Et on ne le pourra pas non plus avec WebAssembly.

Est-ce la mort de JavaScript ?

Non, WebAssembly n'est pas prévu comme un remplaçant à court terme de JavaScript, mais il va évoluer parallèlement ce qui à mon sens est un élément indispensable à son adoption.

Le web n'est pas un média de rupture, les technologies avancent certes rapidement mais en conservant de la rétro-compatibilité. Suivant cette idée, des prototypes de polyfill sont en cours afin de convertir du WebAssembly vers du JavaScript si ce premier n'est pas supporté (assurant la compatibilité mais faisant disparaître les avantages de wasm).

Toutefois le fait que les principaux navigateurs veuillent le standardiser est une excellente nouvelle et un gage d'avancées significatives à venir.

D'asm à wasm

À ce stade vous vous dites sûrement que wasm est uniquement une standardisation d'asm, mais wasm va plus loin. En effet la volonté est de pouvoir exécuter du code C/C++ dans le navigateur mais pas uniquement. À terme il sera possible d'y porter tout type de langage tout en accédant aux API de JavaScript.

Même si l'effort à fournir avant d'y arriver sera énorme le potentiel est extraordinaire.

Aujourd'hui des outils permettant de porter du code wasm vers asm existent (quand je lis que ce n'est pas un média de rupture), ce qui permet donc de l’exécuter dans les navigateurs supportant asm. Concrètement on parle de tous les navigateurs supportant ES6 puisque asm en est un sous ensemble.

Adieu view source ?

C'est pour moi un argument critique, cette mise à disposition du code dans un format binaire pourrait nous faire dire adieu à la possibilité d'en voir le source.

Certes les codes étant maintenant compressés, minifiés voir obscurcis on peut de moins en moins facilement lire le code d'une application web depuis son navigateur. Pourtant cela reste un des fondements du web.

Espérons que WebAssembly disposera d'une option de type source maps permettant de faire le lien entre le code généré et la source.

En tout cas WebAssembly me semble définitivement une technologie qui va compter dans les prochaines années.

Et si on changeait la relation client - prestataire

2015-05-06T00:00:00Z

Ah le sacro saint cahier des charges, la réponse d'appel d'offre, la short-list, les sueurs froides puis le démarrage du projet.

Quelle agence n'a pas connu ça ?

Ce mode de fonctionnement m'a toujours semblé étonnant. Si on repart du besoin, que cherche un client ? Généralement un partenaire fiable et compétent qui pourra l'accompagner dans la réalisation de son projet. Souvent sur du long terme.

Partant de là on peut se demander si le processus ci dessus permettant de choisir le prestataire est le bon. En tant qu'agence voilà ce qui me pose problème :

Comment le client détermine à qui il envoie le cahier des charges ?
Comment le client peut choisir un prestataire, à la simple lecture d'un document et de quelques échanges téléphoniques ?
Y a t-il une chance qu'un mode de fonctionnement basé sur un ou des forfaits puisse pérenniser une relation ?

En tant que client :

Comment je peux cibler les prestataires compétents ? Certains sont très compétents mais peu visibles, plus souvent c'est l'inverse.
Comment juger de la pertinence d'un prix ? Pas besoin de sortir de math sup pour se rendre compte qu'une mission réalisée en 3J à 750€/jour est moins chère qu'une en 10J à 250€/jour. Quel est le bon prix de la compétence de mon prestataire ?
Ai je intérêt à me positionner sur un prix bas ?
Comment m'assurer que mon prestataire va pouvoir m'accompagner dans la durée ?

La diffusion

La diffusion du cahier des charges est une partie assez folklorique. Pour le client qui a fait un choix de technologie ce sera généralement son premier filtre.

Cela n'a pas forcément de sens car si l'implication d'un client dans les technologies qu'il utilise me semble un très bon point il n'en sera généralement pas un bon juge (bien sûr cela exclut le client qui a sa propre équipe technique).

Derrière les critères sont encore plus exotiques (années d'existence, qualité du site web, publicité…).

Ici les solutions ne sont pas évidentes. D'un côté on a les plateformes d'appels d'offres publics qui sont justes mais complètement inutilisables notamment pour les petites entreprises.

De l'autre on a les plateformes orientées projets type 123presta. Mais franchement je n'ai vraiment pas envie d'en parler tant cela va à l'opposé de notre idée de symbiose entre client et prestataire.

Je pense qu'on devrait plutôt s'orienter vers des plateformes visant à évaluer les prestataires, faire des recommandations etc…

Cela existe mais c'est un mode de fonctionnement encore marginalisé.

Investir dans la relation

En tant qu'humain on néglige quasi systématiquement les coûts indirects. Comme ils sont invisibles on a du mal à les évaluer. Pourtant dans le secteur informatique ils sont énormes.

J'ai rarement vu des clients être en mesure d'évaluer le coût du changement d'un prestataire. Êtes vous sûr que choisir un prestataire 100€/J moins cher va vous faire gagner de l'argent ? Si oui, est ce vrai à court terme, à long terme ?

De même il faut provisionner comme un coût le choix du prestataire. Il est beaucoup moins risqué de payer quelques jours de prestation pour juger de son niveau que de s'embarquer à l'aveugle.

Oui vous aurez dépensé un peu de budget mais cela permet de se mettre dans une logique de long terme et de capitaliser sur la relation. Autrement c'est à peu près aussi fiable que de recruter une personne sur la couleur de ses yeux.

Sortir du forfait ?

Je le dis sans détour, le modèle de forfait est un modèle gagnant - perdant. Votre seul espoir est d'être du bon côté. En tant qu'agence soit vous avez fini votre projet plus vite que prévu (ou dans les temps) et vous êtes le gagnant, soit c'est l'inverse et vous pouvez regarder la marge s'envoler.

Ce mode de fonctionnement a donc plusieurs effets pervers, d'un côté ou de l'autre :

Si j'ai été perdant le coup d'avant je vais essayer de compenser
En tant qu'agence si je me rapproche du côté perdant la solution de facilité est de limiter la qualité
Je vais cacher à l'autre qu'il est le perdant
Je fais des estimations que je gonfle pour être sûr de ne pas être le perdant

Qu'est ce qui se passe quand on a été perdant plusieurs fois d'affilé ? La relation se termine (généralement mal).

Selon moi la première chose à faire est de démystifier ce sujet. Parlons en ouvertement entre client et agence pour trouver de bonnes solutions. Le mode de fonctionnement en régie est sans doute beaucoup plus juste s'il n'a pas pour but de prendre le client en otage. Il implique donc de mettre en place des gardes fous:

Quel est le niveau de qualité souhaité ? La qualité est un indicateur complètement abstrait pour lequel il faut se mettre d'accord avec le client.
Le temps de développement d'une fonctionnalité. C'est à dire être en capacité d'alerter le client quand le développement dépasse un nombre de jours entendus.

En ce sens je ne rejoins pas la logique puriste NoEstimates. L'estimation est un indicateur permettant de faire des choix et de piloter un développement. Il permet de pondérer une difficulté et d'en déduire un cap pour le produit.

Si vous êtes un puriste je serai curieux de savoir ce que vous direz au constructeur de votre maison quand vous lui demanderez quand vous pourrez habiter dedans et qu'il vous dira qu'il ne fait pas d'estimation.

Attention, contracter des estimations n'a pas de sens non plus. D'où l'idée de pouvoir se mettre d'accord en amont entre client et prestataire.

Enfin gardons en tête le sens premier du mot estimation. Si votre client n'accepte pas que vous puissiez vous tromper c'est soit qu'il ne connait pas le sens du mot soit qu'il ne souhaite pas être dans une relation où les risques sont mitigés.

L'autre avantage d'estimer est de pouvoir regrouper des fonctionnalités pour en faire des séquences de développements (sprints). Partant de là on se donne des priorités mais on est également en mesure de rapidement voir d'où vient le problème lorsqu'on déborde d'une estimation.

Il n'y a pas de honte à dire que l'estimation n'était pas juste. C'est une estimation. D'ailleurs bien souvent le client l'entendra, à la condition que vous l'ayez prévenu dès l'origine plutôt qu'en le mettant au pied du mur.

Encore une fois l'idée est d'être juste des deux côtés. Si vous attendez cette compréhension de votre client cela signifie que côté prestataire vous vous imposez également une transparence pour prévenir le client que vous avez été plus vite que prévu.

Rapprocher les frontières

Toute la subtilité des deux côtés (client et prestataire) est de s'impliquer et comprendre le métier de l'autre au mieux sans interférer. Je comprends ton domaine de compétence pour rapprocher le mien du tien ; mais je ne te dis pas ce que tu dois faire dans ton domaine.

Il faut chercher à augmenter l'intersection entre les deux domaines de compétences pour en sortir un projet réussi car il n'y a pas de bon projet sans implication.

La relation client fournisseur est un sujet complexe que j'ai effleuré et je ne prétends pas avoir de réponse à chacune des problématiques.

Quel est votre retour d'expérience ? Avez vous des idées pour améliorer cette relation ?

Servir rapidement ses images avec nginx et dragonfly

2015-02-27T00:00:00Z

Lorsqu'on utilise la gem dragonfly, le chargement des images de notre application ressemble à cela :

I, [2015-02-27T16:16:32.957778 #3191]  INFO -- : DRAGONFLY: GET /media/W1siZiIsIjIwMTUvMDIvMjEvOWoxOXhscmMzMV9NX2VuZmxhbW1lX2xlc19jZXNhcl8yMDE1XzAuanBnIl0sWyJwIiwidGh1bWIiLCI3OTJ4NDAwIyJdXQ/-M--Ceremonie%20des%20Cesar%2C%20M%20fait%20son%20cinema-actu_0?sha=ca1afcbcf31555c8 200

On ne peut donc pas demander à nginx de servir directement le fichier depuis le système de fichier car son URL ne correspond pas à son chemin sur le serveur.

C'est problématique car on va demander à notre serveur ruby de servir ces images à chaque fois, ce qui va s'avérer peu performant.

Mise en place d'un proxy cache

Nginx nous offre une directive proxy_cache_path pour faire en sorte de mettre en cache le résultat de certaines URL.

Tout d'abord nous allons créer notre répertoire de cache :

mkdir -p /etc/nginx/cache/dragonfly
chown -R nobody:root /etc/nginx/cache/dragonfly

puis référencer notre cache dans notre fichier nginx.conf.

http {
  proxy_cache_path /etc/nginx/cache/dragonfly levels=2:2 keys_zone=dragonfly:100m inactive=30d max_size=1g;
}

La directive levels définit la profondeur des dossiers créés, ex: /etc/nginx/cache/dragonfly/aa/11.

En 1:1 on aurait quelquechose comme /etc/nginx/cache/dragonfly/a/1.

Cette arboresence est systématiquement reprise dans les fichiers stockés dans ces dossiers de sorte qu'ils puissent retrouver simplement leur place en cas de déplacement, ex: /etc/nginx/cache/dragonfly/ff/84/718ba36b52491e18c227650da4e884ff

La directive keys_zone définit le nom de notre cache et la taille pour les clés. Il s'agit bien des clés de cache et pas des fichiers mis en cache. Une zone de 1M permet de stocker 8 000 clés.

inactive permet de retirer du cache un fichier non accédé depuis un certain temps. Par défaut c'est 10 minutes, ici on utilise 30 jours.

Enfin max_size définit la taille cumulée des fichiers mis en cache. Quand cette taille est atteinte nginx retire les entrées qui ont été utilisées il y a le plus longtemps.

Si un fichier a été mis en cache il y 20 jours et accédé aujourd'hui il sera prioritaire par rapport à un fichier mis en cache il y a 2 jours et accédé hier.

Cache partagé entre plusieurs sites

Si notre nginx fait tourner plusieurs sites il est préférable de déterminer également une clé de cache qui nous évitera les conflits.

http {
  proxy_cache_key "$scheme://$host$request_uri";
}

Configuration du vhost

Il nous reste maintenant uniquement à configurer le site en question.

  location /media {
    proxy_pass http://app;
    proxy_cache dragonfly;
    proxy_cache_valid 200 30d;
  }

Nous demandons donc à servir les fichiers ayant une URL débutant par /media par notre proxy_pass s'il ne sont pas en cache et de les y mettre.

La directive proxy_cache_valid nous permet de spécifier une durée de validité du cache par status de réponse, par exemple 30 jours pour une 200, 1 minute pour une 404 etc…

C'est tout pour cet article, j'espère qu'il vous aidera à rendre le web un peu plus rapide.

Comprendre et implémenter un DSL en ruby

2014-12-23T00:00:00Z

Lorsqu'on débute en Ruby, les DSL apparaissent comme une sorte de magie noire alors qu'on les croise à chaque coin de son éditeur.

Il suffit d'ouvrir un fichier d'environnement dans une application Ruby on Rails pour tomber dessus:

Rails.application.configure do
  # Settings specified here will take precedence over those in config/application.rb.

  # In the development environment your application's code is reloaded on
  # every request. This slows down response time but is perfect for development
  # since you don't have to restart the web server when you make code changes.
  config.cache_classes = false

  # Do not eager load code on boot.
  config.eager_load = false
  …
end

Vous le voyez, dans les DSL tout repose sur l'usage de blocs. Dans cet article je vous présenter un exemple basique dans l'exposition d'un DSL sans intérêt et un exemple plus avancé permettant d'utiliser un DSL pour définir un DOM de la sorte:

Form.new do
  method "post"
  action "/"
  p do
    id "my_firstname"
    input do
      type "text"
      name "firstname"
    end
  end
end

Qu'est ce qu'un DSL ?

Un DSL est l'application d'un langage particulier dans un domaine précis. Comparativement au langage parlé, c'est l'équivalent d'un jargon.

C'est à dire que vous allez utiliser un sous ensemble d'un langage pour exprimer un contexte précis.

Créer son DSL

Prenons un cas simple où je souhaite pouvoir décrire des services à l'aide d'une syntaxe encadrée.

Je voudrai pouvoir exprimer mes services de la sorte:

Service.new do
  description "postgresql"
  port        5432
  host        "foo.bar.com"
  name        "db"
  username    "jean"
  password    "fam0us"
end

On le voit, la configuration d'un service avec cette syntaxe est très lisible et facilement mémorisable. On est finalement assez proche de l'écriture d'un fichier de configuration.

Voyons ce qu'il nous faut pour rendre notre interface de service disponible.

On se doute qu'il va nous falloir une classe avec un constructeur qui prend un bloc. On va invoquer ce bloc s'il est présent (toute méthode ruby possède un bloc optionnel). Pour cela nous utiliserons yield.

class Service
  def initialize(&block)
    yield if block_given?
  end
end

Service.new do
  description "postgresql" # en fait l'appel description("postgresql")
end

Aïe: undefined method 'description' for main:Object

Apparemment notre bloc essaye d'invoquer description au niveau main, vérifions.

class Service
  def initialize(&block)
    yield if block_given?
  end
end

def description(d)
  puts "Not sure you want to call me."
end

Service.new do
  description "postgresql"
end

$ ruby service.rb
Not sure you want to call me.

Effectivement notre bloc ne s’exécute pas dans le contexte du service, il prend le contexte courant. À ce moment self ne représente donc pas l'instance de Service mais le main.

Nous pourrions améliorer notre programme de la sorte pour passer notre contexte au yield:

class Service
  def initialize(&block)
    yield(self) if block_given?
  end

  def description(description)
  end
end

Service.new do |s|
  s.description "postgresql"
end

Bon, ça marche, mais on ne respecte pas la syntaxe initiale souhaitée. Pour ce faire nous avons besoin d'évaluer notre bloc dans le contexte de notre objet.

class Service
  def initialize(&block)
    instance_eval(&block) if block_given?
  end

  def description(description)
    @description = description
  end
end

Service.new do
  description "postgresql"
end

En faisant cela on applique un self.instance_eval(&block). self étant à cet endroit l'instance de Service cela fonctionne normalement.

Si notre DSL doit gérer beaucoup d'attributs on pourra l'enrichir pour gérer dynamiquement nos setters, ou utiliser method_missing.

On pourrait même s'amuser à créer une petite interface pour rendre n'importe quelle classe utilisable comme un DSL.

class DSL
  def self.build(object, &block)
    object.instance_eval(&block)
    object
  end
end

class Service
  def description(description)
    @description = description
  end
end

DSL.build(Service.new) do
  description "postgresql"
end

Gare au contexte

Nous voilà donc arrivé au résultat voulu en finalement très peu de code. Mais je sens que quelque chose vous chagrine.

Vous vous dites que c'est super mais dans ce cas pourquoi des DSL type create_table dans ActiveRecord::Migration sont sous cette forme:

create_table :contacts do |t|
  t.string :email, null: false
  t.timestamps
end

et pas celle ci:

create_table :contacts do
  string :email, null: false
  timestamps
end

Vous le savez sans doute, l'évaluation de code est à utiliser modérément. Dans le contexte de mon bloc je vais être cantonné à mon binding, c'est à dire celui de mon service.

Si je souhaite mettre en place un peu d'abstraction cela commence à poser souci:

class Service
  def initialize(&block)
    instance_eval(&block) if block_given?
  end

  def description(description)
    @description = description
  end
end

class ServiceDefinition
  SERVICES = { pg: 'postgresql' }

  def self.define
    Service.new do
      description name(:pg)
    end
  end

  def self.name(sym)
    SERVICES[sym]
  end
end

undefined method name for #<Service:0x007f93ba10c930>. Je ne peux pas appeler name ici car il le cherche sur mon service.

Si je veux arriver au bon résultat je vais devoir sauvegarder mon contexte avant le bloc:

class Service
  def initialize(&block)
    instance_eval(&block) if block_given?
  end

  def description(description)
    @description = description
  end
end

class ServiceDefinition
  SERVICES = { pg: 'postgresql' }

  def self.define
    context = self
    Service.new do
      description context.name(:pg)
    end
  end

  def self.name(sym)
    SERVICES[sym]
  end
end

Dans le cas présent on voit que ce n'est pas une excellente idée ; attention donc à être sûr de ce qu'on fait et ne pas se créer des problèmes vicieux et complexe à débugger par la suite.

Simuler un DOM avec un DSL

Voyons maintenant comment mettre en place un DSL un tant soit peu utile permettant de définir un document structuré type page HTML.

Le fichier dom.rb est sur notre compte github.

module WithAttributes
  def attributes(*args)
    args.each do |attribute|
      define_method(attribute) do |value|
        # use attr_ prefix to be able to filter these var later.
        instance_variable_set "@attr_#{attribute}", value
      end
    end
  end
end

Je définis un module qui me permettra de définir des attributs dans mes différentes classes représentant mes éléments.

Ces attributs sont placés dans des variables d'instances. Par exemple pour un attribut name c'est @attr_name qui sera créée ainsi que sont setter associé def name(name).

L'intérêt d'utiliser un nom préfixé est de pouvoir lister et filtrer ces attributs par la suite.

class Element
  extend WithAttributes
  attributes :id

  def initialize(&block)
    @childs = []
    instance_eval(&block) if block_given?
  end

  def to_html
    tag = self.class.to_s.downcase

    str = @childs.inject("<#{tag}#{attributes}>") do |acc, child|
      acc << child.to_html
      acc
    end + "</#{tag}>"
  end

  def attributes
    # only keep attr variables
    instance_variables.select { |v| v.to_s.match(/^@attr_/) }.inject("") do |acc, a|
      name  = a.to_s
      name.slice!('@attr_')
      value = instance_variable_get(a)
      acc << " #{name}=\"#{value}\""
    end
  end
end

Element est ma classe de base, celle dont hériteront les autres classes. J'utilise le désormais connu instance_eval(&block) qui permettra de donner des valeurs à mes attributs en utilisant les méthodes définies dynamiquement.

J'ai une méthode to_html récursive qui affiche ma balise avec ses attributs et s'invoque sur les éléments enfants.

class Form < Element
  attributes :method, :action

  def p(&block)
    @childs << P.new(&block)
  end
end

class P < Element
  def input(&block)
    @childs << Input.new(&block)
  end
end

class Input < Element
  attributes :type, :name
end

Le reste est très simple, ce sont des classes qui héritent de ma classe Element et exposent leurs méthodes et attributs.

Conclusion

Le concept de DSL est à la fois puissant tout en étant simple à implémenter. Si vous souhaitez aller plus loin sans repartir de 0 à chaque fois vous pouvez également jeter un œil à la gem docile qui vous permet de mettre en place des DSL très simplement.

Manage your metas with metaslug gem

2014-10-14T00:00:00Z

Metaslug is a gem designed to let you easily manage your metas, based on a locale and an URL (a path to be more accurate).

Why metaslug ?

For quite some time we've been looking for a gem to let us manage metas of our applications outside the codebase with these simple requirements:

Metas are based on a path (slug)
Metas can be different according to the locale
Being a developer should not be a requirement

By metas we mean: title, description, opengraph tag…

We used metamagic which does the job but we still need to manage our metas inside the differents views and have to deal with the locale.

How it works

Our README is a good starting point.

After installing the gem with bundler (gem metaslug in your gemfile) you will generate your locales files based on your routes and use our helper metaslug in your layout.

Metaslug uses simple YAML file to store metas in config/metaslug/{en,fr…}.yml. Your locale file will contain a defaut section, allowing you to set default metas for every page without explicit ones.

The syntax is exactly the same as in the routes, with parameters like :id or so.

Dynamic metas

Of course your YAML file can have dynamic content. We use liquid to let you set your content dynamically.

In the YAML it will result in something like:

en:
  "/posts/:id/edit":
    title: "Edit post {{post.title}}"

In your model you'll have to define the methods accessible by liquid:

class Post < ActiveRecord::Base
  liquid_methods :title
end

And in your controllers you will define which ivar is accessible with metaslug_vars :post, only: :edit. As you can see metaslug_vars has the same syntax as a before_filter. In fact it is a before_filter.

It just marks these variables as accessible and will interpolate them after the action and before the rendering.

Please notice metas are reloaded for each request in development mode only.

Deep metas

There is no particular limitation for metas. This kind of metas:

<meta property="og:locale:alternate" content="fr_FR" />

Will result in:

"/awesome-page":
  og:
    locale:
      alternate: "fr_FR"

There is no control, you can even define your own meta if you want.

What if everything is dynamic?

So you're app as a lot of dynamic content, or maybe you use a CMS ? Great! Metaslug let you write something like this:

# catch all slug
"/:slug":
  title: "{{page.title}}"
  description: "{{page.description}}"

Just remind that the keys are browsed sequentially, you have to put this generic expression at the bottom of your file.

Technical points and roadmap

We actually just compare the request.path to our YAML keys, converted to regexp. It may sound a good idea to reuse the rails router but our goal is to avoid deep coupling with rails.

For the next major version we want to be fully compatible with any rack-based framework.

You can view the YAML files as a current backend solution but it won't be the only one. It's still way to complicate for a customer to edit this kind of files and commit them to the repository. Plus it will require to reload the application.

Insteal, we will add a user interface to allow metas edition from the application. To do this we will need to introduce different storage like database, cache…

Conclusion

We really hope Metaslug will help you manage your metas more easily.

Feel free to suggest some feature or even code it and make a pull request.

The Synbioz Team

Demander à nginx de ne répondre que pour un nom de domaine exact

2014-08-21T00:00:00Z

Nginx répond dès que possible

Mettons que vous ayez un wilcard DNS qui pointe vers votre serveur.

Par exemple *.domain.tld pointe sur une IP donnée.

Si vous avez une application a.domain.tld et b.domain.tld configurée sur votre serveur, que se passe t-il si vous demandez l'URL c.domain.tld ?

Et bien Nginx va tenter de répondre en affichant l'un des deux sites configurés. En effet si vous avez une directive de type :

server {
  listen 80;
  server_name a.domain.tld;
}

Cela ne signifie pas que nginx redirigera sur votre application uniquement lorsque vous demandez a.domain.tld.

Rendre nginx plus strict sur les noms de domaine

Pour obtenir un matching strict du nom de serveur vous devez d'abord renvoyer une 404 dans une directive server globale.

server {
  return 404;
}

server {
  listen 80;
  server_name a.domain.tld;
}

En effet nginx fonctionne sur le principe du plus générique au plus spécifique.

Vous lui indiquez donc que dans le cas général vous voulez retourner une 404, et dans le particulier du bon nom de domaine vous voulez effectuer le traitement indiqué.

CORS, CloudFront et Firefox sont dans un bateau

2014-07-03T00:00:00Z

Le mécanisme CORS (Cross-origin resource sharing) permet de charger des ressources, notamment des assets, depuis un autre domaine que le domaine utilisé par une application web.

Par exemple mon application est sur app.com, je veux charger une image depuis assets.com.

L'intérêt est d'ouvrir son application à l'utilisation de CDN et de servir ses fichiers statiques depuis plusieurs endroits et au plus prêt de l'utilisateur final.

En effet si je dois charger une image depuis mon application, un CDN comme CloudFront me la renverra probablement depuis un endroit différent selon que j'utilise l'application depuis l'Europe ou les états Unis.

D'autre part, chaque navigateur peut ouvrir un nombre limité de connexions HTTP vers un même domaine. Les dernières versions des navigateurs sont généralement autour de 6/8.

Cela signifie que si vous chargez 10 fichiers depuis un même domaine et que votre navigateur peut ouvrir 8 connexions, il devra attendre d'avoir chargé le 1er fichier pour charger le 9ème.

Ce «problème» peut facilement être contourné en faisant pointer des sous domaines de son application vers son CDN. C'est généralement ce qu'on fait avec son sous domaine CloudFront.

C'est à dire faire pointer cdn{1..4}.app.com vers assets.com au niveau DNS.

Est ce que je peux utiliser CORS dès maintenant ?

Le support de CORS par les navigateurs est plus que bon puisque toutes les dernières versions des principaux navigateurs le supportent.

Par contre les mécanismes de sécurité mis en place d'un navigateur à l'autre ne sont pas les même.

En effet, la possibilité d'ouvrir une ressource depuis un autre domaine peut poser quelque soucis de sécurité, puisque par définition on charge un contenu sur lequel on n'a pas de contrôle.

Par exemple les requêtes Ajax était traditionnellement limitées à une police de sécurité stricte des navigateurs, les cantonnant au même domaine. Ce n'est plus le cas depuis l'avènement d'HTML5.

Pour éviter que tout le monde puisse charger n'importe quel contenu, le mécanisme CORS a été mis en place.

Il prévoit que la source du contenu chargé doit explicitement spécifier les domaines qu'elle accepte pour accéder à ses ressources, via l'entête Access-Control-Allow-Origin.

En tant que domaine assets.com, je peux donc annoncer que seul de domaine app.com peut accéder aux ressources proposées.

Ces mécanismes de protection s'appliquent aux JavaScript mais également aux webfont dans le cas de Firefox. Autant Safari et Chrome ne broncheront pas si vous essayez de charger une font type .woff depuis un CDN, autant Firefox s'attend à recevoir les entêtes précisant que le domaine de destination nous y autorise.

Cela signifie que lorsqu'on utilise un CDN comme CloudFront on doit renvoyer ces entêtes sinon la font en question ne sera pas chargée.

Ce n'est peut être pas très grave dans le cas d'une font de caractères ou vous avez sûrement un fallback vers une font classique ; mais dans le cas d'une font d'images c'est plus gênant, voyez plutôt:

Mettre en place CORS avec CloudFront

Le fonctionnement de CloudFront est simple. Imaginons que vous l'utilisiez pour vos images.

&lt;img src="//app.CloudFront.net/images/awesome.png" alt="Awesome image" /&gt;

Si l'image est présente sur votre CDN il la sert directement, si ce n'est pas le cas il la demande à votre application et la met en cache pour la servir directement la fois prochaine.

C'est donc bien au niveau du serveur web de votre application qu'il va falloir renvoyer les entêtes adaptés.

En l'occurrence dans Nginx:

location ~* \.(eot|ttf|woff)$ {
  add_header "Access-Control-Allow-Origin" "app.com";
}

Pour que CloudFront ait «connaissance» de votre application il faut lui donner l'URL de celle via l'onglet Origin.

Lorsque vous faites une requête sur CloudFront, celui ci renvoie les même entêtes que si c'était votre application qui répondait.

Dès lors qu'on consultera un .woff on enverra donc l'entête Access-Control-Allow-Origin

Côté CloudFront il faut s'assurer qu'il laisse passer l'origine. Rendez vous sur votre console AWS, CloudFront, choisissez Distribution Settings, Onglet Behaviors.

Nous allons maintenant indiquer que nous souhaitons transférer certains entête de la requête initiale, notamment l'origine.

En effet pour simplifier la mise en cache CloudFront ne retient par défaut aucun entête.

C'est tout pour la mise en place de CORS avec CloudFront

Un coup d'œil sur un autre CDN, google fonts

Regardons les headers retournés par Google fonts lorsqu'on charge une font:

wget --server-response -O /dev/null http://themes.googleusercontent.com/static/fonts/opensans/v8/cJZKeOuBrn4kERxqtaUH3bO3LdcAZYWl9Si6vvxL-qU.woff

HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Content-Type: font/woff
  Last-Modified: Tue, 28 Jan 2014 23:51:09 GMT
  Date: Wed, 02 Jul 2014 14:25:43 GMT
  Expires: Thu, 02 Jul 2015 14:25:43 GMT
  Access-Control-Allow-Origin: *
  Timing-Allow-Origin: *
  X-Content-Type-Options: nosniff
  Server: sffe
  Content-Length: 14604
  X-XSS-Protection: 1; mode=block
  Cache-Control: public, max-age=31536000
  Age: 416552
  Alternate-Protocol: 80:quic
Length: 14604 (14K) [font/woff]
Saving to: '/dev/null'

Google fonts agit ici comme un CDN, l'avantage est que la font a pu être potentiellement déjà chargée par une autre application, et par conséquent peut déjà se retrouver dans le cache du navigateur client.

Ici l'entête qui nous intéresse le plus est le header Access-Control-Allow-Origin: *, qui indique que le contenu peut être chargé depuis n'importe quel origine. On peut donc parfaitement utiliser un wildcard pour cet entête.

On notera que la mise en cache est particulièrement longue (1 an), puisque ce contenu n'a pas vocation à changer régulièrement.

Le mot de la fin concernant CORS

CORS ne se limite pas au verbe HTTP GET, en effet la spec prévoit qu'il est possible de faire du CORS en POST par exemple. Dans ce cas le navigateur doit envoyer une requête avant (preflight) afin de demander quelles méthodes il peut utiliser pour cette ressource.

J'espère que cet article vous permettra d'y voir plus clair sur l'intérêt et le fonctionnement de CORS.

Lancement d'Hackademy

2014-04-10T00:00:00Z

Hackademy

Après 4 ans de rédaction d'articles et prês de 200 billets au compteur, nous avons fait le constat que nous aimions toujours autant partager nos retours d'expériences et la connaissance de nos outils ; mais également que cela vous plaisait beaucoup.

Nous avons donc naturellement décidé d'aller plus loin en lançant Hackademy, une plateforme de tutoriels vidéos destinés aux métiers du web.

Étant donné le peu de couverture francophone les vidéos seront disponibles en français.

Quel format ?

Nous souhaitons diffuser des vidéos courtes, de 5 à 10 minutes, qui vous permettront soit d'avoir un tour d'horizon d'un outil ou d'une technologie, soit d'approfondir un sujet et d'obtenir un point de vue averti.

Notre constat est que tester et s'approprier des outils ou techniques à disposition est très chronophage. Ce travail de veille et d'expertise est pourtant fondamental puisqu'il permet de choisir et maîtriser ses outils.

En mutualisant cette expertise nous voulons vous faire gagner du temps en tant que développeur, designer, intégrateur, bidouilleur… afin que vous puissiez être plus efficace et également trouver et contrôler les outils que vous aimerez utiliser au quotidien.

De quoi ça parle ?

Nous avons délimité 4 thématiques assez larges:

Le développement (on parlera de ruby, go, python, performances…)
Le développement opérationnel / devops (on parlera de vagrant, docker…)
L'UI/UX (on parlera de design, d'intégration et de leurs outils…)
Data (on parlera de SQL, NoSQL, traitement de données, ETL…)

Nous sommes ouverts sur leur contenu, mais également sur les catégories en elles-mêmes.

Pourquoi une plateforme ?

Le mot plateforme prend son sens dans la contribution. Nous souhaitons qu'Hackademy soit à disposition en consultation et en diffusion. Que chacun puisse y poster ses vidéos.

Pour cela nous avons préparé des outils à base de machine virtuelle afin de faciliter la réalisation des vidéos.

Si vous souhaitez proposer un sujet, nous vous invitons à nous contacter.

Est ce payant ? Puis je être rémunéré ?

La plupart des vidéos seront gratuites, certaines seront réservées à nos abonnés payants. Les contributions sous forme de vidéos payantes seront rémunérées à leurs auteurs.

Pour les contributions gratuites elles sont un excellent moyen de se donner de la visibilité, par exemple pour un freelance qui souhaite mettre en avant son expertise.

Ça commence quand ?

La machine est lancée, nous avons d'ores et déjà produit 3 vidéos et la suite arrive.

Que vous aimiez l'initiative ou non, que vous ayez envie de contribuer ou pas, plus que tout nous aimerions avoir votre avis. Dites nous ce que vous en pensez !

Freelance ou agence, qui choisir et pourquoi ?

2014-03-18T00:00:00Z

J'ai conscience que ce point peut être sujet à débats, et je serai ravis d'avoir des retours d'expérience en commentaire.

Je l'aborde car j'ai une expérience des 2 situations.

Il nous arrive parfois d'être sollicité par des prospects qui mettent également en balance des freelances.

C'est tout à fait normal que le client multiplie les pistes afin de faire son choix ; même si, à mon sens, solliciter plus de 5 intervenants s'apparente à un manque de respect au vu du temps qu'ils auront chacun à consacrer.

Toutefois, je pense que solliciter à la fois des freelances et des agences n'a pas de sens.

Selon moi la vocation du freelance est de proposer son expertise dans une thématique, qu'elle soit technique ou non.

Contracter avec un freelance pour adresser plusieurs thématiques est un problème à la fois pour le freelance mais également pour le client.

À l'inverse, l'agence a vocation à accompagner un client dans plusieurs domaines, de la spécification d'un besoin à la mise en ligne d'un projet.

Le risque pour un freelance me semble de devenir un mouton à 5 pattes, ou d'accepter de le devenir. Le risque pour une agence me semble d'adresser trop de domaines en devenant moyenne dans chacun d'eux.

Je suis client, de quoi ai je besoin ?

Vous avez besoin d'un intervenant sur une thématique précise et bornée ? Les freelances sont excellents dans ce périmètre.

Gardez toutefois en tête que les disponibilités d'un freelance sont variables, la qualité du livrable et sa documentation sont des éléments importants à prendre en considération dans une éventualité de reprise.

Et ce qui intéresse le freelance, au delà de sa liberté (relative), c'est de multiplier les expériences et les challenges, autrement il se ferait embaucher par le client final.

Vous avez besoin d'accompagnement sur la durée ? C'est plutôt l'objectif d'une agence qui réalise souvent des prestations plus longues.

Vous avez besoin d'une force de frappe plus conséquente pour réaliser votre projet ? C'est également là que l'agence peut se démarquer.

Un freelance a des contraintes autres que votre projet: gestion administrative, prospection, suivi client, veille… qu'il peut difficilement mutualiser ou reporter, autrement il ne tiendra pas sur le long terme.

Ces responsabilités existent aussi dans une agence mais peuvent être diluées entre plusieurs personnes, ce qui entraîne une disponibilité plus importante dans la réalisation effective de votre projet.

Cette disponibilité n'est pas nécessairement problématique mais doit être abordée dès le départ. Elle peut se régler en plusieurs configurations: disponible 2 semaines de suite mais pas la 3ème, disponible 4J sur 5 ; tout dépend de vos contraintes et vos besoins en tant que client.

Il est toujours possible de réunir plusieurs freelances aux compétences différentes et sensées être complémentaires. Dans les faits, j'ai rarement vu de réussite dans ces configurations. D'une part, cela oblige le client à orchestrer et organiser tout ce petit monde.

D'autre part, cela dilue les responsabilités où chacun a vite fait de se défausser sur l'autre (c'est pas la faute du créa, c'est la faute de l'inté…) et d'allonger les délais (je ne peux pas avancer tant que je n'ai pas reçu…).

Dans le cadre d'une agence cette organisation est masquée et n'est pas de votre ressort, ce qui ne signifie pas que ces problématiques n'existent pas.

Et le prix ?

Soyons clair le prix n'a rien à voir avec le type de structure, il dépend de la valeur qu'une personne ou une structure peut apporter à votre projet.

Ça semble idiot à écrire mais les clients se posent rarement ces questions:

Est ce que la personne ou l'agence a de l'expérience dans le domaine qui m'intéresse ?
Est elle référente dans son domaine de compétence ?
Est elle comparable ou est elle trop opaque pour que j'ai le moindre critère objectif ?
A t-elle déjà travaillé sur des sujets proches ?
Que disent les gens qui ont travaillé avec ?

Votre projet n'a pas besoin de valoir 100K€ pour se poser ces questions.

Trop souvent on s'arrête à un prix qui ne veut rien dire. Quelqu'un vous propose un tarif de 600€/J contre 400 d'un autre côté ? Mais si le premier réalise la prestation en 5J et l'autre en 10 ?

Sollicitez des experts sur le cœur de valeur de votre projet, qu'ils soient freelance ou agence et faites en sorte de le faire en premier.

Vous construirez la partie visible de l'iceberg par la suite, sans forcément avoir besoin de spécialistes pour ça.

Nous avons des clients qui nous sollicitent pour prototyper le cœur de l'application uniquement et cela nous convient très bien. D'autre souhaitent un accompagnement qui va au delà de la réalisation et cela nous plaît également.

Conclusion

Prestataires : que vous travailliez seul ou en équipe, bâtissez votre offre sur vos points forts quels qu'ils soient (compétences techniques, réseau, communication…) et prenez le risque de dire non quand vous sentez que vous n'allez pas dans le bon sens.

Clients : impliquez vous ! Dans votre produit cela semble évident, mais essayez également de comprendre, sans nécessairement maîtriser, les domaines de compétences auxquels vous faites appel.

C'est cette implication qui vous permettra de faire les bons choix d'intervenants et qui conditionne la réussite de votre projet.

Les filles apprennent à développer à Lille le 31 janvier et 01 février 2014 à Lille avec RailsGirls Lille

2014-01-20T00:00:00Z

Geeks cherchent geekettes

L'idée de RailsGirls est simple : permettre aux filles (mais pas que) de venir gratuitement s'initier au développement web le temps d'une journée.

C'est un concept né en 2010 en Finlande.

Il ne s'agit pas de chercher à devenir développeuse au sortie d'un RailsGirls (même si on espère créer des vocations), mais surtout de permettre aux filles de mieux appréhender le métier technique de développement et venir poser toutes leurs questions, surtout celles que l'on ose pas poser à ses collègues habituellement.

C'est pour qui ?

Le Rails Girls s'organise en 3 types de participants:

Les mentors
Les initiés
Les sponsors, dont Synbioz fait partie

C'est quand ?

Rails Girls Lille aura lieu le vendredi 31 janvier 2014 (soir) et le samedi 01 février 2014 (journée).

L'événement s'organise en deux temps, la veille chacun vient avec sa machine, on se regroupe autour d'un apéro, on apprend à se connaître et on configure les machines pour être prêt à l'emploi le lendemain.

C'est où ?

Les 2 jours se dérouleront à Lille, au Mutualab, 19 rue Nicolas Leblanc Lille.

On s'inscrit où ?

L'inscription se fait via meetup, à cette adresse: http://www.meetup.com/rubynord/events/159579892/

Vous pouvez retrouver toutes les informations concernant l'événement sur la page Rails Girls dédiée

Je ne viendrai pas mais…

Même si vous ne venez pas vous pouvez nous aider !

Il vous suffit de relayer le message, que ça soit sur Facebook, Twitter, en envoyant un email à vos amis ou tout autre moyen.

Rendez vous dans 10 jours.

Du cache HTTP avec les ETag en rails

2013-12-06T00:00:00Z

Notre article sur les caches http vous a expliqué comment fonctionnait le mécanisme de cache, et les échanges entre client et serveur associés.

Nous y avions également évoqué le fonctionnement du mécanisme d'ETag. Voyons aujourd'hui comment le mettre en place dans notre application ruby on rails.

À quoi sert un ETag ?

Le principe d'un ETag est d'associer un identifiant à une ressource HTTP, typiquement une URL. Généralement cet identifiant correspond à un hash.

Ce hash est relatif au contenu que sert la ressource HTTP, de telle sorte qu'il change si la ressource fournie change également.

Quand le client va interroger le serveur il va demander l'URL en fournissant également le ETag qu'il possède. Le serveur va vérifier que le ETag fourni correspond toujours à la ressource actuelle. Si c'est le cas, il va simplement renvoyer un code 304 pour lui signifier qu'il peut utiliser sa version en cache car elle est à jour.

Autrement il fournit le nouvel ETag et son contenu.

On veut des exemples

Nous allons créer une application simple basée sur un scaffold de produit:

bin/rails g scaffold products title description:text price:decimal active:boolean

Voilà la tête de notre action show:

class ProductsController < ApplicationController
  before_action :set_product, only: [:show, :edit, :update, :destroy]

  # GET /products/1
  # GET /products/1.json
  def show
  end
end

Dès lors que vous avez en place un contrôleur classique, un entête ETag est déjà envoyé par le serveur avec votre réponse, par contre il n'est pas exploité en l'état.

Pour mettre en place la gestion du ETag c'est aussi simple que :

def show
  fresh_when(@product)
end

Dès lors notre contrôleur va renvoyer une 304 si la ressource n'a pas changée.

Un cache lié à l'objet

L'intérêt est que vous n'avez pas à gérer manuellement l'invalidation du cache et la gestion du ETag. En effet dès lors que vous modifiez votre objet, par exemple :

product = Product.last
product.update_attributes title: "Reload"

le ETag va changer, le serveur enverra à nouveau une 200 et votre nouvelle ressource sera cachée par le client.

Ce système est vraiment pratique, car transparent, mais il a ses défauts. D'une part si vous mettez à jour l'objet directement en base, que ça soit par le biais d'un script tiers, ou d'un update_column(s) le ETag associé à votre objet ne changera pas.

D'autre part ce couplage entre ETag et objet ne permet pas d'invalider le cache en cas de modification de la vue.

Si par exemple vous modifiez une balise, cela ne sera pas pris en compte.

Aller plus loin

Réaliser des opérations selon l'état du cache

Si vous souhaitez réaliser des traitements si votre objet est périmé vous pouvez utiliser stale?

def show
  if stale?(@product)
    @product.compute_values
    respond_to do |format|
      format.html
    end
  end
end

Que ce soit stale? ou fresh_when vous pouvez passer 3 options, le etag, si vous voulez spécifier sur quel objet le calculer, le last_modified, qui par défaut utilisera le updated_at de l'objet s'il existe et enfin public.

Par défaut le cache est privé, ce qui empêche les intermédiaires entre client et serveur de mettre en cache la ressource (un proxy par exemple).

Si votre ressource HTTP ne contient que des informations publiques vous pouvez l'utiliser.

ETag global

Depuis Rails 4 vous pouvez spécifier un bloc pour l'ensemble de votre contrôleur.

C'est très commode dans le cas ou vos URL renvoient des contenus différents selon les cas. L'exemple le plus fréquent est celui de la gestion de l'utilisateur courant.

Sur les différentes actions, on voudra générer un ETag différent d'un utilisateur à l'autre afin de s'assurer qu'un utilisateur non identifié ne puisse accéder à une page en cache.

etag { current_user.try :id }

Il est parfaitement possible de cumuler les bloc etag {}.

etag { current_user.try :id }
etag do
  { customer_id: current_customer.id } if %w(index edit).include?(params[:action])
end

Comment sont gérés les ETag par Rails ?

Tout d'abord il faut préciser que la gestion est différente entre Rails 3 et Rails 4.

En rails 3 c'est un hash du body qui était produit en tant que contenu du ETag. L'avantage est que la modification de la vue était bien répercutée sur le ETag, on pouvait donc en modifier le code sans problème.

L'inconvénient était de devoir recalculer ce body à chaque fois. Au final on gagnait en données non transférées mais le serveur devait toujours fournir le même travail.

En Rails 4 en revanche, quand nous passons notre objet product à fresh_when, rails va faire l'équivalent de:

response.etag          = @product
response.last_modified = @product.updated_at

Le setter etag peut prendre un tableau, qui correspond aux blocs définis dans le contrôleur.

Il faut savoir que chaque objet à sa propre clé de cache, que ce soit l'instance d'ActiveRecord, comme le modèle en lui même:

Product.model_name.cache_key
# products
product.cache_key
# "products/1-20131206092118622798000"

La chaîne de product correspond donc à la clé de cache du modèle suivi de l'id et du timestamp (colonne updated-at en UTC) de l'objet.

Enfin cette clé est hashée en md5:

Digest::MD5.hexdigest(key)
# f8ea69ebc103b48971a6ec1bd82af7ef

Rails 4 se base donc uniquement sur la clé de l'objet et non plus sur le contenu de la réponse. C'est beaucoup plus performant mais ça pose les problèmes de modification de la vue.

Et pour les collections ?

Vous vous demandez sûrement comment Rails fonctionne pour les collections. En effet il n'y a pas de cache_key pour ActiveRecord::Relation.

Et bien rails, plus particulièrement ActiveSupport::Cache.expand_cache_key(object), renvoie une concaténation des différentes clés des objets composant la collection.

Dans ce cas, si votre collection est triée dans votre vue, vous aurez besoin d'utiliser vos paramètres de tri dans un bloc etag {}.

Conclusion

Le gros avantage du cache HTTP par le biais des ETag tient au fait qu'il est disponible de base. Vous n'avez pas d'installation complémentaire à réaliser.

Forcément, plus la page de base est lourde, plus ce cache est important.

Maintenant, comme tout système de cache, il doit être bien réfléchi et il sera relativement complexe à tester.

There are only two hard things in Computer Science: cache invalidation and naming things.
— Tim Bray.

Créer un nouvel utilisateur PostgreSQL

2013-10-07T00:00:00Z

Créer utilisateur PostgreSQL

Lorsqu'on vient d'un autre SGBD on ne sait pas forcément comment fonctionne PostgreSQL pour la création d'utilisateur.

En fait il possède des commandes et un utilisateur dédié. La première chose à faire va donc être de basculer sur cet utilisateur.

sudo -s -u postgres

Ensuite nous allons créer un nouvel utilisateur pour notre projet.

Il est toujours mieux d'isoler les rôles et de limiter la portée d'une base à un utilisateur.

createuser -d -P martin

L'option -d va permettre à notre utilisateur de créer des bases. L'option -P va forcer l'affectation d'un mot de passe qui nous sera demandé de manière interactive.

Créer la base de donnée

Nous allons maintenant créer la base de données en spécifiant que c'est mon utilisateur qui en est le possesseur (owner), d'où le -O. Cette opération se fait toujours depuis le shell postgres.

createdb -O martin bdd

Connexion à la base de données PostgreSQL

Nous pouvons maintenant sortir du shell postgres et nous connecter avec notre utilisateur:

psql -U martin -h localhost bdd

À noter qu'il est possible de réaliser toutes ces opérations directement en SQL mais il est préférable d'utiliser les commandes dédiées.

En cas de doute n'hésitez pas utiliser --help sur les commandes précédentes.

respond_to et Ruby on Rails

2013-09-18T00:00:00Z

Dans notre série d'articles sur les bases de Ruby on Rails, explorons aujourd'hui la magie de respond_to.

À quoi sert respond_to ?

Le mécanisme respond_to est présent depuis les toutes premières versions de Ruby on Rails.

Il permet depuis un contrôleur d'offrir des réponses différentes selon le format demandé.

Par exemple si je demande l'affichage de mes utilisateurs en JSON, XML ou HTML, le format de rendu sera différent.

C'est particulièrement pratique si votre application web possède un front (visible en HTML) mais qu'elle agit également comme une API, par exemple au format JSON pour interagir avec une application mobile.

Comment est déterminé le format ?

Prenons un contrôleur tout ce qu'il y a de plus basique:

class ProductsController < ApplicationController
  def index
    @products = Product.all
  end
end

Ruby on Rails utilise 2 moyens pour déterminer le format demandé.

Depuis l'extension de l'url (ex: /products.xml)
Depuis les entêtes envoyés par le navigateur (entête Accept)

Le premier est prioritaire sur le second, vérifions avec curl:

curl -i -H "Accept: application/json" http://localhost:8000/products.xml

Voici la partie du résultat qui nous intéresse:

Missing template products/index, application/index with {:locale=>[:en], :formats=>[:xml], :handlers=>[:erb, :builder, :raw, :ruby, :jbuilder, :coffee]}. Searched in:
  * "/Users/fuse/tmp/respond/app/views"

On voit bien que le format recherché est XML. Ce format n'existe d'ailleurs pas de notre côté.

À noter que le contrôleur n'a pas besoin de respond_to explicite quand la vue est présente, quelque soit le format.

Si nous créons une fichier views/products/index.html.erb, ou views/products/index.xml… le contrôleur rendra automatiquement la vue correspondante au format, autrement nous aurons un Template is missing.

Toutefois dès lors que nous définissons un bloc respond_to, nous devons définir tous les formats acceptés, le mapping ne se fait plus automatiquement avec les vues.

Gestion des formats

Vous aurez remarqué que Rails «connaît» un certain nombre de formats. Ces formats représentent le content-type du fichier, autrement appelé type MIME. Vous pouvez les lister avec Mime::EXTENSION_LOOKUP.

Dans Rails, chaque type est en fait un sous module de MIME. Exemple:

Mime::CSV
=> #<Mime::Type:0x007f8954b5e3b8 @synonyms=[], @symbol=:csv, @string="text/csv">

Si dans une action de votre contrôleur vous n'avez pas de respond_to et que vous demandez par exemple products.foo, c'est le format HTML qui sera utilisé, et ce même si vos entêtes demandent un format qui existe.

C'est tout à fait normal car les entêtes envoyés par le navigateur peuvent contenir à peu près n'importe quoi.

curl -i -H "Accept: application/xml" http://localhost:8000/products.foo renverra donc la liste des produits en HTML, même si le fichier index.xml est présent.

Définir vos propres formats

Définir votre propre format est trivial, un initializer est prévu pour cela, config/initializers/mime_types.rb.

Mime::Type.register "application/vnd.ms-excel", :xls

À partir de là vous pourrez gérer votre format Excel dans votre bloc respond_to. Si vous avez besoin de manipuler le format, celui ci se trouve directement dans la requête (request.format).

Exemple:

respond_to do |format|
    format.any(:xml, :foo) { render xml: @products }
    format.xls {
      # Charge à notre code d'implémenter le to_xls
      render xls: @products.to_xls
    }
  end

Un mot sur respond_with

Pour simplifier un peu plus Ruby on Rails a introduit le mécanisme respond_with.

Il s'agit de définir au niveau contrôleur les formats auxquels on répond, puis de répondre avec un objet.

class ProductsController < ApplicationController
  respond_to :json, :xml

  def index
    @products = Product.all

    respond_with @products
  end
end

Par défaut Rails utilise le builder intégré, c'est à dire que dans le cas de XML il fera un rendu de @products.to_xml, mais il parfaitement possible de définir sa propre vue.

À noter que les formats qui ne sont pas explicitement spécifiés ne sont pas accessibles. Ici l'URL /products n'affichera pas la version HTML.

Exploiter des données avec HStore et Ruby on Rails

2013-08-21T00:00:00Z

À l'heure (la mode) du Big Data, l'exploitation de données a le vent en poupe.

Aujourd'hui, quand on pense exploitation de données volumineuses et pas forcément structurées, on pense aussi généralement NoSQL.

Pourtant, des bases de données relationnelles comme PostgreSQL offrent des outils très intéressants tels que l'extension HStore.

Cerise sur le gâteau, notre framework préféré, Ruby on Rails, gère HStore via ActiveRecord depuis la version 4.

Présentation de HStore

À l'heure actuelle, pour stocker des données non structurées on pouvait utiliser le serialize de Ruby on Rails. Cette solution offre l'avantage d'être indépendante du SGBD.

De son côté HStore est une extension de PostgreSQL permettant de stocker des données non structurées sous la forme clé / valeur dans une colonne d'une table classique. Cette colonne est donc de type HStore.

Contrairement à un outil comme redis, ce store peut être interrogé en SQL. Il est par contre dépendant de PostgreSQL.

Usage du HStore

Voici notre cas d'usage: nous avons plusieurs fichiers CSV contenant des informations utilisateurs sur lesquelles nous aimerions réaliser quelques traitements.

Par exemple, nous voudrions faire une jointure de ces deux fichiers pour ne conserver que les lignes avec des emails communs.

D'un CSV à l'autre les données ne sont pas forcément structurées de la même façon (ordre des colonnes…).

Création de l'application

En partant de rails 4, générons une application et configurons la pour utiliser pg.

Cette application est disponible sur notre github.

HStore étant une extension, nous allons l'activer avec une migration.

bin/rails g migration enable_hstore

class SetupHstore < ActiveRecord::Migration
  def self.up
    enable_extension "hstore"
  end

  def self.down
    disable_extension "hstore"
  end
end

Nous allons ensuite créer un modèle représentant notre datastore.

Ce modèle ne comportera qu'une colonne, stockant le path de notre fichier CSV.

bin/rails g model datastore path:string

class CreateDatastores < ActiveRecord::Migration
  def change
    create_table :datastores do |t|
      t.string :path

      t.timestamps
    end
  end
end

Nous allons maintenant créer un modèle Line contenant les différents enregistrements, lié à un Datastore.

bin/rails g model line datastore:references data:hstore

class CreateLines < ActiveRecord::Migration
  def change
    create_table :lines do |t|
      t.references :datastore, index: true
      t.hstore :data

      t.timestamps
    end
  end
end

Notre modèle datastore possède une méthode de classe pour créer un datastore depuis un path.

require 'csv'

class Datastore < ActiveRecord::Base
  has_many :lines

  #
  # Load datastore from CSV file.
  # @param  path [String] path to the file. Must be related to rails root.
  #
  # @return [Datastore] return the loaded datastore.
  def self.load(path)
    app_path = Rails.root.join(path)
    if File.exists?(app_path)
      ary     = CSV.read(app_path)
      headers = ary.shift
      store   = Datastore.create(path: path)

      ary.each do |cols|
        datas = Hash[headers.zip(cols)]
        store.lines.create data: datas
      end

      store
    else
      false
    end
  end

  #
  # Return duplicated lines of the store, base on the key.
  # @param  store [Datastore] Datastore to compare with
  # @param  key [String] Key for comparing value
  #
  # @return [Array] Lines
  def duplicated_lines(store, key)
    self.lines.
      joins("join lines as l on l.datastore_id = #{store.id}").
      where("lines.data -> :key = l.data -> :key", key: key).
      all
  end
end

Il n'est pas recommandé de lire tout le fichier CSV en mémoire, ici je le fais parce que le nombre de lignes n'est pas très important.

Une fois lu, j'extrais les headers, puis j'itère sur les lignes que je zip avec ces headers.

Le zip va nous permettre de mixer les éléments deux à deux ; puis nous transformons le tableau résultant en hash pour le stocker dans le HStore.

À noter que le code contient 2 CSV dans le répertoire datas pour nos tests. Les tests unitaires sont dans test/models.

C'est la méthode duplicated_lines qui nous intéresse le plus car elle illustre ce que nous pouvons faire avec HStore.

Nous allons faire une jointure de la table ligne sur elle même en filtrant sur la clé.

Nous retournons le tout sous forme d'un tableau de lignes.

Hormis le requêtage légèrement différent, le reste est tout à fait classique.

Voici quelques exemples de requêtes possibles:

# nombre de lignes qui n'ont pas la clé email
Line.where.not("data ? :key", key: 'email').count

# ligne avec des emails en .us
Line.where("data -> :key LIKE :value", key: 'email', value: '%.us')

Le gros avantage du HStore est d'être à la fois souple et performant.

À l'inverse, les données sérialisées sont très lourdes à manipuler, et même si cela reste simple de les comparer en ruby, c'est bien plus lent que d'utiliser directement PostgreSQL pour cela.

Dernier point, et non des moindre, il est parfaitement possible d'indexer les champs de type HStore pour en accélérer le requêtage. Le gain n'est effectif que sur certains opérateurs.

Pour aller plus loin, je vous encourage à consulter l'excellente documentation en ligne de PostgreSQL.

Un asset pipeline pour sinatra

2013-07-16T00:00:00Z

Ruby on Rails nous offre de précieux outils par défaut pour améliorer la performance de nos applications web.

L'asset pipeline en fait partie. En suivant quelques conventions, les fichiers JavaScript et CSS sont automatiquement compressés et minifiés en production.

Sprockets

Ce travail est réalisé par la gem sprockets.

Toutefois Sprockets est une application Rack à part entière et est maintenant complètement décorrélée de Ruby on Rails.

Rien ne nous empêche donc de l'utiliser dans un autre framework basé sur Rack comme Sinatra.

Intégration de Sprockets dans Sinatra

Sinatra est le micro framework que nous utilisons pour faire tourner ce site.

Pour de petits besoins applicatifs il est parfaitement adapté.

Pour commencer nous allons charger les gems qui vont bien :

# Gemfile
gem 'sprockets'
gem 'yui-compressor'

yui-compressor va se charger de compresser le résultat en sortie.

Puis nous éditons notre fichier de rackup :

require 'sprockets'
require "yui/compressor"

map '/assets' do
  environment = Sprockets::Environment.new
  environment.append_path 'assets/javascripts'
  environment.append_path 'assets/stylesheets'

  environment.js_compressor  = YUI::JavaScriptCompressor.new
  environment.css_compressor = YUI::CssCompressor.new

  run environment
end

Ensuite il reste à créer une arborescence assets avec les sous-dossiers javascripts et stylesheets et d'y placer les manifest et les fichiers.

On pourra également créer un sous dossier vendor.

Un exemple de manifest:

//= require vendor/foo
//= require bar

C'est tout ce dont vous aurez besoin pour que vos assets soient servis compressés et minifiés.

Le problème est que cette compilation va se faire à chaud (à l'éxécution), ce qui n'est pas particulièrement performant et donc pas acceptable en production.

L'idéal serait que, comme en Rails, un fichier soit compilé au déploiement et automatiquement servi.

Compiler les assets

Commencons par définir sprockets dans le fichier de notre application, pour nous synbioz.rb :

APP_DIR = Dir.pwd

set :sprockets, (Sprockets::Environment.new(APP_DIR) { |env| env.logger = Logger.new(STDOUT) })
set :assets_prefix, 'compiled'
set :assets_path, File.join(APP_DIR, 'public', settings.assets_prefix)

configure do
  settings.sprockets.append_path 'assets/javascripts'
  settings.sprockets.append_path 'assets/stylesheets'

  settings.sprockets.js_compressor  = YUI::JavaScriptCompressor.new
  settings.sprockets.css_compressor = YUI::CssCompressor.new
end

Nous allons maintenant adapter le bloc /assets de notre rackup, qui sera utilisé uniquement en mode development.

En effet les assets ne seront plus servis en invoquant directement sprockets en production.

map '/assets' do
  run settings.sprockets
end

Dorénavant il nous faut une tâche pour compiler nos manifest. Créons cette tâche dans le Rakefile :

namespace :assets do
  desc 'compile assets'
  task :compile => [:assets_version, :compile_js, :compile_css]

  desc 'compile javascript assets'
  task :compile_js do
    compile('js')
  end

  desc 'compile css assets'
  task :compile_css do
    compile('css')
  end

  desc 'create assets version'
  task :assets_version do
    set :assets_version, Time.now.to_i
    File.open(File.join('public', 'ASSETS_VERSION'), 'w+') { |f| f.write(settings.assets_version) }
  end

  private
  def compile(filetype)
    sprockets = settings.sprockets
    asset     = sprockets["application.#{filetype}"]
    outpath   = File.join(settings.assets_path, filetype)
    outfile   = Pathname.new(outpath).join("application.#{settings.assets_version}.#{filetype}")

    FileUtils.mkdir_p outfile.dirname

    asset.write_to(outfile)
    asset.write_to("#{outfile}.gz")
  end
end

La tâche de compilation, disponible via rake assets:compile va compiler les CSS et les JS respectivement dans public/compiled/css et public/compiled/js en créant les dossiers s'ils n'existent pas.

Évidemment ces dossiers ne doivent pas être versionnés.

Nous créons également un fichier contenant la version des assets, sous forme d'un timestamp, le but étant d'éviter d'avoir toujours le même nom de fichier et que les navigateurs servent le fichier de leur cache et non le fichier à jour.

Le pipeline de Rails utilise un mécanisme de digest, ici nous utilisons un simple timestamp. Les fichiers finaux auront ce type de chemin : public/compiled/js/application.1373894136.js.gz

Helpers et déploiement

Il nous reste maintenant à mettre en place des helpers pour que le contenu soit servi directement par sprockets en development et depuis les fichiers minifiés statiques autrement.

Par souci de clarté nos helpers sont encapsulés dans un module.

module AssetHelper
  def digest
    @digest ||= File.read(File.join("public", "ASSETS_VERSION"))
  end

  def js_tag
    if ENV['RACK_ENV'] == 'development'
      '<script src="/assets/application.js" type="text/javascript"></script>'
    else
      "<script src=\"/compiled/js/application.#{digest}.js\" type=\"text/javascript\"></script>"
    end
  end

  def css_tag
    if ENV['RACK_ENV'] == 'development'
      '<link rel="stylesheet" href="/assets/application.css" type="text/css" media="all" />'
    else
      "<link rel=\"stylesheet\" href=\"/compiled/css/application.#{digest}.css\" type=\"text/css\" media=\"all\" />"
    end
  end
end

helpers AssetHelper

Un point important à prendre en compte, notamment pour vos CSS : faites attention à vos chemins.

Étant donné que public/compiled/css possède plusieurs niveau de profondeur, les chemins relatifs risquent d'être complexes à maintenir entre dev et production.

Mes images étant servies depuis /public, un chemin absolu me convient bien, autrement un helper, type asset_path en Rails, peut être pratique.

Dernière chose à ne pas oublier, la compilation des assets au déploiement :

run "cd #{release_path}; RACK_ENV=#{rack_env} bin/rake assets:compile"

Et voilà, vous n'avez plus d'excuses pour faire 15 requêtes HTTP quand 2 sont possibles depuis votre site en Sinatra.

Héberger une application Ruby on Rails avec Amazon Web Services

2013-07-02T00:00:00Z

Rubber est un plugin capistrano dont le but est de faciliter le déploiement d'applications Ruby on Rails sur Amazon Web Services (AWS).

Partons de 0 pour déployer la pré-production d'une application sur AWS.

L'application Ruby on Rails

Commencons par créer une application Rails basique:

rails new todo -d postgresql
bin/rails g scaffold task description:text
bin/rake db:migrate
rm public/index.html
root :to => 'tasks#index'

Configuration d'une instance Amazon EC2

La première chose à faire est de se créer un compte sur Amazon AWS.

Une fois que tout est en ordre nous allons aller dans notre console, qui reprend tous les services auxquels nous avons accès.

Dans la section EC2, nous allon créer une instance, en nous basant sur une Ubuntu 12.04 LTS.

Nous pouvons choisir le type d'instance, selon les besoins en ressources:

Notre instance va ensuite démarrer:

Nous pouvons la couper car rubber va reconfigurer sa propre instance. Pour cela un clic droit sur la ligne avec terminate suffit.

Vérifier que notre instance Amazon EC2 fonctionne

Afin de pouvoir accèder en SSH à notre instance nous allons générer un jeu de clés par le biais du menu key pairs.

Il est possible d'utiliser le nom par défaut (gsg-keypair) ou pas. Attention le jeu de clé doit correspondre à la zone où sera déployée l'application, c'est à dire ne pas avoir un jeu de clé Ouest pour une application web sur la zone Est.

Une fois réalisé nous allons placer cette clé privée dans le dossier ec2 et générer la clé publique associée.

mkdir ~/.ec2
mv ~/Downloads/gsg-keypair.pem ~/.ec2/gsg-keypair
chmod 600 ~/.ec2/gsg-keypair
ssh-keygen -y -f gsg-keypair > gsg-keypair.pub

Vous devez maintenant pouvoir vous connecter à l'instance via:

ssh -i ~/.ec2/gsg-keypair ubuntu@ec2-54-218-17-153.us-west-2.compute.amazonaws.com

La valeur du host est le public DNS disponible quand vous cliquez sur l'instance dans la console Amazon AWS.

Configuration de notre application Rails avec Amazon

C'est maintenant que Rubber entre en jeu. La première chose à faire est de l'installer au niveau global.

gem install rubber && rbenv rehash

À l'image d'un capify pour capistrano, nous allons «vulcaniser» l'application.

Pour cela nous allons choisir un template. Les templates sont des jeux de configuration prêts à l'emploi.

Il en existe un grand nombre dans le dépôt Github Rubber.

Nous allons utiliser nginx, unicorn avec postgresql par le biais du template complete\_unicorn\_nginx\_postgresql.

Tous les fichiers de configuration sont ajoutés directement dans l'application. Ils possèdent tous des réglages par défaut qui sont bien sûr éditables, mais qui fonctionnent en l'état.

La commande ajoute également les gem rubber et open4 dans notre Gemfile.

Il est important de décommenter therubyracer dans le Gemfile, autrement aucun moteur ne sera disponible pour compiler les assets.

Le seul fichier à configurer est le fichier config/rubber/rubber.yml

Les paramètres à changer sont:

Le nom de l'application
L'app_user, si vous avez pris l'AMI Ubuntu c'est «ubuntu» l'utilisateur par défaut
La timezone utilisée, par exemple US/Western
Le domaine de l'application
La région du serveur dans la section aws, par exemple us-west-2

Configuration des clés

Il faut ensuite configurer les clés d'accès Amazon AWS.

Le numéro de compte (account) se trouve dans Account Identifiers: aws_security_credentials

Il faut ensuite aller dans la section Security Credentials, puis Access Keys et créer une clé.

Vous pouvez recopier Access Key ID dans la section access_key de la configuration. Pour le secret il faut se rendre dans la section sécurité et l'afficher.

Pour la partie keyname il faut faudra la changer si vous n'avez pas gardé gsg-keypair. Enfin il faudra configurer les informations de l'image. Le type (ex: m1.medium) et l'id (ex: ami-70f96e40).

Création d'un staging

À partir de là vous avez normalement tous les réglages suffisants pour créer un staging.

J'ai toutefois dû modifier les règles de sécurité suivantes:

auto_security_groups, chaque rôle a son propre groupe de sécurité.
isolate_security_groups, isôle également les rôles au niveau environnement (web_production et staging_production sont des groupes différents).

J'ai du mettre ces 2 valeurs à false pour éviter l'erreur You have exceeded the number of VPC security groups allowed per instance. (Fog::Compute::AWS::Error).

Si vous avez des retours là dessus je suis preneur. J'ai aussi mis prompt_for_security_group_sync à false. Autrement dès lors que les groupes de sécurité remote ne correspondent plus, il demande explicitement s'il faut bien les supprimer.

Il nous reste donc à lancer:

cap rubber:create_staging

Ajouter une dépendance

Imaginons que par la suite votre application ait besoin d'une dépendance supplémentaire, par exemple memcached.

Dans ce cas vous allez re-vulcanizer avec le template en question:

be cap rubber vulcanize memcached

Cela aura pour effet de créer les fichiers de configuration de memcached.

Dans le fichier config/rubber/rubber-memcached.yml on voit que le memcached utilise le role memcached.

Notre instance de production ne possède pas encore ce rôle nous allons l'ajouter:

RUBBER_ENV=production ROLES=memcached be cap rubber:roles:add

Une fois réalisé vous pouvez relancer un bootstrap pour installer les paquets manquants sur l'instance voulue:

RUBBER_ENV=production be cap rubber:bootstrap

Conclusion

Il est à noter qu'avant de recréer un staging après l'avoir supprimé (cap rubber:destroy_staging), j'ai dû manuellement retirer les règles restantes dans la console AWS afin d'éviter les erreurs type: InvalidPermission.Duplicate => the specified rule \"peer: sg-f74dac98, TCP, from port: 1, to port: 65535, ALLOW\" already exists (Fog::Compute::AWS::Error)

Autrement tout c'est déroulé correctement. Vous voilà donc avec une pré-production prêt à l'emploi en quelques commandes.

Dans le prochain article nous verrons comment gérer finement plusieurs instances pour monter en charge.

Les applications web mobiles sont elles en passe de détrôner les applications mobiles natives ?

2013-05-30T00:00:00Z

C'est une tendance que nous constatons, les applications web mobiles sont de plus en plus prisées aux dépens des applications natives.

Un atout nommé responsive

L'avènement relativement récent du responsive web design a beaucoup joué, car il permet de transformer l'apparence du site en fonction des capacités d'affichage du terminal, via les media queries de CSS 3.

Cela signifie que c'est la même application web qui s'affiche que ça soit sur ordinateur ou sur smartphone. Il n'y a donc pas de fonctionnel à re-développer.

Il faut apporter une nuance sur le fait que certains composants fonctionnels, ne peuvent pas être adaptés uniquement visuellement.

Par exemple, afficher une fenêtre modale n'a pas de sens sur un mobile, de même qu'un calendrier ne peut pas se présenter de la même façon.

Cela implique de modifier l'application en elle-même. Pour autant, il n'y a qu'une application pour les différents terminaux.

Il faut également considérer que si certains éléments ne sont pas affichés, il peuvent quand même être téléchargés, ce qui alourdit inutilement la consommation de bande passante et qui pénalise tous les utilisateurs et particulièrement ceux sur mobile.

Le navigateur en tant que machine virtuelle ?

Les portages d'application standalone vers le web ont été nombreux et pas toujours heureux.

Est ce qu'utiliser Photoshop dans un navigateur a du sens ? Rien n'est moins sûr.

Migrer une application vers le web a du sens à partir du moment ou elle est collaborative. Devoir lancer son navigateur pour se servir d'un outil qu'on utilise seul n'a pas de sens.

Quelles performances ?

La question de la performance a longtemps été un argument en défaveur des applications web mobiles mais il faut reconnaître qu'elle est de moins en moins d'actualité.

La puissance et les possibilités qu'offrent les navigateurs, sur mobile ou non, sont de plus en plus impressionnantes.

JavaScript est interprété un peu plus rapidement à chaque nouvelle version de navigateur, ce qui fait du browser un excellent contexte d'exécution.

Pour quelles possibilités ?

Les navigateurs ont de plus en plus accès aux ressources intrinsèques des machines et HTML 5 a beaucoup apporté.

Il suffit de se tourner vers Google, où il est maintenant possible d'effectuer une recherche avec son micro.

On peut également citer en vrac les mécanismes de stockage de données, l'accès aux périphériques (webcam, GPS), la possibilité de faire de la visio-conférence sans plugin (WebRTC)…

Des navigateurs homogènes sur mobile

Évidemment dès qu'on parle de fonctionnalités avancées, on se retrouve en proie aux soucis de compatibilité des navigateurs, untel gérant X, l'autre non.

Ou pire : les deux le gérant différemment.

Cette contrainte est beaucoup moins présente sur le mobile que sur le desktop, d'une part parce que le mobile est plus récent, d'autre part car les 2 principaux acteurs, Safari Mobile sur iOS et Chrome sur Android, ont longtemps partagé une base de code commune avec WebKit (Chrome va maintenant utiliser Blink)

Le web devient la plateforme

C'est la promesse de Mozilla avec Firefox OS : réaliser un OS Mobile entièrement avec des technologies du web.

De fait, pour rendre son application disponible sur cet OS Mobile, aucune nouvelle connaissance n'est nécessaire, ce sont les même que pour créer une application web.

Firefox OS va donc fusionner l'OS et le navigateur, limitant les couches d'éxécution.

Quelles différences de coûts entre natif et web ?

C'est un critère fondamental dans le choix des décideurs.

Il y a de cela quelques temps on pouvait sans risque conseiller de développer une application uniquement pour iOS, dû à sa part de marché largement plus importante.

Ce n'est plus le cas aujourd'hui. Android est maintenant en tête sur tous les segments mobile, sans pour autant qu'iOS soit marginal.

Cela signifie donc que, sauf usage interne, prototype ou marché extrêmement ciblé, toute application devra être développée pour les deux plateformes.

Il faudra également se poser la question des tablettes, et de la gestion des différents terminaux sur ces OS mobiles.

Les développements natifs seront indéniablement plus coûteux s'il faut développer pour plusieurs plateformes. Les points suivants, comme la maintenance, sont également à prendre en compte.

Maintenance

Le web excelle par sa capacité à mettre à disposition une nouvelle version d'une application instantanément, et pour tout le monde.

Nul besoin de maintenir X version pour Y plateforme ni de demander la validation d'un store.

App store : avantage ou inconvénient ?

Pour les applications mobiles natives, l'app store est à double tranchant.

En faire la une peut être une formidable déclencheur de succès, tout comme son mauvais référencement peut considérablement vous pénaliser.

Naviguer dans un store sur mobile n'est pas agréable. Toute comme les internautes ne dépassent pas la première page de Roogle, ils ne parcourront pas 50 applications.

Qui plus est l'accès y est payant et chaque nouvelle version doit faire l'objet d'un validation.

Toutefois les stores vous permettent de faire complètement abstraction de la distribution de votre application (recherche, achat, mise à disposition), ce qui est un point non négligeable.

Compétences

Un autre point est celui des compétences. Les compétences en développement d'applications natives sont moins répandues que les compétences en développement web.

Évidemment ce qui est plus rare est généralement plus cher.

Des développements natifs facilités

Le développement d'application mobiles natives s'est tout de même considérablement amélioré avec des initiatives tierces comme RubyMotion.

RubyMotion est au mobile ce que Ruby on Rails est au web, un formidable jeu d'outils basés sur Ruby pour accélérer les développements d'applications mobiles sous iOS.

Il ne pallie toutefois pas (encore ?) aux contraintes de publication et de gestion des différentes plateformes telles qu'Android.

Un mot sur les solutions hybrides

Disons le clairement, les solutions type Titanium ou PhoneGap sont loin de tenir leurs promesses.

De manière générale le « Write once, run anywhere » (écris le une fois, fais le tourner partout) a toujours été un mirage en informatique.

Elles combinent de nombreux problèmes : lenteur, difficulté de débogage…

Quels arguments pour le natif ?

Les applications mobiles natives ont encore de solides arguments, tout dépend du besoin.

Dans la gestion du mode déconnecté, de la fluidité, des applications gourmandes en performances ou en rendu 3D, elles restent devant.

Les applications natives sont également appréciées pour leurs interfaces utilisateurs cohérentes. Étant donné qu'elles doivent suivre les règles de l'OS mobile, elles sont plus cohérentes.

Elles conservent également l'immense avantage des habitudes utilisateurs.

Très peu d'utilisateurs de smartphone savent par exemple comment créer un raccourci vers une application web pour pouvoir la lancer comme une application mobile.

À l'inverse, les stores sont maintenant très bien compris, en témoigne l'App Store qui a fêté son 50^ème milliard d'apps téléchargées.

Conclusion

Les applications web mobiles offrent des possibilités grandissantes pour des coûts globalement moindres.

Qui plus est, elles rattrapent leurs retards dans les domaines de prédilection des apps mobiles natives (jeu 3D avec WebGL…).

Enfin, Firefox OS, bien que partant avec beaucoup de retard, est à suivre avec attention.

Si vous devez construire une application mobile pour le moyen terme l'option web est à considérer très attentivement, car elle ne cesse de progresser.

Vos scripts ruby avec ARGF

2013-03-26T00:00:00Z

Remplacer le classique ARGV

À l'écriture d'un script ruby on a tendance à utiliser ARGV, pour lire les paramètres entrants.

Généralement cela représente le chemin d'un fichier.

Admettons que je veuille un script tout simple qui rajoute le numéro de chaque ligne:

File.open(ARGV.shift) do |f|
  f.each_line do |line|
    puts "#{f.lineno}: #{line}"
  end
end

Un appel type ./pipe.rb datas.csv fonctionne très bien mais comment faire en sorte que mon script soit réutilisable et que je puisse lui passer du contenu en entrée type:

$ echo "foo,bar\nbaz,coin" | ./pipe.rb
./pipe.rb:4:in `initialize': can't convert nil into String (TypeError)

Nous avons besoin que notre script suive les principes UNIX et puisse être utilisé avec des pipes, en sortie ou en entrée.

Pour cela nous avons à disposition ARGF. ARGF se comporte comme un flux qui est capable d'utiliser l'entrée standard (STDIN) ou un fichier. Notre script va donc se transformer en:

while file = ARGF.gets
  file.each_line do |line|
    puts "#{ARGF.lineno}: #{line}"
  end
end

La sortie (STDOUT) de echo va directement venir alimenter l'entrée de notre script ruby (STDIN) avec le résultat suivant:

echo "foo,bar\nbaz,coin" | ./pipe.rb
1: foo,bar
2: baz,coin

À noter que cela fonctionne également avec un tail -f, exemple:

$ tail -f feed.csv | ./pipe.rb
$ echo "foo,bar\nbaz,coin" > feed.csv
1: foo,bar
2: baz,coin

De la même façon la sortie de notre script peut être réutilisée dans l'entrée d'un utilitaire GNU.

cat datas.csv | ./pipe.rb | grep 'Synbioz' > results

J'espère que ces quelques lignes de Ruby (5!) vous permettrons d'agrémenter vos scripts.

Si vous avez d'autres astuces / bonnes pratiques à partager, n'hésitez pas.

Ruby 2

2013-03-05T00:00:00Z

Pour ses 20 ans, Ruby se voit offrir une release majeure, la 2.0.

Notre langage préféré n'a pas pris une ride, au contraire il gagne en maturité.

Rétro-compatible

Le point le plus important au delà des évolutions du langage est que Ruby 2 est compatible avec Ruby 1.9.

Cela va grandement faciliter le passage de l'un à l'autre. Rails 4 est d'ailleurs d'ores et déjà compatible avec Ruby 2.

Ruby continue sa croissance

En comparaison des autres langages, le nombre de gems disponibles et la croissance associée sont assez impressionnants.

Seul node semble être plus dynamique actuellement.

Attention le nombre de modules disponibles ne présume en rien de la qualité intrinsèque du langage.

Mais cela demeure quand même le gage, pour ceux qui en douterait encore, que Ruby n'est pas une voie de garage.

Par contre l'encéphalogramme de PHP semble vraiment très plat </troll>.

Nouveautés de Ruby 2

Arguments nommés

Il est rare en Ruby d'avoir des méthodes avec un grand nombre d'arguments, et ceci par soucis de lisibilité et de cohérence (inutile de se soucier de l'ordre des paramètres).

Dans le cas où un grand nombre de valeurs doivent être passées on utilise un Hash.

Rails en fait d'ailleurs grand usage par le biais de sa méthode extract_options!, qui permet d'extraire les hash.

L'inconvénient est que la définition de la méthode offre peu de visibilité sur ce qu'elle va avoir à traiter.

Les paramètres nommés existent déjà en Objective-C, et par conséquent cela a été repris dans l'implémentation de RubyMotion.

Cette fonctionnalité existe maintenant dans Ruby 2.

On peut donc définir des méthodes de la sorte:

def debug(content, *values, verbose: false)
end

L'inconvénient est qu'une valeur par défaut doit obligatoirement être fournie pour les paramètres nommés. Cela ne devrait toutefois plus être le cas dans les prochaines versions de Ruby.

De même si on passe un argument qui n'est pas inclus dans la définition on aura un ArgumentError.

debug('foo', debug: true)
# ArgumentError: unknown keyword: debug

Il existe toutefois un moyen de palier à cela en utilisant la notation **.

def debug(content, *values, verbose: false, **extras)
end

À noter également qu'il est possible de faire des choses très avancées dans les paramètres, à savoir définir un paramètre qui utilise la valeur d'un autre ou encore appeler une méthode pour initialiser la valeur par défaut d'un paramètre.

Ex:

def debug(a1 = '', a2 = a1.split, verbose: defaults, **extras)
end

def defaults
  false
end

debug "2.0.0"

a1 = 2.0.0
a2 = ["2", "0", "0"]

Création de symboles

Vous avez sûrement l'habitude de créer des tableaux de mots avec %w:

%w(foo bar baz)
=> ["foo", "bar", "baz"]

On peut désormais faire la même chose avec des symboles avec %i ou %I:

%i(foo bar baz)
=> [:foo, :bar, :baz]

UTF-8, de base

UTF-8 est maintenant utilisé de base, il n'y a plus lieu de le spécifier en haut de ses fichiers dès lors que l'on utilise quelques caractères exotiques (latin, unicode…).

Warning sur les variables inutilisées

Depuis 1.9 l'interpréteur offre des warning sur les variables non utilisées.

Généralement le moyen de l'éviter est d'utiliser _. Par exemple:

{ a: 1, b:2, c:3 }.each do |_, v|
  puts v
end

Maintenant il est aussi possible de préfixer n'importe quelle variable avec _ pour éviter les warning.

{ a: 1, b:2, c:3 }.each do |_k, v|
  puts v
end

Prepend sur les modules

Si vous utilisez rails vous connaissez sûrement prepend_before_filter. Le prepend va s'assurer d'ajouter le filtre au début de la chaîne d'éxécution.

before_filter :a
prepend_before_filter :b
# b sera appelé avant a

Le prepend introduit dans Ruby 2 a la même vocation. Il va vous permettre de vous assurer que votre inclusion a lieu au début de la chaîne d'éxécution.

En toute logique vous disposez d'un callback dans le module lorsqu'il est prepend.

module Bar
  def self.prepended(base)
    puts "Prepended."
  end

  def self.included(base)
    puts "Included."
  end
end

class Foo
  prepend Bar
end

puts Foo.ancestors.join(', ')

class Baz
  include Bar
end

puts Baz.ancestors.join(', ')

# Prepended.
# Bar, Foo, Object, Kernel, BasicObject
# Included.
# Baz, Bar, Object, Kernel, BasicObject

Refinements

Les refinements sont selon moi une vraie killer feature.

La grande promesse des refinements est de limiter voire éviter le monkey patching.

Lorsqu'on commence à goûter à la puissance de Ruby on est très friand de ré-ouvrir des classes au runtime et d'ajouter des méthodes à la volée dans des core classes.

Avec l'expérience c'est une tâche que l'on essaie d'éviter au maximum car cela n'offre aucune garantie.

N'importe qui peut avoir fait la même chose dans une lib, c'est à dire (re-)définir une méthode avec le même nom et écraser la votre.

L'objectif des refinements est de pouvoir limiter la portée d'un ajout et surtout l'obliger de manière explicite ; là ou une inclusion classique aurait une portée globale. Toutefois nous allons voir que cet objectif n'est pas réellement atteint.

module ExtendString
  refine String do
    def words
      self.scan(/[[:alnum:]]+/)
    end
  end
end

puts "Le petit chaperon rouge.".words.count
# undefined method `words' for "Le petit chaperon rouge.":String (NoMethodError)

module ExtendString
  refine String do
    def words
      self.scan(/[[:alnum:]]+/)
    end
  end
end

using ExtendString

puts "Le petit chaperon rouge.".words.count
# 4

Contrairement à ce qu'on peut parfois lire, using n'est pas utilisable à l'heure actuelle dans le contexte d'une classe ou d'un module (undefined method using).

Selon moi cela limite beaucoup son intérêt, puisqu'on ne pourra plus limiter finement sa portée. On n'aura que 2 états, avant et après using.

Toutefois, il faut intégrer que le statut des refinements est expérimental et que l'API peut changer.

Son usage est d'ailleurs actuellement déconseillé. Vous aurez un «warning: Refinements are experimental, and the behavior may change in future versions of Ruby!», sans même utiliser l'interpréteur avec -w.

Répertoire courant

Si vous trouviez aussi que File.dirname(__FILE__) n'était pas spécialement élégant, cela tombe bien on a maintenant __dir__.

Par contre je trouve dommage d'avoir une casse différente pour les deux.

Recherche binaire

Ruby possède maintenant une méthode pour rechercher une valeur dans un tableau trié.

Il s'agit d'une simple méthode dichotomique qui va donc couper le tableau en deux et comparer la valeur avec la valeur du milieu du tableau.

Selon le résultat, si non trouvé, la recherche se poursuit dans la moitié inférieure ou supérieure.

(1..10_000_000).to_a.bsearch { |v| v > 387 }
# => 388

Transformer une structure en hash

Struct.new(:foo).new('bar').to_h
# => {:foo=>"bar"}

À noter que ce n'est pas disponible pour toutes les classes, ce qui semble logique, étant donné que Ruby ne peut pas deviner comment vous voudriez transformer un Array en Hash par exemple.

to_h est disponible pour Struct, OpenStruct et nil.

Énumérateurs lazy

L'intérêt d'un énumérateur lazy c'est que l'ensemble de la chaîne de méthode sera interprétée à chaque tour de boucle:

(1..Float::INFINITY).lazy.select { |i| i * i if i.even? }.first(5)

C'est très pratique pour d'énormes volumes de données car cela évite de se retrouver avec des tableaux intermédiaires.

Surtout dans ce cas présent où la borne supérieure est infinie donc la création du tableau l'est également et que par conséquent l'interpréteur planterait sans lazy.

À noter toutefois qu'il ne convient pas d'utiliser lazy à toutes les sauces, sur des tableaux de données réduits lazy sera beaucoup plus lent que l'implémentation sans.

Méthode appelante

Dans le cas d'un debug il est souvent pratique d'avoir un aperçu de la chaine d'éxécution.

Retrouver la méthode appelante est très pratique pour cela. Précédemment en Ruby ce n'était pas très fiable et particulièrement lent.

caller_locations vous permet d'obtenir le nom du fichier, la ligne et le contexte appelant.

class A
  def hi
    puts caller_locations
    puts "Hi called by #{caller_locations[1,1](0).label}"
    hello
  end

  def hello
    puts "Hello called by #{caller_locations[1,1](0).label}"
  end
end

A.new.hi
# test.rb:70:in `<main>'
# Hi called by <main>
# Hello called by hi

Performance

Je n'ai pas encore eu l'occasion de benchmarker directement Ruby 2.0 en comparaison avec 1.9.

De profonds changements sont annoncés au niveau du garbage collector, du mécanisme de fork mais je préfère tester avant de vous en parler.

Comment l'installer ?

Ruby-build possède une formule prête à l'emploi.

J'ai vu passer quelques messages de personnes ayant eu des soucis avec openssl, mais je dois dire que je n'en ai rencontré aucun sur les différentes machines ou je l'ai installé (uniquement Mac).

Conclusion

Cette version s'annonce comme un très bon cru, qui plus est «quasiment» utilisable en l'état. Alors n'attendez plus, à vos claviers !

L'authenticity token dans ruby on rails

2013-02-07T00:00:00Z

Ruby on Rails nous offre tellement de mécanismes d'abstraction qu'on en oublie parfois les bases.

Dans l'idée de notre article sur le fonctionnement des sessions, découvrons aujourd'hui pourquoi et comment fonctionne l'authenticity token.

Pourquoi un mécanisme de token ?

L'objectif est de prévenir les attaques de type Cross site request forgery.

Le fonctionnement est simple, vous vous authentifiez sur votre application A.

Sur une autre application B vous utilisez un formulaire ou un lien qui pointe en fait vers une action de l'application A sans que vous le sachiez.

En l'absence de mécanisme de contrôle vous pouvez modifier voire supprimer des resources sur l'application A sans même vous en rendre compte.

En tant qu'utilisateur il y a un premier de niveau de sécurité à apporter ; il s'agit d'éviter de rester connecter sur des services qu'on n'est pas entrain d'utiliser.

En somme dès que j'arrête d'utiliser un service je me déconnecte.

Côté développeur il faut absolument éviter de proposer des actions suceptibles de modifier des ressources sous forme de lien ou de form en GET, car dans ce cas les token ne vous protégeront pas comme nous le verrons ci dessous.

Au delà du GET on a déjà un premier volet de sécurité concernant la politique de sécurité des navigateurs pour les appels en AJAX depuis un autre domaine.

Voir à ce sujet les commentaires de l'article sur rails 4 à propos de CORS.

Comment le token peut parer à ça ?

Quand une vue avec un formulaire est rendue, Rails y ajoute un token aléatoire dans un champ caché, et dans la session de l'utilisateur.

À la soumission du formulaire, un contrôle sera fait pour s'assurer que le token est soumis et que sa valeur correspond à celle de la session.

Concrètement ça fonctionne comment ?

Le code de génération du token est très simple, il se trouve dans ActionPack:

# Sets the token value for the current session.
def form_authenticity_token
  session[:_csrf_token] ||= SecureRandom.base64(32)
end

La vérification de la requête est elle aussi basique, Rails va juste vérifier qu'il ne s'agit pas d'une requête GET, HEAD, que la protection est activée et que le token est présent dans les params ou dans les headers, dans le cas d'une requête venant d'un autre domaine.

def verified_request?
  !protect_against_forgery? || request.get? || request.head? ||
    form_authenticity_token == params[request_forgery_protection_token] ||
    form_authenticity_token == request.headers['X-CSRF-Token']
end

Voilà tout pour cet article sur le fonctionnement des tokens.

On trouve trop souvent des articles ou des fils de discussion qui recommandent de désactiver la protection au moindre souci (souvent dans le cas d'utilisation conjointe avec AJAX).

Ne faites pas ça, creusez vous la tête et fixez le problème plutôt que d'ouvrir des brèches de sécurité.

Rails 4

2013-01-08T00:00:00Z

Nouveautés de Rails 4

Strong parameters

L'idée est de déporter la gestion des paramètres protégés du modèle vers le contrôleur.

Cela a du sens dans la mesure où l'autorisation ou non d'écrire un champ est très largement liée au contexte d'exécution (qui suis je, où…).

L'inconvénient est que cela risque de nous amener à écrire plus de code, ce à quoi nous ne sommes pas vraiment habitués.

La suppression des attr_accessible ou attr_protected risque d'être un peu déroutante, dans la mesure ou nous n'aurons pas de protection «par défaut» sur les modèles.

Un exemple de ce qu'il sera possible de faire:

class User < ActiveRecord::Base
  include ActiveModel::ForbiddenAttributesProtection
end

class UsersController
  def create
    @user = User.create(user_parameters)
  end

  private
  def user_parameters
    if current_user.admin?
      params.require(:user).permit(:firstname, :lastname, :admin)
    else
      params.require(:user).permit(:firstname, :lastname)
    end
  end
end

L'inclusion de ActiveModel::ForbiddenAttributesProtection permet de garantir que du code tel que:

user = User.create(params[:user])

ne fonctionnera plus. Sans cela les deux versions fonctionneraient.

À noter que strong_parameters est utilisable en tant que Gem dans des projets rails 3.

Turbolinks

Le principe est d'éviter de recharger l'intégralité d'une page lorsque l'on suit un lien.

Le mécanisme de base est le même que pjax, c'est à dire AJAX + pushState prévu dans HTML5.

Cela signifie que l'on exécute des requêtes asynchrones mais que l'historique est mis à jour ce qui autorise l'usage des boutons du navigateur tel que le retour à la page précédente.

Le postulat de départ est que les ressources type javascript ou CSS ne changent pas d'une page à l'autre et que l'on peut donc éviter d'avoir à les recharger.

Pour cela Turbolinks va donc aller récupérer le contenu de la page, mettre à jour les meta et autre title et changer uniquement le body.

De même si vous enregistrez vos événements manuellement après que le DOM soit prêt cela ne fonctionnera pas, car l'évènement dom:loaded n'est plus envoyé.

Turbolinks offre un mécanisme de substitution en envoyant ses propres évènements, tel que page:fetch (pour lancer le chargement), page:load (la page a été renvoyée par le serveur), page:restore (la page a été rechargée depuis le cache), page:change (la page a été remplacée par la nouvelle version).

Comme pour une Single Page Application, il faudra également faire attention à éviter les fuites mémoires.

L'avantage de Turbolinks est de se dégrader correctement, en effet l'application fonctionnera tout aussi bien sans, cela n'entrave pas la navigation.

Ce qui signifie qu'il n'y a pas de problème potentiel non plus pour votre référencement.

Stream

Un contrôleur peut maintenant inclure ActionController::Live.

Cela lui permet d'émettre une réponse sous forme d'un stream, plutôt que d'un fichier complet à interpréter ou télécharger.

Les méthodes utilisées sont response.stream.write et response.stream.close.

L'avantage est de pouvoir envoyer une réponse morcelée et potentiellement interprétable plus tôt par le navigateur.

Pour exploiter au mieux le potentiel de streaming il vaut mieux utiliser un serveur adapté comme puma, rainbows ou thin.

Le souci avec Unicorn est qu'il ferme la connexion après 30 secondes, son objectif étant de livrer la réponse le plus vite possible, ce qui n'est pas adapté pour du stream.

Verbe HTTP PATCH

Dans la logique REST, PUT concerne une modification sur l'intégralité de l'objet. C'est à dire que le formulaire devrait soumettre tous les attributs.

Une modification partielle d'objet doit normalement être effectué avec PATCH.

Comme les navigateurs ne supportent pas plus nativement PATCH que PUT et DELETE, la méthode traditionnelle sera utilisée, à savoir _method=patch.

PATCH devriendra l'usage par défaut pour les objets en modification mais PUT continuera de fonctionner.

Relations

All

Model.all sera désormais considéré comme un scope et ne retournera plus les enregistrements. C'est tout à fait logique et c'est déjà comme ça que c'est fait avec mongoid, qui retourne Mongoid::Criteria, comme pour un scope.

Pour ActiveRecord, c'est ActiveRecord::Relation qui sera retourné. Pour avoir directement les entités un Model.to_a fera l'affaire.

None

None est un scope à part entière qui ne retourne aucun résultat. Je n'ai jamais eu de cas ou je souhaitais utiliser des scope qui ne retourne rien, donc j'ai du mal à en voir l'intérêt.

Si vous avez des cas d'usages, dites le moi en commentaire.

First, last

L'appel à first et last fera explicitement un tri sur id, plutôt que de laisser le choix à votre SGBD.

À noter que si un default_scope est utilisé c'est bien lui qui sera pris en compte.

Asset pipeline

Le pipeline a été déporté du cœur de Rails, pour évoluer de façon autonome.

sprocket-rails évolue donc à un rythme plus soutenu, en calant sa fréquence sur celle de sprocket et en adoptant le même versionning.

Étant disponible en tant que gem, le réglage config.assets.enabled a été retiré. Pour ne pas utiliser le pipeline il suffit de ne pas utiliser la gem.

Les dossiers de cache ont été séparés par environnement, ce qui va nous simplifier la vie concernant les tests d'intégration.

La précompilation a été revue et très largement améliorée en terme de temps de traitement. Sur les premières démo on parle d'un facteur 5. À confirmer à l'usage.

À noter que la version 3 de sprocket-rails devrait voir l'arrivée de source maps, qui permet de faire concorder un asset original avec sa version minifiée, ce qui offre le meilleur des 2 mondes: un code maintenable, débugable et dont l'accès à la doc est simplifié tout en ayant la performance apportée par la minification.

Cette version devrait concorder avec la sortie de Rails 4.1.

References

On l'a vu à plusieurs reprises la tendance générale est à l'explicite dans Ruby on Rails. Le principe est conservé pour references.

En rails 3 includes est utilisé pour éviter les requêtes n+1. Cela a pour effet de générer 2 requêtes SQL:

Post.includes(:comments)

SELECT "posts".* FROM "posts"
SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1)

En rails 4 cela ne fonctionnera pas si vous précisez des conditions de requêtes via une string, car Rails ne sait pas quel objet vous décrivez dans ce cas.

Par exemple:

Post.includes(:comments).where("comments.created_at > ?", Date.yesterday)

ne fonctionnera pas car une jointure n'est pas faite automatiquement avec comments. Vous devrez le spécifier via:

Post.includes(:comments).where("comments.created_at > ?", Date.yesterday).references(:comments)

À ce moment ce ne sont plus 2 requêtes qui seront exécutées mais 1 seule avec un OUTER JOIN.

Par contre si vous utilisez des requêtes simples ou des symboles, Rails saura se débrouiller seul.

Ex:

Post.includes(:comments).where(:comments => { :email => '' })

Post.includes(:comments).order("comments.created_at")

Évaluation des scopes

En rails 3, tout code dynamique entrainait le besoin d'encadrer son scope dans une lambda, afin d'éviter que l'interprétation se fasse au runtime.

Désormais pour éviter toute confusion, tout scope devra être enrobé, même s'il n'y a pas de risque de confusion comme par exemple:

class User
  scope :active, where(active: true)
end

deviendra:

class User
  scope :active, -> { where(active: true) }
end

Mise à jour d'attributs

À l'image de update_attributes, update_columns fait son apparition et sera le pendant de update_column.

Voici un petit mémo sur qui fait quoi:

Le update_attribute est souvent utilisé sans savoir qu'il ne joue pas les validations.

De même les update_attribute(s) mettent à jour les dirty attributes, c'est à dire ceux dont la valeur a changé entre temps.

Ex:

u = User.first
u.firstname = "John"
u.update_attributes lastname: "Doe"

entraine:

UPDATE "users" SET "firstname" = 'John', "lastname" = 'Doe', "updated_at" = '2013-01-08 09:09:21.050217' WHERE "users"."id" = 2

La recommandation est de ne plus utiliser update_attribute, qui est en passe d'être déprécié.

C'est une situation assez compliquée. Logiquement si on fait le choix d'avoir update_column et update_columns, il n'y a pas de raison de retirer update_attribute.

Pour beaucoup son retrait aurait entrainé du code cassé lors de la mise à jour.

En le gardant et en faisant en sorte que son comportement soit le même que update_attributes, on risque aussi de casser du code mais de façon beaucoup plus critique car silencieuse.

Pourtant je suis surpris que le choix n'est pas été fait d'homogénéiser l'API. Le passage à une nouvelle version majeure aurait été une bonne occasion.

En résumé on vous conseille de ne plus l'utiliser mais rien ne change si vous choisissez de le faire quand même.

Retraits de Ruby on Rails 4

Plugins

Les plugins n'étaient plus guère utilisé en Rails 3. Ils laissent donc définitivement leur place au profit des gems.

Finder

Le find ne disparait pas en tant que tel, mais plutôt l'utilisation de symboles associés, comme find(:first), find(:last), find(:all).

Des méthodes étant prévues au niveau modèle, autant rester DRY.

Les finder dynamiques sont par contre retirés aux dépens du where. C'est à dire:

find_all_by
find_last_by
find_or_initialize_by
find_or_create_by

Je ne suis par contre pas très fan de la méthode de substitution pour les initialize, à savoir where(…).first_or_initialize.

Object#id

Qui n'a jamais vu cette erreur ?

RuntimeError: Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id

Celle ci vient du fait que 4 est l'object_id de nil. Rails vous prévient que vous vous êtes peut être trompé en appelant id à la place de object_id.

Désormais vous aurez toujours l'erreur mais elle sera affichée différemment, avec un simple NoMethodError: undefined method id for nil:NilClass, comme pour n'importe quelle autre méthode.

C'est logique car il est relativement rare d'avoir à utiliser les object_id dans son application.

Gestion du cache

Les mécanismes pour mettre en cache une page ou une action sont retirés.

Seuls les caches de fragments sont maintenus. Ces caches seront nommés grâce au hash de leur contenu, ce qui permettra de les faire expirer automatiquement si leur contenu change (puisque leur nom changera également).

Cela permet également de gérer des caches imbriqués de façon transparente.

Fini donc le versionning de cache manuel et fastidieux, tel que:

<% cache "v1", object do %>
<% end %>

La gestion se fait maintenant de manière beaucoup plus simple et automatisée:

<% cache object do %>
<% end %>

Authenticity token

En rails 3, le token est automatiquement ajouté par Ruby on Rails dans les formulaires ou les liens qui lient vers des contenu non GET.

Si le token n'est pas présent rails.js se chargeait de l'ajouter.

Ce ne sera plus le cas pour les formulaire soumis en AJAX (remote: true).

En effet la police de sécurité fait qu'il n'est pas possible de soumettre un formulaire en AJAX de depuis un autre domaine, ce qui permet d'éviter cette vérification dans le cas de requêtes de ce type.

Cela permet également de mettre en cache les formulaires. Il y a toutefois un inconvénient qui n'est pas neutre, les formulaires ne fonctionneront plus en l'état pour ceux n'ayant pas activé JavaScript.

Pour forcer l'inclusion d'un token l'option authenticity_token: true peut être utilisée.

Non inclusion dans Rails 4

Rails.queue était un peu la grosse nouveauté mise en avant pour Rails 4. Elle a finalement été retirée et ne sera pas incluse dans cette release.

Cela serait dû à des questions restées pour le moment sans réponse concernant le design de l'API de queue.

Le retrait est d'autant plus dommage qu'il se fait tardivement. Toujours est il que la question reste ouverte, la volonté est toujours affichée d'intégrer un mécanisme de queue dans Rails, mais pas sans une API consistante.

Pré-requis de rails 4

Rails 4 nécessitera Ruby 1.9.3 pour fonctionner.

En rails 4 la plupart des choses qui changent et vont être retirées sont juste dépréciées. Elles seront effectivement retirées en 4.1.

Est ce que je peux migrer vers rails 4 ?

Sur une application récente et avec une bonne couverture de tests, la migration ne devrait pas s'avérer trop complexe.

Sur une application plus ancienne (type rails 2) je ne saurai trop vous conseiller de générer un squelette d'application en rails 4 et d'y migrer votre code progressivement.

Conclusion

À mon goût la sortie de Rails 4 est moins excitante que celle de Rails 2 et 3.

La tête de gondole qu'était le système de queue a été retiré et la plupart des choses présentées sont des consolidations. Ce qui est très bien, mais pas forcément très enthousiasmant.

Par ailleurs la tendance est clairement à l'explicite. Quand il s'agit de sécurité c'est bien sûr indispensable et je pense que la vulnérabilité dévoilée sur Github aura été un des facteurs déclenchant pour revoir le système de mise à jour des objets.

En clair Ruby on Rails est entrain de devenir un framework très puissant, dont la volonté est d'intégrer les dernières possibilités offertes par le web.

Son histoire liée à celle de basecamp est un énorme avantage. La refonte de ce dernier, basecamp next, aura permis d'apporter son lot de bonnes idées à Rails, notamment en terme de performances.

Je vous avez fait part de mes inquiétudes à ce sujet et force est de constater que les choses vont dans le bon sens.

Seetemap 1.2

2013-01-03T00:00:00Z

En cette fin d'année 2012 nous avons travaillé dur sur seetemap pour tenir compte de vos remontées.

Nous vous remercions car vous avez été nombreux à tester seetemap et nous apporter vos remarques constructives.

Nous les avons prises en compte pour cette nouvelle itération.

Lancement d'audit dès la page d'accueil

Nous le savons et vous l'avez confirmé, s'inscrire à un service pour le tester est un frein pour beaucoup.

Dans cette optique nous avons mis en place la possibilité de lancer la création de sitemap dès votre arrivée sur le site.

Nous vous demandons uniquement une URL et votre email pour vous prévenir quand le sitemap est disponible.

Plans sur mesure

Nous ne pensions pas l'implémenter si rapidement mais pour certains la limitation à 10 sites était rédhibitoire.

C'est vrai qu'il aurait été dommage de créer plusieurs comptes pour cela.

Vous pouvez désormais ajouter des packs, par tranche de 10 sites, et ce jusque 100.

Filtrer les pages avec paramètres

Ce sont souvent celles que vous retirez en premier de vos sitemap, car elles lient souvent un contenu déjà lié autrement.

En deux clics vous pouvez donc les retirer durablement de votre sitemap.

En effet, une règle est automatiquement créée et les nouvelles pages contenant des paramètres seront automatiquement filtrées lors des prochains audits.

Informations complémentaires sur la page

Vous avez été nombreux à nous demander de voir autre chose que les URL des pages dans votre interface et notamment de voir les titres et descriptions.

C'est maintenant le cas et ceux ci seront renseignés lors du prochain audit de votre site.

Et bien plus

Nous avons aussi amélioré bien d'autres points, comme la consommation mémoire, la prise en compte de la demande d'arrêt d'un audit, etc…

Nous espérons que cette nouvelle version vous permettra de gérer vos sitemap encore plus simplement.

Il y a des conférences qui ne se manquent pas, voici Take Off

2012-12-15T00:00:00Z

Certes ce billet pourrait s'apparenter à du copinage, mais il n'en est rien.

Quand Florian, Benjamin et Robin sont venus présenter Take Off à un apéro ruby, j'avais déjà perçu quelques signes avant coureur sur Twitter.

Take Off a l'ambitieux objectif de réunir un panel de speakers qui nous parleront aussi bien de développement front que back et résolument tourné vers les technologies récentes ou qui vont percer dans le courant 2013.

Les conférences se feront en anglais pour être accessibles au plus grand nombre et aussi parce que le lineup réunit plusieurs intervenants non francophones.

Une conférence éclectique

Ce qui m'a immédiatement séduit c'est l'approche ouverte de la conférence. Il ne s'agit pas de venir de se focaliser sur un outil ou un langague mais de s'intéresser à tout ce qui se fait et se fera de mieux.

Les échanges s'annoncent passionnant.

Prix

Les organisateurs ont réussi le tour de force de réunir une lineup de folie à un prix absolument abordable.

On parle certes de centaines d'euros mais il faut imaginer un peu ce que ça coûte de réunir tout ce beau monde. D'autant plus que le programme comprend la restauration.

Bref, un réel tour de force. Pour ceux qui sont encore hésitants, pensez au prix que vous mettez pour acheter une place de concert ou vous avez juste 2H de show.

Là on parle de 2 jours avec plusieurs intervenants de haut vol.

Je trouve même que le prix startup ou freelance ne devrait pas exister en tant que tel, mais plutôt être un prix pour les particuliers, c'est à dire ceux qui iront sur leur propres deniers.

Lille

Comment à la fois râler que tous les événements soit centralisés à Paris et ne pas participer à une conférence chez nous ?

Les 2 journées permettront aussi de faire découvrir Lille.

Conclusion

Même si le on refera pendant et après, on peut d'ores et déjà féliciter les organisateurs de nous proposer ces 2 jours de conférences.

Chez Synbioz nous avons hâte d'y être!

Lancement en bêta de seetemap

2012-11-08T00:00:00Z

Après quelques temps de gestation nous avons le plaisir d'ouvrir les portes de notre outil de création de sitemap: seetemap.com.

L'existant en gestion de sitemap

Initialement nous avons créé seetemap pour nous car nous n'étions pas satisfaits des solutions existantes de génération de sitemap.

Concernant les solutions locales, elles sont vites limitées. Soit elles tentent de tout faire automatiquement mais ne sont pas capables de détecter toutes vos pages, soit elles vous obligent à déclarer manuellement votre contenu, ce qui s'avère vite fastidieux.

Quant aux solutions distantes elles proposent un audit one-shot, avec souvent un nombre de pages limité, au delà duquel il faut payer.

Nous avons voulu créer une solution qui permette à votre sitemap de se mettre à jour tout seul quand votre contenu évolue, sans que vous n'aillez rien à faire, et quelque soit la taille de votre site.

Sur notre application seetemap

L'usage de l'outil se veut très simple. Inscrivez vous, indiquez l'URL de votre site et attendez que l'audit se termine.

La priorité de vos pages est automatiquement calculée en fonction de leur profondeur et la fréquence de mise à jour s'adaptera automatiquement au fil des audits.

Vous pouvez également modifier manuellement ces informations, tout comme vous pouvez retirer une page de votre sitemap.

Mieux, vous pouvez rechercher des pages et les supprimer à la volée (ex: toutes les pages contenant ?page=). Cela créera une règle qui sera automatiquement appliquée lors des prochains audits, excluant les nouvelles pages qui correspondent à votre règle.

Les audits se font automatiquement à une fréquence déterminée par votre type de compte. D'une fois tous les 3 jours pour les comptes gratuits, à une génération à la demande pour les comptes business. Vous pouvez trouver une synthèse des différentes formules sur le site.

Sur votre site

Pour le moment nous avons créé un module client pour nos amis rubyistes (qui l'eût cru ?), qui permet de mettre à jour automatiquement le sitemap de votre site.

D'autres sont à venir pour différents langages et plateformes, mais vous pouvez quand même télécharger les sitemap et les déposer sur votre site, quelque soit la technologie que vous utilisez.

Nous avons donc publié un gem seetemap que vous aurez juste à inclure dans votre Gemfile. Il est compatible avec toute application basée sur rack et pas uniquement rails.

La procédure d'installation de seetemap-client est décrite sur le site, que ce soit pour rails ou sinatra.

Avis à la communauté

En premier lieu, merci à tous ceux qui nous ont fait leurs retours pendant la première phase de développement du site. Ils ont été précieux.

Nous avons beaucoup d'idées d'améliorations mais nous souhaitons d'abord écouter vos retours, et nous assurer que notre produit améliore votre quotidien.

Pour cela nous avons décidé d'offrir la formule de leur choix à nos 50 premiers testeurs, inscrivez vous vite!

Installer Ruby on Rails sur mac

2012-10-18T00:00:00Z

C'est un sujet récurrent lorsqu'on souhaite se mettre au Ruby on Rails: comment installer un environnement Ruby on Rails sur sa machine ?

Il existe de nombreux tutoriels pour installer Ruby on Rails mais les outils changent et s'améliorent au fil du temps. Les documentations sont donc parfois obsolètes.

Cet article couvre l'installation sous Mac uniquement. Elle a été testée depuis une machine virtuelle vierge sous Mountain Lion, mais devrait fonctionner tout aussi bien sur des versions plus anciennes d'OSX.

Si vous souhaitez suivre cette installation de ruby on rails sur mac en vidéo, rendez vous sur la vidéo associées sur Hackademy.

Installer XCode

XCode ne vous servira pas en temps que tel mais vous permettra d'installer simplement les outils de devéloppement (gcc…) nécessaires à la compilation de ruby.

Vous pouvez l'installer depuis l'app store.

Installer un gestionnaire de paquet

Il y a quelques temps 2 gestionnaires de paquets étaient disponibles sous Mac OS X: Fink et MacPorts.

Si vous utilisez l'un des deux assurez vous de le désinstaller.

À l'heure actuelle c'est Homebrew qui est le plus maintenu. Qui plus est, les formules permettant d'installer des packages sont écrites en ruby, ne boudons pas notre plaisir.

Pour installer brew, votre compte a besoin des privilèges administrateur:

ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"

Installer git

Git est un élément central de tous les outils que nous allons utiliser. C'est un outil de versioning de code source.

brew install git

Installer rbenv

Les derniers OS X sont livrés avec ruby mais en version 1.8.7, alors que la version actuelle est la 1.9.3.

Rbenv permet d'installer plusieurs versions de ruby et d'en changer de façon transparente selon le projet, et donc de suivre les versions les plus à jour pour les projets les plus récents.

Mettons d'abord à jour les formules de Homebrew afin d'installer les dernières versions des outils voulus.

brew update

puis installons rbenv:

brew install rbenv

rbenv va nous permettre d'utiliser plusieurs versions de ruby mais n'inclut pas de base l'outil pour installer des versions spécifiques de ruby. C'est ruby-build qui s'en charge:

brew install ruby-build

Afin que rbenv soit disponible dans notre shell, il a besoin de s'initialiser au lancement du shell:

echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile

Une fois réalisé, ouvrez un nouvel onglet dans le terminal pour que le paramétrage soit pris en compte.

Installer ruby

Maintenant que rbenv est installé, nous allons pouvoir installer la version de ruby voulue.

rbenv install 1.9.3-p194

Définissons cette version comme la version par défaut plutôt que la version 1.8.7 du système:

rbenv global 1.9.3-p194

Installer bundler

L'environnement ruby est composé de gems, qui sont des libs, voire plus, packagées. Bundler est un outil permettant de gérer les dépendances et les versions de ces gems.

gem install bundler

Installer Ruby on Rails

Installons la dernière version de rails:

gem install rails

Au besoin nous pouvons installer une version spécifique, par exemple:

gem install rails -v=3.1

On le voit à l'installation, Ruby on Rails dépend de nombreuses gems.

Quand vous installez une gem qui mettra à disposition une commande, il est important de faire un rbenv rehash.

Une fois installée, la commande est disponible, vous êtes prêt à créer votre première application Ruby on Rails:

rails new app

Spécifier la version de ruby de notre application Rails

Indiquer la version de ruby utilisée est très simple, il suffit de créer un fichier .rbenv-version dans le projet, contenant le numéro de version.

Si je me déplace dans un dossier contenant ce fichier, c'est la version définie qui prendra le pas sur la version globale.

Si par exemple dans mon projet je crée un fichier avec la dernière version sortie (1.9.3-p286), ruby -v m'indiquera que la version n'est pas installée.

Nous espérons que ce pas à pas vous permettra de débuter sous Rails. Pour toute question n'hésitez pas à laisser un commentaire.

Le mécanisme de session en rails

2012-10-04T00:00:00Z

Le fonctionnement d'HTTP

HTTP est un protocole sans état. Il n'inclue pas de notion d'identité de base et chaque requête est donc indépendante.

Cela signifie que le serveur ne me reconnait pas entre chaque requête.

C'est la base du fonctionnement du web, et l'opposé d'une connexion client - serveur tel que FTP.

L'avantage est que le serveur n'a pas à gérer ses clients, tout le monde est logé à la même enseigne. L'inconvénient est que l'ajout d'un mécanisme d'identification va ajouter un surplus d'information à chaque requête.

Les sessions, ou comment transformer HTTP en protocole à état

Le mécanisme de session prend place à la fois côté client et serveur. Il est activé de base sur une application Rails par le biais d'un middleware (ActionDispatch::Session::CookieStore) qui peut être désactivé au besoin.

Lorsqu'un nouvel utilisateur arrive sur l'application, si le serveur ne reçoit pas d'identifiant de session il va en créer un qu'il va transmettre dans sa réponse.

Côté client cet identifiant va être stocké dans un cookie. Les cookies ne sont pas forcément des fichiers plats. Sous chrome les cookies sont stockés dans une base SQLite et sont limités à 4ko en contenu.

Il est fortement déconseillé de placer des objets en session car cela pourrait poser des soucis d'encodage / décodage.

Par exemple on mettra un id utilisateur plutôt que l'objet utilisateur. Qui plus est, cela permet de limiter l'espace occupé par le cookie.

Les sessions avec Ruby on Rails

Ruby on rails possède plusieurs mécanismes de stockage de session. Par défaut il utilise le cookie store qui stocke tout sur le client et ne nécessite aucune configuration.

Dans ce cas l'id session n'a pas d'intérêt pour la partie serveur.

Ce paramètre peut être modifié dans config/initializers/session_store.rb

App::Application.config.session_store :cookie_store, :key => '_app_application_session'

Les autres mécanismes de stockage sont la base de données et le cache. Dans ces cas l'id session va permettre au serveur de retrouver les données associées en base ou en cache.

L'avantage de ces mécanismes est de pouvoir stocker plus de données voir d'améliorer les performances dans le cas du cache.

Attention toutefois, si votre serveur de cache vient à tomber vous n'avez plus d'utilisateur connectés. D'autre part ces mécanismes impliquent une purge côté applicatif si vous ne voulez pas stocker des miliers de sessions fantômes.

Dernier point, vous aurez besoin de partager ces sessions entre serveurs si vous mettez en place du load balancing sur votre application.

Le contenu des cookies

Le contenu des cookies est encodé avec le secret de l'application rails, qui peut être surchargé dans votre initializer avec l'option secret_token.

Voici un exemple de contenu de cookie:

BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWNhZTFlMjY0YWRlZTc2NjNhZDc4YzY4YzkwMzk3NWVlBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMXBEZlQrdkVXZndjdGpQd1JSNTRQUjhYWlp6WHFldUlZYURZZklkYmh4UVE9BjsARkkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjsAVFsISSIJVXNlcgY7AEZbBmkE8NcBLUkiIiQyYSQxMCRMUXNTdU9rbk4wSVIySUZORHFESVcuBjsAVA==--f58cf55b4d11b47c398103643b0ffe7ffdbff309

Le cookie présente 2 parties, séparées par --, d'un côté le contenu et de l'autre côté la signature. Séparons les:

  content = "BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWNhZTFlMjY0YWRlZTc2NjNhZDc4YzY4YzkwMzk3NWVlBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMXBEZlQrdkVXZndjdGpQd1JSNTRQUjhYWlp6WHFldUlZYURZZklkYmh4UVE9BjsARkkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjsAVFsISSIJVXNlcgY7AEZbBmkE8NcBLUkiIiQyYSQxMCRMUXNTdU9rbk4wSVIySUZORHFESVcuBjsAVA=="
  signature = "f58cf55b4d11b47c398103643b0ffe7ffdbff309"

À la réception du cookie, rails va vérifier que le contenu et la signature correspondent. Pour cela il va utiliser son secret token. Note: vous ne devez jamais divulguer ce token où vos sessions seront usurpables.

Voyons quel est le secret de notre app de démo:

secret = Rails.application.config.secret_token
"0b22c3a50d0ba81e396b880268d8d13c5980896a3761a24bc87e704f3589f9d0ef2528ef7480101e0edeccc5320f6310d54fd06ad7df574ee6e8e349ba01ace2"

Voilà ce que fait rails pour générer la signature:

OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, secret, str)
"f58cf55b4d11b47c398103643b0ffe7ffdbff309"

Effectivement, on retombe bien sur notre signature.

Par le biais de ce mécanisme, modifier le contenu du cookie ne permet pas d'usurper une session car la signature ne sera plus valable et notre framework s'en rendra compte.

Attention, si les cookies sont signés leur contenu n'est toutefois pas encrypté.

Il est tout à fait possible d'extraire le contenu d'un cookie.

session = Marshal.load(Base64.decode64(CGI.unescape(content)))
{
              "session_id" => "cae1e264adee7663ad78c68c903975ee",
             "_csrf_token" => "pDfT+vEWfwctjPwRR54PR8XZZzXqeuIYaDYfIdbhxQQ=",
    "warden.user.user.key" => [
        [0] "User",
        [1] [
            [0] 755095536
        ],
        [2] "$2a$10$LQsSuOknN0IR2IFNDqDIW."
    ]
}

J'espère que cet article vous aura permi de mieux appréhender le fonctionnement des sessions, notamment dans Ruby on Rails.

ECMAScript 6

2012-08-29T00:00:00Z

ECMAScript est un langage de script standardisé. Javascript est une implémentation de ce standard.

La version actuellement en cours de discussion est ECMAScript 6, dite harmony.

Comme toute bonne spec elle évolue en fonction des usages et des besoins. ECMAScript s'inspire donc notamment de coffeescript.

Comme toute (bonne) spec elle met aussi beaucoup de temps à être standardisée. Pour ces raisons, les différents navigateurs implémentent des versions non finalisées d'ECMAScript.

Faisons un petit tour d'horizon des nouveautés d'ECMAScript 6.

Variables locales

Il est maintenant possible de définir des variables locales à un bloc (let, const), ce qui évite des conflits potentiels de variables déclarées avec var.

function a() {
  let b = "foo"
}
// b is not defined

Arguments par défaut

Les fonctions permettent maintenant de passer des arguments par défaut. Quant au chaines elles supportent l'interpolation.

function greetings(recipient = "synbioz") {
  let message = `Hello ${recipient}!`
  console.log(message)
}

Déstructuration

let [a, b, c] = [1, 2, 3, 4]
// a == 1
// b == 2
// c == 3

let [a, b, ...c] = [1, 2, 3, 4]
// a == 1
// b == 2
// c == [3, 4]

À l'image des splats en coffescript les ... permettent de récupérer le reste des arguments.

// ne stocke pas le 2
function f() { return [1, 2, 3] }
let [a, , b] = f();

// swap
[a, b] = [b, a]

Chaînes de caractères sur plusieurs lignes

Les utilisateurs d'azerty risquent de ticker devant le caractère choisi (backtick), mais ce sera une excellente raison de passer au bépo.

var str = `hello
  i'm talking
  to you.
`

Sucre syntaxique

for(x of [3, 8, 12]) // 3, 8, 12
console.log("even") if(x % 2 == 0)

Note: for of n'a pas vocation à remplacer for in.

Proxies

Les proxies offre une interface de méta-programmation. Ils permettent de définir des méthodes et autres propriétés objets à la volée.

Pour rapprocher cela de ruby il faut imaginer des choses comme Class.new, define_method, method_missing…

Les usages sont plutôt rares, je vous invite à regarder cet exemple de générateur HTML avec des appels de méthodes chainés.

Quand le proxy va recevoir un appel de méthode, c'est le get du proxy qui sera appelé avec en paramètre l'objet et le nom de la méthode.

Ici get va vérifier que le nom de la méthode fait partie des tags et agir en conséquence.

Weak maps

Les weak maps s'apparentent à un hash dont les clés sont des objets.

Les éléments auxquels on n'accède pas depuis longtemps sont automatiquement collectés par le ramasse miette.

var wm = WeakMap();

(function () {
    let o = {};
    wm.set(o, "bar");
})();

// Ici o n'existera plus en mémoire.

L'intérêt de ce système est d'éviter les fuites mémoires d'objets qui seraient dans un hash classique et qui auraient une référence circulaire (et donc ne serait jamais collectés par le ramasse miette).

Les weak map peuvent aussi permettre d'étendre un objet global dans un contexte défini, sans risque de collision.

// avant: aucune garantie que l'on n'écrase pas une valeur existante.
window.my_object["foo"] = "bar"

// après: plus de risque de collision
function() {
  let wm = new WeakMap()
  wm.set(window.my_object, { 'foo': 'bar' })
}()

Générateurs

Il s'agit de fonctions interruptibles, un exemple ici d'implémentation de fibonacci avec:

function fibonacci() {
  var i = 0, j = 1;
  while (true) {
    yield i;
    var t = i;
    i = j;
    j += t;
  }
}

var f = fibonacci();
for (var i = 0; i < 10; i++) {
  console.log(f.next());
  // 0, 1, 1, 2, 3, 5, 8, 13, 21, 34
}

Structure de données

ECMAScript 6 offre la possibilité de définir ses propres structures de données, en utilisant des données binaires.

const Point2D = new StructType({ x: uint32, y: uint32 });
const Color = new StructType({ r: uint8, g: uint8, b: uint8 });
const Pixel = new StructType({ point: Point2D, color: Color });

Color, Pixel et Point2D agissent tous les 3 comme des objets. Ils permettent de définir le cadre des futures instances.

Approche objet

ECMA 6 offre des mécanismes natifs de gestion objet, comme la définition de classe, l'héritage…

Un exemple de définition d'une classe:

class Point extends Base {
  constructor(x,y) {
    super();
    this[px] = x, this[py] = y;
    this.r = function() { return Math.sqrt(x * x + y * y); }
  }
  get x() { return this[px]; }
  get y() { return this[py]; }
}

Modules

ECMAScript 6 propose un système de module qui permettra de factoriser le code et importer les éléments définis à divers endroits.

module math {
  export function sum(x, y) {
    return x + y;
  }
  export var pi = 3.141593;
}

import {sum, pi} from math;

console.log(sum(pi, 42))

Ce système va s'avérer très pratique pour les libs telles que MooTools, jQuery ou autre.

Variable privées

À l'heure actuelle pour définir des variables privées en javascript dans une classe, voilà le code qu'on doit utiliser:

function A() {
  // private var
  var _foo = "bar";

  this.foo = function() {
    return _foo;
  };
}

Le problème de cette solution est qu'elle n'est pas efficace car la méthode d'accès (fonction this.foo) sera régénérée au runtime à chaque instance créée, alors que le traitement est toujours le même.

ECMAScript 6 introduit donc un nouveau concept pour la gestion des propriétés privées:

var key = Name.create("awesome_key")

function A() { this[key] = 42 }

A.prototype.getKey = function() { return this[key] }

Avec ce système on n'a pas de visiblité sur le nom de la propriété en elle même.

Cette présentation d'ECMAScript 6 vous donne un avant goût du potentiel à venir de javascript.

Évidemment il est impossible de prédire quand cette version sera disponible dans nos navigateurs, encore plus quand elle le sera dans tous les navigateurs ; mais cela vous donne un avant goût de ce que nous réserve javascript dans les versions à venir.

Envoyer des notifications iOS en ruby

2012-07-24T00:00:00Z

Le besoin

Par défaut Mail sur iPhone est incapable de relever automatiquement les emails dans les sous dossiers, pour les comptes de type imap.

Comme j'utilise des tris serveur avec Dovecot c'est particulièrement fastidieux de vérifier chaque sous dossier à la main en situation de mobilité.

Je me suis donc dit qu'il serait pratique d'avoir une notification pour ces emails.

Pré-requis

Tant qu'à faire je souhaitais résoudre ce problème en ruby. Heureusement pour nous Grocer est là.

Pour envoyer des notifications il va nous falloir deux choses importantes:

Un compte developer Apple, afin d'obtenir un certificat permettant de délivrer des notifications.
Le token du device sur lequel envoyer les notifications.

Ce dernier est différent de l'UDID de l'appareil. Pour le récupérer nous allons devoir créer une mini application iOS et l'installer sur l'appareil. C'est expliqué sur le dépôt de Grocer.

Il s'agit uniquement de demander à l'utilisateur l'autorisation pour envoyer des notifications et d'afficher le token dans le log.

// AppDelegate.m
  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSLog(@"Registering for remote notifications");
    [[UIApplication sharedApplication] registerForRemoteNotificationTypes:(UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound)];

    return YES;
  }

  - (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
    NSLog(@"deviceToken: %@", deviceToken);
  }

  - (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error {
    NSLog(@"Error in registration. Error: %@", error);
  }

Une fois l'application buildée et installée, il suffit de la lancer et de consulter les logs du terminal depuis la section organizer de Xcode.

Le fameux token devrait s'y retrouver.

Le nez dans le code

Le code d'envoi des notifications se trouve sur Github.

Paramétrage

Pour commencer il faut paramétrer l'application dans config/global.yml

On peut y mettre plusieurs boîtes. Par défaut j'utilise le format qu'on retrouve pour les DNS, à savoir foo@example.bar devient foo.example.bar

Une fois au moins un compte imap configuré, il reste à coller le certificat d'envoi de notifications dans le dossier certs avec le nom certificate.pem.

On peut décider de ne pas notifier l'arrivée de mail dans certaines boîtes avec skip.

Comment ça marche?

Pour éviter plusieurs notifications concernant les même emails (même s'ils n'ont pas été lus), nous allons stocker les identifiants des emails.

Pour cela nous utilisons une base de données SQLite avec une unique table où nous allons stocker le nom de la boite (sous la forme foo.example.bar.folder.subfolder) et les identifiants des messages non lus.

Le parcours des différents sous dossiers des différentes boites se fait avec net/imap.

Lorsque la différence entre ids des messages non lus (ex: 3,4,5) et ids stockés en base (ex: 1,2,3) renvoie des valeurs (4, 5) nous envoyons une notification.

À noter donc que la notification se fait par sous dossier. On peut donc potentiellement recevoir plusieurs emails à la suite.

Voilà pour une introduction à la mise en place de Grocer, qui remplit parfaitement son rôle. Pour un tour d'horizon complet des différentes options je vous invite à aller jeter un œil sur le Github.

Autrement, vos commentaires sont les bienvenus!

Création de données et validations avec Backbone.js

2012-06-19T00:00:00Z

Après notre introduction à Backbone.js, nous allons voir dans cette partie comment aller plus loin en insérant des données.

Le code de cette application Backbone est disponible sur github.

Créer un formulaire en Backbone.js

Pour commencer nous allons enrichir notre layout d'un nouveau template javascript.

<script type="text/template" id="new_category">
  <input id="category_name" name="category[name]" type="text" placeholder="Type a category…" />
  <input type="button" id="save-new-category" value="Enregistrer" />
</script>

Nous allons simplement mettre à disposition un champ et un bouton.

Côté contrôleur, rien qu'une action create classique. Nous allons simplement préparer nos messages d'erreur pour un affichage côté client.

def create
  @category = Category.new params[:category]
  if @category.save
    respond_with(@category)
  else
    render :status => 500, :json => @category.errors.full_messages.join(', ')
  end
end

Il nous reste à préparer notre vue Backbone.js.

class NewCategoryView extends Backbone.View
  tagName: 'form'
  template: _.template($('#new_category').html())
  events:
    'keypress #category_name': 'saveNewCategoryIfSubmit'
    'click #save-new-category': 'saveNewCategory'
    'focusout #category_name': 'emptyMessages'

  initialize: ->
    _.bindAll(@, 'render')
    @collection.bind 'reset', @render

  render: ->
    $(@el).html @template()
    @

  saveNewCategoryIfSubmit: (event) ->
    if event.keyCode is 13
      event.preventDefault()
      saveNewCategory()

  saveNewCategory: ->
    attributes = { category: { name: $("#category_name").val() } }
    @collection.create(attributes, { error: @showErrors })

  emptyMessages: ->
    $("#messages").empty()

  showErrors: (model, errors) ->
    @emptyMessages()
    $("#messages").html(errors.responseText)

@app.NewCategoryView = NewCategoryView

Le template sera enrobé dans un formulaire.

Dans l'absolu nous n'avons pas besoin de passer la collection à cette vue. Nous le faisons uniquement pour bénéficier de la facilité du create.

Cela s'apparente à ce qu'on pourrait faire dans le cadre d'une association en Ruby on Rails (par exemple @category.products.create).

On pourrait toutefois s'en passer en faisant une initialisation classique du model (new, save).

Gérer les évènements avec Backbone.js

Dans notre vue nous avons introduit la notion d'évènements.

La syntaxe se fait tout simplement sous forme d'un hash avec d'une part l'évènement et le sélecteur et d'autre part la fonction à appeler. L'évènement concerné sera systématiquement passé à cette fonction.

Notre premier évènement va permettre de détecter les frappes dans notre input et appeler saveNewCategoryIfSubmit en retour.

Dans cette fonction nous allons tester si c'est ou non la touche entrée qui est utilisée. Si c'est le cas, nous lançons la création de données.

Nous faisons exactement la même chose lorsque nous cliquons sur le bouton.

Créer des données avec Backbone

Dans cette partie nous allons voir comment créer des données tout en utilisant les validations de notre couche client.

La partie création de données se résume à ces deux lignes:

attributes = { category: { name: $("#category_name").val() } }
@collection.create(attributes, { error: @showErrors })

Pour récupérer nos valeurs nous utilisons simplement la méthode val() de jQuery. Le create de la collection utilise l'url que nous avons définie dans cette dernière pour poster les données.

Le deuxième argument est un hash de définition des callbacks. En cas d'erreur c'est la méthode showErrors qui sera appelée.

Ce callback va nous passer deux paramètres: l'objet et les erreurs. Comme nous avons déjà préparé nos erreurs sous forme de string il nous reste juste à les insérer dans la zone de messages, en l'ayant vidée au préalable.

Notre dernier évènement focusout va automatiquement vider la zone de message quand nous allons retirer le focus du champ.

Validations client avec Backbone.js

Les validations par la couche serveur sont indispensables. Mais dans le cadre d'une application riche, ce n'est pas du luxe d'ajouter des validations clientes afin de d'avoir un retour immédiat.

Cela augmentera le sentiment de vitesse et de confort de l'application.

Pour faire de la validation côté client, backbone.js nous mets à disposition une méthode validate, libre à nous d'implémenter son contenu.

Validate nous passe les attributs en paramètres, mais attention, uniquement les paramètres qui ont été modifiés.

Les attributs de l'objet sont eux stockés dans @attributes. Nous allons donc travailler sur un merge des deux pour passer nos validations.

Pour éviter de merger dans l'une des deux variables nous allons cloner les attributs de l'objet d'abord en utilisant les méthodes de underscore.js.

class Category extends Backbone.Model
  validate: (attributes) ->
    mergedAttributes = _.extend(_.clone(@attributes), attributes)
    if !mergedAttributes.name or mergedAttributes.name.isBlank()
      return "Name can't be blank."

Désormais le create va appeler les validations sur le modèle. Il y a très peu de choses à appeler dans notre vue, le même callback du create sera utilisé avec les mêmes paramètres.

Nous allons juste l'adapter pour utiliser soit responseText si la réponse vient du serveur, soit directement errors.

showErrors: (model, errors) =>
  content = errors.responseText || errors
  @emptyMessages()
  $("#messages").html(content)

Rechargement automatique de la liste

Pour en terminer avec cette partie une étape importante est de recharger automatiquement notre liste à l'ajout d'un item.

C'est là qu'on s'aperçoit de toute la puissance de Backbone.js. Il va nous suffire d'être à l'écoute du add sur la collection pour refaire un rendu de la liste.

initialize: ->
  _.bindAll(@, 'render')
  @collection.bind 'reset', @render
  @collection.bind 'add', @render

J'espère que cette partie vous aura aider à mieux appréhender les concepts et la manière d'utiliser Backbone.js.

Si vous souhaitez que nous allions plus loin, n'hésitez pas à nous en faire part dans les commentaires.

Full-text search with sphinx and thinking sphinx

2012-05-18T00:00:00Z

What is full-text search ?

Full text search allows you to search through content, or part of a content.

It's not designed on top of SQL, it uses an indexed DB which is much more efficient than doing some LIKE queries.

Search engine uses indexed DB. I'm not telling google is using sphinx but it's based on the same concept.

To be able to search some terms, your content must be previously indexed. Each term of each document is indexed with a position.

So the main problem of full-text search is to keep an indexed DB up-to-date. If your content changes very often then you should index it often too.

But indexing is time consuming, and it will use some resources. In addition searching should still be available during indexation.

Sphinx and Thinking Sphinx

Sphinx is open source search server. Thinking sphinx is a gem built for rails which interact greatly with it.

Sphinx must be setup to be able to use Thinking Sphinx. It's available for the 3 main OS.

Installing and configuring Thinking Sphinx

Thinking Sphinx can be installed as a gem and configured ìn config/sphinx.yml This is an example:

development:
  port: 9312
  enable_star: 1
  min_infix_len: 3
test:
  port: 9313
  enable_star: 1
  min_infix_len: 3

You can set the port for each environment or add the ability to search terms part. There is many other options, take a look at the advanced configuration guide.

The index has to be rebuilt when changing configuration file.

rake ts:rebuild

Thinking Sphinx will generate his own config file like config/development.sphinx.conf and maintain his indexed db in db/sphinx/development/

Indexing

As I said before, indexing is not done on the fly when you add new content. You should explicitly add a routine. Trying to index with model callbacks is not a good idea.

So you have to choose the better interval between two indexations.

Whenever is a great gem to automate this job. For example:

every 10.minutes do
  rake "ts:index"
end

every :reboot do
  rake "ts:start"
end

What about using sphinx with database filters ?

Imagine an e-commerce website. You've got tons of products with descriptions. Products belongs_to a category, has some pictures and a state (online or not).

product:
  title: "my great product"
  description: "my great description"
  category\_id: 1
  state: "online"

If a user browse a category and search a product, we should restrict his search to the scope of this category. We also want to be able to restrict search to product having pictures and an online state.

In fact we want to cumulate full-text search and SQL restrictions.

Thinking sphinx can interact with a SQL database like MySQL. There is attributes to do that. People often misunderstood difference between indexed fields (used with indexes) and attributes (used with has).

Fields are searchable while attributes match exact values. The state and category_id are exact values. But be careful, you should consider each attribute as an integer, even state which is a string.

So we're gonna use the CRC32 method to index string as integer and be able to search it.

define_index do
   # fields to use for term search
   indexes title, sortable: true
   indexes description

   # attributes usable as sort / filter criteria
   has category_id

   has "CRC32(state)", as: :state, type: :integer

   has "COUNT(DISTINCT pictures.id) > 0", as: :has_pictures, type: :boolean

   join pictures
 end

sphinx_scope :ts_online do
    { with: { state: "online".to_crc32 } }
  end

The ruby method to_crc32 is not part of the core nor ActiveSupport, it's a thinking sphinx's addition using Zlib.

Zlib.crc32 "ruby"
# => 3428506893

Be aware that this is not perfectly reliable as crc32 can have some collisions depending on the term.

Conclusion

And here we go, we're now able to search products with a particular category, some pictures or not and specific terms in the title and/or description.

Sphinx is an easy to setup and powerful solution to add full-text search to your web application. I really encourage you to dig into the documentation to discover all the available options.

If you don't want to use Sphinx there is other full-text search engine. solr is also very popular and has ruby gem like sunspot to interact with.

The Synbioz Team. Free to be together.

Présentation de backbone.js

2012-04-12T00:00:00Z

Présentation de Backbone.js

Backbone.js est un cadre applicatif pour les applications à forte teneur en javascript.

Backbone.js peut se définir comme un framework MVC mais pas au sens classique du terme. Ici le C représente des Collections d'objets. Le M et le V désignent respectivement les modèles et les vues.

Backbone.js ne possède qu'une dépendance ferme, il s'agit de underscore.js, qui est maintenu par la même équipe.

Le rôle d'underscore.js est de vous apporter tout un tas de méthodes pour vous simplifier la vie (enumerable, binding, template, comparaison…) sans faire 500ko.

Généralement jQuery vient compléter la liste des dépendances finales de l'application, car il y a fort à parier que vous aurez à minima besoin de manipuler le DOM.

Quand utiliser Backbone.js

Backbone.js est un excellent choix pour les applications dites «single page application», c'est à dire une page principale avec un nombre important d'interactions utilisateur.

Plutôt que d'avoir une navigation classique par page (ou le serveur envoie toute la page à chaque URL), la navigation, l'envoi de formulaire et toutes les actions classiques se gèrent en javascript.

Avant, quand on souhaitait faire ce genre de choses, on écrivait son propre javascript, sans aucune convention, ầ grand coup d'AJAX et on se retrouvait vite avec du spaghetti code, complexe à maintenir et à tester.

Backbone.js nous permet de cadrer cela en définissant modèle, vue et collections. On va pouvoir définir des événements sur des changements de valeurs de nos modèles et ainsi rafraichir automatiquement nos vues.

Pour cela Backbone.js possède son propre routeur. On peut faire correspondre des actions à des URL.

Le code créé avec Backbone.js peut être testé via jasmine.

Ce que Backbone.js ne fait pas

Backbone.js est uniquement une couche client, il n'a aucune vocation à gérer la persistence de vos données sur un serveur.

Mais rassurez vous cela se fait très bien, il suffit d'indiquer à nos modèles une URL et d'avoir une API JSON Restful pour être capable de réaliser du CRUD très simplement.

Apprentissage par la pratique

L'objectif de cette première partie est de créer une application qui va lister les catégories récupérées depuis le serveur.

L'application backbone.js est disponible sur github.

Le tag 0.1 correspond à cette partie.

Aperçu rapide de la partie serveur

Pour la persistence des données nous utilisons une application Ruby on Rails qui agit uniquement comme une API.

Nous avons une migration pour créer des catégories qui ont un nom, ainsi que quelques seeds. Une fois l'application clonée il vous reste à configurer votre base de données (database.yml) et lancer le chargement:

bin/rake db:setup

Notre contrôleur categories renvoie uniquement du JSON.

class CategoriesController < ApplicationController
  respond_to :json

  def index
    @categories = Category.all
    respond_with(@categories)
  end
end

On va donc pouvoir récupérer nos catégories sur /categories.json

La partie client avec Backbone.js et coffeescript

Pour son côté pratique et maintenant par habitude, le code est en coffeescript. Jetez un œil à notre introduction à coffeescript si vous ne connaissez pas encore. Vous ne serez pas trop dépaysés.

Le fichier principal est app.coffee, il est généré dans app.js Si vous souhaitez faire des changements en local pour tester, vous pouvez utiliser le Guardfile fournit via:

bin/guard

Il s'occupera de compiler votre coffeescript à la volée.

Explication du code Backbone.js

Logiquement notre application devrait être découplée en plusieurs fichiers, en séparant modèle, vue etc…

Ici la simplicité de l'application fait que tout est en un seul fichier. Commençons à décortiquer le code.

@app = window.app ? {}

Afin que les fichiers javascript puissent avoir connaissance les uns des autres on utilise l'objet global windows et le namespace app.

_.templateSettings = {
    interpolate: /\{\{\=(.+?)\}\}/g,
    evaluate: /\{\{(.+?)\}\}/g
};

Underscore.js possède un système de template, dont la syntaxe par défaut est la même que celle des templates ERB.

Nous changeons cela pour qu'ERB n'essaie pas de les interpréter, ce sera le rôle de Backbone.js.

Pour cela nous modifions les paramètres du template pour avoir une syntaxe proche de celle de mustache.

On va donc passer de <% %> à {{ }}.

Définition du modèle

class Category extends Backbone.Model

Notre catégorie va simplement étendre le modèle de base de Backbone.js pour hériter de toutes ces méthodes (save…).

Ici on utilise directement le mécanisme de coffeescript. Par convention le modèle est au singulier.

En javascript on aurait plutôt:

var Category = Backbone.Model.extend({})

Une fois notre classe créée nous la mettons dans le namespace. Nous le ferons systématiquement pour les autres classes, quelque soit leur fonction.

Définition de la collection

class Categories extends Backbone.Collection
    url: "/categories"
    model: app.Category
  @app.Categories = Categories

La collection se trouve à mi chemin entre la vue et le modèle. Elle concerne un modèle dont elle contiendra une liste, dont le but sera d'aller peupler une vue.

Par convention la collection est au pluriel.

Partant de là nous sommes déjà en mesure de récupérer les données de l'API. Vous pouvez tester depuis la console de votre navigateur:

categories = new window.app.Categories()
  categories.fetch()
  categories.models
  # [Category, Category]

Définition des vues

Regardons comment définir un template dans nos vues HTML.

<script type="text/template" id="category">
    {{= name }}
  </script>

Les templates sont définis dans le head de notre HTML, de base le navigateur n'interprétera rien. Comme mentionné plus tôt nous utilisons la syntaxe de mustache.

Le but pour ces templates est d'être remplacé par le HTML correspondant à ce qu'on souhaite afficher par Backbone.js.

Par exemple #category représentera un élément LI contenant le nom de la catégorie.

Voyons comment est définie notre classe du côté de Backbone.js:

class CategoryView extends Backbone.View
  tagName: 'li'
  template: _.template($('#category').html())

  initialize: ->
    _.bindAll(@, 'render')

  render: ->
    @.$el.html @template(@model.toJSON())
    @
@app.CategoryView = CategoryView

Nous spécifions donc le tagName qui servira à l'enrobage HTML. Il existe d'autres options comme la classe CSS…

Ensuite nous indiquons quel est le template à utiliser (#category). C'est cette définition qui justifie l'enrobage $(document).ready, afin que le DOM soit prêt pour l'initialisation des templates.

Autrement on peut toujours les initialiser dans le constructeur de la vue mais cela impliquera un calcul à chaque instanciation d'objet, donc ce n'est pas recommandé.

Dans le constructeur nous allons nous assurer que le rendu de la vue se fera toujours dans le contexte de cet objet (this).

En effet le render pourra être appelé depuis d'autres endroits, notamment le modèle.

Dans ce cas nous voulons nous assurer que le this courant s'apparentera toujours à cette vue. Nous utilisons pour cela bindAll.

Enfin la méthode render va se servir du modèle que nous lui aurons passé pour générer notre LI.

Plutôt que d'appeler $(@el) on utilise @.$el qui permet d'éviter d'accéder à chaque fois au DOM en stockant une référence à l'élément.

Render doit toujours retourner this afin de pouvoir chainer les appels.

Un petit test en console:

// creation de la categorie
  var category = new window.app.Category({ name: "Synbioz" })
  // creation de la vue
  var view = new window.app.CategoryView({ model: category })

  var content = view.render()
  content.el
  // <li>Synbioz</li>

Regardons maintenant la vue qui listera l'ensemble des catégories:

class CategoriesView extends Backbone.View
  tagName: 'ul'
  template: _.template($('#categories').html())

  initialize: ->
    _.bindAll(@, 'render')
    @collection.bind 'reset', @render

  render: ->
    @.$el.html(@template())
    node = @.$('.categories')
    collection = @collection
    @collection.each (category) ->
      view = new CategoryView
        model: category
        collection: collection
      node.append view.render().el
    @

Avec le binding du reset sur la collection nous introduisons toute la puissance de Backbone.js. Ce code va permettre de surveiller la collection, et de faire automatiquement un render de la vue associée.

Dans la méthode render nous allons utiliser la vue précédente pour générer chaque catégorie et l'ajouter à la liste.

Plutôt que de rechercher .categories dans tout le DOM nous limitons la portée au template, ce qui est nettement plus efficace.

Définition du routeur

Le routeur va nous permettre de définir les routes de notre application. Il définit les routes en GET en faisant matcher l'URL courante sur une action.

class MetricsRouter extends Backbone.Router
  routes:
    '': 'dashboard'

  initialize: ->
    window.categories = new app.Categories()
    @categoriesView = new app.CategoriesView
      collection: categories

  dashboard: ->
    window.categories.fetch()
    $("#container").html(@categoriesView.el);

@app.MetricsRouter = new MetricsRouter()

Dès que nous serons sur la home, la méthode dashboard sera appelée. Dans celle ci on récupère les catégories, ce qui exécute directement un rendering de la vue associée.

Il ne reste qu'à l'ajouter dans le DOM.

Lancement de l'application

Maintenant que tout est en place, lançons l'application:

Backbone.history.start()

Nous n'avons pas encore de navigation mais cela n'en demeure pas moins indispensable.

Par défaut les URL sont gérées comme celles de twitter, avec un #. Mais il existe une option (pushState) qui permet d'utiliser les possibilités d'HTML5 pour mettre à jour l'historique en javascript.

Ainsi pour votre navigateur c'est complètement transparent, la navigation s'apparente à une navigation classique.

Conclusion

Le rapport puissance / taille du code du Backbone.js est assez impressionnant. Il permet de créer des applications plus fluides et réactives en limitant les aller / retour avec le serveur.

Ce cadre applicatif permet d'avoir du code bien organisé, qui plus est testable avec jasmine.

Dans la prochaine partie nous allons gérer toute la partie événementielle et formulaire afin de pouvoir interagir avec la page et naviguer comme dans une application classique.

Le méconnu inverse_of

2012-01-27T00:00:00Z

Rails: le méconnu inverse_of

Active record: le patron de conception

Active record, avant d'être le nom d'une célèbre gem inclue dans rails est le nom d'un design pattern, permettant de faire du mapping objet - relationnel.

C'est à dire qu'il vous permet de manipuler sous forme d'objets vos données stockées dans une base de données.

Optimiser la communication entre les objets et la base de donnée

La gem ActiveRecord vous offre un maximum de confort en mettant à disposition toutes les méthodes pour gérer les opérations basiques de CRUD mais aussi les associations entre tables.

Imaginons deux class product et category:

class Category < ActiveRecord::Base
    has_many :products
  end

class Product < ActiveRecord::Base
    belongs_to :category
  end

Regardons quels sont les appels effectués à la base lorsque nous parcourons les objets:

irb(main):008:0> c2 = Category.first(:include => :products)
    Category Load (0.1ms)  SELECT "categories".* FROM "categories" LIMIT 1
    Product Load (0.2ms)  SELECT "products".* FROM "products" WHERE "products"."category_id" IN (1)
  => #<Category id: 1, name: "Téléphone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">
  irb(main):009:0> c3 = c2.products.first.category
    Category Load (0.2ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = 1 LIMIT 1
  => #<Category id: 1, name: "Téléphone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">
  irb(main):010:0> c3.object_id == c2.object_id
  => false

ActiveRecord n'est pas suffisamment malin pour comprendre que nous sommes en fait sur la même catégorie quand nous demandons la catégorie d'un produit qui fait parti de la liste des produits de cette même catégorie.

Le rôle d'inverse_of

Redéfinissons nos relations pour utiliser inverse_of:

class Category < ActiveRecord::Base
    has_many :products, :inverse_of => :category
  end

class Product < ActiveRecord::Base
    belongs_to :category, :inverse_of => :products
  end

  irb(main):004:0> c2 = Category.first(:include => :products)
    Category Load (0.2ms)  SELECT "categories".* FROM "categories" LIMIT 1
    Product Load (0.2ms)  SELECT "products".* FROM "products" WHERE "products"."category_id" IN (1)
  => #
  irb(main):005:0> c3 = c2.products.first.category
  => #
  irb(main):006:0> c3.object_id == c2.object_id
  => true

En explicitant la relation inverse ActiveRecord sait maintenant retrouver ses petits et éviter d'inutiles requêtes SQL.

Les formulaires imbriqués

Imaginons que vous souhaitiez pouvoir créer directement une catégorie avec un ou plusieurs produits et que vous produits doivent obligatoirement avoir une catégorie.

class Category < ActiveRecord::Base
    has_many :products, :inverse_of => :category

    accepts_nested_attributes_for :products
  end

class Product < ActiveRecord::Base
    belongs_to :category, :inverse_of => :products

    validates_presence_of :category
  end

Sans inverse_of vous risquez d'avoir des soucis à cause de la validation. En effet, le produit ayant une validation sur sa catégorie, il va chercher à la charger.

Sans inverse_of il essayera de la charger depuis la base de donnée, alors qu'elle n'existe pas encore. Avec, il sera capable de récupérer directement l'objet.

Identity map

Très franchement ActiveRecord nous a habitué à un peu plus de magie et d'automatisme pour que l'on n'ait pas envie de définir manuellement tous ses inverse_of.

D'autant plus qu'il semble assez simple de retrouver les associations concordantes et que cette fonctionnalité est présente dans datamapper.

C'est en fait le rôle de la fonction d'identity map introduite par rails 3.1 mais désactivée par défaut.

L'objectif est de n'avoir jamais à recharger un objet depuis la base quand il est déjà en mémoire.

L'activation de la fonctionnalité se fait dans application.rb

config.active_record.identity_map = true

irb(main):005:0> ActiveRecord::IdentityMap.use { c = Category.find(1) ; c2 = Category.find(1) }
    Category Load (57.9ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = ? LIMIT 1  [["id", 1]]
    Category Loaded  From Identity Map (id: 1)
  => #<Category id: 1, name: "Téléphone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">

L'utilisation se fait dans un bloc et l'usage est encore limité. Par exemple utiliser Category.first, même dans le bloc entrainera tout de même 2 requêtes.

De plus l'activation de la fonction ne permet pas pour le moment de remplacer le inverse_of.

C'est pourtant une fonctionnalité très importante car elle permettra de fortement limiter le nombre d'instanciation d'objets.

Pour autant elle n'est pas simple à mettre en place en conservant un comportement tread-safe : on imagine bien deux morceaux de code entrain de mettre à jour le même objet en mémoire.

En résumé, utilisez le inverse_of dès aujourd'hui si ce n'est pas encore le cas car Rails n'est pas prêt de le faire automatiquement pour vous.

Jouons un peu avec les websockets

2011-12-20T00:00:00Z

Jouons un peu avec les websockets

Dans notre présentation d'html5, nous avons brièvement évoqué les websockets.

Les websockets sont un protocole de communication bi-directionnel, standardisé par le w3c et qui est progressivement implémenté par les navigateurs.

La promesse des websockets est d'offrir un mécanisme client / serveur dans votre navigateur. À l'heure actuelle le principal mécanisme existant est HTTP, qui est un protocole sans état.

Concrètement il n'a pas de possibilité de réutilisation de la connexion. Une fois que le serveur a répondu, votre navigateur affiche la réponse mais le serveur n'a pas la possibilité de dire «oups j'ai oublié de te dire quelquechose».

Qui plus est la réponse est enrobée d'un tas de données complémentaires (headers…). Ce n'est pas le cas pour les websockets.

Utiliser les websockets

La question qui brûle les lèvres est «peut on l'utiliser là tout de suite ?»

Oui, d'ailleurs nous le faisons. Coté navigateur, utiliser les websockets directement comporte les même soucis que faire du js pur, c'est à dire qu'il y a un certain nombre d'implémentations.

D'autre part la fonctionnalité a été désactivé dans Firefox 4 et 5 (puis réactivée), suite à la découverte d'une faille de sécurité.

Opera 11 l'a aussi désactivé pour cette raison tandis qu'Internet Explorer ne la supporte pas encore.

Une nouvelle version corrige cette faille du protocole. Elle est implémentée par Firefox 6+ et Chrome 14+.

Pourquoi l'utiliser si ce n'est pas encore supporté partout ?

Comme pour HTML5 ou CSS3, la prise en charge va aller croissante, et tous les navigateurs vont être amenés à l'implémenter (même IE 10).

Et puis il existe aussi des outils capables de mettre en œuvre des mécanismes de substitutions quand la fonctionnalité n'est pas présente ou activée.

socket.io

socket.io est un outil fantastique, capable d'utiliser plusieurs fallback si les websockets ne sont pas disponibles:

socket flash
ajax
iframe
jsonp

Cela vous ouvre la porte à tous les navigateurs, même mobiles.

L'utilisation est vraiment simple, on démarre une écoute côté serveur, on récupère côté client le fichier socket.io.js livré par le serveur (grâce à une balise script), et les deux parties sont prêtes à discuter.

socket.io vous permet de faire facilement du broadcast ou de la gestion de channel. Quant à la déconnexion, elle est prévue de base par le protocole.

Sécurité

On l'a vu plus tôt la spécification évolue pour prendre en compte la sécurité.

Et comme http a https, ws a son pendant wss qui permet d'ouvrir une connexion sécurisée.

En route vers le temps réel

Les websockets ne sont pas comparables à AJAX, elles permettent l'ouverture d'un canal de communication entre le client et le serveur. Du coup le serveur peut devenir une passerelle entre clients, par exemple pour réaliser un tchat.

De même les weksockets peuvent permettre de communiquer entre serveurs, ce n'est pas une technologie utilisable uniquement par les navigateurs.

De nombreuses implémentations existent dans différents langages, que ce soit PHP, Java ou encore ruby et javascript (node.js).

Il existe même un framework bâti avec ruby, cramp

Démo

Plutôt que de vous ennuyer avec un tchat j'ai écrit un puissance 4, afin que 2 joueurs puissent s'affronter.

Le code est disponible sur github.

Puissance 4 from synbioz on Vimeo.

L'essentiel du code est dans src, et il n'est pas énorme, environ 160 LOC de coffee pour le serveur et une 100aine pour le client.

À propos du code

La présence d'un Gemfile est simplement liée au fait que j'utilise un guardfile pour compiler mon coffeescript en javascript.

La couche serveur est gérée en node.js, la page web est statique.

Pour faire tourner le jeu vous avez uniquement besoin de node, npm et du module socket.io

Le jeu est en fait représenté par une classe game. Le client n'a pas de référence sur le jeu, toute la logique du jeu est gérée par le serveur.

Le serveur est en attente de connexion. Une fois qu'un client se connecte il vérifie qu'un jeu est disponible et le signifie au client si c'est le cas en lui indiquant s'il est le joueur 1 ou 2.

Si aucun jeu n'est démarré et que la limite (2 actuellement) n'est pas atteinte, un jeu est créé et la matrice initialisée.

Une fois que les 2 utilisateurs sont enregistrés on envoie aux 2 joueurs un message indiquant que le jeu démarre.

Le premier inscrit commence. À chaque coup joué on vérifie s'il est gagnant ou non, plutôt que de parcourir la grille entière, et on change de joueur.

Si le coup est gagnant on notifie le gagnant et le perdant, et on réactive le bouton permettant de lancer un jeu tout en supprimant la référence sur le serveur.

Le jeu est simplement un exemple de la puissance des websockets. Il ne vise pas à implémenter complètement la logique du jeu, mais si l'envie vous en prend n'hésitez à proposer une pull request.

Déployer et héberger une application Ruby on Rails avec Capistrano Unicorn et Nginx

2011-11-15T00:00:00Z

Déployer et héberger une application Ruby on Rails avec Capistrano, Unicorn et Nginx

Mettre en place Capistrano en multistage

Capistrano est un outil écrit en Ruby qui permet de faciliter les déploiements d'application. Il n'est pas obligatoire que l'application soit une application Rails, cela fonctionne aussi avec des applications sinatra et même des applications non Ruby (Node.js…)

L'objectif du multistaging est de pouvoir déployer différement selon les environnements (staging, production…)

Pour commencer nous allons ajouter les gems nécessaires à notre projet:

gem 'capistrano'
gem 'capistrano-ext'

Une fois les gems enregistrés nous allons les installer et mettre en place Capistrano :

$ bundle install --binstubs
$ bin/capify .
$ mkdir config/deploy
$ cp config/environments/production.rb config/environments/staging.rb
$ cap staging deploy:setup

Le binstubs permet de freezer les bins, c'est une bonne pratique. Cela permet de lancer des commandes comme bin/rake plutôt que bundle exec rake.

Le capify va créer le fichier config/deploy.rb que nous allons éditer par la suite.

La création du dossier config/deploy va permettre de mettre en place une configuration de déploiement propre à chaque environnement (ex: config/deploy/production.rb).

Toutefois l'essentiel de la configuration se fera dans config/deploy.rb car elle varie peu d'un environnement à l'autre.

require "bundler/capistrano"

# allowing shell interactions
default_run_options[:pty] = true

# multistaging
set :stages, %w(staging production)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

set :application, "fake"
set :user, "synbioz"
set :repository,  "ssh://user@server/git/#{application}.git"
set :ssh_options, { :forward_agent => true }
set :deploy_to, "/var/www/#{application}"

set :scm, :git
set :deploy_via, :remote_cache

# number of releases we want to keep
set :keep_releases, 3

set :use_sudo, false
# default rails_env, should be overrided in config/deploy/#{environnement}.rb
set :rails_env, "staging"

# Unicorn informations
set :unicorn_config, "#{current_path}/config/unicorn.rb"
set :unicorn_pid, "#{shared_path}/pids/unicorn.pid"
set :unicorn_bin, "#{current_path}/bin/unicorn"

# useful for rbenv
set :default_environment, {
  'PATH' => "/home/synbioz/.rbenv/shims:/home/synbioz/.rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
}

namespace :maintenance do
  task :start do
    run "ln -nfs #{shared_path}/system/_maintenance.html #{shared_path}/system/maintenance.html"
  end

  task :stop do
    run "rm -f #{shared_path}/system/maintenance.html"
  end
end

namespace :deploy do
  task :start, :roles => :app, :except => { :no_release => true } do
    run <<-CMD
      cd #{current_path} && #{unicorn_bin} -c #{unicorn_config} -E #{rails_env} -D
    CMD
  end

  task :force_stop, :roles => :app, :except => { :no_release => true } do
    run <<-CMD
      if [ -e #{unicorn_pid} ]; then
        kill -9 $(cat #{unicorn_pid});
      fi
    CMD
  end

  task :stop, :roles => :app, :except => { :no_release => true } do
    run <<-CMD
      if [ -e #{unicorn_pid} ]; then
        kill $(cat #{unicorn_pid});
      fi
    CMD
  end

  task :graceful_stop, :roles => :app, :except => { :no_release => true } do
    run <<-CMD
      if [ -e #{unicorn_pid} ]; then
        kill -s QUIT $(cat #{unicorn_pid});
      fi
    CMD
  end

  task :reload, :roles => :app, :except => { :no_release => true } do
    run <<-CMD
      if [ -e #{unicorn_pid} ]; then
        kill -s USR2 $(cat #{unicorn_pid});
      fi
    CMD
  end

  task :restart, :roles => :app, :except => { :no_release => true } do
    run <<-CMD
      if [ -e #{unicorn_pid} ]; then
        kill -9 $(cat #{unicorn_pid});
        sleep 5;
        cd #{current_path} && #{unicorn_bin} -c #{unicorn_config} -E #{rails_env} -D;
      fi
    CMD
  end
end

desc "Create shared folders."
after 'deploy:setup', :roles => :app do
  # for unicorn
  run "mkdir -p #{shared_path}/sockets"
  run "mkdir -p #{shared_path}/config"
  # only for sqlite
  run "mkdir -p #{shared_path}/db"
end

desc "Link db.yml."
after 'deploy:update_code', :roles => :app do
  run "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"
end

desc "Seed datas when cold deploying."
after 'deploy:migrate', :roles => :app, :only => { :no_release => true } do
  run "cd #{release_path} && bin/rake db:seed RAILS_ENV=#{rails_env}"
end

desc "Link maintenance, rbenv and precompile assets."
after 'deploy:symlink', :roles => [:web, :app] do
  run "ln -nfs #{shared_path}/config/.rbenv-version #{release_path}/config/.rbenv-version"
  run "cp #{release_path}/public/_maintenance.html #{shared_path}/system/"
  run "cd #{release_path}; RAILS_ENV=#{rails_env} bin/rake assets:precompile"
end

desc "remove unused releases."
after "deploy", "deploy:cleanup"

Le lancement de deploy:setup va créer les dossiers nécessaires sur le serveur.

Une fois réalisé, il faudra mettre en place une fois pour toute les fichiers de configuration nécessaires sur le serveur, à savoir shared/config/database.yml et shared/config/.rbenv-version

Ceux ci seront liés dans chaque release.

Nous pouvons maintenant lancer le premier déploiement (cold):

$ cap staging deploy:cold

Certaines tâches ne s'effectuent qu'au deploy:cold, dans notre exemple le db:seed. Pour cela nous avons utilisé le paramètre :only => { :no_release => true }.

A l'issu du deploy:cold si tout s'est bien passé la tâche start sera lancée et Unicorn démarré.

Pour les prochains déploiements il suffira de déployer via:

$ cap staging deploy

Configurer Unicorn

La force d'Unicorn est d'avoir un processus master qui s'occupe de charger l'application et de démarrer des workers qui pourront traiter les requêtes.

Chaque worker n'a donc pas à charger l'application Rails, ce qui entraine un important gain de temps. Si un worker plante, le master s'occupera de le relancer.

De plus Unicorn offre la promesse d'une application 0 downtime. En effet l'envoi d'un signal USR2 au master lui indique de recharger l'application Rails (voir tâche reload dans deploy.rb).

A noter toutefois que cette technique n'est pas fiable à 100%. Il m'est arrivé que l'application ne soit pas rechargée. J'ai donc ajouté une tâche restart qui s'assurer d'arrêter puis démarrer l'application.

La configuration d'Unicorn se fait dans config/unicorn.rb Si la configuration d'Unicorn est différente entre le staging et la production on pourrait utiliser un sous dossier comme pour Capistrano.

# unicorn_rails -c config/unicorn.rb -E production -D
worker_processes 4

user "synbioz", "users"
working_directory "/var/www/fake/current"

listen "/var/www/fake/shared/sockets/unicorn.sock", :backlog => 1024
pid "/var/www/fake/shared/pids/unicorn.pid"

# nuke workers after 30 seconds instead of 60 seconds (the default)
timeout 30

stderr_path "/var/www/fake/shared/log/unicorn.stderr.log"
stdout_path "/var/www/fake/shared/log/unicorn.stdout.log"

# combine REE with "preload_app true" for memory savings
# http://rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

before_fork do |server, worker|
  defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect!

  old_pid = "#{server.config[:pid]}.oldbin"

  if File.exists?(old_pid) && server.pid != old_pid
    begin
      sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(sig, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
    end
  end

end

after_fork do |server, worker|
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

Configurer Nginx

La configuration de notre vhost sous Nginx est très simple:

server {
  listen 80;
  server_name fake.server;

  access_log /var/log/nginx/fake.access.log;
  error_log /var/log/nginx/fake.error.log;

  # direct to maintenance if this file exists
  if (-f $document_root/system/maintenance.html) {
    rewrite  ^(.*)$  /system/maintenance.html last;
    break;
  }

  location / {
    root /www/fake/current/public;

    proxy_redirect          http://fake/               /;
    proxy_set_header        Host                                                            $host;
    proxy_set_header        X-Real-IP                                                     $remote_addr;
    proxy_set_header  X-Forwarded-For                                               $proxy_add_x_forwarded_for;

    # If the file exists as a static file serve it directly
    if (-f $request_filename) {
      break;
    }

    if (!-f $request_filename) {
      proxy_pass http://fake;
      break;
    }
  }

  error_page   500 502 503 504  /500.html;
  location = /500.html {
    root   /www/fake/current/public;
  }
}

Dans le fichier nginx.conf il suffit de référencer la socket Unicorn :

upstream fake {
  server unix:/www/fake/shared/sockets/unicorn.sock;
}

La seule subtilité vient du rewrite en cas de présence du fichier de maintenance. Cela permet de mettre en place une page qui interceptera toutes les requêtes.

Cette page peut être mise en place très simplement avec notre commande Capistrano :

$ cap staging maintenance:start

En espérant que cet article facilite vos déploiements à venir.

Tester une propriété CSS via javascript

2011-11-02T00:00:00Z

L'approche classique

Dans une logique d'amélioration progressive, il est important de savoir ce que l'on peut faire ou ne pas faire en CSS avec le navigateur de l'internaute.

Par exemple si l'on souhaite vérifier que le navigateur supporte l'opacité:

if('opacity' in document.body.style) {
  // C'est parti…
}

L'approche media queries

Les media queries permettent d'adapter ses feuilles de style selon le media ciblé et ses capacités.

Cette approche est utilisée dans la partie réalisations du site de Synbioz. Si nous sommes en présence d'un navigateur supportant -webkit-transform-3d, on peut mettre en place l'effet cube.

Ici impossible d'utiliser l'approche classique car javascript connait webkitTransform mais pas webkitTransform3D.

Afin de savoir dans mon code javascript si cette propriété est supportée nous avons donc utilisé la puissance des media queries, avec un morceau de code très léger:

#cube {
  height: 100px;
}

@media (-webkit-transform-3d) {
  height: 200px;
}

Au niveau du javascript il reste à tester la hauteur de l'élément en question. Généralement on utilisera un seul élément caché dans le DOM pour tester toutes les propriétés dont on a besoin.

var cube = document.getElementById("cube");
if(200 == cube.offsetHeight) {
  // propriété supportée
}

Cet article évoque brièvement les media queries dans un usage un peu détourné mais cette nouveauté de CSS3 mériterait un article à elle seule, tant elle peut se révéler pratique.

Proposer une liste de valeurs avec l'i18n de rails

2011-10-19T00:00:00Z

Proposer plusieurs options dans un select avec l'i18n

Bien souvent dans une application vous avez besoin de proposer une liste de valeurs plus ou moins fixes parmi lesquelles l'utilisateur doit faire un choix, par exemple pour choisir sa civilité.

Plutôt que d'utiliser une constante pour stocker un hash clé / valeur des options, ou maintenir un système autre, j'utilise l'i18n de rails.

Cela offre une solution très souple, voyez plutôt:

# fr.yml
gender:
  miss: "Mademoiselle"
  mrs: "Madame"
  mr: "Monsieur"

# code avec formtastic
f.input :gender, :as => :select, :collection => I18n.t("gender").map(&:reverse)

J'ai parlé d'utiliser des valeurs fixes mais vous pouvez très bien ajouter progressivement des valeurs dans votre fichier d'i18n qui seront automatiquement disponibles dans vos vues.

C'est bien entendu encore plus avantageux quand vous travaillez sur une application multilingue.

Intégrer les réseaux sociaux dans son application ruby on rails avec OAuth

2011-10-18T00:00:00Z

Intégrer les réseaux sociaux dans son application ruby on rails avec omniauth

Dans mon introduction à OAuth, je vous avez laissé sur votre faim côté implémentation car ce n'était pas l'objet du billet.

J'avais juste brièvement évoqué omniauth comme l'outil indispensable.

Voyons donc aujourd'hui comment réellement intégrer cette solution avec devise.

Créer des applications sur les plateformes ciblées

Qu'elle que soit la plateforme en question (google, twitter, viadeo, facebook, linkedin…) vous aurez besoin de créer une application sur la plateforme cible. Par exemple sur twitter: https://dev.twitter.com/apps/new

Ce qui nous intéresse c'est de récupérer les clés qui nous permettront d'interagir avec l'application, à savoir le consumer key et le consumer secret.

Configurer notre application rails

En premier lieu, commençons par le plus simple, à savoir installer omniauth. Il suffit de l'ajouter dans le Gemfile.

gem 'omniauth'

Pour utiliser openid (pour s'authentifier via google par exemple), nous aurons besoin des gems suivantes:

gem 'oa-core'
gem 'oa-openid', :require => 'omniauth/openid'

Configurer devise

Omniauth s'intègre très bien avec devise, il suffit de configurer votre initializer devise.rb. Il est de bon ton d'avoir des applications pour votre environnement de dev et d'autres pour votre production.

if Rails.env.development?
  config.omniauth :twitter, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  config.omniauth :facebook, 'CONSUMER_KEY', 'CONSUMER_SECRET', :scope => 'email'
  config.omniauth :linked_in, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  config.omniauth :viadeo, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  config.omniauth :google_apps, OpenID::Store::Filesystem.new('/tmp'), :domain => 'gmail.com'
else
  config.omniauth :twitter, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  config.omniauth :facebook, 'CONSUMER_KEY', 'CONSUMER_SECRET', :scope => 'email'
  config.omniauth :linked_in, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  config.omniauth :viadeo, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  config.omniauth :google_apps, OpenID::Store::Filesystem.new('/tmp'), :domain => 'gmail.com'
end

Configurer notre modèle

Dans le modèle qui gère vos utilisateurs il faut rajouter omniauthable:

# user.rb
devise :omniauthable

Configurer nos routes et notre contrôleur

Nous allons indiquer à devise quel contrôleur utiliser lors de la réception des callbacks des différentes applications…

devise_for :users, :controllers => { :omniauth_callbacks => "users/omniauth_callbacks" }

…et créer le contrôleur correspondant:

rails g controller users/omniauth_callbacks

Notre contrôleur doit hériter de Devise::OmniauthCallbacksController et implémenter une action par service supporté.

class Users::OmniauthCallbacksController < Devise::OmniauthCallbacksController
  def linked_in
    # some stuff
  end

  def twitter
  end
end

Dès lors que vous avez configuré un service, le formulaire de login de devise vous offre immédiatement un lien pour se connecter avec ce service.

Quand vous suivrez ce lien depuis votre application, la plateforme cible (ex: twitter) vous demandera d'autoriser explicitement l'utilisation de vos informations.

Si vous acceptez vous serez redirigé vers l'application que vous développez. A la redirection un hash (env["omniauth.auth"]) est transmis. C'est là que vous trouverez toutes les informations de l'utilisateur selon la plateforme (email, nom, prénom…)

Gestion des autorisations

Beaucoup d'applications prennent la liberté de créer des comptes utilisateurs à la volée au retour de ces informations, en générant un mot de passe, voire un email, aléatoire.

Je pense personnellement que c'est une mauvaise idée. En faisant cela l'utilisateur ne comprendra pas qu'il vient de créer un compte sur votre application, donc il risque fort de créer 1 compte par plateforme utilisée.

De votre côté vous allez vous retrouver avec des données inconsistantes.

Créer un modèle authorization

Nous allons créer un modèle authorization qui permettra de stocker les informations propres à chaque service permettant de s'authentifier.

Cette autorisation est rattachée à un utilisateur, les champs indispensables sont donc:

rails g model Authorization user:references uid:string provider:string token:string secret:string
# user.rb
has_many :authorizations, :dependent => :destroy
# authorization.rb
belongs_to :user

Utilisateur connecté

Si vous êtes connecté, vous avez un current_user donc vous pouvez créer une authorization depuis votre contrôleur.

Depuis l'espace où vous êtes connecté dans votre application vous pouvez lister les autorisations présentes et permettre à l'utilisateur de les révoquer.

Utilisateur déconnecté

Si vous n'êtes pas connecté, la première chose à faire est d'essayer de voir si une autorisation correspondante à l'uid récupéré dans le hash existe depuis le contrôleur de callback.

Si c'est le cas on récupère l'user rattaché à cette autorisation et il devient à la fois authentifié et notre current_user.

S'il n'y a pas d'autorisation correspondante c'est certainement que l'utilisateur veut se créer un compte.

Dans ce cas on va simplement récupérer les informations, les utiliser pour construire notre utilisateur et afficher la vue d'inscription.

Restera alors uniquement à l'utilisateur de rentrer son mot de passe et son email si celui ci n'est pas fourni, ce qui est un confort non négligeable.

Problèmes rencontrés

L'intégration de google m'a posé quelques problèmes, lorsque j'étais authentifié et que je tentais d'autoriser google, au retour mon current_user était nil, la session avait été remise à 0.

En fouillant un peu je me suis rendu compte qu'un ticket avait été ouvert. Cela vient apparemment du formulaire d'envoi des paramètres à google qui ne contient pas le token de protection.

Ce token n'étant pas envoyé, rails fait un reset de la session.

Il y a deux solutions, surcharger le formulaire existant de omniauth pour google en utilisant le helper form_tag qui inclue tout seul le token, ou dans notre contrôleur de callback contourner la vérification:

protect_from_forgery :except => :google_apps

Documentation complémentaire

La doc de devise
Ce gist est un bon point de départ, mis à part qu'il crée des comptes à la volée, et que la quasi totalité du code privé du contrôleur devrait être déporté dans le modèle authorization.

Accélérer le mode développement avec Rails 3.1

2011-10-07T00:00:00Z

Accélérer le mode développement avec Rails 3.1

L'asset pipeline en Rails 3.1 fait couler beaucoup d'encre numérique, et pas toujours en bien.

De mon côté, sur une application 3.1 fraîche, j'ai commencé à voir les temps d'affichage s'accroitrent de plus en plus, avant de me rendre compte en console qu'il s'agissait essentiellement d'un problème de chargement des assets.

+8 secondes pour afficher une image ce n'est clairement pas normal.

Le problème c'est que sprocket est utilisé comme une application rack classique.

Il est monté dans rails et chaque processing d'asset en développement entraîne un rechargement complet de la stack.

Pour (entre autre) désactiver ce comportement je vous conseille l'installation de la gem rails-dev-tweak.

Celle ci va se charger d'intercepter les requêtes concernant les assets et court-circuiter sprocket.

Synbioz recrute un développeur ruby on rails

2011-10-06T00:00:00Z

Synbioz recrute un développeur ruby on rails

Société

Depuis 2007, Synbioz est spécialisée dans le développement d'applications web et métier en ruby on rails.

Nous accompagnons des sociétés aux métiers aussi divers que passionnants, chaque projet est unique, sur mesure et centré utilisateur.

Pour poursuivre notre croissance nous recherchons un développeur Ruby on Rails.

Description du poste

Intégré(e) à une équipe expérimentée et passionné(e) de Ruby on Rails, vous participez à la conception et au développement d'application web en contact direct avec nos clients.

Vous travaillerez dans un cadre technique stimulant et selon les méthodologies agiles. Nous recherchons avant tout un développeur passionné, autonome et ayant l'esprit d'équipe et d'initiative.

Formation

Autodidacte, bac +2 à bac +5.

Expérience

Vous avez de bonnes connaissances en développement web et au moins une première approche de Rails.

Toutes autres expériences complémentaires seront appréciées, notamment la participation à des projets libres et le développement mobile.

Votre environnement

Pas de windows
git, os x || linux
Télétravail

Nos outils

Votre trousse à outil chez Synbioz se constituera des éléments suivants:

rails
rspec
git
node.js
socket.io
jquery
prototype
mongodb

Nous ne vous demandons pas de maitriser ces outils pour postuler.

Il s'agit justement d'outils que vous serez amenés à utiliser et que nous vous aiderons à prendre en main.

Rémunération

Selon formation et expérience.

Equipe

Notre équipe actuelle se compose de 3 profils techniques et d'un commercial. Le siège est basé à Paris mais l'ensemble de l'équipe se situe autour de Lille.

Le poste est ouvert partout en France de part le télétravail mais à compétences égales la proximité sera privilégiée.

Postuler

Vous pouvez nous contacter directement via le site, ou à l'adresse job@synbioz.com

En savoir plus

Présentation de OAuth

2011-08-30T00:00:00Z

Qu'est ce que OAuth ?

OAuth est né de la volonté d'offrir une solution simple et sécurisée aux mécanismes d'autorisation 3 parties. D'une part le client qui représente l'application qui veut utiliser mes données, d'autre part le serveur qui possède les données en question et enfin l'utilisateur qui valide ou non l'accès à ses données.

En effet les différents services web sont de plus en plus interconnectés, par le biais d'API, et il n'est pas rare qu'en tant qu'utilisateur je veuille donner la permission à l'application X d'utiliser certaines de mes données de l'application Y.

Avant OAuth, pour y parvenir, je n'avais pas beaucoup de solutions. J'étais généralement obligé de livrer mon login / mot de passe de Y à X.

Les usages concrets

Ils sont partout, souvent sans que l'on s'en rende compte. Par exemple lorsque j'utilise un client twitter sur smartphone ou sur ordinateur, à chaque fois que je veux poster un message l'application ne me demande pas mon mot de passe.

L'application en question a simplement eu besoin que je l'autorise à un moment donné, mes identifiants ne sont pas transmis à chaque requête.

Comme le montre la capture, je peux à tout moment révoquer cet accès.

Le fonctionnement

Le graphique de Yahoo explique bien le cheminement nécessaire pour qu'un utilisateur puisse donner accès à une ressource.

Voici le déroulement du processus:

Le client et le serveur doivent se mettent d'accord dans un premier temps. Pour cela des jetons clients doivent être créés. Par exemple sur twitter quand vous créez une application, vous récupérez les jetons clients (consumer key et consumer secret).
Une fois fait, les 2 applications vont pouvoir s'échanger des jetons temporaires qui permettront de demander l'autorisation d'accès.
Depuis l'application l'utilisateur peut maintenant être redirigé vers le serveur pour accepter ou non l'accès à ses ressources.
Si le client valide le jeton temporaire, celui ci pourra être converti en jeton d'accès.
Une fois le jeton enregistré, le client peut interagir avec l'API du serveur au nom de l'utilisateur jusqu'à ce que le jeton d'accès expire.

Il y a donc 3 types de jetons:

Jetons clients (consumer): permettent d'identifier le client auprès du serveur.
Jetons temporaires (token request): permettent d'identifier la demande d'autorisation et ne sont pas liés à un utilisateur en particulier.
Jetons d'accès (access token): permettent d'identifier l'utilisateur.

Le cheminement pour l'utilisateur est donc relativement simple, le service qui demande à accéder aux ressources (client) redirige vers le service qui propose la ressource (serveur) en spécifiant un callback.

Une fois l'accès validé par l'utilisateur, le service de destination (serveur) redirige vers le service demandeur (client) grâce au callback.

Une fois ce processus terminé le client peut agir au nom de l'utilisateur.

Il faut noter que les jetons constituent un accès temporaire et n'ont pas vocation à être utilisables ad vitam æternam.

La RFC propose deux méthodes pour signer les requêtes:

Secret partagé (symétrique).
RSA (asymétrique), dans ce cas la sécurité repose sur le secret de la clé privée.

Les versions

OAuth 1.0 (octobre 2007) qui ne doit plus être utilisée en raison d'une faille de sécurité.
OAuth 1.0a (juin 2009) qui corrige ce problème, version la plus largement répandue, utilisé par twitter, gmail, foursquare…
OAuth 2 (mai 2010), encore en draft, utilisé par facebook.

Les confusions

Il ne faut pas confondre authentification et autorisation. OAuth est un mécanisme d'autorisation là ou openid se veut un mécanisme d'authentification. Le premier vise à autoriser là ou le second vise à identifier une personne.

Les limitations

Il est important de noter que OAuth ne propose pas de mécanisme granulaire d'autorisation à proprement parler, il offre un mécanisme d'accès à un service mais ce n'est pas lui qui détermine à quoi a accès X. En fait, libre à Y d'implémenter ce mécanisme et de définir quelles seront les données accessibles.

Les risques

En terme de sécurité, les différents mécanismes mis en place souffrent de quelques faiblesses:

Les redirections sont vulnérables au phishing, notamment au moment de rediriger vers le service où l'utilisateur doit entrer ses identifiants pour autoriser l'accès.
La nécessité d'utiliser des secrets partagés expose les clés à une récupération, que ce soit par le biais d'une écoute du trafic http ou simplement dans le cas de code libre où les jetons clients seront visibles dans le code.

Les outils pour ruby

S'il y a une gem à avoir dans sa trousse à outil du bon développeur ruby, c'est omniauth qui s'intègre avec un nombre incroyable de services.

Cette gem est très bien maintenue et testée.

Conclusion

OAuth est maintenant un protocole largement répandu et s'est imposé comme la référence. A ce jour il parait impensable de ne pas l'utiliser si vous souhaitez construire une API avec un accès protégé.

Introduction à coffeescript

2011-08-02T00:00:00Z

C'est quoi coffeescript ?

Coffeescript est un langage compilé en JavaScript. Il n'est pas interprété nativement, il doit d'abord être converti en JavaScript afin d'être utilisable.

Il est à noter que coffeescript sera inclus directement dans rails 3.1.

Pourquoi l'utiliser ?

Quelques arguments avant de rentrer dans le vif du sujet:

JavaScript généré lisible.
Syntaxe proche de Ruby, très compréhensible.
Mécanisme de classe et d'héritage simplifié.
Inclus dans rails 3.1.
Volume de code à maintenir moindre.
Utilisation de concepts avancés simplifiés (classe, binding…).

Syntaxe

En coffee, vous n'avez pas besoin d'utiliser explicitement le mot clé var, ni les «;», ceux ci seront générés automatiquement pour vous.

Les idées reprises de Ruby

Les parenthèses sont facultatives du moment qu'elles ne posent pas de problèmes à l'interprétation.
Le dernier résultat interprété est retourné, pas besoin de return explicite.
Il est possible de faire de l'interpolation sur les strings du type: "foo #{bar}" ou bar est une variable.
Le if peut être placé en fin d'expression.
Le mot clé unless existe.
Les commentaires sont définis avec #.

L'égalité stricte avec le mot clé is

1 is 1
# true

1 is "1"
# false

Le or= et ?=

or= est l'équivalent de ||=

Attention avec a or= b

a prendra la valeur de b si a est null, undefined, false, vaut 0 ou "" qui valent tous false une fois convertis en booléen.

a ?= b affectera la valeur de b dans a uniquement si a est null ou undefined.

Il s'agit en fait d'un raccourci syntaxique. Chaque valeur définie peut être testée avec ?

a = null
a?
=> false
b = 42
b?
=> true

Equivalences de notation:

# équivalences
a ?= b
a = b unless a?
a = a ? b

Les fonctions

A chaque fois que vous voyez -> il s'agit en fait d'une définition de fonction. C'est un concept central dans coffeescript.

Définissions notre première fonction anonyme:

() -> console.log "Hello from coffee"

donnera en js:

(function() {
  return console.log("Hello from coffee");
});

Si vous avez besoin de pouvoir rappeler votre fonction, ce qui sera souvent le cas, excepté pour les callbacks, il vous suffit de l'affecter:

cube = (num) -> Math.pow num, 3

donnera en js:

cube = function(num) {
  return Math.pow(num, 3);
};

Je ne vous montre qu'une partie du code généré mais le compilateur généré aussi les déclarations de variable pour vous et enrobe le tout dans une fonction anonyme (voir portée).

Nous avons vu comment passer un argument et nommer une fonction.

Important: la génération des fonctions se fait de la forme suivante:

var f = function() {}

// et non:

function f() {}

Les deux syntaxes sont complètement valides, mais c'est la première qui a été retenue pour des raisons de compatibilité avec IE.

Toutefois celle ci est plus contraignante car vous ne pouvez appeler une fonction que quand elle a été définie.

L'ordre de définition est donc très important.

Paramètres par défaut

Les fonctions offrent la prise en charge des arguments par défaut.

helloWorld = (street = "Lille") -> console.log "Hello world from #{street}."

helloWorld()
# Hello world from Lille.
helloWorld("Paris")
# Hello world from Paris.

Splat

Les splat permettent de définir un nombre variable d'arguments qui seront récupérés comme un tableau:

f = (a, b..., c) ->

f("a", "foo", "bar", "baz", 42)

# b => [ 'foo', 'bar', 'baz' ]

A noter que les arguments hors splat sont les premiers à être assignés:

f("a", 42)

b # []

Les splats peuvent être utilisés hors fonction:

[a..., b] = ["foo", "bar", 42]
a # [ 'foo', 'bar' ]

Portée

Le moindre code coffeescript est transformé en un code JavaScript enrobé dans une fonction anonyme.

Cela présente un avantage et un inconvénient. D'une part vous ne risquez pas de rencontrer des conflits de nom ou de portée car le code générée ne peut pas écraser un code existant (namespacing).

D'autre part cela peut poser des problèmes si deux fichiers ont besoin d'interagir.

Au niveau compilation il est possible d'éviter cela avec l'option --no-wrap.

Au niveau code il est possible d'utiliser l'objet global window pour affecter les différents modules.

Par exemple pour déclarer une classe utilisable depuis un autre morceau de code coffee:

window.App = class App

This

Il est facile de s'arracher les cheveux si on maitrise mal la portée en JavaScript. Posez vous toujours la question: qui est this dans ce contexte ?

Coffeescript vous offre un raccourci syntaxe pour accèder directement à la propriété d'un objet:

@attribute équivaut à this.attribute

C'est pratique, notamment pour les classes (voir partie Les classes), mais aussi pour tout objet.

person  = { firstname: "Martin", lastname: "Catty" }
person.introduce = -> console.log "Bonjour, je suis #{@firstname} #{@lastname}."
person.introduce()
# Bonjour, je suis Martin Catty.

Cette syntaxe vient avec un raccourci syntaxique. Par exemple dans le cas classique de définition d'un setter.

setAttribute = (attribute) -> @attribute = attribute

peut être raccourci en:

setAttribute = (@attribute) ->

Coffeescript offre un mécanisme extrèmement simple pour garantir le this actuel. Plutôt que de définir votre fonction avec -> il suffit d'utiliser =>

Exemple:

registerEvents = (node) ->
  node.bind "click", (event) =>

Les classes

Coffeescript introduit un mécanisme de classe très puissant:

window.Animal = class Animal

window.Dog = class Dog extends Animal
  # convention pour une constante mais utilise var
  STATES = ["sleeping", "eating"]

  constructor: ->
    # appelle le constructeur d'Animal
    super

  # méthode de l'objet
  speak: ->
    console.log "woff."

  # variable de classe
  @count: 0

  # méthode statique
  @incCount: -> @count++

Utiliser coffeescript avec rails (avant 3.1)

La convention est de stocker ses fichiers dans app/coffeescripts/

Ensuite il s'agit de générer les fichiers correspondant. Pour cela guard fait très bien l'affaire.

# Gemfile:

group :development do
  gem 'guard'
  gem 'guard-coffeescript'
end

# Guardfile

group 'frontend' do
  guard 'coffeescript', :output => 'public/JavaScripts/compiled' do
    watch(%r{^app/coffeescripts/.+\.coffee$})
  end
end

bundle exec guard

Complément

Il est possible d'appeler du js depuis du coffee avec les backticks `.

Conclusion

L'apprentissage de coffeescript est assez simple, surtout si vous utilisez actuellement Ruby et que vous avez une bonne base en JavaScript.

Le temps d'apprentissage me semble largement valoir le gain en temps de développement et maintenance.

Bref, l'essayer c'est l'adopter.

Le devenir de Rails

2011-07-13T00:00:00Z

Récemment Patrick m'interpellait à propos d'un article sur le devenir de Rails.

Plutôt que de lui répondre en privé, j'en profite pour livrer mon opinion.

Note: cet avis est purement personnel.

Si j'ai vraiment le sentiment que l'auteur cherche à faire un peu de buzz en lançant un gros troll, cela ne signifie pas que je n'ai rien à reprocher à Ruby on Rails.

La courbe d'apprentissage de Rails

L'auteur nous signale qu'en venant de PHP la courbe d'apprentissage est complexe, et encore plus dans les dernières versions de Rails (il cite la 3 et la 3.1).

Je ne suis absolument pas d'accord. D'une part on ne peut pas mettre sur la même ligne un framework et un langage. Forcément si vous venez de PHP il sera plus simple d'appréhender un framework basé sur PHP, que sur Ruby.

D'autre part, je n'ai jamais entendu personne me dire que Ruby était plus complexe que PHP.

D'un côté on a un langage lisible, à l'API claire et réellement objet, de l'autre rien de tout ça. Si vous pensez que j'exagère, je vous invite à lire quelques citations de l'auteur de PHP.

Je ne crois pas que l'apprentissage de Rails 3 soit plus compliqué que celui de Rails 2. Par contre je conçois très clairement que passer de la version 2 à la 3 nécessite un investissement important.

C'est pour cela que lors de mes présentations j'insiste sur Ruby on Rails 2.x car la majorité des développeurs Rails à venir aura certainement à travailler sur des applications Rails 2.3 existantes.

S'ils n'en ont jamais vu, car uniquement formés sur Rails 3, cela risque d'être la douche froide.

Dans tous les cas une expérience sur Ruby on Rails ne s'improvise pas.

Commencer avec Ruby on Rails c'est l'utiliser, maitriser Ruby on Rails c'est le comprendre.

L'absence de route par défaut

Je crois que c'est le plus mauvais argument que j'ai pu lire. Rails est bâti sur un certain nombre de conventions (conventions over configuration), n'importe quel bon développeur sait qu'il est préférable de designer une application restful, c'est à dire basée sur une approche ressources.

L'idée est d'exploiter pleinement le potentiel du protocole HTTP en mappant (ou en émulant) les verbes HTTP sur les actions de CRUD (post pour le create, get pour le read, put pour l'update et delete pour le destroy).

Les helpers javascript

Leur disparition ne peut qu'améliorer la base de code de Rails. C'était très clairement une très mauvaise idée, qui avait privilégié la simplicité au dépend de la qualité.

La couche javascript ne doit pas et n'aurait jamais dû être présente dans les vues. La gestion événementielle doit être déportée dans des fichiers séparés, qui pourront être minifiés et cachés.

Les choix par défaut de Rails

Rails, à l'instar de Freebsd ou Linux sont gérés, désolé pour l'oxymore, par des "dictateurs bienveillants". Cela confère des avantages et des inconvénients. D'une part le projet évolue rapidement avec une certaine ligne directrice, d'autre part on peut se retrouver en opposition avec un choix.

Dans le cas de coffeescript je rejoins l'auteur. Je ne suis pas gêné par ce choix, car nous utilisons de toute façon coffeescript, mais je ne vois pas l'utilité d'imposer une surcouche dans la stack par défaut de Rails.

Il en va de même pour haml / sass. Ce sont des choix très personnels, qui devraient le rester.

Nombreux sont ceux qui reprochent à Rails de vouloir être trop tendance en incluant les libs ou surcouche à la mode. Je ne crois pas que ce soit l'idée. La core team Rails fait le choix d'introduire certains éléments parce qu'elle les considèrent comme facilitant le développement, productifs, plus adaptés ou répandus (par exemple pour le remplacement de prototype par jquery par défaut).

Chaque choix est discutable mais l'essentiel à mon sens reste d'avoir le choix.

C'est l'un des principaux atouts de Rails 3, être indépendant à un grand nombre de niveaux, que ce soit dans le choix du mapping objet relationnel, de la bibliothèque js, du système de tests…

De même on peut maintenant configurer son framework aux petits oignons et charger uniquement les composants requis ; permettant à Rails de développer aussi bien des petites que des grosses applications.

La documentation

Forcément si on utilise la version edge de Rails pour essayer d'écrire un livre cela risque d'être compliqué.

Je pense qu'il s'agit vraiment d'un faux procès car on a quand même beaucoup de documentation pour Rails. Si on regroupe les guides, l'api, les screencasts, les tutoriaux, et tous les éléments d'informations qu'on peut trouver via Rubyflow cela donne une source d'information considérable.

Reproche: l'aspect performance

Loin de moi l'idée de vouer un culte à Rails. D'ailleurs il y a vraiment une chose qui m'irrite: les régressions de performance.

Quand je vois ce tweet de Thomas Fuchs, cela me fait bondir. Clairement, un framework qui se veut professionnel devrait intégrer un certain nombre de tests de performances et une release ne devrait pas pouvoir sortir s'il elle ne remplit pas ces critères.

On ne peut pas transiger là dessus.

Conclusion

La volonté de Rails est, il me semble, de simplifier la vie du développeur. Parfois il s'agit aussi de pousser les bonnes pratiques (par exemple pour la minification en 3.1).

Sa force a toujours été d'avoir une approche pragmatique, donc basée sur des usages réels, et je continuerai à l'utiliser tant que son développement ira dans ce sens.

Encore plus productif avec ruby on rails

2011-06-15T00:00:00Z

Améliorer son environnement de développement Ruby on Rails

Si vous utilisez déjà Ruby on Rails (si vous hésitez encore, jetez un œil à pourquoi choisir ruby on rails) vous vous dites sûrement que rails est déjà très productif out of the box, et vous avez raison.

Base de donnée, serveur embarqué, nul besoin d'un IDE ; tout est là pour commencer à prototyper rapidement. Mais les outils évoluent et il est possible de faire encore mieux.

Pow

Pow est un outil qui embarque à la fois un mini serveur DNS et HTTP. L'installation se borne à l'exécution d'un script sh.

curl get.pow.cx | sh

Le script va récupérer la dernière version et s'installer au démarrage. Attention le script nécessite mac os x 10.6 pour fonctionner, même si une branche linux existe sur ce fork.

L'objectif de pow est de charger vos applications à la demande, il suffit pour cela de faire un lien symbolique dans le dossier ~/.pow

ln -s /mon/app ~/.pow/

Une fois réalisé, faites pointer votre navigateur sur http://app.dev

Le serveur web embarqué est nack. C'est un serveur rack basé sur node.js

Pour les applications rails 3 il n'y a rien à faire, pow s'accommode parfaitement de bundler et rvm.

Pour les applications rails 2 il faut fournir un fichier rackup, qui explique à n'importe quel serveur compatible rack comment booter l'application.

Ce fichier se présente sous cette forme:

require File.dirname(__FILE__) + '/config/environment'
run ActionController::Dispatcher.new

Au delà d'un certain temps (5 min par défaut, configurable dans ~/.powconfig) d'utilisation, l'app sera arrêtée et déchargée.

Si vous avez besoin de forcer le re-chargement de l'application il suffit de faire un:

touch tmp/restart.txt

comme avec passenger. Mais le rechargement forcé devrait être de l'histoire ancienne grâce à l'outil suivant.

Guard

Guard est un outil de détection et de gestion des événements relatifs au système de fichier. Sa force est d'être cross-platform en s'appuyant sur des outils éprouvés selon le type d'OS.

Cela permet par exemple d'exécuter une action lors du changement d'un fichier. Exemples:

Concaténer et minifier le javascript de production lorsque les fichiers sources sont modifiés.
Relancer la série de tests automatiquement à la sauvegarde des fichiers de test.
Relancer le serveur web lorsqu'un fichier de conf est modifié …

Guard s'installe comme n'importe quelle gem, il suffit de l'ajouter au Gemfile.

Ensuite on crée notre Guardfile avec: guard init.

Guard possède un certain nombre de modules complémentaires. Il y en a par exemple un pour s'interfacer avec pow. Dans le Gemfile:

group :development do
  gem 'guard-pow'
end

Et enfin:

guard init pow

Cela vous crée le fichier Guardfile suivant:

guard 'pow' do
  watch('.powrc')
  watch('.powenv')
  watch('.rvmrc')
  watch('Gemfile')
  watch('Gemfile.lock')
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.*\.rb$})
  watch(%r{^config/initializers/.*\.rb$})
end

À la modification de l'un de ces fichiers guard va donc relancer pow automatiquement.

Livereload

Livereload pousse l'automatisation encore un peu plus loin.

Une fois la gem et l'extension (disponible pour safari, chrome, firefox 4) installée, dans le répertoire de l'application il suffit de lancer livereload en console puis de connecter le navigateur.

Une fois fait, chaque changement dans un fichier observé (vue, css, js…) entrainera un rechargement automatique du navigateur.

Il est bien sûr possible d'observer différents types de fichiers en ajoutant leur extension dans le fichier .livereload.

Livereload utilise les websocket pour communiquer avec le navigateur.

Enfin, il existe guard-livereload, qui s'installe comme les autres gem, pour ne plus lancer livereload manuellement.

Au final au lieu de lancer un rails server votre commande par défaut deviendra:

bundle exec guard

Visibilité, introspection, méta-programmation et réflexion avec ruby

2011-05-31T00:00:00Z

Une visibilité différente

Les méthodes publiques

C'est la visibilité par défaut d'une méthode, elle n'a pas de particularité.

Les méthodes privées

Contrairement à d'autres langages, les méthodes privées sont aussi héritées dans les classes descendantes.

class Animal
  attr_accessor :name, :age, :weight

  def initialize(name, weight, age)
    @name = name
    @weight = weight
    @age = age
  end

  def to_s
    "I'm #{name}, I have #{age} years and I weigh #{weight} KG."
  end

  def older?(animal)
    age > animal.age
  end

  def bigger?(animal)
    weight > animal.weight
  end

  protected :age
  private :weight
end

class Dog < Animal
end

class Cat < Animal
  def to_s
    "I'm #{name}, I have #{age} years and I weigh #{weight} (but I have lost some kg)."
  end
end

Animal#weight est privée, pourtant si j'appelle le Cat#to_s, j'aurai bien "I'm garfield, I have 3 years and I weigh 10 (but I have lost some kg)." ce qui signifie que l'on a bien accès à la méthode.

Les autres méthodes de la classe peuvent accéder à la méthode privée, mais uniquement pour l'objet courant. Dans l'exemple garfield.bigger?(snoopy) renverra une erreur car je ne peux pas invoquer weight sur snoopy depuis garfield.

Cette notion de contexte est très importante car même l'invocation sur self ne fonctionnera pas. Si dans mon to_s j'utilisais self.weight j'aurai droit à une erreur d'invocation de méthode privée.

Les méthodes protected

Contrairement à d'autres langage comme java, le fait de définir une méthode protected, ne signifie pas qu'elle pourra uniquement être appelée dans une classe descendante. On a vu que même les méthodes privées étaient héritées.

En effet en ruby une méthode protected est très proche d'une méthode privée. La nuance se trouve au niveau du contexte. Si on a vu que l'invocation de bigger? renvoyait une erreur, dans le cadre d'un attribut protected comme age cela fonctionne, je peux donc invoquer Animal#older?

Les attributs protégés sont donc accessibles aux autres objets de la classe mais aussi aux objets de classe héritées. Par exemple ici je peux accéder à Dog#weight depuis Cat#weight car ils descendent tout deux de Animal.

Introspection

L'introspection est la capacité pour un objet de s'auto-examiner:

p garfield.class
# Cat
p garfield.class.ancestors
# [Cat, Animal, Object, Kernel]
p garfield.methods.sort
# ["==", "===", "=~", "__id__", "__send__", "age", "age=", "bigger?", "class", "clone", "display", "dup", "enum_for", "eql?", "equal?", "extend", "freeze", "frozen?", "hash", "id", "inspect", "instance_eval", "instance_exec", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "name", "name=", "nil?", "object_id", "older?", "private_methods", "protected_methods", "public_methods", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "tap", "to_a", "to_enum", "to_s", "type", "untaint", "weight="]
p garfield.methods(false)
# []

# Object.const_get("RUBY_VERSION")
p garfield.class.ancestors.last.const_get("RUBY_VERSION")
# 1.8.7

On peut par exemple lister toute la hiérarchie de classes parentes, tout comme les constantes et les méthodes définies. Le paramètre false sur methods permet de ne lister que nos propres méthodes et pas celles héritées.

Ici Cat ne définit aucune méthode qui lui est propre, d'où le tableau vide.

Méta-programmation

Il faut visualiser la méta-programmation comme du code qui crée du code.

class Cat
  STATES = ["hungry", "sated"].freeze

  attr_accessor :state

  STATES.each do |state|
    define_method "#{state}?" do
      state == self.state
    end
  end
end

garfield.state = "hungry"

p garfield.hungry?
# true
p garfield.sated?
# false

Ici je peux ré-ouvrir ma class Cat à la volée et y définir des méthodes en fonction d'attributs existants. La clé se trouve dans le define_method qui permet de créer des méthodes dynamiquement.

Réflexion

On a vu dans la première partie des méthodes à la visibilité privée. Toutefois en ruby il n'est pas possible de complètement cacher une méthode.

p garfield.send :weight
# 10
Cat.send :public, :weight
p garfield.weight
# 10

Celle ci peut toujours être invoquée avec send. De même il est possible de changer la visibilité d'une méthode au runtime ! Vous l'aurez compris, ces concepts très puissants sont à utiliser avec parcimonie.

Retour sur nos présentations de rails à Supinfo

2011-05-19T00:00:00Z

La situation de ruby en france

Chez Synbioz, nous avons le sentiment que la demande autour de ruby et ruby on rails s'accroît et que l'offre a de plus en plus de mal à suivre.

Là où 3-4 ans en arrière il fallait convaincre de l'intérêt et de la puissance de la technologie, aujourd'hui certains clients nous la réclame spontanément.

Nombreuses sont les sociétés à vouloir internaliser des profils rubyistes, et vous diront ô combien c'est difficile. Le plus étonnant vient du fait que généralement ceux qui se lancent sur cette technologie sont séduits et n'envisagent pas de faire machine arrière.

Dans l'équation nous avons donc des porteurs de projets friands de la technologie, des développeurs heureux de l'utiliser mais une chose ne suit pas: la formation.

Les rubyistes seniors actuels sont ceux qui ont pris sur leur temps personnel pour se former et découvrir cette technologie. Parfois le déclic (ce fût mon cas) aura été une présentation. Une simple introduction permet d'éveiller la curiosité.

J'avais donc envie de rendre un peu de ce qui m'avait été donné.

Le domaine de l'éducation est assez complexe et immobiliste en général, c'est pourquoi j'ai proposé de sensibiliser les futurs ingénieurs à cette technologie par le biais de conférences.

Supinfo a accepté ma proposition et je les en remercie.

La présentation

Je suis donc intervenu au Supinfo de Valenciennes puis Lille. Ma présentation se divise en 2 parties: une première approche de ruby puis une présentation de rails.

J'ai pris le parti de présenter rails 2.3 qui est, d'après mon expérience, la version la plus répandue à l'heure actuelle. Bien sûr il était tentant de présenter rails 3, mais j'ai privilégié l'approche pragmatique.

D'autant plus que j'ai le sentiment qu'une fois les fondements de rails 2.x intégrés, il est facile de passer à rails 3, là où un retour en arrière semble plus complexe.

La présentation est disponible sous plusieurs formats:

ou directement visible:

Ruby on rails presentation

View more presentations from synbioz.

La présentation a été très bien accueillie par les étudiants et j'ai eu droit à des questions très pertinentes. Il n'est pas évident de proposer une présentation qui s'adapte à la plupart des publics: de celui qui n'a jamais entendu parler de ruby à celui qui a déjà fait une première application en rails.

J'ai ajouté à cette présentation 10 exemples qui permettent de visualiser les concepts évoqués et d'aller un peu plus loin.

Pour tout retour, question ou suggestion d'amélioration vous pouvez m'adresser vos remarques à l'email noté dans la seconde slide du support. N'hésitez pas, c'est toujours agréable d'avoir du feedback.

Cette présentation est sous licence CC BY-NC-SA 2.0. Vous pouvez donc modifier et distribuer cette présentation, sous réserve de citer l'auteur, ne pas en faire un usage commercial, et conserver cette licence si vous partager votre version modifiée.

Le côté objet de javascript

2011-05-17T00:00:00Z

Javascript est un langage objet, même s'il ne possède pas un modèle de programmation par classes mais une modèle orienté prototype.

Un objet n'est donc pas une instance de classe mais un clone de prototype, et peut être modifié «à chaud».

Ce concept est extrêmement puissant ^[1], puisque l'héritage est dynamique, c'est à dire qu'un objet peut changer de parent en cours de route (cf. section Héritage).

Le fait d'ajouter une fonction dans le prototype, rend cette fonction disponible immédiatement dans l'ensemble des clones.

var a1 = ["4", "2"]
Array.prototype.size = function() { return this.length; }
var a2 = ["s", "y", "n", "b", "i", "o", "z"]
a1.size()
=> 2
a2.size()
=> 7

Javascript, un langage tout objet

Javascript est un langage interprété et typé dynamiquement. Il existe deux moyens de connaitre le type d'un objet:

var a = true
typeof a
=> "boolean"
a.constructor.name
=> "Boolean"

typeof Boolean
=> "function"
Boolean.constructor.name
=> "Function"

typeof Function
=> "function"

Function représente donc la base de l'héritage.

Visibilité et portée

Il est possible au sein d'une fonction de définir des variables ou méthodes qui ne seront pas accessibles de l'extérieur.

function A() {
  // private
  var _foo = "foo";

  function foo() {
    return _foo;
  };

  // public
  this._bar = "bar";
  this.bar = function() {
    return this._bar;
  }

  // public method returning private attribute
  this.baz = function() {
    return _foo;
  }
}

var a = new A;
a.foo()
=> TypeError: a.foo is not a function
a._foo
=> "undefined"
a.bar()
=> "bar"
a._bar
=> "bar"
a.baz()
=> "foo"

// static method
A.parse = function() { … }

var a = new A
a.parse()
// TypeError: a.parse is not a function

Simuler la notion de packages

La notion de namespace n'existe pas à proprement parler en Javascript mais elle est très simple à simuler:

var com = {};
com.synbioz = {};

com.synbioz.app = function(name, url) {
  this._name = name;
  this._url = url;
}

new com.synbioz.app("foo", "foo.com")

Héritage

Il faut imaginer la méthode prototype comme un pointeur vers le constructeur dans un héritage par classe.

function Human() { this.speak = function() { return "bonjour" } }
function Monster() { this.speak = function() { return "grrrr" } }

function Hulk() {}

// hulk inherits from Human
Hulk.prototype = new Human()
hulk1 = new Hulk()
hulk1.speak()
=> "bonjour"

// hulk inherits from Monster
Hulk.prototype = new Monster()
hulk2 = new Hulk()
hulk2.speak()
=> "grrrr"

// warning:
hulk1.speak()
=> "bonjour"

Le changement de constructeur n'impacte pas les objets déjà créés car la propriété prototype de hulk1 n'a pas été modifiée, c'est le prototype du parent (Hulk) qui a été modifié.

// still does'nt work
hulk1.prototype = new Monster();
hulk1.speak()
=> "bonjour"

Ce code n'a logiquement aucun effet, on ne peut pas modifier directement le prototype de l'objet, cela reviendrait à vouloir modifier le constructeur d'une instance dans un héritage par classe.

Toutefois, dans certaines implémentations (ex: mozilla), l'objet garde une référence vers le prototype parent.

Attention, la propriété n'est pas standard et ne fonctionne pas sur tous les navigateurs.

hulk1.__proto__ = new Monster
hulk1.speak()
=> "grrrr"

[1]: Attention, Un grand pouvoir implique de grandes responsabilités.

Algorithme déterministe de génération de couleurs

2011-03-08T00:00:00Z

Le problème: générer une suite déterministe de nombres

Dans un programme il arrive parfois que vous ayez à générer une suite de nombres aléatoire. Pour cela rand fait très bien l'affaire.

Par contre vous pouvez avoir besoin de générer une suite de nombres déterministes, c'est à dire que la suite générée sera toujours la même.

Dans mon cas il s'agit de générer un tableau de couleurs pour un chart. Le nombre de couleurs n'est pas défini à l'avance mais je souhaite que les couleurs générées soit toujours les même pour éviter que le graphique change complètement à chaque rafraichissement.

Le fonctionnement de rand

Lorsqu'on utilise un générateur comme rand il commence par initialiser son seed, un nombre sur lequel sera basé la génération des nombres.

Ce nombre est normalement initialisé de façon complètement aléatoire, en se basant sur /dev/random ou /dev/urandom (sur les systèmes UNIX) pour maximiser l'entropie des nombres générés.

Le but étant que les nombres générés soient le moins «devinable» possible.

Dans notre cas nous voulons une suite déterministe, nous allons donc initialiser le seed nous même.

Pour cela en ruby 1.8 on peut utiliser srand:

srand 42
a = [rand, rand, rand]
srand 42
[rand, rand, rand] == a
=> true

En ruby 1.9 on a la classe Random directement:

generator = Random.new(42)
generator.rand

La génération de couleurs

def colors(size)
  1.upto(size).inject([]) { |colors, index|
    r, g, b = yield
    colors << "#%02x%02x%02x" % [r, g, b]
  }
end

def hsv_to_rgb(h, s, v)
  h_i = (h * 6).to_i
  f   = h * 6 - h_i
  p   = v * (1 - s)
  q   = v * (1 - f * s)
  t   = v * (1 - (1 - f) * s)
  case h_i
  when 0
    r, g, b = v, t, p
  when 1
    r, g, b = q, v, p
  when 2
    r, g, b = p, v, t
  when 3
    r, g, b = p, q, v
  when 4
    r, g, b = t, p, v
  when 5
    r, g, b = v, p, q
  end
  [(r * 256).to_i, (g * 256).to_i, (b * 256).to_i]
end

srand 42
c = colors(5) { hsv_to_rgb(rand, 0.5, 0.30) }

Plutôt que d'utiliser une génération pure de 3 couleurs avec rand(256) on utilise la représentation hsv (tsv en français) des couleurs: teinte, saturation, valeur.

Le premier paramètre code la couleur tandis que les suivant codent l'intensité et la brillance. L'intérêt est de générer des couleurs dans les même tons, pour éviter d'avoir des couleurs pastel et d'autres très vives dans le chart.

Vous pouvez donc ajuster manuellement votre teinte et votre saturation. Dans l'exemple on a 0.5 et 0.3.

Je ne vais pas vous expliquer l'algorithme de conversion hsv_to_rgb, je me suis servi de l'article de wikipedia: Teinte Saturation Valeur - Wikipédia

Pour le reste j'appelle colors en lui passant hsv_to_rgb en block. Une fois mes 3 couleurs obtenues, je transforme rgb en notation hexadécimale. Si la notation vous surprend jetez un œil du côté de sprintf.

Précision importante si vous ne lisez pas l'article de wikipedia, l'algorithme de conversion RGB vers TSV n'est pas réversible, vous pouvez donc représenter toutes les couleurs RGB en notation TSV mais pas l'inverse (car l'espace TSV contient plus de couleurs que celui RGB).

Place aux middlewares avec rack

2011-01-04T00:00:00Z

Créer son middleware

Dans mon introduction à rack je vous ai laissé sur votre faim concernant la création de middleware.

Nous allons donc voir comment faire un mini-logger.

Tout d'abord ne pas oublier de rajouter le dossier lib dans l'autoload:

module App
    class Application < Rails::Application
      config.autoload_paths += %W(#{config.root}/lib)
    end
  end

Ensuite on crée une class Tracking dans notre dossier lib:

class Tracking
    def initialize(app)
      @app = app
    end

    def call(env)
      request = Rack::Request.new(env)
      File.open(File.join(Rails.root, "log", "custom.log"), "a") do |f|
       f << "IP: #{request.ip}, PATH: #{request.path}, PARAMS: #{request.params}\n"
      end
      @app.call(env)
    end
  end

Et voilà notre middleware d'une 10aine de ligne.

Quelques explications:

Le constructeur se contente de placer l'objet app dans une variable d'instance pour pouvoir y accéder depuis call.
call prend l'environnement en entrée. Les middlewares sont chaînés, ce qui permet de modifier l'environnement d'un middleware à l'autre.

Par exemple je pourrai définir env['foo'] = 'bar' et y avoir accès dans le middleware suivant.

L'invocation de app.call(env) va renvoyer le status de la requête (code http, ex: 200), les entêtes et la réponse. Le middleware peut donc modifier ces 3 éléments.

Ici nous nous contentons de parser la requête à partir de l'environnement entrant à l'aide de rack. Ensuite nous avons accès à toutes les méthodes classiques de request.

Inclure son middleware

Dans notre fichier d'environnement, par exemple developement.rb il suffit de définir les middlewares de la sorte:

App::Application.configure do
    config.middleware.delete("Rails::Rack::Logger")
    config.middleware.insert_after("ActionDispatch::ParamsParser", "Tracking")
    # config.middleware.use("Tracking")
  end

Il est important de bien utiliser les versions quotées des classes. L'utilisation de la constante entrainerait une exception, car la classe ne serait pas encore chargée.

On a ici commencé par retirer le logger de rack pour ajouter notre middleware après le parser. La dernière ligne montre l'utilisation de use, qui permet d'ajouter le middleware en fin de liste.

On remarque que Rails 3 est vraiment modulable, l'ajout ou la suppression d'un middleware est très simple, rendant le framework très souple.

Analyse d'un middleware existant: Etag

Bon, notre middleware est vraiment basique, mais vous allez voir qu'un middleware plus pratique tel qu'Etag ne fait pas grand chose de plus compliqué.

require 'digest/md5'

  module Rack
    # Automatically sets the ETag header on all String bodies
    class ETag
      def initialize(app)
        @app = app
      end

      def call(env)
        status, headers, body = @app.call(env)

        if !headers.has_key?('ETag')
          digest, body = digest_body(body)
          headers['ETag'] = %("#{digest}")
        end

        [status, headers, body]
      end

      private
        def digest_body(body)
          digest = Digest::MD5.new
          parts = []
          body.each do |part|
            digest << part
            parts << part
          end
          [digest.hexdigest, parts]
        end
    end
  end

L'initialisation est identique. Le call va récupérer le status, les entêtes et la requête.

Ensuite le contenu de la requête est hashé et un entête Etag avec le checksum MD5 ajouté, ce qui permettra au serveur de servir directement le contenu s'il a déjà été calculé.

Et c'est tout !

Introduction à rack

2010-12-28T00:00:00Z

Qu'est ce que rack ?

Rack est une interface entre votre application et votre serveur web. Son but est d'unifier les API pour simplifier la communication entre l'application et le serveur web. Grâce à rack vous pouvez:

interchanger votre serveur, pourvu qu'il soit rack compatible (comme thin, unicorn, passenger…)
extraire un morceau d'application pour la transformer en application autonome
intégrer une application existante dans une autre application (ex: une application sinatra dans une application rails)

Rack porte bien son nom et son logo puisque l'idée sous jacente est de pouvoir empiler des applications qui vont prendre en entrée la requête pour préparer la réponse.

Dans rails 3, chaque contrôleur est une application rack.

Exemple d'app rack basique:

use Rack::ContentLength

  app = lambda { |env| [200, { 'Content-Type' => 'text/html' }, 'Hello World'] }
  run app

Ce petit bout de code est une app rack en soit et peut être lancé via:

rackup app.ru -s thin -p 4000

équivalent à:

thin -R app.ru -p 4000 start

Rack monte à bord de rails

Rails 3 étant compatible rack, vous pouvez parfaitement mapper une url directement sur votre mini-app rack:

# config/routes.rb
  Foo::Application.routes.draw do
    root :to => WelcomeApp
  end

  # lib/welcome_app.rb
  class WelcomeApp
    def self.call(env)
      [200, { 'Content-Type' => 'text/html' }, 'Hello World']
    end
  end

(N'oubliez pas de mettre le dossier lib dans l'autoload_path)

Un empilement de middlewares

Imaginez rails 3 comme une chaîne de middlewares, chacun ayant un travail bien précis à réaliser. Par exemple:

Parser la requête pour extraire le path, les params etc…
Gérer les cookies
Gérer la connexion à la base de données

Pour avoir un listing complet, en console:

Rails.application.middleware

Pas moins de 18 middlewares sont déjà chargés de base.

Tous agissent de façon autonome, ce qui garantit une grande modularité et granularité. Par exemple si vous souhaitez créer une application web qui aura juste quelques contrôleurs et qui ne sauve pas de données en base, vous pouvez charger uniquement ce dont vous avez besoin dans votre config/application.rb.

Par défaut à la création d'une application rails 3 on a:

require 'rails/all'

Ce qui nous charge les middlewares suivants:

[ActionDispatch::Static, Rack::Lock, ActiveSupport::Cache::Strategy::LocalCache, Rack::Runtime, Rails::Rack::Logger, ActionDispatch::ShowExceptions, ActionDispatch::RemoteIp, Rack::Sendfile, ActionDispatch::Callbacks, ActiveRecord::ConnectionAdapters::ConnectionManagement, ActiveRecord::QueryCache, ActionDispatch::Cookies, ActionDispatch::Session::CookieStore, ActionDispatch::Flash, ActionDispatch::ParamsParser, Rack::MethodOverride, ActionDispatch::Head, ActionDispatch::BestStandardsSupport]

Si on décide de charger uniquement action_controller:

require "action_controller/railtie"

[ActionDispatch::Static, Rack::Lock, ActiveSupport::Cache::Strategy::LocalCache, Rack::Runtime, Rails::Rack::Logger, ActionDispatch::ShowExceptions, ActionDispatch::RemoteIp, Rack::Sendfile, ActionDispatch::Callbacks, ActionDispatch::Cookies, ActionDispatch::Session::CookieStore, ActionDispatch::Flash, ActionDispatch::ParamsParser, Rack::MethodOverride, ActionDispatch::Head, ActionDispatch::BestStandardsSupport]

Les deux middlewares ActiveRecord::ConnectionAdapters::ConnectionManagement et ActiveRecord::QueryCache ne sont plus chargés.

Dans notre prochain article sur rack nous verrons comment créer son propre middleware.

Insérer un tableau dans le dom avec Internet Explorer 7

2010-10-20T00:00:00Z

Le problème

Avec prototype, l'insertion d'un tableau sous Internet Explorer 7 (et 6) dans le DOM de la manière ci-dessous ne fonctionne pas:

document.observe("dom:loaded", function() {
  var table = new Element("table");
  var row = new Element("tr");
  row.insert(new Element("td").update("foo"));
  row.insert(new Element("td").update("bar"));
  table.insert(row);
  $(document.body).insert(table);
});

La solution

En effet il est nécessaire de spécifier explicitement les éléments thead et tbody:

document.observe("dom:loaded", function() {
  var table = new Element("table");
  var thead = new Element("thead");
  var row = new Element("tr");
  row.insert(new Element("td").update("foo"));
  row.insert(new Element("td").update("bar"));
  thead.insert(row);
  table.insert(thead);
  $(document.body).insert(table);
});

Selon le w3c la création de ces éléments n'a pas à être explicite. Il s'agit donc (encore) d'un bug d'Internet Explorer, fixé sur IE8.

Les technologies derrière synbioz.com

2010-10-12T00:00:00Z

Le site

Pour le site nous avons fait le choix du minimalisme. Il était très tentant de partir sur Ruby on Rails 3, mais nous n'avions pas besoin de toutes ses fonctionnalités.

Nous nous sommes ensuite penchés sur jekyll qui permet de convertir des fichiers statiques en page HTML. Mais nous souhaitions conserver un minimum de dynamisme.

Nous avons donc fait le choix de sinatra, qui remplit complètement ces pré-requis.

Pour les vues nous utilisons haml ainsi que sass pour les feuilles de style.

Nous sommes aussi parti sur HTML5 ~~parce que son doctype est plus simple à retenir~~ pour commencer à utiliser les éléments implémentés par les navigateurs comme la validation de formulaire côté client avec les nouveaux types d'input (email…) ainsi que les nouveaux attributs (required…).

Concernant CSS3 nous utilisons ses propriétés dans une logique d'amélioration progressive. Nous avons utilisé les media queries et la propriété -webkit-transform-3d (Safari uniquement) pour mettre en place l'effet cube sur la page réalisations.

Le blog

Pour le blog nous aurions pu passer par des solutions dédiées en Ruby on Rails comme typo mais nos besoins étaient trop modestes pour cela.

De plus nous souhaitions nous baser sur git pour versionner nos billets, afin de pouvoir les rédiger depuis un simple shell.

Dans cette optique nous avons développé notre solution maison. L'idée est simple, nous avons un dépôt git avec deux branches, drafts et master. Lors de l'écriture d'un article nous travaillons dans la branche drafts. Une fois le billet terminé il est rapatrié dans le master avec git cherry-pick, puis pushé.

Chaque article correspond donc à un simple fichier. Pour gérer les tags, l'auteur ou encore les catégories nous avons repris un principe en place dans jekyll, le YAML Front Matter, c'est à dire que les informations relatives au billet sont stockées dans l'entête du fichier et parsées à l'import. Exemple:

---
contributors: ["Martin Catty"]
title: Foo
tags:
  - sinatra
  - thor
  - fr
---

Sur le serveur une tâche thor se charge de de récupérer les fichiers écrits en Markdown dans la branche master, de les convertir en html, de récupérer les entêtes et de les importer en base de donnée.

Côté BDD c'est aussi le minimalisme qui prévaut avec sqlite3 et datamapper en guise d'ORM.

Améliorations possibles

Pour le moment les articles sont automatiquement chargés par un cron job mais il serait plus efficace d'utiliser le hook post-receive du dépôt pour invoquer dynamiquement la tâche thor.