woffer 🐧 a écrit 210 commentaires

Encore un point sur YAML, là où je travaille nous utilisons beaucoup Java/Spring Cloud (en plus d'Ansible d'ailleurs).
La configuration de Spring Cloud est faite via le fichier bootstrap.yml qui, comme son extension l'indique, est fichier YAML.

La configuration de Spring Cloud est assez complète (pour ne pas dire assez complexe ;) ) et l'exploitant doit parfois activer des configurations particulières qui ne sont pas livrées par défaut.

Il est parfois nécessaire d'ajouter des configurations supplémentaires qu'il ne connait pas, alors il nous demande le bloc YAML à ajouter.
Et là, ça devient assez pénible car il faut prendre en compte les indentations des lignes précédentes pour que cela fonctionne.
Si l' exploitant l'a modifié (ce qui est normal), alors il ne peut pas copier/coller la section sans tout ré indenter.

Oui, visuellement YAML c'est clair.
Par contre, le modifier sans un éditeur/ide qui t'assiste, à mon humble avis, c'est l'enfer et c'est la majorité des cas pour les exploitants qui accèdent à leurs serveurs en SSH via vi/emacs.

Pour moi, TOML a l'avantage de s'appuyer sur des caractères facilement identifiables pour définir ses structures.
Avec TOML, tu peux indenter si tu souhaites pour clarifier (comme dans les langages de programmation) ta configuration mais ce n'est pas obligatoire.
Donc, tu peux dans les moments critiques (e.g. incident de production en pleine nuit) modifier "à l'arrache"® ton fichier et y revenir plus tard.

Je déteste YAML, bien que super puissant, je trouve ce format très peu pratique en modification.
Je ne sais jamais s'il faut indenter avec plus d'espace ou non, mettre un tiret ou non… Bref c'est la misère pour ma part.

J'imagine le pauvre exploitant seul devant son clavier en pleine nuit dans un incident et avec une modification d'un fichier YAML à effectuer avec son vi.

Je préfère largement utiliser TOML.

Dernier paragraphe:
… je vous conseille d'aler…
Merci

Bonjour,
Je ne connaissais pas comme service, j'ai testé sur une Archlinux (disponible via le dépôt Aur).
Il fonctionne bien.
Merci pour le lien.

Personnellement, moi j'utilise PlantUML depuis des années pour tous mes diagrammes UML. Je peux facilement mettre mes doc UML avec mon code en gestion de conf.

Oui mais le spectacle ne dure qu'une seconde.

A l'inverse, je n'ai pas vu une seule personne dire ce projet critique, il faut le faire en Go ou Rust.

Je peux te dire que dans mon entreprise (grand telco français). L'équipe, dont je fais parti, développe une application critique basée sur une architecture microservices. Et un gros 1/3 des microservices est écrit en Go.
Et pour ma part, c'est un réel bonheur par rapport à Java/spring/spring boot/spring cloud.

Il y a beaucoup moins de tuning à faire, ça fonctionne beaucoup mieux "out of the box" (pas de pool de thread à configurer, consommation mémoire bien plus sobre, déploiement simplifié)

De plus, il y a pleins de fonctionnalités utilisables directement car disponibles sur l'os hôte (e.g. Upgrade d'un microservice sans aucune interruption de service via simple fork et passage du fd du socket au processus fils).
J'ai l'impression de ne pas vivre dans un environnement aseptisé imposé par la jvm, je peux donc facilement tirer avantages des fonctionnalités proposées de l'os sous-jacent (i.e. GNU/Linux pour ma part).

Je serai sur Caen Samedi ;)

T'habites à Fleury ?

Je continue dans les blagues potaches.
OK -> []

Perso, j'aurais choisi Bourg-La-Reine.
OK -> []

Au temps pour moi. OK je sors :)

Merci pour cet article.

on peut en lancer des milliers, réparties automatiquement sur plusieurs threads ou cœurs.

Plutôt que de retenir une limite haute pour le nombre de goroutine, il faut plutôt dire que le nombre de goroutine est rarement le facteur limitant, si c'est goroutine sont en attente par exemple de paquets réseau.

Il y a une vidéo de Rob Pike (que je n'arrive plus à retrouver) où il indique qu'il est courant de voir des serveurs de production chez Google avec des centaines de milliers voire des millions de goroutine.

Ce billet de chez Cloudflare montre que leur serveur DNS (écrit en Go) lance 40k goroutines sans souci particulier autres que des stacks montreuse :)

Personnellement, pour certains cas particuliers, il m'arrive de lancer des centaines de milliers de goroutine sans problème.

La taille minimale de la stack d'une goroutine est de 2ko qui est donc bcp plus petite que celle d'un thread.

