Compare commits
1 Commits
zinoveva-a
...
zinoveva-a
| Author | SHA1 | Date | |
|---|---|---|---|
| f7032a55fc |
@@ -1,154 +0,0 @@
|
|||||||
# Отчёт по лабораторной работе №1
|
|
||||||
|
|
||||||
Выполнила: студентка гр. ИСЭбд-41, Зиновьева А. Д.
|
|
||||||
|
|
||||||
## Разворачивание сервиса Gitea
|
|
||||||
|
|
||||||
Содержимое файла `docker-compose.yml` в папке Gitea:
|
|
||||||
```yaml
|
|
||||||
version: "3"
|
|
||||||
|
|
||||||
networks:
|
|
||||||
gitea:
|
|
||||||
external: false
|
|
||||||
# Контейнер Gitea
|
|
||||||
services: # Описание служб
|
|
||||||
server:
|
|
||||||
image: gitea/gitea:1.20.4 # Образ gitea
|
|
||||||
container_name: gitea # Наименование контейнера
|
|
||||||
environment: # Наши параметры
|
|
||||||
- USER_UID=1000
|
|
||||||
- USER_GID=1000
|
|
||||||
- GITEA__database__DB_TYPE=mysql
|
|
||||||
- GITEA__database__HOST=db:3306
|
|
||||||
- GITEA__database__NAME=gitea
|
|
||||||
- GITEA__database__USER=gitea
|
|
||||||
- GITEA__database__PASSWD=gitea
|
|
||||||
restart: always
|
|
||||||
networks: # Параметры сети
|
|
||||||
- gitea
|
|
||||||
volumes: # Каталоги для хранения данных контейнера
|
|
||||||
- ./gitea:/data
|
|
||||||
- /etc/timezone:/etc/timezone:ro
|
|
||||||
- /etc/localtime:/etc/localtime:ro
|
|
||||||
ports: # Порт локальный и внутри сети
|
|
||||||
- "3000:3000"
|
|
||||||
- "222:22"
|
|
||||||
depends_on:
|
|
||||||
- db
|
|
||||||
# База данных
|
|
||||||
db:
|
|
||||||
image: mysql:8 # Образ БД и версия
|
|
||||||
restart: always # Параметр перезапуска
|
|
||||||
environment: # Подключаем каталог с базой данных
|
|
||||||
- MYSQL_ROOT_PASSWORD=gitea
|
|
||||||
- MYSQL_USER=gitea
|
|
||||||
- MYSQL_PASSWORD=gitea
|
|
||||||
- MYSQL_DATABASE=gitea
|
|
||||||
networks: # Параметры сети
|
|
||||||
- gitea
|
|
||||||
volumes: # Том для хранения данных БД
|
|
||||||
- ./mysql:/var/lib/mysql
|
|
||||||
```
|
|
||||||
Далее в командной строке разворачиваем сервис командой `docker-compose up -d`:
|
|
||||||

|
|
||||||
|
|
||||||
Открываем Docker Desktop и проверяем, что контейнер сервера БД и Gitea созданы и запущены:
|
|
||||||

|
|
||||||
|
|
||||||
Переходим на http://localhost:222:
|
|
||||||

|
|
||||||
|
|
||||||
Регистрируемся и автоматически входим в учетную запись:
|
|
||||||

