!Лекц_Адм_ОС_2025_07_03

1.

Администрирование сетевых
операционных систем

2.

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

3.

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

4.

Службы и протоколы

5.

Эталонные модели
• Эталонная модель OSI
• Эталонная модель TCP/IP
• Сравнение эталонных моделей OSI и TCP/IP

6.

Модель OSI
1. Уровень должен создаваться по мере
необходимости отдельного уровня абстракции.
2. Каждый уровень должен выполнять строго
определенную функцию.
3. Выбор функций для каждого уровня должен
осуществляться с учетом создания
стандартизированных международных
протоколов.

7.

Модель OSI (2)
4. Границы между уровнями должны выбираться
так, чтобы поток данных между интерфейсами
был минимальным.
5. Количество уровней должно быть достаточно
большим, чтобы различные функции не
объединялись в одном уровне без
необходимости, но не слишком высоким, чтобы
архитектура не становилась громоздкой.

8.

Эталонная
модель
OSI

9.

Эталонные модели

10.

Эталонные модели (3)
• Протоколы и сети в модели TCP/IP
Физический +
Передачи
данных

11.

Службы, предоставляемые сетевому
уровню
Хост 1
Хост 2
Хост 1
Хост 2
4
4
4
4
3
3
3
3
2
2
2
1
1
2
Виртуальный
путь данных
1
(a)
•(a) Виртуальное соединение
•(b) Реальное соединение
Фактический
путь данных
(b)
1

12.

Службы, предоставляемые сетевому
уровню (2)
Маршрутизатор
Процесс уровня
Процесс
передачи данных маршрутизации
2
3
2
2
2
Протокол
передачи
данных
Кадры Пакеты
Линия связи
с маршрутизатором
•Протокол передачи данных
3

13.

Сравнение моделей OSI и TCP/IP
Центральная концепция модели
OSI:
• Службы (сервисы)
• Интерфейсы
• Протоколы

14.

Критика модели OSI
• Несвоевременность
• Неудачная технология
• Неудачная реализация
• Неудачная политика

15.

Критика эталонной модели TCP/IP
• Нечеткое разделение понятий служб,
интерфейсов и протоколов
• Не является общей моделью
• Хост-сетевой «уровень» не является на самом
деле уровнем
• Не разделены физический уровень и уровень
передачи данных
• Некоторые протоколы неудачно реализованы и
сложны для обновления (или замены)

16.

Гибридная модель

17.

Интернет

18.

Архитектура Интернет

19.

Виртуальные локальные сети
Здание с централизованной проводкой

20.

Виртуальные локальные сети (2)
(а) Четыре физические ЛВС, объединенные в две виртуальные
сети, серую и белую, двумя мостами (б) Те же 15 машин,
объединенных в две виртуальные сети коммутаторами

21.

Стандарт IEEE 802.1Q
Передача данных из обычного Ethernet в ВЛВС-совместимый Ethernet. Затененные символы –
это ВЛВС-устройства. Все остальные несовместимы с виртуальными сетями

22.

Примерная топология
экспериментальной сети

23.

Аналог ВМ - маршрутизатор

24.

Содержимое DHCP-запроса

25.

26.

Последовательность работы
• 1. Настройка сетевых интерфейсов
• 2. Установка DHCP-сервера isc-dhcp-server
• 3. Настройка файла конфигурации:
• /etc/default/isc-dhcp-server - имя сетевого
интерфейса для принятия запросов
("ens0p3")

27.

• 4. Настройка пула ip-адресов
• /etc/dhcp/dhcpd.conf
• subnet
• range
• option domain-name-servers
• option routers
• option broadcast-address
• dfault-lease-time
• max-lease-time

28.

1. ip route list - проверить IP-адреса и шлюз на клиенте
IP-адрес должен быть из ожидаемого пула
Шлюз (default via) должен быть IP-адресом интерфейса сервера
2. NAT на DHCP-сервере
sudo iptables -t nat -L -n -v
sudo iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
3. Проверка пересылки пакетов (IP Forwarding)
cat /proc/sys/net/ipv4/ip_forward
Если вывод 0, пересылка: sudo nano /etc/sysctl.conf
net.ipv4.ip_forward=1
sudo sysctl -p (применяем настройки)

29.

• 5. Перезапуск сервера
• sudo systemctl restart isc-dhcp-server
• 6. Просмотр статуса
• sudo systemctl status isc-dhcp-server
• Настройка нескольких сетей
• ...

