Initial commit: SaveUrl project migration from Drive
This commit is contained in:
@@ -0,0 +1,72 @@
|
||||
# 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
|
||||
|
||||
Reference in New Issue
Block a user