|
|
||||||
|
|
||||||
## Разворачивание сервиса Wordpress
|
|
||||||
|
|
||||||
Также в файл `docker-compose.yml` в папке Wordpress прописываем следующий код:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
version: '3.1'
|
|
||||||
|
|
||||||
services:
|
|
||||||
# Контейнер Wordpress
|
|
||||||
wordpress:
|
|
||||||
image: wordpress # Образ
|
|
||||||
restart: always # Параметр перезапуска
|
|
||||||
ports: # На каком порте запускаем
|
|
||||||
- 7071:80
|
|
||||||
environment: # Настройки БД WordPress для подключения
|
|
||||||
WORDPRESS_DB_HOST: database # Имя хоста БД MySQL
|
|
||||||
WORDPRESS_DB_USER: user # Имя пользователя БД
|
|
||||||
WORDPRESS_DB_PASSWORD: password # Пароль пользователя БД
|
|
||||||
WORDPRESS_DB_NAME: name_database # Имя БД
|
|
||||||
volumes: # Каталог хранения файлов WordPress
|
|
||||||
- wordpress:/var/www/html
|
|
||||||
# Контейнер MySQL
|
|
||||||
database:
|
|
||||||
image: mysql:5.7 # Образ и его версия
|
|
||||||
restart: always # Параметр перезапуска
|
|
||||||
environment: # Настройки БД для подключения
|
|
||||||
MYSQL_DATABASE: name_database
|
|
||||||
MYSQL_USER: user
|
|
||||||
MYSQL_PASSWORD: password
|
|
||||||
MYSQL_RANDOM_ROOT_PASSWORD: '12345'
|
|
||||||
volumes: # Каталог хранения данных БД
|
|
||||||
- database:/var/lib/mysql
|
|
||||||
|
|
||||||
volumes:
|
|
||||||
wordpress:
|
|
||||||
database:
|
|
||||||
```
|
|
||||||
Далее в командной строке разворачиваем сервис командой `docker-compose up -d`:
|
|
||||||

|
|
||||||
|
|
||||||
Открываем Docker Desktop и проверяем, что контейнер сервера БД и Wordpress созданы и запущены:
|
|
||||||

|
|
||||||
|
|
||||||
Устанавливаем Wordpress и проверяем, что все работает:
|
|
||||||

|
|
||||||

|
|
||||||

|
|
||||||

|
|
||||||
|
|
||||||
## Разворачивание сервиса Redmine
|
|
||||||
|
|
||||||
Также в файл `docker-compose.yml` в папке Redmine прописываем код:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
version: '3.1'
|
|
||||||
|
|
||||||
services:
|
|
||||||
# Контейнер Redmine
|
|
||||||
redmine:
|
|
||||||
image: redmine # Образ контейнера
|
|
||||||
restart: always
|
|
||||||
ports: # На какой порт запускать
|
|
||||||
- 8080:3000
|
|
||||||
environment:
|
|
||||||
REDMINE_DB_MYSQL: db
|
|
||||||
REDMINE_DB_PASSWORD: example
|
|
||||||
REDMINE_SECRET_KEY_BASE: supersecretkey
|
|
||||||
# Контейнер БД MySQL
|
|
||||||
db:
|
|
||||||
image: mysql:5.7 # Образ БД и ее версия
|
|
||||||
restart: always
|
|
||||||
environment: # Название и пароль админа БД
|
|
||||||
MYSQL_ROOT_PASSWORD: example
|
|
||||||
MYSQL_DATABASE: redmine
|
|
||||||
```
|
|
||||||
Далее в командной строке разворачиваем сервис командой `docker-compose up -d`:
|
|
||||||

|
|
||||||
|
|
||||||
Открываем Docker Desktop и проверяем, что контейнер сервера БД и Redmine созданы и запущены:
|
|
||||||

|
|
||||||
|
|
||||||
Переходим на http://localhost:8080:
|
|
||||||

|
|
||||||
|
|
||||||
Регистрируемся и проверяем, что все работает:
|
|
||||||

|
|
||||||
Заходим под админом и подтверждаем учетную запись пользователя:
|
|
||||||

|
|
||||||
Выполнгяем вход под пользователем:
|
|
||||||

