Il évalue l'image docker. Techniquement ces binaires n'ont besoin que du noyau linux avec une config réseau mais absolument rien d'autre.
Après j'ai été moinsé mais toujours pas compris dans quel monde tordu on peut appelé un tel programme un serveur http.
Ça répond à un client http en respectant le protocole, c'est un serveur http point. Ils n'ont d'intérêt que pour l'exercice oui, mais ça ne change rien à ce qu'ils sont.
Non. Il ne respecte pas le protocole. Si je lui demande un HEAD par exemple il est ko.
Voilà. Un protocole c'est un peu plus qu'un Hello world. D'où mon incompréhension du moinsage. C'est de la communication, pas juste réagir bêtement et mécaniquement (cette phrase a un double-sens saurez-vous le percevoir ?)
Sans rancune hein ! Mais on me vend du rêve. Bêtement je clique xD (après y'a tout plein de choses qui m'ont gêné, le distingo entre libc, syscall et api tierce - socket entre autres - pas très bien fait, la comparaison de programmes qui n'ont pas du tout le même niveau d'exigence et donc embarquent pas la même chose - forcément si tu inclus strerror dans le C ça va faire beaucoup de chaînes de caractères à garder dans le binaire… rien à voir avec la langage lui-même).
Non. Il ne respecte pas le protocole. Si je lui demande un HEAD par exemple il est ko.
Il respecte le protocole de l'énoncé :
il faut qu'elle soit capable de répondre en HTTP une OK 200, sinon le déploiement est considéré comme échoué
Tout le reste osef. Je pense qu'environ aucun serveur HTTP implémente toutes les RFCs de manière complète. Dans ce cas c'est un peu extrême mais le cas d'utilisation est très spécifique. De plus c'est bien expliqué que c'est pour s'amuser, c'est pas pour de la prod et ça a un but pédagogique, y compris pour la personne qui a écrit l'article.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Non. Il ne respecte pas le protocole. Si je lui demande un HEAD par exemple il est ko.
Le protocole n'oblige pas à l'implémenter et je suis à peut près sûr qu'au moins certains se comportent bien en renvoyant simplement une erreur.
Mais on me vend du rêve.
Non il ne te vend rien. Les hypothèses de l'exercice sont clairement énoncé dès le départ.
après y'a tout plein de choses qui m'ont gêné,
Mais n'hésite pas à avoir un commentaire pertinent. Ça pourrait t'éviter de te plaindre des notes parce que tu as imaginé qu'on t'avais vendu je ne sais quoi
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Donc, non, techniquement c'est pas « un serveur http point » ni même une tentative de l'être. Ça répond à un besoin très spécifique qui utilise une toute petite partie de la spec HTTP. Mais c'est clairement expliqué au début du post et je suis d'accord que chouiner que c'est pas conforme c'est être complètement à côté de la plaque.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Effectivement il y a une entorse au standard est-ce que ça suffit pour ne pas être une server HTTP ? Pas de mon point de vu.
Je n'ai aucun doute que les équipes de clever cloud peuvent retirer la sonde si ce n'est pas une fonctionnalité disponible de base.
Et surtout ça colporte l'idée de ce genre de sonde doivent simplement répondre à leurs requêtes alors que l'intérêt c'est de vérifier que le logiciel fonctionne. C'est une erreur fréquente d'avoir des url de vie qui ne vérifient rien et c'est assez problématique quant à la fiabilité des déploiements. J'ai bien compris que ce n'est pas de la prod, mais ça n'empêche pas d'une part de le faire remarquer et d'autre part mais sans être de la prod avoir un état fiable de son déploiement c'est toujours plus agréable.
Sinon c'est vraiment sympa ça me donnerait envi de jouer un peu avec chacun pour voir s'il n'y aurait pas des fonctionnalités qui expliquent les différences de tailles (en performance, en comportements en cas non prévu etc).
Posté par Krunch (site web personnel) .
Évalué à 4 (+2/-0).
Dernière modification le 01 novembre 2024 à 10:49.
l'idée de ce genre de sonde doivent simplement répondre à leurs requêtes alors que l'intérêt c'est de vérifier que le logiciel fonctionne
Je pense que c'est un peu plus subtile que ça. Je ne suis pas familier avec Clever Cloud en particulier mais je pense qu'une sonde de « liveness » se doit de vérifier que le service fonctionne indépendamment de toutes dépendances. Si une dépendance dure casse le service mais que le service lui même fait de son mieux, il me semble légitime pour la sonde de répondre "OK". Sinon tu te retrouves à redémarrer le service en boucle, ce qui ne fait qu'intensifier le problème.
On peut (et devrait) avoir des sondes plus poussées qui testent toutes les fonctionnalités. Mais, si un humain est nécessaire pour diagnostiquer une sonde fautive, elle ne devrait pas pouvoir déclencher un redémarrage automatique.
Par exemple : je monte un clone de linuxfr avec le frontend dans un container et la base de données dans un autre. Si la base de données tombe, il est contre-productif de redémarrer le frontend. Donc la sonde de « liveness » du frontend doit dire "OK" même si la base de données est par terre et qu'environ rien ne fonctionne. Le frontend devrait bravement rester debout à servir des erreurs 500 aux utilisateur en attendant que la base de données revienne.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ça dépend du comportement que tu souhaite avoir, mais non une sonde ne devrait pas vérifier toutes les fonctionnalités même si c'était faisable ça n'est pas enviable. La sonde doit pouvoir détecter les problèmes qui nécessitent un redémarrage et peut permettre de rendre clair le fait qu'un service est down.
Mais bref faut tester quelque chose sinon virer la sonde
Si j'ai bien compris, ton application ne fait pas du HTTP mais doit renvoyer un 200 OK quand l'infra d'hébergement lui demande pour qu'elle ne la considère pas comme morte et la remplace.
Et tu veux le faire avec le moins de poids possible. C'est très arbitraire ; Pourquoi pas la sécurité, la robustesse, la latence, le débit, l'empreinte mémoire, etc.
Et tu te dis quel langage produite le plus petit binaire.
Mais l'application en elle même fait déjà de la socket et est écrite dans un certain langage. Donc la méthode la plus simple aurait été d'intégrer cette fonction dans la base de code existante, non ?
Pourquoi pas la sécurité, la robustesse, la latence, le débit, l'empreinte mémoire, etc.
Pour ce qui est de la sécurité, normalement tu te débrouille pour que l'appel ne puisse être fait que par l'orchestrateur et pour le débit l'orchestrateur ne fait qu'un appel toutes les quelques secondes.
J'avais écrit un bout de code similaire pour servir des 503 pendant les temps des maintenances de mon application.
Hors libc, ça pèse 17ko, sans optimisations particulières.
# mouai...
Posté par Nicolas . Évalué à -9 (+0/-9).
Difficile de parler de serveur http pour ce qui est à peine un peu plus évolué qu'un Hello world.
Sinon on doit pouvoir faire encore plus fort avec un simple script bash derrière un xinetd.
[^] # Re: mouai...
Posté par Krunch (site web personnel) . Évalué à 5 (+3/-0).
Tu me dira quand t'aura trouvé un binaire Bash qui fait moins de 20 Ko.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0). Dernière modification le 01 novembre 2024 à 01:38.
Sans compter qu'il dépends des binaires des lignes de commandes que tu va installer pour tourner…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: mouai...
Posté par Nicolas . Évalué à -7 (+0/-7).
Rust, go, vlang sont données pour 200-600 ko…
Après j'ai été moinsé mais toujours pas compris dans quel monde tordu on peut appelé un tel programme un serveur http.
[^] # Re: mouai...
Posté par barmic 🦦 . Évalué à 8 (+6/-0).
Il évalue l'image docker. Techniquement ces binaires n'ont besoin que du noyau linux avec une config réseau mais absolument rien d'autre.
Ça répond à un client http en respectant le protocole, c'est un serveur http point. Ils n'ont d'intérêt que pour l'exercice oui, mais ça ne change rien à ce qu'ils sont.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouai...
Posté par Nicolas . Évalué à -5 (+2/-7).
Non. Il ne respecte pas le protocole. Si je lui demande un HEAD par exemple il est ko.
Voilà. Un protocole c'est un peu plus qu'un Hello world. D'où mon incompréhension du moinsage. C'est de la communication, pas juste réagir bêtement et mécaniquement (cette phrase a un double-sens saurez-vous le percevoir ?)
Sans rancune hein ! Mais on me vend du rêve. Bêtement je clique xD (après y'a tout plein de choses qui m'ont gêné, le distingo entre libc, syscall et api tierce - socket entre autres - pas très bien fait, la comparaison de programmes qui n'ont pas du tout le même niveau d'exigence et donc embarquent pas la même chose - forcément si tu inclus strerror dans le C ça va faire beaucoup de chaînes de caractères à garder dans le binaire… rien à voir avec la langage lui-même).
[^] # Re: mouai...
Posté par Krunch (site web personnel) . Évalué à 7 (+6/-1).
Il respecte le protocole de l'énoncé :
Tout le reste osef. Je pense qu'environ aucun serveur HTTP implémente toutes les RFCs de manière complète. Dans ce cas c'est un peu extrême mais le cas d'utilisation est très spécifique. De plus c'est bien expliqué que c'est pour s'amuser, c'est pas pour de la prod et ça a un but pédagogique, y compris pour la personne qui a écrit l'article.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par barmic 🦦 . Évalué à 6 (+5/-1).
Le protocole n'oblige pas à l'implémenter et je suis à peut près sûr qu'au moins certains se comportent bien en renvoyant simplement une erreur.
Non il ne te vend rien. Les hypothèses de l'exercice sont clairement énoncé dès le départ.
Mais n'hésite pas à avoir un commentaire pertinent. Ça pourrait t'éviter de te plaindre des notes parce que tu as imaginé qu'on t'avais vendu je ne sais quoi
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouai...
Posté par Krunch (site web personnel) . Évalué à 4 (+3/-1).
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Donc, non, techniquement c'est pas « un serveur http point » ni même une tentative de l'être. Ça répond à un besoin très spécifique qui utilise une toute petite partie de la spec HTTP. Mais c'est clairement expliqué au début du post et je suis d'accord que chouiner que c'est pas conforme c'est être complètement à côté de la plaque.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par Nicolas . Évalué à -8 (+1/-9).
Bah changez le titre surtout. Plutôt que d'être insultant. Linuxfr n'a pas changé d'un chouilla à ce que je vois…
[^] # Re: mouai...
Posté par Graveen . Évalué à 6 (+4/-0).
le problème c'est toi, ils sont assez gentils pour te l'expliquer calmement, mais tu ne comprends visiblement pas :)
[^] # Re: mouai...
Posté par barmic 🦦 . Évalué à 3 (+2/-1).
Effectivement il y a une entorse au standard est-ce que ça suffit pour ne pas être une server HTTP ? Pas de mon point de vu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouai...
Posté par Krunch (site web personnel) . Évalué à 5 (+4/-1).
Le golf est un hobby valide. Critiquer le hobby des autres sans même essayer de participer me semble moins valide.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Super avec un mais
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Je n'ai aucun doute que les équipes de clever cloud peuvent retirer la sonde si ce n'est pas une fonctionnalité disponible de base.
Et surtout ça colporte l'idée de ce genre de sonde doivent simplement répondre à leurs requêtes alors que l'intérêt c'est de vérifier que le logiciel fonctionne. C'est une erreur fréquente d'avoir des url de vie qui ne vérifient rien et c'est assez problématique quant à la fiabilité des déploiements. J'ai bien compris que ce n'est pas de la prod, mais ça n'empêche pas d'une part de le faire remarquer et d'autre part mais sans être de la prod avoir un état fiable de son déploiement c'est toujours plus agréable.
Sinon c'est vraiment sympa ça me donnerait envi de jouer un peu avec chacun pour voir s'il n'y aurait pas des fonctionnalités qui expliquent les différences de tailles (en performance, en comportements en cas non prévu etc).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Super avec un mais
Posté par Krunch (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 01 novembre 2024 à 10:49.
Je pense que c'est un peu plus subtile que ça. Je ne suis pas familier avec Clever Cloud en particulier mais je pense qu'une sonde de « liveness » se doit de vérifier que le service fonctionne indépendamment de toutes dépendances. Si une dépendance dure casse le service mais que le service lui même fait de son mieux, il me semble légitime pour la sonde de répondre "OK". Sinon tu te retrouves à redémarrer le service en boucle, ce qui ne fait qu'intensifier le problème.
On peut (et devrait) avoir des sondes plus poussées qui testent toutes les fonctionnalités. Mais, si un humain est nécessaire pour diagnostiquer une sonde fautive, elle ne devrait pas pouvoir déclencher un redémarrage automatique.
Par exemple : je monte un clone de linuxfr avec le frontend dans un container et la base de données dans un autre. Si la base de données tombe, il est contre-productif de redémarrer le frontend. Donc la sonde de « liveness » du frontend doit dire "OK" même si la base de données est par terre et qu'environ rien ne fonctionne. Le frontend devrait bravement rester debout à servir des erreurs 500 aux utilisateur en attendant que la base de données revienne.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Super avec un mais
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Ça dépend du comportement que tu souhaite avoir, mais non une sonde ne devrait pas vérifier toutes les fonctionnalités même si c'était faisable ça n'est pas enviable. La sonde doit pouvoir détecter les problèmes qui nécessitent un redémarrage et peut permettre de rendre clair le fait qu'un service est down.
Mais bref faut tester quelque chose sinon virer la sonde
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Super avec un mais
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Dans ce genre de cas la base de données est censée avoir sa propre sonde.
# architecture
Posté par steph1978 . Évalué à 3 (+1/-0).
Si j'ai bien compris, ton application ne fait pas du HTTP mais doit renvoyer un
200 OKquand l'infra d'hébergement lui demande pour qu'elle ne la considère pas comme morte et la remplace.Et tu veux le faire avec le moins de poids possible. C'est très arbitraire ; Pourquoi pas la sécurité, la robustesse, la latence, le débit, l'empreinte mémoire, etc.
Et tu te dis quel langage produite le plus petit binaire.
Mais l'application en elle même fait déjà de la socket et est écrite dans un certain langage. Donc la méthode la plus simple aurait été d'intégrer cette fonction dans la base de code existante, non ?
[^] # Re: architecture
Posté par Thomas Douillard . Évalué à 5 (+3/-1).
Si c'est juste un défi technique pour le sport, il n'y a pas de base de code existante ?
[^] # Re: architecture
Posté par barmic 🦦 . Évalué à 3 (+2/-1).
Pour ce qui est de la sécurité, normalement tu te débrouille pour que l'appel ne puisse être fait que par l'orchestrateur et pour le débit l'orchestrateur ne fait qu'un appel toutes les quelques secondes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Intéressant !
Posté par Graveen . Évalué à 5 (+3/-0).
Les comparaisons sont pertinentes, didactiques et l'ensemble est sympa à lire !
# 17ko - C
Posté par steph1978 . Évalué à 4 (+2/-0).
J'avais écrit un bout de code similaire pour servir des 503 pendant les temps des maintenances de mon application.
Hors libc, ça pèse 17ko, sans optimisations particulières.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.