Unité 9 / 11

Génération de scripts et d'automatisation : Bash, Python et PowerShell

Gains :

  • Capacité à comprendre les points forts de Bash, Python et PowerShell et à demander à l'intelligence artificielle de produire des brouillons de script sûrs et protégés
  • Possibilité d'ajouter des garde-fous aux scripts tels que set -euo pipefail, la vérification des variables vides, le mode d'exécution à sec et la journalisation
  • Capacité à lire des commandes destructrices et à les essayer dans un environnement isolé et avec un essai à sec au préalable, et à appliquer la discipline consistant à ne pas intégrer le secret dans le script.

L’esprit du DevOps se résume en une phrase : « Automatisez le travail que vous effectuez deux fois ». Toute tâche répétitive effectuée manuellement (nettoyage des journaux, sauvegarde, vérification de l'état du serveur, traitement des fichiers par lots) prend du temps et est finalement corrompue par une erreur humaine. Les scripts prennent en charge ces tâches : de petits programmes qui exécutent une série de commandes de manière séquentielle, fiable et reproductible. Le professionnel DevOps utilise fréquemment trois langages : Bash (pour les scripts shell Linux/Unix), Python (pour la logique complexe, les appels d'API, la manipulation de données) et PowerShell (pour Windows et la gestion cloud).

L’IA est peut-être là où elle offre la valeur la plus pratique en matière de génération de scripts : produire une ébauche de travail à partir d’une description en une phrase, résoudre un bug mystérieux, traduire un script dans une autre langue. Mais un script est dangereux lorsqu'il est exécuté à l'aveugle : un mauvais rm, un Remove-Item -Recurse supprimera les fichiers de manière irréversible. C'est pourquoi la devise de cette unité est : Laissez l'IA écrire le script, vous le lisez, essayez-le d'abord en mode sans échec, puis exécutez-le.

Quelle langue choisir et quand ? En règle générale : si le travail consiste à exécuter plusieurs commandes système à la suite (copier un fichier, redémarrer un service, récupérer une archive), Bash est le choix le plus naturel car Linux est omniprésent sur les serveurs. Si le travail implique une logique de décision, un bouclage, une transformation de données, une demande d'API ou un traitement JSON (c'est-à-dire une logique dépassant 20 lignes), Python se distingue par sa lisibilité et ses bibliothèques riches ; Un script Bash complexe devient vite incompréhensible, tandis que Python reste facile à maintenir. Si le travail implique la gestion de serveurs Windows, Active Directory ou Azure, PowerShell est l'environnement naturel car sa nature orientée objet s'intègre profondément à ces plates-formes. Spécifier la langue que vous avez choisie et pourquoi lors de la demande d'un script à l'IA garantit que la sortie est appropriée et idiomatique pour votre environnement.

