Архив рубрики: Публикации

Самые умные птицы – ТОП-10 самых умных видов птиц в мире

Вы можете подумать, что животные неразумны, но это заблуждение. На самом деле они могут выполнять некоторые задачи, к которым они приспособлены даже лучше, чем люди. Однако вопрос «умны ли животные» до сих пор остается предметом дискуссий среди исследователей. Некоторые придерживаются мнения, что животные могут реагировать на определенные раздражители, в то время как другие утверждают, что эти существа генетически наделены определенными полезными инстинктами и не способны делать что-либо большее. Но что правда? Какому утверждению мы должны верить?

Что ж, это не так просто, интеллект – это сложное понятие, и ответ зависит от разных восприятий. Проблема животных в том, что их интеллект нельзя измерить количественно. Вы не можете заставить их пройти тесты или сравнить их со своими сверстниками. Затем исследователи разработали тесты для измерения когнитивных способностей животного, но не смогли найти правильных ответов. После множества проб и ошибок они поняли, что совершали ошибку, тестируя животных с помощью задач, которые могли выполнять только люди. После того, как они оценили каждый вид на предмет определенного поведения, понятного животному, они смогли определить свой интеллект.

Какие виды самые умные?

Все мы слышали о ловкости лисы и интеллекте дельфинов. В общем, вы можете рассматривать собак и кошек более умно, чем птиц, рептилий и насекомых. Это может вас удивить, но птицы – одни из самых умных существ в мире. Наши пернатые товарищи умны и могут адаптироваться к новым условиям и окружающей среде. Практическим примером этого является тот факт, что птицы преодолевают расстояния до 44000 миль во время миграции ради пищи и других ресурсов.

У них пропорционально большой мозг

Чтобы проанализировать интеллект птиц, мы можем рассмотреть размер и структуру мозга. Исследования показывают, что их мозг больше по сравнению с маленькими телами. Кроме того, различные области мозга птицы имеют более высокую взаимосвязь, чем остальные млекопитающие. Что ж, я не удивлен, то, как мой волнистый попугайчик имитирует все, что мы говорим вокруг него, много говорит о его интеллекте. Но это всего лишь один пример; многие другие наблюдения подтверждают это утверждение. Например, вьюрки-дятлы разрезают палки на отрезки соответствующей длины, чтобы использовать их в качестве инструментов для охоты на насекомых, или вороны-падальщики, которые кладут орехи на дорогу, чтобы приближающиеся машины могли раздавить скорлупы.

Что ж, в мире около 18000 видов, давайте взглянем на 10 самых умных птиц, попавших в список:

Вороны:

В США насчитывается более 30 миллионов ворон, но животные не получают должной оценки. Многие из нас могут считать их жуткими, но они одни из самых умных существ в мире. Вороны способны решать сложные задачи; их мозг почти размером с большой палец. Исследования также показывают, что они способны считать до 5, создавать индивидуальные инструменты для их использования и могут запоминать лица. Исследователи наблюдали это явление, сделав сканирование своего мозга, которое показало, что они могут идентифицировать людей, которые кажутся дружелюбными или опасными, и запоминать их лица. Вся семья Corvidae, в которую входят вороны, вороны, сойки и грачи, имеет очень сложную социальную структуру; они делятся информацией со всей группой, а затем принимают решения. Они также способны строить прочные связи с людьми.

Кеа:


Птица – одна из самых умных среди всех разновидностей и известна своими выходками. Кеа – это попугай, который происходит из Новой Зеландии. Хотя ки – дружелюбные и игривые птички, они имеют репутацию печально известной воровства еды. Кеасы беспокоят людей и имеют обыкновение уничтожать машины и оборудование. Однако по некоторым тестам на интеллект они превзошли животных, таких как гиббоны и обезьяны. Другое исследование выявило необычную характеристику нечеловеческих существ, которую продемонстрировал Кеа. В задаче, где одной птице приходилось ждать, пока другой партнер более минуты работает вместе и высвобождает пищу, Ки проявили замечательный интеллект и командную работу. Это показало их способность определять, когда им нужно работать в команде и ждать партнера по сотрудничеству.

Какаду:



Эти живые птицы принадлежат к семейству попугаев и не только умны, но и ласковы. Какаду обладают прекрасными речевыми способностями и могут имитировать звуки и слова, которые они слышат. Исследования показывают, что они умнее четырехлетних детей. Исследование показало, что какаду могут распознавать скрытый объект. Кроме того, они могут отслеживать один и тот же элемент, если вы поместите его в другое место. Фактически, их способность к постоянству объектов выше, чем у четырехлетних детей. Если вы держите одного из них в качестве домашнего питомца, убедитесь, что в клетке есть много забавных игрушек.

Ара:



Ара не только разноцветны, но и обладают яркой индивидуальностью. Они могут показаться забавными и интересными, но при этом довольно умны, игривы и ласковы. Это попугаи, принадлежащие к одному из шести родов, самый большой из которых имеет длину около 4 футов. Анализ последовательности генома ара показывает, что геном имел основу ДНК, которая составляет одну треть того, что есть у млекопитающих. Они могут выполнять фокусы и обладают отличными когнитивными способностями.

Африканский серый:



В серости известна своими способности говорить; они могут имитировать наши звуки и слова и быстро их улавливать. Они могут выучить до 200 слов или даже больше, а также могут имитировать звуки животных, чтобы отпугнуть хищников, но это еще не все. Согласно исследованию, эти попугаи обладают отличными способностями к рассуждению, которые могут и могут находить спрятанную пищу, используя свои навыки обнаружения. Человеческие дети развивают эту способность в трехлетнем возрасте, поэтому африканских серых можно считать умнее трехлетних.

Вороны:



Другой член семейства Corvidae, Вороны также являются одними из самых умных видов в мире. Известно, что вороны работают в командах во время охоты за едой, поскольку один партнер отвлекает родителей, а другой нападает на новорожденного. Исследования также показывают, что Вороны могут планировать будущее. Исследователи заметили, что птицы держали инструменты в стороне, которые, по их мнению, пригодились бы им позже. У них также есть свои уникальные призывы обращаться к другим воронам и отличные навыки памяти; они могут узнать друг друга после долгих лет разлуки.

Щелкунчики:



Они связаны с воронами и сойками; несомненно, в семье есть одни из самых умных птичек. Щелкунчики также известны своей памятью и знанием своего окружения. Летом они собирают огромное количество семян сосны на зиму и закапывают их на площади в 200 квадратных миль. Они запоминают все места (их может быть около 3000), где хранят эти семена. Они также достаточно умны, чтобы считать числа. Щелкунчики всегда выбирают из заданной кучи семян ту, в которой содержится большее количество семян.

Джейс:



К семейству относятся разные виды сойок, такие как голубая сойка, евразийская сойка, калифорнийская сойка и многие другие. Евразийский Джей умен, поскольку он знает, как произвести впечатление на свою половинку. Он получает подарки для супруга, и это, скорее всего, именно то, чего он хочет. Scrub Jays – планировщики, которые думают о будущем. Например, они решат, что они хотят съесть на завтрак на следующий день, найдут еду и сохранят ее. В неволе синие сойки умны и используют бумагу со дна клетки для создания инструментов, которые могут помочь достать предметы за пределами вольера. Недавние исследования также показали, что Jay’s может имитировать знакомые звуки и может имитировать людей.

Сорока:



Это единственные птицы, прошедшие испытание на зеркало. Тест – это метод оценки самосознания существа. В эксперименте на животное наносят метку или наклейку в месте, которое они не видят. Затем их заставляют стоять перед зеркалом, если птица царапает пятно и пытается его удалить; это показатель того, что они осознают себя. Его успешно прошли евразийские сороки. Также известно, что они хорошо играют в «прятки»; их результаты на уровне 4-5-летних. Они также общительны и могут копить блестящие предметы,

