Ansible: playbook в Ansible
Главное меню » Linux » Ansible: playbook в Ansible
Чтобы лучше понять различия между специальной командой Ansible и сценариями Ansible; вы можете думать о специальных командах Ansible как о командах Linux, а playbook – как о сценариях bash.
Специальные команды Ansible идеально подходят для выполнения задач, которые не выполняются часто, таких как получение данных о работоспособности серверов, получение системной информации и т. д.
С другой стороны, плейбуки Ansible идеально подходят для автоматизации сложных задач, таких как системные исправления, развертывание приложений, конфигурации брандмауэра, управление пользователями и т. д.
Обратите внимание, что мы включили все сценарии, сценарии и файлы, которые я собираюсь обсудить в этой серии, в этот репозиторий GitHub.
Прежде чем следовать этой статьи по Ansible Playbook, вам следует обратиться к настройке, упомянутой в первой главе серии статей о Ansible.
Создание вашей первой Ansible playbook
Плейбуки написаны в формате YAML (еще один язык разметки). Если вы не знаете YAML; Мы включили наиболее важные правила синтаксиса YAML на рисунок ниже, чтобы вы могли легко следовать всем примерам статьи:
Кроме того, YAML чувствителен к отступам. Отступ в два пробела рекомендуется использовать в YAML; однако YAML будет следовать любой системе отступов, которую использует файл, если она согласована.
Постоянно нажимать два пробела на клавиатуре не раздражает, поэтому сделайте себе одолжение и включите следующую строку в файл
Это преобразует вкладки в два пробела всякий раз, когда вы работаете с файлом YAML. Понравился этот удобный совет по Vim?
Теперь давайте создадим ваш первый сценарий. В каталоге проекта создайте файл с именем first-playbook.yml со следующим содержимым:
Playbook будет работать на всех хостах и использует файловый модуль для создания файла с именем /tmp/foo.conf ; вы также устанавливаете режим: 0664 и параметры модуля owner: destroyer, чтобы указать права доступа к файлу и владельца файла. Наконец, вы устанавливаете опцию state: touch, чтобы убедиться, что файл создается, если он еще не существует.
Чтобы запустить playbook, вы можете использовать команду ansible-playbook, за которой следует имя файла playbook:
Вот полный вывод вышеуказанной команды:
Результат запуска playbook довольно понятен. На данный момент обратите особое внимание на значение changed = 1 в сводке PLAY RECAP, которое означает, что одно изменение было успешно выполнено на управляемом узле.
Что такое Ansible и как его использовать
Авторизуйтесь
Что такое Ansible и как его использовать
Что такое Ansible? Это ПО с открытым исходным кодом, которое автоматизирует поставку программного обеспечения, управление конфигурацией и развёртывание приложений. Ansible помогает DevOps-специалистам автоматизировать сложные задачи.
Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Ключевые особенности программы Ansible
Установка и запуск
Инструкцию по установке на другие ОС можно найти здесь.
Структура Ansible
Модули
Это небольшие программы, выполняющие определённую работу на сервере. Например, вместо запуска этой команды:
Мы можем использовать модуль apt и установить htop:
Использование модуля даст вам возможность узнать, установлен он или нет.
Плагины
Ansible поставляется с несколькими удобными плагинами, и вы можете легко написать свой собственный.
Инвентаризация хостов
Чтобы предоставить перечень хостов, нам нужно обозначить список, находящийся в файле инвентаризации. Он напоминает содержание файла hosts.
В простейшем виде он может содержать одну строку:
Playbooks
Ansible playbooks — это способ отправки команд на удалённые компьютеры с помощью скриптов. Вместо того, чтобы индивидуально использовать команды для удалённой настройки компьютеров из командной строки, вы можете настраивать целые сложные среды, передавая скрипт одной или нескольким системам.
group_vars
Файл содержит набор переменных, например имя пользователя и пароль базы данных.
Это способ сгруппировать несколько задач в один контейнер, чтобы эффективно автоматизировать работу с помощью понятной структуры каталогов.
Обработчики
Представляют собой списки задач, которые на самом деле не отличаются от обычных задач, на которые ссылается глобально уникальное имя и которые оповещаются уведомителями. Если ничто не уведомляет обработчик, он не будет запускаться. Независимо от того, сколько задач уведомляет обработчик, он запускается только один раз, после того как все задачи завершены.
Если у вас playbook с большим объёмом, может быть полезно иметь возможность запускать только определённую часть его конфигурации.
Демо «Реальное приложение»
Цель этой демонстрации — установить приложение Laravel в VPS. Для этого используем Lightsail.
Последовательность действий для создания и запуска Laravel APP:
Рассмотрим каждый пункт подробнее.
Создание экземпляра Ubuntu Lightsail
Перейдите на панель управления Lightsail и нажмите «Создать экземпляр».
Выберите свою любимую ОС.
Выберите «Добавить скрипт запуска», который запускается после создания вашего экземпляра. Не забудьте получить SSH-ключ.
Установка зависимостей Ansible на нашем VPS
Добавьте эти sh-команды для установки зависимостей:
Теперь у нас есть готовый экземпляр, перейдём к построению Ansible Project.
Добавление SSH-ключей в Git
Вы должны добавить свой сервер id_rsa.pub к своим ключам GitHub SSH, войдя в свой сервер.
Сборка хостов и ansible.cfg
Определение роли в Ansible
Используем модуль Ping, чтобы убедиться, что хост работает, после чего нужно обновить все пакеты и установить два модуля: git и htop.
Определение обработчика
Установка модулей PHP
Чтобы вызвать обработчик, мы должны использовать notify: Restart PHP-FPM, имена обработчиков должны быть уникальными.
В этом руководстве мы определили php как тег, поэтому, например, если вы хотите запустить только эту задачу из своего playbook, вам необходимо выполнить её с —tags = ”php”, которая будет исполнять только её.
Установка Nginx
Добавление default-конфигурации Nginx
vars.yml
Примечание: Рекомендуется использовать ansible-vault для шифрования и дешифрования переменных.
Как использовать Ansible-Vault
Создайте секретный файл хранилища, содержащий ключ шифрования, который шифрует ваши переменные.
Чтобы зашифровать переменные, используйте:
Чтобы расшифровать переменные, используйте:
Создание базы данных MySql, имени пользователя и пароля
mysql_user и mysql_pass определены внутри vars.yml.
Клонирование кодовой базы
repo_git_url и app_work_dir определены внутри vars.yml.
Генерирование .env
Ansible использует шаблонизатор Jinja2 для динамических выражений и доступа к переменным. Создадим файл env.conf.
Создание playbook
Как видно, мы определили aws как хост для этого playbook, и sudo yes даёт нам возможность выполнять команду как пользователю sudo. У нас есть vars_files, где мы храним наши vars. Мы установили roles, каждая role выполняет определённую задачу. И, наконец, у нас есть handlers, которые содержат все обработчики проекта.
🐹 Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.
Опубликовано 2021-04-07 · Обновлено 2021-04-15
Содержание:
На чем было опробовано:
1. Введение.
Официальную документацию с официальными примерами всегда можно почитать на сайте разработчиков Ansible.
Как установить и первоначально настроить Ansible описано здесь:
Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:
По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.
Как настраивать защищенные плейбуки описано в этом разделе.
2. Сценарии — playbooks.
Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах.
Рассмотрим структуру и правила написания таких сценариев более подробно.
Все сценарии в Ansible пишутся на YAML — это удобный для человека формат данных, гораздо более простой, чем XML или JSON.
Чтобы выполнить сценарий используется команда ansible-playbook со следующим синтаксисом:
Для Ansible практически каждый YAML файл начинается со списка. Каждый элемент списка — список пар «ключ-значение», часто называемая словарем.
Основными параметрами/группами простого сценария являются:
Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:
Рассмотрим все эти разделы более подробно.
В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.
Так, строка формата:
Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соединение, но и любого другого.
Если добавить параметр ‘ user: postgres ‘, то все действия будут выполняться с привилегиями пользователя postgres.
В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:
Далее указываются модули Ansible, которые будут задействованы при ее выполнении:
Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:
Еще некоторые примеры.
Словарь представлен в виде « ключ: » (двоеточие и пробел) « значение »:
При необходимости словари могут быть представлены в сокращенной форме:
Можно указать логические значение (истина/ложь) так:
Целиком наш пример YAML–файла будет выглядеть так:
Для переменных Ansible использует « << var >> ». Если значение после двоеточия начинается с « < », то YAML будет думать, что это словарь.
Для использования переменных нужно заключить скобки в кавычки:
Этого достаточно для начала написания playbooks.
По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.
3. Обработчики событий — handlers.
4. Контроль выполнения.
Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи.
Для этого можно использовать оператор « when »:
5. Шаблонизация.
В Ansible используется шаблонизатор Jinja2.
Приведём пример шаблона (часть конфигурации powerdns):
В приведённом примере мы подставляем в шаблон следующие значения:
Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template ; он же может задать необходимые права доступа и изменить владельца/группу:
Внимание! Файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.
6. Делегирование задачи другому узлу.
Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла.
7. Роли.
Ролью называется типовой набор переменных и задач, назначаемых для одного или нескольких серверов. Если вам нужно применить к серверу или группе серверов типовой набор операций, вам достаточно просто назначить ему роль. Предварительно в проекте каталоге проекта должна быть создана соответствующая структура.
В сценариях роли назначаются следующим образом:
8. Структура проекта.
9. Пишем первые playbook’и.
Playbook может состоять из списка обслуживаемых серверов, переменных пользователя, задач, обработчиков (хендлеров) и так далее. Большинство настроек конфигурации можно переопределить в playbook. Каждый playbook состоит из одного или более действия (игры) в списке.
Цель игры — связать группу хостов с предопределенными ролями, представленными как вызов задач Ansible.
В качестве другого примера давайте рассмотрим процесс установки nginx.
Создадим директорию, где будут хранится playbooks:
Создадим файл setup_nginx.yml в директории playbooks со следующим содержанием:
Давайте рассмотрим содержимое:
Узнать, на каких узлах будет происходить работа, можно командой:
где – путь к вашему playbook ( playbooks/setup_nginx.yml ).
Задача — это список действий, которые вы хотите выполнить. Поле задачи содержит имя задачи (справочная информация о задаче для пользователя playbook), модуль, который должен быть выполнен и аргументы, требуемые для модуля. Параметр « name » может добавляться опционально, но, в целом, рекомендуемый.
10. Пример сценария.
В этом примере первое воспроизведение предназначено для web-серверов, а второе — для серверов баз данных:
11. Практические примеры плейбуков.
По данной ссылке я создам небольшую подборку типовых плейбуков, которые могут пригодиться вам в повседневной работе.
12. Запуск плейбуков.
Чтобы запустить плейбук и выполнить все определенные в нем задачи, используйте команду ansible-playbook:
13. Запрос информации о play.
Точно так же можно запросить все узлы, которые будут затронуты выполнением play, без запуска каких-либо задач на удаленных серверах:
Вы можете использовать теги, чтобы ограничить выполнение play.
14. Управление выполнением плейбука.
Эта опция в качестве аргумента требует правильное имя задачи:
Например, если вы хотите выполнить только задачи, помеченные как nginx или mysql, вы можете использовать:
15. Настройка защищенных плейбуков.
Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.
Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.
Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон
Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.
Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.
Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но «как-то всё криво».
Названия
Главная ошибка пользователя Ansible — это не знать как что называется. Если вы не знаете названий, вы не можете понимать то, что написано в документации. Живой пример: на собеседовании, человек, вроде бы заявлявший, что он много писал на Ансибле, не смог ответить на вопрос «из каких элементов состоит playbook’а?». А когда я подсказал, что «ожидался ответ, что playbook состоит из play», то последовал убийственный комментарий «мы этого не используем». Люди пишут на Ансибле за деньги и не используют play. На самом деле используют, но не знают, что это такое.
Так что начнём с простого: как что называется. Может быть вы это знаете, а может и нет, потому что не обратили внимания, когда читали документацию.
ansible-playbook исполняет playbook. Playbook — это файл с расширением yml/yaml, внутри которого что-то такое:
Мы уже поняли, что весь этот файл — плейбука. Мы можем показать где тут роли (roles), где таски (tasks). Но где тут play? И чем отличается play от role или playbook?
В документации это всё есть. И это пропускают. Начинающие — потому что там слишком много и всё сразу не запомнишь. Опытные — потому что «тривиальные вещи». Если вы опытный — перечитывайте эти страницы хотя бы раз в полгода, и ваш код станет классом лучше.
и вот это тоже ещё одна play:
Что же такое play? Зачем она?
Если вы хотите «что-то» исполнить «где-то» — вы пишете play. Не роль. Не роль с модулями и делегейтами. Вы берёте и пишете play. В которой, в поле hosts вы перечисляете где исполнять, а в roles/tasks — что исполнять.
Просто же, да? А как может быть иначе?
Одним из характерных моментов, когда у людей возникает желание сделать это не через play, это «роль, которая всё настраивает». Хочется иметь роль, которая настраивает и сервера первого типа, и сервера второго типа.
Архетипичным примером является мониторинг. Хочется иметь роль monitoring, которая настроит мониторинг. Роль monitoring назначается на хосты мониторинга (в соотв. play). Но, выясняется, что для мониторинга нам надо поставить пакеты на хосты, которые мы мониторим. Почему бы не использовать delegate? А ещё надо настроить iptables. delegate? А ещё надо написать/поправить конфиг для СУБД, чтобы мониторинг пускала. delegate! А если креатив попёр, то можно сделать делегацию include_role во вложенном цикле по хитрому фильтру на список групп, а внутри include_role можно ещё делать delegate_to снова. И понеслось.
Благое пожелание — иметь одну-единственную роль monitoring, которая «всё делает» — ведёт нас кромешный ад из которого чаще всего один выход: всё переписать с нуля.
Где тут случилась ошибка? В тот момент, когда вы обнаружили, что для выполнения задачи «x» на хосте X вам надо пойти на хост Y и сделать там «y», вы должны были выполнить простое упражнение: пойти и написать play, которая на хосте Y делает y. Не дописывать что-то в «x», а написать с нуля. Пусть даже с захардкоженными переменными.
Вроде бы, в абзацах выше всё сказано правильно. Но это же не ваш случай! Потому что вы хотите написать переиспользуемый код, который DRY и похож на библиотеку, и нужно искать метод как это сделать.
Вот тут вот притаилась ещё одна грубая ошибка. Ошибка, которая превратила множество проектов из терпимо написанных (можно лучше, но всё работает и легко дописать) в совершенный ужас, в котором даже автор не может разобраться. Оно работает, но упаси боже что-то поменять.
Эта ошибка звучит так: роль — это библиотечная функция. Эта аналогия сгубила столько хороших начинаний, что просто грустно смотреть. Роль — не библиотечная функция. Она не может делать вычисления и она не может принимать решения уровня play. Напомните мне, какие решения принимает play?
Спасибо, вы правы. Play принимает решение (точнее, содержит в себе информацию) о том, какие таски и роли на каких хостах выполнять.
Если вы делегируете это решение на роль, да ещё и с вычислениями, вы обрекаете себя (и того, кто ваш код будет пытаться разобрать) на жалкое существование. Роль не решает где ей выполняться. Это решение принимает play. Роль делает то, что ей сказали, там, где ей сказали.
Почему заниматься программированием на Ансибле опасно и чем COBOL лучше Ансибла мы поговорим в главе про переменные и jinja. Пока что скажем одно — каждое ваше вычисление оставляет за собой нестираемый след из изменения глобальных переменных, и вы ничего с этим не можете сделать. Как только два «следа» пересеклись — всё пропало.
play и только play решает на каких хостах что исполняется.
В этом разделе мы разобрались с противостоянием play и role. Теперь поговорим про отношения tasks vs role.
Таски и Роли
… И куда делись tasks?
Мы снова начинаем с азов — устройство play. Если вы плаваете в этом вопросе, вы не можете использовать play как основу для всего остального, и ваш результат получается «шатким».
Устройство play: директива hosts, настройки самой play и секции pre_tasks, tasks, roles, post_tasks. Остальные параметры для play нам сейчас не важны.
Но мы всё ещё не ответили на вопрос: а куда вызов модуля foo писать? Надо ли нам под каждый модуль писать целую роль? Или лучше иметь толстую роль подо всё? А если не роль, то куда писать — в pre или в post?
Разумеется, формулировка вопроса намекает, что сломается. Но что именно?
И, возвращаемся, к нашему ‘foo’. Куда его поместить? В pre, post или в roles? Очевидно, это зависит от того, нужны ли нам результаты работы хэндлера для foo. Если их нет, то foo не нужно класть ни в pre, ни в post — эти секции имеют специальный смысл — выполнение тасок до и после основного массива кода.
Теперь ответ на вопрос «роль или таска» сводится к тому, что уже есть в play — если там есть tasks, то надо дописать в tasks. Если есть roles — надо делать роль (пусть и из одной task). Напоминаю, tasks и roles одновременно не используются.
Понимание основ Ансибла даёт обоснованные ответы на, казалось бы, вопросы вкусовщины.
Таски и роли (часть вторая)
Теперь обсудим ситуацию, когда вы только начинаете писать плейбуку. Вам надо сделать foo, bar и baz. Это три таски, одна роль или три роли? Обобщая вопрос: в какой момент надо начинать писать роли? В чём смысл писать роли, когда можно писать таски?… А что такое роль?
Одна из грубейших ошибок (я про это уже говорил) — считать, что роль — это как функция в библиотеке у программы. Как выглядит обобщённое описание функции? Она принимает аргументы на вход, взаимодействует с side causes, делает side effects, возвращает значение.
Теперь, внимание. Что из этого можно сделать в роли? Вызвать side effects — всегда пожалуйста, это и есть суть всего Ансибла — делать сайд-эффекты. Иметь side causes? Элементарно. А вот с «передать значение и вернуть его» — вот тут-то и нет. Во-первых, вы не можете передать значение в роль. Вы можете выставить глобальную переменную со сроком жизни размером в play в секции vars для роли. Вы можете выставить глобальную переменную со сроком жизни в play внутри роли. Или даже со сроком жизни плейбуки ( set_fact / register ). Но вы не можете иметь «локальные переменные». Вы не можете «принимать значение» и «возвращать его».
Итого: роль — это не функция.
Что же хорошего есть в роли? Во-первых, у роли есть default values ( /default/main.yaml ), во-вторых у роли есть дополнительные каталоги для складывания файлов.
Ещё одна деталь: можно пытаться делать роли, которые будут доступны для переиспользования (через galaxy). После появления коллекций распространение ролей можно считать почти забытым.
Таким образом, роли обладают двумя важными особенностями: у них есть дефолты (уникальная особенность) и они позволяют структурировать код.
Возвращаясь к исходному вопросу: когда делать таски а когда роли? Таски в плейбуке чаще всего используются либо как «клей» до/после ролей, либо как самостоятельный строительный элемент (тогда в коде не должно быть ролей). Груда нормальных тасок в перемешку с ролями — это однозначная неряшливость. Следует придерживаться конкретного стиля — либо таски, либо роли. Роли дают разделение сущностей и дефолты, таски позволяют прочитать код быстрее. Обычно в роли выносят более «стационарный» (важный и сложный) код, а в стиле тасок пишут вспомогательные скрипты.
Существует возможность делать import_role как таску, но если вы такое пишете, то будьте готовы к объяснительной для собственного чувства прекрасного, зачем вы это хотите делать.
Въедливый читатель может сказать, что роли могут импортировать роли, у ролей может быть зависимость через galaxy.yml, а ещё есть страшный и ужасный include_role — напоминаю, мы повышаем навыки в базовом Ансибле, а не в фигурной гимнастике.
Хэндлеры и таски
Давайте обсудим ещё одну очевидную вещь: хэндлеры. Умение их правильно использовать — это почти искусство. В чём разница между хэндлером и таской?
Так как мы вспоминаем основы, то вот пример:
У роли handler’ы лежат в rolename/handlers/main.yaml. Handler’ы шарятся между всеми участниками play: pre/post_tasks могут дёргать handler’ы роли, а роль может дёргать handler’ы из плей. Однако, «кросс-ролевые» вызовы handler’ов вызывают куда больший wtf, чем повтор тривиального handler’а. (Ещё один элемент best practices — стараться не делать повторов имён handler’ов).
Основное различие в том, что таска выполняется (идемпотентно) всегда (плюс/минус теги и when ), а хэндлер — по изменению состояния (notify срабатывает только если был changed). Чем это чревато? Например, тем, что при повторном запуске, если не было changed, то не будет и handler. А почему может быть так, что нам нужно выполнить handler когда не было changed у порождающей таски? Например, потому что что-то сломалось и changed был, а до хэндлера выполнение не дошло. Например, потому что сеть временно лежала. Конфиг поменялся, сервис не перезапущен. При следующем запуске конфиг уже не меняется, и сервис остаётся со старой версией конфига.
Ещё одно положительное свойство handler’а состоит в том, что он не засоряет вывод. Не было изменений — нет лишних skipped или ok в выводе — легче читать. Оно же является и отрицательным свойством — если опечатку в линейно исполняемой task’е вы найдёте на первый же прогон, то handler’ы будут выполнены только при changed, т.е. при некоторых условиях — очень редко. Например, первый раз в жизни спустя пять лет. И, разумеется, там будет опечатка в имени и всё сломается. А второй раз их не запустить — changed-то нет.
Отдельно надо говорить про доступность переменных. Например, если вы notify для таски с циклом, то что будет в переменных? Можно аналитическим путём догадаться, но не всегда это тривиально, особенно, если переменные приходят из разных мест.
… Так что handler’ы куда менее полезны и куда более проблемны, чем кажется. Если можно что-то красиво (без выкрутас) написать без хэндлеров лучше делать без них. Если красиво не получается — лучше с ними.
Чем меньше if’ов (явных или декларативных — в форме when или форме include_vars по набору переменных), тем лучше роль. Иногда приходится делать ветвления, но, повторю, чем их меньше, тем лучше. Так что вроде бы хорошая роль с galaxy (работает же!) с кучей when может быть менее предпочтительна, чем «своя» роль из пяти тасок. Момент, когда роль с galaxy лучше — когда вы что-то начинаете писать. Момент, когда она становится хуже — когда что-то ломается, и у вас есть подозрение, что это из-за «роли с galaxy». Вы её открываете, а там пять инклюдов, восемь таск-листов и стопка when ‘ов… И в этом надо разобраться. Вместо 5 тасок линейным списком, в котором и ломаться-то нечему.