Opérations d’application 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/le mutex de mise à jour à l’échelle de l’instance est occupé par les autres opérations.
À partir de , Tokyoles API CICD qui nécessitent d’obtenir le verrou de mise à jour/le mutex à l’échelle de l’instance pour effectuer les opérations demandées seront mises en file d’attente au lieu d’être rejetées lorsque le verrouillage/le mutex à l’échelle de l’instance de mise à jour est occupé par les autres opérations. Lorsqu’une demande CICD est reçue, le service CICD correspondant construit un message d’opération d’application NowMQ (file d’attente de messages Now) et insère le message dans la file d’attente à l’aide des 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 d’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 l’opération de l’application
Lorsque le message NowMQ d’opération d’application est créé et inséré, l’enregistrement de suivi d’exécution de la demande CICD correspondante est créé et son sys_id est ajouté au corps du message NowMQ. Le suivi d’exécution 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 des informations sur la position dans 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] ».
Exemples de suivis de l’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 de 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 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 une privation de verrouillage/mutex pour l’installation manuelle à partir de l’interface utilisateur. Lorsque cela se produit, l’administrateur peut temporairement mettre en pause 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 de la file d’attente des opérations de l’application Diagnostics du système >. 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 supprimera éventuellement le message en file d’attente correspondant de NowMQ par la tâche de surveillance de l’intégrité de la file d’attente des opérations de l’application.
Page de l’interface utilisateur de file d’attente des opérations de l’application
Exemple de page d’interface utilisateur de 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 », 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 d’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.
Fenêtre de mise à niveau et file d’attente des opérations de l’application
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 le traitement des 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.
Une fois la mise à niveau 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 de verrouillage/mutex à l’échelle de l’instance observés dans une version antérieure à Tokyo ne sera pas visible. La demande est mise en file d’attente et traitée 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/importation
- api/sn_cicd/plugin/{plugin_id}/activate
- api/sn_cicd/plugin/{plugin_id}/rollback
Paralléliser les installations d’applications et les activations de modules 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 file d’attente prend un verrou/mutex à l’échelle de l’instance et maintient ce mutex jusqu’à ce qu’une opération en file d’attente soit terminée. Ce verrou est appelé 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. Il est toujours possible de mettre en pause la file d’attente 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. Elle peut être désactivée à 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 un travail peut s’exécuter, il est planifié pour être récupéré 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, la valeur par défaut étant 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 partageant le même périmètre, y compris les personnalisations.
- Deux opérations quelconques qui entraînent des changements de schéma.
- Deux opérations quelconques contenant des scripts correctifs.
Le traitement de 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 maintient 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 .