Sujet : configuration
-
Écrire des scripts d'administration idempotents : vérifier avant de modifier, fichiers drop-in et commentaires de repère
Un script d'administration qu'un agent peut relancer après un échec partiel ou une exécution planifiée répétée doit laisser le système dans le même état, qu'il s'exécute une fois ou cinq fois. Trois pratiques le garantissent : vérifier l'état actuel avant toute modification, écrire des fichiers drop-in séparés plutôt que d'éditer des fichiers partagés, et délimiter par des repères tout bloc dont le script est propriétaire.
-
Tracer une valeur de configuration de sa déclaration jusqu'au comportement effectif à l'exécution
Expliquer pourquoi la modification d'un fichier de configuration a changé, ou non, le comportement de l'application, en traçant la valeur à travers son chemin réel de chargement et de surcharge.
-
ConfigMaps et Secrets dans Kubernetes : limites de taille, propagation des mises à jour et ce qu'un Secret ne protège pas
Les ConfigMaps et les Secrets sont tous deux des objets clé-valeur plafonnés à 1 Mio ; les clés montées en volume se rafraîchissent après un délai de synchronisation du kubelet, alors que les variables d'environnement ne se rafraîchissent jamais, les montages subPath ne se mettent jamais à jour, et un Secret n'est encodé qu'en base64 et stocké non chiffré dans etcd, sauf si le chiffrement au repos et le RBAC sont configurés.
-
Faire progresser un même build à travers les environnements : promotion de configuration et parité dev-prod
Construire un artefact une seule fois, lui donner une identité immuable, et faire progresser cet artefact exact du test à la préproduction puis à la production en ne changeant que la configuration propre à chaque environnement ; maintenir les environnements semblables en services annexes et en topologie, afin qu'une étape réussie soit prédictive de la suivante.
-
Tester les changements de configuration qui modifient l'autorité d'un autre utilisateur
Repérer les écritures de configuration qui accordent indirectement des permissions, même lorsque leur point d'accès ressemble à une simple modification de paramètres. Cette proposition suit le changement d'autorité qui en résulte, plutôt que de juger du risque d'après le nom de la route.
-
L'Object Data Manager : pourquoi la configuration des périphériques et du système AIX ne se trouve pas dans un fichier
AIX stocke les définitions de périphériques, les entrées des sous-systèmes SRC et de nombreux attributs système sous forme d'objets dans la base Object Data Manager (ODM), sous /etc/objrepos et /usr/lib/objrepos, et non dans des fichiers texte modifiables. lsattr, lsdev et chdev sont l'interface prise en charge ; chdev -P reporte une modification au prochain redémarrage au lieu de l'appliquer immédiatement.
-
Modifier la configuration d'un service géré par SMF avec svccfg plutôt qu'en éditant son fichier de configuration
svccfg listprop et setprop lisent et écrivent la configuration persistante d'un service dans le dépôt SMF ; svcadm refresh la copie dans l'instantané d'exécution. Lorsque SMF génère le fichier de configuration d'un service (par exemple /etc/resolv.conf à partir de network/dns/client), toute modification manuelle de ce fichier est écrasée.
-
Docker Compose pour le développement local : fichiers de surcharge, profils, dépendances saines et watch
Garder un compose.yaml unique et versionné qui reflète la forme de la production, ajouter un compose.override.yaml pour les ports locaux et les montages liés, réserver les outils optionnels derrière des profils, faire attendre depends_on jusqu'à service_healthy, et utiliser develop.watch pour synchroniser ou reconstruire lors des changements de fichiers.
-
Gérer les secrets en dehors du dépôt
Les identifiants d'accès doivent se trouver dans une configuration protégée, injectée à l'exécution – jamais dans le contrôle de version, dans des images ni dans des journaux ; chaque service reçoit ses propres identifiants, étroitement délimités, et la rotation est une procédure entraînée plutôt qu'une urgence. Les étapes suivent le cheat sheet OWASP sur la gestion des secrets et la séparation Twelve-Factor entre configuration et code.
-
Valeurs par défaut sécurisées et conception à échec fermé
Le principe des valeurs par défaut à sécurité intégrée de Saltzer et Schroeder fonde l'accès sur une permission explicite, de sorte qu'une erreur refuse plutôt qu'elle n'accorde ; appliqué aujourd'hui, cela signifie une autorisation qui refuse par défaut, une configuration qui refuse de démarrer lorsqu'un paramètre de sécurité manque, et des chemins d'erreur qui ferment l'accès plutôt que de l'ouvrir.
-
Typage implicite de YAML 1.1 et 1.2 : le problème de la Norvège, les nombres octaux et quels parseurs suivent quelle version
Le type booléen de YAML 1.1 traite yes, no, on et off comme des booléens et un zéro initial comme un octal ; le Core Schema de YAML 1.2 restreint les booléens à true/false et exige le préfixe explicite 0o pour l'octal. PyYAML, js-yaml et gopkg.in/yaml.v3 se situent chacun à un endroit différent entre les deux.
-
Définir des paramètres du noyau Linux avec sysctl : modifications à chaud ou via /etc/sysctl.d
`sysctl -w` modifie un paramètre du noyau jusqu'au prochain redémarrage ; pour le rendre persistant, il faut déposer un fichier dans /etc/sysctl.d/ et comprendre l'ordre de chargement entre /usr/lib, /etc et /run. `sysctl --system` applique tous les fichiers configurés et indique lequel l'emporte en cas de conflit.
Lisible par machine : JSON