[{"_1":2,"_163":-5,"_164":-5},"loaderData",{"_3":4,"_18":19,"_26":27,"_142":143},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16,"_17":11},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","dockerRebrandTour","routes/_layout",{"_20":-5,"_21":22,"_23":22,"_24":11,"_25":22},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_28":29,"_30":-5,"_31":11,"_32":11,"_33":34,"_35":36,"_37":-5,"_38":11,"_39":40,"_89":-5,"_90":91,"_130":-5,"_131":11,"_132":22,"_133":11,"_134":11,"_135":-5,"_136":11,"_137":-5,"_138":139,"_140":92,"_141":-7},"canonicalUrl","https://hub.docker.com/r/luxifer/readability-api/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","luxifer","reponame","readability-api","cloudBuildSource","isAutobuildsAvailable","repo",{"_41":42,"_43":44,"_46":47,"_48":49,"_50":11,"_51":52,"_53":54,"_55":56,"_58":36,"_33":34,"_59":60,"_61":45,"_62":63,"_64":65,"_66":67,"_68":-5,"_69":63,"_70":71,"_72":11,"_73":34,"_74":75,"_80":22,"_81":82,"_86":34,"_87":88},"categories",[],"content_types",[45],"image","date_registered","2017-05-31T10:45:12.836839Z","description","REST API on top of mozilla/readability","is_private","last_updated","2018-05-09T09:03:39.958137Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[57],"application/vnd.docker.container.image.v1+json","name","pull_count",358,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# Readability REST API\n\nProof of concept of a REST API on top of https://github.com/mozilla/readability\n\n## Server\n\n### Local\n\n```\nnpm install\nnpm start\n```\n\n### Docker\n\n```\ndocker build -t readability-api .\ndocker run -p 4567:4567 readability-api\n```\n\n## Usage\n\nYou can query any path of the app, just pass an `url` query parameter with the _url encoded_ to transform into an article.\n\n```\ncurl localhost:4567/\\?url=http%3A%2F%2Fblog.luxifer.fr%2F2016%2F04%2F04%2Fdeploiement-avec-go-et-ansible-dans-docker%2F\n```\n\nYou will get a `JSON` object like this:\n\n```json\n{\n \"textContent\" : \"\\n \\n La semaine dernière je me suis mis en tête de développer une application afin de centraliser tous les déploiements qu’on fait à Xotelia. J’ai fait le tour et il existe en SaaS ou en Open source des solutions pour ça. Je n’en ai pas trouvé qui fonctionne avec ansible (bien que lors d’un déploiement on puisse installer ce qu’on veut), ou alors trop cher. De plus on ne déploie pas chaque branche, seulement master ou une feature-branch qu’on veut tester sur un environnement différent de la production. C’est la que j’ai décidé de développer notre propre outil de déploiement. À savoir que sur chacun de nos projets nous avons un playbook ansible de déploiement, mais que jusqu’à maintenant on les lance sur nos propres machines. Il me fallait aussi un outil qui me permette de lancer une commande dans hipchat pour déclencher un déploiement.\\n\\nÉtant un grand fan de go et de docker je me suis dit que ça serait pas mal de pouvoir lancer un container docker, dans lequel je lance ansible, et avoir par dessus un petit frontent avec un flux des logs.\\n\\nJ’ai donc commencé a chercher un client docker en go et je suis tombé sur celui-la. Il me semblait qu’il n’y en avait pas à part dans le core de docker ou alors développé par des tiers, mais je me suis trompé. Et qui plus est, très bien documenté et idiomatic.\\n\\nPour le stockage des résultats des builds je me suis tourné vers RethinkDB. Une base de données NoSQL.\\n\\nLe principe de fonctionnement est simple, quand je reçois un événement de déploiement depuis github, je crée un container à partir d’une image qui contient ansible. Dans ce container je clone le dépôt à déployer et je lance le playbook ansible. Je notifie github et hipchat de l’état du déploiement via leurs API respective. Une fois le déploiement terminé je supprime le container.\\n\\nLes embûches\\n\\nJe suis tombé sur plusieurs problèmes lors du développement de ce projet. Tout d’abord il faut savoir que quand dans la console on lance docker run en fait en interne docker va faire un create puis un start.\\n\\nEnsuite il faut que depuis ce container je puisse me connecter en ssh sur les serveurs sur lesquels je vais déployer mes projets, et que je puisse aussi cloner les projets que je vais déployer. Pour ce faire je passe en bind la clé SSH de l’hôte sur lequel est installé deployer vers le root du container comme ceci :\\n\\n\\nimport \\\"github.com/docker/engine-api/types/container\\\"\\n\\nhostConfig := container.HostConfig{\\n Binds: []string{\\\"/home/deployer/.ssh/id_rsa:/root/.ssh/id_rsa\\\"},\\n}\\n\\n\\n\\nJe crée donc mon container avec cette configuration, et je le lance. Comme je ne m’attache pas a celui-ci, tout se passe en background. Donc il faut que j’attende la fin de l’exécution pour récupérer l’exit code.\\n\\n\\nexitCode, err := dockerClient.ContainerWait(ctx, container.ID)\\n\\n\\n\\nJe fais beaucoup d’appels à l’API docker dans la même fonction et donc beaucoup d’erreur à gérer. Comme go permet de retourner plusieurs éléments par fonction, à chaque fois que j’ai une erreur, je la remonte. Il me faut donc un moyen pour arrêter le container en cours à la moindre erreur pour ne pas laisser de déchêts sur la route. C’est la qu’intervient le mot-clé defer. Ce mot-clé permet de définir un comportement qui sera exécuté juste avant le retour d’une fonction. Très pratique pour fermer un fichier ou un io.Reader.\\n\\nOn arrive à la partie la plus intéressante, que j’ai fais en deux fois. La récupération des logs du container une fois l’exécution terminée.\\n\\n\\nimport \\\"github.com/docker/engine-api/types\\\"\\n\\nlogOpts := types.ContainerLogsOptions{\\n ContainerID: container.ID,\\n ShowStdout: true,\\n ShowStderr: true,\\n Follow: true,\\n}\\n\\n\\n\\nCe qui a été exécuté dans le container a peut–être écrit dans la sortie standard ou la sortie d’erreur. Il faut donc que je récupère les deux. C’est la que je suis tombé sur une partir qui manque de documentation. Quand on demande à l’API docker les logs d’un container avec les deux sorties, docker va les multiplexer pour les mettre dans le même io.Reader. Et pour savoir sur quelle sortie correspond quelle ligne, docker va rajouter un header à chaque ligne pour indiquer si ça correspond a stdin, stdout ou stderr.\\n\\nIl faut donc je de démultiplexe ce que me renvoit docker pour avoir un résultat lisible. En fouyant un peu sur github et google, je suis tombé sur ce petit package dans le projet docker. et en particulier la fonction StdCopy. Cette fonction permet de démultiplexer une source (io.Reader) et d’écrire stdout et stderr vers deux io.Writer distinct.\\n\\nEt voilà le tour est joué, j’ai mes logs propre pour chaque déploiement. Sauf que les problèmes ne s’arrêtent pas là. J’ai voulu rajouter de la couleur dans ces logs. Car la commande ansible écrit sur stdout avec différentes couleurs. Pour ce faire il faut que le terminal utilisé supporte la couleur. Il suffit de rajouter ENV TERM xterm dans le Dockerfile du container et ansible va pouvoir afficher de la couleur. Mais ce n’est pas tout, il faut aussi dire à docker d’utiliser un pseudo terminal (PTY) pour le container sinon cette variable d’environnement ne servira a rien. Pour ça il faut modifier la configuration utilisée pour créer le container :\\n\\n\\nimport \\\"github.com/docker/engine-api/types/container\\\"\\n\\nconfig := container.Config{\\n [...]\\n Tty: true,\\n OpenStdin: true,\\n [...]\\n}\\n\\n\\n\\nMais voilà, en rajoutant cette configuration, quand on récuère les logs, docker ne va pas multiplexer les sorties stdout et stderr mais va renvoyer la sortie brut du pseudo terminal. Donc il ne faut plus utiliser stdcopy.StdCopy.\\n\\nComme je l’ai dit plus haut, je voulais avoir une page pour suivre le déploiement et afficher le flux des logs. J’avais deux possibilités pour ça, soit utiliser les Websocket ou Server-sent event. Le premier est en full duplexe, c’est à dire que le serveur et le client peuvent écrire dedans. Le deuxième est dans un sens seulement, le serveur envoi des messages au client. Je suis parti sur Server-sent event, car je n’ai pas besoin que le client (la page web) envoi de message au serveur.\\n\\nCôté serveur, j’utilise un petit package go qui me permet de créer les événements. Ensuite, pour que dans mon handler du flux je puisse renvoyer les logs sous la forme d’événements j’ai créé une struct qui contient un http.ResponseWriter et la quantité de data envoyée. Avec cette struct j’implémente l’interface io.Writer. Je me suis inspiré de ce que j’ai trouvé dans le projet drone :\\n\\n\\nimport (\\n \\\"http\\\"\\n \\\"strconv\\\"\\n\\n \\\"github.com/manucorporat/sse\\\"\\n)\\n\\ntype StreamWriter struct {\\n writer http.ResponseWriter\\n count int\\n}\\n\\nfunc (w *StreamWriter) Write(data []byte) (int, error) {\\n var err = sse.Encode(w.writer, sse.Event{\\n Id: strconv.Itoa(w.count),\\n Event: \\\"message\\\",\\n Data: string(data),\\n })\\n w.writer.(http.Flusher).Flush() // ne pas oublier de flush le ResponseWriter à chaque message pour que le serveur envoi l'événement au client.\\n w.count += len(data)\\n return len(data), err\\n}\\n\\n\\n\\nIl ne me reste plus qu’a copier le io.Reader que me renvoi docker pour les logs dans cet io.Writer. Ne pas oublier de définir le Content-Type à text/event-stream.\\n\\n\\nimport (\\n \\\"http\\\"\\n \\\"io\\\"\\n\\n \\\"github.com/manucorporat/sse\\\"\\n)\\n\\nfunc streamHandler(w http.ResponseWriter, req *http.Request) {\\n w.Header().Set(\\\"Content-Type\\\", sse.ContentType)\\n reader, _ := dockerClient.ContainerLogs(ctx, logOpts)\\n writer := &StreamWriter{w, 0}\\n io.Copy(writer, reader)\\n}\\n\\n\\n\\nJe peux donc récupérer ces événements depuis la page du déploiement et les afficher.\\n\\nRésultat final\\n\\nJ’ai donc maintenant une application qui reçoit les événements de déploiement de github et qui lance le déploiement dans un container docker. Je peux suivre le tout dans une joli page web. Ainsi est né Deployer.\\n\\nLa suite du projet ? Avoir une meilleure gestion des releases, savoir qui a déployer quoi à quel moment, un historique des commits déployés, une intégration avec une application github oauth pour simplifier l’ajout de projet à déployer, une sécurisation du webhook github avec un secret, etc. La liste est longue.\\n\\n \\n \\n \\n Si vous trouvez une typo, n'hésitez pas à forker et éditer cet article. Merci beaucoup !\\n \\n \\n \\n \\n \\n \\n \\n \\n\",\n \"title\" : \"Déploiement avec Go et Ansible dans Docker\",\n \"length\" : 8265,\n \"uri\" : {\n \"spec\" : \"http://blog.luxifer.fr/2016/04/04/deploiement-avec-go-et-ansible-dans-docker/\",\n \"scheme\" : \"http\",\n \"host\" : \"blog.luxifer.fr\",\n \"pathBase\" : \"http://blog.luxifer.fr/2016/04/04/deploiement-avec-go-et-ansible-dans-docker/\",\n \"prePath\" : \"http://blog.luxifer.fr\"\n },\n \"excerpt\" : \"La semaine dernière je me suis mis en tête de développer une application afin de centraliser tous les déploiements qu’on fait à Xotelia. J’ai fait le tour et il existe en SaaS ou en Open source des solutions pour ça. Je n’en ai pas trouvé qui fonctionne avec ansible (bien que lors d’un déploiement on puisse installer ce qu’on veut), ou alors trop cher. De plus on ne déploie pas chaque branche, seulement master ou une feature-branch qu’on veut tester sur un environnement différent de la production. C’est la que j’ai décidé de développer notre propre outil de déploiement. À savoir que sur chacun de nos projets nous avons un playbook ansible de déploiement, mais que jusqu’à maintenant on les lance sur nos propres machines. Il me fallait aussi un outil qui me permette de lancer une commande dans hipchat pour déclencher un déploiement.\",\n \"byline\" : null,\n \"content\" : \"