Ладьи:



Еще один член семейства вороньих, Грачи обладают исключительными навыками решения задач. Они могут решить задачу из басни Эзопа, где ворона должна пить воду из частично наполненного кувшина. Талантливые грачи также используют ту же технику, что и ворона в книге, и пьют воду. Они также используют и даже создают свои инструменты. Исследование, проведенное в университетах Кембриджа и Королевы Марии, показало, что грачи всегда выбирают правильный тип инструмента, когда им предлагают задачу и набор инструментов.

Автор Автор:

Даника Бойд – энтузиаст птиц и любителей природы. В течение нескольких лет она разводила домашних птиц и теперь имеет огромный практический опыт ухода за птицами. Она пишет для команды birdcagesnow.com.

Источник записи: www.wonderslist.com



2021-09-02T09:51:00
Животные

Ansible: Сбор произвольной информации на хостах с помощью Ansible custom facts. Вывод информации в формате *.json.

На чем было опробовано:




  1. Ansible 2.9.18
  2. Hyper-V на Windows 10 Pro.
  3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
  4. Node 1: CentOS Linux release 7.9.2009 (Core).
  5. Node 2: CentOS Linux release 7.9.2009 (Core).
  6. Node 3: CentOS Linux release 7.9.2009 (Core).
  7. Node 4: CentOS Linux release 7.9.2009 (Core).








1. Задача.




К примеру, нам требуется с помощью внедрения custom facts для Ansible организовать сбор версий контейнеров, запущенных на серверах, а так же сбор версий некоторого программного обеспечения на серверах, которое имеет файл с указанием версии в своём каталоге /ecp/po/version.txt.




Собранная информация должна формироваться в json-формат.




Дополнительно требуется рассмотреть средства визуализации информации в удобном виде (opensource web-приложения).




2. Решение задачи.




Решение будет состоять из нескольких этапов:







В системе Ansible есть возможность собирать системную информацию, которая собирается в виде фактов с помощью встроенного модуля setup.




Со сбором стандартных переменных по умолчанию всё предельно ясно, но что делать, если мы хотим сформировать наши собственные переменные на всех хостах, чтобы в дальнейшем использовать их в нашем коде?




Для этого существует возможность добавления Custom facts, что делается следующим образом:







Создаем инвентарь test-servers.inventory на 4 тестовых сервера:




# mcedit /ansible/test-servers.inventory




С таким содержимым:




[test_servers]
server1   ansible_ssh_host=192.168.0.39 ansible_ssh_user=root
server2   ansible_ssh_host=192.168.0.30 ansible_ssh_user=root
server3   ansible_ssh_host=192.168.0.31 ansible_ssh_user=root
emachines ansible_ssh_host=192.168.0.12 ansible_ssh_user=root




Создаем специальный custom.fact файл для загрузки на узлы, который, по сути, является скриптом для выполнения некоторого комплекса действий на удалённом узле.




По замыслу будут собираться некоторые переменные и заворачиваться в разметку json.




#!/bin/bash

file_po="/etc/po/version.txt"
host_name=$(hostname)
ecp_ver=$(awk -F: '/rel_ver/{print $2}' $file_po)
docker_info=$(docker ps --format ' {{json .Names}}: {{json .Image}}, ' | paste -sd'n' | sed '$ s/.$//')
jp="/$host_name.json"

echo "{" > $jp
echo ""Информация об узлах": {" >> $jp
echo ""$host_name": {" >> $jp
if test -f "$file_po"; then
    echo ""Софт": {" >> $jp
    echo ""Версия чего-то": "$ecp_ver"" >> $jp
    echo "}" >> $jp
    echo "," >> $jp
fi
echo ""Докеры на узле": {" >> $jp
echo "$docker_info" >> $jp
echo "}" >> $jp
echo "}" >> $jp
echo "}" >> $jp
echo "}" >> $jp




Создаём специальный playbook custom-facts-fetch.yml, содержащий сценарий /ansible/files/custom.fact для узла, возвращающий некоторый файл json на Ansible master сервер с каждого узла:




---
- name: "Cбор Ansible custom facts"
  hosts: all

  tasks:
  - name: "Удаление предыдущей версии Ansible custom facts файлов на узле"
    file:
      state: "absent"
      path: "/etc/ansible/facts.d/"

  - name: "Создание Ansible custom fact каталога"
    file:
      path: "/etc/ansible/facts.d"
      state: "directory"
      mode: 0766

  - name: "Загрузка на узлы Ansible custom fact файлов"
    copy:
      src: "/ansible/files/custom.fact"
      dest: "/etc/ansible/facts.d/custom.fact"
      mode: +x

  - name: "Объявление служебной переменной для Ansible custom fact"
    debug: "var=ansible_local"
    notify:
    - reload facts

  - name: "Перезагрузка facts"
    setup: "filter=ansible_local"

  - name: "Подготовка списка файлов *.json для выгрузки с узла"
    find:
      paths: "/"
      recurse: "no"
      patterns: "*.json"
    register: "files_to_copy"

  - name: "Выгрузка файлов *.json с узла на Ansible master сервер"
    fetch:
      src: "{{ item.path }}"
      dest: "/ansible/json"
    with_items: "{{ files_to_copy.files }}"




Напишем скрипт custom-facts-fetch-PLAY.sh для запуска playbook на целевом inventory:




#!/bin/bash.

ansible-playbook /ansible/custom-facts-fetch.yml -i /ansible/test-servers.inventory




Сделаем файл скрипта исполняемым:




# chmod +x custom-facts-fetch-PLAY.sh




И запустим его.




Ответ:







После успешной отработки playbook на сервере Ansible master появится каталог /ansible/json с подкаталогами ‘имя_узла‘:







В каждом из которых будет находиться json файл вида имя_узла.json:
















Содержимое json файла первого узла emachines:







Содержимое json файла второго узла server1:







Содержимое json файла третьего узла server2:







Содержимое json файла четвертого узла server3:







Получилось несколько файлов json, по файлу с каждого целевого узла.




Сколько узлов мы задействовали для Ansible custom facts, столько и json файлов и будет.




В первом файле emachines.hamsterden.loc.json не имеется фрагмент с названием «Версия чего-то‘, по втором файле cos7client1.hamsterden.loc.json такой фрагмент имеется, а так как в custom.fact реализована проверка на фактическое наличия файла /ecp/po/version.txt.




К примеру, наличие файла /ecp/po/version.txt бывает только у серверов типа «web-server». Так как скрипт «сам учитывает» тип сервера, то можно смело применять custom.fact на все целевые серверы и файл json всегда будет генерироваться корректно для каждого типа серверов.




Для создание сводного json файла по всем файлам со всех узлам, воспользуемся утилитой jq.




Ссылка на официальный сайт утилиты: https://stedolan.github.io/jq/.




Установка утилиты:




# yum install jq -y




План работ с файлами:




file1.json + file3.json + file3.json + file4.json = final_result_po.json




Создадим make-final-json-file.sh скрипт:




# mcedit /ansible/make-final-json-file.sh




#!/bin/bash

#создание каталогов для обработки файлов
mkdir -p /ansible/json/temp
mkdir -p /ansible/json-ready

#каталог куда Ansible кладет скачанные json файлы с узлов
ja="/ansible/json"

#временный каталог куда Ansible складывает все json файлы из всех каталогов узлов перед сведением информации в единый файл json
jrt="/ansible/json/temp"

#каталог куда Ansible помещает сводный json файл со всей добытой информацией по узлам
jr="/ansible/json-ready"

