Задачи и внедрявания

Задачи

Задачата (job) е една единица работа за един агент или конектор. Внедряванията се разклоняват на много задачи; скриптовете, опресняванията на инвентаризацията и рестартиранията са единични задачи.

• sent се задава, когато задачата бъде записана в WebSocket. Без ack в рамките на 60 s задачата се връща в created и се изпраща отново при следващата връзка. Съобщението hello на агента изброява задачите, които той все още държи, така че двете страни се синхронизират след повторно свързване.
• Агентите изпълняват задачите последователно за всяко устройство (без едновременни инсталатори); сървърът все пак може да постави много задачи в опашка.
• Всяка задача има expires_at; периодичната проверка за офлайн устройства маркира задачите с изтекъл срок като timeout.
• Започнала задача (running; агентите изпращат съобщение за напредък, когато задача започне) изтича timeout_seconds + 5 минути след началото си. Агентът изпълнява задачите на устройството една след друга, затова задача, която е потвърдил, но не е започнал, чака, докато има неприключила по-ранна задача на устройството, и след това се отчита от момента, в който последната от тях е приключила (сесиите за отдалечен работен плот не се броят).
• Резултатите са идемпотентни: дублиран job.result за приключила задача се игнорира.
• Тайните, от които задачата се нуждае (LDAP парола, идентификационни данни за push инсталиране, токен за регистриране, връзки за изтегляне), се добавят при доставката от обогатителите на задачи (job enrichers). Таблицата jobs съхранява само препратки или запечатан шифротекст.

Планировчик на внедряванията

Основни инварианти:

• deployment_targets се материализира веднъж при стартирането. Устройствата, регистрирани по-късно, не се добавят автоматично; Add new devices изпълнява филтъра отново.
• Едно преминаване избира само целите в pending на онлайн устройства, като спазва max_concurrency (цели в опашка, изтегляне или инсталиране) и прозореца за поддръжка в часовата зона на обекта на устройството.
• Прозорецът се оценява в SQL: deployment_in_window(now, coalesce(site tz, tenant default tz), start, end).
• Едновременно се изпълнява само едно преминаване за внедряване (SELECT … FOR UPDATE върху реда на внедряването; резултатите за цели първо заключват внедряването в същия ред, а при взаимно блокиране (deadlock) се прави повторен опит), така че няколко реплики могат безопасно да изпълняват преминавания.
• Преминаванията се изпълняват на всеки 30 s, при всяко hello от агент, който има чакащи цели, и след всеки резултат за цел (обединени за всяка секунда). Преминаването също така уточнява състоянието на целите, чиято задача е приключила без резултат.
• Неуспешна цел или цел с изтекло време, за която има оставащи повторни опити, се връща в pending с next_attempt_at = now + retry_backoff × 2^(attempt-1).
• Когато внедряването изтече, чакащите и поставените в опашка цели изтичат (задачите в опашката се отменят на агента).
• Състоянието и броячите на внедряването се преизчисляват от неговите цели при всяка промяна и се кешират в реда.
• Задачите не съхраняват връзка за изтегляне. Обогатителят за пакети предварително подписва нов URL, валиден един час, при всяка доставка на задачата; агентите опресняват изтекла връзка чрез GET /api/agent/v1/packages/{id}/download-url.

Определяне на целите

all, devices (изричен списък) или filter (филтърът за устройства плюс условия software_present / software_absent с незадължително сравнение на версията чрез version_cmp). Устройствата без агент и изведените от експлоатация устройства се изключват и се отчитат в excluded_count. Най-много 20 000 цели (too_many_targets).

Планировчикът се тества от entrosity-axis.backend/internal/deploy/scheduler_integration_test.go, който симулира парк от устройства в различни часови зони, прозорци, повторни опити и повторни свързвания.