Коллеги приветствую👋

Сегодня немного дополним более ранний пост про использование inputs в пайплайнах. Это такое, что точно можно использовать, если все почему-то так еще не делаете. Рассмотрим проект запуска пайплайна в ручную, с указанием разных типов переменных. В этом случае хорошо получается заменить их на inputs и сделать все удобнее.

Как мы разбирали уже ранее - есть условия переменных и при выборе окружения будет возможность выбрать стенды только внутри этого окружения, но теперь добавим еще разные типы, проверяем поля и так мы убедимся, что запуск пайплайна не упадет из-за некорректных данных указанных при запуске

  inputs:
    environment:
      description: "Target environment"
      options: ["test", "stage", "prod"]
      default: "test"

    landscape:
      description: "Target stand"
      rules:
        - if: $[[ inputs.environment ]] == "prod"
          options: ["my-prod01", "my-prod02"]
          default: "my-prod01"
        - if: $[[ inputs.environment ]] == "stage"
          options: ["my-stage01", "my-stage02"]
          default: "my-stage01"
        - options: ["my-test01", "my-test02", "sandbox01"]
          default: "my-test01"

    playbook:
      description: "Playbook to run"
      rules:
        - if: $[[ inputs.environment ]] == "prod"
          options: ["deploy", "check", "rollback"]
          default: "check"
        - if: $[[ inputs.environment ]] == "stage"
          options: ["deploy", "check", "rollback", "smoke", "migrate"]
          default: "deploy"
        - options: ["first_playbook", "deploy", "check", "smoke", "migrate", "debug"]
          default: "first_playbook"

    mode:
      description: "Execution mode"
      options: ["apply", "check", "diff"]
      default: "apply"

    limit_hosts:
      description: "Optional ansible --limit"
      default: ""
      regex: '^$|^[A-Za-z0-9_.:,-]+$'

    forks:
      description: "Ansible forks"
      type: number
      default: 10

    gather_facts:
      description: "Enable gather_facts"
      type: boolean
      default: true

    verbose:
      description: "Enable -vvv"
      type: boolean
      default: false

    confirmation:
      description: "Type APPROVE for production apply"
      default: ""

Для числовых знаний поставим type: number и boolean когда просто выбираем true/false что-бы не писать это текстом - можно и ошибиться.

Получаем основные поля - выбираются из предложенных вариантов. Число в специальном поле и переключатели там где это уместно. Остается пару полей с строкой - в данном случае это для гибкости.

Коллеги, приветствую👋

Сегодня поговорим о том, как быстро перенести индекс Elasticsearch между кластерами без S3.
Недавно при переезде на новый кластер Elasticsearch понадобилось перенести только несколько индексов. Казалось бы, задача простая: перенести документы — и готово. Но индекс в Elasticsearch - это не только документы. Есть ещё mapping, settings, aliases и другие метаданные.

Самый правильный вариант - Snapshot/Restore
Для полноценного переноса Elasticsearch предоставляет механизм Snapshot/Restore. Snapshot можно хранить во внешнем repository, например в S3, а затем восстановить на другом кластере.

Документация:
Snapshot and Restore
S3 repository
Это хороший вариант, когда инфраструктура уже готова. Но что делать, если доступ к S3 нужно ещё получить, а индексы нужны буквально «вчера»?

Reindex — быстрый перенос документов
В Elasticsearch есть API _reindex, который позволяет скопировать документы из одного индекса в другой. Он также поддерживает перенос из удалённого Elasticsearch-кластера.

Простейший вариант:

POST /_reindex
{
  "source": {
    "index": "old-index"
  },
  "dest": {
    "index": "new-index"
  }
}

Документация: Reindex API
Но здесь есть важный нюанс.
_reindex переносит документы, но не переносит mapping и settings исходного индекса.

Поэтому целевой индекс нужно подготовить до запуска reindex.
Сначала mapping, потом документы
Получить mapping исходного индекса можно так:

GET /old-index/_mapping

Документация: Get mapping
После этого создаём индекс на новом кластере с нужным mapping:

PUT /new-index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "keyword"
      },
      "age": {
        "type": "integer"
      }
    }
  }
}

Это важно, потому что если создать пустой индекс без нужного mapping, Elasticsearch может применить dynamic mapping при первой индексации документов. В результате типы полей могут отличаться от исходного индекса.
При создании индекса можно сразу задать settings, mappings и aliases: Create index API.

И не забываем про aliases
Ещё одна частая ошибка — перенести документы и забыть про aliases.

Например, приложение работает с:

users

а на самом деле это alias, указывающий на:

users-2026-08

Получить aliases можно через:

GET /old-index/_alias

После переноса их необходимо создать на новом индексе.

Например:

PUT /new-index/_alias/users

Или использовать _aliases, если нужно одновременно удалить alias со старого индекса и добавить его на новый:

POST /_aliases
{
  "actions": [
    {
      "remove": {
        "index": "old-index",
        "alias": "users"
      }
    },
    {
      "add": {
        "index": "new-index",
        "alias": "users"
      }
    }
  ]
}

Это удобно при production-миграции: приложение продолжает обращаться к тому же alias, а мы просто переключаем его на новый индекс.

Документация: Aliases API
Можно автоматизировать
Если индексов много или не хочется писать всё вручную, можно использовать elasticsearch-dump.
Инструмент позволяет отдельно переносить data, mapping, alias, settings, analyzer и другие сущности.
elasticsearch-dump на GitHub

Например:

elasticdump \
  --input=http://old-es:9200/my_index \
  --output=http://new-es:9200/my_index \
  --type=mapping

elasticdump \
  --input=http://old-es:9200/my_index \
  --output=http://new-es:9200/my_index \
  --type=data

Это уже можно завернуть в обычный Bash-скрипт и автоматизировать миграцию.

🎉 Розыгрыш завершен!

🏆 Победители:
1. @WolkStt

🔍 Проверить результаты