惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Stack Overflow Blog
Stack Overflow Blog
T
Tailwind CSS Blog
Recent Announcements
Recent Announcements
宝玉的分享
宝玉的分享
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
P
Proofpoint News Feed
D
Docker
Google DeepMind News
Google DeepMind News
aimingoo的专栏
aimingoo的专栏
B
Blog RSS Feed
Microsoft Security Blog
Microsoft Security Blog
博客园 - 【当耐特】
M
MIT News - Artificial intelligence
云风的 BLOG
云风的 BLOG
小众软件
小众软件
Hugging Face - Blog
Hugging Face - Blog
WordPress大学
WordPress大学
IT之家
IT之家
H
Help Net Security
Apple Machine Learning Research
Apple Machine Learning Research
Martin Fowler
Martin Fowler
S
SegmentFault 最新的问题
B
Blog
D
DataBreaches.Net

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Мини-пайплайн на страже синтаксиса и секретов в Ansible
magnusroot · 2026-04-30 · via Все публикации подряд на Хабре

Уровень сложностиПростой

Время на прочтение5 мин

Охват и читатели2.3K

Туториал

Представим, что у нас есть репозиторий, где хранятся плейбуки и роли Ansible. Делался он долго, старательно и по правилам. И даже если мы перед коммитами проверяем его через линтер, чтобы не сломать хрупкую YAML красоту и перепроверяем не забыли ли мы подчистить секреты с которыми проводили тесты, то рано или поздно подобную ошибку совершит кто-то другой. И вот, чтобы снизить такую вероятность и лишний раз не заниматься правками в Git, чтобы вычистить пароли или поправить форматирование, можно немного обезопасить репозиторий заранее.

Примеры настройки я буду показывать на Gitea, просто потому что она есть под рукой, но всё это актуально и работает и на остальных подобных системах, возможно, некоторые названия в интерфейсе будут немного другие.

Готовим инфраструктуру

Для начала нам понадобится Runner - это тот самый трудяга, который будет раз за разом выполнять проверки, которые мы ему зададим. В нашем случае это будет Docker-контейнер. Развернуть его можно как на той же ноде, где стоит и Git, а можно и на любой другой, была бы сетевая связность.

Шаг 1

И так, заходим на нашу машину, где решили разворачивать раннер и создаём dockerfile со следующим содержимым:

FROM docker.gitea.com/runner-images:ubuntu-latest

RUN apt-get update && \
    apt-get install -y yamllint && \
    apt-get install -y wget && \
    wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.4/gitleaks_8.18.4_linux_x64.tar.gz && \
    tar -xzf gitleaks_8.18.4_linux_x64.tar.gz && \
    mv gitleaks /usr/local/bin/ && \
    rm gitleaks_8.18.4_linux_x64.tar.gz && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

За основу берём образ предоставляемый самим gitea и добавляем в него yamllint для проверки синтаксиса и поиска ошибок в YAML-файлах, а также gitleaks, который будет искать забытые пароли, ключи, API и прочие секреты. Сохраняем файл и собираем образ:

docker build -t ubuntu-yamllint:latest .

Шаг 2

Создаём файл docker-compose.yml со следующим содержимым:

version: '3'
services:
  act_runner:
    image: gitea/act_runner:latest
    privileged: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./runner_data:/data
    environment:
      - GITEA_INSTANCE_URL=https://YOUR_GIT
      - GITEA_RUNNER_REGISTRATION_TOKEN=YOUR_TOKEN
      - GITEA_RUNNER_NAME=my-docker-runner
      - GITEA_RUNNER_LABELS=ubuntu-yamllint:docker://ubuntu-yamllint:latest,ubuntu-latest:docker://docker.gitea.com/runner-images:ubuntu-latest,ubuntu-22.04:docker://docker.gitea.com/runner-images:ubuntu-22.04
    restart: unless-stopped

Здесь важно заполнить две переменные - GITEA_INSTANCE_URL (указать где находится ваш Git-репозиторий) и GITEA_RUNNER_REGISTRATION_TOKEN. Токен можно получить в настройках репозитория, во вкладке Actions -> Runners, нажав кнопку Create new Runner. В этом же меню раннер появится после того, как вы запустите Docker-контейнер.