\\n

La semaine dernière je me suis mis en tête de développer une application afin de centraliser tous les déploiements qu’on fait à Xotelia. J’ai fait le tour et il existe en SaaS ou en Open source des solutions pour ça. Je n’en ai pas trouvé qui fonctionne avec ansible (bien que lors d’un déploiement on puisse installer ce qu’on veut), ou alors trop cher. De plus on ne déploie pas chaque branche, seulement master ou une feature-branch qu’on veut tester sur un environnement différent de la production. C’est la que j’ai décidé de développer notre propre outil de déploiement. À savoir que sur chacun de nos projets nous avons un playbook ansible de déploiement, mais que jusqu’à maintenant on les lance sur nos propres machines. Il me fallait aussi un outil qui me permette de lancer une commande dans hipchat pour déclencher un déploiement.

\\n\\n

Étant un grand fan de go et de docker je me suis dit que ça serait pas mal de pouvoir lancer un container docker, dans lequel je lance ansible, et avoir par dessus un petit frontent avec un flux des logs.

\\n\\n

J’ai donc commencé a chercher un client docker en go et je suis tombé sur celui-la. Il me semblait qu’il n’y en avait pas à part dans le core de docker ou alors développé par des tiers, mais je me suis trompé. Et qui plus est, très bien documenté et idiomatic.

