On 2016-04-29 11:07, Olivier Macchioni wrote:

Un des soucis que j'ai, c'est comment tester la stack version N+1 avant de la passer en production... Il s'agirait typiquement de permettre à certains clients d'utiliser N+1 avant les autres. Il y a plusieurs options, aucune ne me satisfaisant vraiment:

• donner un "secret" aux testeurs (URL secrète, certificat SSL client, cookie à configurer manuellement sur le poste client?)...

Le secret (url ou autre) qui permet d'inserer l'IP source dans une stick table, et ensuite une autre ACL avec des use_backend pour passer le traffic la ou ca va bien.

Ensuite dans la phase de migration tu joue avec la bascule de poids opour basculer 100% des clients vers la stack N+1.

Le 29/04/2016 11:07, Olivier Macchioni a écrit :

Bonjour la liste,

Bonjour,

Pour ceux qui ne connaissent pas, le Blue-Green Deployment, c'est http://martinfowler.com/bliki/BlueGreenDeployment.html : deux stacks (par exemple LAMP) complètes, en version N et N+1, derrière un Load-Balancer.

[snip]

Je suppose que le problème a déjà été résolu par pas mal de monde... vous faites comment vous ? :)

Pas avec HAProxy :-) Pour le coup j'utilise plutôt varnish pour ça. Dans le cas présent, avec cookie et un header HTTP. (voir plus bas) Cependant, en jettant un œil à la doc, il me semble que l'on peut faire un peu la même chose avec HAProxy en utilisant comme balance rdp-cookie. Mais je connaissais pas cette balance et j'utilise HAProxy pour faire des choses beaucoup plus simples :-)

Pour la façon dont je solutionne ça...

J'ai cette sub que j'appelle ensuite dans le recv : sub blue_green { if (req.http.cookie ~ "m_test=c") { set req.http.X-migration = "c"; } else if (req.http.cookie ~ "m_test=n") { set req.http.X-migration = "n"; } else if (client.ip ~ mynetwork) { set req.http.X-migration = "n"; } else { C{ #include <netinet/in.h> #include <string.h> #include <unistd.h> #include <stdlib.h>

char nc[2]; char *user_agent; in_addr_t s_addr; struct sockaddr_storage client_ip = *(VRT_r_client_ip(sp)); struct sockaddr_in *client_ip_in = (struct sockaddr_in *) &client_ip;

nc[1] = '\0'; user_agent = VRT_GetHdr(sp, HDR_REQ, "\013user-agent:"); if (user_agent != (void*)0 && strstr(user_agent, "Googlebot") != (void*)0) { nc[0] = 'c'; } else { s_addr = ntohl(client_ip_in->sin_addr.s_addr); if (s_addr & 2) nc[0] = 'n'; else nc[0] = 'c'; } VRT_SetHdr(sp, HDR_REQ, "\012X-migration:", nc, vrt_magic_string_end); }C } }

Elle génère un header qui dit "c" (current) ou "n" (next). L'applicatif à la possibilité de générer un cookie m_test avec un petit bouton pour les utilisateurs qui veulent passer à l'une ou l'autre des versions.

Dans mon cas, c'est l'applicatif qui passe en version N ou N+1 en fonction de la requête (c'est varnish qui nous sert de load-balancer), mais je pourrais aussi très bien définir plusieurs director et faire de mon header un déterminant dans le choix d'icelui avec un recv de ce goût là :

sub vcl_recv { call blue_green

if ( req.http.X-migration == "n"; ) { set req.backend = frontal-next; } elif ( req.http.X-migration == "c"; ) { set req.backend = frontal; } }