Установка системы мониторинга zabbix

1.

Установка системы мониторинга zabbix
sudo apt update
wget https://repo.zabbix.com/zabbix/5.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.4-1+ubuntu20.04_all.deb
dpkg -i zabbix-release_5.4-1+ubuntu20.04_all.deb
apt update
sudo apt install apache2
sudo systemctl start apache2
sudo systemctl enable apache2
sudo apt install php php-mbstring php-gd php-xml php-bcmath php-ldap php-mysql
nano /etc/php/7.4/apache2/php.ini
sudo systemctl restart apache2
sudo apt install mariadb-server
sudo mysql_secure_installation
sudo mysql -u root –p
CREATE DATABASE zabbix character set utf8 collate utf8_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'P@ssword321’;
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent
zcat /usr/share/doc/zabbix-sql-scripts/mysql/create.sql.gz | mysql –u root -p zabbix
nano /etc/zabbix/zabbix_server.conf
systemctl restart zabbix-server zabbix-agent apache2
systemctl enable zabbix-server zabbix-agent apache2

2.

3.

4.

5.

6.

Login/password Admin/zabbix

7.

Что будет сегодня на уроке
Рассмотрим кластеры как вариант оптимизации
Рассмотрим работу DevOps инженера
Подведем итоги курса

8. Кластеры как вариант оптимизации

Анализ, оптимизация и
аварийные работы в Linux
Кластеры как вариант оптимизации

9.

Анализ, оптимизация и
аварийные работы в Linux
Кластеризация
Кластер — слабо связанная совокупность нескольких вычислительных систем, работающих
совместно для выполнения общих приложений, и представляющихся пользователю единой
системой.

10.

Анализ, оптимизация и
аварийные работы в Linux
Виды кластеров
Отказоустойчивые кластеры (High-availability clusters, HA)
Кластеры с балансировкой нагрузки (Load balancing clusters)
Вычислительные кластеры (High performance computing clusters, HPC)
Системы распределенных вычислений

11.

Анализ, оптимизация и
аварийные работы в Linux

12.

Анализ, оптимизация и
аварийные работы в Linux

13.

Анализ, оптимизация и
аварийные работы в Linux
Высоконагруженные кластерные системы

14.

Анализ, оптимизация и
аварийные работы в Linux
Высоконагруженные кластерные системы

15.

Анализ, оптимизация и
аварийные работы в Linux

16.

Анализ, оптимизация и
аварийные работы в Linux

17.

Кто такой DevOps инженер
и
чем он может быть полезен

18.

Так кто же такие DevOps инженеры?
Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации
взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие.
Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении
продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или
иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы
повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом.
DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и
работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние
компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой
итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность
самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную
задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили
требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды»
разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему
опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы,
правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора,
который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его
опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды»
разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и
продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой
команде. Так, собственно, и появились DevOps в представлении большинства.

19.

Частично или полностью, со временем, данные системные администраторы начали понимать потребности
именно этой конкретной команды в области разработки, как упростить жизнь разработчикам и тестировщикам,
как выкатить обновление и не остаться ночевать в пятницу в офисе, исправляя ошибки деплоя. Время шло,
теперь «звездами» становились системные администраторы, понимающие чего хотят разработчики. С целью
минимизации импакта начали подтягиваться утилиты управления, все вспомнили старые и надежные методы
изоляции уровня ОС, которые позволяли минимизировать требования по безопасности, управлению сетевой
части, да и конфигурации хоста в целом и, как следствие снизить требования к новым «звездам».
Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание
изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите
позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым
внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь
одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не
стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост
уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к
системным администраторам, которые способны построить данные системы.
Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование,
появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного
процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего
описанного выше — меньше взаимосвязей, проще в управлении. Очень редко можно встретить полностью
микросервисную архитектуру, я бы сказал 50 на 50 — 50 процентов микросервисов, черные коробки, пришло на
вход, вышло обработанное, другие 50 — разодранный монолит, сервисы неспособные работать отдельно от
других компонентов. Все это вновь наложило ограничения на уровень знаний как разработчиков, так
администраторов.
Подобные «качели» уровня экспертных знаний того или иного ресурса продолжаются и по сей день.