\\n\\n

Pour le stockage des résultats des builds je me suis tourné vers RethinkDB. Une base de données NoSQL.

\\n\\n

Le principe de fonctionnement est simple, quand je reçois un événement de déploiement depuis github, je crée un container à partir d’une image qui contient ansible. Dans ce container je clone le dépôt à déployer et je lance le playbook ansible. Je notifie github et hipchat de l’état du déploiement via leurs API respective. Une fois le déploiement terminé je supprime le container.

\\n\\n

Les embûches

\\n\\n

Je suis tombé sur plusieurs problèmes lors du développement de ce projet. Tout d’abord il faut savoir que quand dans la console on lance docker run en fait en interne docker va faire un create puis un start.

\\n\\n

Ensuite il faut que depuis ce container je puisse me connecter en ssh sur les serveurs sur lesquels je vais déployer mes projets, et que je puisse aussi cloner les projets que je vais déployer. Pour ce faire je passe en bind la clé SSH de l’hôte sur lequel est installé deployer vers le root du container comme ceci :

\\n\\n

\\n

import \\\"github.com/docker/engine-api/types/container\\\"\\n\\nhostConfig := container.HostConfig{\\n    Binds: []string{\\\"/home/deployer/.ssh/id_rsa:/root/.ssh/id_rsa\\\"},\\n}\\n

