Avec les "Workers" qu'on peut exécuter directement chez le CDN, on
peut faire un mix.
Par exemple :
- Un worker qui vérifie chaque upstream…
- et qui génère un fichier de configuration avec au moins un upstream
qui fonctionne : { api_host: "https://api1.example.com"; }.
L'application Javascript télécharge ce fichier de configuration et
utilise ce hostname pour toutes les requêtes d'API
- ou juste une page minimale qui permet de charger le javascript
depuis le bon upstream : <html><script
src='https://www1.example.com/boot.js' /></html>
Ça permet de mettre un peu de logique dans le "worker" (optimisation
géographique, vérifications précises de l'état de l'upstream), sans
tomber dans l’extrême et l'utilisation d'IP.
On Thu, Mar 5, 2020 at 2:01 PM Raphael Mazelier <[email protected]> wrote:
>
> Je crois que l'on a mélangé un peu plusieurs discussions mais au final
> on en revient toujours au même débat : ou placer la redondance ? coté
> infra ou coté applicatif ?
>
> La redondance infrastructure est d'une certaine manière plus facile à
> réaliser mais moins efficace ou plus dure à mettre au point.
>
> La redondance coté client est sans doute très intéressante si l'on
> accepte de passer du temps coté client. C'est vrai pour qu'une page web,
> on peut sans doute trouver des solutions intéressantes avec les
> possibilités de bricoler en js actuelle.
>
> Une squelette statique délivré via un CDN (avec un peu de cache), du js
> qui fait des checks sur les différents serveurs de ressources,
> construction de la page après. Ça doit se faire.
>
> Même pas besoin de DoH en fait. D'ailleurs DoH coté client js, why not,
> mais après il faudrait pouvoir faire comprendre au browser qu'il doit
> utiliser ce qui vient d’être résolu pour le reste, ce qui est peut être
> possible mais je ne sais pas comment faire.
>
> Ca serait intéressant de faire un POC la dessus.
>
> --
>
> Raphael Mazelier
>
> On 05/03/2020 00:50, Jonathan Leroy - Inikup via frnog wrote:
>
> > Le mer. 4 mars 2020 à 23:04, Philippe Bourcier <[email protected]> a écrit
> > :
> >> Utiliser des cookies, en 2020 ? ... :)
> >> Web Storage, JWT, sessionless... ?
> > Web Storage n'est pas fait pour stocker des infos de session
> > (n'importe quel script tiers sur la page peut accéder à son contenu).
> > JWT est une horreur à éviter à tout prix
> > (https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid).
> > Dans les faits le sessionless quasiment impossible pour une app web
> > sans utiliser JWT.
> >
> > Donc oui, les cookies sont nécessaires en 2020. :)
> >
> > Pour répondre à la question initiale :
> > - Vraie solution propre : si tu as besoin d'un failover sur un DC
> > secondaire, c'est que ton business est critique et que toute coupure
> > te coûte une somme non négligeable. Donc il te faut demander un /24
> > (ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en
> > BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de
> > métier (ou à défaut, tu peux changer d'hébergeur).
> >
> > - Solution pas trop sale alternative : Cloudflare propose un LB dans
> > le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs
> > de ton pool toutes les 15 seconds et il y a même une API.
> >
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
--
Théophile Helleboid
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
