Yes le fameux compute@edge. Très pratique mais pas très donné pour le
moment.
--
Raphael Mazelier
On 05/03/2020 12:43, Théophile Helleboid wrote:
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 <r...@futomaki.net> 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 <phili...@frnog.org> 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/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
