Merge branch 'main' into v2

pull/5/head
Dmitry Ignatiev 12 months ago
commit 52cbf5c5db

@ -1,8 +1,8 @@
# Экзаменационное задание для портфолио 2 # Экзаменационное задание для портфолио 2
Подготовьте демонстрацию работы nginx сервиса в режиме высокой доступности. Согласно схеме, сделайте так, что nginx на studX проксирует: Подготовьте демонстрацию работы nginx сервиса в режиме высокой доступности. Согласно схеме, сделайте так, что nginx на studX проксирует:
- все запросы по адресу `/ha/1/` узлу `gwX` для демонстрации работы сайта в режиме высокой доступности настроенном с помощью модуля `ngx_http_upstream_module`, - все запросы по адресу `https://ha1.studX.myoffice.ru/` узлу `gwX` для демонстрации работы сайта в режиме высокой доступности настроенном с помощью модуля `ngx_http_upstream_module`,
- все запросы по адресу `/ha/2/` узлу `10.160.179.140+X` для демонстрации работы сайта в режиме высокой доступности настроенном с помощью `keepalived`. - все запросы по адресу `https://ha2.studX.myoffice.ru/` узлу `10.160.179.140+X` для демонстрации работы сайта в режиме высокой доступности настроенном с помощью `keepalived`.
``` ```
________ ________
@ -13,10 +13,10 @@
роутер public IP 193.32.63.170+X:[22,80,443] -> private IP 10.160.179.10+X:[22,80,443] роутер public IP 193.32.63.170+X:[22,80,443] -> private IP 10.160.179.10+X:[22,80,443]
| |
_______|_______ _______|_______
| | /ha/2/ | | https://ha2.studX.myoffice.ru/
| studX |---------------------------+-------------------+ | studX |---------------------------+-------------------+
|_______________| | | 10.160.179.140+X/24 в роли virtual IP |_______________| | | 10.160.179.140+X/24 в роли virtual IP
| /ha/1/ | ens18 | ens18 | https://ha1.studX.myoffice.ru/ | ens18 | ens18
| ens18 в vlan499 ___________ ___________ | ens18 в vlan499 ___________ ___________
_______|_______ | | | | _______|_______ | | | |
| | | nginx 3 | | nginx 4 | | | | nginx 3 | | nginx 4 |

@ -1,6 +1,6 @@
# Экзаменационное задание для портфолио 3 # Экзаменационное задание для портфолио 3
Настройте почтовый сервер на основе Postfix и Dovecot для своего домена studX.myoffice.ru (или любой другой). Заведите один или несколько почтовых ящиков для новых пользователей. Пользователь должен иметь возможность: Настройте почтовый сервер на основе Postfix и Dovecot для своего домена studX.myoffice.ru. Заведите один или несколько почтовых ящиков для новых пользователей. Пользователь должен иметь возможность:
- подключиться из мобильного или десктопного почтового клиента к серверу со своим логином и паролем, - подключиться из мобильного или десктопного почтового клиента к серверу со своим логином и паролем,
- отправить почту на внешний адрес gmail.com/yandex.ru/mail.ru, - отправить почту на внешний адрес gmail.com/yandex.ru/mail.ru,
- принять почтовое сообщение с внешнего адреса отправленное как ответ на входное письмо. - принять почтовое сообщение с внешнего адреса отправленное как ответ на входное письмо.

@ -1,6 +1,6 @@
# Экзаменационное задание для портфолио 4 # Экзаменационное задание для портфолио 4
Выполните задания по настройке Proxmox на виртуальных машинах и предоставьте доступ к веб-интерфейсу по адресу `https://studX.myoffice.ru/proxmox/`. Заведите тестового пользователя, который обладает правами на: Выполните задания по настройке Proxmox на виртуальных машинах и предоставьте доступ к веб-интерфейсу по адресу `https://proxmox.studX.myoffice.ru/`. Заведите тестового пользователя, который обладает правами на:
- запуск/выключение созданной для него виртуальной машины, - запуск/выключение созданной для него виртуальной машины,
- может создавать диски, - может создавать диски,
- может изменять конфигурацию оборудования виртуальной машины, - может изменять конфигурацию оборудования виртуальной машины,

