Moments d'inertie d'une raquette de tennis

2024-07-19T00:00:00+00:00

Le moment d'inertie (exprimé en $kg.m^{2}</script> ) est une mesure de la résistance d'un objet à changer sa vitesse de rotation autour d'un axe (au même titre que l'inertie est la résistance d'un objet à changer sa vitesse de translation). Il varie avec la masse et la distance de la-dite masse par rapport à l'axe de rotation. <figure> <figcaption> Axes de rotations d'une raquette de tennis </figcaption> </figure> Une raquette de tennis possède 3 moments d'inertie principaux (passant par le centre de masse) : <ul> <li>transversal: la raquette tourne autour de l'aze x (Fig. 1).</li> <li>lateral: la raquette tourne autour de l'axe y (Fig. 1) de façon similaire à un coup droit (le réel moment d'inertie pour ce genre de coup est toutefois mesuré là où la main se place sur le manche plutôt qu'au centre de masse pour être plus représentatif de l'effort à fournir dans la réalité).</li> <li>polaire: la raquette tourne autour de l'axe z (Fig. 1), comme par exemple lorsqu'une balle est frappée décentrée.</li> </ul> Le moment de rotation polaire est généralement appelé twistweight. C'est lui qui est impliqué lorsqu'une balle est frappée de façon décentrée par rapport à l'axe de rotation z. L'augmenter permet donc de rendre une raquette moins sensible au décentrage, en placant des masses à 3h et 9h. Le moment de rotation lateral est généralement appelé swingweight. Il est impliqué dès lors que la raquette entre en mouvement. L'augmenter (en ajoutant une masse à 12h par exemple) va permettre d'augmenter la puissance de frappe. Plus on ajoute de la masse à distance de l'axe de rotation, plus le moment d'inertie augmente, plus il va être difficile de faire tourner la raquette autour de ce même axe. </article> <article> <h1>Terraform at LumApps: Part 3 - Handling our Terraform breaking changes at scale</h1> 2024-06-10T16:32:00+02:00 I authored or co-authored this post : <a href="https://medium.com/lumapps-engineering/terraform-at-lumapps-part-3-daa3c869f0f4">https://medium.com/lumapps-engineering/terraform-at-lumapps-part-3-daa3c869f0f4</a>. </article> <article> <h1>Terraform at LumApps: Part 2 - Managing terragrunt.hcl files at scale</h1> 2023-12-18T00:00:00+01:00 I authored or co-authored this post : <a href="https://medium.com/lumapps-engineering/terraform-at-lumapps-part-2-27494897def4">https://medium.com/lumapps-engineering/terraform-at-lumapps-part-2-27494897def4</a>. </article> <article> <h1>Terraform at LumApps: Part 1 - A huge Terraform monorepo</h1> 2022-05-23T00:00:00+01:00 I authored or co-authored this post : <a href="https://medium.com/lumapps-engineering/terraform-at-lumapps-part-1-f37660b4ed95">https://medium.com/lumapps-engineering/terraform-at-lumapps-part-1-f37660b4ed95</a>. </article> <article> <h1>Drop ALT led configuration using bitmask</h1> 2020-08-23T12:23:13+02:00 I recently purchased an <a href="https://drop.com/buy/drop-alt-high-profile-mechanical-keyboard">ALT mechanical keyboard</a> from Drop (formerly Massdrop). After going through the mandatory modding (changing Halo Trues for Aliaz switches, changing stabilizers, lubbing what needed to be lubed, etc...), I started compiling and flashing my own custom <a href="https://github.com/qmk/qmk_firmware">QMK firmware</a>. It worked pretty great, but I was stuck at backlight configuration. I could not understand or guess how to configure it. I ended up <a href="https://github.com/qmk/qmk_firmware/blob/master/keyboards/massdrop/alt/config_led.h#L52-L169">reading code</a> and <a href="https://github.com/qmk/qmk_firmware/blob/master/keyboards/massdrop/alt/keymaps/default_md/keymap.c#L183-L221">examples</a> provided by QMK. The keyboard is built upon a 105 LED matrix. A particular example caught my attention : <pre data-linenos data-lang="c" style="background-color:#fafafa;color:#61676c;" class="language-c "><code class="language-c" data-lang="c"><table><tbody><tr><td>1</td><td>//Specific LEDs use specified RGB values while all others are off </td></tr><tr><td>2</td><td>{ .flags = LED_FLAG_MATCH_ID | LED_FLAG_USE_RGB, \ </td></tr><tr><td>3</td><td> .id0 = 0xFF, \ </td></tr><tr><td>4</td><td> .id1 = 0x00FF, \ </td></tr><tr><td>5</td><td> .id2 = 0x0000FF00, \ </td></tr><tr><td>6</td><td> .id3 = 0xFF000000, \ </td></tr><tr><td>7</td><td> .r = 75, \ </td></tr><tr><td>8</td><td> .g = 150, \ </td></tr><tr><td>9</td><td> .b = 225 \ </td></tr><tr><td>10</td><td>}, </td></tr></tbody></table></code></pre> And it struck me ! Bitmask ! The only thing that can select -- at the same time -- both a single address and multiple ones is a bitmask ! By converting hexadecimal values to decimal, we get familiar-looking numbers. They belong to the <a href="https://en.wikipedia.org/wiki/1_%2B_2_%2B_4_%2B_8_%2B_%E2%8B%AF">successive power of two</a> serie : $$ \mathrm{0xFF} = 255 = 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = \displaystyle\sum_{i=0}^{7} 2^{i} $$ $$ \mathrm{0x0000FF00} = 65280 = 1 + 2 + \ldots = \displaystyle\sum_{i=8}^{15} 2^{i} $$ $$ \mathrm{0xFF000000} = 4278190080 = 16 777 216 + 33 554 432 + \ldots = \displaystyle\sum_{i=24}^{31} 2^{i} $$ The keyboard is separated in 4 groups of 32 LEDs (except the last one of 9 LEDs) : <ul> <li><code>.id0</code>: from <code>Esc</code> to <code>a</code></li> <li><code>.id1</code>: from <code>s</code> to <code>fn</code></li> <li><code>.id2</code>: from <code>Left Arrow</code> to Underglow LED above <code>5</code></li> <li><code>.id3</code>: from Underglow LED above <code>4</code> to the end (Underglow LED left of <code>Ctrl</code>)</li> </ul> Each LED is assigned a number from <code>0</code> to <code>31</code> based on its position in the group. Let say we want to display a green color on the first four letters of every row (<code>Q(16)</code>, <code>W(17)</code>, <code>E(18)</code>, <code>R(19)</code>, <code>A(31)</code>, <code>S(0)</code>, <code>D(1)</code>, <code>F(2)</code>, <code>Z(13)</code>, <code>X(14)</code>, <code>C(15)</code>, <code>V(16)</code>). We just need to add every value as a power of two : $$ .id0 = 2^{16} + 2^{17} + 2^{18} + 2^{19} + 2^{31} = 2 148 466 688 $$ $$ .id1 = 2^0 + 2^1 + 2^2 + 2^{13} + 2^{14} + 2^{15} + 2^{16} = 122 887 $$ And we get : <pre data-linenos data-lang="c" style="background-color:#fafafa;color:#61676c;" class="language-c "><code class="language-c" data-lang="c"><table><tbody><tr><td>1</td><td>{ .flags = LED_FLAG_MATCH_ID | LED_FLAG_USE_RGB, \ </td></tr><tr><td>2</td><td> .id0 = 2148466688, \ </td></tr><tr><td>3</td><td> .id1 = 122887, \ </td></tr><tr><td>4</td><td> .id2 = 0, \ </td></tr><tr><td>5</td><td> .id3 = 0, \ </td></tr><tr><td>6</td><td> .r = 0, \ </td></tr><tr><td>7</td><td> .g = 255, \ </td></tr><tr><td>8</td><td> .b = 0, \ </td></tr><tr><td>9</td><td>}, </td></tr></tbody></table></code></pre> While being a smart way to target both one and multiple LEDs, it's not very easy to understand and even less to change. Fortunately, someone very nice created a bitmask generator <a href="http://daedalusrising.com/maskdrop/">online</a>. </article> <article> <h1>Graphes : Le danger des séries empilées</h1> 2020-05-03T11:33:00+01:00 Le graphe suivant montre un nombre de requêtes en fonction du temps sur 4 serveurs. Les séries sont empilées afin de pouvoir facilement lire la somme de ces requêtes sur l'ensemble de l'infrastructure. <figure> <figcaption> Exemple typiques de séries empilées : nombre de requêtes en fonction du temps sur 4 serveurs </figcaption> </figure> Il est très facile d'extraire quelques informations : <ul> <li>3 des 4 serveurs reçoivent chacun une dizaine de requêtes par seconde;</li> <li>L'un des serveurs reçoit plus de requêtes que les autres;</li> <li>L'ensemble de l'infrastructure encaisse une soixantaine de requêtes par seconde;</li> </ul> <h2 id="pourquoi-les-series-empilees-sont-dangereuses">Pourquoi les séries empilées sont dangereuses ?</h2> Il semble aussi évident que l'infrastructure a vu une chute massive des requêtes sur chacun des noeuds. En réordonnant les séries en plaçant le serveur le plus chargé en haut, une différence intéréssante se dessine : <figure> <figcaption> Le même exemple avec les séries ordonnées différement </figcaption> </figure> Toute l'infrastructure n'est pas affectée par la diminution brutale du nombre de requêtes mais seulement un des serveurs ! <figure> <figcaption> Denis Brogniart est stupéfait de cette découverte </figcaption> </figure><h3 id="est-ce-un-probleme-avec-les-donnees-avec-le-graphe">Est-ce un problème avec les données ? Avec le graphe ?</h3> Les séries inférieures influencent la forme des séries supérieures. L'ordre des séries change donc la perception que l'on a d'un graphe et, par conséquent, les conclusions qu'on en tire ! Le fait de pouvoir facilement lire une somme pousse à ne plus prendre en compte les différences entre les séries mais seulement lire la série la plus haute et ainsi voir, de façon erronée, une baisse sur toute l'infrastructure. Ce ne sont ni les données ni leur représentation qui sont erronées, mais bien la lecture que nous en avons. Sans être vigilant, il est facile de penser que la baisse du nombre de requêtes affecte tout l'infrastructure. <h2 id="comment-s-en-premunir">Comment s'en prémunir ?</h2> Il est très facile de se prémunir d'une telle erreur d'interprétation : ne pas empiler les séries. Pour pouvoir quand même lire un total, il suffit d'ajouter une série représentant leur somme : <figure> <figcaption> Le même exemple sans empiler les séries et avec une somme des séries (noir) </figcaption> </figure> Avec cette représentation, il apparait de façon très évidente que les variations d'une série ont bien un effet sur le total (puisqu'il s'agit de la somme des points des séries) mais pas sur les autres séries. </article> <article> <h1>Timeseries : Cardinalité et explosion</h1> 2020-01-04T21:12:00+01:00 <a href="https://fr.wikipedia.org/wiki/Cardinalit%C3%A9_(math%C3%A9matiques)">Wikipédia</a> indique : <blockquote> En mathématiques, la cardinalité est une notion de taille pour les ensembles. Lorsqu'un ensemble est fini, c'est-à-dire si ses éléments peuvent être listés par une suite finie, son cardinal est la longueur de cette suite, autrement dit il s'agit du nombre d'éléments de l'ensemble. </blockquote> C'est donc le nombre de valeurs uniques d'un ensemble. Dans le cas de Prometheus, la cardinalité d'une métrique $M$ est le produit de la cardinalité de ses $n$ labels $L_{n}$ tel que : $$ Card(M) = \prod_{n=0}^{X}Card(L_n) $$ Ainsi, il est facile d'imaginer une métrique <code>http_request_duration_seconds</code> ayant les caractéristiques suivantes : <ul> <li>Un label <code>verb</code> qui représente les méthodes HTTP et qui a pour valeurs possibles : <code>GET</code>, <code>POST</code>, <code>PUT</code> et <code>DELETE</code> ($Card = 4$);</li> <li>Un label <code>le</code> qui est le bucket dans lequel la mesure tombe. Il a pour valeurs possibles : 0.1, 0.2, 0.5, 1, <code>+Inf</code> ($Card = 5$);</li> <li>Un label <code>browser</code> qui indique le navigateur utilisé par le client : Chrome, Firefox, IE, Edge, Safari, Opera, Others ($Card = 7$);</li> <li>Un label <code>device</code> qui représente la famille de périphérique utilisé par le client : Desktop, Mobile, Tablet ($Card = 3$);</li> <li>En enfin, un label <code>os</code> qui indique la "marque" de l'OS utilisé par le client : Linux, Microsoft, Apple ($Card = 3$);</li> </ul> Si la métrique n'avait qu'un seul label, voire deux, la cardinalité serait faible. Le problème survient lorsque un label est ajouté ou lorsque la cardinalité d'un label augmente subitement. La métrique fini innévitablement par arriver à une <a href="https://fr.wikipedia.org/wiki/Explosion_combinatoire">explosion combinatoire</a> : un petit changement du nombre de données rend la cardinalité de notre métrique irraisonable. Au début, tout commence de manière raisonnable : il n'y a que 2 verbes et 5 buckets. Puis on se dit qu'il faudrait séparer par OS. Puis par famille de client. Puis par navigateur. Puis par... Et la cardinalité est passée de $2 \cdot 5 = 10$ à $4 \cdot 5 \cdot 7 \cdot 3 \cdot 3 = 1260$ ! Le plus surprenant c'est que l'augmentation de la cardinalité des labels augmente considérablement la cardinalité de la métrique ! Admettons que chaque cardinalité augmente de 1 (ce qui est peu), la cardinalité de la métrique passe de $1260$ à $5 \cdot 6 \cdot 8 \cdot 4 \cdot 4 = 3840$, soit plus du triple de la valeur initiale ! Que va-t'il se passer si l'on décide d'ajouter un label <code>customer</code> qui a pour valeur un UUID ? D'après <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)">Wikipédia</a>, un UUID dans sa version 4 a 122 bits générés aléatoirement à 0 ou 1, soit $2^{122}$ possiblités ! <figure> <figcaption> Boooooom </figcaption> </figure> Il semble évident que demander une granularité aussi fine à un tel système est impossible. Les timeseries sont conçues pour traiter et afficher des données en temps réel. Malheureusement, le temps réel est quelque chose de très coûteux, il faut donc faire quelques compromis. Limiter la précision (et donc la cardinalité) est un bon moyen d'équilibrer le cout. Il faudrait alors se tourner vers un second système dédié à de la précision, tel que l'analyse de logs, pour compléter les mesures. Les timeseries servent à donner une vue d'ensemble d'un système (que ce soit au niveau d'un serveur, d'une application, d'un cluster, d'un datacenter...) mais ne peuvent pas servir à débugger et à trouver l'origine d'un problème. Une fois qu'un problème est détecté, c'est vers les logs qu'il faut se tourner. </article> <article> <h1>Esctl: managing elasticsearch from the command line</h1> 2019-09-22T22:08:00+01:00 During my month of unemployment, I spent time thinking on how I had tackled technical problems in my last year-and-half of work. The best part of my day-to-day mission was to ensure our Elasticsearch clusters were healthy, secured and efficient. To that end, I was using a combination of tools: <ul> <li>raw <code>curl</code> commands,</li> <li>bash scripts I wrote,</li> <li>graphical interfaces,</li> <li>Prometheus monitoring and alerting,</li> <li>Some automation,</li> <li>commands embedded in SaltStack</li> </ul> It's easy to see there is no common way to manage those clusters, and I was relying on a bunch of disparate stuff. <h2 id="the-problem">The problem</h2> The issue does not come from Elasticsearch itself but is inherent to any software that exposes an HTTP API to manage itself: curl-of-the-death. Here are some commands I used to run on a regular basis (examples come from <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html">Elasticsearch's documentation</a>). <h4 id="list-indices">List indices</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ curl -X GET "localhost:9200/_cat/indices" </td></tr><tr><td>2</td><td>yellow open foo VrIiXmIRRA6BNP5JWaXKqA 1 1 0 0 283b 283b </td></tr></tbody></table></code></pre> <h4 id="change-the-number-of-replicas-of-a-given-index">Change the number of replicas of a given index</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ curl -X PUT "localhost:9200/twitter/_settings?pretty" -H 'Content-Type: application/json' -d' </td></tr><tr><td>2</td><td>{ </td></tr><tr><td>3</td><td> "index" : { </td></tr><tr><td>4</td><td> "number_of_replicas" : 2 </td></tr><tr><td>5</td><td> } </td></tr><tr><td>6</td><td>} </td></tr><tr><td>7</td><td>' </td></tr></tbody></table></code></pre> <h4 id="reset-a-index-s-refresh-interval-to-its-default-value">Reset a index's refresh interval to its default value</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ curl -X PUT "localhost:9200/twitter/_settings?pretty" -H 'Content-Type: application/json' -d' </td></tr><tr><td>2</td><td>{ </td></tr><tr><td>3</td><td> "index" : { </td></tr><tr><td>4</td><td> "refresh_interval" : null </td></tr><tr><td>5</td><td> } </td></tr><tr><td>6</td><td>} </td></tr><tr><td>7</td><td>' </td></tr></tbody></table></code></pre> <h4 id="pretty-print-cluster-stats">Pretty-print cluster stats</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ curl -X GET "localhost:9200/_cluster/stats" </td></tr><tr><td>2</td><td>{ </td></tr><tr><td>3</td><td> "_nodes": { </td></tr><tr><td>4</td><td> "total": 1, </td></tr><tr><td>5</td><td> "successful": 1, </td></tr><tr><td>6</td><td> "failed": 0 </td></tr><tr><td>7</td><td> }, </td></tr><tr><td>8</td><td> ... </td></tr><tr><td>9</td><td> "nodes": { </td></tr><tr><td>10</td><td> "count": { </td></tr><tr><td>11</td><td> "total": 1, </td></tr><tr><td>12</td><td> "data": 1, </td></tr><tr><td>13</td><td> "coordinating_only": 0, </td></tr><tr><td>14</td><td> "master": 1, </td></tr><tr><td>15</td><td> "ingest": 1 </td></tr><tr><td>16</td><td> }, </td></tr><tr><td>17</td><td> "versions": [ </td></tr><tr><td>18</td><td> "7.2.1" </td></tr><tr><td>19</td><td> ], </td></tr><tr><td>20</td><td> "jvm": { </td></tr><tr><td>21</td><td> "max_uptime_in_millis": 1565394, </td></tr><tr><td>22</td><td> "versions": [ </td></tr><tr><td>23</td><td> { </td></tr><tr><td>24</td><td> "version": "12.0.1", </td></tr><tr><td>25</td><td> "vm_name": "OpenJDK 64-Bit Server VM", </td></tr><tr><td>26</td><td> "vm_version": "12.0.1+12", </td></tr><tr><td>27</td><td> "vm_vendor": "Oracle Corporation", </td></tr><tr><td>28</td><td> "bundled_jdk": true, </td></tr><tr><td>29</td><td> "using_bundled_jdk": true, </td></tr><tr><td>30</td><td> "count": 1 </td></tr><tr><td>31</td><td> } </td></tr><tr><td>32</td><td> ], </td></tr><tr><td>33</td><td> "mem": { </td></tr><tr><td>34</td><td> "heap_used_in_bytes": 128029720, </td></tr><tr><td>35</td><td> "heap_max_in_bytes": 1056309248 </td></tr><tr><td>36</td><td> }, </td></tr><tr><td>37</td><td> "threads": 31 </td></tr><tr><td>38</td><td> }, </td></tr><tr><td>39</td><td> ... </td></tr><tr><td>40</td><td> } </td></tr><tr><td>41</td><td>} </td></tr></tbody></table></code></pre> <h4 id="reroute-shard-0-of-index-test-from-node1-to-node2">Reroute shard 0 of index 'test' from node1 to node2</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ curl -X POST "localhost:9200/_cluster/reroute?pretty" -H 'Content-Type: application/json' -d' </td></tr><tr><td>2</td><td>{ </td></tr><tr><td>3</td><td> "commands" : [ </td></tr><tr><td>4</td><td> { </td></tr><tr><td>5</td><td> "move" : { </td></tr><tr><td>6</td><td> "index" : "test", "shard" : 0, </td></tr><tr><td>7</td><td> "from_node" : "node1", "to_node" : "node2" </td></tr><tr><td>8</td><td> } </td></tr><tr><td>9</td><td> } </td></tr><tr><td>10</td><td> ] </td></tr><tr><td>11</td><td>} </td></tr><tr><td>12</td><td>' </td></tr></tbody></table></code></pre> <h4 id="change-cluster-s-transient-setting-indices-recovery-max-bytes-per-sec-to-20mb">Change cluster's transient setting 'indices.recovery.max_bytes_per_sec' to 20mb</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ curl -X PUT "localhost:9200/_cluster/settings?flat_settings=true&pretty" -H 'Content-Type: application/json' -d' </td></tr><tr><td>2</td><td>{ </td></tr><tr><td>3</td><td> "transient" : { </td></tr><tr><td>4</td><td> "indices.recovery.max_bytes_per_sec" : "20mb" </td></tr><tr><td>5</td><td> } </td></tr><tr><td>6</td><td>} </td></tr><tr><td>7</td><td>' </td></tr></tbody></table></code></pre> Commands are short, but if I need to pass URL parameters, content type, HTTP verb and a full JSON body, they are no longer short... Of course, I could use some bash alias to hide the <code>-H 'Content-Type: application/json'</code>, or maybe use the excellent <a href="https://httpie.org/">HTTPie</a> but the biggest pain comes from the JSON body! <h2 id="requirements">Requirements</h2> I needed a tool which could abstract all those long curl commands and could be flexible enough. After looking on the Internet, it appeared the few tools already written didn't support commands I needed. Thus, I decided to write my own, and I came with a list of requirements: <table><thead><tr><th>Requirement</th><th>Solution</th></tr></thead><tbody> <tr><td>Easy and fast to write</td><td>Python : high-level, easy to read and write, I know it well</td></tr> <tr><td>Fast to use</td><td>Command-line</td></tr> <tr><td>Abstract/hide params</td><td>Command-line params and integrated help ! I don't want to remember what verb to use, what URL params to give, what to put in the JSON body, etc...</td></tr> <tr><td>Don't spend time on building CLI</td><td><a href="https://github.com/openstack/cliff">Openstack's Cliff</a></td></tr> <tr><td>Easy to switch cluster, without remembering long server name</td><td>Config file</td></tr> <tr><td>Each cluster may have different setup (ssl, auth, etc...)</td><td>Config file</td></tr> <tr><td>Nice and pretty output</td><td><a href="https://github.com/openstack/cliff">Cliff</a> comes with <a href="https://pypi.org/project/PrettyTable/">PrettyTable</a></td></tr> <tr><td>Inspiration</td><td><a href="https://github.com/openstack/python-openstackclient">Openstack's CLI</a> and <a href="https://kubernetes.io/docs/reference/kubectl/overview/">kubectl</a></td></tr> </tbody></table> <h2 id="the-solution">The solution</h2> I ended up writing <a href="https://github.com/jeromepin/esctl">esctl</a>. It checks all my requirements and it's very easy to add new features by inheriting a class based on the output type. <figure> <figcaption> Esctl subcommands taxonomy </figcaption> </figure> It relies on a config file (inspired by <code>kubectl</code>) to declare settings (global and cluster-wide), clusters, users and contexts (an association of a user and a cluster) : <pre data-linenos data-lang="yaml" style="background-color:#fafafa;color:#61676c;" class="language-yaml "><code class="language-yaml" data-lang="yaml"><table><tbody><tr><td>1</td><td>settings: </td></tr><tr><td>2</td><td> no_check_certificate: true </td></tr><tr><td>3</td><td> max_retries: 0 </td></tr><tr><td>4</td><td> timeout: 20 </td></tr><tr><td>5</td><td> </td></tr><tr><td>6</td><td>clusters: </td></tr><tr><td>7</td><td> localhost: </td></tr><tr><td>8</td><td> servers: </td></tr><tr><td>9</td><td> - http://localhost:9200 </td></tr><tr><td>10</td><td> </td></tr><tr><td>11</td><td> foo01-prd-sfo: </td></tr><tr><td>12</td><td> servers: </td></tr><tr><td>13</td><td> - https://master01-foo01-prd-sfo1.example.com </td></tr><tr><td>14</td><td> - https://master02-foo01-prd-sfo2.example.com </td></tr><tr><td>15</td><td> - https://master03-foo01-prd-sfo3.example.com </td></tr><tr><td>16</td><td> settings: </td></tr><tr><td>17</td><td> timeout: 60 </td></tr><tr><td>18</td><td> </td></tr><tr><td>19</td><td>users: </td></tr><tr><td>20</td><td> jerome: </td></tr><tr><td>21</td><td> username: jerome </td></tr><tr><td>22</td><td> password: P@ssw0rD </td></tr><tr><td>23</td><td> </td></tr><tr><td>24</td><td>contexts: </td></tr><tr><td>25</td><td> localhost: </td></tr><tr><td>26</td><td> cluster: localhost </td></tr><tr><td>27</td><td> </td></tr><tr><td>28</td><td> production: </td></tr><tr><td>29</td><td> user: jerome </td></tr><tr><td>30</td><td> cluster: foo01-prd-sfo </td></tr><tr><td>31</td><td> </td></tr><tr><td>32</td><td>default-context: localhost </td></tr></tbody></table></code></pre> Esctl provides a lot of commands and subcommands to manage Elasticsearch: <pre style="background-color:#fafafa;color:#61676c;"><code>usage: esctl [--version] [-v | -q] [--log-file LOG_FILE] [-h] [--debug] [--context CONTEXT] esctl optional arguments: --version show program's version number and exit -v, --verbose Increase verbosity of output. Can be repeated. -q, --quiet Suppress output except warnings and errors. --log-file LOG_FILE Specify a file to log output. Disabled by default. -h, --help Show help message and exit. --debug Show tracebacks on errors. --context CONTEXT Context to use Commands: cat allocation Show shard allocation. cluster allocation explain Provide explanations for shard allocations in the cluster. cluster health Retrieve the cluster health. cluster routing allocation enable Change the routing allocation status. cluster stats Retrieve the cluster status. complete print bash completion command (cliff) config context list List all contexts. help print detailed help for another command (cliff) index close Close an index. index create Create an index. index delete Delete an index. index list List all indices. index open Open an index. logging get Get a logger value. logging reset Reset a logger value. logging set Set a logger value. node hot-threads Print hot threads on each nodes. node list List nodes. </code></pre> It allows to dramatically shorten previously shown commands : <h4 id="list-indices-1">List indices</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ esctl index list </td></tr><tr><td>2</td><td>+-------+--------+--------+------------------------+---------+---------+------------+--------------+------------+--------------------+ </td></tr><tr><td>3</td><td>| Index | Health | Status | UUID | Primary | Replica | Docs Count | Docs Deleted | Store Size | Primary Store Size | </td></tr><tr><td>4</td><td>+-------+--------+--------+------------------------+---------+---------+------------+--------------+------------+--------------------+ </td></tr><tr><td>5</td><td>| foo | yellow | open | VrIiXmIRRA6BNP5JWaXKqA | 1 | 1 | 0 | 0 | 283b | 283b | </td></tr><tr><td>6</td><td>+-------+--------+--------+------------------------+---------+---------+------------+--------------+------------+--------------------+ </td></tr></tbody></table></code></pre> <h4 id="change-the-number-of-replicas-of-a-given-index-1">Change the number of replicas of a given index</h4> Not implemented yet. Would look like : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ esctl index settings set number_of_replicas 2 --index=twitter </td></tr></tbody></table></code></pre> <h4 id="reset-a-index-s-refresh-interval-to-its-default-value-1">Reset a index's refresh interval to its default value</h4> Not implemented yet. Would look like : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ esctl index settings reset refresh_interval --index=twitter </td></tr></tbody></table></code></pre> <h4 id="pretty-print-cluster-stats-1">Pretty-print cluster stats</h4> <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ esctl cluster stats </td></tr><tr><td>2</td><td>+------------------------------------------------+------------------------------+ </td></tr><tr><td>3</td><td>| Attribute | Value | </td></tr><tr><td>4</td><td>+------------------------------------------------+------------------------------+ </td></tr><tr><td>5</td><td>| _nodes.failed | 0 | </td></tr><tr><td>6</td><td>| _nodes.successful | 1 | </td></tr><tr><td>7</td><td>| _nodes.total | 1 | </td></tr><tr><td>8</td><td>... </td></tr><tr><td>9</td><td>| nodes.count.coordinating_only | 0 | </td></tr><tr><td>10</td><td>| nodes.count.data | 1 | </td></tr><tr><td>11</td><td>| nodes.count.ingest | 1 | </td></tr><tr><td>12</td><td>| nodes.count.master | 1 | </td></tr><tr><td>13</td><td>| nodes.count.total | 1 | </td></tr><tr><td>14</td><td>| nodes.discovery_types.single-node | 1 | </td></tr><tr><td>15</td><td>| nodes.fs.available_in_bytes | 48388599808 | </td></tr><tr><td>16</td><td>| nodes.fs.free_in_bytes | 51605315584 | </td></tr><tr><td>17</td><td>| nodes.fs.total_in_bytes | 62725623808 | </td></tr><tr><td>18</td><td>| nodes.jvm.max_uptime_in_millis | 1565394 | </td></tr><tr><td>19</td><td>| nodes.jvm.mem.heap_max_in_bytes | 1056309248 | </td></tr><tr><td>20</td><td>| nodes.jvm.mem.heap_used_in_bytes | 128029720 | </td></tr><tr><td>21</td><td>| nodes.jvm.threads | 31 | </td></tr><tr><td>22</td><td>| nodes.jvm.versions[0].bundled_jdk | True | </td></tr><tr><td>23</td><td>| nodes.jvm.versions[0].count | 1 | </td></tr><tr><td>24</td><td>| nodes.jvm.versions[0].using_bundled_jdk | True | </td></tr><tr><td>25</td><td>| nodes.jvm.versions[0].version | 12.0.1 | </td></tr><tr><td>26</td><td>| nodes.jvm.versions[0].vm_name | OpenJDK 64-Bit Server VM | </td></tr><tr><td>27</td><td>| nodes.jvm.versions[0].vm_vendor | Oracle Corporation | </td></tr><tr><td>28</td><td>| nodes.jvm.versions[0].vm_version | 12.0.1+12 | </td></tr><tr><td>29</td><td>... </td></tr><tr><td>30</td><td>| status | yellow | </td></tr><tr><td>31</td><td>| timestamp | 1565893455640 | </td></tr><tr><td>32</td><td>+------------------------------------------------+------------------------------+ </td></tr></tbody></table></code></pre> <h4 id="reroute-shard-0-of-index-test-from-node1-to-node2-1">Reroute shard 0 of index 'test' from node1 to node2</h4> Not implemented yet <h4 id="change-cluster-s-transient-setting-indices-recovery-max-bytes-per-sec-to-20mb-1">Change cluster's transient setting 'indices.recovery.max_bytes_per_sec' to 20mb</h4> Not implemented yet. Would look like : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ esctl cluster settings set --transient indices.recovery.max_bytes_per_sec 20mb </td></tr></tbody></table></code></pre> <h2 id="what-a-subcommand-look-likes">What a subcommand look likes</h2> I created 3 output class based on Cliff's ones: <ul> <li><code>EsctlCommand</code> : Doesn't expect any output</li> <li><code>EsctlLister</code> : Expect a list of elements in order to create a multi-columns table</li> <li><code>EsctlShowOne</code> : Expect a key-value list to create a two-columns table</li> </ul> To add a new subcommand, I only need to choose the output class (and inherit my class from it) and write the <code>take_action</code> method: <pre data-linenos data-lang="python" style="background-color:#fafafa;color:#61676c;" class="language-python "><code class="language-python" data-lang="python"><table><tbody><tr><td>1</td><td>def take_action(self, parsed_args): </td></tr><tr><td>2</td><td> """Generate or retrieve data to be displayed. </td></tr><tr><td>3</td><td> </td></tr><tr><td>4</td><td> Arguments: </td></tr><tr><td>5</td><td> parsed_args {argparse.Namespace} -- Arguments from the command line. </td></tr><tr><td>6</td><td> </td></tr><tr><td>7</td><td> Returns: </td></tr><tr><td>8</td><td> Any -- The data to be displayed, as specified by Cliff </td></tr><tr><td>9</td><td> """ </td></tr><tr><td>10</td><td> </td></tr><tr><td>11</td><td> return data </td></tr></tbody></table></code></pre> Here is, as a sample, the class associated to the <code>esctl cluster health</code> command: <pre data-linenos data-lang="python" style="background-color:#fafafa;color:#61676c;" class="language-python "><code class="language-python" data-lang="python"><table><tbody><tr><td>1</td><td>class ClusterHealth(EsctlShowOne): </td></tr><tr><td>2</td><td> """Retrieve the cluster health.""" </td></tr><tr><td>3</td><td> </td></tr><tr><td>4</td><td> def take_action(self, parsed_args): </td></tr><tr><td>5</td><td> # Retrieve the cluster health using the appropriate elasticsearch-py function. Then order the output and sort it </td></tr><tr><td>6</td><td> health = self._sort_and_order_dict(Esctl._es.cluster.health()) </td></tr><tr><td>7</td><td> </td></tr><tr><td>8</td><td> # Add coloration of the "status" (RED, YELLOW, GREEN) key based on it's value </td></tr><tr><td>9</td><td> health["status"] = Color.colorize( </td></tr><tr><td>10</td><td> health.get("status"), getattr(Color, health.get("status").upper()) </td></tr><tr><td>11</td><td> ) </td></tr><tr><td>12</td><td> </td></tr><tr><td>13</td><td> # Return a tuple of tuple. It will lead to a two-column table : "Attribute" and "Value" </td></tr><tr><td>14</td><td> return (tuple(health.keys()), tuple(health.values())) </td></tr></tbody></table></code></pre> Which will display : <pre style="background-color:#fafafa;color:#61676c;"><code>+----------------------------------+----------------+ | Field | Value | +----------------------------------+----------------+ | active_primary_shards | 0 | | active_shards | 0 | | active_shards_percent_as_number | 100.0 | | cluster_name | docker-cluster | | delayed_unassigned_shards | 0 | | initializing_shards | 0 | | number_of_data_nodes | 1 | | number_of_in_flight_fetch | 0 | | number_of_nodes | 1 | | number_of_pending_tasks | 0 | | relocating_shards | 0 | | status | green | | task_max_waiting_in_queue_millis | 0 | | timed_out | False | | unassigned_shards | 0 | +----------------------------------+----------------+ </code></pre> Instead of : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>{ </td></tr><tr><td>2</td><td> "cluster_name" : "docker-cluster", </td></tr><tr><td>3</td><td> "status" : "green", </td></tr><tr><td>4</td><td> "timed_out" : false, </td></tr><tr><td>5</td><td> "number_of_nodes" : 1, </td></tr><tr><td>6</td><td> "number_of_data_nodes" : 1, </td></tr><tr><td>7</td><td> "active_primary_shards" : 0, </td></tr><tr><td>8</td><td> "active_shards" : 0, </td></tr><tr><td>9</td><td> "relocating_shards" : 0, </td></tr><tr><td>10</td><td> "initializing_shards" : 0, </td></tr><tr><td>11</td><td> "unassigned_shards" : 0, </td></tr><tr><td>12</td><td> "delayed_unassigned_shards" : 0, </td></tr><tr><td>13</td><td> "number_of_pending_tasks" : 0, </td></tr><tr><td>14</td><td> "number_of_in_flight_fetch" : 0, </td></tr><tr><td>15</td><td> "task_max_waiting_in_queue_millis" : 0, </td></tr><tr><td>16</td><td> "active_shards_percent_as_number" : 100.0 </td></tr><tr><td>17</td><td>} </td></tr></tbody></table></code></pre> </article> <article> <h1>PATCH-er selon la RFC</h1> 2019-04-02T16:08:00+01:00 <h2 id="put-mise-a-jour-totale">PUT: mise à jour totale</h2> La plupart des APIs REST proposent des mécanismes pour modifier des ressources, notamment grâce au verbe PUT qui permet d'envoyer la ressource à mettre à jour. PUT pose tout de même 3 problèmes : <ul> <li>Il est nécéssaire de faire un GET au préalable afin d'obtenir la totalité de la ressource</li> <li>Il faut s'assurer que la ressource n'a pas été modifiée côté serveur entre le GET et le PUT</li> <li>Il faut envoyer l'intégralité de la ressource, y compris les champs qui restent inchangés.</li> </ul> La méthode PUT apparait ne pas être la solution idéale pour effectuer une mise à jour partielle. Certaines API proposent d'exposer directement chaque champ de la ressource et d'utiliser PUT pour faire la mise à jour : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PUT /users/jeromepin/age </td></tr><tr><td>2</td><td> </td></tr><tr><td>3</td><td>24 </td></tr></tbody></table></code></pre> C'est une solution simple mais qui rajoute beaucoup de complexité dans l'API. Et si le client souhaite mettre à jour plusieurs informations, il doit effectuer plusieurs appels PUT. La solution n'est toujours pas là. Heureusement, la <a href="https://tools.ietf.org/html/rfc5789">RFC 5789</a> propose un verbe HTTP conçu pour les mises à jour partielles : PATCH <h2 id="patch-mauvais-usage">PATCH: mauvais usage</h2> PATCH permet donc de modifier partiellement une ressource donnée. Ainsi beaucoup d'APIs ont ajouté le support de ce verbe au travers d'appels tels que : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PATCH /users/jeromepin </td></tr><tr><td>2</td><td> </td></tr><tr><td>3</td><td>age=25 </td></tr></tbody></table></code></pre> ou encore : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PATCH /users/jeromepin </td></tr><tr><td>2</td><td> </td></tr><tr><td>3</td><td>{ "age" : "25" } </td></tr></tbody></table></code></pre> CE N'EST PAS LE RÔLE DE PATCH ! PATCH ne doit pas envoyer une partie d'une ressource. <h2 id="patch-er-correctement">PATCH-er correctement</h2> Le but de PATCH n'est pas seulement de mettre à jour une ressource. En réalité, ce n'est pas du tout la façon dont PATCH doit fonctionner. La RFC indique : <blockquote> The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. </blockquote> Il est clairement indiqué que PATCH, contrairement à PUT qui envoi la nouvelle ressource dans son intégralité, doit envoyer une liste d'instructions décrivant la façon selon laquelle la ressource située sur le serveur doit être modifiée. Une requête PATCH ressemble à ça : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PATCH /users/jeromepin HTTP/1.1 </td></tr><tr><td>2</td><td>Host: www.example.com </td></tr><tr><td>3</td><td>Content-Type: application/example </td></tr><tr><td>4</td><td> </td></tr><tr><td>5</td><td>[description of changes] </td></tr></tbody></table></code></pre> <code>[description of changes]</code> est appelé "patch document" (ou plus simplement "patch"). Le format de ce patch n'est pas défini dans cette RFC est peut-être de n'importe quel type comme par exemple la sortie de la commande <code>diff</code> : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PATCH /users/jeromepin HTTP/1.1 </td></tr><tr><td>2</td><td>Host: www.example.com </td></tr><tr><td>3</td><td>Content-Type: application/diff </td></tr><tr><td>4</td><td> </td></tr><tr><td>5</td><td>--- old-json 2019-04-01 12:02:50.000000000 +0200 </td></tr><tr><td>6</td><td>+++ new-json 2019-04-01 12:03:00.000000000 +0200 </td></tr><tr><td>7</td><td>@@ -1,4 +1,4 @@ </td></tr><tr><td>8</td><td>{ </td></tr><tr><td>9</td><td> "name": "Jerome Pin", </td></tr><tr><td>10</td><td>- "age": 24 </td></tr><tr><td>11</td><td>+ "age": 25 </td></tr><tr><td>12</td><td>} </td></tr></tbody></table></code></pre> Le <code>Content-Type</code> du PATCH doit être adapté au format du patch envoyé. Le serveur DOIT appliquer la totalité des changements de la requête de façon atomique et ne jamais fournir (c.à.d enregistrer en base ou retourner à un client) la ressource partiellement modifiée. Si le patch ne peut pas être appliqué dans sa totalité, alors il ne doit pas être appliqué du tout. <h3 id="quel-format-pour-un-patch">Quel format pour un patch ?</h3> La RFC 5789 est très souple et n'indique pas de type spécifique pour le format du patch, ainsi, c'est au serveur de veiller à supporter le type de patch approprié aux documents qu'il manipule. Heureusement, pour la manipulation de documents JSON (issus par exemple de base de données orientées documents), les RFC <a href="https://tools.ietf.org/html/rfc6901">6901</a> et <a href="https://tools.ietf.org/html/rfc6902">6902</a> définissent respectivement les termes "JSON Pointer" et "JSON Patch". Un "JSON Pointer" défini une syntaxe sous forme de chaine de caractères pour identifier une valeur spécifique au sein d'un objet JSON : <code>/users/0/email</code>. Un "JSON Patch" défini la structure d'un document JSON permettant d'exprimer une série de modifications à appliquer à un document JSON : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>[ </td></tr><tr><td>2</td><td> { "op": "test", "path": "/a/b/c", "value": "foo" }, </td></tr><tr><td>3</td><td> { "op": "remove", "path": "/a/b/c" }, </td></tr><tr><td>4</td><td> { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, </td></tr><tr><td>5</td><td> { "op": "replace", "path": "/a/b/c", "value": 42 }, </td></tr><tr><td>6</td><td> { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, </td></tr><tr><td>7</td><td> { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } </td></tr><tr><td>8</td><td>] </td></tr></tbody></table></code></pre> Avec ces deux nouvelles RFC, il est possible d'effectuer une requête PATCH pour enfin modifier un document JSON : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PATCH /users/jeromepin HTTP/1.1 </td></tr><tr><td>2</td><td>Host: www.example.com </td></tr><tr><td>3</td><td>Content-Type: application/json-patch+json </td></tr><tr><td>4</td><td> </td></tr><tr><td>5</td><td>[ </td></tr><tr><td>6</td><td> { "op": "replace", "path": "/age", "value": "25" } </td></tr><tr><td>7</td><td>] </td></tr></tbody></table></code></pre> Dans le cas où le serveur manipule du XML, une <a href="http://tools.ietf.org/html/rfc5261">RFC</a> décrit un format équivalent au JSON-Patch. <h2 id="conclusion">Conclusion</h2> Cet usage de PATCH reste très peu connu. Il est censé être le standard à utiliser pour des mises à jour partielles, mais il est facile de s'aperçevoir qu'un tel fonctionnement complexifie la gestion du serveur et la façon dont nous avons l'habitude d'utiliser les verbes plus traditionnels (GET, POST, PUT). La RFC étant très souple, il est tout à fait possible d'utiliser son propre format de patch, ainsi pour incrémenter l'age, il est possible de faire quelque chose comme : <pre data-linenos data-lang="json" style="background-color:#fafafa;color:#61676c;" class="language-json "><code class="language-json" data-lang="json"><table><tbody><tr><td>1</td><td>PATCH /users/jeromepin HTTP/1.1 </td></tr><tr><td>2</td><td>Host: www.example.com </td></tr><tr><td>3</td><td>Content-Type: application/custom-format+json </td></tr><tr><td>4</td><td> </td></tr><tr><td>5</td><td>[ </td></tr><tr><td>6</td><td> { "increment": "age" } </td></tr><tr><td>7</td><td>] </td></tr></tbody></table></code></pre> Évidemment, d'un point de vue conceptuel, il faut alors se demander si cette façon d'envoyer des actions plutôt que des états est compatible avec la philosophie REST ? N'est-ce pas plus proche de RPC ? </article> <article> <h1>Construire de bons microservices</h1> 2018-09-02T14:51:00+01:00 <h2 id="configuration">Configuration</h2> La configuration d'un service doit être optionnelle et tous ses paramètres doivent avoir une valeur par défaut : <pre data-linenos data-lang="javascript" style="background-color:#fafafa;color:#61676c;" class="language-javascript "><code class="language-javascript" data-lang="javascript"><table><tbody><tr><td>1</td><td>const ELASTICSEARCH_HOST = process.env.ELASTICSEARCH_HOST || 'localhost'; </td></tr></tbody></table></code></pre> Ou encore : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>ELASTICSEARCH_HOST=${$ELASTICSEARCH_HOST:-localhost} </td></tr></tbody></table></code></pre> Chaque élément de configuration doit être modifiable par une variable d'environnement correctement nommée. L'intérêt est de permettre de changer le comportement de l'application au runtime plutôt qu'au buildtime. De plus, l'usage d'orchestrateurs de conteneurs comme Docker Swarm ou Kubernetes rendent plus pratique le passage de variables d'environnement que de fichiers de configuration. <pre data-linenos data-lang="yaml" style="background-color:#fafafa;color:#61676c;" class="language-yaml "><code class="language-yaml" data-lang="yaml"><table><tbody><tr><td>1</td><td>apiVersion: v1 </td></tr><tr><td>2</td><td>kind: Pod </td></tr><tr><td>3</td><td>metadata: </td></tr><tr><td>4</td><td> name: foo </td></tr><tr><td>5</td><td>spec: </td></tr><tr><td>6</td><td> containers: </td></tr><tr><td>7</td><td> - name: foo </td></tr><tr><td>8</td><td> image: foo:1.0 </td></tr><tr><td>9</td><td> env: </td></tr><tr><td>10</td><td> - name: ELASTICSEARCH_HOST </td></tr><tr><td>11</td><td> value: "elasticsearch.example.com" </td></tr></tbody></table></code></pre> <h2 id="signaux-et-fermeture">Signaux et fermeture</h2> Une application doit être en mesure de réagir aux <a href="http://man7.org/linux/man-pages/man7/signal.7.html">signaux</a> envoyés par l'OS et en tirer parti. Par exemple, <a href="https://prometheus.io">Prometheus</a> recharge sa configuration à la réception d'un SIGHUP : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ kill -HUP 1234 </td></tr><tr><td>2</td><td>INFO[1234] Loading configuration file prometheus.yml source=main.go:201 </td></tr><tr><td>3</td><td>INFO[1234] Stopping target manager... source=targetmanager.go:281 </td></tr><tr><td>4</td><td>INFO[1234] Target manager stopped. source=targetmanager.go:216 </td></tr><tr><td>5</td><td>INFO[1234] Starting target manager... source=targetmanager.go:122 </td></tr></tbody></table></code></pre> L'application doit s'éteindre proprement lorsqu'elle reçoit un <code>SIGTERM</code>. Elle doit pouvoir nettoyer tous les éléments externes dont elle a eu besoin : connections ouvertes, caches utilisés, fichiers ouverts, fichiers temporaires créés, etc... <h2 id="logs">Logs</h2> La gestion des logs est souvent bien plus complexe que ce que l'on pense. Il est donc généralement intéressant de faire usage d'une librairie dédiée. Cette librairie est en charge de différents paramètres : <ul> <li>format : JSON, clé-valeur</li> <li>contexte : date et heure, module émétteur</li> <li>export : réseau (<code>tcp/udp</code>, <code>http</code>, <code>kafka</code>, ...), <code>syslog</code>, fichiers</li> <li>rotation</li> </ul> Dans le cas d'un microservice, l'application ne doit pas s'occuper du routage et du stockage de ses logs. Elle doit simplement écrire dans <code>stdout</code> et <code>stderr</code> en fonction des besoins, et laisser un routeur de logs (comme <a href="https://github.com/fluent/fluentd">fluentd</a> ou <a href="https://www.elastic.co/products/beats/filebeat">filebeat</a>) gérer et acheminer les logs. Chaque message de log doit être associé au bon niveau (<code>debug</code>, <code>info</code>, <code>warn</code>, <code>error</code>, ...) pour qu'il puisse être affiché et/ou traité de façon optimale. Il peut être intéressant d'afficher un message pour certains cas : <ul> <li>Message de démarrage de l'application;</li> <li>Ports sur lesquels elle écoute;</li> <li>Services auxquels elle est connectée;</li> <li>Évènements prévus et imprévus;</li> <li>Signaux reçus;</li> <li>Fermeture;</li> </ul> <blockquote> [foo] [INFO] Listening on port 80 </blockquote> <blockquote> [foo] [INFO] Connected to mysql://foo:bar@host:port/database. Alive and kicking ! </blockquote> <blockquote> ... </blockquote> <blockquote> [foo] [INFO] SIGHUP received. Reloading configuration </blockquote> <blockquote> ... </blockquote> <blockquote> [foo] [INFO] Shutting down... Closing connexions, removing temporary files </blockquote> <h2 id="choix-du-langage">Choix du langage</h2> <h3 id="eviter-les-langages-a-machines-virtuelles">Éviter les langages à machines virtuelles</h3> Les langages basés sur des machines virtuelles (Java, Clojure, Erlang, .NET) sont plus lents à démarrer et ont nécessairement besoin de plus de ressources. De plus, ces machines virtuelles sont généralement conçues pour gérer de large applications monolithiques qui ont besoin de fonctionnalités avancées de gestion de mémoire, de CPU, de threads, etc... Ces fonctionnalités sont redondantes avec les orchestrateurs et les runtimes et peuvent créer des conflits, comme par exemple la JVM qui ne supporte pas (ou mal) les limites de CPU et de mémoire définies dans un conteneur. Seules les <a href="https://bugs.openjdk.java.net/browse/JDK-8196595">versions les plus récentes du JDK 10</a> permettent une prise en charge correcte de ces paramètres. <h3 id="creer-des-binaires-statiques">Créer des binaires statiques</h3> Utiliser un langage qui crée des binaires statiques présente plusieurs avantages : <ul> <li>le binaire est portable : les librairies liées sont distribuées avec le binaire;</li> <li>il n'est pas nécessaire d'avoir une arborescence complète d'un OS (<code>/bin</code>, <code>/usr/bin</code>, <code>/tmp</code>, etc...) pour exécuter le binaire;</li> <li>la construction du binaire est prévisible;</li> <li>le binaire est moins sensible aux contaminations de ses librairies par des tierces-parties;</li> </ul> C'est avec toutes ces contraintes que des langages comme <a href="https://golang.org/">Go</a> et <a href="https://www.rust-lang.org/">Rust</a> ont vu leur popularité croître énormément ces dernière années. Pour un même programme C++ : <pre data-linenos data-lang="cpp" style="background-color:#fafafa;color:#61676c;" class="language-cpp "><code class="language-cpp" data-lang="cpp"><table><tbody><tr><td>1</td><td>#include <iostream> </td></tr><tr><td>2</td><td> </td></tr><tr><td>3</td><td>int main() { </td></tr><tr><td>4</td><td> std::cout << "Foo"; </td></tr><tr><td>5</td><td> return 0; </td></tr><tr><td>6</td><td>} </td></tr></tbody></table></code></pre> Le binaire compilé dynamiquement pèse 7.8Ko contre 1.6Mo statiquement. La différence vient de la présence (ou non) des librairies nécessaires au sein du binaire. La commande <code>ldd</code> permet de connaître les librairies liées au binaire : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ g++ -o foo foo.cpp </td></tr><tr><td>2</td><td>$ ldd foo </td></tr><tr><td>3</td><td> linux-vdso.so.1 (0x00007fffc9ff8000) </td></tr><tr><td>4</td><td> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6c9c4b6000) </td></tr><tr><td>5</td><td> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6c9c1b5000) </td></tr><tr><td>6</td><td> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6c9bf9f000) </td></tr><tr><td>7</td><td> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c9bbf4000) </td></tr><tr><td>8</td><td> /lib64/ld-linux-x86-64.so.2 (0x00007f6c9c7c1000) </td></tr></tbody></table></code></pre> Mon binaire <code>foo</code> requiert notamment <code>libstdc++.so.6 </code> (<code>/usr/lib/x86_64-linux-gnu/libstdc++.so.6</code>) et <code>libc.so.6</code> (<code>/lib/x86_64-linux-gnu/libc.so.6</code>). Si je distribue ce binaire sur une autre machine, il faudra non seulement qu'elle tourne sur le même OS, mais aussi que les librairies soient les mêmes (chemin et version) : <pre data-linenos data-lang="bash" style="background-color:#fafafa;color:#61676c;" class="language-bash "><code class="language-bash" data-lang="bash"><table><tbody><tr><td>1</td><td>$ mv /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6.old </td></tr><tr><td>2</td><td>$ ./foo </td></tr><tr><td>3</td><td>./foo: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory </td></tr></tbody></table></code></pre> <h2 id="stateless-vs-stateful">Stateless vs Stateful</h2> Un bon conteneur est un conteneur que l'on peut déplacer et redémarrer à la demande, sans pré-requis. Il faut donc qu'il soit le plus possible <code>stateless</code> : toutes les données persistantes dont a besoin l'application doivent être stockées dans des systèmes externes comme une base de données. Il ne doit pas y avoir de différence entre plusieurs instances d'une application. <h2 id="robustesse-healthchecks-et-timeouts">Robustesse, healthchecks et timeouts</h2> L'application doit être en mesure de gérer les erreurs via une dégradation de service ou via du back-off plutôt que de crasher. Elle doit pouvoir non-seulement répondre à des health checks (via une route http par exemple) mais aussi en émettre afin de surveiller la disponibilité des services liés. À un stade plus avancé, l'application doit supporter des mécanismes plus complexes comme les timeouts, le throttling et les <a href="https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern">circuit-breakers</a>. </article> <article> <h1>Sharding : Propriétés et fonctionnement</h1> 2018-07-12T08:54:00+01:00 Le sharding (aussi souvent nommé horizontal partitioning) est une méthode de séparation des données d'une base de données en plusieurs groupes logiques, généralement répartis sur plusieurs nœuds d'un cluster. Le sharding a plusieurs avantages : <ul> <li>dépasser les limitations d'une machine seule (CPU, stockage, etc...);</li> <li>effectuer des traitements concurrents;</li> <li>limiter la diffusion d'une requête à un sous-set de données;</li> </ul> Le sharding est souvent implémenté au niveau de la base de donnée elle-même (comme <a href="https://www.elastic.co/guide/en/elasticsearch/reference/6.2/_basic_concepts.html#getting-started-shards-and-replicas">Elasticsearch</a>, Cassandra ou <a href="https://docs.mongodb.com/manual/sharding/">MongoDB</a>) mais peut aussi l'être au niveau applicatif pour supporter des bases de données où le sharding n'est pas natif (comme <a href="https://redis.io/topics/partitioning">Redis</a>). Il existe plusieurs stratégies pour distribuer des données dans plusieurs base de données. Chacune a ses avantages et ses inconvénients et doit être choisie avec soin en fonction des besoins et des contraintes. Quelle que soit la stratégie choisie, il faut toujours prendre en compte les possibles hotspots : une distribution inégale des données entraine une surutilisation de certains shards et réduit presque à néant l'intérêt du sharding. <h2 id="principes-de-base">Principes de base</h2> <h3 id="notions">Notions</h3> <ul> <li>clé de shard : (shard key) Suite de caractères qui identifie de façon unique un shard.</li> <li>shard logique : (logical shard) Ensemble de données stockées sur un seul nœud et partageant la même clé de shard.</li> <li>shard physique : (physical shard) Un nœud du cluster, il peut contenir plusieurs shards logiques.</li> </ul> <h3 id="comment-les-donnees-sont-lues-et-ecrites">Comment les données sont lues et écrites</h3> Les bases de données sont utilisées pour stocker des données. Par conséquent le choix de la stratégie de sharding dépend de ces accès. Il s'agit de définir à l'avance les <a href="https://landing.google.com/sre/sre-book/chapters/service-level-objectives/">SLOs</a> : <ul> <li>Quelle est la distribution entre la lecture et l'écriture ? (50/50, 80/20, etc...)</li> <li>Quels volumes sont gérés ?</li> <li>Quels sont les objectifs de performance ? (latence, vitesse, etc...)</li> </ul> <h3 id="comment-les-donnees-sont-distribuees">Comment les données sont distribuées</h3> Les hotspot contrebalancent presque totalement l'intérêt du sharding. Il faut donc choisir avec soin le critère sur lequel les données vont être distribuées. Se baser sur une clé trop commune et non-uniformément distribuée va créer un déséquilibre dans la répartition de nos données. Par exemple, dans une base de données qui stocke des documents utilisateurs, distribuer les données en se basant sur l'identifiant de l'utilisateur est une mauvaise idée. Si un utilisateur enregistre beaucoup plus de documents que les autres, le shard auquel il est associé va croître fortement. Que va-t-il se passer lorsque ce shard dépassera la taille d'un nœud ? Comment ce shard va impacter les performances du reste du cluster ? <h3 id="comment-gerer-la-redistribution-des-donnees">Comment gérer la redistribution des données</h3> Une fois que les questions ci-dessus sont traitées, que le cluster fonctionne et que l'utilisation prend de l'ampleur, un premier problème survient : comment ajouter/modifier/supprimer des nœuds sans affecter les performances ? Lors de la modification de l'état du cluster, les données stockées vont devoir être redistribuées et il va falloir en déplacer de grandes quantités rapidement sans avoir d'incidence sur les performances. <h2 id="sharding-algorithmique">Sharding algorithmique</h2> Le sharding algorithmique (aussi nommé Client side partitioning) permet au client de déterminer le shard sans aide extérieure, en se basant uniquement sur une fonction généralement de la forme <code>hash(key) % num_nodes</code>. <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-routing-field.html">Elasticsearch</a> utilise cette stratégie pour définir sur quel shard doit se trouver un document : <pre style="background-color:#fafafa;color:#61676c;"><code>shard_num = hash_murmur3(doc._id) % num_primary_shards </code></pre> Le sharding algorithmique distribue les données en se basant uniquement sur cette fonction, et ne prend en compte aucun paramètre extérieur comme le taux d'utilisation d'un nœud, la taille de la donnée à traiter, etc... Redistribuer les données peut s'avérer complexe : cela requiert non seulement de déplacer les données mais aussi de mettre à jour la fonction utilisée. La fonction idéale ne devrait pas nécessiter de déplacer plus de <code>1/n</code> données et ne devrait pas déplacer des données qui n'ont pas besoin de l'être. <h2 id="sharding-dynamique">Sharding dynamique</h2> Le sharding dynamique (parfois nommé Proxy assisted partitioning) nécessite un service externe pour déterminer l'emplacement d'une donnée. Ce service agit comme un annuaire et indique la correspondance entre une clé (ou un ensemble de clés) et le shard sur lequel cette clé est assignée. Par exemple, <a href="https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#NameNode_and_DataNodes">HDFS</a> utilise un Namenode pour stocker ses métadonnnées. <table><thead><tr><th>range</th><th>shard</th></tr></thead><tbody> <tr><td>0, 3</td><td>0</td></tr> <tr><td>4, 7</td><td>1</td></tr> <tr><td>8, B</td><td>2</td></tr> <tr><td>C, F</td><td>3</td></tr> </tbody></table> Pour lire ou écrire une donnée, les clients ont nécessairement besoin de contacte le service de localisation. Celui va ensuite contacter la base de données elle-même, faisant office de proxy. Ce service externe permet de mieux gérer les données non-uniformément distribuées puisque les ensembles de clés n'ont pas besoin d'être de taille identique mais peuvent varier en fonction des besoins. En revanche, il devient aussi un point de défaillance unique : chaque lecture ou écriture a besoin d'y accéder, il faut donc que la stabilité et les performances soient au rendez-vous. Il ne peut pas être caché ni dupliqué facilement : des données obsolètes causeraient un désastre sur le cluster. <h2 id="conclusion">Conclusion</h2> Le sharding ajoute de la complexité non seulement en termes de développement mais aussi d'opérations : les données ne sont plus stockées au même endroit, le réseau introduit de la latence, la topologie change, plus de serveurs doivent être configurés, etc... Le sharding ne doit pas être le premier axe d'amélioration. Bien connaître les données que à stocker et la façon dont elles vont être utilisées est beaucoup plus important. Utiliser un serveur plus puissant suffit souvent à régler les problèmes de performances tant que l'échelle reste modérée. Si l'application est limitée par les performances de lecture de la base de données, ajouter des caches ou des replicas de lecture peut corriger le problème sans ajouter trop de complexité. Enfin, il est important de s'assurer que les données sont organisées de façon optimale : les blobs sont sur un stockage externe (système de fichier, stockage objets, etc...), l'analyse et la recherche sont délégués à d'autres systèmes, etc... </article> </main></body></html>$

Jérôme Pin

Terraform at LumApps: Part 4 - Chasing performance

Moments d'inertie d'une raquette de tennis