Opérations d’applications en file d’attente
Les API CICD qui doivent obtenir le verrou de mise à jour/mutex à l’échelle de l’instance pour effectuer les opérations demandées sont mises en file d’attente au lieu d’être rejetées lorsque le verrou/mutex à l’échelle de l’instance de mise à jour est occupé par les autres opérations.
À partir de , Tokyoles API CICD qui doivent obtenir le verrou de sécurité de l’instance/le mutex de mise à jour pour effectuer les opérations demandées seront mises en file d’attente au lieu d’être rejetées lorsque le verrou de sécurité/le mutex de mise à jour de l’instance est occupé par les autres opérations. Lorsqu’une demande CICD est reçue, le service CICD correspondant construit un message NowMQ (Now Message Queue) d’application et insère le message dans la file d’attente à l’aide d’API NowMQ. Les messages en file d’attente sont ensuite interrogés par la tâche planifiée et traités un par un ou en parallèle si le traitement parallèle est activé et que l’opération répond aux critères nécessaires.
Opération d’application Message NowMQ
Les messages NowMQ de l’opération d’application ont un objet commun qui est « sys.applifecycle.operation ». Le corps du message de l’opération d’application Le message NowMQ contient un objet JSON qui inclut le sys_id du suivi de l’exécution (également appelé ID de progression renvoyé dans la réponse d’API CICD), le type d’opération qui peut être l’un des suivants : app_install, plugin_activation, batch_install, rollback, import_app et apply_changes. Il contient également des informations telles que l’ID du module d’extension pour l’activation du module d’extension, l’ID de l’application ou le périmètre de l’installation de l’application.
Suivi de l’exécution pour le fonctionnement de l’application
Lorsque le message NowMQ d’opération d’application est créé et inséré, l’enregistrement de suivi d’exécution pour la demande CICD correspondante est créé et son sys_id est ajouté au corps du message NowMQ. Le suivi des exécutions est initialement dans l’état En attente. La colonne « Détails » du suivi des exécutions contient les informations sur le type d’opération et les paramètres d’entrée importants pour la demande CICD. Sa colonne « Message » contient les informations sur la position de la file d’attente. Lorsque la file d’attente est mise en pause, le message est précédé de « [La file d’attente des opérations de l’application est en pause] ».
Exemple de suivis d’exécution des opérations de l’application lorsque la file d’attente est en cours d’exécution.
Exemple de suivis d’exécution des opérations d’application lorsque la file d’attente est en pause.
Gérer la file d’attente des opérations de l’application
Alors que l’installation manuelle des produits à partir de Toutes les applications est en file d’attente, l’installation manuelle d’une application à partir de l’interface utilisateur comme Toutes les applications ou Gestionnaire d’applications n’est pas mise en file d’attente.
Parfois, l’instance peut recevoir, mettre en file d’attente et gérer de nombreuses demandes CICD, ce qui peut entraîner l’affamation de l’installation manuelle à partir de l’interface utilisateur pour le verrouillage de l’ensemble de l’instance/mutex. Lorsque cela se produit, l’administrateur peut suspendre temporairement la file d’attente des opérations de l’application.
L’administrateur peut gérer la file d’attente des opérations de l’application via la page d’interface utilisateur Diagnostics du système >File d’attente des opérations de l’application. Dans le panneau « État de la file d’attente de l’opération », l’administrateur peut mettre en pause ou reprendre la file d’attente. L’administrateur peut également annuler le suivi de l’exécution en attente, ce qui finira par supprimer le message mis en file d’attente correspondant de NowMQ par la tâche Surveillance de l’intégrité de la file d’attente des opérations de l’application.
Page de l’interface utilisateur File d’attente des opérations de l’application
Exemple de page d’interface utilisateur File d’attente des opérations d’application. L’administrateur peut cliquer sur le bouton dans « État de la file d’attente de l’opération » pour mettre en pause ou reprendre la file d’attente.
Cliquez sur l’élément de liste « Suivis de l’exécution des opérations de l’application », puis le formulaire Suivi de l’exécution s’ouvre. Si le message en file d’attente est en attente dans la file d’attente, mettez à jour l’état du suivi de l’exécution sur « Annulé » et enregistrer le changement annulera la demande CICD mise en file d’attente correspondante. Remarque : si l’état du suivi de l’exécution est « En cours d’exécution », la demande CICD ne peut pas être annulée.
File d’attente des opérations de l’application et fenêtre de mise à niveau
Par défaut, 2 heures (personalisables via la propriété système « com.glide.update_operation.queue_upgrade_window ») avant la mise à niveau planifiée, la file d’attente des opérations de l’application arrête de traiter les messages mis en file d’attente.
L’état de la file d’attente des opérations de l’application est changé en « Mise à niveau en pause ». Pendant cette période de mise à niveau, les nouvelles demandes CICD continuent d’être mises en file d’attente.
Lorsque la mise à niveau est terminée, la file d’attente des opérations de l’application reprend automatiquement le traitement des messages mis en file d’attente.
Impact sur le pipeline CICD
Les contrats de demande/réponse existants pour les API CICD ne sont pas modifiés. L’échec de l’opération dû à la mise à jour des conflits Verrou à l’échelle de l’instance/mutex observés dans une version antérieure à Tokyo ne sera pas visible. La demande est mise en file d’attente et servie une par une ou en parallèle selon le type de tâche.
API CICD prenant en charge la mise en file d’attente
- api/sn_cicd/app_repo/install
- api/sn_cicd/v1/app_repo/install
- api/sn_cicd/v2/app_repo/install
- api/sn_cicd/app_repo/rollback
- api/sn_cicd/v1/app_repo/install
- api/sn_cicd/v2/app_repo/rollback
- api/sn_cicd/sc/apply_changes
- api/sn_cicd/v1/sc/apply_changes
- api/sn_cicd/v2/sc/apply_changes
- api/sn_cicd/app/lot/install
- api/sn_cicd/sc/import
- api/sn_cicd/plugin/{plugin_id}/activate
- api/sn_cicd/plugin/{plugin_id}/rollback
Paralléliser les installations d’applications et les activations de module d’extension
- api/sn_cicd/app_repo/install
- api/sn_cicd/v1/app_repo/install
- api/sn_cicd/v2/app_repo/install
- api/sn_cicd/plugin/{plugin_id}/activate
Tout le traitement de la file d’attente prend un verrou/mutex à l’échelle de l’instance et conserve ce mutex jusqu’à ce qu’une opération en file d’attente soit terminée. Ce verrou s’appelle UpdateMutex, et son état peut être consulté dans la table sys_mutex . Pendant ce temps, les opérations qui prennent ce même verrou (installations d’applications, activations de modules d’extension, opérations de contrôle de source) ne sont pas exécutables via l’interface utilisateur. La file d’attente peut toujours être mise en pause via la page File d’attente des opérations de l’application pour libérer le verrou une fois que les tâches en cours d’exécution ont été terminées.
La parallélisation est activée par défaut. Il peut être désactivé à l’aide de la propriété com.glide.update_operation.parallel_operation_enabled, et toutes les opérations s’exécuteront séquentiellement à partir de la file d’attente comme dans les versions précédentes.
Limites de la parallélisation
Le processeur de file d’attente détermine si une tâche mise en file d’attente peut s’exécuter. Si une tâche peut s’exécuter, elle est planifiée pour être récupérée par un nœud d’instance lors de la première disponibilité. Dans le cas contraire, il est renvoyé dans la file d’attente et le processeur évalue la tâche suivante dans la file d’attente pour traitement.
Il existe une limite au nombre maximal de tâches pouvant être exécutées en parallèle, qui est définie par défaut sur 2. Cette propriété peut être activée/désactivée via glide.update.app_operation_queue.parallel.max mais gardez à l’esprit qu’il existe une limite supérieure de threads disponibles pour effectuer l’installation et qu’une parallélisation accrue nécessite de la mémoire supplémentaire qui peut ralentir l’instance pour les utilisateurs actifs.
Obtention de verrous de ressources
- Deux opérations qui partagent le même périmètre, y compris les personnalisations.
- Deux opérations au choix qui entraînent des changements de schéma.
- Deux opérations contenant des scripts correctifs.
Le traitement de la file d’attente détermine si ces critères sont remplis pour les opérations mises en file d’attente et reporte les tâches non traitables si nécessaire. L’ID d’avancement de la tâche est mis à jour pour indiquer si l’opération attend l’obtention des verrous de ressources appropriés. Une opération d’exécution conserve une liste des ressources (périmètres, schéma, scripts correctifs présents) dans la table sys_padlock, et l’insertion et la libération de ces verrous peuvent être observées dans cette table par l’ID de progression. Si une tâche en file d’attente est différée en raison de l’impossibilité d’obtenir les verrous nécessaires sur les ressources, elle est mise en pause pour permettre le traitement d’autres messages. La période de refroidissement peut être modifiée avec la propriété com.glide.update_operation.job_cancel_timeout_minutes. La tâche est toujours dans la file d’attente et est visible sur la page File d’attente des opérations de l’application .
com.glide.update_operation.max_failure_count .