Compare commits
1 Commits
zinoveva-a
...
zinoveva-a
| Author | SHA1 | Date | |
|---|---|---|---|
| 344ae488f6 |
@@ -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 |
62
tasks/zinoveva-ad/lab_8/README.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Отчет по лабораторной работе №8
|
||||
|
||||
Выполнила студентка гр. ИСЭбд-41 Зиновьева А. Д.
|
||||
|
||||
## Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
||||
|
||||
Существует несколько причин, почему сложные системы, такие как социальные сети, пишутся в распределенном стиле с разделением функциональности:
|
||||
|
||||
1. Распределение нагрузки: Распределенный подход позволяет равномерно распределять нагрузку между разными серверами или сервисами. Это позволяет обеспечить масштабируемость системы и обрабатывать большое количество запросов от пользователей.
|
||||
|
||||
2. Изоляция сбоев: Когда функциональность разделена на отдельные сервисы, сбой в одном сервисе не влияет на работу других. Это повышает отказоустойчивость системы в случае возникновения проблем.
|
||||
|
||||
4. Гибкость и масштабируемость: Распределенный стиль позволяет добавлять или изменять сервисы независимо друг от друга. Это делает систему гибкой и позволяет ей масштабироваться в соответствии с развитием бизнеса и потребностями пользователей.
|
||||
|
||||
## Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
||||
|
||||
Системы оркестрации приложений - это инструменты, которые упрощают разработку, развертывание и управление распределенными приложениями и сервисами. Они помогают автоматизировать масштабирование, управление конфигурацией, мониторинг, масштабирование и отказоустойчивость системы. Однако, они также могут быть сложными и требовать дополнительных знаний и усилий для изучения и понимания их работы.
|
||||
|
||||
Сложности:
|
||||
1. Понимание и использование систем оркестрации требует времени и усилий для изучения и освоения.
|
||||
2. Системы оркестрации могут иметь свои ограничения и требования к структуре и формату приложений. Она требует совместимости и настройки между различными компонентами системы.
|
||||
|
||||
## Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
||||
|
||||
Очереди обработки сообщений используются для организации и управления потоком информации между разными компонентами или сервисами в распределенной системе. Они позволяют организовать эффективную обработку сообщений, упорядочивая их и обеспечивая их последовательную обработку.
|
||||
|
||||
"Сообщение" может иметь различные значения.
|
||||
|
||||
Это могут быть:
|
||||
1. Запросы на выполнение определенных операций;
|
||||
2. Данные для обработки;
|
||||
3. Уведомления о событиях.
|
||||
|
||||
Очереди обработки сообщений позволяют приложениям эффективно обрабатывать и передавать сообщения, гарантируя их сохранность, упорядоченность и последовательную обработку.
|
||||
|
||||
## Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
||||
|
||||
Преимущества:
|
||||
1. Масштабируемость: Распределенные приложения могут легко масштабироваться горизонтально путем добавления новых узлов.
|
||||
2. Отказоустойчивость: Если один узел выходит из строя, остальные узлы продолжают работать, что обеспечивает высокую доступность системы.
|
||||
2. Надежность: Распределенные приложения могут быть устойчивыми к отказу одного или нескольких узлов.
|
||||
4. Улучшенная производительность: Распределенные приложения могут распределять нагрузку между узлами системы, что позволяет эффективно использовать ресурсы и достигать более высокой производительности.
|
||||
|
||||
Недостатки:
|
||||
1. Сложность разработки: из-за необходимости управления, синхронизации и т.д.
|
||||
2. Задержки: могут быть адержки связи из-за необходимости передачи данных по сети.
|
||||
|
||||
## Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
||||
|
||||
Внедрение параллельных вычислений в распределенную систему может быть целесообразно в определенных случаях.
|
||||
|
||||
Примеры, когда внедрение параллельных вычислений действительно нужно:
|
||||
|
||||
1. Когда нужна обработка больших объемов данных, сложные вычисления.
|
||||
2. Когда требуется повысить производительность и отзывчивость.
|
||||
3. Когда требуется обслуживать большое количество одновременных запросов пользователей
|
||||
|
||||
Примеры, когда внедрение параллельных вычислений не обязательно:
|
||||
|
||||
1. Когда не требуется вычислительная мощность;
|
||||
2. Когда задачи сильно зависят друг от друга и не могут быть эффективно разделены на подзадачи;
|
||||
3. Когда внедрение может добавить сложности в разработке.
|
||||