#обработка файлов и удаление временных промежуточных результатов
cp -i $(find /$ja -iname "*.json") $jrt
cd $jrt
jq -s '.[0] * .[1] * .[2] * .[3]' *.json > "$jrt"/temp.json
cat "$jrt"/temp.json | sed 's/{}/"нет докеров"/' > "$jr"/final_result_po.json

#удаление временных каталогов и файлов
rm -rf $jrt
rm -rf $ja




Сделаем файл скрипта исполняемым:




# chmod +x /ansible/make-final-json-file.sh




Результатом работы скрипта будет сводный json файл всех четырёх final_result_po.json в каталоге /ansible/json_ready на Ansible master сервере:







Текстовый файл:




{
  "Информация об узлах": {
    "cos7client1.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "9.11.2"
      },
      "Докеры на узле": {
        "wordpress-compose_nginx_1": "nginx:latest",
        "wordpress-compose_wordpress_1": "wordpress:php7.4-fpm-alpine",
        "wordpress-compose_pma_1": "phpmyadmin/phpmyadmin",
        "wordpress-compose_mysql_1": "mariadb"
      }
    },
    "cos7client2.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "10.2.1"
      },
      "Докеры на узле": "нет докеров"
    },
    "cos7client3.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "9.3.4"
      },
      "Докеры на узле": "нет докеров"
    },
    "emachines.hamsterden.loc": {
      "Докеры на узле": {
        "onlyoffice": "onlyoffice/documentserver",
        "funny_heisenberg": "onlyoffice/documentserver"
      }
    }
  }
}




Если открыть final_result_po.json файл в браузере Mozilla Firefox, то информация будет корректно визуализирована в удобно читаемом виде:







Задача выполнена!




X. Оригиналы источников информации.




  1. golinuxcloud.com «Working with Ansible facts | Create custom facts with examples».
  2. github.com «Ansible local fact example».
  3. medium.com «Custom facts for Ansible».
  4. otus.ru «Ansible: формируем переменные на всех хостах с Custom facts».
  5. mydailytutorials.com «Working with Ansible facts – retrieving facts».
  6. adyxax.org «Ansible custom factsAnsible custom facts».
  7. Источник: https://hamsterden.ru/ansible-collecting-arbitrary-information-on-all-hosts-with-custom-facts/






2021-09-01T15:48:22
Software

Ansible: Часть 5. Настройка защищенных плейбуков.

На чем было опробовано:




  1. Ansible 2.9.18
  2. Hyper-V на Windows 10 Pro.
  3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
  4. Node 1: CentOS Linux release 7.9.2009 (Core).
  5. Node 2: CentOS Linux release 7.9.2009 (Core).
  6. Node 3: CentOS Linux release 7.9.2009 (Core).








1. Введение.




Как установить и первоначально настроить Ansible описано здесь:




Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»




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




Ссылка: «Ansible: Часть 2. Примеры простых задач.»




Рассмотрим структуру и правила написания таких сценариев более подробно.




Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»




По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.




Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»




2. Ansible Vault для хранения конфиденциальных данных.




Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.




Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.




2.1. Создание нового зашифрованного файла.




Вы можете создать новый зашифрованный файл Ansible с помощью:




# ansible-vault create credentials.yml




Эта команда выполнит следующие действия:




  1. Сначала вам будет предложено ввести новый пароль. Вам нужно будет указывать этот пароль при каждом доступе к содержимому файла, будь то редактирование, просмотр или просто запуск плейбука или команд с использованием его значений.
  2. Затем откроется редактор командной строки по умолчанию, чтобы вы могли заполнить файл требуемым содержимым.
  3. Наконец, когда вы закончите редактирование, ansible-vault сохранит файл как зашифрованный.




2.2. Шифрование существующего файла.




Чтобы зашифровать существующий файл Ansible, вы можете использовать следующую команду:




# ansible-vault encrypt credentials.yml




Эта команда запросит у вас пароль, который вам нужно будет вводить при каждом доступе к файлу credentials.yml.




2.3. Просмотр содержимого зашифрованного файла.




Если вы хотите просмотреть содержимое файла, который ранее был зашифрован с помощью ansible-vault, и вам не нужно изменять его содержимое, вы можете использовать команду:




# ansible-vault view credentials.yml




Она предложит вам указать пароль, который вы выбрали при первом шифровании файла с помощью ansible-vault.




2.4. Редактирование зашифрованного файла.




Чтобы изменить содержимое файла, который ранее был зашифрован с помощью ansible-vault, выполните:




# ansible-vault edit credentials.yml




Эта команда предложит вам указать пароль, который вы выбрали при первом шифровании файла credentials.yml. После проверки пароля откроется редактор командной строки по умолчанию с незашифрованным содержимым файла, что позволит вам внести нужные изменения. По завершении вы можете сохранить и закрыть файл, как обычно, и обновленное содержимое будет сохранено и зашифровано.




2.5. Расшифровка файлов.




Если вы хотите навсегда расшифровать файл, ранее зашифрованный с помощью ansible-vault, вы можете сделать это с помощью следующего синтаксиса:




# ansible-vault decrypt credentials.yml




Эта команда предложит вам ввести тот пароль, который использовался при первом шифровании файла. После проверки пароля содержимое файла будет сохранено на диск в виде незашифрованных данных.




3. Использование нескольких паролей.




Ansible поддерживает для хранилища несколько паролей, сгруппированных по разным идентификаторам. Это полезно, если вы хотите иметь выделенные пароли хранилища для различных сред – для разработки, тестирования и производства.




Чтобы создать новый зашифрованный файл с пользовательским идентификатором хранилища, включите параметр --vault-id вместе с меткой и расположением, где ansible-vault может найти пароль для этого хранилища. Метка может быть любой, а расположение может быть либо prompt (что означает, что команда должна предложить вам ввести пароль), либо путь к файлу паролей.




# ansible-vault create --vault-id dev@prompt credentials_dev.yml




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




# ansible-vault create --vault-id prod@prompt credentials_prod.yml




Мы использовали dev и prod в качестве идентификаторов хранилищ, чтобы продемонстрировать, как вы можете создавать отдельные хранилища для каждой среды. Самостоятельно вы можете создать столько хранилищ, сколько захотите, и использовать любой ID.




Теперь, чтобы просмотреть, отредактировать или расшифровать эти файлы, вам необходимо предоставить тот же ID хранилища и источник пароля вместе с командой ansible-vault:




# ansible-vault edit credentials_dev.yml --vault-id dev@prompt




4. Использование файла паролей.




Если вам нужно автоматизировать процесс инициализации серверов в Ansible с помощью стороннего инструмента, вам потребуется способ ввода пароля хранилища без его запроса. Вы можете сделать это, используя файл паролей через ansible-vault.




Файл паролей может быть простым текстовым файлом или исполняемым скриптом. Если файл является исполняемым, выходные данные, созданные ним, будут использоваться в качестве пароля хранилища. В противном случае в качестве пароля хранилища будет использоваться необработанное содержимое файла.




Чтобы применить файл паролей в ansible-vault, необходимо указать путь к файлу паролей при выполнении любой из команд vault:




# ansible-vault create --vault-id dev@path/to/passfile credentials_dev.yml




Ansible не различает контент, который был зашифрован с помощью prompt, и простой файл пароля при условии, что входной пароль один и тот же. С практической точки зрения это означает, что файл можно зашифровать, используя prompt, а затем создать файл пароля для хранения того же пароля, который использовался в методе prompt. Также верно и обратное: вы можете зашифровать содержимое, используя файл паролей, а затем использовать метод prompt, предоставляя тот же пароль при запросе Ansible.




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




Официальный репозиторий Ansible содержит несколько примеров сценариев, которые вы можете использовать для справки при создании своего скрипта под потребности вашего проекта.