|
|
||||||
|
Before Width: | Height: | Size: 118 KiB |
|
Before Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 89 KiB |
|
Before Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 29 KiB |
|
Before Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 123 KiB |
|
Before Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 118 KiB |
|
Before Width: | Height: | Size: 73 KiB |
|
Before Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 76 KiB |
|
Before Width: | Height: | Size: 66 KiB |
|
Before Width: | Height: | Size: 59 KiB |
|
Before Width: | Height: | Size: 93 KiB |
|
Before Width: | Height: | Size: 64 KiB |
|
Before Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 50 KiB |
57
tasks/zinoveva-ad/lab_7/README.md
Normal file
@@ -0,0 +1,57 @@
|
|||||||
|
# Отчет по лабораторной работе №7
|
||||||
|
|
||||||
|
Выполнила студентка гр. ИСЭбд-41 Зиновьева А. Д.
|
||||||
|
|
||||||
|
## Какие алгоритмы и методы используются для балансировки нагрузки?
|
||||||
|
|
||||||
|
Балансировка нагрузки - это процесс распределения рабочих задач между серверами или ресурсами, чтобы оптимизировать производительность и обеспечить стабильную работу системы. Алгоритмы и методы, которые используются для балансировки нагрузки:
|
||||||
|
|
||||||
|
1. Round-Robin DNS (Round Robin): Клиент отправляет DNS-запрос для определенного домена, DNS-сервер отвечает клиенту, возвращает список IP-адресов серверов, связанных с этим доменом, обеспечивая равномерное распределение нагрузки.
|
||||||
|
|
||||||
|
2. Весовая балансировка (Weighted Round Robin): У каждого сервера устанавливается вес. Список серверов и их весов сохраняется в балансировщике нагрузки. DNS возвращает IP-адреса в зависимости от их веса, который может быть связан с производительностью сервера, нагрузка получается гибко распределенной.
|
||||||
|
|
||||||
|
3. Распределенная хэш-функция (Distributed Hash Tables, DHT): Каждый сервер отвечает за свою часть IP-пространства, что позволяет быстро и эффективно распределять нагрузку.
|
||||||
|
|
||||||
|
4. Балансировка на основе IP: Когда клиент отправляет запрос на сервер, пакет данных включает IP-адрес, запрос клиента попадает на балансировщик нагрузки, который анализирует IP для определения, на какой сервер направить запрос. Трафик получается равномерным.
|
||||||
|
|
||||||
|
5. Балансировка на основе порта: Сервер балансировки определяет, на какой порт отправить запрос, исходя из информации о портах, полученных от клиента.
|
||||||
|
|
||||||
|
6. Балансировка с использованием состояния (Stateful Load Balancing): Сервер балансировки учитывает состояние каждого сервера, чтобы определить, какой из них наиболее подходит для обработки запроса.
|
||||||
|
|
||||||
|
Оптимальный выбор алгоритма или метода для балансировки нагрузки будет зависеть от конкретных требований и характеристик системы.
|
||||||
|
|
||||||
|
## Какие открытые технологии существуют для балансировки нагрузки?
|
||||||
|
|
||||||
|
1. NGINX: популярный веб-сервер и обратный прокси, который может выполнять функции балансировки нагрузки. Он распределяет трафик между несколькими серверами, поддерживает разные алгоритмов балансировки нагрузки и имеет гибко настраивается.
|
||||||
|
|
||||||
|
2. HAProxy: работает на уровне TCP/HTTP. Программа предоставляет возможность балансировки нагрузки между серверами приложений. Она обеспечивает высокую производительность, поддерживает много различных протоколов. (также поддерживает SSL)
|
||||||
|
|
||||||
|
3. Apache HTTP Server: этот веб-сервер с функциями балансировки нагрузки. У него есть модуль mod_proxy_balancer, он позволяет распределить трафик между несколькими серверами.
|
||||||
|
|
||||||
|
4. IPVS (IP Virtual Server): модуль ядра Linux, который обеспечивает балансировку нагрузки на уровне IP. Он позволяет распределять трафик между несколькими серверами на основе разных алгоритмов.
|
||||||
|
|
||||||
|
Каждая из них имеет свои плюсы и минусы.
|
||||||
|
|
||||||
|
## Как осуществляется балансировка нагрузки на базах данных?
|
||||||
|
|
||||||
|
Балансировка нагрузки на базах данных может быть сложной задачей, так как базы данных являются критическими компонентами веб-приложений. Однако, есть несколько подходов и методов, которые помогают решить эту задачу:
|
||||||
|
|
||||||
|
1. Репликация данных - процесс создания копий базы данных на нескольких серверах. Один сервер назначается сервером мастер, который принимает записи, а остальные серверы являются серверами слейвами, которые получают обновления из мастер-сервера. Запросы на чтение могут быть перенаправлены на любой из серверов слейвов, распределяя нагрузку между ними.
|
||||||
|
|
||||||
|
2. Шардинг - разбиения базы данных на несколько независимых фрагментов (шарды) и их распределение по разным серверам/узлам. Каждый шард содержит только часть данных, и клиенты направляют запросы к соответствующему шарду. Это позволяет распределить нагрузку между серверами.
|
||||||
|
|
||||||
|
3. Подходы на основе запросов - эти методы используются для маршрутизации запросов БД на основе типа запроса или определенных правил. Например, можно настроить прокси-сервер или брокер сообщений для маршрутизации запросов к соответствующим серверам БД.
|
||||||
|
|
||||||
|
## Реверс-прокси как один из элементов балансировки нагрузки.
|
||||||
|
|
||||||
|
Реверс-прокси - это сервер, расположенный между клиентом и серверами БД, и его главная задача заключается в перенаправлении запросов от клиента к соответствующим серверам БД.
|
||||||
|
|
||||||
|
Реверс-прокси выполняет функции:
|
||||||
|
1. Балансировка нагрузки;
|
||||||
|
2. Кеширование;
|
||||||
|
3. Шифрование и безопасность (SSL);
|
||||||
|
4. Обработка статических файлов;
|
||||||
|
5. Фильтрация запросов;
|
||||||
|
6. Обратная маршрутизация.
|
||||||
|
|
||||||
|
Использование реверс-прокси позволяет более эффективно распределить нагрузку, улучшить производительность и обеспечить безопасность.
|
||||||