Pas à pas : génération de scripts sécurisés

  1. Décrivez la tâche et l'environnement. Que fera-t-il, quel OS/shell, quelles contraintes ?
  2. Demandez des garde-corps de sécurité. Dans bash, définissez -euo pipefail (arrêt en cas d'erreur, arrêt sur variable non définie), invite de confirmation pour les opérations dangereuses, déplacez-vous d'abord au lieu de supprimer.
  3. Demander le mode de fonctionnement à sec. Laissez le script écrire quoi faire avec --dry-run, mais ne le faites pas.
  4. Lisez et comprenez. Vérifiez ce que fait chaque ligne, en particulier les opérations de suppression/déplacement/réseau.
  5. Essayez-le dans un environnement isolé. Dans le dossier de test, exécutez-le avec des exemples de données.
  6. Ajouter à la journalisation. Laissez le script enregistrer ce qu'il fait afin de pouvoir le visualiser plus tard.

Éléments essentiels d'un script sécurisé

Un script de production doit inclure ces garde-fous :

  • Arrêt en cas d'erreur. Bash : définissez -euo pipefail. PowerShell : $ErrorActionPreference = 'Arrêter'. Si une étape échoue, les suivantes ne devraient pas fonctionner.
  • Idempotence (répétabilité). Si le script s'exécute deux fois, il ne devrait pas infliger deux fois plus de dégâts ; Logique "Si vous l'avez déjà, ignorez-le".
  • Approbation et essai à sec. Pour les opérations destructrices "tu es sûr ?" ou l'indicateur --dry-run.
  • Validation des entrées. Les paramètres sont-ils conformes aux attentes ? Une variable vide peut transformer rm -rf "$DIR"/ en rm -rf / désastre.
  • Enregistrement. Enregistrement de ce qui a été fait et quand.
Astuce : L'erreur la plus dangereuse dans Bash est la suppression avec une variable vide. rm -rf "$DIR" essaie de supprimer le répertoire racine si $DIR est vide. set -u (arrêt sur une variable non définie) et vérifier [ -n "$DIR" ] avant de supprimer est une bouée de sauvetage. Demandez explicitement ces protections lorsque vous demandez des scripts à l’IA.

Sécurité : commandes secrètes et destructrices

Deux grands dangers :

  1. Intégrer le secret dans le script. Le mot de passe ne doit pas être en texte brut dans le script du jeton ; Doit être lu à partir d'une variable d'environnement ou d'un coffre-fort. Les scripts vont dans Git ; Le secret enfoui est une fuite permanente.
  2. Commandes destructrices. rm -rf, Remove-Item -Recurse -Force, DROP TABLE, terraform destroy — lorsque vous les voyez dans un script, arrêtez-vous et réfléchissez-y à deux fois. N'essayez jamais en premier la commande destructrice générée par l'IA en prod.
Attention : lorsque vous dites à l'IA "d'écrire un script qui nettoie ces fichiers", lisez attentivement la portée de la commande find... -delete ou rm qu'elle produit. Un caractère générique (*) ou un mauvais chemin supprimera plus que ce que vous souhaitez supprimer. Exécutez toujours le script en premier avec le mode "liste à supprimer" au lieu de supprimer.

Comparaison de trois langues

critère

coup

Python

PowerShell

Où c'est le meilleur

Shell Linux, chaîne de commandes

Logique complexe, API, données

Gestion du cloud Windows

Courbe d'apprentissage

Moyen (piégé)

facile

moyen

Gestion des erreurs

set -euo pipefail

essayer/sauf

essayer/attraper, -ErrorAction

portabilité

Unix/Linux/mac

partout

Multiplateforme (PS 7+)

quand

Bref, le système fonctionne

Logique de plus de 20 lignes

Windows/AD/Azure

trois mini-cases

Cas 1 — 2 heures de bricolage en 5 minutes. Un ingénieur passait 2 heures à collecter et archiver les journaux de 40 serveurs chaque semaine. Il a demandé à l'IA de décrire la tâche, de définir -euo pipefail + protections contre la marche à sec et de générer un script Bash. J'ai d'abord validé le script avec un essai à sec, puis l'ai lié à la tâche planifiée (cron). Le travail hebdomadaire est réduit à 5 minutes et l’erreur humaine est éliminée.

Cas 2 : catastrophe de variable nulle évitée. Il y avait rm -rf "$TARGET"/* dans le script de nettoyage produit par l'IA, mais si TARGET n'était pas assigné quelque part, il restait vide. Il s’en est rendu compte alors qu’il étudiait comme ingénieur ; set -u et [ -n "$TARGET" ] || ajout du contrôle de sortie 1. Pendant les tests, la variable est restée nulle et le script s'est arrêté en toute sécurité plutôt que de manière catastrophique.

Cas 3 : jeton intégré capturé. Pour plus de commodité, AI a ajouté une ligne TOKEN = "ghp_realtoken" à un script Python qui demande une API (à titre d'exemple). L'ingénieur l'a supprimé et l'a modifié en lecture à partir de la variable d'environnement avec os.environ["TOKEN"] et a annulé et renouvelé le jeton. Si le script allait vers Git, le jeton serait public.

Quatre modèles copiables

1) Script Bash sécurisé :

Écrivez un script Bash : [TASK]. Règles obligatoires :- `set -euo pipefail` au début.- Vérifiez que la variable n'est pas vide partout où vous la supprimez/déplacez.- Drapeau `--dry-run` : écrivez ce qu'il faut faire dans ce mode mais ne le faites pas.- N'intégrez pas le secret ; Lire à partir de la variable d'environnement. - Imprimez un journal informatif à chaque étape. Commentez le script et marquez la ligne la plus dangereuse.

2) Description/contrôle du script :

Décrivez le script suivant ligne par ligne et vérifiez la sécurité : secret intégré, commande destructrice (rm/Remove-Item/DROP), entrée non validée, manque de gestion des erreurs ? Écrivez chaque risque par ordre d’importance et de correction. Scénario : [CODE]

3) Traduction linguistique :

Traduisez ce script [LANGUE SOURCE] en [LANGUE CIBLE]. Conservez le comportement textuellement, utilisez la gestion des erreurs idiomatiques de la langue cible, déplacez tous les secrets intégrés vers une variable d'environnement. Notez les points qui peuvent se comporter différemment.Script : [CODE]

4) Tâche planifiée (cron/tâche planifiée) :

Utilisez ce script [FRÉQUENCE : par ex. Écrivez une définition de planification ([cron / systemd timer / Windows Task Scheduler]) qui s'exécutera [à 02h00 tous les soirs]. Ajoutez comment m'avertir en cas d'échec (journal/code de sortie/notification) et comment éviter les chevauchements.

Invite faible/Invite forte

Faible : "Écrivez un script qui supprime les anciens fichiers."

Résultat : un script rm sans portée, non protégé et sans exécution à sec ; S'il s'exécute dans le mauvais dossier, il sera supprimé de manière irréversible.

Strong : "Écrivez un script bash pour supprimer les fichiers .log datant de plus de 30 jours sous /var/log/app. Utilisez set -euo pipefail, arrêtez si le répertoire cible est vide, listez d'abord ce qu'il faut supprimer avec --dry-run, enregistrez chaque transaction, n'intégrez pas le secret. Marquez la ligne la plus dangereuse. "

Différence : la deuxième affirmation donne la portée complète, les garde-corps de sécurité et les attentes en matière de fonctionnement à sec ; La sortie peut être exécutée en toute sécurité.

Erreurs courantes

  • Exécuter le script sans le lire. Supprimer/déplacer des lignes en particulier conduit à un désastre.
  • Ne pas vérifier les variables vides. Catastrophe classique de la suppression du répertoire racine avec rm -rf "$X"/.
  • ignorez `set -euo pipefail` / `-ErrorAction Stop`. Un pas se déclenche, le scénario continue à l'aveugle.
  • Intégrer le secret dans le script. Fuite persistante vers Git.
  • Processus destructif sans marche à sec. D'abord "montre-moi quoi faire", puis fais-le.
  • Faire le premier essai en prod. Fonctionnement sans environnement de test isolé.

En résumé

DevOps est l'art de l'automatisation ; Le travail répétitif est délégué aux scripts Bash, Python et PowerShell. L'IA est très pratique pour rédiger des scripts, déboguer et traduire des langues, mais un script sécurisé doit inclure des protections contre les erreurs telles que set -euo pipefail, la vérification des variables nulles, le mode d'exécution à sec, l'absence de secret intégré et la journalisation. Il est de votre responsabilité de lire et de tester chaque script, en particulier ceux contenant des commandes destructrices, dans un environnement isolé et de l'exécuter au préalable.

Tâche de candidature

Choisissez une tâche récurrente (archivage des logs, sauvegarde, nettoyage). (1) Demandez à l'IA de générer un script protégé avec le modèle "Secure Bash script". (2) Faites vérifier la sécurité du même script que le modèle « Description/audit du script » et recherchez la ligne la plus dangereuse signalée par l'IA. (3) Vérifiez son comportement en exécutant le script avec des exemples de fichiers dans un dossier de test, d'abord avec --dry-run.

liste de contrôle

  • [ ] J'ai écrit la tâche dont je ne veux pas, le système d'exploitation/shell et les garde-fous de sécurité.
  • [ ] Le script présente une erreur d'arrêt comme set -euo pipefail / -ErrorAction Stop.
  • [ ] J'ai ajouté une variable vide et une vérification des entrées avant la suppression/le déplacement.
  • [ ] Il existe un mécanisme --dry-run/confirmation pour les opérations destructrices.
  • [ ] Il n'y a aucun secret intégré dans le script ; les valeurs proviennent de la variable d'environnement/cas.
  • [ ] J'ai réalisé le premier test dans un environnement de test isolé avec simulation.