20.

Build Engineer/Release Engineer
Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и
его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это
далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в
промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением
DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать
продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без
оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам
качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров
перекочевала на плечи системных администраторов.

21.

Ops'ы такие разные
Мы двигаемся дальше и вновь наличие большого круга обязанностей и недостаток квалифицированных кадров
толкает нас на жесткую специализацию, как грибы после дождя, появляются различные Operations:
TechOps — системные администраторы эникеи aka HelpDesk Engineer
•LiveOps — системные администраторы, преимущественно отвечающие за продуктивные среды
•CloudOps — системные администраторы специализирующиеся на публичных «облаках» Azure, AWS, GCP, etc.
•PlatOps/InfraOps/SysOps — системные администраторы инфраструктуры.
•NetOps — сетевые администраторы
•SecOps — системные администраторы специализирующиеся на информационной безопасности — PCI
compliance, CIS compliance, patching, etc.
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку,
тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с
подходами и средствами автоматизации, хотя бы на высоком уровне, помимо этого понимающая также пред и
пост-релизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development,
что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы
планирования работ командами и управления ожиданиями заказчика.
Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не
только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также
планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он
должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.

22.

DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. Это культура,
методика, если угодно. DevOps-движение возникло в 2008 году и было призвано решить накопившиеся проблемы.
Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации.
Разработчики считали, что если код запустился у них локально, то нет проблем — можно запускать в продакшен.
Если всё же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть
разработчики разбираются». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую
страдало качество конечного продукта. Сильно накладывало отпечаток ещё и то, что за один релиз выкатывалось
очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.
DevOps был призван решить эти проблемы. Он должен был стать связующим звеном между командой разработки
и командой эксплуатации. Условно, в DevOps культуре можно выделить несколько ролей, которые очень хорошо
соотносятся с профессиями:
•Build Engineer — человек, отвечающий за сборку кода. Подтягивание зависимостей, разбор конфликтов в коде —
это все про него.
•Release Engineer — отвечает за доставку кода от разработки в продакшн. Какая ветка пойдет в тестирование,
какой билд попадет на продакшн, релиз-инженер занимается именно этим.
•Automation Engineer — инженер по автоматизации. Автоматизирует все, что движется. А что не движется, двигает
и тоже автоматизирует. Автоматическая сборка при пуше в гит, прогон тестов, деплой на staging, деплой в
продакшн — это все его задачи. Ключевая роль в DevOps подходе.
В целом можно выделить ещё несколько ролей. Например, Security Engineer, который будет отвечать за прогон
security-тестов и изучение уязвимостей в используемых компонентах.
В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К
примеру, роль билд-инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов
обычно отдается системным администраторам. А DevOps-специалисту остаётся проработать и автоматизировать
процесс сборки и доставки кода от разработчика в продакшн.

23.

Польза, которую дает внедрение DevOps в компании
Прежде всего остального, нужно сначала понять, в чем состоит суть технологии, внедряемой DevOps инженер.
Потому что в противном случае все рассуждения и аргументы останутся слишком умозрительными. Так целью
деятельности специалистов данного профиля является создание «умной» сетевой инфраструктуры. То есть,
программируемых сетей и систем нового поколения, использующих широкие возможности автоматизации.
Стоит отметить, что для достижения подобного результат не нужно изобретать какие-то новые технологии.
Вместо этого используются вполне традиционные и понятные инструменты, примененные по-новому. А именно —
программирование и системное администрирование, дополненные сетевой инженерией. В результате
специалист пишет скрипты, позволяющие автоматически управлять сетью. Кроме того, размещает сеть на
удобной платформе, используя максимум преимуществ виртуализации.
По сути, такая инфраструктура минимально привязана к аппаратному обеспечению и может управляться
централизованно. А то и вовсе автоматически реагировать на те или иные условия, заданные инженером. Кроме
того, этот подход дает бизнесу ряд дополнительных преимуществ:
•более низкие расходы на развертывание и поддержание работы сети;
•уменьшенные затраты времени узкопрофильных ИТ-специалистов;
•гибкость в вопросах изменения возможностей системы, ее масштабирования и регулирования.
То есть, можно смело заключить, что инженер DevOps позволяет экономить деньги. Или при тех же затратах
получать более заметный результат.