@ -0,0 +1,3 @@
# Экзаменационное задание для портфолио 5
Выполните контейнеризацию приложения todo_app и предоставьте доступ к веб-интерфейсу по адресу `https://docker.studX.myoffice.ru/`.

@ -30,7 +30,7 @@ Docker Compose использует YAML в качестве языка конф
### 5. Docker Swarm ### 5. Docker Swarm
Docker Swarm это простой оркестратор для контейнеров, который доступен из коробки. Позволяет объединить докер демоны на разных машинах в кластер, что даёт возможность поставки распределённых приложений упакованных в контейнеры. Swarm позволяет настраивать кластеризованные приложения как с помощью интерфейса командной строки, так и с декларативно, наподобие Docker Compose. Типичными задачами для такого типа приложений являются организация высокой доступности, балансировки нагрузки и канареечного обновления сервиса. Также вы можете добиться эластичности распределённого приложения, которое создаёт и удаляет контейнеры в зависимости от поступающей нагрузки. Docker Swarm это простой оркестратор для контейнеров, который доступен из коробки. Позволяет объединить докер демоны на разных машинах в кластер, что даёт возможность поставки распределённых приложений упакованных в контейнеры. Swarm позволяет настраивать кластеризованные приложения как с помощью интерфейса командной строки, так и декларативно, наподобие Docker Compose. Типичными задачами для такого типа приложений являются организация высокой доступности, балансировки нагрузки и канареечного обновления сервиса. Также вы можете добиться эластичности распределённого приложения, которое создаёт и удаляет контейнеры в зависимости от поступающей нагрузки.
Имейте ввиду, что разделение томов данных в кластере имеет свои особенности, о которых подробно можно почитать по ссылкам ниже, но вот некоторые из них. Имейте ввиду, что разделение томов данных в кластере имеет свои особенности, о которых подробно можно почитать по ссылкам ниже, но вот некоторые из них.

@ -205,7 +205,7 @@
Про SSH туннели подробнее можете почитать здесь: \ Про SSH туннели подробнее можете почитать здесь: \
https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot
### 5. Docker Swarm ## 5. Docker Swarm
1. Инициализируйте Docker в режим Swarm 1. Инициализируйте Docker в режим Swarm