5. Запуск плейбука с зашифрованными данными.




Каждый раз, когда вы запускаете плейбук, в котором используются данные, ранее зашифрованные с помощью ansible-vault, вам нужно будет указывать пароль хранилища в команде playbook.




Если вы использовали параметры по умолчанию и prompt при шифровании данных плейбука, вы можете использовать опцию --ask-vault-pass, чтобы Ansible запрашивал пароль:




# ansible-playbook myplaybook.yml --ask-vault-pass




Если вы использовали файл пароля вместо prompt, вы должны использовать опцию --vault-password-file:




# ansible-playbook myplaybook.yml --vault-password-file my_vault_password.py




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




# ansible-playbook myplaybook.yml --vault-id dev@prompt




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




# ansible-playbook myplaybook.yml --vault-id dev@vault_password.py




Если ваш play использует несколько хранилищ, вы должны добавить параметр --vault-id для каждого из них в произвольном порядке:




# ansible-playbook myplaybook.yml --vault-id dev@vault_password.py --vault-id test@prompt --vault-id ci@prompt




6. Оригиналы источников информации.




  1. selectel.ru «Система управления конфигурацией Ansible».
  2. dmosk.ru «Инструкция по установке и запуску Ansible на CentOS».
  3. dmosk.ru «Что такое ansible».
  4. 8host.com «Как работать с Ansible: простая удобная шпаргалка».
  5. habr.com «Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 1: Введение».
  6. kamaok.org.ua «Установка и использование Ansible на Centos7».
  7. Источник: https://hamsterden.ru/ansible-vault-playbooks/






2021-09-01T15:40:11
Software

10 вопросов, которые стоит задать вашему провайдеру ИТ-безопасности. Часть 2

Какой ваш план действий в случае утечки данных?

Эксперты по кибербезопасности согласятся, что вопрос больше не в том, «если», а в том, «когда» вы будете взломаны.

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

Правление также должно знать законы, регулирующие его обязанности по раскрытию утечки данных. Директива NIS и GDPR являются примерами законодательства, которое вводит обязательства по уведомлению о корпоративных нарушениях.

 

Соблюдают ли ведущие стандарты ИТ-безопасности?

Примеры включают ведущий международный стандарт управления информационной безопасностью ISO 27001, Стандарт безопасности данных индустрии платежных карт (PCI DSS) и схему Cyber ​​Essentials (которая обеспечивает базовую защиту кибербезопасности от 80% кибератак).

Сертификация по ведущим международным стандартам, таким как ISO 27001, означает, что компания применяет проверенную передовую практику в области кибербезопасности и представляет целостный подход к защите не только информации в Интернете, но и рисков, связанных с людьми и процессами.

Компания также может выбрать независимую сертификацию, чтобы убедиться, что реализованные средства управления работают должным образом.

 

Правильно ли расходуется наш бюджет на ИТ-безопасность?

Установление бюджета на ИТ-безопасность — это не просто получение денег на покупку дополнительных технологий для исправления дыр в кибербезопасности. Главное — использовать стратегический подход к распределению бюджета, чтобы реально изменить положение компании в области информационной безопасности.

Повышенная безопасность не приводит к расширению технологий. Фактически, одни только технологии не защитят ваш бизнес от постоянных угроз.

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

 

Есть ли у нас видимость в сети?

Плохая видимость поведения сети может нанести серьезный ущерб организации. Исследование IBM Cost of Data Breach Study 2017 показало, что среднее время на обнаружение утечки данных составляет 191 день.

Многие администраторы не имеют достаточно глубокого доступа к сети и аналитике безопасности, которые им необходимы, чтобы иметь точное представление о том, что на самом деле происходит, и не имеют инструментов, которые могут быстро идентифицировать, интерпретировать и реагировать на угрозы.

ИТ-отделы и службы безопасности должны иметь возможность поддерживать четкую и постоянную видимость в сети.

 

Когда вы в последний раз тестировали наши процедуры восстановления?

Исследование стоимости утечки данных : влияние управления непрерывностью бизнеса в 2017 г., проведенное Институтом Ponemon, показало, что программы обеспечения непрерывности бизнеса значительно сокращают время на выявление и устранение утечек данных.

Эффективное управление непрерывностью бизнеса (BCM) помогло компаниям сэкономить 43 дня на выявлении нарушения и 35 дней на его локализации.

Планы BCM и аварийного восстановления необходимо регулярно тестировать, чтобы установить, может ли бизнес быстро восстановиться после атаки. Некоторые из соображений «что, если» должны установить, насколько уязвимы сами варианты отката для кибератак.

Например, злонамеренное нападение на ваши данные может не обнаруживаться в течение некоторого времени, а данные резервного копирования также могут быть

скомпрометированы.

 

Заключение

Передача ИТ-безопасности на аутсорсинг — отличный способ защитить вашу компанию. Однако, как и в случае с любым аутсорсингом, жизненно важно выбрать правильную компанию и быть в курсе последних событий в области безопасности.

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

 

Начало:



2021-09-01T13:01:06
Безопасность

10 вопросов, которые стоит задать вашему провайдеру ИТ-безопасности

Кибербезопасность затрагивает все компании любого размера во всех секторах. Угрозы серьезны и развиваются, а законодательные и нормативные требования растут. Ущерб, с которым сталкиваются предприятия, означает, что ИТ-безопасность слишком велика, чтобы ее игнорировать.

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

ИТ-безопасность такая же, как и любая другая сторонняя услуга, как услуга IT-поддержки, обслуживания и сопровождения юридических лиц: https://itspectr.ru/it-podderzhka/ в Москве. Если вы пользуетесь услугами бухгалтера, вы все равно проверяете свой банковский баланс. Так что только потому, что у вас есть обеспечение ИТ-безопасности, вы все равно должны проявлять интерес к своей безопасности.

Здесь мы собрали 10 вопросов, которые нужно задать вашему провайдеру ИТ-безопасности:

 

С какими основными рисками сталкивается мой бизнес?

По данным Gartner, к 2020 году 30% компаний Global 2000 будут напрямую скомпрометированы независимой группой киберактивистов или киберпреступников.

Вашему бизнесу необходимо расставить приоритеты по реальным рискам, выявляя бреши в безопасности и их влияние на ваш бизнес. Затем вы можете убедиться, что бюджет для управления этими рисками назначен соответствующим образом.

Вам следует спросить своего поставщика ИТ-безопасности , хорошо ли он понимает влияние соответствующих юридических, нормативных и договорных требований, связанных с кибербезопасностью.

 

Вы тестируете наши системы, прежде чем возникнет проблема?

Существует множество тестов, которые могут оценить уязвимость систем, сетей и приложений. Важным элементом любого режима безопасности должны быть регулярные тесты на проникновение.

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

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

 

Вы проводите регулярную оценку рисков ИТ-безопасности?

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

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

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

 

Как соблюдается кибербезопасность?

Аудит может помочь вашему бизнесу понять эффективность своей кибербезопасности. Если организация решила соответствовать стандарту информационной безопасности, например ISO 27001, орган по сертификации может провести независимую проверку ее средств управления информационной безопасностью.

Затем это можно использовать в качестве конкурентного преимущества при проведении торгов на новый бизнес, как в случае с компаниями, сертифицированными по ISO 27001.

Сертификаты также могут предоставить убедительные доказательства того, что компания проявляла должную осторожность при защите своих информационных активов.

 

Предлагаете ли вы эффективную программу повышения осведомленности в области ИТ-безопасности?

Большое количество нарушений вызвано ошибкой или халатностью сотрудников. Опрос GSIS показывает, что сотрудники несут ответственность за 27% всех инцидентов, связанных с кибербезопасностью.