24.

Что DevOps дает команде
•Меньше ошибок. Одна из причин, почему случаются сбои при развертывании, связана с багами. В DevOps циклы
разработки короче обычных, поэтому код выходит чаще. В результате искать ошибки становится проще, а значит,
количество сбоев уменьшается.
•Сокращение времени выхода сервиса на рынок. Масштабируемые инфраструктуры — облачные платформы,
инструменты для ускорения сборки, параллельные рабочие процессы, работа в одной среде — сильно сокращают
время работы. Развертывать и запускать приложение стало в разы быстрее.
•Создание более гибких и отказоустойчивых систем. Это достигается за счет использования облачной
инфраструктуры. Она дает возможность быстро масштабировать систему, использовать только нужное
количество ресурсов и оперативно увеличивать мощности.
•Повышенная надежность и безопасность приложений. Среди DevOps-инструментов есть те, которые
анализируют исходный код программного обеспечения, чтобы определить, есть ли в нем недостатки
безопасности. Еще есть приложение, которое сканирование сервисы на наличие в них уязвимостей — OWASP
(Open Web Application Security Project).

25.

DevOps
создание технологического стека
(инфраструктуры)
для разработки программного
обеспечения
Развитие
инновационных
технологий
в компании
Поиск и применение
инновационных технологий для
безопасной и бесперебойной
работы информационных ресурсов
Создание регламентов и процедур
для разработки
Программного обеспечения
Создание регламентов и процедур
по работе с инновационными технологиями
специалистов и пользователей
Внедрение практик DevOps в
разработке программного обеспечения
Передача в эксплуатацию инновационных
Технологий специалистам
Автоматизация
бизнес процессов
компании
Применение практик автоматизации
бизнес процессов компании.

26.

27.

ВП
Бизнес Аналитик
Создает ТЗ для
нового функционала
Руководитель проекта
Расставляет приоритеты
Создание архитектуры
Включает в себя 3-х специалистов
Dev Лид – отвечает за архитектуру кода , Бизнес Аналитик – отвечает за бизнес логику, DevOps (старший или ведший
системный администратор или системный аналитик) – отвечает за архитектуру серверной части, сетевой части и железа
Разработка ПО
Ответственные Dev Лид, разработчики,
бизнес аналитик присутствует
как консультант, DevOps помогает частично автоматизировать процессы разработки
Разворачивание продукта на
тестовых стендах
ответственный DevOps
Тестирование
Ответственный тестировщик.
Бизнес аналитик и DevOps в виде консультантов
Разворачивание продукта на
приемочном стенде
ответственный DevOps
Проведение приемосдаточных испытаний
ответственные руководитель проекта, бизнес
аналитик
Разворачивание продукта
У заказчика
ответственный DevOps

28.

29.

Модульное тестирование
Ответственные разработчики,
определяет необходимость Dev Лид
Функциональное тестирование доработок
Ответственные разработчики
Полное функциональное тестирование
Ответственный тестировщик, выполняет согласно тест планов
по заранее заданным тест кейсам (выполняется до мержа в ветку мастер) на специальном тестовом
стенде подготовленным DevOps
Регрессионное тестирование
Ответственный тестировщик, выполняет согласно тест планов
по заранее заданным тест кейсам (после мержа в ветку мастер) на специальном тестовом стенде
подготовленным DevOps
Нагрузочное тестирование
Ответственный тестировщик, выполняет согласно тест планов
по заранее заданным тест кейсам (после мержа в ветку мастер) на специальном тестовом стенде
подготовленным DevOps
Системное тестирование или ПСИ
Ответственные Бизнес Аналитик, руководитель проекта, DevOps, после
этапов тестирования на итоговом стенде компании
Интеграционное тестирование (отдельный вид тестирования) проводится
при необходимости, необходимость определяет руководитель проекта
(если есть интеграция с другими системами)
Отчет о тестировании и Bug отчет,
создается тестировщиком после
проведения тестирования

30.

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

31.

32.