\\n

\\n\\n

Je crée donc mon container avec cette configuration, et je le lance. Comme je ne m’attache pas a celui-ci, tout se passe en background. Donc il faut que j’attende la fin de l’exécution pour récupérer l’exit code.

\\n\\n

\\n

exitCode, err := dockerClient.ContainerWait(ctx, container.ID)\\n

\\n

\\n\\n

Je fais beaucoup d’appels à l’API docker dans la même fonction et donc beaucoup d’erreur à gérer. Comme go permet de retourner plusieurs éléments par fonction, à chaque fois que j’ai une erreur, je la remonte. Il me faut donc un moyen pour arrêter le container en cours à la moindre erreur pour ne pas laisser de déchêts sur la route. C’est la qu’intervient le mot-clé defer. Ce mot-clé permet de définir un comportement qui sera exécuté juste avant le retour d’une fonction. Très pratique pour fermer un fichier ou un io.Reader.

\\n\\n

On arrive à la partie la plus intéressante, que j’ai fais en deux fois. La récupération des logs du container une fois l’exécution terminée.

\\n\\n

\\n

import \\\"github.com/docker/engine-api/types\\\"\\n\\nlogOpts := types.ContainerLogsOptions{\\n    ContainerID: container.ID,\\n    ShowStdout:  true,\\n    ShowStderr:  true,\\n    Follow:      true,\\n}\\n

\\n

\\n\\n

Ce qui a été exécuté dans le container a peut–être écrit dans la sortie standard ou la sortie d’erreur. Il faut donc que je récupère les deux. C’est la que je suis tombé sur une partir qui manque de documentation. Quand on demande à l’API docker les logs d’un container avec les deux sorties, docker va les multiplexer pour les mettre dans le même io.Reader. Et pour savoir sur quelle sortie correspond quelle ligne, docker va rajouter un header à chaque ligne pour indiquer si ça correspond a stdin, stdout ou stderr.

\\n\\n

Il faut donc je de démultiplexe ce que me renvoit docker pour avoir un résultat lisible. En fouyant un peu sur github et google, je suis tombé sur ce petit package dans le projet docker. et en particulier la fonction StdCopy. Cette fonction permet de démultiplexer une source (io.Reader) et d’écrire stdout et stderr vers deux io.Writer distinct.

\\n\\n

Et voilà le tour est joué, j’ai mes logs propre pour chaque déploiement. Sauf que les problèmes ne s’arrêtent pas là. J’ai voulu rajouter de la couleur dans ces logs. Car la commande ansible écrit sur stdout avec différentes couleurs. Pour ce faire il faut que le terminal utilisé supporte la couleur. Il suffit de rajouter ENV TERM xterm dans le Dockerfile du container et ansible va pouvoir afficher de la couleur. Mais ce n’est pas tout, il faut aussi dire à docker d’utiliser un pseudo terminal (PTY) pour le container sinon cette variable d’environnement ne servira a rien. Pour ça il faut modifier la configuration utilisée pour créer le container :