Социальная инженерия остается распространенной тактикой, при которой преступники могут проникнуть в сеть закулисными методами, используя уязвимых или неосведомленных сотрудников.

Невозможно переоценить критическую важность эффективной программы повышения осведомленности персонала. Исследования показывают, что традиционные меры по повышению осведомленности о кибербезопасности можно значительно улучшить с помощью многогранной программы безопасности, которая полностью меняет корпоративную культуру и борется с постоянным неправильным поведением сотрудников.

 

Продолжение:



2021-09-01T12:52:02
Безопасность

Ansible: Часть 4. Практические примеры плейбуков.

На чем было опробовано:




  1. Ansible 2.9.18
  2. Hyper-V на Windows 10 Pro.
  3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
  4. Node 1: CentOS Linux release 7.9.2009 (Core).
  5. Node 2: CentOS Linux release 7.9.2009 (Core).
  6. Node 3: CentOS Linux release 7.9.2009 (Core).








1. Введение.




Для тех, кто решит изучать Ansible, данный раздел будет крайне полезен. В данном разделе соберу некоторые полезные примеры из повседневной практики, чтобы вы могли понять как работает Ansible и научиться его использовать самостоятельно.




Официальную документацию с официальными примерами всегда можно почитать на сайте разработчиков Ansible.




Ссылка: docs.ansible.com.
Раздел: «Intro to playbooks».




Как установить и первоначально настроить Ansible описано здесь:




Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»




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




Ссылка: «Ansible: Часть 2. Примеры простых задач.»




Рассмотрим структуру и правила написания таких сценариев более подробно.




Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»




Как настраивать защищенные плейбуки описано в этом разделе.




Ссылка: «Ansible: Часть 5. Настройка защищенных плейбуков.»




2. Схема учебного стенда.




Пускай у нас будет вот такой стенд из 4х виртуальных машин под управлением CentOS 7:







Все сервера, в данном примере, имеют одинаковую операционную систему CentOS Linux release 7.9.2009 (Core), одинаковых пользователей root и одинаковые пароли на учетных записях root.




Задачи: для всех узлов.







Протестировать:







Условие: удалённые виртуальные машины можно настраивать только системой Ansible.




Дополнительно: еще в эту инструкцию я буду добавлять разные новые и полезные примеры, но вверху в задачах, учитывать это не буду.




3. Подготовка сервера Ansible.




Первым делом отключим на Ansible Server систему SELinux. Рамках учебного стенда она нам не нужна.




Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux.




Ссылка: «CentOS 7: Как временно или навсегда отключить SELinux».




3.1. Отключение SELinux.




Конечно в интернете имеется много способов настройки и эксплуатации этой системы, но в данной инструкции я, пока что, настраивать SELinux не буду.




Пожалуй, это самый суровый способ, но тоже работает.




Вводим команду:




# yum -y remove selinux*




Перезапустим Ansible Server:




# shutdown -r now




3.2. Обновление системы.




Обновим полностью операционную систему сервера Ansible:




# yum -y update && yum -y upgrade




3.3. Установка Ansible.




По умолчанию Ansible нет в репозитории CentOS 7.




Подключим дополнительный репозиторий EPEL:




# yum -y install epel-release




После устанавливаем сам сервер управления Ansible:




# yum -y install ansible




Проверка версии установленной версии Ansible:




# rpm -qa | grep ansible




Ответ:







или вот так:




# ansible --version




Ответ:







Отлично! Теперь у нас есть сервер Ansible.




3.4. Создание файла инвентаря.




Установим файловый менеджер и текстовый редактор в одном лице — Midnight Commander:




# yum -y install mc




Файл инвентаря по умолчанию обычно находится в /etc/ansible/hosts, но вы можете использовать опцию -i для указания пользовательских файлов при запуске команд и плейбуков для Ansible.




Это удобный способ настройки индивидуального инвентаря для каждого проекта, который можно включить в системы контроля версий, такие как Git.




Создадим свой файл нашего инвентаря:




# cd ~
# mkdir -p ~/ansible-inventory
# cd ~/ansible-inventory
# touch my-test-servers.inventory




Откроем наш файл инвентаря:




# mcedit /root/ansible-inventory/my-test-servers.inventory




Создадим такой файл inventory вот с таким наполнением:




[test_servers]
server1 ansible_ssh_host=192.168.0.39 ansible_ssh_user=root
server2 ansible_ssh_host=192.168.0.30 ansible_ssh_user=root
server3 ansible_ssh_host=192.168.0.31 ansible_ssh_user=root




где







3.5. Генерация ключей пользователя root.




Создаём пару RSA-ключей для пользователя root на Ansible сервере:




# ssh-keygen




На все вопросы жмём Enter. Нам не нужны никакие пароли на ключи и генерируем ключи мы в каталог по умолчанию.




Ответ:







3.6. Проброс root-ключей на узлы.




Копируем открытые ключи пользователя root на узлы, которыми планируем управлять с помощью Ansible.




Выполним команду автоматической установки публичного ключа пользователя root на все узлы с авторизацией по паролю, до которых может дотянутся Ansible по списку инвентаря my-test-servers.inventory.




# ansible all -m authorized_key -a "user=root key='{{ lookup('file', '/root/.ssh/id_rsa.pub') }}' path=/root/.ssh/authorized_keys manage_dir=no" --ask-pass -i /root/ansible-inventory/my-test-servers.inventory




Ответ: длинный список изменений на каждом узле.







Конечно можно было и вручную всё распространить, у нас узлов 3 штуки, а представьте, если их было бы 10-20 штук:




# ssh-copy-id root@192.168.0.39
# ssh-copy-id root@192.168.0.30
# ssh-copy-id root@192.168.0.31




Ответы:







3.7. Проверка связи с узлами.




Чтобы убедиться, что Ansible может подключаться к узлам и запускать команды и плейбуки, вы можете использовать следующую команду:




# ansible -m ping test_servers -i /root/ansible-inventory/my-test-servers.inventory




Модуль ping проверит, есть ли у вас валидные учетные данные для подключения к нодам, определенным в файле инвентаря, и может ли Ansible запускать сценарии Python на удаленном сервере от имени root пользователя.




Ответ pong означает, что Ansible готов запускать команды и плейбуки на этом узле.




Ответ:







Выполним простую команду 'uptime' для проверки возможности управления узлами:




# ansible -a 'uptime' test_servers -i /root/ansible-inventory/my-test-servers.inventory




Ответ:







3.8. Настройка входа Ansible на самого себя.




Также настроим вход по ключу Ansible Server на самого себя:




# cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys




Проверяем:




# cat /root/.ssh/authorized_keys




Ответ:







К началу работы с Ansible учебный комплекс готов!




4. Выполнение учебных задач на узлах.




Внимание! Почти все типовые действия, которые вам потребуются для работы с Ansible, имеются на официальном сайте с технической документацией по этой системе. Не тратьте на поиски в интернете готовых решений, сразу открывайте официальное руководство пользователя Ansible и ищите там.




Ссылка: docs.ansible.com.




4.1. Отключение SELinux и перезагрузка узлов.




Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux. Рамках учебного стенда она нам не нужна.




Ссылка: «CentOS 7: Как временно или навсегда отключить SELinux».




Посмотрим и убедимся, что на всех узлах, стоит SELinux:




# ansible -m shell -a 'rpm -qa | grep selinux' test_servers -i /root/ansible-inventory/my-test-servers.inventory




Ответ:







Как видно SELinux присутствует в установленном состоянии на всех узлах. Выполним дезактивацию SELinux с помощью Ansible, без удаления SELinux с узлов.




Воспользуемся готовым решением selinux от создателей Ansible по дезактивации SELinux на узлах.




Ссылка: docs.ansible.com.




