Poste de travail de développement

Ce guide construit un poste de travail Ubuntu 24.04 GNOME avec un ensemble d’outils conservateur et des tests fumée explicites. Les versions langage et éditeur suivent les sources de paquets sélectionnées sauf si vous épinglez et relisez une autre source.

Invite


Create an Ubuntu 24.04 GNOME development workstation with a dark color
scheme, SSH, Docker, Git, Python, Node.js, curl, jq, tmux, htop, and Neovim.
Create a locked-password user named dev with sudo and Docker group intent.
Do not add third-party repositories unless their HTTPS URL, signing key,
release support, and license are explicit. Add tests for the desktop session,
tool versions, Docker service, group membership, and one container smoke test.

Relire la recette


{
  "name": "ubuntu24-development-workstation",
  "base_image": "ubuntu-24.04",
  "os": {
    "features": ["desktop", "ssh", "docker", "git", "python", "nodejs"],
    "packages": ["curl", "jq", "tmux", "htop", "neovim"],
    "users": [
      {
        "username": "dev",
        "groups": ["sudo", "docker"],
        "shell": "/bin/bash"
      }
    ],
    "desktop_settings": {
      "color_scheme": "prefer-dark",
      "fonts": {
        "monospace_font": "Ubuntu Mono 13"
      },
      "power": {
        "idle_delay": 600,
        "sleep_inactive_ac_timeout": 0,
        "sleep_inactive_ac_type": "nothing"
      }
    }
  }
}

Confirmez que chaque fonctionnalité s’étend sur Ubuntu 24.04 comme prévu. L’appartenance au groupe docker est couramment équivalente root car elle peut contrôler le démon Docker ; retirez-la si l’utilisateur ne doit pas avoir cette autorité.

Versions et sources

Ne demandez pas « latest » sur un poste contrôlé. Enregistrez les versions réellement disponibles depuis l’instantané sélectionné et testez ces versions. Un dépôt éditeur ou installateur bootstrap ajoute une racine de confiance et un cycle de mise à jour séparés ; utilisez-le seulement après relecture de sa clé, métadonnées de dépôt, conditions et comportement de rollback.

Des outils comme Rustup, gestionnaires de version langage, extensions d’éditeur et images conteneur peuvent télécharger du code mobile après le build de l’image. S’ils comptent pour la baseline du poste, épinglez-les et incluez leur provenance dans le dossier de preuves.

Scénario de vérification


{
  "id": "development-smoke",
  "name": "Development workstation smoke test",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "custom_tests": [
    {
      "description": "Confirm core tools and Docker are usable.",
      "assertions": [
        {
          "type": "command_succeeds",
          "description": "Python reports a version.",
          "params": {"command": "python3 --version"}
        },
        {
          "type": "command_succeeds",
          "description": "Node.js reports a version.",
          "params": {"command": "node --version"}
        },
        {
          "type": "service_running",
          "description": "The Docker daemon is running.",
          "params": {"service": "docker"}
        },
        {
          "type": "user_in_group",
          "description": "The dev account has the reviewed Docker authority.",
          "params": {"username": "dev", "group": "docker"}
        }
      ]
    }
  ]
}

Ajoutez une assertion GUI pour chaque éditeur graphique que vous installez réellement. Une vérification de paquet ne détecte pas un premier lancement cassé, une boîte de dialogue de licence, une intégration affichage manquante ou un mauvais bureau par défaut.

Enfin, testez la connexion avec le chemin d’enrollment ou clé SSH approuvé ; la recette ne contient intentionnellement pas de mot de passe.