wilk a écrit 1159 commentaires

A mettre en rapport avec la notion de cloud souverain sous licences fermées :

https://linuxfr.org/users/wilk/journaux/le-cloud-souverain-francoogle

https://blog.scaleway.com/fr/doctrine-cloud-au-centre-un-pas-de-geant-pour-la-modernisation-numerique-de-letat-et-des-interrogations/

Le problème restant que 5 ans plus tard le retard aura été d'autant plus creusé que l'on aura subventionné ceux qui creusent !

Le problème de la sobriété c'est surtout le fait que le terme soit péjoratif.
Il y a un livre "âge de pierre, âge d'abondance" qui montre que « Si l'homme primitif ne rentabilise pas son activité, c'est non pas parce qu'il ne sait pas le faire, mais parce qu'il n'en a pas envie. ».
Par exemple à cette époque de nomades à pied le fait de posséder quelque chose est tout de suite une contrainte car il faut le transporter. J'aime bien retrouver cette valeur des choses en randonnée.
En informatique j'aime bien aussi quand j'élimine du code, une dépendance, une couche intermédiaire…
La sobriété pourrait vraiment être vue comme un atout plutôt qu'une contrainte.

Clairement le problème avec ces technos c'est de debuger le client "ça marche pas" alors que sur notre poste ça marche très bien.

La vidéo de la conférence :

https://twitter.com/i/broadcasts/1ynJOBwXEMlGR

C'est du PostgreSQL ou MySQL. On peut faire exactement la même chose chez soit ou chez OVH mais c'est un sacré boulot et on se rend compte que ce que l'on paye ça n'est pas seulement la probabilité que ça prenne feu ou pas mais le service fourni tout autour au cas où ça prendrait feu à un endroit.

Je ne comprends trop l'intérêt de calculer en terme de datacenter. Autant qu'un datacenter parte en fumé c'est assez rare, autant qu'une machine ou encore mieux qu'une vm parte en fumée ça arrive tous les jours. Et pour l'utilisateur c'est ce qui compte, peu importe que les serveurs d'à côté partent en fumée aussi, il en suffit d'un et que ce soit le notre…
L'article met bien l'accent sur le fait de gérer plus ou moins soit-même la redondance.
Il me semble que c'est à ce niveau qu'il faut faire des comparaisons et quitter ou non OVH. C'est à dire dans les services disponibles sur l'infrastructure proposée pour pouvoir gérer cette redondance.
Hors c'est bien à ce niveau que le leader distance complètement les suivants, ça me semble même sans commune mesure.
Eventuellement on peut palier à ça avec des compétences internes, mais on ne compare plus du tout la même chose et encore moins le coût final.
En tout cas bravo à Cozy pour avoir réussi cet exploit, et on peut préciser "en particulier chez OVH" ! Chez l'autre il n'y aurait eu aucun mérite !

edit: pour ceux qui voudraient se rendre compte, regardez les possibilités d'une BDD Aurora par ex, et imaginez faire la même chose chez OVH (ou autres)…

Je ne peux pas l'expliquer pour le moment, je l'ai trouvé par tâtonnement (je me suis fait un défi de passer de websocket à sse dans la journée en prod !)… Ce qui a été délicat c'est qu'en local je testais en accès direct à mon application, et en prod par Nginx. Je n'ai pas encore testé si ça passe par un load balancer type ELB…

Maintenir un version web et une version desktop risque d'être assez lourd non ? Est-ce que l'objectif à terme est de n'en conserver qu'une ?

Ton article m'a donné envie d'essayer les SSE pour remplacer un système de websocket que je n'utilisais que dans un sens (serveur vers client et classique dans l'autre sens).

Il y a quelques années pour apprendre le langage Go j'avais réécris un système de websocket en Python (pour un jeu de scrabble) qui fonctionnait mais il m'était impossible de faire évoluer ce code spaghetti. Le résultat était déjà plutôt concluant, mais plat de pâte tout de même.
Du coup je viens de le réécrire avec SSE.
Première chose plus besoin de dépendre d'une lib externe (gorilla.websocket) et pas mal de code de tuyauterie à supprimer autant côté serveur que client.
Ensuite le côté sens unique de SSE correspond exactement au fonctionnement des channels en Go. Ce qui fait que mon dispatcher fonctionne aussi bien avec des clients distants (un client SSE = un channel) ou des goroutines (par exemple un robot joueur).
En Python j'avais séparé mon appli en plusieurs services (les robots à part) qui communiquaient par websocket, et la du coup je les ais réintégrés dans la même application et ils communiquent par channel sans changer grand chose au code, ça me laisse le choix.
Bref, les SSE sont un excellent moyen de familiariser aux concepts de channel en Go.

A part ça, j'ai eu quelques surprises niveau Nginx.
Dans un premier temps je me suis dit, avec http ça va aller tout seul. Effectivement ça semble fonctionner tout seul.
Mais en regardant les logs je me suis aperçu que la connexion était coupée toutes les minutes.
J'ai rajouté ça :

proxy_buffering off;
proxy_cache off;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;

Tout allait bien jusqu'à ce que des joueurs se plaignent que ça rame, ce que n'avais pas constaté dans mes essais. Après enquête je comprends que c'est quand on ouvre plusieurs onglets. J'essaye d'ouvrir une dizaine d'onglets, l'ordinateur se met à souffler comme un malade et les derniers onglets tournent sans rien afficher. Systématiquement à partir du sixième ! J'essaye un autre navigateur, pareil, 6 onglets max.
C'est finalement une limitation http, je trouve enfin qu'il faut passer en http2