Раздел: «selinux — Change policy and state of SELinux».




Создадим плейбук для дезактивации SELinux на узлах с помощью Ansible Server:




# mcedit /root/ansible-playbooks/01-pb-selinux-disable.yml




Записываем в него содержимое:




---
- name: Операции с SELinux
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Отключаем SELinux
    selinux:
      state: disabled




Проверим синтаксис плейбука 01-pb-selinux-disable.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Примечание! Я заранее проверил состояние SELinux на узлах. Он активен и работает.




# sestatus




Ответ:







Применим плейбук на узлы и посмотрим что будет с SELinux:




# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml -i /root/ansible-inventory/my-test-servers.inventory




Ответ:







Чтобы завершить дезактивацию SELinux, требуется перезагрузить узлы. Перезагрузка узла с помощью Ansible не сложная задача.




Предполагаются следующие шаги:




  • SSH подключение на узел.
  • Перезагрузите узел.
  • Отключитесь, прежде чем узел закроет ваше ssh-соединение.
  • Подождите некоторое количество секунд, чтобы убедиться, что узел действительно выключен.
  • Попробуйте подключиться по ssh к узлу и выполнить команду.
  • Повторите попытку ssh, пока она не сработает.




В Ansible версии 2.7 или выше. 2.7 ввели модуль перезагрузки – reboot.




Ссылка: docs.ansible.com.
Раздел: «ansible.builtin.reboot».




Теперь все, что вам нужно сделать, это добавить это в свой плейбук:




---
- name: Перезагрузка серверов
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Перезагрузка хостов и ожидание их перезагрузки
    reboot:
      msg: "Reboot initiated by Ansible"
      connect_timeout: 5
      reboot_timeout: 600
      pre_reboot_delay: 0
      post_reboot_delay: 30
      test_command: whoami




Этот плейбук выполнит следующее:




  • Перезагрузит узел.
  • Подождет 30 секунд.
  • Попытается подключиться через SSH и запустить whoami.
  • Отключится через 5 секунд, если не сработает ssh.
  • Будет продолжать пытаться подключиться в течение 10 минут (600 секунд).




Применим плейбук:




# ansible-playbook /root/ansible-playbooks/02-pb-reboot.yml -i /root/ansible-inventory/my-test-servers.inventory




Ответ:







Примечание! После перезагрузки узлов я проверил состояние SELinux на узлах:




# sestatus




Ответ:







Как видно SELinux отключен на всех узлах дистанционно с помощью Ansible.




Примечание! В любой команде Ansible, которая требует перезагрузки после изменения узел будет перезагружен, когда playbook завершится, а затем Ansible будет ждать, пока узел не станет доступным, и ssh будет работать, прежде чем перейти к следующему плейбуку.




Добавьте директиву:




notify: Reboot host and wait for it to restart




Ссылка: docs.ansible.com.




Раздел: «Execute Ansible ‘actions’».




Примечание! Если вам нужно перезагрузиться на полпути через playbook вы можете заставить все задачи выполниться с помощью команды:




- name: Reboot if necessary
  meta: flush_handlers




Иногда это можно сделать, чтобы что-то изменить, заставить сервер перезагрузиться, а затем проверить, что изменения вступили в силу и все в том же playbook.




4.2. Обновление операционных систем на узлах.




Перед выполнением других учебных задач, обновим операционные системы на узловых серверах с помощью Ansible.




Воспользуемся готовым решением ansible.builtin.yum от создателей Ansible по обновлению программного обеспечения на узлах.




Ссылка: docs.ansible.com.
Раздел: «Manages packages with the yum package manager».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/03-pb-upgrade-all-packages.yml




Записываем в него содержимое:




---
- name: Обновление всех пакетов на узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Обновить все пакеты
    yum:
      name: '*'
      state: latest




Проверим синтаксис плейбука 03-pb-upgrade-all-packages.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/03-pb-upgrade-all-packages.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Применим плейбук на узлы и посмотрим что будет происходить на узлах в связи с обновлением программного обеспечения:




# ansible-playbook /root/ansible-playbooks/03-pb-upgrade-all-packages.yml -i /root/ansible-inventory/my-test-servers.inventory




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







После некоторого всплеска активности CPU на узлах Ansible всё завершилось.




Ответ:







Все пакеты на узлах успешно обновлены до последнего актуального состояния из доступных узлам репозиториев.




4.3. Установка группы полезных программ.




Про учебному сценарию требуется установить пакет программного обеспечения, который состоит из традиционного набора программ для многих серверов: mcwgettar.




Снова воспользуемся готовым решением ansible.builtin.yum от создателей Ansible по установке программного обеспечения mcwgettar на узлах.




Ссылка: docs.ansible.com.
Раздел: «Manages packages with the yum package manager».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/04-pb-progs-install.yml




Записываем в него содержимое:




---
- name: Установка полезных программ на всех узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Установить группу программ
    yum:
      name: "{{ package }}"
    vars:
      package:
      - mc
      - wget
      - tar
      state: latest




Проверим синтаксис плейбука 04-pb-progs-install.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/04-pb-progs-install.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Применим плейбук на узлы и посмотрим как установится группа программного обеспечения:




# ansible-playbook /root/ansible-playbooks/04-pb-progs-install.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Все пакеты на узлах успешно установлены программы mcwgettar из доступных узлам репозиториев.




4.4. Настройка межсетевого экрана.




Для успешной и безопасной работы любого сервера первым делом требуется настраивать его сетевую безопасность. Настроим разрешение обращаться к узлам по 80 порту и 443 порту.




Воспользуемся готовым решением ansible.posix.firewalld от создателей Ansible по настройке межсетевого экрана firewalld на узлах.




Ссылка: docs.ansible.com.
Раздел: «ansible.posix.firewalld – Manage arbitrary ports/services with firewalld».




Отдельно установим модуль ansible.posix.firewalld на Ansible сервер:




# ansible-galaxy collection install ansible.posix




Ответ:







Ansible поменяет настройки в файлах конфигурации firewalld. Для того, чтобы новые настройки были задействованы, требуется перезапустить firewalld на узлах.




В этом перезапуске службы межсетевого экрана нам поможет модуль ansible.builtin.service от создателей Ansible.




Ссылка: docs.ansible.com.
Раздел: «ansible.builtin.service – Manage services».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/05-pb-http-https.yml




Записываем в него содержимое:




--
- name: Разрешение 80 и 443 порта - firewalld
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Разрешим 80 порт
    ansible.posix.firewalld:
      service: http
      permanent: yes
      state: enabled
  - name: Разрешим 443 порт
    ansible.posix.firewalld:
      service: https
      permanent: yes
      state: enabled
  - name: Перезапустим service firewalld на всех узлах
    ansible.builtin.service:
      name: firewalld
      state: restarted




Проверим синтаксис плейбука 05-pb-http-https.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/05-pb-http-https.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Примечание! Перед запуском плейбука проверим состояние межсетевого экрана на любом из узле.




# firewall-cmd --list-all




Ответ:







Как видно — порты 80 и 443 закрыты, то есть отсутствуют с списке разрешенных.




Применим плейбук на узлы разрешим узлам соединения по 80 и 443 порту:




# ansible-playbook /root/ansible-playbooks/05-pb-http-https.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Примечание! Проверим состояние межсетевого экрана на любом из узле.




# firewall-cmd --list-all




Ответ:







Как видно — порты 80 и 443 открыты, то есть отсутствуют с списке разрешенных.




Все узлы успешно получили разрешение на использование 80 и 443 порта.




Чтобы открыть какой-либо конкретный порт, сделайте по аналогии:




