Opérations d’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.
À compter 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 crée un message NowMQ (file d’attente des messages Now) d’opération de l’application et l’insère 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 de l’application Message NowMQ
Les messages NowMQ d’opération de l’application ont un objet commun qui est « sys.applifecycle.operation ». Le corps du message NowMQ de l’opération de l’application contient un objet JSON qui inclut la sys_id du suivi des exécutions (également appelé ID d’avancement 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, rollback, import_app et apply_changes. Il contient également des informations telles que l’ID de 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 de l’application est créé et inséré, l’enregistrement du suivi de l’exécution de 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 des 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é du préfixe « [File d’attente des opérations de l’application est en pause] ».
Exemple 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 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 mise en file d’attente, l’installation manuelle d’une application à partir de l’interface utilisateur comme Toutes les applications ou Application Manager 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’installation manuelle à partir de l’interface utilisateur en raison d’un manque de verrouillage/mutex à l’échelle de l’instance. Lorsque cela se produit, l’administrateur peut temporairement suspendre 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 correspondant mis en file d’attente de NowMQ par la tâche de surveillance de la santé 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 File d’attente d’opération d’application. L’administrateur peut cliquer sur le bouton dans « État de la file d’attente des opérations » 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, mettez à 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 des exécutions 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 (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 le traitement des messages 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 fenêtre 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 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 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 file d’attente
- api/sn_cicd/app_repo/installer
- api/sn_cicd/v1/app_repo/installer
- api/sn_cicd/v2/app_repo/installer
- api/sn_cicd/app_repo/rollback
- api/sn_cicd/v1/app_repo/installer
- 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/installer
- api/sn_cicd/v1/app_repo/installer
- api/sn_cicd/v2/app_repo/installer
- api/sn_cicd/plugin/{plugin_id}/activate
Tout le traitement de file d’attente prend un verrouillage/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 affiché dans la table sys_mutex . Pendant ce temps, les opérations qui prennent ce même verrou (installations d’applications, activations de plug-ins, 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 à la première disponibilité. Dans le cas contraire, 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 par défaut de 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 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 reporte 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 (étendues, 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 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 .