Я новичок в Docker, подскажите, пожалуйста, как корректно решить следующую задачу с помощью docker-compose: есть контейнер sborka, в нем собирается java web application (war файл на выходе), есть второй контейнер prod, запускающий приложе…
На текущей момент с командой разработки бекенда пользуемся следующим подходом:
Есть тестовая ветка staging, из которой мы создаем ветки (feature-ветки) для наших задач. После выполнения мерджим задачу обратно в staging и через GitLab проек…
Всем привет. Есть проблема при работе gitlab-ci. Сборка java через mvn и упаковка собранного Jar файла в докер.
В варианте build package dockerise не собирается jar файл. По логам он есть, но если смотреть по пути где он якобы собрался, фа…
from rich.console import Console
from rich.tree import Tree
paths: dict = {
‘pyproject.toml’: False,
‘docs’: {
‘source’: {
‘conf.py’: True, ‘index.rst’: False, ‘use_guide.rst’: False, ‘api.rst’: False
}…
Разберем роль CI в жизненном цикле разработки (что в себя включает эта часть процесса, какие задачи решает) и на практике настроим CI для приложения API сервера.
В прошлой с…
Почему профессиональные сертификаты так востребованы в портфолио инженера? Какие преимущества сертификаты дают специалисту? И какие ТОП-20 сертификаций необходимы системному инженеру? Мы постарались собрать ответы в этой статье.
…
Без снобизма о гиперконвергенции.
Термин «гиперконвергенция» описывает класс строительных блоков для ИТ-архитектуры. Такие блоки максимально стандартизированы и в одном устройстве объединяют вычислительные ресурсы, хранилище данных и другие компоненты. Например, гиперконвергентная система HPE SimpliVity 380G Gen10 предоставляет вычислительные ресурсы и распределенное хранилище данных со встроенными механизмами дупликации и сжатия, а также дополнительный набор функций для резервного копирования. При этом управление всеми процессами осуществляется через плагин, устанавливаемый в консоль гипервизора.
У каждого подхода есть свои сильные и слабые стороны, которые определяют его область применения. По сравнению с традиционной архитектурой, где отдельно собраны серверы и хранилище, гиперконвергентные системы занимают меньше физического пространства в ЦОДе и, как правило, потребляют меньше электроэнергии. Они хорошо справляются с большинством задач, предполагающим «симметричное» масштабирование (параллельно увеличиваем вычислительные ресурсы и ёмкость хранилища), а вот с «асимметричным» масштабированием, когда требуется значительное увеличение одного типа ресурсов без роста другого их типа, начинаются сложности.
Поддерживать стабильную производительность сложно, когда на одном узле размещено много данных. А при распределении данных по нескольким узлам могут возникать дополнительные сетевые задержки.
Чтобы справиться со сложностями масштабирования, компания HPE анонсировала новый тип дезагрегированных гиперконвергентых систем, которые сочетают в себе элементы классической и конвергентной инфраструктуры, позволяя масштабировать вычислительные ресурсы и ёмкость хранилища полностью независимо друг от друга.
Здесь все зависит от задачи. Классическая гиперконвергентная система HPE SimpliVity 380G Gen10 отлично подходит для установки в крупной филиальной сети или в небольших офисах за счет простого управления большим количеством территориально распределенных кластеров. Положительно сказывается и возможность обеспечения высокой доступности в двухузловой конфигурации, наличие встроенной системы резервного копирования виртуальных машин и возможность оптимизации передачи данных между кластерами за счет механизмов сжатия и дедупликации данных.
Дезагрегированная гиперконвергентная система HPE Nimble Storage dHCI подходит для использования в центрах обработки данных для размещения приложений с высокими требованиями к производительности и «асимметричным» масштабированием ресурсов. Она обладает следующими преимуществами:
Дезагрегированное решение HPE Nimble Storage dHCI состоит из следующих компонентов:
Данное решение также может быть развернуто на уже имеющихся у заказчиков серверах HPE ProLiant 9-го и 10-го поколений.
Одно дело описать преимущества, и совсем другое – увидеть их в действии. Ознакомиться с HPE Nimble Storage dHCI можно прямо сейчас на тест-драйве со следующим набором функций:
Разбираемся, как разрабатывать ПО короткими спринтами с автоматическими тестами и развертыванием в продакшене.
Чего хочет заказчик от отдела разработки?
…
На выбор есть факультеты, профессии, программы и курсы по 7 направлениям: программирование, IT-инфраструктура, аналитика, дизайн, маркетинг, менеджмент и школьникам.
— Читать дальше ««Чёрная пятница» в GeekBrains»
…
Быть связующим звеном между разработкой и эксплуатацией – сложнейшая работа, которой занимаются инженеры DevOps. Предлагаем углубиться в изучение этого вопроса с помощью нашей подборки лучших тематических каналов YouTube.
…
Делаю обработку изображения с помощью расширения GD. У меня локально всё работает, на деве и проде проекта нет, картинка загружается но кода GD как будто нет вообще, проходит мимо. Но дело в том что сборка у нас 1 в 1. phpinfo 1 в 1. В чем…
Шуточный тест, чтобы определить, какое направление стажировки SafeBoard может вам подойти. Просто выбирайте решения, которые вам ближе всего.
— Читать дальше «Какое из 8 направлений IT-стажировки вам подходит? Тест от Tproger и Kaspersky»
…
Книги остаются одним из самых популярных и экономичных способов получения необходимых знаний в сфере ИТ. Мы подготовили подборку актуальной литературы для начинающих и опытных специалистов DevOps.
Предлагаем ознакомиться со списком актуальной литературы, которая будет полезна как новичкам, так и опытным специалистам DevOps.
Авторы: Джез Хамбл, Джон Уиллис, Патрик Дебуа.
Одна из самых популярных книг по изучению методологии DevOps, которая уже много лет не теряет актуальности.
В ней представлены три основополагающих принципа DevOps, описанные как «Три пути»: поток, обратная связь, непрерывное обучение и экспериментирование. Кроме того, в книге описывается, как разные типы организаций могут использовать DevOps и почему это может помочь им получить конкурентное преимущество в сфере ИТ.
Книга также наполнена реальными сценариями и опытом таких компаний, как Etsy, Nordstrom, Google, Facebook, Alcoa и Target.
Подходит для новичков.
Отзывы:
Книга хорошо и подробно описывает вопросы перехода от традиционных разработки и эксплуатации к подходам DevOps, со многими сложностями и подводными камнями на этом пути (многие книги зациклены на том, как все сделать правильно сразу – т.е. стартап). Большой плюс – в наличии целой главы, посвященной вопросам безопасности и соответствия государственным/отраслевым нормам. Success stories приятно разбивают повествование, давая голове отдохнуть.
Авторы: Джез Хамбл, Джин Ким, Николь Форсгрен.
В течение многих лет считалось, что производительность групп по доставке программного обеспечения не имеет значения и она не может обеспечить конкурентное преимущество компаниям. Авторы потратили четыре года на новаторские исследования, включающие сбор данных из отчетов о состоянии DevOps, проведенных совместно с компанией Puppet. Николь Форсгрен, Джез Хамбл и Джин Ким намеревались найти способ измерения производительности доставки программного обеспечения и того, что этим движет, с использованием тщательных статистических методов. В этой книге описаны их выводы.
Книга подходит как для разработчиков программного обеспечения, так и для ИТ-менеджеров, руководителей высшего звена.
Отзывы:
Хорошая книга, дает понимание основных понятий по DevOps. В плане практического применения больше подходит для аналитиков, чем для инженеров, но будет полезна и тем, и другим.
Конечно, эту книгу взахлеб будут читать руководители и сотрудники ИТ-компаний. Но она не только для них. Она для всех нас, коллеги!
Книга дает главное – методологию масштабирования вашей компании и бизнеса. И полезные прикладные практики работы.
Авторы: Эви Немет, Гарт Снайдер, Трент Хейн.
В этой книге подробно описываются передовые практики, которые применяются для каждого аспекта системного администрирования, включая управление хранилищем, проектирование и администрирование сети, веб-хостинг и горизонтальное масштабирование, автоматизацию, управление конфигурацией, анализ производительности, DNS, безопасность, и многое другое.
Подходит для новичков.
Отзывы:
Отличная книга для тех, кто хочет разобраться с администрированием систем. Сам до этого ничего не изучал по этой теме и скажу, что книга дает основы, понимание концепции в целом. Дальше разобраться с любой конкретной системой проблем не будет.
Когда-то эта книга была моей первой книгой по Linux. Рекомендую для начинающих админов. Материал изложен понятно, но рассчитывать, что в одной книге вам подробнейшим образом расскажут и про sendmail и про bind не стоит. Идеальна для получения ОБЩИХ представлений об ОСНОВНЫХ вещах.
Автор: Джиджи Сайфан.
Kubernetes – это система с открытым исходным кодом, которая используется для автоматизации развертывания, масштабирования и управления контейнерными приложениями.
Благодаря этой книге вы подробно изучите функции, доступные в Kubernetes версии 1.10, а также основы архитектуры и дизайна Kubernetes. Научитесь запускать сложные микросервисы с отслеживанием состояния, ознакомитесь с такими расширенными функциями, как горизонтальное автомасштабирование подов, выкатывание обновлений, квотирование ресурсов, обустроите долговременное хранилище на бэкенде.
Книга подойдет для системных администраторов и разработчиков, имеющих промежуточное представление о Kubernetes и желающих освоить его расширенные функции.
Отзывы:
Отлично подойдет для знакомства с технологией, в противовес чтения документации на английском. Легко читается, изложены все ключевые концепции. Но местами идет описание каких-либо ресурсов или компонентов переведенных на русский. Нужно ловить себя на мысли, что речь сейчас идет именно о DeploymentConfig, который в тексте звучит как «конфигурация развертывания», немного странно.
Автор: Эдриен Моуэт.
Платформа Docker предлагает более простые, быстрые и надежные методы разработки, распространения и запуска программного обеспечения, чем было доступно ранее. Из этой книги вы узнаете, почему контейнеры так важны, какие преимущества вы получите, освоив Docker, и как сделать его частью процесса разработки.
Подходит для новичков.
Отзывы:
Замечательная книга для кодера, который хочет выйти из каменного времени классического развертывания приложения и начать работать с кластерами облачных технологий.
Некоторые моменты устарели, однако, это не недостаток книги т.к. описание от чего шел проект Docker позволяет понять почему он сделан именно так.
Нужна была книга для «быстрого старта», в итоге, она подошла для этого – прекрасно. Главное, что получилось развернуть кластер с её помощью.
Автор: Mikael Krief.
В книге представлены различные шаблоны и инструменты, которые можно использовать для подготовки и настройки инфраструктуры в облаке. Вы начнете с понимания культуры DevOps, применения DevOps в облачной инфраструктуре, подготовки с помощью Terraform, настройки с помощью Ansible и создания образов с помощью Packer.
Затем вы ознакомитесь с управлением версиями исходного кода с помощью Git и построением конвейера CI/CD с использованием Jenkins, GitLab CI и Azure Pipelines. Эта книга также поможет в создании контейнеров и развертывании ваших приложений с помощью Docker и Kubernetes.
Книга подойдет для разработчиков и системных администраторов, заинтересованных в понимании CI/CD и контейнеризации с помощью инструментов и методов DevOps.
Отзывы:
Книга позволяет узнать о различных инструментах, используемых в DevOps. Помимо объяснения на очень хорошем уровне, в книге есть ссылки для просмотра исходного кода в репозиториях Git. Рекомендую!
Автор: Kief Morris.
Шесть лет назад «Инфраструктура как код» была новой концепцией и сейчас только набирает обороты. Автор книги рассказывает, как эффективно использовать принципы, практики и шаблоны, разработанные командами DevOps для управления инфраструктурой облачной эпохи.
Книга подходит для инженеров DevOps и системных администраторов.
Отзывы:
Эта книга полна отличной информации о том, как управлять кодом IaC. Кроме того, полно шаблонов и анти-шаблонов, которые специально предназначены для кода IaC.
Автор: Jeffery D. Smith.
Автор описал, как реализовать методы DevOps в несовершенных средах. Книга объединяет с одной стороны учебник по технологиям, а с другой – справочник по психологии. Кроме того, в ней описаны способы реализации методологии DevOps в команде.
Книга подходит как для DevOps-инженеров, так и для ИТ-менеджеров.
Отзывы:
В этой книге рассматриваются сценарии, с которыми вы, скорее всего, столкнетесь на работе, объясняется, почему многие решения, основанные на здравом смысле, терпят неудачу, и предлагаются отличные решения, которые можно попробовать. Книга будет полезной как для DevOps-инженеров, так и для менеджеров. Ее можно читать от корки до корки, содержит много информации, но при этом легкая в чтении с небольшой долей юмора.
Автор: Martyn Coupland.
Кроме того, в книге описано, как взаимосвязаны аспекты культуры, людей и процессов, и что без любого из этих элементов DevOps вряд ли будет успешным. По мере вашего прогресса вы узнаете, как измерить и оценить успех DevOps в вашей компании, а также изучите плюсы и минусы основных инструментов. В заключительных главах раскрыты последние тенденции в DevOps.
Подходит для новичков.
Отзывы:
Очень хорошо написанная и продуманная практическая книга по глубокому погружению в DevOps. Настоятельно рекомендую эту книгу всем, кто работает в сфере технологий. Она удобна для ознакомления с работой, как в облаке, так и в локальной среде. Принципы и практики из этого руководства помогли моей команде внедрить DevOps.
Автор: Marc Hornbeek.
Книга состоит из пяти частей:
Книга подходит как для DevOps-инженеров, так и для ИТ-менеджеров.
Отзывы:
Независимо от вашего уровня знаний, эта книга поможет полностью заполнить пробелы. Несколько человек давали мне разные объяснения методологии DevOps, но только эта книга стала для меня исчерпывающим и авторитетным источником информации. Есть много ссылок, которые можно дополнительно использовать в обучении, а в дополнениях книги есть полезные рабочие листы.
Если вы находитесь только в начале пути, стоит обратить внимание на курс Факультета DevOps образовательной онлайн-платформы GeekBrains. Эксперты-практики из ведущих российских технологических компаний научат вас использовать методологии Agile и Scrum, оптимизировать CI/CD и работать с облачными технологиями. Курс подойдет как новичкам в IT, так и опытным специалистам, которые хотят сменить направление.
За 18 месяцев обучения вы освоите актуальную программу по DevOps, решите шесть проектных задач и создадите итоговую работу с сокурсниками, а также изучите основы Python и облачных технологий, работу с сервисами Linux и Kubernetes.
Успешно окончившим курс студентам HR-специалисты GeekBrains помогут создать резюме и предложат вакансии. Гарантия трудоустройства закреплена в договоре.
С повышением объёмов данных растёт необходимость их защиты. Здесь как раз требуется DevSecOps, где DevOps – процесс разработки и доставки программы, а частица Sec отвечает за защиту этого приложения.
Грубо говоря, это врезка дополнительного шага в методологию разработки ПО. Шаг добавляется после внесения изменений в программу. Сама же методология направлена на более тесное сотрудничество между командами разработки и эксплуатации и добавляя к ним команду безопасности.
С учётом нынешней скорости разработки новых версий продукта, команда информационной безопасности не всегда успевает держаться в том же темпе. Для его сохранения следует задуматься о включении проверок безопасности кода как можно раньше – это можно назвать частью процесса «сдвиг влево», когда команда безопасности тестирует код до разработчиков.
Разумеется, вплотную заниматься методологией придётся тем разработчикам, которые входят в команду по информационной безопасности. Да, это та самая команда, которая позже взбесит всех прочих программистов, но такова цена безопасности.
При этом важно понимать, что и обычные разработчики, и команда безопасности всегда будут правы по своему и искать кого-то более виноватого бессмысленно – это лишь ещё оттянет процесс разработки.
Беспокойство о безопасности может полностью похоронить любую разработку из-за нерационально расходуемого времени.
Философия DevSecOps предлагает интегрировать тесты безопасности во все циклы DevOps: начало, дизайн, сборку, тестирование, выпуск, поддержку и обслуживание.
Методология предлагает постоянное сотрудничество между разработчиками, командой выпуска и безопасниками. Она помогает поддерживать высокую скорость разработки без большого урона для безопасности.
Во избежание этого следует заранее создать различные правила остановки разработки при наличии уязвимостей. Например, при наличии критической ошибки безопасности дальнейшая разработка прекращается, и все силы перебрасываются на её исправление. Если ошибка не настолько критична, но имеет значение, можно не прерывать разработку, а лишь обратить на проблему внимание.
Правильное настроение во время программирования экономит время. В данном случае разработчикам следует фокусироваться на безопасности – в дальнейшем это сокращает время, затрачиваемое на вылов и исправление багов.
Методологию, кстати, можно использовать не только для разработки ПО, но и в других сферах:
Как у каждой методологии, у DevSecOps есть собственные стандартные практики, упрощающие её использование:
DevSecOps – методология разработки, в которой код, прежде чем выйти в релиз, тестируется на возможные информационные утечки. Это влияет на скорость разработки, поэтому следует заранее определить уровни ошибок: от критических до маловажных.
Если вы заинтересованы в развитии карьеры в этой сфере, стоит обратить внимание на «Факультет информационной безопасности» образовательной онлайн-платформы GeekBrains. На 70% учебная программа состоит из вебинаров с преподавателями, которым вы сможете задать все интересующие вопросы по темам и оперативно получить от них обратную связь.
Продолжительность обучения – один год. За это время вы освоите современные технологии и компетенции, которые необходимы специалистам по безопасности: Application Security Engineer, пентестеру, специалисту по информационной безопасности или DevSecOps-инженеру.
Курс заточен на системных администраторов и девопс-инженеров, Будут разбирать задачи инфраструктуры, связанные с Ansible, Docker, Kubernetes.
— Читать дальше «Курс «Python для инженеров»»
…
Dell Technologies приглашает студентов дневного отделения технических вузов Санкт-Петербурга на оплачиваемую стажировку. На выбор есть 5 направлений: программирование на Java, C++ или Python, тестирование ПО, DevOps и администрирование.
— Читать дальше…
Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.
…
Международная конференция по тестированию и обеспечению качества ПО. 3 дня докладов и мастер-классов от ведущих мировых специалистов.
— Читать дальше «TestCon Moscow 2021»
…
Мы расспросили ведущего инженера DevSecOps о том, почему этот подход настолько важен, каким организациям стоит его внедрять, какие шаги нужно предпринять и какие факторы стоит при этом учитывать.
DevSecOps – это философия интеграции практик безопасности в процесс DevOps.
Этот стратегический сдвиг в интеграции средств управления безопасностью в жизненный цикл разработки программного обеспечения (SDLC) оказал большое влияние на отрасль.
DevSecOps решает наиболее распространенную проблему, с которой сталкивались многие компании на пути к DevOps, когда более быстрые выпуски кода приводили к большему количеству уязвимостей. Благодаря DevSecOps, критические проблемы безопасности решаются по мере их поступления, а не после возникновения угрозы или компрометации.
Если понимать DevSecOps дословно, то это безопасный DevOps. Другими словами, это именно практики разработки, внедрения и эксплуатации продукта (приложения, сайта, банк-клиент платформы, облачного сервиса и т.д.) с учетом требований к информационной безопасности.
Речь идет о превентивном выявлении недостатков кода, которые потом могли бы вылиться в уязвимости ПО (то что еще называется термином Secure SDLC или SSDLC).
Также это проработка и внедрение механизмов защиты от мошеннических операций и разного рода фрода (например, это очень актуально для банк-клиент приложений, электронных бирж и обменников криптовалюты) в разрабатываемый продукт, обеспечение безопасности облачной среды (AWS, GCP, Yandex.Cloud и т.д.), где он эксплуатируется. То есть распределение прав доступа к ресурсам, определение пользовательских ролей в системе, мониторинг Kubernetes-кластера как ядра системы, выявление инцидентов и реагирование на них.
DevSeсOps – это то, что должно быть в любой компании, которая занимается разработкой ПО и которая заботится о своих клиентах, сохранности их данных, ну и конечно же о собственной репутации. Размер компании тут не так важен, различия будут скорее в том, что более крупная компания имеет большую капитализацию и, соответственно, бюджетирование на решение вопросов безопасности, по сравнению со стартапом, где все только набирает обороты.
Правдивость известной фразы «Безопасность стоит дорого, но ее отсутствие еще дороже» не раз была доказана на примере крупных взломов. Например, можно вспомнить скомпрометированную цепочку поставок SolarWinds или нашумевшую атаку на Capital One в 2019 году, когда было потеряно 30 ГБ данных, содержащих записи о 106 млн. пользователей, ну и ярко отметившуюся в 2018 году cryptojacking-атаку на компанию Tesla, Илона Маска.
Все, кто хотят строить свой бизнес на перспективу и делать качественный продукт мирового уровня, должны обращать значимое внимание на DevSecOps.
Это прежде всего снижение расходов на стадии поддержки продукта. Если еще до релиза на этапе разработки исключить критические уязвимости (CVE, CWE) и баги, то не понадобится выпускать патчи (исправления) или вовсе отзывать продукт с рынка.
Еще одно преимущество – это соответствие комплаенс-требованиям: как российским (например, ЦБ РФ для финансовых учреждений), так и международным (Cloud Security Alliance (CSA), Cloud Native Computing Foundation (CNCF), PCI DSS, GDPR и т.д.). Это дает возможность проходить аудиты соответствия требованиям контролирующих органов, получать соответствующие лицензии и сертификаты на вид деятельности (особенно критично для бирж, обменников, систем банк-клиент), подтверждать свою ответственность перед клиентами и партнерами.
И непосредственно – это внутренняя инфраструктурная безопасность облачной среды, которую периодически пытаются взломать хакерские группы, боты и потенциально нечестные конкуренты по нише, разделяемой на рынке. Средствами только стандартного DevOps эти вопросы никогда не решить.
Классический подход к внедрению DevSecOps описан в нескольких книгах:
К тому же нужно понимать, что внедрение SDLC (безопасного цикла разработки ПО) – это часть общих работ по запуску DevSecOps в компании, и они отличаются между собой по сложности и длительности. В самом простом варианте это всегда определение целей и задач, выставление требований к продукту и процессу его разработки (то что называется secure by design), планирование работ, внедрение технических и программных средств защиты, мониторинг и поддержка.
Проблем всегда хватает. Большинство из них совпадает с типичными проблемами DevOps. Например, речь идет о внедрении процедур проверки качества кода и выявления уязвимостей на стадии комита, далее целевого репозитория и хранилища артефактов в общий CD/CI конвейер (так называемые паплайны).
Конкретно ИБ-шной спецификой можно назвать борьбу с ложными срабатываниями статического анализатора кода (SAST), централизованное управление секретами с минимальными издержками на производительность и удобство работы в системе, разработка кастомных правил безопасности под каждый независимый контур – Dev, Stage, Prod.
Решающий фактор в этом деле на мой взгляд – это компетенции и мотивация тех сотрудников, которые отвечают за безопасность в компании. Осознание современных угроз и скрытых рисков, понимание того, как баг может повлиять на конечный продукт, знание средств и систем защиты – все это поможет выстроить некий roadmap того, как необходимо внедрять DevSecOps-практики в каждодневную работу команды разработчиков и DevOps-инженеров.
Следующий фактор – это наличие бюджета на закупку и поддержку различных средств безопасности. Нужно понимать приоритетность внедрения решений, а также обладать специфической экспертизой в некоторых тонкостях реализации защиты периметра или отдельных end-point хостов. Если бюджета нет, то на первых порах можно обойтись средствами open sources, которые, конечно, не дадут того уровня, что дают коммерческие решения, но все таки не оставят в чем мать родила.
Описание каждой практики достойно отдельной статьи. Однако можно упомянуть ключевые bullet points при внедрении DevSecOps, а именно:
Методология DevOps затрагивает не только группы разработки и эксплуатации. Если вы хотите в полной мере использовать гибкость и оперативность подхода DevOps, ИТ-безопасность также должна играть важную роль в полном жизненном цикле приложений, которые вы разрабатываете.
В быстро меняющемся цифровом мире компаниям крайне важно адаптироваться к возрастающему количеству кибератак, которые каждый день ставят под угрозу безопасность приложений.
Если вы заинтересованы в развитии карьеры в этой сфере, стоит обратить внимание на «Факультет информационной безопасности» образовательной онлайн-платформы GeekBrains. На 70% учебная программа состоит из вебинаров с преподавателями, которым вы сможете задать все интересующие вопросы по темам и оперативно получить от них обратную связь.
Продолжительность обучения – один год. За это время вы освоите современные технологии и компетенции, которые необходимы специалистам по безопасности: Application Security Engineer, пентестеру, специалисту по информационной безопасности или DevSecOps-инженеру.
Внутри отрасли DevOps успели сложиться узкие прикладные направления – осваивающему профессию новичку нужно представлять, какая комбинация навыков потребуется для каждого из них. Рассказываем про отличия основных специализаций в небольшом об…
Изучив основы и подготовив тестовый полигон, мы переходим к практической части. Сегодня разберем, как создать первое приложение на Python + Flask и развернуть его в кластере k8s.
Поскольку Python – единственный язык программирования, на котором я что-то умею писать, особого выбора у
меня нет. Приложения будет запускаться как веб-сервер, слушать
указанный порт и при обращении выдавать приветствие “Hello from Python”. Кроме Python потребуется фреймворк Flask.
Код приложения:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello from Python"
if __name__ == "__main__":
app.run(host='0.0.0.0')
В первых двух строчках мы подключаем Flask, а далее создаем обработку
корневого запроса. Приложение неидеально, но как минимальный вариант для развертывания в кластере k8s оно сгодится. Так как k8s – это среда запуска
контейнеров, для переноса приложение необходимо упаковать, например, в Docker.
Чтобы собрать контейнер, нужно поставить Docker на локальную машину (да,
да – Капитан очевидность). Инструкция по инсталляции есть на официальном сайте – процесс довольно несложен. Далее собирать образ можно
средствами Docker, я использую для этих целей утилиту buildah. Она ни разу меня не подводила, рекомендую.
Для начала создаем директорию, из которой
будем собирать контейнер. Первый файл в директории назовем, например, app.py (его код приведен выше). Для установки зависимостей нам потребуется файл requirements.txt. Поскольку приложение простенькое, достаточно добавить только модуль Flask:
Flask==1.0.2
Третий
файл называется Dockerfile – без расширения. Его содержимое:
FROM python:3.9-alpine
RUN mkdir /app
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "/app/app.py"]
Разберем его построчно:
/app внутри контейнера.
/app. Ее в кластере нет, и контейнер падает с ошибкой (не найден файл /app/app.py).
pip и скармливаем ему файл зависимостей. Flask скачивается и устанавливается в контейнер.
app.py.app.py, requirements.txt, Dockerfile.Находясь в директории
с файлами, выполняем команду для сборки контейнера на основе Dockerfile с
помощью утилиты buildah:
buildah bud -f ./Dockerfile .
Запустится сборка, прогрузятся все зависимости из requirements.txt, и в
итоге сгенерируется хеш – строка Storing signatures, которая нам в дальнейшем
понадобится (копируем ее в буфер обмена)
Дальше необходимо запушить сборку в локальный репозиторий Docker.
Выполняем следующую команду, подставляя в параметры свой хеш:
buildah push dedd9a5526d3c97231e9a0b73ca1e4a91ece0d70a7f7bff254f61f7d28d8e9fb docker-daemon:app:v0
Контейнер уже можно увидеть в списке локального репозитория Docker, выполнив следующую команду:
docker image ls
docker run --rm -d -v `pwd`:/app -p 5000:5000 app:v0
Приложение откликается, значит контейнер рабочий. Последний штрих – запушить
контейнер из локального репозитория в удаленный, например, в Docker Hub. Это нужно, чтобы мы могли скачать контейнер в кластер k8s и запуститься его уже там.
Чтобы это сделать, потребуется авторизоваться на
Docker Hub и создать пустой репозиторий. Детально описывать эту процедуру не
буду: процесс похож на создание Git-репозитория.
docker login
<выполните авторизацию>. Делается один раз, пароль и логин запоминаются
docker tag app:v0 <ваш логин docker hub>/<ваш репозиторий>/app:v0
buildah push <image ID> <ваш логин docker hub>/<ваш репозиторий>:app
Теперь можно на любом хосте с Docker запустить
контейнер и в качестве расположения указать уже не локальный репозиторий, а
Docker Hub.
docker run --rm -d -v `pwd`:/app -p 5000:5000 test/learn_images:app:v0
Цель – развернуть приложение Python из контейнера, но уже в кластере k8s
в нескольких репликах.
Для этого необходимо создать два объекта (подробнее мы рассматривали их в предыдущей статье):
Заходим по SSH на мастер-узел (ноду), проверяем работоспособность kubectl.
Далее необходимо создать deployment.yaml.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 2
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: app
image: <ваш логин docker hub>/<ваш репозиторий>:app
ports:
- containerPort: 5000
protocol: TCP
name: http
resources:
limits:
cpu: 50m
memory: 20Mi
requests:
cpu: 50m
memory: 20Mi
Разбираем подробнее:
Deployment, но может быть и Service или, скажем, Pod.Deployment (именно так он будет отображаться в кластере k8s).
limits). Без этих ресурсов приложение не стартует и планировщик кластера будет искать подходящий узел, удовлетворяющую минимальным ресурсам. Запрашиваемые (requests) – это ресурсы, которые резервируются на ноде для вашего приложения. Сверх этих ограничений приложение не получит ресурсов CPU и RAM.
Сохраняем файл deployment.yaml и выполняем команду для развертывания приложения:
kubectl create -f deployment.yaml
Если
ошибок в файле не было, успешный исход – активное приложение в 2 репликах.
Посмотреть состояние можно следующей командой:
kubectl get pod -o wide
Приложение
развернуто в двух репликах – с помощью curl можно обратиться к каждой из них по IP пода, но это плохой вариант (поды рано или поздно
переедут на другие узлы и IP поменяются). Давайте напишем еще один объект
кластера, который закроет эту проблему – Service.
endpoint).Создаем еще один файл service.yaml.
apiVersion: v1
kind: Service
metadata:
labels:
app: app
name: app
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 5000
selector:
app: app
type: ClusterIP
Его главные отличительные особенности:
Service будет принимать трафик. Deployment и все реплики по этой метке.
Service. В нашем случае для сетевого взаимодействия внутри кластера k8s.
Запускаем процедуру создания следующей командой:
kubectl create -f service.yaml
Далее
смотрим детали Service:
kubectl get svc -o wide
Супер! У нас есть IP, по которому можно обращаться к сервису в
кластере с любого пода.
Подведем итог статьи. Мы добились следующих результатов:
Поздравляю, вы развернули первое приложение в кластере k8s! Возможно оно простовато, но в следующих статьях мы будем доводить его до ума.
Продолжая цикл статей по Kubernetes, мы познакомимся с базовыми конструкциями кластера k8s.
В предыдущих статьях мы рассмотрели системы оркестрации и научи…
JetBrains опросила разработчиков из 183 стран, чтобы составить ежегодный отчёт об экосистеме разработки в 2021 году. Вот основные тезисы исследования.
— Читать дальше «JetBrains опубликовала ежегодный отчёт о мире разработки The State of Developer Ecos…
DevOps – одна из самых сложных областей, в которой чтобы отлично справляться и оставаться актуальным, вам нужно постоянно учиться. Рассмотрим 5 проектов, способных в этом помочь.
П…
Развитие сферы IT делает некоторые профессии неактуальными, и пальма первенства переходит к более востребованным на рынке. Направление DevOps – одно из таких. Мы расспросили разработчицу и сисадмина о том, почему и как они перешли в DevOps.
С появлением методологии DevOps, многие традиционные роли в IT трансформируются именно в этом направлении. Наиболее распространенным является переход с позиции системного администратора или разработчика на позицию DevOps-инженера.
Чаще всего сравнивают именно профессии системного администратора и специалиста по DevOps. Эти роли разделяют ряд общих задач, но существуют и фундаментальные различия между ними.
Системные администраторы не участвуют в процессе разработки программного обеспечения. DevOps-инженеры играют более активную роль. Они сосредоточены на работе над всем жизненным циклом продукта, а системные администраторы участвуют только на стадии его эксплуатации.
Обычно в обязанности системного администратора входит следующее:
Некоторые навыки и обязанности системных администраторов актуальны и для DevOps-инженеров, но для смены профессии потребуются и дополнительные:
В обязанности разработчика входит:
Мы пообщались с профессионалами, которые связали свою карьеру сначала с разработкой и системным администрированием, но со временем перешли в DevOps.
Справедливости ради стоит отметить, что спустя полгода обучения, потратив много часов и нервов, я все еще практически ничего не знала. Но мне повезло вскоре устроиться на работу джуном-питонистом. Было сложно и страшно, условия были отвратительными, а работа бесперспективной и выматывающей.
Учиться получалось скорее вопреки, чем по ходу, но больше всего огорчало, что все мои попытки понять более широкую картину или разобраться в чем-то поглубже встречали либо непонимание, либо агрессию. Мне всегда было некомфортно, если я не понимала, что и зачем я делаю.
В какой-то момент все мои коллеги-бэкендеры уволились и я стремительно выгорела, поэтому решила поискать другую работу. Учитывая, что опыт в программировании у меня был к тому моменту не слишком положительный, я подумывала о том, чтобы слегка сменить сферу деятельности (что довольно нетрудно в IT, особенно вначале).
Когда мне предложили позицию инженера по эксплуатации, я была в восторге, потому что можно было наконец узнать про все захватывающие вещи, в которые мне раньше не удавалось углубиться. На деле все опять оказалось не так уж радужно, но я многому научилась, а заодно узнала о существовании инженеров DevOps. Это звучало как отличная перспектива для профессионального роста, поэтому я начала потихоньку поглядывать на вакансии и читать про указанные в них технологии. Позже я узнала о том, что в одной из IT-компаний есть курсы DevOps и пошла туда обучаться вместе с коллегой. По ходу курса студентов периодически собеседовали на проекты и после одного из таких интервью мне предложили работу.
Это включает множество различных задач:
В ходе всей работы я мои коллеги постоянно взаимодействуем с разработчиками, тестировщиками и менеджерами. Стараемся вовлекать их в обсуждение архитектурных решений и вопросов построения процессов.
Новичку в DevOps важно понимать, что придется очень много взаимодействовать с людьми, ведь смысл методологии DevOps именно в этом. Нужно уметь договариваться. Кроме того, очень пригодится умение сохранять хладнокровие в критических ситуациях (хотя оно приходит с опытом), системное мышление (для проектирования и траблшутинга). Иногда вам придется работать в условиях, когда все сломано и ничего не понятно, поэтому любопытство, пытливый ум и терпение тоже будут кстати.
Важно уметь подмечать проблемные места, которые можно улучшить: какие процессы можно автоматизировать, какие оптимизировать, а какие и вовсе упразднить. Очень полезно уметь читать логи и правильно формулировать вопросы в Google и для коллег.
Советую изучать:
Чем меньше опыта, тем сложнее разбираться с незнакомыми технологиями. Когда одну незнакомую концепцию объясняют с помощью других, легко отчаяться, но все большие и сложные вещи можно разобрать на маленькие и простые.
Стоит начать с самого малого и потихоньку разбираться с новыми понятия. Не нужно бояться задавать глупые вопросы более опытным коллегам. Обычно людям не составляет труда кратко и доходчиво объяснить то, в чем они хорошо разбираются – это помогает сэкономить время и избежать ошибок.
Мне кажется, неопытные инженеры чаще совершают ошибки по невнимательности. Например, мой коллега однажды перепутал имя базы и вместо того, чтобы создать новую, сломал старую. А в другой раз скопировал не ту команду и вместо бекапа удалил важные данные. Важно сохранять спокойствие, быстро найти того, кто компетентен решить проблему и объяснить ему, что произошло. И вынести из происшествия уроки на будущее, конечно же.
В какой-то момент я уволился с должности старшего сисадмина и занялся поисками новой работы. Мне сделали два предложения одновременно – начальником отдела в сфере ритейла и рядового инженера в маленькой геймдев-компании. Именно во втором предложении промелькнуло это самое слово DevOps.
Я все еще до конца не понимал что это такое, но было интересно. Поэтому стал участвовать в разработке игр и развиваться в направлении DevOps. А развиваться там было куда: между ритейловым сисадмином и DevOps-инженером просто гигантская пропасть технологий.
Роль DevOps-инженера очень разнится от компании к компании. Есть определенные схожие функции, например, настройка и поддержка CI/CD пайплайнов. Часто к этой роли относят и инфраструктурные вопросы, особенно в облаках. Мне также приходилось проектировать и настраивать инфраструктуру со всеми нужными сервисами: мониторингом, логированием и так далее. Помогал командам разработки настроить их процесс, щедро сдобрив его автоматизацией и петлями обратной связи. Иногда нужно было помочь разработчикам лучше использовать возможности среды, объяснить, как правильно жить в облаке или Kubernetes.
Считаю, что DevOps – это мастер на все руки, поэтому хотя бы раз я делал в команде все сразу.
Когда человек решает стать DevOps, в первую очередь он должен понимать что это такое. К примеру, DevOps – это не должность, а методология. Важно понимать все принципы, на которых эта методология строится и все ценности, которые она пропагандирует. Среди последних – коммуникация, ее можно выделить как один из важнейших навыков для хорошего DevOps-инженера.
Нужно понимать, что каждый участник вашей команды делает, как им помочь в проблемных ситуациях, и не бояться говорить, стремиться к достижению взаимопонимания.
Из hard skills я бы выделил скрипты и арсенал поверхностного понимания технологий. К примеру сертификация уровня Associate любого облака дает такой арсенал. Чем шире арсенал, тем лучше, но это не имеет большого смысла, если нет фундамента. В роли фундамента для хорошего специалиста DevOps обычно выступает глубокая экспертиза в администрировании Unix-like систем и сетевое администрирование.
В первую очередь новичку в DevOps нужно закладывать фундамент, то есть осваивать операционные системы и сетевые технологии. Если есть достаточное понимание вышеперечисленного, стоит изучить скрипты на Bash/Python. Потом перейти к Ansible, Terraform, Jenkins, Kubernetes.
Мне вспоминается ощущение ошеломления, когда я впервые увидел список технологий, которые мне нужно было изучить на своей первой работе DevOps-инженером. Из всего списка я слышал только об одной или двух, остальные были загадкой. Сначала этот океан технологий выглядит просто непокоримым, но со временем начинаешь понимать – везде примерно одно и то же, только с разными «бантиками». Жизнь становится проще, но это не умаляет объем технологий, которые надо изучить на начальном этапе.
Другой момент, который меня удивил – это токсичные коммьюнити. Очень легко не так задав вопрос нарваться на весьма грубые, обидные или язвительные комментарии в IT-сообществах в сети. Однако сейчас тренд идет на смягчение токсичности, и зачастую новичку помогают и разжевывают интересующие его вопросы.
В итоге именно вы решаете в каком направлении двигаться – стать системным администратором, разработчиком или перейти в DevOps. Как и во многих смежных направлениях, эти роли частично пересекаются. Системные администраторы уже имеют опыт написания сценариев и могут быть знакомы с технологиями автоматизации развертывания приложений, управления конфигурациями и так далее. Многие разработчики имеют представление о системном администрировании, так что изучать неофиту придется не половину (Dev или Ops), а немного меньше.
Если вы только собираетесь освоить популярную профессию, стоит обратить внимание на курс «Старт в DevOps: системное администрирование для начинающих» образовательной онлайн-платформы Skillbox. Там вы сможете получить навыки администрирования Linux, научитесь настраивать веб-серверы и поддерживать работу сайтов, а также усвоите базовые знания для развития в DevOps-инженерии.
За год занятий с экспертами-практиками вы соберете портфолио и сможете начать карьеру системного администратора в IT-компании. Если ваша цель – стать инженером DevOps, вы сможете попрактиковаться на реальных проектах и получите базовые навыки для развития. Продолжить обучение можно на продвинутых курсах: «Профессия DevOps-инженер», «Профессия DevOps-инженер PRO» и «Инфраструктурная платформа на основе Kubernetes». Все интересующие вопросы вы сможете задать куратору в чате Telegram, а ваши домашние задания лично прокомментирует преподаватель и даст полезные советы.
Продолжаем изучать проектирование контейнеров. В этой статье речь пойдет о пространстве пользователя и почему оно так важно для разработчиков программного обеспечения.
…
Развитие сферы ИТ приводит к тому, что некоторые специальности постепенно теряют актуальность. Есть мнение, что системный администратор – одна из умирающих профессий. Разбираемся правда ли это и в каком направлении стоит развиваться сисадмину.
Основные обязанности системного администратора:
Дело в том, что системные администраторы нужны любому бизнесу, а не только связанному с ИТ. У хорошего сисадмина вся инфраструктура исправно работает, рутинные задачи автоматизированы, и создается иллюзия, будто он ничего не делает. Тут кроется главное недопонимание между работодателем и сотрудником.
В малом и среднем бизнесе на плечи системного администратора зачастую ложится много дополнительной, несвойственной ему работы – от мытья полов в серверной и монтажа СКС до обязанностей офис-менеджера и личного помощника директора. На такой должности действительно можно выгореть, тем более деньгами на ней особо не балуют.
Выход здесь один: относиться к работе как к источнику опыта и менять ее при первой возможности.
Начав с младшей позиции, можно стать ведущим системным администратором или начальником отдела информационных технологий. Сейчас должность системного администратора еще актуальна, а потребность в таких специалистах достаточно высока, однако развитие облачных технологий и автоматическое развертывание инфраструктуры забирает значительную часть их работы. Растет спрос на специалистов более высокой квалификации (сетевых инженеров) и настоящих универсалов, разбирающихся еще и в разработке – инженеров DevOps. Для системного администратора оба этих направления – хорошие варианты движения вверх по карьерной лестнице.
Главное отличие от сисадмина в том, что сисадмины чаще обслуживают готовую инфраструктуру (если не считать небольших организаций, где айтишники «от скуки на все руки»), а сетевой инженер должен уметь построить и задокументировать корпоративную сеть с нуля. Также его работа предполагает взаимодействие с активным сетевым оборудованием таких вендоров, как Cisco, Mikrotik, Juniper и т.д.
Что касается железа, сетевой инженер не всегда работает с ним напрямую. Благодаря виртуализации и современному софту можно превращать конечные устройства в маршрутизаторы и строить более масштабируемые и отказоустойчивые сети. Большой разницы для инженера при работе с физическим или виртуальным оборудованием нет: логика принятия решений и протоколы у них одинаковые.
Чтобы стать сетевым инженером вы должны знать:
Если же кроме системного администрирования вас притягивает и разработка, стоит задуматься о стоящей на стыке этих областей профессии.
Инженер DevOps – специалист, который внедряет эти методики в рабочий процесс.
Когда разработчики проекта начинают писать программу, они советуются с devops-ами о том, в каком окружении будет работать код. Инженеры DevOps предоставляют эту информацию и корректируют моменты, которые связаны с конкретной спецификой окружения. После того, как программисты закончили работу с кодом, инженер DevOps должен довести его до клиента: организовать компиляцию, сборку, тестирование, развертывание на тестовых окружениях. На этой стадии специалист вникает в процессы ручного и автоматизированного тестирования.
Также в задачи специалиста входит написание большого количества кода на скриптовых языках: Python, GoLang или Bash.
Чтобы стать инженером DevOps вы должны знать:
Если вы только начинаете свой путь в ИТ, будет нелегко, поскольку багаж знаний в этой сфере требуется солидный. Большинство переходят в DevOps, имея опыт разработки или администрирования: в этом случае останется освоить примерно половину требуемого материала.
Сетевой инженер и инженер DevOps – востребованные профессии. Опытные специалисты могут рассчитывать на оклад более 200 000 в месяц, даже работая удаленно. При этом обучение не должно забрать у вас много сил и времени, если вы уже имеете опыт работы системным администратором.
Если вы не стоите на месте и хотите развиваться, обратите внимание на факультет «Сетевой инженер» образовательной онлайн-платформы GeekBrains. За одиннадцать месяцев вы изучите основы сетевых технологий, коммутацию и маршрутизацию, безопасность, масштабирование сетей и автоматизацию сетевой инфраструктуры, сделаете 2 проекта для портфолио, а также получите диплом о переподготовке и помощь в трудоустройстве.
Эксперты по информационной безопасности, 4 тематических секции, воркшопы, встречи и конкурсы в городском пространстве Санкт-Петербурга.
— Читать дальше «Конференция ZeroNights 2021»
…
EPAM набирает команду разработчиков, инженеров, тестировщиков и аналитиков для работы в проектах Выделенного Центра Разработки. Оффер через 48 часов и welcome-бонус в размере одного оклада.
— Читать дальше «Project Hiring Week»
…
Библиотека программиста продолжает серию интервью с представителями IT-индустрии. Наш корреспондент побеседовала с Алексеем Шараповым, Head of DevOps компании «ЦРПТ». Он рассказал о своем пути в отрасли, какие требования к кандидатам предъявляют работодатели и стоит ли считать DevOps профессией или только ролью.
Библиотека программиста: Добрый день, Алексей! Расскажите, пожалуйста, для начала о своем бэкграунде. Где учились, работали, прежде чем стать инженером DevOps?
Алексей Шарапов: Учился в Ярославском Государственном Техническом Университете по специальности «Органическая химия», но вскоре понял, что больше люблю разработку и все, что с ней связано.
Еще в университете я, читая разные статьи, наткнулся на самые первые упоминания DevOps. Это был примерно 2013 год, статья Барух Садогурского, которая меня невероятно впечатлила. Тогда было абсолютно непонятно что такое DevOps, кроме того, что этим занимаются парни, которые погружены в администрирование и разработку с одинаковой интенсивностью. Мне понравилось, загорелся идеей и решил для себя, что буду заниматься именно DevOps.
После окончания университета работал сначала на «Почте России», позже в небольшой компании фармацевтического завода, а разработкой занимался на фрилансе, искал клиентов на бирже Upwork. Со временем попал в «СберТех» в первую волну DevOps и закрутилось.
Б.П.: С чего начался ваш путь в профессию, почему решили уйти именно в DevOps?
А.Ш.: Мой путь в профессии начался с двух направлений параллельно. На основной работе я занимался администрированием парка серверов и в это же время разрабатывал сайты на фрилансе. После этого более глубоко погрузился в администрирование, Linux сервера. При этом разработку не бросал никогда, делал простые задачи, изучал Java и даже брался за задачи по разработке наравне с коллегами. Также проходил курсы по разработке на Java для более глубокого погружения, курсы по PHP и JavaScript, так как хотелось больше узнать о программировании изнутри.
Такой план действий изначально был выбран для понимания полного цикла как администрирования, так и разработки, изучения инструментов изнутри. И спустя пять лет таких упражнений стало более понятно, как строить процессы взаимодействия в командах.
Б.П.: Дайте свое определение DevOps.
А.Ш.: DevOps – это практики, направленные на взаимодействие между отделом разработки и отделом Ops, которые помогают быстрее поставлять продукт с меньшим количеством ошибок и проблем.
Б.П.: По вашему мнению, DevOps – это профессия или часть обязанностей?
А.Ш.: На мой взгляд DevOps – это часть обязанностей, процесс, но никак не профессия. Мне очень нравится, когда разработчики или администраторы глубоко погружаются в эти вопросы и сами могут решить большую часть проблем.
Б.П.: Опишите основные требования, которые предъявляют к специалистам разных уровней работодатели.
А.Ш.: Требования к специалистам с одной стороны растут, даже к джуниорам. С другой стороны – нехватка хороших инженеров DevOps позволяет на некоторые вещи закрыть глаза.
На данный момент я определяю требования к специалистам разных уровней следующим образом:
Б.П.: Опишите ваш типичный рабочий день.
А.Ш.: Типичный день обозначить очень сложно, так как каждый приносит что-то новое и интересное.
В основном мое рабочее утро начинается с разбора почты, базовых нотификаций. Далее в зависимости от планов на день это может быть разбор старых проблем, фикс багов собственного кода, написание нового для нового функционала. Достаточное количество времени занимает общение со смежными отделами, разбор идей, которые генерируют разработчики и администраторы, консультации и ответы на вопросы по поводу инструментария. Ну и конечно нельзя забывать про обед.
Б.П.: Какой стек технологий вы используете в работе?
А.Ш.: Стек технологий, который я использую в работе, достаточно широк. Это и K8S для запуска сервисов, GitLab CI для процессов CI (непрерывной интеграции), Ansible в связке с Python – для автоматизации всего.
Вокруг этих инструментов сосредоточен еще очень большой набор технологий. Например, Helmfile для накаток на разные среды, Argo CD в других проектах, иногда приходится писать на Go (например для экспортеров), где-то копаться в Java.
Б.П.: Какие технологии сейчас становятся более популярными, что учить, чтобы быть на шаг впереди остальных?
А.Ш.: Я бы выделил K8S, сейчас без него никуда. А также весь около K8S стек технологий. Это и Helm и GitOps-инструменты. Ну и облачные платформы – AWS и GCD идут впереди планеты всей и позволяют делать невероятные вещи.
Б.П.: К каким трудностям в профессии специалист DevOps должен быть готовым?
А.Ш.: Первое, что я выделил бы – понимание того, что коммуникации будут составлять достаточно большую часть вашей работы. Второе – вы должны всегда успевать за стеком разработчиков, за их изменениями и нововведениями. Ну и третье – отслеживать, что нового в индустрии, а новостей всегда много: K8S без Docker, Ansible без модулей и все в этом духе. Высокий темп в этой области превосходит многие другие.
Новости я чаще всего узнаю на конференциях, хотя информация там бывает немного запоздалой. Кроме того, читаю официальные блоги, стараюсь вовремя узнавать о релизах отдельных инструментов и общаюсь с коллегами из других компаний для обмена опытом и новостями в индустрии.
Б.П.: Сколько лет вам понадобилось, чтоб вырасти до уровня senior? Что больше всего повлияло на ваш рост, как специалиста?
А.Ш.: До senior я морально вырос спустя семь лет с начала работы. Сейчас я лид направления DevOps в компании, руковожу лидами DevOps в группах разработки, но не бросаю и работу руками. Работаю с командами разработки, эксплуатации. Стараюсь уделять внимание и той и другой стороне.
На мой рост больше всего повлияли желание и увлеченность. DevOps как направление меня невероятно драйвит, а желание развиваться в профессии до сих пор такое же сильное, как и вначале карьеры.
Б.П.: Посоветуйте начинающим специалистам: как и где лучше получить знания, какие ресурсы будут полезны, что почитать и какие видеолекции, видео посмотреть, и прочее.
А.Ш.: В первую очередь, важен реальный опыт. Будь я на месте новичка в сфере – общался и советовался бы с опытными коллегами и не гнушался бы любой работы, которая будет развивать меня как специалиста.
Самая моя любимая книга для новичков – «Unix и Linux: руководство системного администратора», Немет Эви, Снайдер Гарт.
Полезно смотреть видеозаписи крупных российских и зарубежных конференций, таких как DevOpsConf, KubeCon, DockerCon.
Из ресурсов я читаю в основном блоги на официальных сайтах Docker, K8S, Red Hat, ну и Хабр, он до сих пор несет много полезной информации.
Самостоятельно получить навыки и знания для работы инженером DevOps, судя по истории героя этой статьи, будет непросто. Вам понадобится много времени и сил на изучение необходимых в профессии технологий.
Если вы находитесь только в начале пути, стоит обратить внимание на курс Факультета DevOps образовательной онлайн-платформы GeekBrains. Эксперты-практики из ведущих российских технологических компаний научат вас использовать методологии Agile и Scrum, оптимизировать CI/CD и работать с облачными технологиями. Курс подойдет как новичкам в IT, так и опытным специалистам, которые хотят сменить направление.
За 18 месяцев обучения вы освоите актуальную программу по DevOps, решите шесть проектных задач и создадите итоговую работу с сокурсниками, а также изучите основы Python и облачных технологий, работу с сервисами Linux и Kubernetes.
Успешно окончившим курс студентам HR-специалисты GeekBrains помогут создать резюме и предложат вакансии. Гарантия трудоустройства закреплена в договоре.
Свежие комментарии