30.

sudo vim /etc/netplan/...
network:
version: 2
ethernets:
enp0s3:
...
network:
version: 2
renderer: NetworkManager
dhcp4: true
enp0s8:
dhcp4: no
addresses: [192.168.1.1/24]

31.

Служба DNS
• DNS (Domain Name System) – система,
переводящая понятные человеку доменные
имена в IP-адреса, которые используют
компьютеры для связи друг с другом.

32.

Хранение имён в файле
• Hosts.txt (/etc/hosts,
C:\Windows\System32\drivers\etc\hosts)
• Формат записей:
IP-адрес ресурса <пробел> название ресурса
123.123.123.123 faq-reg.ru www.faq-reg.ru

33.

Проблемы с файлом
• Информационные потоки и нагрузка
• Конфликты имён
• Синхронизация

34.

Решение
• Децентрализация
– Локальное управление данными
– Обеспечение доступности
– Иерархия

35.

DNS как распределённая БД
• Механизм клиент-сервер
• Репликация
• Кэширование

36.

DNS-серверы
• Владеет информацией об отдельных
сегментах базы данных
• Обеспечивают доступ к информации DNSклиентам

37.

Структура DNS и ФС

38.

Порядок чтения имён

39.

Управление доменами

40.

Зоны DNS

41.

Псевдоним в DNS

42.

DNS-запрос
• компьютер или устройство отправляет
запрос на ближайший DNS-сервер
• сервер называется рекурсивным
резолвером
• если этот сервер знает нужный IP-адрес, он
возвращает его вашему браузеру
• если нет, запрос передается на другие DNSсерверы, пока не будет найден правильный
адрес

43.

DNS-запрос
• Локальный кеш: сначала браузер проверяет свой
локальный кеш на наличие записи для
example.com. Если она найдена, используется
кешированный IP-адрес.
• Рекурсивный резолвер: если записи нет в
локальном кеше, запрос отправляется на
рекурсивный DNS-сервер. Этот сервер выполняет
роль посредника, который ищет нужную
информацию, обращаясь к другим серверам.

44.

DNS-запрос
• Корневые серверы: если рекурсивный сервер не
знает IP-адрес, он отправляет запрос на один из
корневых серверов. Корневые серверы знают,
какой сервер отвечает за каждый домен верхнего
уровня (TLD), такой как .com, .net, .org и так далее.
• Сервер TLD: корневой сервер отвечает, какой
сервер управляет доменом .com, и рекурсивный
резолвер отправляет запрос на этот сервер.

45.

DNS-запрос
• Авторитетный сервер: сервер TLD (например, для
.com) отвечает, какой сервер управляет доменом
example.com. Рекурсивный резолвер направляет
запрос на авторитетный DNS-сервер для
example.com, который содержит точные данные о
домене.
• Подключение к веб-сайту: теперь, когда браузер
знает IP-адрес, он может отправить запрос
непосредственно на сервер, чтобы загрузить
содержимое веб-сайта.

46.

Микросервисы
• Микросервис – это независимый,
автономный ресурс, спроектированный как
отдельный выполняемый файл или процесс
• разрабатывается, тестируется,
развертывается и масштабируется
независимо от других микросервисов
• слабая взаимозависимость, высокая
масштабируемость и ориентированность на
службы

47.

Микросервисы

48.

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

49.

Монолитная архитектура

50.

Архитектура на основе
микросервисов

51.

Расширение функциональности

52.

Вспомогательные микросервисы

53.

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

54.

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

55.

Выгоды микросервисных
архитектур
• непрерывное развертывание. Благодаря меньшему
количеству взаимозависимостей в коде и более
быстрому циклу разработки парадигма микросервисов
поддерживает культуру непрерывного развертывания и
интеграции разработки и эксплуатации (DevOps) и
фактически подталкивает к ее использованию;
• больше свободы и меньше зависимости.
Микросервисы по определению автономны и
независимы. Команда разработчиков может
сосредоточиться на своем микросервисе и свободно
расширять его возможности, не опасаясь нарушить
работу другого микросервиса, пока они гарантируют
неизменность интерфейса или реализуют новый
интерфейс, обратно совместимый с прежним;

56.

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

57.