---
- name: Разрешение в firewalld порта 10051 для zabbix-agent на узлах
  hosts:
    cos7client1
    cos7client2
    cos7client3
    cos7gla
  become_method: sudo
  become_user: root

  tasks:
  - name: Открыть порт 10051 по UDP
    firewalld:
      port: 10051/udp
      permanent: yes
      state: enabled

  - name: Открыть порт 10051 по TCP
    firewalld:
      port: 10051/tcp
      permanent: yes
      state: enabled

  - name: Перезапустим firewalld на всех узлах
    ansible.builtin.service:
      name: firewalld
      state: restarted




4.5. Установка web-сервера Nginx и тестирование отдачи тестовой страницы.




Для тестовых узлов я выбрал Nginx в качестве учебного web-сервера. Его и установим.




Снова воспользуемся готовым решением ansible.builtin.yum от создателей Ansible по установке web-сервера Nginx на узлах.




Ссылка: docs.ansible.com.
Раздел: «Manages packages with the yum package manager».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/06-pb-nginx-install.yml




Записываем в него содержимое:




---
- name: Установка web-сервера Nginx на всех узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Создаем файл nginx.repo оригинального репозитория Nginx на узлах
    copy:
      content: "[nginx-mainline]nname=nginx mainline reponbaseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/ngpgcheck=1nenabled=1ngpgkey=https://nginx.org/keys/nginx_signing.keynmodule_hotfixes=true"
      dest: "/etc/yum.repos.d/nginx.repo"
      backup: yes
      owner: root
      group: root
      mode: 0644
  - name: Установим Nginx на узлы
    yum:
      name: nginx
      state: latest
  - name: Запустим Nginx на узлах
    ansible.builtin.service:
      name: nginx
      state: started




Проверим синтаксис плейбука 06-pb-nginx-install.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/06-pb-nginx-install.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Применим плейбук на узлы и посмотрим как установится web-сервера Nginx на узлах:




# ansible-playbook /root/ansible-playbooks/06-pb-nginx-install.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Проверим доступность демонстрационной страницы HTML web-сервера на узлах Ansible.




Наберем в браузере адрес какого-нибудь узла:




# http://192.168.0.30




Ответ на всех узлах будет одинаковый:







Web-сервер Nginx развернут. Можете использовать его в своих целях.




Что еще интересного можно сделать:




  • поменять на готовую страничку приветствия, через проброс файла;
  • написать свою страничку на HTML5 и подбросить её в виде текстовой строки через плейбук;
  • восстановить копию баз данных, подкинуть файлы хостинга и конфигурации Nginx;
  • и так далее.




Если вам не нравится данная стандартная скучная картинка, то ее всегда можно разнообразить красивой заглушкой на HTML5.




Вот описание замысла: инструкция «Nginx: Модификация базовой страницы приветствия. Заглушка на HTML5». Реализуем это.




По умолчанию index.html — заставка Nginx, хранится в каталоге /usr/share/nginx/html на узлах, значит, если её принудительно заменить на что-то другое, то Nginx это будет добросовестно показывать.




В копировании содержимого Ansible каталога в другой каталог узлов, поможет модуль ansible.builtin.copy.




Ссылка: docs.ansible.com.
Раздел: «Copy files to remote locations».




Создадим каталог /root/ansible-files/nginx/ntml5/zastavka для хранения содержимого заглушки на HTML5.




# mkdir -p /root/ansible-files/nginx/html5/zastavka




Заранее скачайте заставку на HTML5 и распакуйте её в каталог /root/ansible-files/nginx/ntml5/zastavka. Будем копировать содержимое этого каталога на узлы Ansible.




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/07-pb-nginx-html5.yml




Записываем в него содержимое:




--
- name: Копирование каталогов Ansible в каталог узлов
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
# Копируйте дважды, так как иногда файлы пропускаются (в основном только один файл пропускается из папки, если папка не существует).
  - name: Копирование из каталога в каталог
    copy:
      src: "/root/ansible-files/nginx/html5/zastavka/"
      dest: "/usr/share/nginx/html/"
      owner: root
      group: root
      mode: 0644
      backup: yes
    ignore_errors: true




Примечание: Если вы передаете несколько путей с помощью переменной, тогда:




src: "/ корень / {{элемент}}"




Примечание: Если вы передаете путь, используя переменную для разных элементов, тогда:




src: "/ root / {{item.source_path}}"




Проверим синтаксис плейбука 07-pb-nginx-html5.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/07-pb-nginx-html5.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Применим плейбук на узлы и посмотрим как измениться страница приветствия web-сервера Nginx на узлах:




# ansible-playbook /root/ansible-playbooks/07-pb-nginx-html5.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Проверим доступность новой демонстрационной страницы HTML web-сервера на узлах Ansible.




Наберем в браузере адрес какого-нибудь узла:




# http://192.168.0.39




Ответ на всех узлах одинаковый:







Web-сервер получил новую заглушку HTML5 и Nginx поменял страничку приветствия, которая была по умолчанию.




4.6. Добавить пользователей с sudo.




Для обслуживания тестовых серверов создадим пару учетных записей для самых трудолюбивых сотрудников, которые будут работать не покладая лапок. Учетный записи для пользователей: Мурзик и Барсик.




Создадим на самом сервере Ansible двух пользователей: myrzik и barsik. Генерируем для них ключи. Можно и готовые ключи использовать для установки на узлах, но у меня их нет. Барсик с Мурзиком не прислали ключи.




Создание:




# adduser myrzik
# adduser barsik




Установка паролей, чтобы они могли заходить на сервер Ansible:




# passwd myrzik
# passwd barsik




Генерируем для них ключи:




# su myrzik
# ssh-keygen




На все вопросы для myrzik просто жмём Enter.




# su barsik
# ssh-keygen




На все вопросы для barsik просто жмём Enter.




Теперь у нас на сервере Ansible появилось две учетные записи для наших пушистых коллег.




Добавим на узлы с помощью Ansible учетные записи пользователей myrzik и barsik вход по ключам, а так же режим sudo без пароля для них.




В работе Ansible с учетными записями пользователей поможет модуль ansible.builtin.user.




Ссылка: docs.ansible.com.
Раздел: «Manage user accounts».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/08-pb-sudo-users.yml




Записываем в него содержимое:




--
- name: Дистанционно добавление произвольных учетных записей с Ansible на узлы
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Убедимся, что у нас на узлах есть группа "wheel"
    group:
      name: wheel
      state: present

  - name: Разрешим пользователям группы "wheel" иметь sudo без пароля
    lineinfile:
      dest: /etc/sudoers
      state: present
      regexp: '^%wheel'
      line: '%wheel ALL=(ALL) NOPASSWD: ALL'
      validate: visudo -cf %s

  - name: Создадим пользователя myrzik и поместим его в группу "wheel"
    ansible.builtin.user:
      name: myrzik
      comment: Cat Myrzik
      group: wheel

  - name: Пробросим публичный ключ пользователя myrzik с Ansible
    authorized_key:
      user: myrzik
      state: present
      key: "{{ lookup('file', '/home/myrzik/.ssh/id_rsa.pub') }}"
      path: /home/myrzik/.ssh/authorized_keys

  - name: Создадим пользователя barsik и поместим его в группу "wheel"
    ansible.builtin.user:
      name: barsik
      comment: Cat Barsik
      group: wheel

  - name: Пробросим публичный ключ пользователя barsik с Ansible
    authorized_key:
      user: barsik
      state: present
      key: "{{ lookup('file', '/home/barsik/.ssh/id_rsa.pub') }}"
      path: /home/barsik/.ssh/authorized_keys




Проверим синтаксис плейбука 08-pb-sudo-users.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/08-pb-sudo-users.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Применим плейбук на узлы и посмотрим что будет с обновление программного обеспечения:




