Opérations de l’application en file d’attente
Les API CICD qui doivent obtenir le verrou/mutex à l’échelle de l’instance de mise à jour 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 Tokyo, les API CICD qui nécessitent d’obtenir le verrou/mutex à l’échelle de l’instance 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/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 des messages Now) et insère le message dans la file d’attente à l’aide des API NowMQ. Les messages mis 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 si l’opération répond aux critères nécessaires.
Opération de l’application Message NowMQ
Les messages NowMQ de l’opération de l’application ont un objet commun qui est « sys.applifecycle.operation ». Le corps du message NowMQ de l’opération d’application 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 API CICD), le type d’opération qui peut être l’un des suivants : app_install, plugin_activation, batch_install, restaurer 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 pour l’installation de l’application.
Suivi de l’exécution pour l’exploitation de l’application
Lorsque le message NowMQ de l’opération d’application est créé et inséré, l’enregistrement du suivi de l’exécution pour la demande CICD correspondante est créé et son sys_id est ajouté dans le corps du message NowMQ. Le suivi des exécutions est initialement dans l’état En attente. La colonne « Détails » du suivi de l’exécution 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 dans la file d’attente. Lorsque la file d’attente est mise en pause, le message est précédé de « [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 de l’exécution des opérations de l’application lorsque la file d’attente est mise 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 mise en file d’attente, l’installation manuelle d’une application à partir de l’interface utilisateur comme Toutes les applications ou le 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 une absence de verrou/mutex à l’échelle de l’instance lors de l’installation manuelle à partir de l’interface utilisateur. 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 des exécutions 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 d’interface utilisateur de file d’attente des opérations d’application
Exemple de page d’interface utilisateur de file d’attente d’opération d’application. L’administrateur peut cliquer sur le bouton « É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 », cela ouvre le formulaire Suivi de l’exécution. Si le message en file d’attente est en attente dans la file d’attente, mettre à jour l’état du suivi des exécutions sur « Annulé » et enregistrer le changement annulera la demande CICD correspondante en file d’attente. Remarque : si l’état du suivi d’exécution est « En cours d’exécution », la demande CICD ne peut pas être annulée.
File d’attente des opérations d’application et fenêtre de mise à niveau
Par défaut, 2 heures (personnalisables 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.
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 verrou/mutex à l’échelle de l’instance observés dans une version antérieure à Tokyo n’est 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/batch/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 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 traitement de 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 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 code 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é. Si ce n’est pas le cas, elle est renvoyée à 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 quelconques qui partagent le même champ d’application, 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 différe les tâches non traitables si nécessaire. L’ID de progression 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 en cours d’exécution gère une liste des ressources (portées, 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 mode de refroidissement pour permettre le traitement des autres messages. La période de récupération peut être modifiée à l’aide de 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 .