@ -2,46 +2,43 @@
## 0. Настройка кластера ## 0. Настройка кластера
В этом задании мы сконфигурируем основу будущего кластера с беспарольным доступом по 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/hosts` управляющей машины имена узлов, например так:
```
Настройте сеть. В этой машине наиболее простым способом будет модификация конфигурационного файла `/etc/netplan/01-netcfg.yaml`. Используйте ip адрес из сети `192.168.1.0/24`, шлюз `192.168.1.1`, любой общедоступный DNS. В настройках оборудования виртуальной машины подключите сетевое устройство к `vmbr15+X`. 192.168.0.111 n1
192.168.0.112 n2
В нашем случае у управляющего узла будет два сетевых интерфейса, подключенных к `vmbr499` и `vmbr15+X`. Используйте один шлюз по умолчанию в управляющем узле. У управляемых узлов `studX-node[1-3]` один, подключенный к `vmbr15+X`. 192.168.0.113 n3
```
Добавьте в `/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`.
Превратите виртуальную машину в шаблон для узлов кластера. Сгенерируйте в управляющей машине `gwX` ssh ключи без кодовой фразы (passphrase) для пользователя `stud` по алгоритму ed25519. Настройте беспарольный доступ для пользователя `stud` на машины: `n1`, `n2`, `n3`. Пользователь `stud` должен иметь возможность перейти в суперпользователя с помощью `sudo` на управляемых машинах.
Создайте 3 машины `studX-node[1-3]` из шаблона `studX-node`. Настройте сеть, установив уникальные IP. Поменяйте имена хостов командой `hostnamectl set-hostname`. В итоге схема должна выглядеть следующим образом. В итоге схема должна выглядеть следующим образом.
``` ```
_______________ _______________
| | | |
| studX | Управляющий узел с Ansible | gwX | Управляющий узел с Ansible
|_______________| |_______________|
| ens19 в vlan 15+X, IP 192.168.1.100/24 | ens19 в vmbrX, IP 192.168.0.1/24
| |
+---------+---------+-------------------+ +---------+---------+-------------------+
| 192.168.1.101/24 | 192.168.1.102/24 | 192.168.1.103/24 | 192.168.0.111/24 | 192.168.0.112/24 | 192.168.0.113/24
__________ __________ __________ __________ __________ __________
| | | | | | | | | | | |
| node 1 | | node 2 | | node 3 | Узлы под управлением Ansible | node 1 | | node 2 | | node 3 | Узлы под управлением Ansible
|__________| |__________| |__________| |__________| |__________| |__________|
``` ```
Проверьте, что доступ с `studX` по ключу работает. Проверьте, что доступ с `gwX` по ключу работает.
``` ```
stud@studX # ssh node1 gatekeeper@gwX # ssh stud@n1
stud@studX # ssh node2 gatekeeper@gwX # ssh stud@n2
stud@studX # ssh node3 gatekeeper@gwX # ssh stud@n3
``` ```
## 1. Установка Ansible, введение в команды ## 1. Установка Ansible, введение в команды
Далее все команды выполняются в консоли управляющего узла `studX`. Далее все команды выполняются в консоли управляющего узла `gwX`.
Установите Ansible. Установите Ansible.
``` ```
@ -60,11 +57,11 @@ ansible [core 2.13.4]
Требованием для работы Ansible являются: возможность подключения к удалённому узлу по ssh и наличие установленного Python интерпретатора на каждом узле. Требованием для работы Ansible являются: возможность подключения к удалённому узлу по ssh и наличие установленного Python интерпретатора на каждом узле.
Управление кластером с помощью Ansible может осуществляться в двух режимах ad-hoc интерактивном режиме и в режиме выполнения проекта конфигурации playbook. В первом случае все команды начинаются с вызова ansible. Документация команды `man ansible`. Управление кластером с помощью Ansible может осуществляться в двух режимах ad-hoc интерактивном режиме и в режиме выполнения проекта конфигурации playbook. В первом случае все команды начинаются с вызова `ansible`. Документация команды `man ansible`.
### 1.1. Инвентарь ### 1.1. Инвентарь
Прежде чем выполнять команды, создадим кластер в терминах Ansible. В Ansible инструменте существует понятие инвентаря (Inventory), файла, который содержит список сгруппированных имён или ip адресов. Прежде чем выполнять команды, создадим кластер в терминах Ansible. В Ansible инструменте существует понятие инвентаря (*Inventory*), файла, который содержит список сгруппированных имён или ip адресов под управлением Ansible.
Создайте файл `/etc/ansible/hosts`. Отредактируйте его так, чтобы он содержал только группу `cluster` и имена машин, входящих в кластер. В квадратных скобках указывается имя группы, ниже следуют имена машин. Вы можете использовать шаблоны для перечисления номеров (также используют квадратные скобки), которые раскрываются следующим образом: Создайте файл `/etc/ansible/hosts`. Отредактируйте его так, чтобы он содержал только группу `cluster` и имена машин, входящих в кластер. В квадратных скобках указывается имя группы, ниже следуют имена машин. Вы можете использовать шаблоны для перечисления номеров (также используют квадратные скобки), которые раскрываются следующим образом:
``` ```
@ -72,18 +69,22 @@ ansible [core 2.13.4]
abc[1:3] раскрывается в abc1 abc2 abc3 abc[1:3] раскрывается в abc1 abc2 abc3
A[1:3]B раскрывается в A1B A2B A3B A[1:3]B раскрывается в A1B A2B A3B
``` ```
Наш кластер `cluster` в `/etc/ansible/hosts` может выглядеть так
Вы также можете указать имя пользователя под именем которого `ansible` подключается по `ssh` в блоке `[cluster:vars]`. Наш кластер `cluster` в `/etc/ansible/hosts` в итоге может выглядеть так:
``` ```
# cat /etc/ansible/hosts # cat /etc/ansible/hosts
[cluster] [cluster]
node[1:3] n[1:3]
[cluster:vars]
ansible_user=stud
``` ```
**Примечание.** Обратите внимание что в скобках используется двоеточие, а не знак тире. **Примечание.** Обратите внимание что в скобках используется двоеточие, а не знак тире.
Таким образом кластер `cluster` в терминах Ansible - это группа имён машин `node1`, `node2`, `node3`.
### 1.2 Модули ### 1.2 Модули
Далее на управляющем узле запускайте команды от обычного пользователя - `stud` или `gatekeeper`.
#### 1.2.1 ping #### 1.2.1 ping
Запустим нашу первую Ansible команду: Запустим нашу первую Ansible команду:
@ -104,81 +105,99 @@ $ ansible cluster -m ping -f 1
Добавленный в конце ключ `-f` позволяет ограничить количество одновременно изменяемых узлов. Его также применяют для обновления компонентов распределённого приложения по частям, для избегания остановки всей системы. Добавленный в конце ключ `-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 ```bash
# узнать время на текущей машине, нам необходимо вызвать:
date date
# Верное ли время на узлах?
# узнать имена файлов в директории `~/.ssh/`: # узнать имена файлов в директории `~/.ssh/`:
ls -la ~/.ssh/ ls -la ~/.ssh/
# узнать информацию о процессорах: # узнать информацию о процессорах:
lscpu lscpu
# узнать количество свободного места на дисках: # узнать количество свободного места на дисках:
df -h df -h
# узнать версию операционной системы (для CentOS, Red Hat, Fedora) и ядра линукс # узнать версию операционной системы (для CentOS, Red Hat, Fedora) и ядра линукс
cat /etc/os-release cat /etc/os-release
lsb_release -a lsb_release -a
uname -a uname -a
# проверить, что нужный пакет находится в списке установленных # проверить, что нужный пакет находится в списке установленных
apt list installed python3 apt list installed python3
``` ```
Выполнение консольных команд на узлах кластера с помощью модуля `shell` выглядит следующим образом: #### 1.2.4 setup
```
# ansible cluster -m shell -a "date"
```
Верное ли время на узлах?
После ключа `-a` в `ansible` передаётся строка с командой. Попробуйте выполнить несколько вышеупомянутых команд аналогичным образом.
#### 1.2.3 setup
В задачах конфигурации кластера как правило требуется не только узнавать информацию о различных свойствах, конфигурациях систем, но и использовать данную информацию в качестве параметров в других командах. В задачах конфигурации кластера как правило требуется не только узнавать информацию о различных свойствах, конфигурациях систем, но и использовать данную информацию в качестве параметров в других командах.
Для сбора информации о состоянии (Facts) узлов используется модуль `setup`. Выполните команду для одного узла и просмотрите результат. Среди этих данных есть результаты, полученные нами ранее. Для сбора информации о состоянии (*Facts*) узлов используется модуль `setup`. Выполните команду для одного узла и просмотрите результат. Среди этих данных есть результаты, полученные нами ранее.
``` ```
$ ansible node1 -m 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`. Результатом является иерархическая структура в 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`. Для установки ПО нам потребуется модуль `apt`.
Проверьте установлена ли python3. Например так: Проверьте установлена ли 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" $ 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. Подробнее об эскалации прав можно прочитать в https://docs.ansible.com/ansible/2.3/become.html.
Таким образом мы переводим кластер из состояния без htop в состояние с htop. Можно убедиться, что при повторном запуске никаких изменений производиться не будет. Таким образом мы переводим кластер из состояния без `htop` в состояние с `htop`. Можно убедиться, что при повторном запуске никаких изменений производиться не будет.
## 2. Ansible Playbook ## 2. Ansible Playbook
Большую часть времени в Ansible вы потратите на написание сценариев управления конфигурацией (Playbook). Playbook — это термин который Ansible использует для названия таких сценариев. Большую часть времени в Ansible вы потратите на написание сценариев управления конфигурацией (*Playbook*). Playbook — это термин который Ansible использует для названия таких сценариев.
В этом задании установим Greenplum на наш кластер. В этом задании установим Greenplum на наш кластер.
### 2.1 Шаблон конфигурации ### 2.1 Шаблон конфигурации
В первую очередь создайте папку проекта управления конфигурацией `ansible-greenplum`, в которой будет лежать файл со сценарием. Назовите этот файл `main.yml`. В первую очередь создайте папку проекта управления конфигурацией `ansible-greenplum` (или любым другим именем), в которой будет лежать файл с конфигурацией. Назовите этот файл `main.yml`.
Поместите в него следующие строки и попробуйте запустить с флагом `--verbose`. Поместите в него следующие строки и попробуйте запустить с флагом `--verbose`.
```yaml ```yaml
@ -194,9 +213,9 @@ $ ansible-playbook main.yml -v
### 2.2 Создание пользователя-администратора распределённой базы данных ### 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). Перед установкой поменяйте пароль на более сложный. Первая задача - создать пользователя `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: vars:
- version: "6.22.1" - version: "6.22.1"
- greenplum_admin_user: "gpadmin" - greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme" - greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes become: yes
tasks: tasks:
- name: create greenplum admin user - name: create greenplum admin user
@ -219,10 +238,16 @@ $ ansible-playbook main.yml -v
$ ansible-playbook 1.yml $ ansible-playbook 1.yml
``` ```
Можно убедиться, что пользователь создан отдельными командами оболочки:
```
$ ansible cluster -m shell -a 'cat /etc/passwd | grep gpadmin'
$ ansible cluster -m shell -a 'cat /etc/shadow | grep gpadmin' -bK
$ ansible cluster -m shell -a 'ls -laht /home/ | grep gpadmin'
```
### 2.3 Настройка репозитория на целевых узлах ### 2.3 Настройка репозитория на целевых узлах
Поместите содержимое файла в 2.yml и запустите. Конфигурация настроит Greenplum репозиторий для apt. Напишите следующую конфигурацию в файле `2.yml` и запустите. Конфигурация настроит Greenplum репозиторий для `apt`. Обратите внимание что для этих этапов глобально указано повышение прав до `root` в начале файла.
```yaml ```yaml
--- ---
@ -243,13 +268,18 @@ $ ansible-playbook 1.yml
state: present 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 Установка пакета ### 2.4 Установка пакета
Установим пакет Greenplum конфигурацией `3.yml`. Установим пакет Greenplum конфигурацией `3.yml` и сделаем несколько изменений для его использования.
```yaml ```yaml
--- ---
@ -257,7 +287,7 @@ $ ansible-playbook 2.yml
vars: vars:
- version: "6.22.1" - version: "6.22.1"
- greenplum_admin_user: "gpadmin" - greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme" - greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes become: yes
tasks: tasks:
- name: install package - name: install package
@ -269,6 +299,7 @@ $ ansible-playbook 2.yml
paths: /opt paths: /opt
patterns: 'greenplum*' patterns: 'greenplum*'
file_type: directory file_type: directory
recurse: false
register: installed_dir register: installed_dir
- name: change install directory ownership - name: change install directory ownership
file: file:
@ -282,18 +313,43 @@ $ ansible-playbook 2.yml
with_items: "{{ installed_dir.files }}" 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 ### 2.5 Настроим параметры ОС для Greenplum
Для оптимальной работы базе данных может потребоваться держать открытыми много файлов и запускать много процессов. Посмотрим на лимиты и увеличим до рекомендованных в конфигурации:
```
$ ansible cluster -a 'prlimit' --become-user gpadmin --become -K
$ ansible cluster -a 'cat /etc/security/limits.conf'
```
Содержимое файла `4.yml`:
```yaml ```yaml
--- ---
- hosts: cluster - hosts: cluster
vars: vars:
- version: "6.22.1" - version: "6.22.1"
- greenplum_admin_user: "gpadmin" - greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme" - greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes become: yes
tasks: tasks:
- name: update pam_limits - name: update pam_limits
@ -306,14 +362,27 @@ $ ansible-playbook 3.yml
nofile: 524288 nofile: 524288
nproc: 131072 nproc: 131072
``` ```
Увеличит количество открытых файлов и процессов для пользователя, от имени которого запускается процесс базы данных.
``` ```
$ ansible-playbook 4.yml $ 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 Финальная версия ### 2.6 Финальная версия
Соберите все предыдущие конфигурации в один файл и запустите ещё раз. Ошибок быть не должно, кластер перешёл в состояние с установленной Greenplum. Соберите все предыдущие конфигурации в один файл, удалите лишние строки и запустите ещё раз. Ошибок быть не должно, кластер перешёл в состояние с установленной Greenplum.
```
$ rm main.yml && cat *.yml > main.yml
$ # delete unnecessary header lines
```
```yaml ```yaml
--- ---
@ -321,7 +390,7 @@ $ ansible-playbook 4.yml
vars: vars:
- version: "6.22.1" - version: "6.22.1"
- greenplum_admin_user: "gpadmin" - greenplum_admin_user: "gpadmin"
- greenplum_admin_password: "changeme" - greenplum_admin_password: "changeme" # поменяйте на стандартный пароль MyOffice
become: yes become: yes
tasks: tasks:
- name: create greenplum admin user - name: create greenplum admin user
@ -372,9 +441,10 @@ $ ansible-playbook 4.yml
nproc: 131072 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. - Nemeth E. et al. UNIX and Linux system administration handbook. Chapter 23.

