DevOps *

В августе Southbridge провели интенсив по Кубернетес Слёрм-1.
В октябре мы его повторили (Слёрм-2) и добавили продвинутый курс (МегаСлёрм).

Удовольствие не из дешевых: Слёрм-2 стоил 35 000 ₽, МегаСлёрм — 75 000 ₽ (онлайн 15 и 35). Я общался с заказчиками, участниками и спикерами, проводил опросы и собирал статистику.

Вот мои наблюдения о том, кто что получил за свои деньги. Многие выводы можно экстраполировать на платные курсы в целом.

1. Слёрм помогает определиться по Кубернетес

Оказалось, понимание «нам подходит Кубернетес» ценнее, чем «мы можем в Кубернетес».

Руководители, отправляя своих инженеров (разработчиков, администраторов) на Слёрм, декларировали: «Пусть пощупает технологию и решит, подходит ли она для наших задач».

Участники Слёрма-1 рассказывали: «После интенсива мы внедрили Кубернетес, теперь я приехал на МегаСлёрм».

3 дня интенсива — в самый раз, чтобы увидеть технологию в полный рост, а не в режиме «Рабинович по мануалам установил». Тут даже вопросов нет, оно того стоит.

Часто в рамках проверки Pull Request, помимо, собственно, code review, возникает необходимость проделывать набор рутинных проверок. Некоторые проверки могут касаться оформления PR. Другие — проверять смежные условия, которые составляют основу процесса принятия изменений.
Если рутинные проверки не автоматизированы, человек может начать их забывать или обходить. Потому, что рутина — это скучно.

Visual Studio Team Services предлагает довольно удобную инфраструктуру для обработки Pull Request. Сюда входят настраиваемые политики merge builds, назначение ревьюеров, правила слияния принимаемых изменений. Все это дополненной удобной системой обсуждения и комментирования кода.

Мощнейшим инструментом расширения процесса Pull Request являются внешние подключаемые политики.

Об их создании и использовании и поговорим (и посмотрим код)

Для того чтобы быстро поднять рабочее окружение существует много способов. Один из них — поднять все необходимые сервисы в Docker-контейнерах. Чтобы ускорить создание новых проектов на Yii-framework я написал такую небольшую инструкцию, которую используют разработчики в нашей команде.

• Как методы и процессы разработки отражаются на эксплуатации?
• Что движет каждой стороной конфликта?
• В чем первопричина разногласий?

Эта статья является свободной интерпретацей официального руководства Creating Highly Available Clusters with kubeadm для Stacked control plane nodes. Мне не нравятся сложный язык и примеры использованные в нем, поэтому я написал свое руководство.

Если у вас появятся какие-либо вопросы или вам будет что-то неясно, обратитесь к официальной документации или спросите Google. Все этапы описаны здесь в максимально простой и сдержанной форме.

Вчера стартовал Слёрм-2, интенсив по Кубернетес. Первое выступление: Павел Селиванов рассказывает, как участники Слёрма будут осваивать Кубернетес, а потом читает лекцию по Docker. В чате жаловались, что "Докер за час — это далеко за гранью", на что Павел ответил: "Наша задача — не изучить Докер, а согласовать точки зрения на Докер, чтобы в дальнейшей работе не было разночтений".

С радостью сообщаем о выпуске GitLab 11.4 с невероятными обновлениями, призванными помочь командам разработчиков работать вместе более эффективно. Большинство команд разработчиков, внедряющих концепцию DevOps, стремится сократить продолжительности рабочего цикла. Поэтому приветствуются такие улучшения, которые сокращают потери времени и лишнюю работу и тем самым позволяют ускорить поставку приложений и добиться лучших результатов в бизнесе.

В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.

Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".

Однако мир БД традиционно стоит особняком вдалеке от этой феерии прогресса и технологий. Процесс разработки и сопровождения БД не меняется годами и продолжает вселять ужас и страх в разработчиков, администраторов и пользователей по всему миру. Но возможно ли представить БД в виде обычного кода? Приблизиться к основному процессу разработки, использовать общие инструменты и подходы? Об этом под катом.

Сергей Бондарев ведет половину тем на интенсивах по Кубернетес Слёрм-2 и МегаСлёрм.
На Слёрм-2 еще не поздно зарегистрироваться онлайн, а на МегаСлёрм даже можно успеть приехать.

Тотальная стандартизация

Я готовил этот материал для выступления на конференции и спросил у нашего технического директора, в чем главная фишка Kubernetes для нашей организации. Он ответил:

Разработчики сами не понимают, сколько лишней работы делали.

Видимо, его вдохновила недавно прочитанная книга «Factfulness» — сложно заметить незначительные и непрерывные изменения к лучшему, и мы постоянно упускаем из виду свой прогресс.

Но переход на Kubernetes точно нельзя назвать незначительным.

Прошел первый день РедСлёрма, интенсива по системному администрированию.
На РедСлёрме системные администраторы Southbridge рассказывают, что и почему используют в работе. Отдельное спасибо Selectel за ресурсы для практики.

На РедСлёрм собралось 40 человек (14 в зале, 26 в онлайне). Учитывая, что повторять РедСлёрм мы больше не будем, получился милый эксклюзивный междусобойчик.

По сравнению с первым Слёрмом не хватает лета, треша и ощущения потной и кровавой победы над обстоятельствами. Там мы вечером собирались на веранде, открывали ноутбуки и пиво, и сидели до полуночи. Было что-то среднее между хакатоном и бардовским слетом.

Как-то я уже писал тут о переезде из Азии в Европу, а теперь хочу написать, что я в этой Европе делаю. Есть такая профессия — DevOps, точнее нет, но так получилось, что это именно то чем я сейчас занимаюсь. Сейчас для оркестрации всего что бежит в докере мы используем rancher, о чем я тоже уже писал. Но вот случилось ужасное, вышел ранчер 2.0 который переехал на kubernetes (дальше просто k8s) и поскольку k8s сейчас действительно стандарт для управления кластером, возникло желание тоже построить всю инфраструктуру заново с блекджеком и библиотекаршами. Что еще добавляет пикантности это то что компания постоянно нанимает разных специалистов из разных стран и с разными традициями и кто-то и собой приносит puppet, кому-то милее ansible, а кто-то вообще считает что Makefile + bash — наше все. Поэтому однозначного мнения как все должно работать просто нет, а очень хочется.

Предварительно был собран такой зоопарк технологий и инструментов:

Наша команда отвечает за эксплуатацию и развитие большого корпоративного продукта.
В начале 2017 года, передохнув от крупного внедрения и перечитав "lessons learned", мы твердо решили пересмотреть процесс разработки и доставки нашего приложения. Нас беспокоила низкая скорость и качество доставки, не позволяя нам обеспечивать уровень сервиса, который от нас ожидают заказчики.

Пора было переходить от слов к делу — менять процессы.

В этой статье будет кратко рассказано о том с чего мы начинали, что делали, какая ситуация сейчас, с какими трудностями столкнулись, что пришлось пока оставить за скобками, что ещё планируем делать.