Indépendamment de la quantité d’expérience que vous avez, il ne nous est pas possible de connaître et de nous souvenir de chaque facette d’un environnement de programmation. J’en ai fait l’expérience plusieurs fois.
Certains d’entre vous diront certainement que je serais superficiel pour ne pas avoir exploré toutes les facettes d’un langage comme Java si je prétends avoir une expérience suffisante de son utilisation. Ainsi soit-il. Mais étendre l’aide aux autres m’a aidé, à son tour, parce que j’ai pu apprendre beaucoup de nouvelles choses que je n’avais pas eu la chance de rencontrer pendant mon travail de projet.
Passons maintenant au sujet de cet article.
Récemment, une équipe qui rencontrait un problème pour obtenir un calendrier à exécuter selon l’heure d’été m’a été référée. Bien que j’aie (fièrement) mentionné comment j’ai géré un programme Airflow complexe de 4 000 DAG, tous utilisant une application de générateur DAG (évidemment après une exploration appropriée), je n’ai pas eu la chance d’implémenter la fonction de fuseau horaire dans Airflow.
Par défaut, Airflow utilise UTC.
J’ai fait ce qui vient naturellement à chacun de nous ces jours-ci – j’ai fait une recherche sur Google. Quelques liens :
- Comment utiliser les fuseaux horaires dans Apache Airflow
- Comment prendre en compte l’heure d’été lors de l’utilisation de la programmation Cron dans le flux d’air
Il est possible de mettre à jour la configuration d’Airflow pour qu’elle fonctionne selon le fuseau horaire requis, mais la recommandation est de laisser Airflow fonctionner sur UTC lors de la configuration des DAG pour reconnaître le fuseau horaire requis.
Pour qu’un DAG Airflow comprenne l’heure d’été, nous devons utiliser la bibliothèque du pendule, créer un objet de fuseau horaire et l’ajouter au start_time paramètre de l’objet DAG comme ci-dessous
import pendulum
from airflow import DAG
from datetime import datetime, timedelta
local_tz = pendulum.timezone("Europe/Paris")
default_args = {
"start_date": datetime(2023, 1, 1, tzinfo=local_tz),
"owner": "Airflow",
other parameters as required
}
dag = DAG(
dag_id="timezone_dag",
schedule_interval="10 5 * * *",
default_args=default_args
)Dans cet exemple, nous utilisons ‘Paris’ comme fuseau horaire, qui est en avance d’une heure sur UTC pendant la période hivernale et de deux heures en avance lorsque l’heure d’été est activée/active. Une fois que nous avons défini ces informations, nous avons été définis.
Le problème que nous avons rencontré était lors de la démonstration que le DAG fonctionne – plus encore lorsque l’heure d’été est activée, étant donné que l’heure d’été n’est pas encore entrée en vigueur cette année.
Permettez-moi de réitérer. Spécifier le paramètre de fuseau horaire pour un DAG était aussi simple que de passer un couteau chaud dans du beurre. Poussant cette analogie plus loin, le problème auquel nous étions confrontés était de savoir comment mettre le beurre liquide sur le pain à l’aide d’un couteau 🙂
Voici comment nous avons procédé pour tester le DAG. Étant donné que nous sommes dans la période janvier/février de l’année, la définition du fuseau horaire signifiait que nous pouvions définir le calendrier du DAG et attendre que l’horloge atteigne l’heure appropriée, et le DAG était éteint. Le seul problème était la façon dont Airflow affiche les informations à l’écran. Comme Airflow fonctionne toujours sur l’horloge UTC, il exécute le DAG à 10 minutes après 5 h, comme prévu, mais l’interface utilisateur affiche l’heure à 10 minutes après 4 h.
Permettez-moi de répéter cela. L’horaire du DAG signifie que le DAG est configuré pour s’exécuter à 10 h 05, heure de Paris. Airflow exécute le DAG à 4 h 10. Déroutant? Oui, mais c’est un comportement attendu car l’heure de Paris a une heure d’avance sur l’UTC.
Une fois que nous avons démontré que le paramètre de fuseau horaire fonctionnait comme prévu, nous avons voulu tester que le DAG fonctionne lorsque l’heure d’été était activée. Pour tester l’heure d’été, nous avons dû changer les horloges. C’était facile à faire sur une machine virtuelle Linux en utilisant le date -s commande. Lorsque nous avons essayé de changer l’horloge de nos ordinateurs portables fournis par l’entreprise, nous avons rencontré des problèmes. Nous n’avions pas la permission de changer l’heure. Nous avons également essayé d’ajouter une nouvelle horloge et de définir la valeur, mais sans succès.
Donc, nous avons fait la prochaine chose logique. Nous avons lancé une machine virtuelle Windows sur laquelle nous avions le contrôle pour modifier les paramètres d’horloge. Nous avons changé l’heure au 17 juin 2023 et nous sommes partis. Nous avons fixé la date de début du DAG au 17 juin et avons attendu avec impatience. Lorsque le DAG ne s’est pas exécuté, j’ai réalisé que nous devions définir la date au moins un jour avant l’horloge. (N’oubliez pas qu’Airflow exécute un DAG seulement après la période prévue pour ce DAG est passée / terminée) Nous avons donc réglé l’horloge sur le 15 juin 2023. Après ce changement, une fois de plus, nous avons regardé Airflow, mais rien ne s’est passé – le DAG ne s’est pas exécuté.
Après réflexion, je me suis rendu compte que l’heure à laquelle on voulait exécuter le DAG dans le planning de production n’était pas importante pour la démonstration. J’ai donc modifié le calendrier DAG pour qu’il s’exécute toutes les 5 minutes. En l’occurrence, nous fixons l’horaire à « 5 * * * *« , s’attendant à ce que le DAG s’exécute toutes les cinq minutes. Ce n’est pas le cas. Ce calendrier signifie que le DAG s’exécutera cinq minutes après minuit chaque jour.crontab.guru et vérifié l’expression, et définissez-la correctement sur « */5 * * * *« . Une fois que nous avons réinitialisé les horloges sur toutes les VM (trois Linux et une Windows), nous avons attendu. Quatre VM pour une démonstration simple ? Une pour éditer le DAG, une pour exécuter le serveur Web Airflow, une pour exécuter le planificateur Airflow et la Machine virtuelle Windows pour la connexion à l’interface utilisateur Airflow.
On règle les horloges de chacune des VM sur 10h, 17 juin 2023 et a commencé à surveiller l’interface utilisateur d’Airflow. Lorsque l’horloge a dépassé 10h05, le DAG ne s’est pas exécuté. Et nous nous sommes laissés nous gratter la tête. Nous avons parcouru chacune des machines virtuelles. Ensuite, j’ai noté l’horloge affichée dans le journal du planificateur d’Airflow. Comme il nous fallait du temps pour régler l’horloge sur chaque VM, nous avons introduit une différence d’une à trois minutes entre toutes les VM. Ainsi, si la machine virtuelle Windows fonctionnait à 10h03, au moins une machine virtuelle Linux était à 10h00. Une fois que nous avons réalisé cela, nous sommes retournés à la surveillance de l’interface utilisateur. Et sur le point, le DAG a été exécuté à 10h08 (selon l’horloge affichée par l’interface utilisateur). Ensuite, le DAG a été exécuté de manière cohérente à chaque intervalle de cinq minutes.
Et enfin, nous avions un mécanisme grâce auquel nous pouvions démontrer à n’importe qui – de manière cohérente – que le paramètre de fuseau horaire spécifié sur le DAG fonctionne.