server {
listen 443 ssl http2;

Tout semble rentrer dans l'ordre.

Bilan, les SSE en Go c'est un régal, je garde.

Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.

Je pense que tu as bien compris le but de la manœuvre. Je fais un petit retour d'xp dans un autre fil, ça répondra peut-être à tes questions.

A propos du code, un truc qui m'a perturbé quand j'ai regardé (y a longtemps), c'est les noms des tables et champs PostgreSQL en majuscule, ça oblige à les mettre entre guillemet ce qui n'est pas toujours pratique… D'où vient cette idée ?

J'utilise https://github.com/kopia/kopia ça permet à la fois d'envoyer sur S3 en même temps c'est dédupliqué, compressé, incrémental etc… Sinon en rclone marche très bien aussi.

Clairement je ne vois pas du tout comment les "petits" (pas si petits déjà !) peuvent y arriver, surtout qu'ils essayent de jouer sur les prix et du coup se privent de pouvoir investir ou faire de la qualité, c'est le cercle vicieux…
Pas évident dans ce contexte d'être clair et sans baratin. Je trouve que Hetzner le fait assez bien, il ne propose pas ce qu'il ne sait pas encore faire. Tandis que les deux nôtres peinent à essayer de faire semblant que…
En tout cas c'est mal barré car la barre est de plus en plus haute et monte plus vite que ceux qui essayent de suivre.

Je cite :

Actuellement, les données de notre service d'Object Storage ne sont pas redondées sur différentes AZ ou même régions.
Suite aux différentes demandes clients, sur notre plateforme "Feature Request"
(https://feature-request.scaleway.com/posts/110/object-storage-replication-between-many-regions), cette fonctionnalité va être implémentée, mais je ne peux
vous communiquer d'ETA.

Inutile de demander pour les bases de données avec l'option HA, c'est écrit "Nous nous assurons également que vos instances fonctionnent sur des hyperviseurs différents", donc c'est clairement pas séparé physiquement.

Chez l'autre quand on crée une BDD il demande : c'est pour des tests ? Non, alors activez tout de suite la réplication multi AZ. Et si vous êtes sérieux cochez la case réplication à l'autre bout de l'Europe en plus (c'est assez récent par contre).

Dans sa dernière vidéo Octave prétend qu'il va faire évoluer le milieu industriel dans son ensemble… Non, mais s'il te plait laisse le milieu industriel en dehors !

Bon, le chef de niveau 2 a répondu, chez Scaleway les objets de type S3 c'est S3 dans le même panier bien au chaud. Il m'invite à suggérer la fiture sur le forum ad hoc et en attendant à cloner mes objets moi-même.

On est tellement à des années lumière de l'autre à 3 lettres… pfiouuu…

Du coup on déclare quoi ? Que les données des clients qui étaient dans le cloud sont maintenant dans les nuages (mais là c'est sûr elles vont y rester) ?

Suite à cet article :
https://blog.scaleway.com/how-we-protect-your-data/

Je viens de demander chez Scaleway si le stockage objet est répliqué 3x sur des datacenters éloignés géographiquement et à quelle distance.
Réponse du support : "Je vérifie auprès de nos techniciens de niveau 2."

…Chef chef, on ne stocke quand même pas les objets 3x au même endroit hein ? Je lui répond quoi au client ?

Jamais vu une option payante pour vérification des sauvegardes…

Prochain drame psychologique : nous rappelons qu'il était de la responsabilité du client de vérifier les sauvegardes.

Les mails (ou autres messageries directes) remplacent de plus en plus souvent des conversations et des réunions en chair et en os. Hors on n'enregistre pas ces conversations pour les ressortir "t'avais dit ça…". Ce qui ressort de ces conversations éventuellement on en fait un résumé que l'on classe dans le projet ad hoc.
Je fais pareil avec les mails, je les empile sur le bureau tant qu'ils ne sont pas traités, certains je les range dans un carton, la plupart finissent à la poubelle à plus ou moins brève échéance. Bref, j'en conserve très peu et pas longtemps.
Du coup peu importe le client mail. J'utilise vim comme un crayon, pour tout. Et mutt comme un vulgaire bureau avec quelques tiroirs.

Merci pour ces explications.
Un truc qui m'a aidé à comprendre et utiliser Git (j'utilisais plutôt Mercurial) c'est un tuto où on écrit un proto en Python :
https://www.leshenko.net/p/ugit/
J'adorerai voir la même chose avec Pijul !

D'où vient le fait que l'implémentation à l'air si longue ?
Je me souviens qu'à l'époque ou Git est né, mercurial, arch, tla, bazaar… il ne semblait pas si difficile d'implémenter de nouvelles idées de dvcs.
Est-ce le principe en lui-même où ça n'a rien à voir ?
Je ne pense quand même pas non plus que ça vienne de Rust ?

Moi je serai à ta place j'aurai donné mon numéro de portable.

-Merci de bien vouloir me donner votre numéro de portable.
-Impossible je l'ai déjà donné à Stripe hier (je vais quand même voir s'ils ne peuvent pas me le rendre).