В этом задании мы сконфигурируем основу будущего кластера с беспарольным доступом по ssh c управляющей машины.
В этом задании мы сконфигурируем основу будущего кластера с беспарольным доступом по ssh c управляющей машины. В качестве управляющей машины используйте машину подключенную к `vmbrX`, например `gwX`. Создайте 3 виртуальных машины: `studX-ubuntu-n1`, `studX-ubuntu-n2`, `studX-ubuntu-n3` из шаблонов: `ubuntu-n1`, `ubuntu-n2`, `ubuntu-n3` соответственно со свеже установленной ОС Ubuntu 18.04 в режиме `Linked Clone`. Укажите свой ресурсный пул при создании. Подключите их в `vmbrX`.
Создайте виртуальную машину `studX-node` из шаблона `ubuntu-template`со свеже установленной ОС Ubuntu 18.04 в режиме `Linked Clone`. Укажите свой ресурсный пул при создании.
Настройте сеть. В этой машине наиболее простым способом будет модификация конфигурационного файла `/etc/netplan/01-netcfg.yaml`. Используйте ip адрес из сети `192.168.1.0/24`, шлюз `192.168.1.1`, любой общедоступный DNS. В настройках оборудования виртуальной машины подключите сетевое устройство к `vmbr15+X`.
В нашем случае у управляющего узла будет два сетевых интерфейса, подключенных к `vmbr499` и `vmbr15+X`. Используйте один шлюз по умолчанию в управляющем узле. У управляемых узлов `studX-node[1-3]` один, подключенный к `vmbr15+X`.
Добавьте в `/etc/hosts` имена узлов в соответствии со схемой ниже на `studX` и `studX-node`.
Сгенерируйте в управляющей машине `studX` ssh ключи без кодовой фразы (passphrase) для пользователя `stud` по алгоритму ed25519. Если нужно в машине `studX-node` отредактируйте конфигурацию `/etc/ssh/sshd_config`, разрешите доступ к машине по паролю и перезагрузите sshd `systemctl restart sshd`. Добавьте публичный ключ в `authorized_keys` машины `studX-node`с помощью `ssh-copy-id`.
Добавьте в `/etc/hosts` управляющей машины имена узлов, например так:
```
192.168.0.111 n1
192.168.0.112 n2
192.168.0.113 n3
```
Превратите виртуальную машину в шаблон для узлов кластера.
Сгенерируйте в управляющей машине `gwX` ssh ключи без кодовой фразы (passphrase) для пользователя `stud` по алгоритму ed25519. Настройте беспарольный доступ для пользователя `stud` на машины: `n1`, `n2`, `n3`. Пользователь `stud` должен иметь возможность перейти в суперпользователя с помощью `sudo` на управляемых машинах.
Создайте 3 машины `studX-node[1-3]` из шаблона `studX-node`. Настройте сеть, установив уникальные IP. Поменяйте имена хостов командой `hostnamectl set-hostname`. В итоге схема должна выглядеть следующим образом.
| node 1 | | node 2 | | node 3 | Узлы под управлением Ansible
|__________| |__________| |__________|
```
Проверьте, что доступ с`studX` по ключу работает.
Проверьте, что доступ с`gwX` по ключу работает.
```
stud@studX # ssh node1
stud@studX # ssh node2
stud@studX # ssh node3
gatekeeper@gwX # ssh stud@n1
gatekeeper@gwX # ssh stud@n2
gatekeeper@gwX # ssh stud@n3
```
## 1. Установка Ansible, введение в команды
Далее все команды выполняются в консоли управляющего узла `studX`.
Далее все команды выполняются в консоли управляющего узла `gwX`.
Установите Ansible.
```
@ -60,11 +57,11 @@ ansible [core 2.13.4]
Требованием для работы Ansible являются: возможность подключения к удалённому узлу по ssh и наличие установленного Python интерпретатора на каждом узле.
Управление кластером с помощью Ansible может осуществляться в двух режимах ad-hoc интерактивном режиме и в режиме выполнения проекта конфигурации playbook. В первом случае все команды начинаются с вызова ansible. Документация команды `man ansible`.
Управление кластером с помощью Ansible может осуществляться в двух режимах ad-hoc интерактивном режиме и в режиме выполнения проекта конфигурации playbook. В первом случае все команды начинаются с вызова `ansible`. Документация команды `man ansible`.
### 1.1. Инвентарь
Прежде чем выполнять команды, создадим кластер в терминах Ansible. В Ansible инструменте существует понятие инвентаря (Inventory), файла, который содержит список сгруппированных имён или ip адресов.
Прежде чем выполнять команды, создадим кластер в терминах Ansible. В Ansible инструменте существует понятие инвентаря (*Inventory*), файла, который содержит список сгруппированных имён или ip адресов под управлением Ansible.
Создайте файл `/etc/ansible/hosts`. Отредактируйте его так, чтобы он содержал только группу `cluster` и имена машин, входящих в кластер. В квадратных скобках указывается имя группы, ниже следуют имена машин. Вы можете использовать шаблоны для перечисления номеров (также используют квадратные скобки), которые раскрываются следующим образом:
```
@ -72,18 +69,22 @@ ansible [core 2.13.4]
abc[1:3] раскрывается в abc1 abc2 abc3
A[1:3]B раскрывается в A1B A2B A3B
```
Наш кластер `cluster` в `/etc/ansible/hosts` может выглядеть так
Вы также можете указать имя пользователя под именем которого `ansible` подключается по `ssh` в блоке `[cluster:vars]`. Наш кластер `cluster` в `/etc/ansible/hosts` в итоге может выглядеть так:
```
# cat /etc/ansible/hosts
[cluster]
node[1:3]
n[1:3]
[cluster:vars]
ansible_user=stud
```
**Примечание.** Обратите внимание что в скобках используется двоеточие, а не знак тире.
Таким образом кластер `cluster` в терминах Ansible - это группа имён машин `node1`, `node2`, `node3`.
### 1.2 Модули
Далее на управляющем узле запускайте команды от обычного пользователя - `stud` или `gatekeeper`.
Добавленный в конце ключ `-f` позволяет ограничить количество одновременно изменяемых узлов. Его также применяют для обновления компонентов распределённого приложения по частям, для избегания остановки всей системы.
#### 1.2.2 shell
#### 1.2.2 command
Для ad-hoc режима естественнее всего подходят модули `command` (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html) и `shell` (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html). Командный модуль выполняет команды на целевой машине без использования оболочки. Это модуль используется по-умолчанию. После ключа `-a` передаётся строка с командой.
```
$ ansible cluster -a 'echo Hello, world worker $USER'
$ ansible cluster -a "echo Hello, world admin $USER"
```
Для ad-hoc режима естественнее всего подходит модуль `shell` (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html). Данный модуль позволяет выполнить любую консольную команду на нескольких узлах. Приведём ряд примеров, чтобы вы попробовали их далее на всём кластере:
#### 1.2.3 shell
Модуль `shell` позволяет выполнить любую консольную команду на нескольких узлах в оболочке. Вы можете использовать возможности оболочки, например вызов других команд и подстановку результатов.
```
$ ansible cluster -m shell -a 'echo Hello, world $(hostname) user $USER'
$ ansible cluster -m shell -a "echo Hello, world $(hostname) user $USER"
```
Попробуйте ряд примеров на всём кластере `cluster`:
```bash
# узнать время на текущей машине, нам необходимо вызвать:
date
# Верное ли время на узлах?
# узнать имена файлов в директории `~/.ssh/`:
ls -la ~/.ssh/
# узнать информацию о процессорах:
lscpu
# узнать количество свободного места на дисках:
df -h
# узнать версию операционной системы (для CentOS, Red Hat, Fedora) и ядра линукс
cat /etc/os-release
lsb_release -a
uname -a
# проверить, что нужный пакет находится в списке установленных
apt list installed python3
```
Выполнение консольных команд на узлах кластера с помощью модуля `shell` выглядит следующим образом:
```
# ansible cluster -m shell -a "date"
```
Верное ли время на узлах?
После ключа `-a` в `ansible` передаётся строка с командой. Попробуйте выполнить несколько вышеупомянутых команд аналогичным образом.
#### 1.2.3 setup
#### 1.2.4 setup
В задачах конфигурации кластера как правило требуется не только узнавать информацию о различных свойствах, конфигурациях систем, но и использовать данную информацию в качестве параметров в других командах.
Для сбора информации о состоянии (Facts) узлов используется модуль `setup`. Выполните команду для одного узла и просмотрите результат. Среди этих данных есть результаты, полученные нами ранее.
Для сбора информации о состоянии (*Facts*) узлов используется модуль `setup`. Выполните команду для одного узла и просмотрите результат. Среди этих данных есть результаты, полученные нами ранее.
```
$ ansible node1 -m setup
```
Результатом является иерархическая структура в JSON формате. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html. Для обращения к значениям (листьям JSON структуры) указывается путь из названий, разделённых точками. Например:`ansible_eth0.ip4.address` или `ansible_date_time.date`.
#### 1.2.4 apt
#### 1.2.5 apt
Для установки ПО нам потребуется модуль `apt`.
Проверьте установлена ли python3. Например так:
```
$ ansible cluster -m shell -a "apt list installed python3"
$ ansible cluster -a "apt list installed python3"
```
Целью использования Ansible является перевод распределённой системы из одного состояния в другое. По этой причине в параметрах многих модулей можно встретить параметр `state`. Данных параметр для модуля apt допускает значения: `present` - присутствует, `absent` - отсутствует, `latest` - последняя версия. Кроме него нам потребуется параметр `name` - имя или шаблон имени по которому нужно искать устанавливаемое ПО. Другие параметры модуля yum доступны на официальном сайте https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html.
Целью использования Ansible является перевод распределённой системы из одного состояния в другое. По этой причине в параметрах многих модулей можно встретить параметр `state`. Данных параметр для модуля `apt` допускает значения:
- `present` - присутствует,
- `absent` - отсутствует,
- `latest` - последняя версия.
Кроме него нам потребуется параметр `name` - имя или шаблон имени по которому нужно искать устанавливаемое ПО. Другие параметры модуля `apt` доступны на официальном сайте https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html.
Попробуем установить htop следующей командой:
Попробуем установить `htop` следующей командой:
```
$ ansible cluster -m apt -a "name=htop state=present"
```
#### 1.2.5 Эскалация прав доступа
#### 1.2.6 Эскалация прав доступа
Для повышения прав доступа используется ключ `--become` или сокращенный вариант `-b`.
Для повышения прав доступа до суперпользователя на управляемых машинах используется ключ `--become` или сокращенный вариант `-b`. Если вы не настроили sudo без запроса пароля на управялемых машинах, вы можете добавить ключ `--ask-become-pass` или сокращенный вариант `-K` для запроса пароля. По умолчанию `--become-user` равен `root`.
```
$ ansible cluster -m apt -a "name=htop state=present" -b
$ ansible cluster -m apt -a "name=htop state=present" --become --ask-become-pass
```
Подробнее об эскалации прав можно прочитать в https://docs.ansible.com/ansible/2.3/become.html.
Таким образом мы переводим кластер из состояния без htop в состояние с htop. Можно убедиться, что при повторном запуске никаких изменений производиться не будет.
Таким образом мы переводим кластер из состояния без `htop` в состояние с`htop`. Можно убедиться, что при повторном запуске никаких изменений производиться не будет.
## 2. Ansible Playbook
Большую часть времени в Ansible вы потратите на написание сценариев управления конфигурацией (Playbook). Playbook — это термин который Ansible использует для названия таких сценариев.
Большую часть времени в Ansible вы потратите на написание сценариев управления конфигурацией (*Playbook*). Playbook — это термин который Ansible использует для названия таких сценариев.
В этом задании установим Greenplum на наш кластер.
### 2.1 Шаблон конфигурации
В первую очередь создайте папку проекта управления конфигурацией `ansible-greenplum`, в которой будет лежать файл со сценарием. Назовите этот файл `main.yml`.
В первую очередь создайте папку проекта управления конфигурацией `ansible-greenplum` (или любым другим именем), в которой будет лежать файл с конфигурацией. Назовите этот файл `main.yml`.
Поместите в него следующие строки и попробуйте запустить с флагом `--verbose`.
```yaml
@ -194,9 +213,9 @@ $ ansible-playbook main.yml -v
### 2.2 Создание пользователя-администратора распределённой базы данных
Преступим у настройке конфигурации для Greenplum.
Преступим у настройке конфигурации для Greenplum. Мы будет тестировать конфигурацию по частям во временных конфигурационных файлах, а затем объединим в `main.yml`.
Создайте файл 1.yml и поместите содержимое из листинга следующего ниже. Отличие от предыдущего примера заключается в добавлении блока с переменными `vars`. Все действия понадобится выполнять с правами `root`, поэтому мы добавляем параметр `become: yes`.
Создайте файл `1.yml` и поместите содержимое из листинга следующего ниже. Отличие от предыдущего примера заключается в добавлении блока с переменными `vars`. Все действия понадобится выполнять с правами `root`, поэтому мы добавляем параметр `become: yes`.
Первая задача - создать пользователя `gpadmin` и установить ему пароль `changeme`с помощью модуля `user` (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html). Перед установкой поменяйте пароль на более сложный.
@ -206,7 +225,7 @@ $ ansible-playbook main.yml -v
vars:
- version: "6.22.1"
- greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme"
- greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
Поместите содержимое файла в 2.yml и запустите. Конфигурация настроит Greenplum репозиторий для apt.
Напишите следующую конфигурацию в файле `2.yml` и запустите. Конфигурация настроит Greenplum репозиторий для `apt`. Обратите внимание что для этих этапов глобально указано повышение прав до `root` в начале файла.
```yaml
---
@ -243,13 +268,18 @@ $ ansible-playbook 1.yml
state: present
```
```
$ ansible-playbook 2.yml
$ ansible-playbook 2.yml -K
```
Перепроверим, что репозиторий с greenplum зарегистрирован:
```
$ ansible cluster -m shell -a 'ls /etc/apt/sources.list.d/'
$ ansible cluster -m shell -a 'cat /etc/apt/sources.list.d/ppa_greenplum*'
```
### 2.4 Установка пакета
Установим пакет Greenplum конфигурацией `3.yml`.
Установим пакет Greenplum конфигурацией `3.yml` и сделаем несколько изменений для его использования.
```yaml
---
@ -257,7 +287,7 @@ $ ansible-playbook 2.yml
vars:
- version: "6.22.1"
- greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme"
- greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes
tasks:
- name: install package
@ -269,6 +299,7 @@ $ ansible-playbook 2.yml
paths: /opt
patterns: 'greenplum*'
file_type: directory
recurse: false
register: installed_dir
- name: change install directory ownership
file:
@ -282,18 +313,43 @@ $ ansible-playbook 2.yml
with_items: "{{ installed_dir.files }}"
```
```
$ ansible-playbook 3.yml
$ ansible-playbook 3.yml -K
```
Согласно этой конфигурации в системе должен стоять пакет `greenplum-db-6`:
```
$ ansible cluster -a 'apt list installed greenplum-db-6'
```
Зарегистрирована временная переменная `installed_dir`, которую можно использовать в остальной части конфигурации. Она содержит выдачу команды `find`:
```
$ ansible cluster -a 'find /opt/ -maxdepth 1 -type d -name greenplum*'
```
Изменён владелец установленных файлов на `gpadmin`:
```
$ ansible cluster -m shell -a 'ls -laht /opt/green*'
```
В`.bashrc` добавлена директория с исполняемыми файлами базы данных `greenplum` в переменную PATH:
```
$ ansible cluster -a 'tail -n1 /home/gpadmin/.bashrc'
```
### 2.5 Настроим параметры ОС для Greenplum
Для оптимальной работы базе данных может потребоваться держать открытыми много файлов и запускать много процессов. Посмотрим на лимиты и увеличим до рекомендованных в конфигурации:
```
$ ansible cluster -a 'prlimit' --become-user gpadmin --become -K
$ ansible cluster -a 'cat /etc/security/limits.conf'
```
Содержимое файла `4.yml`:
```yaml
---
- hosts: cluster
vars:
- version: "6.22.1"
- greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme"
- greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes
tasks:
- name: update pam_limits
@ -306,14 +362,27 @@ $ ansible-playbook 3.yml
nofile: 524288
nproc: 131072
```
Увеличит количество открытых файлов и процессов для пользователя, от имени которого запускается процесс базы данных.
```
$ ansible-playbook 4.yml
```
Проверим изменились ли значения в конфигурационном файле:
```
$ ansible cluster -a 'cat /etc/security/limits.conf'
```
**Примечание.** Значения `prlimit` могут не измениться для интерактивного логина. Это не повлияет на процессы базы данных, которые стартуют не интерактивно. Подробнее объяснение описано здесь https://superuser.com/questions/1200539/cannot-increase-open-file-limit-past-4096-ubuntu/1200818#_=_
### 2.6 Финальная версия
Соберите все предыдущие конфигурации в один файл и запустите ещё раз. Ошибок быть не должно, кластер перешёл в состояние с установленной Greenplum.
Соберите все предыдущие конфигурации в один файл, удалите лишние строки и запустите ещё раз. Ошибок быть не должно, кластер перешёл в состояние с установленной Greenplum.
```
$ rm main.yml && cat *.yml > main.yml
$ # delete unnecessary header lines
```
```yaml
---
@ -321,7 +390,7 @@ $ ansible-playbook 4.yml
vars:
- version: "6.22.1"
- greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme"
- greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes
tasks:
- name: create greenplum admin user
@ -372,9 +441,10 @@ $ ansible-playbook 4.yml
nproc: 131072
```
```
$ ansible-playbook main.yml
$ ansible-playbook main.yml -K
```
Чтобы запустить распределённую базу данных вам потребуется проследовать далее по официальной инструкции https://docs.vmware.com/en/VMware-Greenplum/6/greenplum-database/install_guide-create_data_dirs.html. Запуск базы данных оставляем читателю в качестве упражения.
## Релевантные источники
- Nemeth E. et al. UNIX and Linux system administration handbook. Chapter 23.