# ansible-playbook /root/ansible-playbooks/08-pb-sudo-users.yml -i /root/ansible-inventory/my-test-servers.inventory




Ответ:







На все узлы были добавлены учетные записи myrzik и barsik с входом по ключу и sudo возможностями.




Прогуляемся самостоятельно учетной записью myrzik по узлам, потому что у него лапки, и проверим доступ к sudo.




# su myrzik

# ssh myrzik@192.168.0.39

# sudo su




Мы стали root.




Вернёмся обратно на Ansible сервер:




# exit

# exit

# exit




Ответы:







Для учетной записи barsik аналогично, у него тоже лапки:







Всё работает исправно!




4.7. Удаление учетных записей пользователей.




Так как пользователи Мурзик и Барсик, начали хулиганить на узлах и ронять сервера своими лапками, срочно удалим их учетные записи со всех узлов!




Для удаления учетных записей воспользуемся готовым решением ansible.builtin.user от создателей Ansible.




Ссылка: docs.ansible.com.
Раздел: «Manage user accounts».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/09-pb-users-del.yml




Записываем в него содержимое:




---
- name: Дистанционно удалим произвольные учетные записи на всех узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Удалим учетную запись myrzik на узлах
    ansible.builtin.user:
      name: myrzik
      state: absent
      remove: yes

  - name: Удалим учетную запись barsik на узлах
    ansible.builtin.user:
      name: barsik
      state: absent
      remove: yes




Проверим синтаксис плейбука 09-pb-users-del.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/09-pb-users-del.yml --syntax-check




Ответ:







Проверка синтаксиса пройдена.




Применим плейбук на узлы и посмотрим как удалятся учетные записи:




# ansible-playbook /root/ansible-playbooks/09-pb-users-del.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Указанные в плейбуке учетные на узлах Ansible удалены.




4.8. Запуск консольных команд.




Иногда на узлах требуется запускать простые банальные консольные команды.




Воспользуемся модулем ansible.builtin.shell от создателей Ansible.




Ссылка: docs.ansible.com.
Раздел: «Execute shell commands on targets».




Создаем файл плейбука:




# mcedit /root/ansible-playbooks/10-pb-shell.yml




Записываем в него содержимое:




---
- name: Запустим с помощью Ansible команду для командной строки на узлах
  hosts: test_servers
  become_method: sudo
  become_user: root

  tasks:
  - name: Запустим дистанционно запись генерированной строки в файл
    ansible.builtin.shell: openssl rand -base64 32 >> somefile.txt
    args:
      chdir: /root
      creates: somefile.txt
  - name: Скопируем полученный файл внутри каталога
    ansible.builtin.shell: cp /root/somefile.txt /root/somefile2.txt




Проверим синтаксис плейбука 10-pb-shell.yml специальной утилитой --syntax-check от Ansible:




# ansible-playbook /root/ansible-playbooks/10-pb-shell.yml --syntax-check




Ответ:







Применим плейбук на узлы и посмотрим как удалятся учетные записи:




# ansible-playbook /root/ansible-playbooks/10-pb-shell.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Команда для командной строки на узлах Ansible исполнена.




Есть еще способы запустить консольную команду:




---
- name: Установка zabbix-agent на узлах
  hosts:
    cos7client1
    cos7client2
    cos7client3
  become_method: sudo
  become_user: root

  tasks:
  - name: Установка репозитория docker и установка docker на узлы
    ansible.builtin.shell: "curl -fsSL https://get.docker.com/ | sh"

  - name: Поставим в автозапуск docker на узлах
    ansible.builtin.service:
      name: docker
      enabled: yes

  - name: Запустим docker на узлах
    ansible.builtin.service:
      name: docker
      state: started

  - name: Версия docker на узлах
    ansible.builtin.shell: docker info

  - name: Executing a Command Using Shell Module
    shell: docker info

  - name: Executing a command using command module
    command: docker info




Для того, что бы увидеть что выводит команда в консоль узла, введите ключ -vvv:




# ansible-playbook /ansible/roles/docker-install.yml -i /ansible/hosts/pb-zs-stend.yaml -l cos7client1 -vvv




4.9. Объединение плейбуков в Основную книгу.




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




Например:




---
- import_playbook: A-systemd-networkd.yml
- import_playbook: B-fail2ban-ssh.yml
- import_playbook: C-enable-watchdog.yml




Создадим Основную книгу:




# mcedit /root/ansible-playbooks/my-main-book.yml




Вот такой вот будет Основная книга нашем в учебном варианте:




---
- name: Запустим с помощью Ansible сборник плейбуков - Основная книга
  hosts: test_servers
  become_method: sudo
  become_user: root

- import_playbook: 01-pb-selinux-disable.yml
- import_playbook: 02-pb-reboot.yml
- import_playbook: 03-pb-upgrade-all-packages.yml
- import_playbook: 04-pb-progs-install.yml
- import_playbook: 05-pb-http-https.yml
- import_playbook: 06-pb-nginx-install.yml
- import_playbook: 07-pb-nginx-html5.yml
- import_playbook: 08-pb-sudo-users.yml
- import_playbook: 09-pb-users-del.yml
- import_playbook: 10-pb-shell.yml




Проверка синтаксиса плейбука:




# ansible-playbook /root/ansible-playbooks/my-main-book.yml --syntax-check




Ответ:







Применим Основную книгу на узлы и посмотрим как по экрану поползет длинная вереница событий на узлах:




# ansible-playbook /root/ansible-playbooks/my-main-book.yml -i /root/ansible-inventory/my-test-servers.inventory




Некоторое время ждём.




Ответ:







Все задачи во всех плейбуках успешно выполнены!




5. Прочие операции с плейбуками.




5.1. Проверка синтаксиса плейбука:




# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --syntax-check




Ответ:







5.2. Просмотр задач, которые будут выполнены в плейбуке:




# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --list-tasks




Ответ:







5.3. Просмотр списка узлов, на которых будет выполняться в плейбук:




# ansible-playbook /root/ansible-playbooks/01-pb-selinux-disable.yml --list-hosts




Ответ:







6. Оригиналы источников информации.




  1. kamaok.org.ua «Установка и использование Ansible на Centos7».
  2. oblako.kz «Установка Ansible на Centos 7.3».
  3. tproger.ru «Что такое Ansible и как его использовать».
  4. habr.com «Пособие по Ansible».
  5. stackru.com «Можно ли записать эти команды в Ansible Playbook?»
  6. habr.com «Заметка по ansible. Server reboot.»
  7. itisgood.ru «Перезагрузка хоста с помощью Ansible».
  8. codeby.net «Как создать новый файл config в Ansible playbook».
  9. qastack.ru «Скопируйте несколько файлов с помощью Ansible».
  10. qastack.ru «Как создать каталог с помощью Ansible».
  11. docs.ansible.com «selinux — Change policy and state of SELinux».
  12. docs.ansible.com «ansible.builtin.meta – Execute Ansible ‘actions’».
  13. docs.ansible.com «ansible.builtin.yum — Manages packages with the yum package manager».
  14. docs.ansible.com «ansible.posix.firewalld – Manage arbitrary ports/services with firewalld».
  15. docs.ansible.com «ansible.builtin.service — Manage services».
  16. docs.ansible.com «ansible.builtin.copy — Copy files to remote locations».
  17. docs.ansible.com «ansible.builtin.user — Manage user accounts».
  18. docs.ansible.com «ansible.builtin.shell – Execute shell commands on targets».
  19. docs.ansible.com «ansible.builtin.reboot – Reboot a machine».
  20. sprosi.pro «Как запустить несколько playbooks в соответствии с Ansible?»
  21. Источник: https://hamsterden.ru/practical-examples-of-playbooks/






2021-09-01T12:43:18
Software