Выгоды микросервисных
архитектур
• разделение и децентрализация данных. В отличие от
монолитных приложений, где все данные обычно хранятся
вместе в центральной базе данных, микросервисы дают
возможность разделить данные. Каждый микросервис может
владеть только своими данными и не делиться ими с другими
микросервисами;
• широта выбора. В отличие от монолитного приложения, где все
компоненты используют единую базу данных, платформу и
должны быть написаны на одном языке программирования,
микросервисы дают возможность использовать инструменты,
лучше подходящие для каждого конкретного случая. Один
микросервис может использовать Oracle и ОС Linux, а другой –
NoSQL и Microsoft Windows.

58.

Сравнение масштабируемости

59.

Недостатки микросервисов
• сложность поиска и устранения неисправностей.
Микросервисы предлагают свои возможности посредством
механизма взаимодействий между микросервисами, что
увеличивает число потенциальных точек отказа.
Сложные вопросы:
• Насколько нормально работает моя система в данный момент?
• Если конечный пользователь сообщает о такой проблеме, как
низкая производительность или длительные периоды
ожидания, с чего начать устранение неполадок?
• Отследить путь обработки запроса в монолитном приложении
намного проще. Но в приложении, состоящем из
микросервисов, каждый запрос может быть разбит на
несколько запросов, обрабатываемых разными
микросервисами. Поиск и устранение неполадок в этом случае
могут стать немного сложнее;

60.

Недостатки микросервисов
• увеличенные задержки. Внутрипроцессные
взаимодействия (как и в монолитных приложениях)
выполняются намного быстрее межпроцессных (как
в случае с микросервисами);
• сложность сопровождения. Когда приложение
состоит из сотен или даже тысяч микросервисов,
группам оперативного сопровождения приходится
преодолевать сложности, связанные с настройкой
инфраструктуры, развертыванием, мониторингом,
резервным копированием и управлением. Эти
сложности можно преодолеть с помощью высокого
уровня автоматизации;

61.

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

62.

Монолитная система

63.

Параметры системы

64.

Миграция монолитной системы
на микросервисную архитектуру

65.

Процессы
и их поддержка в
операционных системах

66.

Понятие процесса
Процесс и программа
• Термин «процесс» характеризует совокупность
– набора исполняющихся команд
– ассоциированных с ним ресурсов
– текущего момента его выполнения
находящуюся под управлением ОС
• Процесс ≠ программа, которая исполняется:
– для исполнения одной программы может организовываться
несколько процессов
– в рамках одного процесса может исполняться несколько программ
– в рамках процесса может исполняться код, отсутствующий в
программе

67.

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

68.

Набор операций
одноразовые
• создание процесса – завершение процесса
• запуск процесса – приостановка процесса
• блокирование процесса – разблокирование
процесса
• (изменение приоритета)
многоразовые

69.

Process Control Block
и контекст процесса
Контекст процесса
Системный контекст
состояние процесса
программный счетчик
Регистровый
содержимое регистров
контекст
данные для планирования использования процессора и
управления памятью
• учетная информация
• сведения об устройствах ввода-вывода, связанные с
процессом
PCB
Код и данные в адресном пространстве
Пользовательский контекст

70.

Пример генеалогического леса процессов
Процесс 1
Процесс 12
Процесс 2
Процесс 255
Процесс 4
Процесс 3
Процесс 14
Процесс 23
Процесс 192
Процесс 15
Процесс 128

71.

Создание процесса
• Порождение нового PCB с состоянием процесса рождение
• Присвоение идентификационного номера
из ресурсов родителя
• Выделение ресурсов
из ресурсов ОС
• Занесение в адресное пространство кода и установка
значения программного счетчика
дубликат родителя
из файла
• Окончание заполнения PCB
• Изменение состояния процесса на готовность

72.

Завершение процесса
• Изменение состояния процесса на закончил
исполнение
• Освобождение ресурсов
• Очистка соответствующих элементов в PCB
• Сохранение в PCB информации о причинах
завершения

73.

Пример генеалогического леса процессов
Процесс 1
Процесс 2
Процесс 12
Процесс 255
Процесс 3
?
Процесс 14
Процесс 15
Процесс 4
Процесс 128
Процесс 23
Процесс 192
(Parent – 255)

74.

Запуск процесса
• Выбор одного из процессов, находящихся в состоянии
готовность
• Изменение состояния выбранного процесса на
исполнение
• Обеспечение наличия в оперативной памяти информации,
необходимой для его выполнения
• Восстановление значений регистров
• Передача управления по адресу, на который указывает
программный счетчик

75.