Что такое контейнеры
Прежде чем рассказывать про Docker, нужно сказать несколько слов о технологии контейнеризации.
Контейнеры — это способ упаковать приложение и все его зависимости в единый образ. Этот образ запускается в
изолированной среде, не влияющей на основную операционную систему. Контейнеры позволяют отделить приложение от
инфраструктуры: разработчикам не нужно задумываться, в каком окружении будет работать их приложение, будут ли там
нужные настройки и зависимости. Они просто создают приложение, упаковывают все зависимости и настройки в единый
образ. Затем этот образ можно запускать на других системах, не беспокоясь, что приложение не запустится.
Docker — это платформа для разработки, доставки и запуска контейнерных приложений. Docker позволяет создавать
контейнеры, автоматизировать их запуск и развертывание, управляет жизненным циклом. Он позволяет запускать
множество контейнеров на одной хост-машине.
Контейнеризация похоже на виртуализацию, но это не одно и то же. Виртуализация работает как отдельный компьютер, со
своим виртуальным оборудованием и операционной системой. При этом внутри одной ОС можно запустить другую ОС. В
случае контейнеризации виртуальная среда запускается прямо из ядра основной операционной системы и не
виртуализирует оборудование. Это означает, что контейнер может работать только в той же ОС, что и основная. При этом
так как контейнеры не виртуализируют оборудование, они потребляют намного меньше ресурсов.

33.

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

34.

Ускорение и автоматизация развертывания приложений и масштабируемость
Контейнеры упрощают развертывание приложений. В классическом подходе для установки программы может
потребоваться выполнить несколько действий: выполнить скрипт, изменить файлы настроек и так далее. В этом
процессе не исключена вероятность человеческой ошибки: пользователь запустит скрипт два раза, перепутает
последовательность или что-то не поймет. Контейнеры позволяют полностью автоматизировать этот процесс, так как
включают в себя все нужные зависимости и порядок выполнения действий.
Также контейнеры упрощают развертывание на нескольких серверах. В классическом подходе для того, чтобы
развернуть одно и то же приложение на нескольких машинах, нужно будет повторять одни и те же действия.
Контейнеры избавляют от этой рутинной работы и позволяют автоматизировать развертывание.
Контейнеры приближают к микросервисной архитектуре
Контейнеры хорошо вписываются в микросервисную архитектуру. Это подход к разработке, при котором приложение
разбивается на небольшие компоненты, по возможности независимые. Обычно противопоставляется монолитной
архитектуре, где все части системы сильно связаны друг с другом.
Это позволяет разрабатывать новую функциональность быстрее, ведь в случае с монолитной архитектурой изменение
какой-то части может затронуть всю остальную систему.
Docker compose — одновременно развернуть несколько контейнеров
Docker-compose позволяет разворачивать и настраивать несколько контейнеров одновременно. Например, для вебприложения нужно развернуть стек LAMP: Linux, Apache, MySQL, PHP. Каждое из приложений — это отдельный
контейнер. Но в этой ситуации нам нужны именно все контейнеры вместе, а не отдельно взятое приложение. Dockercompose позволяет развернуть и настроить все приложения одной командой, а без него пришлось разворачивать и
настраивать каждый контейнер отдельно.

35.

Хранение данных в Docker
Она из главных особенностей контейнеров — эфемерность. Это означает, что контейнеры могут быть в любой
момент остановлены, перезапущены или уничтожены. При этом все накопленные данные в контейнере будут
потеряны. Поэтому приложения нужно разрабатывать так, чтобы они не полагались на хранилище данных в
контейнере, это называется принципом Stateless.
Это хорошо подходит для приложений или сервисов, которые не сохраняют результаты своей работы. Например,
функции расчета или преобразования данных: им на вход поступил один набор данных, они его преобразовали или
рассчитали и вернули результат. Все, ничего никуда сохранять не нужно.
Но далеко не все приложения такие, и есть много данных, которые нужно сохранить. В контейнерах для этого
предусмотрены несколько способов.
Тома (Docker volumes)
Это способ, при котором докер сам создает директории для хранения данных. Их можно сделать доступными для
разных контейнеров, чтобы они могли обмениваться данными. По умолчанию эти директории создаются на хостмашине, но можно использовать и удаленные хранилища: файловый сервер или объектное хранилище.
Монтирование каталога (bind mount)
В этом случае директория сначала создается в хост-системе, а уже потом монтируется в докер контейнеры.
Но этот способ не рекомендуется, потому что он усложняет резервное копирование, миграцию и совместное
использование данных несколькими контейнерами.