\\n\\n

\\n

import \\\"github.com/docker/engine-api/types/container\\\"\\n\\nconfig := container.Config{\\n    [...]\\n    Tty:       true,\\n    OpenStdin: true,\\n    [...]\\n}\\n

\\n

\\n\\n

Mais voilà, en rajoutant cette configuration, quand on récuère les logs, docker ne va pas multiplexer les sorties stdout et stderr mais va renvoyer la sortie brut du pseudo terminal. Donc il ne faut plus utiliser stdcopy.StdCopy.

\\n\\n

Comme je l’ai dit plus haut, je voulais avoir une page pour suivre le déploiement et afficher le flux des logs. J’avais deux possibilités pour ça, soit utiliser les Websocket ou Server-sent event. Le premier est en full duplexe, c’est à dire que le serveur et le client peuvent écrire dedans. Le deuxième est dans un sens seulement, le serveur envoi des messages au client. Je suis parti sur Server-sent event, car je n’ai pas besoin que le client (la page web) envoi de message au serveur.

\\n\\n

Côté serveur, j’utilise un petit package go qui me permet de créer les événements. Ensuite, pour que dans mon handler du flux je puisse renvoyer les logs sous la forme d’événements j’ai créé une struct qui contient un http.ResponseWriter et la quantité de data envoyée. Avec cette struct j’implémente l’interface io.Writer. Je me suis inspiré de ce que j’ai trouvé dans le projet drone :

\\n\\n

\\n

import (\\n    \\\"http\\\"\\n    \\\"strconv\\\"\\n\\n    \\\"github.com/manucorporat/sse\\\"\\n)\\n\\ntype StreamWriter struct {\\n    writer http.ResponseWriter\\n    count  int\\n}\\n\\nfunc (w *StreamWriter) Write(data []byte) (int, error) {\\n    var err = sse.Encode(w.writer, sse.Event{\\n        Id:    strconv.Itoa(w.count),\\n        Event: \\\"message\\\",\\n        Data:  stri","has_starred","hub_user","immutable_tags_settings",{"_76":11,"_77":78},"enabled","rules",[79],".*","is_automated","permissions",{"_83":22,"_84":11,"_85":11},"read","write","admin","user","storage_size",570079933,"orgData","recentTags",[92],{"_93":45,"_94":95,"_96":97,"_98":99,"_100":101,"_51":119,"_120":95,"_121":34,"_122":57,"_58":123,"_124":125,"_126":110,"_127":119,"_128":67,"_129":22},"content_type","creator",117056,"full_size",269474358,"id",11421344,"images",[102],{"_103":104,"_105":106,"_107":108,"_109":110,"_111":112,"_113":114,"_115":108,"_116":-5,"_117":97,"_64":67,"_118":-5},"architecture","amd64","digest","sha256:3e03083dca1aa192544d50184c3f36134a4050b764c25009af1d746d67d28ee2","features","","last_pulled","2026-10-21T21:19:25.402043845Z","last_pushed","2018-05-09T09:03:40Z","os","linux","os_features","os_version","size","variant","2018-05-09T09:03:39.667457Z","last_updater","last_updater_username","media_type","latest","repository",1532685,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxRunInCloud","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_39":144,"_151":152,"_138":161,"_162":11},{"_41":145,"_43":146,"_46":47,"_48":49,"_50":11,"_51":52,"_53":54,"_55":147,"_58":36,"_33":34,"_59":60,"_61":45,"_62":63,"_64":65,"_66":67,"_68":-5,"_69":63,"_70":71,"_72":11,"_73":34,"_74":148,"_80":22,"_81":150,"_86":34,"_87":88},[],[45],[57],{"_76":11,"_77":149},[79],{"_83":22,"_84":11,"_85":11},"tags",{"_153":65,"_154":-5,"_155":-5,"_156":157},"count","next","previous","results",[158],{"_93":45,"_94":95,"_96":97,"_98":99,"_100":159,"_51":119,"_120":95,"_121":34,"_122":57,"_58":123,"_124":125,"_126":110,"_127":119,"_128":67,"_129":22},[160],{"_103":104,"_105":106,"_107":108,"_109":110,"_111":112,"_113":114,"_115":108,"_116":-5,"_117":97,"_64":67,"_118":-5},[],"canDeleteTags","actionData","errors"]

luxifer/readability-api

Tags for luxifer/readability-api