Приостановка процесса
• Автоматическое сохранение программного счетчика и
части регистров (работа hardware)
• Передача управления по специальному адресу (работа
hardware)
• Сохранение динамической части регистрового и
системного контекстов в PCB
• Изменение состояния процесса на готовность
• Обработка прерывания

76.

Блокирование процесса
• Обработка системного вызова
• Сохранение контекста процесса в PCB
• Перевод процесса в состояние ожидание

77.

Разблокирование процесса
• Уточнение того, какое именно событие произошло
• Проверка наличия процесса, ожидающего этого
события
• Перевод ожидающего процесса в состояние
готовность
• Обработка произошедшего события

78.

Выполнение кода
пользователя
Восстановление
контекста
Работа hardware
Выполнение кода ОС
Процесс 1
Работа hardware
Исполнение
Готовность
Выполнение кода
пользователя
Процесс 2
Ожидание
Прерывание
Сохранение
контекста
Готовность
Обработка
прерывания
Исполнение
Выполнение кода ОС
Планирование
Пример цепочки операций

79.

Уровни планирования процессов
• Долгосрочное планирование – планирование
заданий.
• Среднесрочное планирование – swapping.
• Краткосрочное планирование – планирование
использования процессора.

80.

Цели планирования
• Справедливость
• Эффективность
• Сокращение полного времени выполнения
(turnaround time)
• Сокращение времени ожидания (waiting time)
• Сокращение времени отклика (response time)

81.

Желаемые свойства
алгоритмов планирования
• Предсказуемость
• Минимизация накладных расходов.
• Равномерность загрузки вычислительной системы.
• Масштабируемость.

82.

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

83.

Основные причины для объединения
усилий процессов
• Повышение скорости решения задач
• Совместное использование данных
• Модульная конструкция какой-либо системы
• Для удобства работы пользователя
Кооперативные или взаимодействующие процессы - это
процессы, которые влияют на поведение друг друга путем
обмена информацией
83

84.

Категории средств обмена информацией
• Сигнальные
• Канальные
• Разделяемая память
84

85.

Основные аспекты логической организации
передачи информации
Как устанавливается связь
• Нужна или не нужна инициализация?
• Способы адресации
– прямая адресация
• симметричная
• асимметричная
– непрямая или косвенная адресация
85

86.

Основные аспекты логической организации
передачи информации
Информационная валентность процессов
и средств связи
• Сколько процессов может быть ассоциировано с конкретным
средством связи?
• Сколько идентичных средств связи может быть
задействовано между двумя процессами?
• Направленность связи
– симплексная связь
– полудуплексная связь
– дуплексная связь
86

87.

Основные аспекты логической организации
передачи информации
Особенности канальных средств связи
Буферизация
• Буфера нет (нулевая емкость)
процесс-передатчик всегда обязан ждать приема
• Буфер конечной емкости
процесс-передатчик обязан ждать освобождения места в буфере,
если буфер заполнен
• Буфер неограниченной емкости (нереализуемо!)
процесс-передатчик никогда не ждет
87

88.

Основные аспекты логической организации
передачи информации
Особенности канальных средств связи
Модели передачи данных
• Потоковая модель
операции приема/передачи не интересуются содержимым данных и
их происхождением, данные не структурируются
• Модель сообщений
на передаваемые данные накладывается определенная структура
88

89.

Основные аспекты логической организации
передачи информации
Особенности канальных средств связи
Потоковая модель - pipe
P0
5 байт
15
начало
конец
P2
255 байт
10 байт
P1
89

90.

Основные аспекты логической организации
передачи информации
Особенности канальных средств связи
Модель сообщений
P0
P2
m1
m3
m3 m2
m1
m3
m2
m1
m2
P1
90

91.

Основные аспекты логической организации
передачи информации
Надежность средств связи
Средство связи считается надежным, если:
Нет потери информации
Нет повреждения информации
Нет нарушения порядка поступления информации
Не появляется лишняя информация
91

92.

Основные аспекты логической организации
передачи информации
Как завершается связь
• Нужны ли специальные действия для прекращения
использования средства связи?
• Как влияет прекращение использования средства
связи одним процессом на поведение других
участников взаимодействия?
92

93.

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

94.

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

95.

Виртуальные машины

96.

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

97.

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

98.

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

99.

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

100.

Проблемы, характерные для
виртуальных машин
• операционные системы сами потребляют
значительные объемы ресурсов. Им
необходимы большой объем памяти и
значительная вычислительная мощность.
Резервная копия виртуальной машины
имеет очень большой размер, потому что
этот файл содержит ОС, установленное
приложение с зависимостями и локальные
данные

