Масштаб моей инфраструктуры на работе не велик — число серверов можно пересчитать по пальцам рук, часть в облаке, часть на своём железе. И стек технологий достаточно проверенный: в ряде проектов это PHP+MySQL, в одном случае NodeJS+MongoDB. Немного Go, и немного 1С. Обычный малый, или быть может, слегка средний бизнес.
Я стараюсь по минимуму хостить что-то у себя, по максимуму использовать готовые SaaS сервисы: мониторинг в NewRelic и okmeter.io, YouTrack в облаке, Bitbucket для репозиториев и даже Continues Integration в облаке Bitbucket Pipelines, о чём я рассказывал в прошлом выпуске, короче, по максимуму в SaaS! Для малого бизнеса и моих нагрузок все эти SaaS сервисы укладываются в минимальные или даже бесплатные тарифные планы, нет смысла заниматься обслуживанием инфраструктуры самостоятельно.
Тем не менее, какие-то сервера всё-таки есть. И очень долгое время это были сервера-снежинки: хаотичные настройки, наслоения различного софта различных версий, слабая документация. Случись что с таким хрупким сервером-снежинкой, пришлось бы потратить целый день на переустановку, вспоминая что там вообще должно быть.
Частично у меня были наборы bash скриптов и инструкций не первой свежести, которые частично помогли бы, но в целом это не порядок.
Чтобы навести порядок я где-то год назад начал использовать Ansible, описав текущую инфраструктуру и поддерживаю плейбуки в актуальном состоянии.
Если не слышали про Ansible, или слышали, но не в курсе что это и зачем, поясню в двух словах. Допустим, нам нужно установить на сервер php-fpm и nginx и подложить правильные файлы конфигурации.
Чтобы автоматизировать, можно написать простейший bash скрипт, который последовательно выполнит нужные команды apt install и скопирует файлы конфигурации, которые должны идти в комплекте с этим скриптом.
Ansible — это утилита написанная на Python, для которой мы подготавливаем некий yaml файл (называемый плейбуком), в нём описываем требуемую конфигурацию софта на сервере. Запускаем утилиту ansible-playbook с yaml-плейбуком в качестве параметра и Ansible производит установку и настройку описанной конфигурации на удалённом сервере.
Обычно запуске самой утилиты ansible-playbook делается локальной машине и он ходит на сервер по ssh, в том числе перекидывает туда с локальной машины заранее подготовленные файлы конфигов.
Казалось бы, это те же bash скрипты, только в профиль. Но выходит удобнее, понятнее, yaml файлы с описанием конфигурации банально проще читать. Специально сейчас не углубляюсь в детали и примеры. Возможно, как-нибудь запишу отдельный подкаст про мой опыт работы с Ansible.
Кстати, это не единственный в природе инструмент оркестрации, из тех что на слуху есть ещё Chef, Puppet, Salt Stack. Я их не пробовал, но что я читал в обзорных статьях и слышал в подкастах, в частности в DevOps Дефлопе и Hangops.ru — Ansible проще и идеально подходит для маленьких и средних инфраструктур.
Из популярных DevOps инструментов я также использовал (и сейчас использую) Docker для окружения разработки в некоторых проектах.
Также я что-то читал и слышал о Hashicorp Stack (такие инструменты как Packer, Terraform, …), то тут то там всё чаще всплывал Kubernetes.
Одновременно с этим я ощущал, что мои знания не систематизированы и обрывочны, хотелось всё разложить по полочкам. Я в первую очередь разработчик, а не системный администратор, у меня не было желания и времени углубляться в темы администрирования Linux, но хотелось овладеть базовыми инструментами на стыке Dev и Ops.
И вот летом прошлого года я наткнулся на описание курса по DevOps на платформе Otus. Сейчас это, возможно, прозвучало как реклама. На самом деле это не реклама в классическом виде, т.е. я записываю этот подкаст не по заказу, хочу лишь поделиться своим опытом и путём, который, во многом, был сформирован этими курсами.
Прочитав программу, я выделил для себя темы которые были однозначно актуальны (Ansible, Docker), и прочие для расширения кругозора. Финальным аргументом «ЗА» стало то, что среди преподавателей увидел знакомые имена из подкастов про DevOps, а к этим ребятам уже было какое-то доверие. Также авторами и преподавателями на курсе являются специалисты из широко известной в узких DevOps кругах компании Express42.
Вкратце, пройдусь по некоторым пунктам программы: общие слова про DevOps, история развития и всё такое, ChatOps, VPN и Bastion Host, знакомство с Google Cloud Platform, Packer, Terraform, Ansible, тестирование Ansible ролей в Vagrant, Docker, Docker Machine, Docker Compose, технологии непрерывной поставки на примере GitLab CI, мониторинг и алертинг, Prometheus и Grafana, логирование, distributed tracing, контейнерная оркестрация в целом и Docker Swarm и Kubernetes в частности, Ingress, Helm, Интеграция Kubernetes в GitlabCI, Масштабирование в Kubernetes.
Как видите, программа довольно мощная.
Я проходил курс с первым потоком (первым набором) и иногда это было заметно, материал был шероховат. Иногда в презентациях были ошибки или опечатки, но они быстро разрешались либо смекалкой, либо обсуждением в Slack чате, чувствовалось что ведущие курса реально переживали за своё дело, старались помочь, разъяснить, исследовать возникшие проблемы – честно говоря, я такого не ожидал!
Сквозной нитью через все занятия проходило некое приложение, аналог Reddit, инфраструктуру для которого мы постепенно описывали и разворачивали различными инструментами. Практические занятия, на мой взгляд, составляют 80% всей ценности в этом курсе и составлены они весьма хорошо. Представляю какой титанический труд был проделан для проектирования и описания всей этой учебной инфраструктуры.
Самой большой трудностью для меня было то, что часть учебного приложения написана на Ruby и puma, с которыми я никогда не работал и не имею никакого опыта. Править код приложения не требовалось, но были сложности с установкой и настройкой systemd сервиса puma с использованием rvm — эта часть была задана как ДЗ. Через час слепых попыток по мотивам ответов на StackOverflow я понял, что просто теряю время. Разбираться с нюансами запуска Ruby мне было совершенно не интересно и не практично, я посмотрел как выполнили это задание мои коллеги по курсу (другие студенты) и просто использовал их решение. Таких моментов было несколько и я не стеснялся брать чужие решения, если считал тему не интересной для собственного глубокого погружения.
Домашние задания обычно содержали основную задачу и дополнительную задачу «со звёздочкой», которую можно выполнять по желанию. И тут опять же – некоторые мне были реально интересны и я погружался в тему, а некоторые задания «со звёздочкой» пропускал, чтобы не тратить время и идти дальше.
Большую часть лекций я смотрел в записи, т.к. время online вещания лично для меня было не удобно. Кажется, всего 3 лекции я посмотрел в режиме реального времени. И оказалось это даже эффективнее. Во-первых, записи я смотрел с ускорением 1.25-1.5x – очень экономит время без ущерба восприятию материала. Во-вторых, мог ставить на паузу, некоторые лекции смотрел в метро по дороге.
По ходу курса я сильно отстал, пропустил около 1,5 месяцев, но не чувствовал себя «за бортом», потому что получал помощь и полезные советы от преподавателей на ровне со всеми. Судя по чату, больше меня отстал всего один человек и это даже как-то подбадривало, что я не самый последний.
В конце был дипломный проект, по желанию, но только для тех кто сдал домашние работы по 23 лекцию включительно (всего лекций было около 30). Я поставил себе цель наверстать эти лекции и сдать домашние задания вплоть до 23-го, чтобы переходить к проекту. Таким образом я сознательно пропустил последнюю часть курса про Kubernetes, мне банально не хватало времени, зато успешно поработал над дипломным проектом.
В качестве дипломного проекта предлагалось готовое приложение, которое нужно было развернуть в Google Cloud Platform с использованием лучших практик и полученных знаний. Выбор конкретных инструментов оставался за студентом. Как вариант, можно было использовать своё собственное приложение.
Я взял своё приложение, над которым трудился по работе. Сначала описал предполагаемую архитектуру и обосновал выбор инструментов в отдельном документе в Google Docs, расшарил в Slack чате, получил пару рекомендаций, начал работать.
Как я быстро обнаружил, дипломный проект является важной частью обучения – это закрепления материала. Пересматривая слайды старых презентаций и выполненное мной когда-то ДЗ, некоторые темы открывал для себя в новом свете. И, хотя эти темы были давно пройдены, я не стеснялся задавать свои свежие вопросы в чате и получал помощь от коллег-студентов и преподавателей.
По ходу дипломной работы пришлось уменьшить амбиции касательно архитектуры, иначе я бы просто не успел к сроку показа первой минимально-рабочей версии. Успел! Дмитрий Мишенко, один из преподавателей, сделал очень подробное ревью, показал слабые места в архитектуре, за что ему огромное спасибо!
В итоге я успешно сдал более-менее работающий проект, получив зачёт. А ещё через пару недель, доведя всё до ума, вывел этот проект в production, ведь это с самого начала была реальная живая задача по работе, которая к тому же прошла тщательное ревью специалистом из Express 42. Если бы я нанимал компанию Express 42 в качестве внешних консультантов на проект, их работа могла бы оказаться дороже, чем я заплатил за курс обучения на Otus. Такой лайфхак, берите на заметку ;)
Пропущенные лекции и ДЗ по Kubernetes так и лежат на моём компьютере, возможно, я к ним вернусь, но уже без возможности получить проверку домашней работы.
В конце курса выдаётся сертификат. Наверное, он доступен где-то в личном кабинете, но, честно говоря, вряд ли он мне пригодится.
Также было предложение пройти собеседование в компаниях-партнёрах: Avito, Крок, Новые облачные технологии, EPAM, Sitronics, Лаборатория Касперского, ЛАНИТ и Яндекс. Я отказался, т.к. вакансии operations инженера, связанные с работой над инфраструктурой, меня не интересовали. Я лишь хотел подтянуть свои знания современных инструментов, чтобы стать более эффективным и полезным как разработчик. Мне всё-таки больше нравится создавать софт, а не эксплуатировать.
В общем, материалом курса и самим процессом остался очень доволен. А результат, в частности реально запущенный проект, превзошёл все мои ожидания!
Для кого порекомендую подобные курсы? Для тех, кто не хочет тратить время на самостоятельный сбор информации и не знает, а что именно нужно изучать и зачем. На курсе очень эффективно всё разложат по полочкам, и главное, замотивируют применять лучшим практики и следовать философии DevOps! Звучит прям как секта какая-то. На том же Otus раз в несколько месяцев происходит набор в новый поток — посмотрите расписание.
Ну а если у вас и так глаза горят и вы знаете, что вам сейчас нужно, например, тот же Docker или Kubernetes — можно и без курсов, главное погрузиться в профессиональную среду: зайдите в соответствующие телеграм чаты, подпишитесь на нужных людей в твиттере, ходите на митапы, в том числе бывают online митапы, как hangops.ru, и, наконец, слушайте подкасты. Подкасты – это интересно, не напряжено и расширяет кругозор.
Всем DevOps!
Отзыв взят с сайта mooc.ru