36.

Архитектура (компоненты) Docker
Теперь расскажем подробнее про компоненты, из которых состоит Docker.
Docker daemon
Это сервис, через который осуществляется все взаимодействие с контейнерами: создание и удаление, запуск
и остановка. Этот сервис работает в фоновом режиме и получает команды от интерфейса командной строки
или API.
Docker client (клиент)
Это интерфейс командной строки для управления docker daemon. Мы пользуемся этим клиентом, когда
создаем и разворачиваем контейнеры, а клиент отправляет эти запросы в docker daemon.
Docker image (образ)
Это неизменяемый файл (образ), из которого разворачиваются контейнеры. Приложения упаковываются
именно в образы, из которых потом уже создаются контейнеры.
Приведем аналогию на примере установки операционной системы. В дистрибутиве (образе) ОС есть все, что
необходимо для ее установки. Но этот образ нельзя запустить, для начала его нужно «развернуть» в готовую
ОС. Так вот, дистрибутив для установки ОС — это Docker image, а установленная и работающая ОС — это Docker
container. Но контейнеры обычно разворачиваются одной командой — это намного проще и быстрее, чем
установка ОС.
Docker container (контейнер)
Это уже развернутое из образа и работающее приложение.
Docker Registry
Это репозиторий с докер-образами. Разработчики создают образы своих программ и выкладывают их в
репозиторий, чтобы их можно было скачать и воспользоваться ими. Распространенный публичный
репозиторий — Docker Hub. В нем собраны образы множества популярных программ или платформ: базы
данных, веб-серверы, компиляторы, операционные системы и так далее. Также можно создать свой
приватный репозиторий, например внутри компании. Разработчики будут размещать там образы, которые
будут использоваться всей компанией.

37.

Dockerfile
Dockerfile — это инструкция для сборки образа. Это простой текстовый файл, содержащий по одной команде в
каждой строке. В нем указываются все программы, зависимости и образы, которые нужны для разворачивания
образа.
Для примера рассмотрим dockerfile, который мы будем использовать далее в этой статье чтобы развернуть
собственное приложение:
Первая строчка означает, что за основу мы берем образ с названием python версии 3 это называется базовый образ. Docker
найдет его в docker registry, скачает и будет использовать за основу. Вторая строчка означает, что нужно скопировать
файл main.py в корень файловой системы контейнера. Третья строчка означает, что нужно запустить python и передать ему
в качестве параметра файл main.py.

38.

Далее рассмотрим примеры нескольких команд докер и что происходит, когда мы их выполняем.
Все эти команды выполняются в Docker client, который отправляет их в docker daemon:
•Команда docker build (зеленая стрелка) читает dockerfile и собирает образ.
•Команда docker pull (красная стрелка) скачивает образ из docker registry. По умолчанию docker скачивает образы из
публичного репозитория Docker Hub. Но можно создать свой репозиторий и настроить докер, чтобы он работал с ним.
•Команда docker run (черная стрелка) берет образ и разворачивает его в контейнер.

39.

Итоги
Анкета обратной связи
Вернись , пожалуйста, на платформу
и заполни форму обратной связи после занятия.
Это поможет сделать наш курс еще интереснее!)

40.

Домашнее задание
1. Установить и настроить систему мониторинга zabbix на любой из ВМ в virtualbox.
2. Используя графики zabbix провести анализ производительности системы (можно
поэкспериментировать с сервисами, включить отключить и смотреть через Zabbix как
работают графики и как меняется производительность).
3. Подключить вторую машину в систему мониторинга zabbix
4. Установить на второй машине связку веб сервер + База данных + cms нагрузить ее с
помощью siege и посмотреть как это отразиться в системе мониторинга zabbix
Дополнительные задания
*5. Создать 3 ВМ (минимум 2 у кого ресурсов мало), установить proxmox, объединить все
ВМ в один кластер на proxmox
*6. Все ноды подключить в систему мониторинга zabbix
*7. Скачать образ виртуальной машины прикрепленный в 6 уроке, развернуть и
попытаться восстановить ее работу.