101.

Проблемы, характерные для
виртуальных машин
• общий доступ к виртуальным машинам. Перемещение виртуальных
машин и организация общего доступа к ним из WAN занимают много
времени из-за большого размера;
• переносимость. Когда один разработчик передает подготовленную
виртуальную машину другому разработчику, он не прекращает
разработку, а продолжает вносить изменения в приложение, базу
данных, окружение и т.д. По истечении некоторого времени
разработчик будет вынужден вновь передать виртуальную машину
целиком. Аналогичные проблемы возникают при переходе от
разработки к тестированию в эксплуатационном окружении. Есть два
пути: или перекомпилировать весь код в каждой виртуальной
машине, или переместить окружение целиком;

102.

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

103.

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

104.

Контейнеры

105.

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

106.

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

107.

Контейнеры Docker
• Docker–технология внесла несколько
изменений в контейнеры Linux, чтобы
сделать их более переносимыми, простыми
в использовании и гибкими. С этой целью
был реализован набор утилит, которые
обеспечивают переносимость и гибкость
контейнеров. Эти утилиты позволяют легко
создавать, передавать, копировать и
запускать контейнеры.

108.

Контейнеры Docker
• процессы. В одном контейнере Linux (LXC) можно
запустить несколько процессов, тогда как в
контейнере Docker может выполняться только один
процесс. Если приложение состоит из нескольких
процессов, необходимо создать соответствующее
количество контейнеров Docker. Поскольку каждый
процесс выполняется в отдельном контейнере, есть
возможность управлять процессами и изменять их
поведение по отдельности. Это согласуюется с
идеей микросервисов, когда каждая служба
действует автономно и в отдельном процессе;

109.

Контейнеры Docker
• постоянное хранилище. Контейнеры Docker не имеют своего
состояния, т.к. не поддерживают собственного постоянного
хранилища. При необходимости можно подключить такое
хранилище, смонтировав Docker;
• переносимость. Docker обеспечивает большую переносимость,
чем LXC. При использовании LXC переносимость не
гарантируется, т. е. при перемещении контейнера LXC с одного
хоста на другой он может работать с ошибками из-за различий
между конфигурациями серверов. Docker гарантирует
беспроблемную переносимость, потому что лучше, чем LXC,
изолирует приложение от таких деталей, как настройки
операционной системы, сетевой подсистемы и хранилища.
Закончив разработку и тестирование, программист может
создать образ, который гарантированно будет работать после
загрузки и запуска в эксплуатационном окружении.

110.

NAT на DHCP-сервере
sudo iptables -t nat -A POSTROUTING -o enp0s3
-j MASQUERADE

111.

Проверка пересылки пакетов (IP
Forwarding)
cat /proc/sys/net/ipv4/ip_forward
Если вывод 0, пересылка:
sudo nano /etc/sysctl.conf
Редактируем строку: net.ipv4.ip_forward=1
sudo sysctl -p (применяем настройки)

112.

Установка BIND9
sudo apt update && sudo apt upgrade –y
sudo apt install bind9 bind9utils bind9-doc -y
sudo systemctl status bind9
sudo systemctl start bind9

113.

Разрешение доступа к порту 53
для DNS-запросов
sudo ufw allow 53/tcp
sudo ufw allow 53/udp

114.

Редактирование
конфигурационного файла
sudo nano /etc/bind/named.conf.options
acl dnsclients {
192.168.0.0/24;
localhost;
localnets;
};
options {
...
allow-query {dnsclients;};
...
listen-on { any; };
listen-on-v6 { none; };
};

115.

Проверка конфигурации
sudo named-checkconf
sudo systemctl restart bind9

116.

Проверка работы
Команды:
• dig
• nslookup

117.

Access-lists

118.

Установка Docker
• sudo apt update
• sudo apt install curl software-propertiescommon ca-certificates apt-transport-https -y
• curl -fsSL
https://download.docker.com/linux/ubuntu/g
pg | sudo apt-key add • sudo add-apt-repository "deb [arch=amd64]
https://download.docker.com/linux/ubuntu
jammy stable"

119.

• sudo apt update
• sudo apt install docker-ce -y
• sudo systemctl status docker
• sudo usermod -aG docker $USER
• newgrp docker

120.

Установка Docker Compose
• sudo apt-get install docker-compose
• docker compose version