index.html (14816B)
1 <!DOCTYPE html> 2 3 <html lang="fr"> 4 5 <head> 6 <meta charset="utf-8"> 7 <meta http-equiv="content-type" content="text/html; charset=utf-8" /> 8 9 <link rel="start" href="https://vincent.demeester.fr" /> 10 11 <title>Vincent Demeester</title> 12 <link rel="canonical" href="https://vincent.demeester.fr/posts/2015-07-31-config-managment-intro/"> 13 <link href="https://vincent.demeester.fr/index.xml" rel="alternate" type="application/rss+xml" title="Vincent Demeester" /> 14 15 <link rel="openid.server" href="https://indieauth.com/openid" /> 16 <link rel="openid.delegate" href="http://vincent.demeester.fr/" /> 17 <link rel="shortcut icon" type="image/x-icon" href="favicon.ico"> 18 19 <link rel="stylesheet" href="/css/screen.css" type="text/css" /> 20 <link rel="stylesheet" href="/css/sbrain.css" type="text/css" /> 21 <link rel="stylesheet" href="/css/syntax.css" type="text/css" /> 22 23 </head> 24 25 <body lang="fr"/> 26 27 28 29 30 31 32 <div id="main-container"> 33 <div id="page"> 34 <article class="post"> 35 <header> 36 <h1 class="emphnext">Gestion de configuration : introduction</h1><a href='https://vincent.demeester.fr/posts/2015-07-31-config-managment-intro/'></a> 37 <address class="signature"> 38 <span class="date">Fri, 31 July, 2015</span> 39 <span class="words">(1300 Words)</span> 40 </address> 41 <ul class="tag_box inline"> 42 43 <li class="category"><a href="/categories/#configurations">configurations</a></li> 44 45 46 47 48 49 <li class="tag tag-git"><a href="/tags/#git">git<span>3</span></a></li> 50 51 52 <li class="tag tag-myrepos"><a href="/tags/#myrepos">myrepos<span>1</span></a></li> 53 54 55 <li class="tag tag-mr"><a href="/tags/#mr">mr<span>1</span></a></li> 56 57 58 <li class="tag tag-vcsh"><a href="/tags/#vcsh">vcsh<span>1</span></a></li> 59 60 61 <li class="tag tag-linux"><a href="/tags/#linux">linux<span>4</span></a></li> 62 63 64 <li class="tag tag-posix"><a href="/tags/#posix">posix<span>1</span></a></li> 65 66 67 <li class="tag tag-shell"><a href="/tags/#shell">shell<span>2</span></a></li> 68 69 70 <li class="tag tag-sharing"><a href="/tags/#sharing">sharing<span>1</span></a></li> 71 72 <br/> 73 74 </ul> 75 </header> 76 77 78 79 <p> 80 Cela doit faire au moins 2 ans que je souhaite partager la façon dont 81 je gère mes configurations (en anglais <i>dotfiles</i>). Comme j'ai 82 longtemps repoussé l'échéance, probablement de peur d'avoir un roman à 83 écrire, je vais en faire une série de petits billets de blog dont 84 celui-ci est l'introduction. Nous y aborderons donc mon besoin, et mes 85 choix. 86 </p> 87 88 <div id="outline-container-sec-1" class="outline-2"> 89 <h2 id="sec-1">Besoin(s)</h2> 90 <div class="outline-text-2" id="text-1"> 91 <p> 92 En bon <b>geek</b> que je suis, je suis fan des <i>dotfiles</i>. Les <i>dotfiles</i> 93 — fichiers de configurations — sont de petits fichiers, habituellement 94 dans notre dossier personnel (votre <i>$HOME</i>), qui nous permettent de 95 paramétrer et personnaliser nos outils de tous les jours. C'est 96 principalement vrai pour des outils en ligne de commande — et ça tombe 97 bien, j'adore — mais pas uniquement limité à ces derniers. 98 </p> 99 100 <p> 101 Je vais faire un très petit aparté sur le pourquoi de cette 102 personnalisation : 103 </p> 104 105 <ul class="org-ul"> 106 <li>C'est <b>fun</b> à faire et c'est relativement important de mon point de vue. 107 </li> 108 <li>C'est <b>éducatif</b> ou formateur ; on lit les documentations de nos 109 outils, leurs fonctionnalités un peu cachées. On va souvent découvrir 110 un peu la philosophie dans laquelle l'outil a été créé. C'est en 111 mettant les <i>mains dans le cambouis</i> et en <i>foutant un gros bordel</i> 112 que j'ai le plus appris (ça va du <i>langage</i> shell et d'autres 113 langages de scripts, de POSIX, au noyau linux ou encore au LISP avec 114 GNU/Emacs). 115 </li> 116 <li>Cela fait <b>gagner du temps</b> et de manière non négligeable. Je suis 117 né <span class="underline">courageux mais terriblement fainéant</span> (et oui c'est possible 118 <code>:-P</code>), j'aime pas trop me répéter quand ça devient un peu compliqué 119 / chiant (e.g. <code>docker run monimage args</code> ça va, <code>docker run</code> avec 120 <code>-v /tmp:/tmp -v /var/run/docker.socket:/var/run/docker.socket […]</code> 121 et <code>run monimage arg1 arg2 arg3 […]</code> moins déjà). 122 </li> 123 </ul> 124 125 <p> 126 Mais revenons à nos moutons et faisons une petite liste de mes besoins, un 127 peu en vrac : 128 </p> 129 130 <ul class="org-ul"> 131 <li>J'ai plusieurs ordinateurs (laptop/desktop/serveurs) et je souhaite 132 avoir mes configurations <b>synchronisées</b> entre ceux-ci — et ce de 133 manière simple, c'est à dire <i>une commande à exécuter</i>. 134 </li> 135 <li>C'est lié au point précédent mais, je ne <i>peux pas vivre</i> sans 136 outil de gestion de version, comme <b>git</b>. Il me faut donc un outil 137 ou ensemble d'outil qui sache utiliser des outils de gestion de 138 version <i>du marché</i>. 139 140 141 <div class="figure"> 142 <p><img src="./img/git-all-the-thing.jpg" alt="git-all-the-thing.jpg" /> 143 </p> 144 </div> 145 </li> 146 147 <li>En fonction de mes ordinateurs, mes besoins de configuration 148 changent. Il me faut donc un outil <b>flexible</b> qui me permette de dire 149 par exemple : sur ce PC j'ai un serveur <code>Xorg</code> donc j'ai besoin de 150 mes configuration xorg, de celle de mon <i>window manager</i>, etc. — et 151 inversement sur ce serveur j'ai besoin de python et haskell mais pas 152 de xorg.. 153 </li> 154 <li>Je ne souhaites pas avoir à faire des liens symboliques, ou de 155 scripts d'installation. Je trouves que ça rends les choses plus 156 compliquées. Du coup il faut que je puisse avoir <b>plusieurs <i>dépôts 157 de configuration</i></b> (repository) qui pointent au même endroit, sans 158 que ce soit le bordel. 159 </li> 160 <li>Le <b>partage</b> est important pour moi. Il en découle deux choses : 161 <ol class="org-ol"> 162 <li>Il faut que je puisse documenter un peu mon repository, avec un 163 bon vieux <code>README</code> ; sans que chaque <code>README</code> se marche dessus. 164 </li> 165 <li>Il y a quelques <b>informations</b> qui sont <b>personnelles</b>, comme par 166 exemple les clés ssh. Il me faut donc être capable d'avoir des 167 <i>dépôts publiques</i> et des <i>dépôts privés</i>. C'est grandement facilité 168 par l'aspect <i>flexibilité</i> <code>:-)</code>. 169 </li> 170 </ol> 171 </li> 172 <li>Un bonus que je souhaite, est de pouvoir disposer de <b>hooks</b>, un peu 173 à la manière de git (voir <a href="https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks">ici</a>). L'idée est de pouvoir <b>générer</b> un 174 fichier de configuration à partir d'un ensemble de fichiers qui 175 viendraient de différents dépôts. Le meilleur exemple que je peux 176 donner c'est <code>~/.ssh/config</code> dans lequel je vais y mettre des bouts 177 publiques que je souhaites partager (comme le <code>Host *</code> avec des 178 trucs cool comme <code>ControlPersist</code>, on en parlera plus tard) et des 179 bouts privés (mes hosts privés, avec mes configurations de 180 <i>rebonds</i>, etc..). 181 </li> 182 </ul> 183 184 <p> 185 Cette liste a mis un certain temps à se former dans ma tête, mais une 186 fois qu'elle était formée, j'ai pu assez facilement faire des choix. 187 </p> 188 </div> 189 </div> 190 191 <div id="outline-container-sec-2" class="outline-2"> 192 <h2 id="sec-2">Choix</h2> 193 <div class="outline-text-2" id="text-2"> 194 <p> 195 Deux outils et un peu d'organisation permettent de répondre à mes 196 besoins. Les deux outils sont <code>vcsh</code> et <code>myrepos</code> (anciennement appelé 197 <code>mr</code>), fait par respectivement Richard Hartmann et Joey Hess (tout 198 deux assez impliqué dans la communauté Debian). 199 </p> 200 </div> 201 202 <div id="outline-container-sec-2-1" class="outline-3"> 203 <h3 id="sec-2-1">vcsh</h3> 204 <div class="outline-text-3" id="text-2-1"> 205 <p> 206 En un mot, <a href="https://github.com/RichiH/vcsh">vcsh</a> permet de maintenir plusieurs <i>repository</i> <a href="http://git-scm.com/">git</a> dans 207 un seul dossier. Par défaut tous les <i>repository</i> git maintenus par 208 <code>vcsh</code> pointent vers le dossier <code>$HOME</code>, mais il est possible 209 d'utiliser un autre dossier. 210 </p> 211 212 <p> 213 L'idée est de pouvoir disposer de plusieurs repository par <i>famille 214 d'application</i>, par exemple <code>vim</code>, <code>ssh</code>, <code>emacs</code>, <code>zsh</code>, etc. Cela 215 permet ainsi d'avoir différents ensemble de configurations sur 216 différentes machines et pour différents utilisateurs. Cela apporte 217 une très grande flexibilité et facilite le partage de configuration 218 (au sein d'une entreprise ou d'un projet par exemple) tout en 219 laissant la place à la définition de configuration(s) 220 personnalisé(s). 221 </p> 222 223 <p> 224 En bonus, <code>vcsh</code> supporte un système de hook, permettant d'exécuter 225 des commandes à différents moments du <i>workflow</i> — c'est la seule 226 partie qui manquant à <code>vcsh</code> de mon point de vue alors j'y ai 227 apporté ma petit pierre. 228 </p> 229 230 <p> 231 <code>vcsh</code> est la clé de voûte de ma gestion de configuration. Sans le 232 travail formidable de <a href="http://richardhartmann.de/">Richard Hartmann</a>, je ne sais pas comment je 233 ferais.. 234 </p> 235 </div> 236 </div> 237 238 <div id="outline-container-sec-2-2" class="outline-3"> 239 <h3 id="sec-2-2">myrepos</h3> 240 <div class="outline-text-3" id="text-2-2"> 241 <p> 242 En un mot, <a href="https://myrepos.branchable.com/">myrepos</a> est un outil permettant de <i>gérer</i> plusieurs 243 repository (git, subversion, mercurial, …) avec une seule 244 commande : <code>mr</code>. C'est simple et efficace : 245 </p> 246 247 <ul class="org-ul"> 248 <li><code>mr u</code> (ou <code>mr update</code>) pour récupérer les dernières modifications (<code>git pull</code>, 249 <code>svn up</code>, …). 250 </li> 251 <li><code>mr -d $HOME/.config u</code> pour récupérer les dernières modifications 252 des repository qui sont dans <code>$HOME/.config</code>. 253 </li> 254 <li><code>mr -j 6 u</code> pour paralléliser la récupération (ici 6 jobs en parallèle). 255 </li> 256 <li><code>mr p</code> pour pousser des modifications (<code>git push</code>, …). 257 </li> 258 <li><code>mr run</code> pour lancer un commande (j'utilise ça tous les jours). 259 </li> 260 </ul> 261 262 <p> 263 Il est également possible de personnaliser les commandes à lancer lors 264 d'un <i>update</i> ou autre (toutes les commandes), et même en définir des 265 nouvelles. Cela se présente comme suit : 266 </p> 267 268 269 <div class="org-src-container"> 270 271 <pre class="src src-conf">[<span class="org-type">foo</span>] 272 <span class="org-variable-name">checkout</span> = git@github.com:joeyh/foo.git 273 <span class="org-variable-name">update</span> = git pull --rebase 274 275 [<span class="org-type">bar</span>] 276 <span class="org-comment-delimiter"># </span><span class="org-comment">This repository has an upstream, which I've forked;</span> 277 <span class="org-comment-delimiter"># </span><span class="org-comment">set up a remote on checkout.</span> 278 <span class="org-variable-name">checkout</span> = 279 git clone git@github.com:joeyh/bar.git 280 cd bar 281 git remote add upstream git@github.com:barbar/bar.git 282 <span class="org-comment-delimiter"># </span><span class="org-comment">make `mr zap` integrate from upstream</span> 283 <span class="org-variable-name">zap</span> = 284 git pull upstream 285 git merge upstream/master 286 git push origin master 287 288 [<span class="org-type">mystuff</span>] 289 <span class="org-variable-name">checkout</span> = git@github.com:joeyh/foo.git 290 <span class="org-comment-delimiter"># </span><span class="org-comment">Skip if the current user is not joey</span> 291 <span class="org-variable-name">skip</span> = test `whoami` != joey 292 293 [<span class="org-type">DEFAULT</span>] 294 <span class="org-comment-delimiter"># </span><span class="org-comment">Teach mr how to `mr gc` in git repos.</span> 295 <span class="org-variable-name">git_gc</span> = git gc <span class="org-string">"$@"</span> 296 </pre> 297 </div> 298 299 <p> 300 Une autre fonctionnalité qui m'est totalement indispensable est ce 301 qu'on appel les <code>fixup(s)</code>. Il est en effet possible d'exécuter une ou 302 plusieurs commandes (shell) après un <code>update</code> (ou via la commande 303 <code>fixup</code>). C'est grâce à ce système la que je génère mes fichiers de 304 configuration en provenance de plusieurs repository (comme 305 <code>$HOME/.ssh/config</code> ou encore <code>$HOME/.gitconfig</code>). 306 </p> 307 308 <p> 309 <code>myrepos</code> est l'exemple de l'outil simple et efficace qui fait une 310 chose et le fait très bien, et dont je n'arrive pas à me passer 311 <code>:-D</code>. Je l'utilise également dans plein d'autres cas, comme par 312 exemple pour mettre à jour mes <i>forks</i> de projets open-source. 313 </p> 314 </div> 315 </div> 316 </div> 317 318 <div id="outline-container-sec-3" class="outline-2"> 319 <h2 id="sec-3">Conclusion</h2> 320 <div class="outline-text-2" id="text-3"> 321 <p> 322 Et voilà, c'est tout pour cette introduction <code>;-)</code>. La prochaine 323 partie se penchera sur la <b>structure</b> que j'utilise ainsi que le 324 repository principal qui est <a href="https://github.com/vdemeester/vcsh-home"><b>vcsh-home</b></a>. Dans les parties suivantes 325 on parlera des autres repository et donc des configurations 326 spécifiques pour les différents outils (comme <a href="https://github.com/vdemeester/sh-config">sh-config</a>, 327 <a href="https://github.com/vdemeester/emacs-config">emacs-config</a> ou encore <a href="https://github.com/vdemeester/go-config">go-config</a>). On parlera aussi probablement de 328 <code>git-annex</code> dans le futur. 329 </p> 330 </div> 331 </div> 332 333 334 </article> 335 <hr /> 336 <div class="prev-next"> 337 338 <a class="paging-link prev" href="/posts/2016-09-18-firefox-places-and-bookmarks/" title="Firefox hidden feature — places in bookmarks">← Previous post</a> 339 340 341 342 <a class="paging-link next" href="/posts/2015-06-01-docker-1.6-ecosystem/" title="Docker 1.6 et son écosystème">Next post →</a> 343 344 </div> 345 346 </div> 347 </div> 348 349 <footer> 350 <nav> 351 352 <a href="/">home</a> 353 <span class="text-muted"> | </span> 354 355 <a href="/about">about</a> 356 <span class="text-muted"> | </span> 357 358 <a href="/archive">archive</a> 359 <span class="text-muted"> | </span> 360 361 <a href="/categories">categories</a> 362 <span class="text-muted"> | </span> 363 364 <a href="/tags">tags</a> 365 <span class="text-muted"> | </span> 366 367 <a href="https://twitter.com/vdemeest">twitter</a> 368 <span class="text-muted"> | </span> 369 370 <a href="https://github.com/vdemeester">github</a> 371 <span class="text-muted"> | </span> 372 373 <a href="https://vincent.demeester.fr/index.xml">rss</a> 374 </nav> 375 <br/> 376 <address> 377 <span class="copyright"> 378 Content and design by Vincent Demeester 379 (<a rel="licence" href="http://creativecommons.org/licenses/by-nc-sa/3.0/">Some rights reserved</a>) 380 </span><br /> 381 <span class="engine"> 382 Powered by <a href="https://gohugo.io/">Hugo</a> and <a href="https://github.com/kaushalmodi/ox-hugo/">ox-hugo</a> 383 </span> 384 </address> 385 </footer> 386 </body> 387