Files
save-url-main/documentacion/03_CONFIGURACION_VARIABLES.md
T
2026-05-09 14:20:17 -04:00

2.5 KiB

Configuración (Airflow Variables)

Fuente de configuración real

El código en SaveUrl.py obtiene configuración principalmente desde Airflow Variables usando airflow.models.Variable.get(...).

Esto implica:

  • Debes definir estas Variables en tu instancia de Airflow (UI o CLI).
  • El archivo .env.example sirve como referencia de nombres, pero no es la fuente en ejecución si corres bajo Airflow.

Variables requeridas

SQL Server

  • DB_MSSQ_SERVER: hostname o IP del SQL Server
  • DB_MSSQ_USER: usuario
  • DB_MSSQ_PASSWORD: password

Notas:

  • La conexión ODBC usa ODBC Driver 18 for SQL Server.
  • La tabla destino es fija: URL_FTP.
  • El nombre de “database” (catálogo) se toma de la lista INFORMATIONS dentro del código (ej. glm_pmi, IS001, etc.).

FTP

  • FTP_000oqta_SERVER
  • FTP_000oqta_USER
  • FTP_000oqta_PASSWORD

Notas:

  • El código construye el path como FTP_BASE_PATH + code_folder.
  • code_folder se calcula como <name_folder><MM> (mes actual), por ejemplo glmpmi04.

Kafka

  • BOOTSTRAP_SERVERS_DOCKER: brokers accesibles desde el entorno Airflow (por ejemplo kafka-kraft:9092)
  • KAFKA_USE_SSL: "True" o "False"

Si KAFKA_USE_SSL == "True", además se leen (desde variables de entorno del proceso, vía os.getenv, no Airflow Variables):

  • SECURITY_PROTOCOL (ej. SASL_SSL)
  • SASL_MECHANISM (ej. SCRAM-SHA-256)
  • SASL_PLAIN_USERNAME
  • SASL_PLAIN_PASSWORD
  • SSL_CAFILE (path al CA dentro del contenedor/host)
  • SSL_CHECK_HOSTNAME (True/False)

Importante: en el código actual, BOOTSTRAP_SERVERS_DOCKER y KAFKA_USE_SSL se obtienen como Airflow Variables, pero los demás parámetros de seguridad se obtienen desde os.getenv. En despliegues en contenedores, asegúrate de definir esas variables en el entorno del scheduler/worker.

Webhook de notificación

  • WEBHOOK_URL_NOTIFICATION: endpoint que acepta POST con JSON {"message": "..."}

Plantilla .env.example

El archivo .env.example contiene los nombres esperados (útil para referencia), pero:

  • el proyecto no debería versionar un .env real con secretos
  • en Airflow, se recomienda gestionar secretos con backend (Vault/Secrets Manager/etc.) o Variables protegidas

Validación recomendada (pre-flight)

Antes de activar el DAG en producción, valida:

  • Variables existen (sin typos)
  • SQL user tiene SELECT e INSERT sobre URL_FTP
  • FTP credenciales permiten NLST sobre el path base
  • Kafka accesible desde el contenedor/worker que ejecuta el DAG