--- # Перекат нагрузок, которые не перезапускаются сами при правке конфигурации. # # ЗАЧЕМ ЭТО ОТДЕЛЬНАЯ ЗАДАЧА. Flux обновляет ConfigMap в кластере за пару минут, # но под продолжает работать со старым содержимым: у релизов universal-chart в # шаблоне пода нет контрольной суммы конфига, поэтому спецификация не меняется # и Kubernetes не видит причин пересоздавать под. Всё, что задаётся через # ConfigMap, применяется только после явного переката. # # Так это выглядит на практике: правишь nginx.conf, Flux рапортует Applied # revision, проверяешь — поведение старое. Легко принять за «правка не поехала» # и пойти искать несуществующую ошибку. Дважды так и было: сначала с порядком # set/rewrite, потом с auth_type. # # ПОЧЕМУ НЕ ДЕКЛАРАТИВНО. Правильное лечение — аннотация с хешем конфига в # шаблоне пода, тогда изменение ConfigMap меняет спецификацию и перекат # происходит сам. Здесь так не выходит: имя ConfigMap чарту передаётся строкой, # монтирование он делает сам, и посчитать хеш на этапе kustomize нечем — # configMapGenerator переименовал бы ресурс, но ссылку внутри чарта, который # рендерится уже в кластере, не поправил бы. Так что действие остаётся # императивным, и его место — здесь, а не в чьей-то памяти. # # ЗАПУСК ТОЛЬКО ЯВНЫЙ. Задача не выполняется при обычном прогоне: перекат # нагрузок посреди деплоя — не то, что должно случаться само. # uv run poe reload # либо точечно: # uv run poe reload -- -e "sarex_reload_workloads=[{'namespace':'django','deployment':'frontend'}]" - name: Перекатить нагрузки с изменённой конфигурацией ansible.builtin.shell: cmd: >- {{ compose_cmd }} exec -T k3s-server sh -ec ' kubectl -n {{ item.namespace }} rollout restart deploy/{{ item.deployment }} kubectl -n {{ item.namespace }} rollout status deploy/{{ item.deployment }} --timeout={{ sarex_reload_timeout }} ' chdir: "{{ deploy_dir }}" loop: "{{ sarex_reload_workloads }}" loop_control: label: "{{ item.namespace }}/{{ item.deployment }} — {{ item.why | default('правка конфигурации') }}" changed_when: true tags: [reload]