Planifier le déploiement

Planifiez les vagues avant d’installer la première machine. La liste de la vague 1, le canal des vagues 2 et 3, et le responsable du retour arrière sont tous des réponses de la liste de contrôle des prérequis ; cette page les transforme en calendrier.

Trois vagues

Trois vagues de deux semaines chacune, chacune prouvant quelque chose dont la suivante dépend. La vague 1 prouve l’installation et la clé sur de vraies machines. La vague 2 prouve votre outil de déploiement. La vague 3 prouve le périmètre. N’élargissez jamais une vague avant que la précédente ne remplisse ses critères de sortie.

Chaque vague, pilote compris, s’inscrit avec une clé d’organisation : les personnes sur les machines n’ont donc besoin d’aucun compte console. Déployer le client présente les voies.

Attribut	Vague 1	Vague 2	Vague 3
Périmètre	Une dizaine de machines	Une cinquantaine de machines	Le périmètre complet
Voie d’installation	Clé d’organisation, à la main sur chaque machine ou avec une première recette	Clé d’organisation, sans intervention, par votre outil de déploiement	Clé d’organisation, sans intervention, par votre outil de déploiement
Durée	Deux semaines	Deux semaines	Deux semaines
Activité	Inscrire chaque machine avec la clé de la vague, la vérifier, relancer les agents qui attendent encore la personne qui les utilise, et noter ce que les personnes rencontrent	Empaqueter l’installation, la prouver sur une machine de chaque système d’exploitation, puis la lancer sans intervention et lire le rapport qu’elle collecte	Lancer le même paquet sur tout le périmètre, et relancer les machines qui ne remontent jamais rien
Critères d’entrée	L’organisation est configurée, et la clé d’organisation de la vague est créée	La vague 1 a rempli ses critères de sortie, et la recette s’exécute proprement sur une machine de chaque système d’exploitation	Votre outil de déploiement est prouvé sur chaque système d’exploitation du parc, et le type de proxy est confirmé sur chaque sous-réseau concerné
Critères de sortie	Chaque machine inscrite remonte à la console dans les 24 heures suivant l’installation ; la vérification propre du client ne signale aucun problème sur chacune ; aucun agent n’attend encore la personne qui l’utilise ; la route du proxy est confirmée sur chaque système d’exploitation de la vague	Les quatre mêmes, plus chaque machine installée sans qu’un développeur ouvre un terminal	Les quatre mêmes, plus la décision de passer en exploitation courante
Retour arrière	openlatch uninstall sur la machine concernée ; la CA de relais reste approuvée sauf si vous ajoutez --purge	La même chose, livrée par l’outil qui a fait l’installation	La même chose, livrée par l’outil qui a fait l’installation

Figure 1. Six semaines, trois vagues : ce que prouve chacune, et le passage de l’une à l’autre.

Vérifier chaque machine et chaque vague décrit comment une machine, puis une vague, est prouvée au regard de ces critères.

Effort et calendrier

L’effort se concentre sur la première semaine, quand l’organisation est mise en place et la route prouvée sur une machine de chaque système d’exploitation du parc. Ensuite, chaque vague répète une procédure qui a déjà fonctionné.

Phase de travail	Vague 1	Vague 2	Vague 3	Effort habituel
Préparer la console	Connecter SAML, définir les domaines autorisés et la conservation de l’audit, inviter l’équipe de déploiement, créer la clé d’organisation de la vague 1	Créer la clé d’organisation de la vague 2	Créer la clé d’organisation de la vague 3, et transmettre la routine d’exploitation	Une journée la première semaine, puis quelques heures par semaine
Préparer le réseau	Approuver l’entrée de flux sortant et confirmer la route du proxy	Revoir la route par votre outil de déploiement	Aucun autre changement	Une demi-journée la première semaine
Préparer les machines	Prouver l’installation sur une machine par système d’exploitation, puis inscrire dix machines avec la clé de la vague	Porter l’installation dans le canal que vous exploitez déjà et lancer la vague	Étendre le même canal aux machines restantes	Quelques minutes par machine après la première
Confirmer et exploiter	Confirmer que chaque machine installée apparaît dans le registre des agents de la console, avec un propriétaire quand un annuaire est connecté	Point hebdomadaire et revue de l’outil de déploiement	Point hebdomadaire, puis décision de passer en exploitation courante	Un point hebdomadaire pendant tout le déploiement

Une clé par vague

Chaque vague s’inscrit avec sa propre clé d’organisation, créée à partir de Host enrollment : une clé à révoquer ne concerne ainsi qu’une seule vague. Une machine n’a besoin de la clé que pour s’inscrire : elle l’échange contre un identifiant d’hôte qui lui est propre, qui continue de fonctionner une fois la clé révoquée ou renouvelée.

Moment	Que faire de la clé
Avant la vague	En tant qu’admin ou owner, créez-la sous Settings › API keys à partir de Host enrollment, nommez-la d’après la vague et conservez-la dans votre coffre de secrets. Elle appartient à l’organisation : elle continue donc de fonctionner si vous partez
Pendant la vague	Livrez-la à chaque machine sous forme de fichier de clé, par --api-key-file ou OPENLATCH_API_KEY_FILE, ou sous le nom OPENLATCH_API_KEY dans l’environnement dans lequel l’installation s’exécute, jamais en ligne de commande. openlatch init supprime un fichier de clé une fois la machine inscrite
Avant la vague 1, facultatif	Faites approuver le certificat de relais de votre organisation à l’échelle de la machine, et vérifiez une machine par système d’exploitation avec openlatch doctor. Chaque vague livre ensuite le même bundle à côté de sa propre clé
Après la vague	Conservez-la seulement pour les inscriptions à venir. Les machines inscrites qui exécutent le client actuel ne l’utilisent plus ; une machine sur un client antérieur s’authentifie avec elle jusqu’à sa mise à jour
Pour la retirer	Attendez que la date de dernière utilisation de la clé cesse d’avancer après la dernière inscription de la vague, puis supprimez-la, ce qui la révoque. Une gestion des postes qui relance l’installation sur des machines pas encore inscrites a besoin d’une clé valide tant qu’elle fonctionne

Retour arrière

Désignez le responsable du retour arrière avant la vague 1 : la personne qui peut suspendre une vague et retirer le client d’une machine. La désinstallation se fait avec openlatch uninstall, lancée sur la machine ou livrée par l’outil qui a fait l’installation, et elle laisse chaque agent tel qu’il était. Elle conserve la CA de relais, toujours approuvée ; ajoutez --purge pour la retirer. Désinstaller couvre la désinstallation en entier.

En bref

• Trois vagues de deux semaines, toutes inscrites avec une clé d’organisation : une dizaine de machines, une cinquantaine par votre outil de déploiement, puis le périmètre. N’élargissez qu’une fois que la vague précédente remplit ses critères de sortie.
• La première semaine porte l’essentiel de l’effort : l’organisation, l’entrée de flux sortant, et l’installation prouvée sur une machine par système d’exploitation.
• Une clé d’organisation par vague, créée à partir de Host enrollment. Une machine n’en a besoin que pour s’inscrire ; révoquez-la une fois la vague inscrite sur le client actuel.
• Désignez un responsable du retour arrière avant la vague 1. La désinstallation se fait avec openlatch uninstall, machine par machine ; la CA de relais reste approuvée sauf si vous ajoutez --purge.