Цель:Получить вводные знания по DevOps, ознакомится с методологией и основными определениями.
DevOps инженер - такую вакансию часто можно встретить на сайтах по поиску работы. На различных технических ресурсах постоянно обсуждаются облака, инфраструктура, деплой(развертывание) приложений. Поэтому может сложиться ощущение, что DevOps - это технология, которая позволяет деплоить приложения.
Но это не совсем верно. DevOps это не технология и не язык программирования. Сам по себе DevOps это методология разработки программного обеспечения.
Основные определения:
development and operations) - методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта.deploy) - развертывание, - помещение исполняемого кода на сервер, где он будет работать.build) - процесс сборки и/или компиляции программного продуктаsandbox), которая используется для тестирования приложения.pipeline) - набор процессов организованный в последовательность по типу конвейера позволяющий непрерывно производить программные артефакты.(Продакшн, тест, стейджинг - эти определения относятся к окружениям окружения )
Методология DevOps сосредоточена на коммуникации, сотрудничестве и интеграции между подразделениями разработки и эксплуатации. Создание продукта требует больших временных затрат и состоит из нескольких итераций, таких как разработка идеи-концепции, написание кода, тестирование, деплой приложения. Конечной целью является качественный продукт, доставленный вовремя. Над этим работает команда разработчиков, тестировщики и адмнинов. Каждая команда обладает своей зоной ответственности.
Разработчики пишут код, причем каждый пишет свою часть,которую потом интегрирует в общий продукт.
Тестировщик занимается тестированием какой-то части продукта, после тестирования продукт либо уходит на следующий шаг - продакшн, либо возвращается разработчику для устранения багов (ошибок).
Задача operations команды, в свою очередь, заключается в том, чтобы готовый код правильно функционировал в различных средах разработки.
Все команды взаимно зависят друг от друга, без их взаимодействия и эффективной коммуникации продукт разработан не будет.
Каждая итерация требует временных затрат и, конечно же, компаниям-разработчикам программного обеспечения и заказчикам этого программного продукта хочется сократить время поставки без потери качества. Сделать это за счет сокращения времени написания кода или тестирования, невозможно.
Экономия времени возможна только за счет сокращения времени простоя между итерациями разработки ПО. Другими словами, за счет сокращения времени ожидания командами своей работы.
Это и предлагает DevOps методология - обеспечить эффективное и быстрое взаимодействие между командами.
Теперь у вас есть понимание классической DevOps методологии. На практике чаще всего применяются DevOps концепции, относящиеся к инфраструктуре приложений, а под DevOps инженером понимаю специалиста, который отвечает за инфраструктуру, развертывание, мониторинг и доступность приложений. Также DevOps инженер отвечает за настройку окружений для разработчика, тестировщика и в продакшене.
System(Software) as a Service.Platform as a Service
Infrastructure as a Service
Эти три понятия приобрели популярность в последние лет десять, и представляют собой единую концепцию по которой некоторая услуга предоставляет в формате сервиса, которым вы пользуетесь как функционалом, или API, или любая другая форма. Достаточно часто эти концепции объясняются на примере пиццы (Рис. 1.1):
Незакрашенные элементы - ваша зона ответственности, закрашенные элементы - зона ответственности провайдера
Концепция, название которой переводится как "Домашние питомцы против рогатого скота". Звучит странно, поэтому на русский язык название концепции чаще всего не переводится. В целом концепция заключается в двух различных подходах к управлению системами на серверах.
Подход Pet - этот подход довольно старый, но все еще актуальный. Заключается он в том, что система на серверах устанавливается один раз, и далее конфигурируется под любые нужды, а в случае поломки чинится.
Подход Cattle - более свежий, появившийся с распространением виртуальных серверов. Заключается в том, что система зачастую предварительно настроена уже в самом образе из которого она разворачивается. Если же система сервера повреждена, система просто уничтожается и разворачивается новая копия.
Оба подхода имеют право на жизнь и используются по сей день в разных видах, но уже чаще на разных уровнях и с разными типами приложений.
К примеру подход Cattle используется когда время простоя неприемлемо в силу невозможности переноса приложения на другой сервер или балансировки подключений. К примеру - гипервизоры, базы данных. Несмотря на то что буквально недавно получили достаточно широкое распространение технологии позволяющие перенести процесс (вместе с оперативной памятью и прочим) с одного сервера на другой не останавливая сам процесс. Это предельно сложная и затратная операция, и в случае гипервизора - по затратам дешевле починить систему на существующем, нежели переносить все ресурсы на новый сервер. Еще один пример - поддержка GitLab на своих серверах. Несмотря на прекрасное разделение ролей между компонентами приложения, опять таки проще, поддерживать в хорошем состоянии один сервер, чем перемещать хранилище, подключения к базе, очереди, обработчики задач и прочее с сервера на сервер.
С другой стороны, многие веб-приложения прекрасно работают вне своего состояния и не требуют много локальных ресурсов хранилища, что позволяет перенаправить трафик, просто пристрелив некорректно работающее приложение и поднять вместо старого экземпляра - новый.
Минусы и плюсы разумеется есть у обоих подходов, и в основном это касается ресурсов затрачиваемых на поддержку системы и глубины знаний требуемых для поддержки этой самой системы.
Тема очень тесно переплетена с предыдущей по принципу управления и менеджмента системами и экземплярами приложений.
Для инфраструктуры понятия Stateless/stateful я бы описал следующим образом: это типы инфраструктуры в которой важно или не важно, продолжит ли после перезагрузки система с того же состояния что было до отключения.
Здесь всё условно и зависит от самого приложения, которое вы поддерживаете, но, в значительном количестве случаев, можно привести следующие примеры:
keep-alive соединения сокетов, которые не переподключаются самостоятельно - вы можете свободно убить любой из балансировщиков нагрузки, и все подключения сбалансируются на оставшиеся, а убитый экземпляр можно заменить новым балансировщиком. Или к примеру front-end часть которая отдает статику, балансирует нагрузку друг с другом. В случае если один из бэкендов, отдающих статику, вылетает - балансировщик нагрузки это замечает и легко может подобрать нехватающие данные с оставшихся. Это - stateless. Вам безразлично в каком состоянии остановится и восстановится экземпляр приложения.NFS, Ceph, самба и так далее. Постоянную репликацию данных очень тяжело обеспечить, и всегда важно чтобы после перезагрузки все файлы были в ожидаемо последнем состоянии. В случае повреждения файловов - можно потерять ощутимый кусок информации.Минусов и плюсов тут нет, в работе DevOps-a присутствуют оба типа приложений, и придётся поддерживать оба. И в процессе разработки инфраструктуры нужно иметь ввиду как эти концепции работают.
Теоретически можно сказать что для Stateless идеально подходит концепция Cattle а для Stateful - Pet, но это не так. Зачастую и stateless приложения удобнее и выгоднее поддерживать постоянными инстансами, а stateful - перезапустить как Pet, но имея возможность выполнить graceful shutdown и сохранив все данные.
Профессия DevOps инженера включает в себя множество различных компетенций, обладание которыми желательно каждому DevOps-у.
Язык программирования для написания скриптов.
Наиболее оптимальные варианты Python или Golang. DevOps-инженер не программист. Конечно, есть разработчики, которые совмещают сразу 2 компетенции. Написание кода DevOps-инженеру нужно для того, чтобы автоматизировать процессы, а также создавать личные инструменты. Наиболее популярным языком среди DevOps-ов и простым для изучения является Python в силу простоты написания скриптов автоматизации. Также часто используется Golang. Он работает быстрее Python, но его изучение занимает больше времени, однако его весомым преимуществом является то, что весь код собирается в один файл который удобно перебрасывать между машинами.
Операционные системы.
Полезно вникнуть в особенности различных операционок семейства Unix. Возможно, вы не будете использовать каждую из них, но знать заранее с каким проектом придется столкнуться - невозможно. Строение операционных систем лучше изучить детально: каким образом происходит работа внутри системы, файловой подсистемы, сокетов, оперативной памяти и сетей, как система взаимодействует с потоками и разнообразными процессами, каким образом она выполняет распределение нагрузок и ресурсов.
Умение работать с терминалом.
Терминал - рабочая среда DevOps-a. Нужно знать, как быстро выполнять базовые манипуляции с системой, текстом, сетью. В системе нужно уметь смотреть состояние ресурсов, выполнять локальные конфигурации, отслеживать, к примеру, сетевой трафик и открытые соединения, конфигурацию ядра. В работе встретится много работы с текстом, например, редактирование конфигураций. Для этого лучше использовать редакторы в терминале - Vi/Vim/Nano. Пригодятся знания инструментов обработки текста, вроде grep/awk/wc/cat/echo и т.д. Часто придётся смотреть логи локально, поэтому нужно знать соответствующие инструменты.
Сети
Взаимодействия приложений и пользователей с приложениями происходит через сеть. Важно знать, как она работает, по каким принципам взаимодействуют хосты в сети, как работает DNS, как помочь клиенту найти нужный хост (а также сделать отказоустойчивость и балансировку нагрузки), как соединить большие сети, какие протоколы как передают данные и как их шифровать.
Облачные инфраструктуры
Принципы работы облачных инфраструктур схожи: виртуальные сети, вычислительные инстансы, хранилища и способы авторизации. Остальное зависит от провайдера и предоставляемых сервисов.
Оркестрация контейнеров
В эпоху микросервисов контейнеризация используется очень активно. Контейнерами нужно как-то управлять, для этого существует несколько главных инструментов - оркестраторов. Самый распространенный (так как поддерживается и продвигается Google) - Kubernetes, также используется Docker-Swarm, в больших корпорациях - Openshift.
Метрики и логирование
Метрики и логирование - основной инструмент в анализе инцидентов, и того, как работает инфраструктура. Важно знать, как и куда собирать метрики, логи, как и на основе чего создавать алерты.
Наиболее важные вещи будут рассмотрены в этом курсе. Остальные рекомендуются к самостоятельному изучению.
CI/CD делится на три понятия, два из которых предельно близки:
CI - Continuous integration (Непрерывная интеграция)CD - Continuous delivery (Непрерывная доставка) и Continuous deployment (Непрерывное развёртывание)Давайте рассмотрим чуть более конкретные примеры.
CI (Continuous integration)- это в принципе одно и тоже понятия для любых типов пайплайнов. Это включает в себя параллельную разработку командой разработчиков одного продукта - то есть использование git или любой VCS (version control system), а также постоянную проверку нового кода и поддержание его в работоспособном состоянии. Плюс сюда же включена сборка продукта в некие артефакты.
CD (Continuous delivery) - это доставка артефактов на окружение, ручное или автоматизированное тестирование самого продукта, и подготовка к деплою в продакшен окружение. Однако само развертывание производится по ручному разрешение.
CD (Continuous deployment) - в случае Continuous deployment это та же доставка, однако полностью в автоматическом режиме новая версия доставляется в продакшен окружение.
DevOps в классическом понимании - методология разработки программного обеспечения. На практике DevOps инженер это специалист, отвечающий за инфраструктур, развертывание, создание и поддержание работоспособности сред разработки и тестирования.
Существуют различные DevOps концепции ,наиболее популярные - SaaS. PaaS. IaaS., Pet vs Cattle, Stateful - Stateless.
Профессия DevOps инженера находится между железом и разработкой, поэтому для эффективной работы необходимо понимание как высокоуровневых, так и низкоуровневых инструментов.
Цель:Получить вводные знания по DevOps, ознакомится с методологией и основными определениями.
DevOps инженер - такую вакансию часто можно встретить на сайтах по поиску работы. На различных технических ресурсах постоянно обсуждаются облака, инфраструктура, деплой(развертывание) приложений. Поэтому может сложиться ощущение, что DevOps - это технология, которая позволяет деплоить приложения.
Но это не совсем верно. DevOps это не технология и не язык программирования. Сам по себе DevOps это методология разработки программного обеспечения.
Основные определения:
development and operations) - методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта.deploy) - развертывание, - помещение исполняемого кода на сервер, где он будет работать.build) - процесс сборки и/или компиляции программного продуктаsandbox), которая используется для тестирования приложения.pipeline) - набор процессов организованный в последовательность по типу конвейера позволяющий непрерывно производить программные артефакты.(Продакшн, тест, стейджинг - эти определения относятся к окружениям окружения )
Методология DevOps сосредоточена на коммуникации, сотрудничестве и интеграции между подразделениями разработки и эксплуатации. Создание продукта требует больших временных затрат и состоит из нескольких итераций, таких как разработка идеи-концепции, написание кода, тестирование, деплой приложения. Конечной целью является качественный продукт, доставленный вовремя. Над этим работает команда разработчиков, тестировщики и адмнинов. Каждая команда обладает своей зоной ответственности.
Разработчики пишут код, причем каждый пишет свою часть,которую потом интегрирует в общий продукт.
Тестировщик занимается тестированием какой-то части продукта, после тестирования продукт либо уходит на следующий шаг - продакшн, либо возвращается разработчику для устранения багов (ошибок).
Задача operations команды, в свою очередь, заключается в том, чтобы готовый код правильно функционировал в различных средах разработки.
Все команды взаимно зависят друг от друга, без их взаимодействия и эффективной коммуникации продукт разработан не будет.
Каждая итерация требует временных затрат и, конечно же, компаниям-разработчикам программного обеспечения и заказчикам этого программного продукта хочется сократить время поставки без потери качества. Сделать это за счет сокращения времени написания кода или тестирования, невозможно.
Экономия времени возможна только за счет сокращения времени простоя между итерациями разработки ПО. Другими словами, за счет сокращения времени ожидания командами своей работы.
Это и предлагает DevOps методология - обеспечить эффективное и быстрое взаимодействие между командами.
Теперь у вас есть понимание классической DevOps методологии. На практике чаще всего применяются DevOps концепции, относящиеся к инфраструктуре приложений, а под DevOps инженером понимаю специалиста, который отвечает за инфраструктуру, развертывание, мониторинг и доступность приложений. Также DevOps инженер отвечает за настройку окружений для разработчика, тестировщика и в продакшене.
System(Software) as a Service.Platform as a Service
Infrastructure as a Service
Эти три понятия приобрели популярность в последние лет десять, и представляют собой единую концепцию по которой некоторая услуга предоставляет в формате сервиса, которым вы пользуетесь как функционалом, или API, или любая другая форма. Достаточно часто эти концепции объясняются на примере пиццы (Рис. 1.1):
Незакрашенные элементы - ваша зона ответственности, закрашенные элементы - зона ответственности провайдера
Концепция, название которой переводится как "Домашние питомцы против рогатого скота". Звучит странно, поэтому на русский язык название концепции чаще всего не переводится. В целом концепция заключается в двух различных подходах к управлению системами на серверах.
Подход Pet - этот подход довольно старый, но все еще актуальный. Заключается он в том, что система на серверах устанавливается один раз, и далее конфигурируется под любые нужды, а в случае поломки чинится.
Подход Cattle - более свежий, появившийся с распространением виртуальных серверов. Заключается в том, что система зачастую предварительно настроена уже в самом образе из которого она разворачивается. Если же система сервера повреждена, система просто уничтожается и разворачивается новая копия.
Оба подхода имеют право на жизнь и используются по сей день в разных видах, но уже чаще на разных уровнях и с разными типами приложений.
К примеру подход Cattle используется когда время простоя неприемлемо в силу невозможности переноса приложения на другой сервер или балансировки подключений. К примеру - гипервизоры, базы данных. Несмотря на то что буквально недавно получили достаточно широкое распространение технологии позволяющие перенести процесс (вместе с оперативной памятью и прочим) с одного сервера на другой не останавливая сам процесс. Это предельно сложная и затратная операция, и в случае гипервизора - по затратам дешевле починить систему на существующем, нежели переносить все ресурсы на новый сервер. Еще один пример - поддержка GitLab на своих серверах. Несмотря на прекрасное разделение ролей между компонентами приложения, опять таки проще, поддерживать в хорошем состоянии один сервер, чем перемещать хранилище, подключения к базе, очереди, обработчики задач и прочее с сервера на сервер.
С другой стороны, многие веб-приложения прекрасно работают вне своего состояния и не требуют много локальных ресурсов хранилища, что позволяет перенаправить трафик, просто пристрелив некорректно работающее приложение и поднять вместо старого экземпляра - новый.
Минусы и плюсы разумеется есть у обоих подходов, и в основном это касается ресурсов затрачиваемых на поддержку системы и глубины знаний требуемых для поддержки этой самой системы.
Тема очень тесно переплетена с предыдущей по принципу управления и менеджмента системами и экземплярами приложений.
Для инфраструктуры понятия Stateless/stateful я бы описал следующим образом: это типы инфраструктуры в которой важно или не важно, продолжит ли после перезагрузки система с того же состояния что было до отключения.
Здесь всё условно и зависит от самого приложения, которое вы поддерживаете, но, в значительном количестве случаев, можно привести следующие примеры:
keep-alive соединения сокетов, которые не переподключаются самостоятельно - вы можете свободно убить любой из балансировщиков нагрузки, и все подключения сбалансируются на оставшиеся, а убитый экземпляр можно заменить новым балансировщиком. Или к примеру front-end часть которая отдает статику, балансирует нагрузку друг с другом. В случае если один из бэкендов, отдающих статику, вылетает - балансировщик нагрузки это замечает и легко может подобрать нехватающие данные с оставшихся. Это - stateless. Вам безразлично в каком состоянии остановится и восстановится экземпляр приложения.NFS, Ceph, самба и так далее. Постоянную репликацию данных очень тяжело обеспечить, и всегда важно чтобы после перезагрузки все файлы были в ожидаемо последнем состоянии. В случае повреждения файловов - можно потерять ощутимый кусок информации.Минусов и плюсов тут нет, в работе DevOps-a присутствуют оба типа приложений, и придётся поддерживать оба. И в процессе разработки инфраструктуры нужно иметь ввиду как эти концепции работают.
Теоретически можно сказать что для Stateless идеально подходит концепция Cattle а для Stateful - Pet, но это не так. Зачастую и stateless приложения удобнее и выгоднее поддерживать постоянными инстансами, а stateful - перезапустить как Pet, но имея возможность выполнить graceful shutdown и сохранив все данные.
Профессия DevOps инженера включает в себя множество различных компетенций, обладание которыми желательно каждому DevOps-у.
Язык программирования для написания скриптов.
Наиболее оптимальные варианты Python или Golang. DevOps-инженер не программист. Конечно, есть разработчики, которые совмещают сразу 2 компетенции. Написание кода DevOps-инженеру нужно для того, чтобы автоматизировать процессы, а также создавать личные инструменты. Наиболее популярным языком среди DevOps-ов и простым для изучения является Python в силу простоты написания скриптов автоматизации. Также часто используется Golang. Он работает быстрее Python, но его изучение занимает больше времени, однако его весомым преимуществом является то, что весь код собирается в один файл который удобно перебрасывать между машинами.
Операционные системы.
Полезно вникнуть в особенности различных операционок семейства Unix. Возможно, вы не будете использовать каждую из них, но знать заранее с каким проектом придется столкнуться - невозможно. Строение операционных систем лучше изучить детально: каким образом происходит работа внутри системы, файловой подсистемы, сокетов, оперативной памяти и сетей, как система взаимодействует с потоками и разнообразными процессами, каким образом она выполняет распределение нагрузок и ресурсов.
Умение работать с терминалом.
Терминал - рабочая среда DevOps-a. Нужно знать, как быстро выполнять базовые манипуляции с системой, текстом, сетью. В системе нужно уметь смотреть состояние ресурсов, выполнять локальные конфигурации, отслеживать, к примеру, сетевой трафик и открытые соединения, конфигурацию ядра. В работе встретится много работы с текстом, например, редактирование конфигураций. Для этого лучше использовать редакторы в терминале - Vi/Vim/Nano. Пригодятся знания инструментов обработки текста, вроде grep/awk/wc/cat/echo и т.д. Часто придётся смотреть логи локально, поэтому нужно знать соответствующие инструменты.
Сети
Взаимодействия приложений и пользователей с приложениями происходит через сеть. Важно знать, как она работает, по каким принципам взаимодействуют хосты в сети, как работает DNS, как помочь клиенту найти нужный хост (а также сделать отказоустойчивость и балансировку нагрузки), как соединить большие сети, какие протоколы как передают данные и как их шифровать.
Облачные инфраструктуры
Принципы работы облачных инфраструктур схожи: виртуальные сети, вычислительные инстансы, хранилища и способы авторизации. Остальное зависит от провайдера и предоставляемых сервисов.
Оркестрация контейнеров
В эпоху микросервисов контейнеризация используется очень активно. Контейнерами нужно как-то управлять, для этого существует несколько главных инструментов - оркестраторов. Самый распространенный (так как поддерживается и продвигается Google) - Kubernetes, также используется Docker-Swarm, в больших корпорациях - Openshift.
Метрики и логирование
Метрики и логирование - основной инструмент в анализе инцидентов, и того, как работает инфраструктура. Важно знать, как и куда собирать метрики, логи, как и на основе чего создавать алерты.
Наиболее важные вещи будут рассмотрены в этом курсе. Остальные рекомендуются к самостоятельному изучению.
CI/CD делится на три понятия, два из которых предельно близки:
CI - Continuous integration (Непрерывная интеграция)CD - Continuous delivery (Непрерывная доставка) и Continuous deployment (Непрерывное развёртывание)Давайте рассмотрим чуть более конкретные примеры.
CI (Continuous integration)- это в принципе одно и тоже понятия для любых типов пайплайнов. Это включает в себя параллельную разработку командой разработчиков одного продукта - то есть использование git или любой VCS (version control system), а также постоянную проверку нового кода и поддержание его в работоспособном состоянии. Плюс сюда же включена сборка продукта в некие артефакты.
CD (Continuous delivery) - это доставка артефактов на окружение, ручное или автоматизированное тестирование самого продукта, и подготовка к деплою в продакшен окружение. Однако само развертывание производится по ручному разрешение.
CD (Continuous deployment) - в случае Continuous deployment это та же доставка, однако полностью в автоматическом режиме новая версия доставляется в продакшен окружение.
DevOps в классическом понимании - методология разработки программного обеспечения. На практике DevOps инженер это специалист, отвечающий за инфраструктур, развертывание, создание и поддержание работоспособности сред разработки и тестирования.
Существуют различные DevOps концепции ,наиболее популярные - SaaS. PaaS. IaaS., Pet vs Cattle, Stateful - Stateless.
Профессия DevOps инженера находится между железом и разработкой, поэтому для эффективной работы необходимо понимание как высокоуровневых, так и низкоуровневых инструментов.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.