В переменной GITEA_RUNNER_LABELS указаны несколько лейблов. Я использую только ubuntu-yamllint:latest. Остальные можно удалить, они на работу не влияют, но можно и оставить, так как не мешают они тоже.

Запускаем контейнер и наблюдаем, как он начинает работать:

docker compose up -d
docker ps

Настраиваем пайплайн

Мы подготовили место где будет работать наш пайплайн, теперь очередь самого пайплайна.

Шаг 1

В директории Ansible создадим директорию .gitea/workflows и в ней файл, который можно назвать как угодно, например yamllint_and_pass_check.yml. Запишем в него следующие настройки:

---
name: YAML Lint

on: [push]

jobs:
  yamllint:
    runs-on: ubuntu-yamllint
    steps:
      - name: Checkout linting
        uses: actions/checkout@v4
      - name: Run yamllint with auto-detected config
        run:  yamllint -c .yamllint .
  gitleaks:
    runs-on: ubuntu-yamllint
    steps:
      - name: Checkout passwords leaks
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run gitleaks
          run: gitleaks detect --source .
...

Суть в следующем, указываем имя, на каком шаге выполняется (в нашем случае на push), какой образ используем и указываем какие задачи выполнить (сами задачи разбиты по шагам, которые также имеют имена).

Но некоторые строки требуют дополнительного пояснения.

uses: actions/checkout@v4 - использует стандартный action GitHub версии 4 (Gitea почти всё берёт оттуда), который означает клон репозитория в рабочую директорию контейнера (по сути git clone). Подробнее про Actions и какие они бывают можно посмотреть здесь.

fetch-depth: 0 - снимает ограничения на глубину истории и скачивает всё, для поиска секретов это важно.

yamllint -c .yamllint . и gitleaks detect --source . - запускают наши проверки.

Шаг 2

И чтобы линтер и gitleaks не указывали на все подряд проблемы (потому что что-то должно быть в таком виде по задумке, а что-то просто невозможно поправить по ряду причин), мы их немного настроим.

Всё в той же директории Ansible создадим файл .yamllint с содержимым:

---
extends: default

ignore: |
  roles/filebeat_install/files/fields.yml
  .gitea/workflows/yamllint.yml

rules:
line-length:
max: 180
...

Тут можно настроить максимальную длину строки, после превышения которой линтер начнёт ругаться, а также указать какие файлы игнорировать при проверке.

Также есть возможность отключать проверку линтером прямо в рабочих файлах, указывая перед нужными строками правило которое применять не нужно:

# yamllint disable-line rule:line-length

Теперь очередь gitleaks. Создаём файл .gitleaks.toml и запишем в него:

[extend]
useDefault = true

[allowlist]
paths = [
  '''roles/logs_settings_on_ptaf/templates/filebeat.yml.j2''',
]

Здесь Также можно указать проверку каких файлов необходимо исключить, если имеется такая необходимость.

Защищаем master-ветку

Заходим в настройки репозитория и видим там вкладку Branches

Там можем или создать новое правило, или отредактировать имеющееся.

Для защиты ветки от вливания в неё непроверенных изменений будет достаточно в разделе Push выставить Disable Push и в разделе Force Push выставить Disable Force Push. А в разделе Pull Request Merge укажем Enable Merge. Также не лишним будет поставить галочку на пункте Administrators must follow branch protection rules, чтобы у админов репозитория не было соблазна обходить общие правила.

Также будет необходимо поставить галочку на пункте Enable Status Check и выбрать проверки, которые должны завершиться успешно, чтобы мёрдж в главную ветку был разрешён. Но выбор этих проверок появится только после хотя бы одного их выполнения.

Заключение

После выполнения всех этих действий мы получаем защиту мастер-ветки от бардака и утечки секретов. Новые пуши должны отправляться в отдельные ветки и уже потом мёрджиться в основную. Но это будет успешно только в том случае, если будут пройдены обе проверки. Можно добавить дополнительные проверки, если таковые нужны. Необходимо просто дополнить dockerfile нужными утилитами и пересобрать образ. Как пример, можно добавить ansiblelint, но, по моему скромному мнению, его проверки слишком уж жёсткие, так как проверяется не только синтаксис, но и правильность использования тех или иных инструментов Ansible, что подойдёт не для всех.