00:00:00
этот ролик - это не видеолекция здесь мы
00:00:02
просто понятными словами рассмотрим те
00:00:04
термины которые идут Рука об руку со
00:00:06
словом девопс и вот кстати Первый из
00:00:09
них девопс часто называют подходом
00:00:13
методологией и всякими другими умными
00:00:15
словами и мы тоже Конечно можем сказать
00:00:17
что это методология которая объединяет
00:00:19
разрабов си админов и прочих тварей А
00:00:21
ещё мы можем сказать что она направлена
00:00:23
на автоматизацию всего и вся но по факту
00:00:26
в компаниях всё выглядит так что есть
00:00:27
допустим какой-то продукт Ну или там
00:00:29
приложение им занимается команда условно
00:00:32
10 разрабов п тестировщиков и о ПМ и
00:00:35
Например у них сидит прикрепленный
00:00:36
девопс и как это выглядит дальше Вот они
00:00:39
пишут своё приложение добавляют фичи там
00:00:41
кнопку на сайт или эту кнопку каким-то
00:00:43
правильным образом надо сделать и ничего
00:00:46
не поломать так вот занимается тем что
00:00:49
автоматизирует множество процессов и
00:00:51
смысл в том что из-за того что их раньше
00:00:53
делали руками накапливались ошибки изза
00:00:55
человеческого фактора Ну там что-то заб
00:00:58
мто вспомни счёт автоматизации которую
00:01:01
приносят псы человеческие ошибки
00:01:03
сводятся к минимуму плюс ему надо
00:01:05
сделать так чтобы всем было удобно
00:01:06
работать Что это значит То есть надо
00:01:08
чтобы у всех была единая среда не было
00:01:11
проблем типа у меня что-то работает а
00:01:13
вот на сервере не работает и ещё devops
00:01:16
может подружить между собой каждого
00:01:17
члена команды можно привести
00:01:19
какой-нибудь пример Аля ПМ не понимает
00:01:21
почему на какую-то маленькую кнопочку
00:01:23
уходит много времени и разработчик
00:01:25
пытается объяснить там тонкость
00:01:26
архитектуры баги но ПМ будет слышать
00:01:29
только сдела завтра там послезавтра и
00:01:31
так далее как будто человек просто
00:01:32
откладывает задачу а div способен ему
00:01:35
показать реальные цифры в дашборда
00:01:37
результаты тестов этапы пайплайн чтобы
00:01:39
ПМ наглядно видел Сколько шагов проходит
00:01:42
обновление и таким образом команда
00:01:44
просто находит общий язык и меньше
00:01:48
ссорится это буквосочетание можно
00:01:50
встретить всегда Когда речь идёт про
00:01:52
devops если сказать Попро простому то по
00:01:54
сути CCD - это как конвейер на заводе но
00:01:56
только для кода Давайте представим вот
00:01:59
есть у нас команда разработки это те же
00:02:00
10 разрабов Там пять тестировщиков и ПМ
00:02:03
с прикреплённым девопсом
00:02:05
какой-то разработчик Вася написал код
00:02:08
для новой кнопки и хочет добавить его в
00:02:10
проект вот что происходит Дальше без CCD
00:02:14
этот процесс выглядит вот так Вася залил
00:02:16
код никто не проверил вдруг этот код
00:02:18
ломает приложение на следующий день впт
00:02:20
вышла версия с багом все бегают и кричат
00:02:23
Кто сломал сайт а оказывается у Васи
00:02:25
например была опечатка которую никто не
00:02:26
заметил всё проблема на ровном месте в
00:02:30
то же время как этот процесс будет
00:02:31
выглядеть с C CD Вася заливает код в
00:02:33
репозиторий и автоматически запускается
00:02:35
Ci Ci переводится как Continuous
00:02:37
integration по нашему непрерывная
00:02:39
интеграция Что она делает автоматически
00:02:42
собирает проект прогоняет автотесты
00:02:44
проверяет качество кода и проверяет
00:02:46
какие-нибудь уязвимости и если что-то
00:02:48
идёт не так C сразу сообщает Вася ты на
00:02:50
нажал исправляй Если всё ок переходим к
00:02:54
CD это Continuous Delivery либо
00:02:56
Continuous deployment то есть
00:02:58
непрерывная доставка и или непрерывное
00:03:00
развёртывание то есть что здесь
00:03:02
происходит код автоматически
00:03:03
отправляется в тестовую среду а потом
00:03:05
отправляется в копию прода зачем это
00:03:08
сделано чтобы изменения не повлияли на
00:03:10
сам прод в случае ошибок но при этом
00:03:12
чтобы можно было потестить в реальных
00:03:14
условиях и после всех проверок после их
00:03:16
успешного прохождения он отправляется в
00:03:22
прод пайплайн - это по сути инструкция
00:03:25
которая описывает Как работает в icd
00:03:27
возвращаемся к нашему разраб Вася вот он
00:03:30
залил код и нажал кнопку запустить
00:03:31
pipeline и дальше Всё развивается по
00:03:33
следующему сценарию робот взял свежий
00:03:36
код Поставил все зависимости собрал
00:03:37
приложение запустил тесты проверил не на
00:03:40
говнокод ли Вася задеплоил в тестовую
00:03:42
среду запустил интеграционные тесты И
00:03:44
если всё ок то он плот в прот То есть
00:03:47
pipeline можно представить как чёткий
00:03:49
маршрут для вашего кода от компа до
00:03:51
сервера где сидят реальные пользователи
00:03:53
а Фишка пайплайн в том что это не просто
00:03:55
набор команд А это Визуальная штука и
00:03:58
все члены команды видят На каком сейчас
00:04:00
этапе находится код Какие шаги пройдены
00:04:02
успешно где всё поломалось И сколько
00:04:04
времени занял каждый
00:04:10
шаг сейчас сразу рассмотрим два понятия
00:04:13
которые всегда идут Рука об руку это Як
00:04:15
инфраструктура как код и config
00:04:18
менеджмент В чём смысл инф как код вот
00:04:21
мы devops инженер и мы просто пишем файл
00:04:23
вот такой вот как вы видите на экране
00:04:26
потом запускаем команду типа terraform
00:04:27
apply это просто один из инструмен
00:04:30
для или какой-нибудь аналог его и через
00:04:33
15 минут ВС наше окружение готово А
00:04:35
главное если нам понадобится сделать ещ
00:04:37
одну такое же мы просто поменяем пару
00:04:39
переменных и запустим снова То есть
00:04:41
фишка Як в том что вся инфраструктура
00:04:43
описана в коде который можно во-первых
00:04:45
положить в гит и сделать разные версии
00:04:47
например плюс его можно автоматически
00:04:49
проверить Ну например точно ли Мы
00:04:51
открываем нужный порт наружу Ну и
00:04:53
конечно его можно запустить хоть 100
00:04:55
хоть сся хоть миллион раз и получить
00:04:57
одинаковый результат а совершенно
00:05:00
спокойно может произойти ситуация Аля
00:05:02
пришёл новичок и говорит а как у нас
00:05:04
настроен прод сервер Да мы сами не знаем
00:05:06
а сак просто посмотри в репозитории там
00:05:08
точно описание всего версия OS все
00:05:11
пакеты настройки сети мониторинг короче
00:05:14
это гораздо проще ещё и для поддержки
00:05:16
потом
00:05:18
Туту ребят все кому сейчас интересно
00:05:21
переходите в нашу телегу Там мы очень
00:05:23
много материалов постим по девопсу
00:05:25
переходите читайте Подписывайтесь Если
00:05:27
вы видите свою карьеру в девопс этот
00:05:29
канал точно будет для вас полезен Всем
00:05:31
спасибо едем
00:05:35
дальше переходим конфиг менеджменту вот
00:05:38
мы развернули 10 новых серва ков с
00:05:40
помощью Як только они пустые и голые это
00:05:42
можно сравнить по сути с новой квартирой
00:05:44
без ремонта и мебели и дальше если у нас
00:05:46
например нет конфиг менеджмента то мы
00:05:49
вручную заходим на каждый сервер pss мы
00:05:51
вручную ставим все нужные пакеты мы
00:05:53
копируем конфиги откуда-то настраиваем
00:05:55
сетевые службы А через неделю первый
00:05:57
сервер начинает глючить потому что мы
00:05:59
забыли поставить какое-то важное
00:06:00
обновление а связка я и config
00:06:02
менеджмент работает следующим образом мы
00:06:05
также с помощью какого-нибудь я
00:06:06
инструмента Пусть это будет терраформ
00:06:08
создаём 10 серва ков А как только Они
00:06:11
созданы автоматически запускаем UN это
00:06:13
как раз уже инструмент конфиг
00:06:15
менеджмента и ставим всё что нам там
00:06:17
надо какой-нибудь инкс Там и так далее и
00:06:20
тому подобное все библиотеки все
00:06:22
зависимости и так далее прописали этот
00:06:24
Файлик прогнали и он запустился у на
00:06:26
сразу на всех севака которые мы только
00:06:28
что развернули
00:06:29
уб и главное автоматически не надо
00:06:31
заходить на каждый сервер делать что-то
00:06:33
руками так ещ и с вероятностью того что
00:06:36
можно что-то забыть и надо будет искать
00:06:38
проблему а представьте у вас не 10
00:06:40
серверов А 100 Это с ума можно сойти
00:06:42
каждый перепроверить настроить Ну то
00:06:44
есть это по сути невозможно А с конфиг
00:06:46
менеджментом один раз написали файл
00:06:48
автоматически запустили на всех серва
00:06:50
ках всё у вас 100 одинаковых серва
00:06:55
ков контейнеризация это понятие
00:07:00
самый простой пример который любят
00:07:02
приводить на всех курсах в интернете в
00:07:04
любых статьях это то что контейнеризация
00:07:06
- это как коробка со всем необходимым
00:07:08
для приложения внутри Но перед тем как
00:07:11
более подробно рассмотреть
00:07:12
контейнеризации Давайте разберём разницу
00:07:14
контейнеров и виртуалок вот нам надо
00:07:17
запустить приложение и у нас два
00:07:18
варианта Первый - это с виртуалкой то
00:07:20
есть мы берём физический сервак ставим
00:07:22
программу через которую создаются
00:07:24
виртуалки какой-нибудь
00:07:25
viral не суть создам виртуалку с
00:07:28
полноценной си
00:07:30
внутри этой системы ещё ставим всё
00:07:31
нужное по и только потом запускаем
00:07:33
приложение Ну то есть по сути это
00:07:35
реально создать целую полноценную
00:07:37
систему только для того чтобы запустить
00:07:38
какое-то одно приложение а если мы
00:07:40
используем контейнеры то мы берём тот же
00:07:42
самый физический сервак ставим туда
00:07:44
докер и запускаем контейнер который
00:07:46
содержит только само приложение и
00:07:48
минимум необходимых библиотек то есть
00:07:51
какие основные отличия виртуалки от
00:07:52
контейнера на виртуалке у вас
00:07:54
полноценная операционка там ядро
00:07:56
драйверы все службы и так далее
00:07:58
контейнер же использу ядро хостой
00:08:00
системы тут надо подумать но при этом он
00:08:03
имеет свои библиотеки и настройки Так
00:08:05
что же такой контейнер наверное уже
00:08:07
назрел Вопрос контейнер - это
00:08:10
стандартизированный пакет с приложением
00:08:12
и всем необходимым для его работы то
00:08:13
есть там библиотеки точных версий
00:08:15
зависимости конфигурационные файлы
00:08:17
переменное окружение ну ещё можно
00:08:19
сказать зачем нужны контейнеры вообще
00:08:21
изначально Первое - это изоляция
00:08:23
приложений Ну условно говоря нам надо
00:08:25
разные версии PHP на одном сервере на
00:08:27
виртуалке это реально ад создать Вторая
00:08:29
причина - это быстрое масштабирование
00:08:31
условно говоря если нагрузка быстро
00:08:33
возросла то нам бы без контейнеров
00:08:35
пришлось поднимать серваки и настраивать
00:08:36
их а с контейнерами мы просто запускаем
00:08:39
ещё пять штук за 10 секунд и всё у нас
00:08:40
классно работает Ну и конечно это про
00:08:42
эффективное использование ресурсов на
00:08:44
одном и том же сервере мы можем
00:08:46
развернуть Ну например пять виртуалок а
00:08:49
контейнеров 50 Ну сопоставимо
00:08:54
да микросервис - это слово которое можно
00:08:56
услышать не только в девопс его слышно и
00:08:58
в разработке там везде везде везде везде
00:09:01
по сути микросервис - это когда у нас
00:09:03
есть большое приложение и мы его разбили
00:09:04
на маленькие и главные независимые куски
00:09:07
нуно ещё когда говорят про микросервисы
00:09:09
конечно всегда вспоминают Монолит мы это
00:09:11
тоже вспомним на примере ситуации вот у
00:09:13
нас есть компания Рога и копыто и мы
00:09:15
разрабатываем приложение для заказа еды
00:09:17
Первое - это Монолит то есть что у нас
00:09:19
одно большое приложение которое делает
00:09:21
всё это там авторизация там каталог
00:09:24
корзина оплата доставка Короче всё-всё
00:09:26
всё что нам надо плюс у нас ещё все
00:09:27
разрабы пишут код в одно ме
00:09:30
одна огромная кодовая база и любое
00:09:32
изменение у нас требует перезапуска
00:09:33
всего приложения а микросервисной подход
00:09:36
- это когда у нас отдельный сервис и для
00:09:38
автоматизации и для каталога и для
00:09:39
корзины для оплаты для отслеживания если
00:09:41
мы меняем какую-то функцию в конкретном
00:09:44
сервисе перезапустить Надо только его
00:09:46
всё классно ничего останавливать не надо
00:09:48
А причём тут вообще микросервисы ИС вы
00:09:50
можете спросить а ответ на самом деле
00:09:52
прост для микросервисов идеальная
00:09:55
технология - это контейнеры То есть
00:09:57
микросервис - это аите решение а
00:10:00
контейнеры - это удобный способ это
00:10:01
решение реализовать а самая простая
00:10:03
аналогия которую можно привести на
00:10:05
микросервисы это Например у нас есть
00:10:07
магазин и всё подряд навалено просто в
00:10:10
центре зала все товары там и всякие
00:10:12
футбольные мчи какие-нибудь сетевые
00:10:14
фильтры там - Всё лежит в одном месте а
00:10:17
микросервис - это когда мы в магазине
00:10:19
сделали отделы вот у нас спорттовары вот
00:10:21
у нас Электроника вот у нас там ещё
00:10:23
чего-нибудь то есть по сути что мы
00:10:25
сделали мы взяли монолитный магазин и
00:10:27
распилили его на микросервисной
00:10:32
дела оркестрация - Это страшное слово
00:10:35
которое преследует всех преследует
00:10:37
девопс джуны это слово не любят но
00:10:40
разбираться в этом надо простым языком
00:10:42
оркестрация - Это когда у нас вот есть
00:10:43
много контейнеров и нам надо ими
00:10:45
управлять там запускать останавливать
00:10:48
перезапускать при сбои нагрузку
00:10:50
распределять масштабировать короче куча
00:10:52
всего надо делать с этими контейнерами и
00:10:54
тут Точно также мы рассмотрим на
00:10:56
банально примере вот у нас есть 10
00:10:58
микросервисов для этой доставки еды и
00:11:00
каждый у нас работает в своём контейнере
00:11:02
если у нас нет оркестрация то во-первых
00:11:04
нам надо вручную запускать каждый
00:11:06
контейнер следить чтобы если произошёл
00:11:08
сбой этот контейнер обязательно
00:11:10
перезапустил плюс мы ещё должны
00:11:11
прокинуть маршруты обязательно это то
00:11:14
что они должны слышать снаружи и как они
00:11:16
ещё между собой должны внутри общаться и
00:11:18
при любом масштабировании Нам всё это
00:11:20
Придётся делать вручную нагрузка выросла
00:11:22
и мы пошли руками запускать новые
00:11:24
контейнеры Ну естественно нормальный
00:11:26
человек так делать не будет Он возьмёт и
00:11:28
поставит оркестратор то есть что мы
00:11:30
делаем мы описываем в манифестах так
00:11:33
называемых это по сути просто файлы
00:11:35
настройки что мы хотим сделать То есть
00:11:37
какие контейнеры сколько копий и Какие
00:11:39
ресурсы им нужны А дальше оркестратор
00:11:41
уже сам решает где как это он будет
00:11:43
запускать если контейнер упал
00:11:45
оркестратор просто его автоматически сам
00:11:47
перезапустить если нагрузка начала расти
00:11:50
оркестратор сам автоматически будет
00:11:52
дополнительной копии поднимать опять же
00:11:54
если проводить аналогию это как будто мы
00:11:56
описали регламент того как должен
00:11:58
функционировать
00:12:00
назначили туда руководителя дали ему
00:12:02
этот регламент и дальше он сам уже
00:12:03
руководит отделом мы туда не лезем ВС у
00:12:05
нас работает хорошо Ну а ещё надо
00:12:08
сказать есть такая штука кубернетес
00:12:09
называется это самый популярный
00:12:11
оркестратор
00:12:14
Зачем вообще используется мониторинг Ну
00:12:17
самое банальное это видеть работает
00:12:18
сервис или нет сюда же к мониторингу
00:12:20
можно отнести артин То есть например мы
00:12:22
себе поставили уведомление Короче если
00:12:24
вот этот сервис у нас отвечает дольше 5
00:12:26
секунд мы отправляем уведомление Что
00:12:29
задыхается надо идти проверять Ну и
00:12:31
естественно мониторинг по сути нужен для
00:12:32
того чтобы просто предотвращать проблемы
00:12:34
мы видим все аномалии заранее мы можем
00:12:37
успеть сделать нужные вещи чтобы у нас
00:12:39
это не привело Никаким проблемам Ну и
00:12:41
мониторинг по сути состоит из трёх
00:12:43
основных компонентов первые - это
00:12:45
метрики и соответственно сбор метрик
00:12:47
Какие базовые метрики это вот нагрузка
00:12:49
проца памяти сетевой трафик время
00:12:52
отклика количество запросов ещё куча
00:12:55
куча всего насколько хватит фантазий и
00:12:57
метрики мы получаем двумя способами
00:12:59
во-первых это могут быть агенты То есть
00:13:01
это маленькие программки которые
00:13:02
собирают нужные нам метрики Либо мы эти
00:13:04
самые метрики вытягиваем напрямую из
00:13:06
приложений едем дальше И следующий
00:13:08
компонент мониторинга - это у нас
00:13:09
система Где хранятся данные То есть все
00:13:11
эти метрики собрали нам их надо где-то
00:13:13
хранить и дальше уже идёт визуализация
00:13:15
соответственно это красивые графики там
00:13:17
панельки чтобы и девопс и п могли одним
00:13:20
взглядом оценить состояние
00:13:23
системы последнее о чём мы сегодня
00:13:25
поговорим - это логирование на самом
00:13:27
деле Здесь ничего сложного нет это
00:13:28
просто просто процесс записи событий там
00:13:31
ошибок предупреждений Любой любой другой
00:13:33
текстовой информации о работе приложения
00:13:36
То есть если мониторинг нам показывает
00:13:38
как и насколько хорошо или насколько
00:13:40
плохо сервис живёт то логирование нам
00:13:42
показывает что конкретно происходит Ну а
00:13:45
нужно логирование в первую очередь для
00:13:46
отладки устранения ошибок например
00:13:48
приложение упало или просто начало себя
00:13:51
странно вести логи - Это первый источник
00:13:53
информации условно говоря в час дня у
00:13:55
нас сервис упал и выдал ошибку
00:13:56
подключения к базе посмотрели логи и там
00:13:59
видим хост базы недоступен Окей всё
00:14:01
стало понятно
00:14:02
Здорово а сейчас поговорим про то как же
00:14:05
это логирование всё-таки работает есть
00:14:07
уровни логирования Например у нас есть
00:14:09
эррор - это критические ошибки после
00:14:11
которых приложение может упасть У нас
00:14:13
есть ворнинг это предупреждение если
00:14:15
что-то идёт не очень хорошо но как бы
00:14:17
всё работает и есть инфо это просто
00:14:20
информационные сообщение о каких-то
00:14:22
обычных событиях там запуск остановка
00:14:25
запрос сделал и так далее ну и логично
00:14:28
что перед тем как ги смотреть нам их
00:14:29
надо как-то собрать и агрегировать
00:14:31
потому что в мире микросервисов и
00:14:32
контейнеров логов очень много и они
00:14:34
разбросаны по разным местам
00:14:36
соответственно нам нужно какое-то
00:14:37
приложение которое будет пылесосить все
00:14:39
эти места и затягивать логи в одно место
00:14:41
и уметь эти логи фильтровать там искать
00:14:43
строить графики на их основе и так далее
00:14:46
и самый популярный инструмент для этого
00:14:48
есть это так называемый елк СТК состоит
00:14:51
из трёх инструментов это elastic Search
00:14:53
это стаж И это кибана ну а дальше уже
00:14:55
происходит поиск и анализ этих самых
00:14:57
логов то есть нам надо уметь быстро их
00:14:59
искать по ключевым словам ошибкам датам
00:15:01
Ну а дальше мы уже просто строим
00:15:02
дашборды по этим логам это как раз-таки
00:15:04
та самая кибана про которую мы сказали
00:15:06
до этого и по этим дашборда уже смотрим
00:15:08
сколько ошибок было за час день неделю и
00:15:10
так далее Вы любите дашборды Яндекс
00:15:14
Яндекс а вот видос и Подошёл к концу
00:15:17
Если вам понравилось если вам интересно
00:15:18
Пожалуйста пишите в комменты пишите что
00:15:21
вы ещё хотите видеть какие темы Какие
00:15:22
ролики Какие термины и так далее и тому
00:15:24
подобное мы все эти комменты читаем Нам
00:15:27
очень приятно и очень полезно слышать
00:15:29
ваше мнение Всем спасибо большое за
00:15:31
просмотр всем пока-пока
