airflow пытается получить доступ к работникам сельдерея, используя идентификатор работника вместо URL - PullRequest
Новая
       13

airflow пытается получить доступ к работникам сельдерея, используя идентификатор работника вместо URL

1 голос
/ 02 ноября 2019

У меня работает Airflow с CeleryExecutor и 2 работниками. Когда мой DAG запускается, задачи генерируют журнал в файловой системе работника, который их запускал. Но когда я захожу в веб-интерфейс и нажимаю на журналы задач, я получаю: 

*** Log file does not exist: /usr/local/airflow/logs/test_dag/task2/2019-11-01T18:12:16.309655+00:00/1.log
*** Fetching from: http://70953abf1c10:8793/log/test_dag/task2/2019-11-01T18:12:16.309655+00:00/1.log
*** Failed to fetch log file from worker. HTTPConnectionPool(host='70953abf1c10', port=8793): Max retries exceeded with url: /log/test_dag/task2/2019-11-01T18:12:16.309655+00:00/1.log (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f329c3a2650>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

http://70953abf1c10:8793/, очевидно, не правильный IP-адрес работника. Тем не менее, celery@70953abf1c10 - это имя этого работника в Сельдерее. Кажется, что Airflow пытается узнать URL-адрес работника из Celery, но вместо этого Celery дает имя работника. Как я могу решить это?

Ответы [ 2 ]

1 голос
/ 05 ноября 2019

Решение DejaLekic поставило меня на правильный путь, но это было не совсем очевидно, поэтому я добавляю этот ответ для пояснения.

В моем случае я запускал Airflow на контейнерах Docker. По умолчанию контейнеры Docker используют мостовую сеть под названием bridge. Это специальная сеть, которая не разрешает имена хостов автоматически. Я создал новую мостовую сеть в Docker под названием airflow-net, и все мои контейнеры Airflow присоединились к этому (оставить значение по умолчанию bridge не было необходимости). Тогда все просто заработало.

По умолчанию Docker устанавливает в качестве имени хоста шестнадцатеричный идентификатор контейнера. В моем случае идентификатор контейнера начинался с 70953abf1c10, а имя хоста также было 70953abf1c10. Существует параметр Docker для указания имени хоста, но он оказался необязательным. После того как я подключил контейнеры к новой мостовой сети, 70953abf1c10 начал преобразовываться в этот контейнер.

1 голос
/ 02 ноября 2019

Простейшим решением является либо использование имени по умолчанию, которое будет включать имя хоста, либо явное указание имени узла с допустимым именем хоста (пример: celery1@hostname.domain.tld).

Если вы используете настройки по умолчанию, то на машине с работником воздушного потока неправильно задано имя хоста 70953abf1c10. Вы должны исправить это, запустив что-то вроде: hostname -B hostname.domain.tld

...