Дайте письменые ответы на следующие вопросы:
- В чём отличие режимов работы сервисов в Docker Swarm кластере: replication и global?
- в global режиме сервис будет развернут одной репликой на каждой ноде в кластере, а в режиме replication сервис будет иметь указанное количество реплик
- Какой алгоритм выбора лидера используется в Docker Swarm кластере?
- Raft
- Что такое Overlay Network?
- Виртуальная сеть которая работает по верх физических сетей, используется Docker Swarm для связи нод на которых запущен Docker
Создать ваш первый Docker Swarm кластер в Яндекс.Облаке
Для получения зачета, вам необходимо предоставить скриншот из терминала (консоли), с выводом команды:
docker node ls
Создать ваш первый, готовый к боевой эксплуатации кластер мониторинга, состоящий из стека микросервисов.
Для получения зачета, вам необходимо предоставить скриншот из терминала (консоли), с выводом команды:
docker service ls
Выполнить на лидере Docker Swarm кластера команду (указанную ниже) и дать письменное описание её функционала, что она делает и зачем она нужна:
# см.документацию: https://docs.docker.com/engine/swarm/swarm_manager_locking/
docker swarm update --autolock=true
Создать собственный образ операционной системы с помощью Packer.
Для получения зачета, вам необходимо предоставить:
- Скриншот страницы, как на слайде из презентации (слайд 37).
Ответ:
Создать вашу первую виртуальную машину в Яндекс.Облаке.
Для получения зачета, вам необходимо предоставить:
- Скриншот страницы свойств созданной ВМ, как на примере ниже:
Ответ:
Создать ваш первый готовый к боевой эксплуатации компонент мониторинга, состоящий из стека микросервисов.
Для получения зачета, вам необходимо предоставить:
- Скриншот работающего веб-интерфейса Grafana с текущими метриками, как на примере ниже
Ответ:
Сценарий выполения задачи:
- создайте свой репозиторий на https://hub.docker.com;
- выберете любой образ, который содержит веб-сервер Nginx;
- создайте свой fork образа;
- реализуйте функциональность: запуск веб-сервера в фоне с индекс-страницей, содержащей HTML-код ниже:
<html>
<head>
Hey, Netology
</head>
<body>
<h1>I’m DevOps Engineer!</h1>
</body>
</html>
Опубликуйте созданный форк в своем репозитории и предоставьте ответ в виде ссылки на https://hub.docker.com/username_repo. Ответ: https://hub.docker.com/r/momukeev/netology
Посмотрите на сценарий ниже и ответьте на вопрос: "Подходит ли в этом сценарии использование Docker контейнеров или лучше подойдет виртуальная машина, физическая машина? Может быть возможны разные варианты?"
Детально опишите и обоснуйте свой выбор.
--
Сценарий:
- Высоконагруженное монолитное java веб-приложение - монолитное веб-приложение предполагает сборку всего в одном месте (frontend, backend, UI). Так как монолитное веб-приложение высоконагруженное, то стоит размещать или на физической среде, или можно использовать пара виртуализацию, если накладными расходами можно пренебречь, однако контейнеризация не подойдет, так предполагается выполнение одного сервиса в рамках контейнера.
- Nodejs веб-приложение - контейнеризация подойдет для решения задачи, по сути node.js - это условно говоря environment для javascript для построения логики работы веб-приложения, является его частью, модулем, хорошо укладывается в микро сервисную архитектуру.
- Мобильное приложение c версиями для Android и iOS - предполагается, что приложение имеет своего потребителя, а значит необходим UI для взаимодействия с пользователем. По моему мнению, корректнее всего использовать виртуализацию с реализацией виртуальной машины.
- Шина данных на базе Apache Kafka - если можно так выразится, то это сервис по трансляции данных из одного формата данных одного приложения в другое. По моему мнению хорошо применить контейнеризацию, так как отсутствуют накладные расходы на виртуализацию, достигается простота масштабирования и управления. В данном случае необходимо организация отказоустойчивости.
- Elasticsearch кластер для реализации логирования продуктивного веб-приложения - три ноды elasticsearch, два logstash и две ноды kibana - для упомянутых продуктов есть контейнеры на docker hub. Из-за простоты управления и сборки контейнеров, мне кажется необходимо распихать продукты по контейнерам и на основании контейнеров собрать кластер стека ELK. В силу прозрачности реализации, в том числе возможности реализации подходов IaaC, контейнеризация в данном случае помогает закрыть вопросы по менеджменту и что очень важно получить регулярный предсказуемый результат.
- Мониторинг-стек на базе Prometheus и Grafana - по моему мнению также как и пример с ELK, скорее всего с течением времени будут вноситься изменения в систему мониторинга и не один раз, будут добавляется метрики, так как точки мониторинга будут меняться - добавляться новый функционал, было бы не плохо применить IaaC в том числе и в этом случае - мониторинг как код, контейнеризация помогает этого добиться.
- MongoDB, как основное хранилище данных для java-приложения - либо виртуализация, либо контейнеризация, все зависит от реализации архитектуры приложения. Сложно дать вразумительный ответ - никогда не работал с данной БД, затрудняюсь обосновать выбор. Чувствую, что так будет правильно.
- Gitlab сервер для реализации CI/CD процессов и приватный (закрытый) Docker Registry - отдельный физический сервер или виртуализация, если сервер есть в наличии использовал бы его, но только необходимо оценить доступные объемы хранения данных, в том числе подумать о техническом сопровождении: просчитать затраты на поддержку железа и ЗИП. Если по совокупности поставленных задач будет понятно, что через осязаемое недалекое время мы выйдем за пределы мощностей физ. сервера, то выбрал бы, на перспективу, виртуализацию, однако возможны первичные затраты на доп. железо, но все зависит от проекта. Требуется пред проектная аналитика.
- Запустите первый контейнер из образа centos c любым тэгом в фоновом режиме, подключив папку
/dataиз текущей рабочей директории на хостовой машине в/dataконтейнера; - Запустите второй контейнер из образа debian в фоновом режиме, подключив папку
/dataиз текущей рабочей директории на хостовой машине в/dataконтейнера; - Подключитесь к первому контейнеру с помощью
docker execи создайте текстовый файл любого содержания в/data; - Добавьте еще один файл в папку
/dataна хостовой машине; - Подключитесь во второй контейнер и отобразите листинг и содержание файлов в
/dataконтейнера.
Ответ:
vagrant@server1:~$ docker run -d -v /data:/data centos sleep infinity
Unable to find image 'centos:latest' locally
latest: Pulling from library/centos
a1d0c7532777: Pull complete
Digest: sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c473f432b177
Status: Downloaded newer image for centos:latest
e9cf28d5df2578897da72159620abfefa35c2c00d8bc6068b5f784c511257260
vagrant@server1:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e9cf28d5df25 centos "sleep infinity" About a minute ago Up About a minute unruffled_bhaskara
vagrant@server1:~$ docker exec -it e9cf28d5df25 bash
[root@e9cf28d5df25 /]# ls -lah /
total 60K
drwxr-xr-x 1 root root 4.0K Sep 16 11:35 .
drwxr-xr-x 1 root root 4.0K Sep 16 11:35 ..
-rwxr-xr-x 1 root root 0 Sep 16 11:35 .dockerenv
lrwxrwxrwx 1 root root 7 Nov 3 2020 bin -> usr/bin
drwxr-xr-x 2 root root 4.0K Sep 16 11:35 data
drwxr-xr-x 5 root root 340 Sep 16 11:35 dev
drwxr-xr-x 1 root root 4.0K Sep 16 11:35 etc
drwxr-xr-x 2 root root 4.0K Nov 3 2020 home
lrwxrwxrwx 1 root root 7 Nov 3 2020 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Nov 3 2020 lib64 -> usr/lib64
drwx------ 2 root root 4.0K Sep 15 2021 lost+found
drwxr-xr-x 2 root root 4.0K Nov 3 2020 media
drwxr-xr-x 2 root root 4.0K Nov 3 2020 mnt
drwxr-xr-x 2 root root 4.0K Nov 3 2020 opt
dr-xr-xr-x 188 root root 0 Sep 16 11:35 proc
dr-xr-x--- 2 root root 4.0K Sep 15 2021 root
drwxr-xr-x 11 root root 4.0K Sep 15 2021 run
lrwxrwxrwx 1 root root 8 Nov 3 2020 sbin -> usr/sbin
drwxr-xr-x 2 root root 4.0K Nov 3 2020 srv
dr-xr-xr-x 13 root root 0 Sep 16 11:35 sys
drwxrwxrwt 7 root root 4.0K Sep 15 2021 tmp
drwxr-xr-x 12 root root 4.0K Sep 15 2021 usr
drwxr-xr-x 20 root root 4.0K Sep 15 2021 var
[root@e9cf28d5df25 /]#
debian:
vagrant@server1:~$ docker run -v /data:/data -d debian sleep infinity
Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
23858da423a6: Pull complete
Digest: sha256:3e82b1af33607aebaeb3641b75d6e80fd28d36e17993ef13708e9493e30e8ff9
Status: Downloaded newer image for debian:latest
2aaf49f49d25ea6629af62858f8156b9c732199c774754f5e8c0b2a7f94ae5eb
vagrant@server1:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2aaf49f49d25 debian "sleep infinity" 5 seconds ago Up 4 seconds tender_leakey
e9cf28d5df25 centos "sleep infinity" 5 minutes ago Up 5 minutes unruffled_bhaskara
c4bd1c8a1313 nginx "/docker-entrypoint.…" About an hour ago Up About an hour 0.0.0.0:80->80/tcp, :::80->80/tcp nginx-server
1c00ed4e50d3 nginx "/docker-entrypoint.…" 2 hours ago Up 2 hours 80/tcp musing_banzai
08aa6924c40b nginx "/docker-entrypoint.…" 3 hours ago Up 3 hours 80/tcp nginx_netology
vagrant@server1:~$ docker exec -it 2aaf49f49d25 bash
root@2aaf49f49d25:/# ls -lah /
total 76K
drwxr-xr-x 1 root root 4.0K Sep 16 11:41 .
drwxr-xr-x 1 root root 4.0K Sep 16 11:41 ..
-rwxr-xr-x 1 root root 0 Sep 16 11:41 .dockerenv
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 bin
drwxr-xr-x 2 root root 4.0K Sep 3 12:10 boot
drwxr-xr-x 2 root root 4.0K Sep 16 11:35 data
drwxr-xr-x 5 root root 340 Sep 16 11:41 dev
drwxr-xr-x 1 root root 4.0K Sep 16 11:41 etc
drwxr-xr-x 2 root root 4.0K Sep 3 12:10 home
drwxr-xr-x 8 root root 4.0K Sep 12 00:00 lib
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 lib64
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 media
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 mnt
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 opt
dr-xr-xr-x 190 root root 0 Sep 16 11:41 proc
drwx------ 2 root root 4.0K Sep 12 00:00 root
drwxr-xr-x 3 root root 4.0K Sep 12 00:00 run
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 sbin
drwxr-xr-x 2 root root 4.0K Sep 12 00:00 srv
dr-xr-xr-x 13 root root 0 Sep 16 11:41 sys
drwxrwxrwt 2 root root 4.0K Sep 12 00:00 tmp
drwxr-xr-x 11 root root 4.0K Sep 12 00:00 usr
drwxr-xr-x 11 root root 4.0K Sep 12 00:00 var
С контейнера под centos создаю в директории файл и файл с хоста
vagrant@server1:~$ docker exec -it e9cf28d5df25 bash
[root@e9cf28d5df25 /]# echo '' > /data/centos-file-1
[root@e9cf28d5df25 /]# ls /data
centos-file-1
[root@e9cf28d5df25 /]# echo '' > /data/fedora-host-file-2
[root@e9cf28d5df25 /]# ls /data
centos-file-1 fedora-host-file-2
[root@e9cf28d5df25 /]# exit
exit
vagrant@server1:~$ docker exec -it 2aaf49f49d25 bash
root@2aaf49f49d25:/# ls -lah /data
total 16K
drwxr-xr-x 2 root root 4.0K Sep 16 11:45 .
drwxr-xr-x 1 root root 4.0K Sep 16 11:41 ..
-rw-r--r-- 1 root root 1 Sep 16 11:44 centos-file-1
-rw-r--r-- 1 root root 1 Sep 16 11:45 fedora-host-file-2
root@2aaf49f49d25:/#
Воспроизвести практическую часть лекции самостоятельно.
Соберите Docker образ с Ansible, загрузите на Docker Hub и пришлите ссылку вместе с остальными ответами к задачам.
Выполненное домашнее задание пришлите ссылкой на .md-файл в вашем репозитории.
Домашнее задание к занятию "5.1. Введение в виртуализацию. Типы и функции гипервизоров. Обзор рынка вендоров и областей применения."
Опишите кратко, как вы поняли: в чем основное отличие полной (аппаратной) виртуализации, паравиртуализации и виртуализации на основе ОС.
Ответ:
Аппаратная (полная) виртуализация - Полная виртуализация аппаратного обеспечения сервера. В основе виртуализации лежит гипервизор. Он выполняет роль посредника между физическими устройствами сервера и их представлением в гостевой операционной системы. Полная эмуляция процессора, памяти и необходимых перифирийных устройств, в силу чего большие накладные расходы, что может выливаться в уменьшение производительности. Однако данные проблемы отчасти закрываются динамической трансляцией и реализацией аппаратной виртуализации Inet-VT, AMD-V.
Паравиртулизация - в том числе эмуляция работы устройств, однако гостевая ОС знает о наличии гипервизора, а выполнения привилегированных инструкций происходит через гипервизор, поэтому происходит серьезное изменение ядра гостевой ОС. В силу данной особенности подходит для ОС с открытым кодом, издержки меньше, производительность не особо страдает.
Виртуализация на основе ОС - виртуализирует физический сервер на уровне ОС, позволяя запускать изолированные виртуальные серверы называемые Виртуальные Частные Серверы или Контейнеры . При виртуализации на уровне операционной системы не существует отдельного слоя гипервизора. Вместо этого сама хостовая операционная система отвечает за разделение аппаратных ресурсов между несколькими виртуальными серверами и поддержку их независимости друг от друга. Виртуализация на уровне операционной системы имеет минимальные накладные расходы и обеспечивает самую высокую степень консолидации, однако эта технология не позволяет запускать ОС с ядрами, отличными от ядра базовой ОС.
Выберите один из вариантов использования организации физических серверов, в зависимости от условий использования.
Организация серверов:
- физические сервера,
- паравиртуализация,
- виртуализация уровня ОС.
Условия использования:
- Высоконагруженная база данных, чувствительная к отказу.
- Различные web-приложения.
- Windows системы для использования бухгалтерским отделом.
- Системы, выполняющие высокопроизводительные расчеты на GPU.
Опишите, почему вы выбрали к каждому целевому использованию такую организацию.
Ответ:
-
На физические сервера я бы выбрал системы, выполняющие высокопроизводительные расчеты на GPU. Так ка потребуется установка мощных графических процессоров для обработки данных. Хотя, графические интерфейсы в том, числе виртуализируются, однако предполагаю, что все таки физические решения для графических вычислений более производительны.
-
Паравиртуализацию я выбрал бы Windows системы для использования бухгалтерским отделом - системы для бухов не требуют от нас супер производительности и кол-во обращение более менее прогнозируемое и поддается подсчету. Виртуализация более масштабируемое решение, скорее всего можно сформировать единую точку управления.
-
Паравиртуализацию я бы выбрал различные web-приложения - Так как это web-приложения, то это значит, что будет достаточно много обращений к ним, как к сервису, поэтому нам в первую очередь необходимо обеспечить хорошую производительность и снизить накладные расходы. Данный способ так же позволяет утилизировать по максимуму хостовые ресурсы, управление контейнерами позволит нам упростить в принципе управление стеком веб приложений.
-
Bиртуализация уровня ОС я бы выбрал высоконагруженная база данных, чувствительная к отказу - базу данных можно рассматривать, как приложение (сервис), по моему мнению необходимо запаковать это в контейнер, создать несколько таких контейнеров, тем самым получить отказоустойчивый кластер, управление контейнером сводится к управлению процессом - быстро и без накладных расходов.
Выберите подходящую систему управления виртуализацией для предложенного сценария. Детально опишите ваш выбор.
Сценарии:
- 100 виртуальных машин на базе Linux и Windows, общие задачи, нет особых требований. Преимущественно Windows based инфраструктура, требуется реализация программных балансировщиков нагрузки, репликации данных и автоматизированного механизма создания резервных копий.
- Требуется наиболее производительное бесплатное open source решение для виртуализации небольшой (20-30 серверов) инфраструктуры на базе Linux и Windows виртуальных машин.
- Необходимо бесплатное, максимально совместимое и производительное решение для виртуализации Windows инфраструктуры.
- Необходимо рабочее окружение для тестирования программного продукта на нескольких дистрибутивах Linux.
Ответ:
-
VMWare. В рамках продуктов виртуализации и управления, решения от VMWare являются наиболее сбалансированными, имеют достаточно обширный функционал, который позволит закрыть вопросы по сопровождению и администрированию среды на 100 VM Windows, Linux.
-
KVM. Решение на базе KVM позволит управлять гостевыми ОС, как Windows, так и Linux, без особых потерь в производительности, что обеспечивает решение поставленной задачи. Проект развивающийся, это несет в себе риски, но ими можно пренебречь, так как производительность нас интересует в первую очередь.
-
XEN PV. Решение позволит поднять инфраструктуру на базе Windows OS, является open source проектом, обеспечит высокую производительность.
-
Virtual Box совместно с Vagrant. Для создания окружения для тестирования подойдет open source решение Virtual Box, с помощью Vagrant можно добиться автоматизации сборки такого окружения, при помощи Vagrantfile отдавать данное окружения всем, кто заинтересован, это позволит точно быть уверенным, что среда у всех единая.
Опишите возможные проблемы и недостатки гетерогенной среды виртуализации (использования нескольких систем управления виртуализацией одновременно) и что необходимо сделать для минимизации этих рисков и проблем. Если бы у вас был выбор, то создавали бы вы гетерогенную среду или нет? Мотивируйте ваш ответ примерами.
Ответ: Если приходится использовать гетерогенная среду, специфика поставленной задачи такова, что гетерогенная среда будет оправдана, и с точки зрения затрат, и с точки зрения управления, то тогда необходимо внедрять такое решение, но учитывать особенности - две или более точки управления виртуальными средами, это в свою очередь тянет за собой и необходимость привлекать более скиловый персонал, объем выполняемых работ увеличиться, потребуется разработка автоматизационных решений под обе среды, возможно это наложит существенные ограничения на выбор стека технологий по мониторингу, логированию и бекапированию или наоборот увеличит кол-во продуктов. В том числе значительно усложняется вопрос по реализации прозрачного процесса управления изменениями, то есть изменения, которые будут доставляться в одну среду, могут отличаться в смысле способа и метода доставки в другой среде. Для минимизации влияния всех описаных факторов, техническое решение должно быть проработано хорошо, задача отладки процессов управления сервисов в гетерогенной среде становиться крайне важна, в том числе для страховки необходимо будет прорабатывать детальный план DRP - disaster recovery plan. По моему личному мнению, гетерогенная среда виртуализации - требует определенного баланса между необходмиым и достаточным, необходимо отдавать себе отчет в том, какой стек технологий будет использоваться, и точно не стоит боятся, необходимо ответственно подходить к архитектуре решения.
Omukeev Mairambek Эти файлы будут проигнорированы в будущем 1 1
*/.terraform/
*.tfstate .tfstate.
crash.log crash.*.log
*.tfvars *.tfvars.json
override.tf override.tf.json *_override.tf *_override.tf.json
.terraformrc terraform.rc