Hello,
J'utilise synergy au boulot un PC sous Windows (c'est le client synergy) et un PC sous Linux (c'est le serveur), et malheureusement, cela ne fonctionne pas car les touches venant de synergy ne semblent pas capturées par WinCompose.
Tristesse…

Après une rechercher rapide, je pense que c'est la cause de mon pb :
http://www.freedesktop.org/software/systemd/man/journald.conf.html#RateLimitInterval=

J'essayerai d'ici la fin de semaine et je vous tiens au courant si ça corrige ou pas le pb.

Le problème vient bien du mécanisme d'anti-flooding qui limite à 1000 messages par tranche de 30s (c'est la configuration par défaut).
Il suffit juste de mettre la clef RateLimitBurst à 0 (sous Archlinux) dans le fichier /etc/system/journald.conf et de redémarrer journald. Et cela fonctionne.

Ce n'est donc pas un problème venant de go.

Après une rechercher rapide, je pense que c'est la cause de mon pb :
http://www.freedesktop.org/software/systemd/man/journald.conf.html#RateLimitInterval=

J'essayerai d'ici la fin de semaine et je vous tiens au courant si ça corrige ou pas le pb.

Je viens de demander à la liste de golang nuts https://groups.google.com/forum/#!topic/golang-nuts/0n8EkqakuTc
D'après eux, c'est dû à un mécanisme d'anti-flooding genre 1000 msg par minute.

Savez-vous où je peux trouver ce genre de configuration pour journald/systemd ?

De toutes les façons, je suis gourmand, donc je mangerais dans tous les cas :)

Tous mes trajets maison<->travail sont effectués depuis plus d'un an à vélo (et déjà plus de 5600 km au compteur :) )

Personnellement, j'utilise gb qui fonctionne très bien et surtout ;
- ne modifie pas les chemins d'import des dépendances
- rassemblement toutes tes dépendance dans répertoire vendor avec un fichier manifest

De plus, son approche workspace me convient beaucoup plus que l'approche GOPATH.

À froid comme ça, je dirais c'est pas bien de mixer un même atomic.Value pour des type differents mais ça résoudra pas ton besoin :)
Et si je ne me trompe pas ce n'est pas un probleme de générique puisque je ne vois pas comment ça aurait résolu ton problème ici. si jamais tu avais « var value sync.Value<[]byte> » tu ne pourrais toujours pas changer de type (i.e. passer de []byte à autre chose).
Et dans les 2 cas tu utiliseras 2 variables. Par contre, je suis d'accord avec toi le comportement de atomic.Value est étrange.

Je ne veux pas mixer un même atomic.Value avec des types différents mais montrer que c'est possible de le faire par inadvertance (erreur) et que la compilation ne te remontre pas cette erreur qui te pétera à la figure au runtime…

A mon avis, tu l'as dans l'os :) (ou faut que j'y réfléchisse plus mais je suis fainéant ce soir :) )
Il faut bien comprendre que dans Go, il y a des trucs bien dégoutant mais aussi des trucs super intéressant.
Il faut faire la balance pour voir si ce langage peut répondre à vos problématique/besoins ou pas.

Merci pour ton analyse je la partage sauf pour les génériques où j'avoue je n'ai pas très bien compris ton point.

Effectivement, je n'ai pas été assez clair. Je vais donner un exemple très concret avec atomic.Value qui permet de partager une valeur sans aucun lock entre plusieurs goroutine et de façon performante.

A cause d'un manque de générique, nous sommes obligés de passer interface{} (qui est le java.lang.Object de go) pour enregistrer/récupérer une valeur.
sync.Value.Store est obligé de vérifier si le type est identique à celui enregistrer la première fois et te lancera un panic (au runtime) si ce n'est pas le même type (voir cet exemple)

J'aurai préféré avoir une truc comme ci-dessous (et d'autant plus si cela ne reste pas au runtime comme Java) :

var value sync.Value<[]byte>

Pour go generate, cela reste pour ma part (c'est mon avis et c'est normal qu'il ne soit pas partagé :) ) une bidouille si tu l'utilises pour combler le manque de generics du langage.

les goroutines engendrent facilement des "data race" etc… On est vite refroidi !

Ah oui, j'oubliai le détecteur de race condition. Pour en avoir détecter plusieurs, c'est vraiment un outil qui est très utile.
Pour l'activer, il suffit de compiler le binaire avec l'option -race.
Le détecteur de race condition remonte uniquement des vrais positifs (il peut donc en laisser passer), donc ils faut toujours prendre au sérieux les alertes remontées (elles sont remontées dans la STDERR via une stack trace des deux goroutine impliquées et qd elles ont été créées).

Autre point, le fait de l'activer, cela va consommer en terme de mémoire et d'usage CPU. Donc, on :
- doit passer tous ses tests unitaire/microbenching avec le détecteur activé et cela dès le début du projet.
- peut imaginer l'activer sur une partie de votre cluster.

Je n'ai jamais vérifié comment fonctionne exactement go get mais je pense que d'enlever les imports non utilisés doit aussi faciliter la tâche de l'analyseur pour descendre les sources et ses dépendances.

Jamais testé.
Mais je pense que les structures implémentant la fonction des deux interfaces peuvent être vue comme l'une ou l'autre interface.