@ -1,13 +1,13 @@
# Портфолио # Портфолио
## 1. proxmox ## 1. proxmox
Web интерфейс созданного в задании Proxmox доступен по адресу https://studX.myoffice.ru/proxmox/. Web интерфейс созданного в задании Proxmox доступен по адресу https://proxmox.studX.myoffice.ru/.
## 2. nginx_ha ## 2. nginx_ha
Cайты доступены по адресу https://studX.myoffice.ru/ha/1/ и https://studX.myoffice.ru/ha/2/. При остановке активной машины должен обслуживаться резервным сервером. Cайты доступены по адресу https://ha1.studX.myoffice.ru/ и https://ha2.studX.myoffice.ru/. При остановке активной машины сайт должен обслуживаться резервным сервером.
## 3. docker ## 3. docker
Cайт с демонстрацией развёрнутого в docker приложения доступен по адресу https://studX.myoffice.ru/docker/. Cайт с демонстрацией развёрнутого в docker приложения доступен по адресу https://docker.studX.myoffice.ru/.
## 4. postfix + dovecot ## 4. postfix + dovecot
Из почтового клиента можно отправить почту с почтового ящика stud@studX.myoffice.ru и прочитать входящие сообщения. Из почтового клиента можно отправить почту с почтового ящика stud@studX.myoffice.ru и прочитать входящие сообщения.
Loading…
Cancel
Save