Transcription
Так. Привет. Меня зовут Андрей Фамин. Я преподаватель курсов линейки управления в OTUS. OTUS - это образовательная платформа, которая специализируется на обучении IT. Мы обучаем тех, кто создаёт будущее, помогаем профессионалам развиваться, а новичкам войти в индустрию. Компании доверяют нам обучения своих сотрудников, как индивидуальных специалистов, так и целых команд. Мы предлагаем широкую линейку IT-курсов на популярные и на узко специализированные темы по направлениям программирования, анализ и аналитика, инфраструктура, архитектура, Data Science, Game Def, управление IT-командами и другие. Здесь найдётся всё для Junior, middle и Senior специалистов. Курсы VOTUS - это онлайн-обучение, которое проходит в формате живых вебинаров, где опытные специалисты делятся собственными решениями реальных задач. Мы поддерживаем студентов на всём пути обучения. Наставники ежедневно ревьюят домашние задания и дают развёрнутую обратную связь. А непонятные вопросы всегда можно уточнить в учебном чате или задать преподавателю на занятия. Благодаря поддержки экспертов, у студентов получается осваивать даже сложные и очень сложные темы. Важная часть обучения - это проектная работа, в которой студенты реализуют полученные на курсе знания. И обычно она максимально приближена к реальным рабочим задачам. Поэтому выполненный проект пополнит ваше профессиональное портфолио и поможет при поиске новой работы либо при обсуждении повышения. По окончании обучения у студентов остаётся бессрочный доступ к материалам курса. Они всегда могут вернуться за вдохновением и новыми идеями. Тус - это лицензированная образовательная платформа. В окончании обучения мы выдаём студентам официальный документ, который подтвердит профессиональный рост. Это удостоверение о повышении квалификации или диплом о профессиональной переподготовке. Также сертификат о прохождения курса всегда доступен в личном кабинете студента на русском и английском языках. Наша миссия - развивать технологии, обучая их создателей. Каждым занятии, каждым проверенным домашним заданием или проектом, мы создаём настоящее и будущее образование. Мы видим это будущее в разработке качественных материалов и организации дружелюбного коммьюнити. Приглашаем вас разделить с нами этот путь.
Здравствуйте. Мм, добро пожаловать на открытый урок. Соответственно, по традиции пишем в чат, если всё хорошо. Минус: если плохо видно или плохо слышно или нужна какая-то помощь. Угу, вижу, всё хорошо, вижу плюсы. Вот я буду поглядывать на чат, если вдруг что я увижу пока что. А будем двигаться дальше. Представлюсь. Меня зовут Пётр Безденежных. Я fullstack-разработчик ээ с восьмилетним опытом, а работы, а дополнительно ещё 3 года стажа у меня DevOps инженером. Вот опыт, как раз-таки DevOps опытом. Сегодня я с вами буду делиться какими-то практиками, а вы можете видеть ээ мои контакты в Телеграме и почту. Озвучу правила сегодняшнего вебинара. Мм активное участие участие приветствуется. Мм, участие подразумевается вопросами в чате. Мм, я их вижу, но могу отвечать не сразу. Иногда какой-то блок текста закончу и потом поднимаю вопрос: "А есть ли какие-нибудь уточнения, вопросы и так далее?" Мм, запись вебинара участникам придёт на почту. А маршрут сегодняшнего вебинара следующий. А сейчас мы знакомимся, рассматриваем правила. А дальше мы начнём, а, погружаться в теорию сегодняшнего занятия. Оно ээ буквально говорит о том, в чём роль DevOps в разработке. Дальше перейдём к архитектурной составляющей. Мы рассмотрим структуру workflow, а, пайплайны. Вот, ээ, разберём некоторые практики. Мм, как-никак у нас best practices название открытого урока, так что куда ж без них. А чуть поближе познакомимся с курсом и в конце отрефлексируем наше сегодняшнее наш сегодняшний открытый урок. А давайте чуть ближе познакомимся. Напишите в чате, есть ли у вас опыт работы в DevOps. Кто был бы не против поделиться такой информацией? Угу. Мне это нужно, чтобы понимать, а нужно ли в некоторых местах, а, поглубже где-то останавливаться или, может быть, можно пройтись по верхам, по некоторым вещам, а, и так далее. Угу. Вижу, вижу. То есть лучше побольше м побольше теории, побольше оснований давать. Угу, вижу. Угу. Плюс 5 лет, да, лучше побольше. Понял. Хорошо. Вот. И небольшую обратную связь, чтобы понимать, на что ориентироваться. А с какой основной целью вы пришли сегодня? Может быть, там получить информацию или ещё что-нибудь. Прямо вот опишите, чтобы знать на на что мне ориентироваться в процессе. Угу. Вижу. Хотелось бы опыта разработчика, набраться информации, узнать новое, посмотреть, как профи делают, получить информацию, как делают другие. Хочется познакомиться с CI/CD, освоить направление, получить информацию. Здорово, да, это прямо всё попадает под то, что мы собирались сегодня делать. Отлично. Едем дальше. А, соответственно, CI/CD best practices. Цели вебинара. Я просматриваю на ваши ответы. Да. Писать докер-контейнеры. Да, да, вижу. Цели сегодняшнего вебинара. А, во-первых, к концу занятия вы сможете научиться разграничивать этапы CI, сборка, теста, как пример, и CD, то есть deploy в workflow. А вы сможете учитывать особенности архитектуры а вашего приложения или вашей организации, где вы работаете при построении CI/CD, а также э сможете применять практики теоретической части благодаря тому, что мы рассмотрим конкретные ситуации, где это было бы полезно. И, собственно говоря, всё это вместе нам нужно для того, чтобы, а, рассматривать CI/CD как способ автоматизировать процессы эффективно. И первая тема, которую мы затронем - это роль DevOps в разработке. Но прежде чем говорить о DevOps, давайте поймём, что такое DevOps. А я бы очень хотел бы послышать ваше представление об этом. Как вы считаете, что такое DevOps? Его уже раньше не было. Были сервера, были программы, интернет. Всё это существовало ещё до того, как DevOps появился. Ну как-то же без него жили. А раз он появился, то значит, ну зачем-то он был нужен. Зачем? Что это такое? Методология. Действительно, DevOps - это методология. Мм, но, наверное, какая-то особая методология. Философия и набор практик к организации процессов, да. Культура взаимодействия между разработчиками и Ops, да. Сбор по контроль на prod-специалист автоматизирующий процесс разработки. Действительно, DevOps - это ещё и DevOps-еры, конкретные люди. Всё правильно. Мы эту тему тоже затронем, что это конкретные люди. М чуть попозже. Э, здорово. Набор практик, инструментов. Всё здорово, да? Все ответы верные. И обобщая ответы, которые вы дали, можно прийти к некоторому интересному выводу. DevOps-ер - это тот, кто делает разраба счастливым. Объясню, почему. Потому что разрабы они такие существа, которые очень любят кодить. Они вот делают свои фичи, они фиксят баги. И вот вот они вот благодаря DevOps-еру и DevOps они могут заниматься только этим и не думать о сборки приложений, о том, что оно должно куда-то доставляться, о том, что оно должно как-то там тестироваться автоматически. Всё это уже снимается с плеч разраба. И, собственно говоря, если вы DevOps, то ваша миссия делать разраба счастливыми. И переходим к тому, как раз-таки к особенности национального DevOps, как я это называю. Да, вижу ваши ответы. Действительно, да. А особенности национального DevOps. Дело в том, что разные компании и работодатели могут по-разному представлять роль DevOps-ера и, соответственно, могут иметь э ожидания от вас, как от DevOps-ера. отличные от того, что от ваших ожиданий от себя, да, и тем более это может быть довольно-таки большими различия. И есть некоторые типичные кейсы, которые не совсем и не всегда, и, может быть, не только DevOps-ерские, но от вас могут ожидать. И полезно это проговорить. Например, а, типичный пример. Перенеси приложение, да, перенеси приложение в Docker. Вот оно у нас есть на bare metal решение какой-нибудь монолит висит, да? Перенеси это в Kubernetes или типичная вообще фраза хочу в облако да на луну хочу в облако вот и конечно можно наверное просто взять и такое же монолитное условно говоря облако какое-нибудь поднять и также монолитно туда всё бахнуть но это как будто бы ну не совсем то зачем нужен DevOps да значит нужно разбивать там микросервисы а этого опять текстное сотрудничество с кодом вот и ну или например сделай тесты чтобы в пайплайнах были, да и допиши их. Тоже типичный запрос. А бывает от DevOps-ера ждут, что вот он либо сможет написать тесты, либо что он их сможет перенести. А это не всегда вот то, что можно вот так вот с лёгкостью сделать, просто копипастом в какой-нибудь пайплайн. Просто потому что тесты бывают, например, интеграционные, и в интеграционных тестах нужно поднять окружение, типа базу данных там и так далее, да? А это уже не может требовать определённую разработку или классический ещё пример, у нас падает сборка, сделай, чтобы не падала. Казалось бы, классика DevOps, CI/CD, иди почини. А это может, а падать она может быть, например, из-за того, что, ну, разраб какой-нибудь, что-нибудь, какую-нибудь фичу криво написал и запушил. И вот билд не собрался, да? И казалось бы, причём здесь DevOps-ер? как бы идите к своим разрабам и объясните им, что они должны писать под хорошо. Вот просто некоторые вещи я затронул, чтобы вы понимали, что а то, что вы ожидаете от себя или от DevOps-ера, может, в принципе отличаться от того, что ваш работодатель или наниматель, если вы фрилансер, может вас ожидать. Это довольно-таки интересный опыт с опытом приходит со временем. Так, готов ваши вопросы посмотреть и уточнения. То есть размыты границы между DevOps, SRE и разрабом. Да, да, совершенно верно. А казалось бы, в теории они не размытые. Есть конкретное определение, что такое DevOps, что такое SRE, что такое разраб, да? А на практике мы имеем то, что, ну, кто-то как-то где-то что-то делает, и дай бог, если оно хотя бы есть каждый из этих веток специалистов, а то оно ещё и перемешано. Может быть, одновременно DevOps и разраб. Я, например, на стартапе на одном работал. меня как фрилансера фрилансера пригласили, и вот я там был DevOps-ер, разраб. Благо, опыт fullstack позволял мне это делать. Ну вот в чём отличие от SRE, а оно довольно тонкое и опять же от места к месту разница. Ну, условно говоря, условно говоря, а вот в одной из мм компаний, где я ээ сотрудничал, куда меня нанимали, SRE-шники были скорее как команда быстрого реагирования. То есть, а, в моменте, если что-то где-то упало, срочно починить или rollback-нуть, если что-то поломалось, да? Вот в то время как DevOps он скорее на предупреждение работает. Как бы, когда ты DevOps-ер, ты пишешь пайплайны и ты пишешь бэк-кейсы, что если что бэкролишь, да, ролбекишь ээ случаи и всё. Вот. А мм ссылочку на курс киньте, плиз, который тут будет рекламиться. А, да, обязательно. Это всё будет, это всё будет. Так, нам нужно двигаться дальше. У нас ограниченное время. Спасибо за вопросы. Может быть, у нас в конце ещё время останется. Я ещё поотвечаю. Переходим к следующей теме. Отсюда, ну, отсюда следует, что DevOps проще стать, если есть опыт разработчика или sysadmin. Да, да, это верное утверждение. По крайней мере, на моём опыте это часто так наблюдается. Структура workflow, да? Workflow, как некоторые процессы состоит из пайплайнов, да? То есть, а пайплайн - это автоматизированный процесс, состоящий из последовательности шагов, которые где-нибудь, неважно где, в GitHub, в GitLab, выполняются для сборки, тестирования, доставки кода и прочих целей, да? То есть это некоторый процесс, который мы захотели автоматизировать, и где-то он там в другом месте а выполняется. А, соответственно, раз пайплайн - это процесс, то логично, что есть триггер, что-то, что вызывает этот процесс. Есть, ну, начало процесса, он начинается и как-то он там заканчивается, да? Разберём с вами основы, потому что, а, мы сможем пройти некоторый эволюционный путь сейчас вместе и потом сверху, пройдя его, а, составить некоторые вопросы, на которые полезно ответить, когда работаешь с пайплайном. Вот. Тем более я видел, что не все имеют опыт в DevOps пришедшей. Думаю, это будет полезно. Так вот, продолжаю. Каждый процесс имеет триггер, что его запустило. Начало и конец. Начинаем развивать идею. Если есть конец, то конец может быть хорошим или плохим. А, ну хорошим концом может быть. Например, всё собралось, залились релизы, и у нас лежит где-то там для пользователей доступный для скачивания, а рабочий м наш продукт айтишный. Супер. Ну или что-то где-то сфейлилось, да. Это нехороший конец. Продолжаем. Если у нас есть начало, значит, у нас может быть какая-то предобработка начала. Объясню. А прежде чем делать билды, которые зачастую бывают довольно на нагру с высокой нагрузкой и длительные операции, а может иметь смысл сделать что-нибудь, ну, типа линтинг, да, то есть проверить синтаксис кода, то есть до того, как вообще даже начинать билдить, проверить, не поставил ли где-нибудь лишнюю запятую какой-нибудь неродивый кодер. Да, мы их будем иногда ругать, как DevOps-еры. Вот. Э-э, и, соответственно, предобработка джобсы - это конкретные шаги в процессе, которые выполняется, да, продолжаем развивать идею, что если у нас есть предобработка, значит, может быть и постобработка, да? То есть мы получаем, что, а, причём постобработка может быть как общая, вне зависимости от того, как оно закончилось, хорошо или плохо, так и уникальное для каждого, например, плохого конца. В случае разных плохих концов разная обработка или в случае хороших. Пример, а если у нас начал билдиться продакшн, что очень важно, но не сбилдился или сбилдился там наполовину, да? Например, куда-нибудь там образы улетели куда-нибудь в регистры уже начали меняться, но где-то что-то пошло не так и поломалось. Было бы неплохо, если бы разрабы или вы как DevOps-ер об этом как можно скорее узнали. И можно какой-нибудь там, а, вебхук повесить обработчик, который в случае, если сфейлился, а, пайплайн продакшена вас в Телеграме оповестил. Ну, или как вам захотелось, не суть важно. Соответственно, постобработка. Коротко о самих джобсах, то есть некоторых вот этих шагах, которые могут в процессе выполняться. Это может быть тестирование, это может быть докеризация, это может быть билд приложения, публикация, тогда это уже не CD, да? То есть доставка приложения, это может быть генерация документации, что, кстати, является хорошим таким юзкейсом. Аэ, генеративная документация по коду. Ну, куберизация приложения, очевидно, после докеризации. Это может быть какой-нибудь там Helm-чарт и так далее. Мм, соответственно, берём нашу логику, которую мы рассмотрели, и теперь мы можем её размножить в том смысле, что пайплайн может быть не один. Один пайплайн, который, например, э реагирует на ветку dev в репозитории, и благодаря чему оно там проходит свои какие-то там шаги, как-то предобрабатывается, посторабатывается и улетает в dev-test, да, и у нас dev разворачивается. И отдельный пайплайн для prod, который, например, реагирует только на pull requests, для того, чтобы какой-нибудь шальной коммит в prod какой-нибудь там, не знаю, пришёл джун и вот взял и с дуру запушил в prod что-то. Вот, чтобы ничего не поломалось, то реагируем только на pull requests принятые. Вот. И мы имеем совершенно множество пайплайнов, которые могут быть у нас в обработке. И GitOps. Осторожно, спойлеры, спойлеры того, что будет у нас внутри курса, а и которому посвящён этот открытый урок. Потому что не только пайплайнов может быть у нас множество, у нас может быть больше одного репозитория. Более того, это нужно делать. Например, один репозиторий. Часто будем сталкиваться на занятиях, что у нас будет два репозитория. Один репозиторий с приложением каким-нибудь, а, в котором билдится приложение, тестится, да-да-да-да-та, докеризируется, Docker образ, собирается, пушится куда-нибудь в каком-нибудь регистре и отдельный репозиторий с манифестами, в который во второй репозитории пушится а изменения манифестов. То есть первый репозиторий триггерит изменения во втором репозитории, а изменение второго репозитория уже подтягивает какой-нибудь, ну, не знаю, Argo CD, например, да, который, а, в Kubernetes подтягивает манифесты и запускает их. Вот. Но это всё спойлеры, спойлеры. Более подробно это всё будет рассмотрено у нас на курсе. Надеюсь, вас там увидит, кстати говоря. И пайплайны их структура описывается чаще всего конфигурациями, да? И вот маленький отрывочек, пример из манифеста, где мы можем посмотреть на триггер. Мы буквально описываем, что он push branches main, то есть когда кто-то что-то запушил в main или на pull request branches main. То есть когда кто-то что-то запушил в main или когда кто-то а запулил что-то в main, то тогда мы запускаем этот пайплайн, да, и jobs и идёт перечисление джобсов, то есть шагов, которые должны быть выполнены. В данном случае шаг lint and test, буквально проверить синтаксис и протестировать приложение. И подходим к концу. Я понимаю, много было дано информации, скоро перейдём к к к диалогу, но сначала подведём итог. А вопросы для разработки CI/CD. А когда мы приступаем к работе над CI/CD, полезно задаться следующими вопросами: а что является основным процессом? Например, основным процессом является билд а мобильного приложения. И в целом, как конечный продукт - это мобильное приложение. Соответственно, мы это рассматриваем как точку, главную точку, и начинаем от неё исходить. Что, а что является предобработкой может быть туда отнесено? Например, если у нас мобильное приложение, оно может быть на основе веб-приложения и с помощью какого-нибудь, если это JS, с помощью какого-нибудь Capacitor упаковано в мобильное приложение, да? То есть предработкой будет build сборка веб-приложения. Третий вопрос, какую постобработку необходимо сделать? То есть с другой стороны для этого основного процесса, что будет постобработкой, причём в случае провала или успеха? И какие процессы ещё существуют, но пока не вытащены в джобсы. То есть, может быть, например, существуют тесты, да, но они существуют в коде. То есть там программисты сами нажимают там какой-нибудь npm run test, и тесты запустились. Тесты есть, но они не в CI. Вынести их в CI можно. Или, допустим, наоборот, они есть в CI, но это build and test, то есть там она и билдится, и тестится в одном джобсе. Это нехорошо. Желательно бы разделять логические отдельные конструкции, такие как build, тестирование, сборка, докеризация в каждый отдельный jobsstep отдельно. Вот это м вопросы, которые полезно задавать каждый раз, когда вы сталкиваетесь с разработкой CI/CD. Я готов смотреть ваши вопросы и уточнения. Пайпы хранить централизовано же можно, чтобы пайп брал по ветке, шаблоны из репы с шаблонами. Да, пайпы хранить централизовано можно. А, всё верно. А GitHub Actions можно указать вообще другую репу, откуда брать инструмент для джобы, но не конкретный пайплайн. Всё верно. Да, действительно, так. А, и если есть ещё какие-то вопросы с ходу, готов сейчас ещё посмотреть. Вы их напишите, я к ним вернусь и пока продолжу. А, вижу какой-то вопрос. Настроил себе CI/CD на GitLab. Так, с GitLab я, к сожалению, не работал, но, может быть, смогу подсказать что-нибудь абстрактное. Установил на удалённый VPS-сервер. Понятно. Приложение тоже в Docker. Docker in Docker. Это тру или зашквар? Ходят слухи, что Docker in Docker - это зашквар, но в условиях CI как будто бы не сильно есть большие большой выбор, что с этим можно сделать, да? А, но иногда бывают моменты, как этого можно избежать. Например, зависимые контейнеры. Знаю, что, например, а в, насколько я помню, и в GitHub, и в GitLab есть возможности для, а, степа или джобы, да, указать, что вот ты вот работаешь вот в контейнере Ubuntu, но подними ещё вот такие-то контейнеры вместе с этим и их использовать для окружения. И зачастую это помогает избежать паттерна Docker and Docker. Так, отвечает ли DevOps за тестирование репозитории со скриптами Bash, написанными DevOps-ом? А DevOps может отвечать за это. По идее тестировщики существуют для того, чтобы писать тесты, но, например, тестировщиков может не быть в команде, но есть DevOps-ер, который что-то может сделать на Bash или на чём-нибудь, и тогда это делает. Это, ну, реальность такова, мы с этим сталкиваемся. Вот. А та-та-та-тата. Docker Docker полезны для сборки. Да, да, да, да. А какая зарплата минимальная, средняя, максимальная DevOps специалиста в Москве? А не слежу в последнее время за этим в Москве, но м зарплата у айтишников в целом, не только у DevOps-еров, штука крайне неоднозначная. И разброс очень большой. И тут скорее зависит от того, насколько хорошо ты сможешь себя позиционировать и насколько хорошо сможешь себя продать. И сколь насколько много готовы платить. Так, я должен идти дальше. Спасибо за вопросы. Дальше потом, если что, продолжим, вернёмся. Переходим к практикам. Аэ практика - это использование артефактов. Артефакты - это что-то, что мы хотим сохранить между шагами внутри одного пайплайна. Это могут быть, например, какие-то бинарники, которые мы собрали в процессе. Это могут быть зависимости, а modules в JavaScript-овых проектах в Python-овых проектов и так далее. Это могут быть образы с помощью команды docker save. Кстати, сам довольно долгое время я не пользовался этим не знал, что Docker образ можно сохранить в tar архиве, а, и передать в следующий пайплайн. Ну, если кому-то зачем-то это надо. А так вообще Docker-образы лучше, конечно, отправлять куда-нибудь какие-нибудь внешние регистры. Вот. И там это дело хранить и обрабатывать. Ну и в целом любые результаты каких-то длительных процессов. Мы упаковываем файлики, ээ, и как артефакты передаём следующим шагам, чтобы там это выполнялось. Кэширование. Кэширование - это тоже хороший паттерн, который полезно применять, но с кэшированием нужно быть очень осторожным. А сначала примеры, что можно кэшировать. Это, например, те же самые зависимости Node Modules а или venv. Мм, ну, например, если, ээм, было был у нас пайплайн для сборки приложения, он отработал всё хорошо, а потом программист взял и, мм, изменил какие-нибудь там мм настройки репозитория, да, и закомитил это и запушил. Настройки репозитория, скорее всего, ну, не влияют на сборку, а значит, на мы сможем сократить время и ресурсы вычислительные, а, м, у пайплайна, который просто подгрузит Node Modules или билды с прошлого вообще с прошлого пайплайна, с прошлого запуска, с прошлого коммита. Вот. Э, интересный момент, слои образов можно кэшировать. Это для меня тоже было определённое открытие некоторое время назад, что м какие-то общие популярные слои образов между сессиями, между пайплайнами можно кешировать и тем самым сохранять время. Но вот важный момент, который нужно учесть при работе с кэшем, любым кэшем, не только в пайплайнах, это нужно следить за его размером, чтобы он не переполнился, например, и не съел всё ваше свободное место, особенно если оно ограничено, и очень точно настраивать валидацию. А вот я сейчас рассказал про пример, да, с ребилдом и зависимостями, да, что если, например, зависимости не поменялись у проекта, то, соответственно, можно его не перебилживать. И таким образом мы при коммите берём старый билд. И это может подставить вас, потому что а программист мог не менять сами зависимости, да, но изменить настройки билда, конфигурацию билда. И таким образом, а а если кэш у нас его валидация типа нужен, не нужен, настроен только на зависимости, то тогда мы получим ту ситуацию, что мы изменили правила билда, коммит улетел, а, но билд взялся старый, хотя не должен был. Он должен был перебиться, перебиться, потому что мы конфигурацию билда поменяли. Вот тестирование очень хороший паттерн, который желательно всегда выносить в CI. И если у вас его нету в CI и вообще нету тестов, постарайтесь сделать так, чтобы они у вас появились. Сходите на поклон к э программистам, а лучше к начальнику, а лучше к своему начальнику, чтобы он пошёл к начальнику программистов, и чтобы как-то, чтобы появились тесты. Это очень важно, очень полезно. Супер, супер. Всем рекомендую. Тесты - это хорошо. А многоступенчатые Docker-образы, мм, это Docker сборки. Это тоже интересный паттерн, а, который позволяет экономить, а, как время билда. А, ну это не столько важно, как даже, может быть, и не время билда, а размер итогового образа. Docker буквально кратно может сохранять, когда мы, например, билдим приложение в одном контейнере, в одном а образе, а запускаем его уже в в другом. Rollback. Не забывайте про rollback. Э-э, если вы делаете какую-нибудь доставку или вы делаете какую-нибудь сборку, обязательно пишите сценарии, что нужно сделать, если произошёл фейл того-то. Например, если вы у вас билд Docker образа, да, и вы потом делаете пуш, а и после пуша вы, например, после пуша Docker образа вы хотите этот Docker образ применить на проде, но применение на проде сломалось, да? То есть пайплайн сломался, но образ-то уже запушился, и у него могли уже лейблы, например, поменяться. И для того, что если вдруг сервер prod рестартует из-за чего-то, он может подтянуть уже новый билд, новый образ, который может быть некорректным. Соответственно, нам нужно rollback сценарий, если Docker образ запушился в регистре, но потом оттуда не применился. Мы должны это обязательно откатить. То есть rollback-и наши всё, не забывайте про них. Это очень важно. А ещё больше различных практик мы рассмотрим на курсе, на занятиях. Э там буквально будет рассматриваться, почему это GitOps. То есть Git как источник истины, на который мы опираемся, которому мы верим и из которого исходит всё. Будет рассмотрен Kubernetes как среда очень удобная для GitOps и Argo CD как инструмент, аа реализации GitOps подхода методологии с pull со своим pull механикой подтягивания из репозитория данных и многое-многое другое. Всё будет у нас на курсе. Сейчас мы я просто не смогу охватить всё, что можно рассказать. Немножечко момент для для дискутирования. Что насчёт того, чтобы использовать искусственный интеллект в CI? Это не то, что я видел где-то, не то, что я могу вам посоветовать, как best practice, но это вопрос, который было бы мне интересно, например, с вами обсудить. Представьте себе, что программисты пишут какие-то свои фичи, они делают pull requests куда-нибудь в main, да, чтобы это появилось. И в процессе пайплайна там собирается тесты, проходятся, бла-бла-бла, и
На одном из этапов берётся неронка. Она смотрит документацию проекта, она смотрит gitlog, изменение, что было изменено, да, в файлах, и делает кодрев, как как делают программисты. И на основании кодрев оно либо пускает дальше в работу код, либо не пускает и даёт на доработку. Как вы думаете, насколько это применимо или интересно ли было бы такое попробовать внедрить?
Так, ээ, придётся или Лем разворачивать и рак подключать. Сложно, но можно. Применимо, но не работает. Парадоксальность наше. Всё, действительно придётся лилем разворачивать, если не использовать какие-нибудь внешние нейронки. Да, ведь всё-таки хоть это может быть в как с точки зрения наверное secюрити antipatternтер, да, то есть использовать внешние сервисы, да, но с другой стороны вот я сколько знаю больших компаний и во всех них программисты используют нейронки тот же Sonet, да, или ГРОГ, они подключают и прямо просто туда загружают код свой Legacy, вот этот самый, который коммерческая тайна и всё прочее, и с ним работают и и молча все соглашаются. и делают это, да? То есть формально по идее использование тогда нейронки вся не сильно хуже, чем то, что и так делают программисты.
Угу. Нет, не есть хорошо. Большинство атак в на CCD вроде идёт с одной стороны, да. Но о'кей. Спасибо вам за обсуждение этой темы. К вопросам чуть позже вернусь.
М, хотя бы давайте прямо сейчас, прежде чем переходить к спойлеру занятий, я ещё посмотрю ваши вопросы. А так так так. Есть ещё одно решение. Канико, это инструмент, написанный нагон. Собирает образы контейнеров из dockerфайл без docker. М, интересно, надо будет глянуть. А, так, как улучшить валидацию для кэширования? Заставлять прогеров лучше описывать каждый комит. как улучшить валидацию для кширования. Скорее тут придётся вам, как девопсеру, понять, а как это работает. Вам нужно будет пойти и поговорить с программистами на тему того, а что это вообще за штука и как вы её собираете. А почему вы её собираете именно так? Вот я, например, описал одинкейс, да, когда кэширование было завязано на ээ зависимости, а программист поменял конфигурацию билда и и в итоге из-за этого мы получили фейл. А потому что нужно учитывать конфигурацию билда в валидации кэша. Так что это и только вместе с программистами обсуждать по-друго. Либо самому сидеть разбираться с нейронками, скидывать кучу кода и говорить: "Объясни мне, почему это именно так?" Да и тысячу зависимости понимать. Ну а куда деваться? Тяжела доля девопсера, но вроде как и платят тоже неплохо.
Так, хорошо. М, перейдём к мм спойлерам, к девятнадцатому занятию. Аа сегодняшний открытый урок, он сделан на основе девятнадцатого занятия, на котором мы с вами встретимся, я очень надеюсь. И в спойлерах я сейчас покажу вам немножко кода, немножко расскажу логику того, как что и как а у нас на занятии. А так так так секундочку, я нажму демонстрировать экран, изменить скрин. Я хочу демонстрировать весь скрин. Так. Хочу вот это демонстрировать. Так, напишите в чат, появился ли код, пожалуйста. Минус, минус, минус. Так, давайте посмотрим сейчас. Тогда я попробую ещё раз. Старт share. Секундочку. Скрин. Вот так вот выбрать первый скринше. Почему-то так шерин экрана не включается. Так, сделаем по-другому. Угу. Написано is sharing your screen. То есть, по идее, share скрина должен был заработать. Так, минус. М. А если я сейчас нажму вот это remove и добавить? Вот так вот. Хорошо, я попробую share window сделать. Тут платформа почему-то подтормаживает. Не знаю, почему так попробую выключить видеокамеру и включить трансляцию. Может быть, так заработает. Сижу на Макус. Так, секундочку, сейчас отпишу о технической проблеме. Так. Попробую обновить страницу. А вот и снова я. И вот она у меня показывает, предлагает зашерить скрин. Вот я ему говорю: "Показывай скрин". Аа так, смотрю чат, пока вебка. А если вот так по идее должен был начаться? Я сделал теперь не экран, а конкретное приложение, чтобы он курсор за Понятно. Мм, что-то в платформе не работает. Давайте тогда, а, перейдём к другу, к следующей, к следующему моменту. Это мы идём к демонстрации. Э, спойлеры мы проматываем. Никаких спойлеров. Мы ещё не закончили, но уже сейчас вы можете заполнить опрос о нашем занятии. Я вам сейчас скину ссылку на опрос. И попрошу вас его заполнить. Было бы очень здорово. Скину его в чат. Вот. И переходим дальше.
Мм, расскажу вам побольше о курсе. Я помню, были вопросы о курсе, о том, что там и как. А-а, значит, мы видим сейчас вырезку с, э, страницы курса, буквально автоматизировать управление инфраструктурой и приложениями. А вот здесь мы видим программу курса. В самом начале будет рассматриваться основы Kubernates, а это будет значит основные сущности, которые в нём есть. А-а, как пример, мы будем рассматривать, а, миниbe от докера, чтобы локально запускать Kubernate. Вот. Дальше рассмотрим введение в методологию GitOPS. Почему GitOPS именно Git Ops называется? А какие он предлагает инструменты? Я часть из них уже затрагивал, например, тот же ARGOC CD. А развёртывание инфраструктуры GOPS. А и в самом конце будет проектная работа, которую вы сможете использовать, а, в своём портфолио. А расскажу о преподавателях, мм, о себе я уже немножко рассказал в самом начале, мм, и о своём опыте. Вот Андрей Вилков, а, руководитель нашего курса. У него шикарный опыт, причём опыт, э, преимущественного девопсера. Мм, в то время как у меня в основном, конечно же, это всё-таки ФСЕК разработчик. А, он участвует в проектах компании Craftway, автоматизирует кучу всего, а, и очень интересно и последовательно ведёт лекции. Соответственно, а с нами обоими вы ещё встретитесь у нас на курсах. А обучение US а проходит в живом формате вебинаров, точно так же, как сегодня. А нетворкинг, а это определённо бонус, потому что вы сможете, а задавать вопросы как друг другу, как будучи специалистами, так и преподавателям. Все записи и материалы сохраняются в личном кабинете навсегда, что очень удобно. Проект, который вы выполните, поможет вам расширить ваше портфолио. Программа обучения на курсах обновляется каждый запуск. Соответственно, а мы поддерживаем актуальность а методик, инструментов, которые мы передаём. Вот. Ты по каждому домашнему изданию преподавать преподаватель даёт развёрнутый фидбэк, чтобы это было не просто там сделай то-то и всё, ты там в итоге вы там сделали или не сделали, как бы, ну нет, на мы подходим к вопросу серьёзно и даём обратную связь. А о курсе, значит, QR-код с информацией об этом. Старт обучения тридцатого числа. Вот длительность 3 месяца.
Подведём итоги занятия. Мы с вами рассмотрели, а, этапы C, мы рассмотрели архитектуру, как его правильно строить, какие вопросы задавать, рассмотрели практики и особенности, которые, которым лучше придерживаться, когда мы формируем CCD, и конкретные, мм, которые могут быть полезными, как положительные, так и отрицательные юзкейсы. Всё это нам нужно для того, чтобы понимать, как строить CCD, как автоматизировать эффективно. Давайте под конец ещё сделаем небольшую проверку. Я буквально пару вопросов, чтобы закрепить, как-то освежить то, что мы говорили в самом начале. Первое - это назовите вопросы, на которые надо ответить, чтобы построить качественный workкфлоу. Сколько вспомните? А про CD часть сегодня будет А мы затронули часть CD, но основная часть CD, то есть, э, Delivery, у нас рассматривается на курсе, потому что это напрямую касается именно углублённых практик, именно доставка в берnй. И я, наверное, мог бы вам и об этом сегодня рассказать, но, к сожалению, у нас ограниченное время, да, и просто Да, спасибо большое за вопрос. Ну а, пожалуйста, назовите вопросы, которые вы помните, из теоретической части, какие вопросы нужно задать, чтобы построить качественный workflow. Что является основным процессом? Супер. Это то, с чего стоит начинать, действительно. А как собираем, как тестируем, как начинаем, как деплом и откатываем? Да, верно. Это действительно то, что Да, да, да, да, да. Ну и по также, если отталкиваться от основного процесса, что является предобработкой и постобработкой. Ну и второй вопрос. А какие инструменты работы CCD мы сегодня рассмотрели? Что запомнилось? Так. Что-нибудь запомнилось? Было logo GitLab на одном из слайдов. Действительно, CD в Гитлабе существует. Это правда. Хорошо. М, двигаемся дальше. Собственно говоря, мы уже подходим к концу. М следующий открытый урок у нас будет восемнадцатого числа. Повторюсь, старт обучения тридцатого числа, а QR-код, по которому сможете получить дополнительную информацию. Присоединяйтесь к Telegram-каналу OTUS IT News. А, буквально там публикуется анонс открытых уроков, какие-то советы от экспертов, э, интересные темы поднимаются нашими специалистами, обсуждения. Вот. И ещё раз напомню, пожалуйста, заполните опрос о мероприятии. Это нам нам будет очень приятно и полезно ээ получить обратную связь, чтобы мы могли становиться лучше. Мы читаем все ваши сообщения и берём их в работу. Собственно говоря, спасибо. Приходите учиться в тус. На этом на сегодня всё. А если есть какие-то ещё вопросы, у нас осталось немножко времени для того, чтобы я ещё чуть-чуть поотвечал. И вам спасибо, Сергей. Вопрос по теории выше. Так, э, был бы благодарен, если если вы скопируете его ещё раз, чтобы я не искал. Вот. Да, я пока что преподаю только на этом курсе. Мм, задумываюсь о том, чтобы, а, принять участие в курсах по разработке, потому что всё-таки основной мой стаж рабочий - это, аэ, м, разраб. Я прямо разраб лет опыта. Восемь - это потому что самый этот самый техничный опыт. Но в целом я начинал уже 10 лет у меня опыта. Так, а вопрос. На курсе учат только инструментом без теории по по OS Linux. А, да, конкретно на этом курсе теория по OS Linux, если и будет, то очень поверхностно и быстро. А основной упор делается именно на Kubernates в начале как основная среда, в которой будет работа. Потом рассматривается методология Гитопса и то, как она реализуется через те или иные инструменты. Конкретно на OS Linux акценты ставиться практически не будут. И вообще теории, а, и базы нет. А теория есть. Но теория концентрируется на вопросах гитопса и на на вопросахбернейса. Это как, ну, и C, очевидно, CCD, как то, что я, например, сегодня рассказал на базе девятнадцатого урока. У меня сегодня открытый урок. И вам спасибо. Что же, на этом всё. Тогда всем хорошего вечера, доброй ночи. Спасибо за то, что пришли. Приходите к нам учиться, будем вас ждать. Спасибо, Михаил. Всем до свидания.