DevOps *

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

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

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

Привет, друзья. Как вы успели заметить, мы очень любим Kubernetes. Так, так и даже так.

Поэтому мы, недолго думая, решили запустить свою собственную серию митапов по K8S в Mail.Ru Group – встречайте @Kubernetes Meetup.

Прим. перев.: Оригинальная статья была написана техническим писателем из Google, работающим над документацией для Kubernetes (Andrew Chen), и директором по software engineering из SAP (Dominik Tornow). Её цель — доступно и наглядно объяснить основы организации и реализации high availability в Kubernetes. Нам кажется, что у авторов получилось, поэтому мы рады поделиться переводом.



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

Kubernetes — масштабируемый и надёжный движок оркестровки контейнеров. Масштабируемость здесь определяется отзывчивостью в присутствии нагрузки, а надёжность — отзывчивостью в присутствии отказов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доброго времени суток!

Рано или поздно в организациях возникают проблемы с распространением js модулей между проектами, настало то время когда в нашей компании встал этот вопрос.

Копировать и вставлять код это путь на темную сторону, поэтому было принято решение писать не просто js код, а создавать из него npm пакеты чтобы распространять между своими проектами.

Поиск бесплатных, частных npm репозиториев завел в тупик, а использование частных репозиториев на npm требует платы (а это не наш менталитет).

Поскольку в офисе есть сервер, который работает всегда(почти), было решено развернуть локальный npm.

В чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.

Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:

• Какие бывают требования и чем они характеризуются,
• Типы задач и порядок их описания в Issue tracker,
• Как оформлять User story и Tech story,
• Как описывать баги,
• Настройка конвейера развертывания.

Опытные инженеры вряд ли узнают из статьи что-то новое, но надеемся, что начинающим специалистам эта информация пригодится.

Привет, Хабр! В данной статье я хочу поделиться опытом разворачивания тестового сервера для команды разработчиков. Вкратце суть проблемы — есть команда разработки и несколько проектов на php. Пока нас было мало и проект был по сути один, то использовался 1 тестовый сервер и чтобы показать задачу заказчику — разработчик «столбил» сервер на определенное время. Если «окон» по времени не было, то приходилось ждать. Со временем рос коллектив и сложность задач, соответственно увеличивалось время проверки и занятость тестового сервера, что негативно влияло на сроки выполнения и премию. Поэтому пришлось искать решение и оно под катом.

Как поднять High-Availability Kubernetes кластер и не взорвать мозг? Использовать Kubespray, конечно же.

Kubespray — это набор Ansible ролей для установки и конфигурации системы оркестрации контейнерами Kubernetes.

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров.

Осторожно, под катом 4 скриншота elasticsearch и 9 скриншотов prometheus!

Павел Селиванов — основной спикер на интенсивах по Кубернетес (Слёрм-2 для тех, кто только знакомится с технологией и МегаСлёрм для тех, кто уже работает с Кубернетес).
25–27 октября — Слёрм-2
29–31 октября — МегаСлёрм

Если вы зарегистрируетесь до 18 октября, скажите менеджеру «я с вебинара», и вам сделают скидку 10%.

Слёрм-3 намечен на июнь '19.

TL;DR вебинара:

1. Если вы рассчитываете на волшебную таблетку, которая сама по себе решит ваши проблемы, то Kubernetes вам не нужен. На этом можно закончить просмотр/чтение.

Прим. перев.: оригинальная статья была недавно опубликована в блоге Kubernetes и написана сотрудниками компаний Google и Huawei (Jing Xu, Xing Yang, Saad Ali), активную деятельность которых вы непременно видели в GitHub'е проекта, если когда-либо интересовались фичами и проблемами K8s, связанными с хранением данных. Инженеры рассказывают о предназначении снапшотов томов (volume snapshots), их текущих возможностях и основах работы с ними.

— Усталым хипстерам глаголим истину.

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

Чтобы понять и простить дальнейший текст вам понадобятся поверхностные знания как работать с Kubernetes на уровне пользователя и какие-нибудь слухи про Helm.

19 сентября в Москве состоялся первый тематический митап HUG (Highload++ User Group), который был посвящён микросервисам. На нём прозвучал доклад «Эксплуатация микросервисов: размер имеет значение, даже если у вас Kubernetes», в котором мы поделились обширным опытом компании «Флант» в области эксплуатации проектов с микросервисной архитектурой. В первую очередь он будет полезен всем разработчикам, задумывающимся о применении этого подхода в своём настоящем или будущем проекте.



Представляем видео с докладом (50 минут, гораздо информативнее статьи), а также основную выжимку из него в текстовом виде.

NB: Видео и презентация доступны также в конце этой публикации.

Кубернетес — распиаренная технология. Те, кто не умеет работать с кубом, пытаются внедрить его туда, где он не нужен. Страдают все: заказчики, админы, репутация Кубернетес.

Southbridge организует интенсивы по k8s. Мы хотим, чтобы на них приезжали те, кому куб действительно полезен, и потом нормально с ним работали.

15 октября в 19:00 Павел Селиванов проведет вебинар «Нужен ли вам Kubernetes».

Темы вебинара:

— DevOps как правильный подход к Kubernetes
— Сильные и слабые стороны Kubernetes
— Область применения Kubernetes
— Требования к эксплуатации k8s
— Требования к разработке под k8s
— Заказы на внедрение k8s (потребность в админах, знающих k8s)
— Слёрм: что дает Слёрм-2 и МегаСлёрм в освоении k8s.

UPD: Запись и расшифровка вебинара

Дежурство — это важная составляющая большинства современных организаций. Ведь часто бывает, что проблема прилетает и в 3 часа ночи. Но кто должен дежурить? И как организовать этот процесс так, чтобы он имел смысл?

Заглядывайте под кат, там Барух Садогурский (@jbaruch) и Леонид Игольник (@ligolnik) расскажут хоррор-историю про одного неудачливого дежурного. Помните Васю, которому всегда приходилось фиксить баги бухому в три часа ночи? Это только начало.



Материал подготовлен на основе выступления Баруха и Леонида на осенней конференции DevOops 2017.

В прошлом году у организации CNCF (Cloud Native Computing Foundation), помогающей развиваться таким Open Source-проектам, как Kubernetes и Prometheus, появилась программа сертификации CKA (Certified Kubernetes Administrator). В начале этого лета мы решили в ней поучаствовать и получили первые сертификаты для своих сотрудников. О том, что это, зачем и как происходит, с удовольствием рассказываем всем любопытствующим читателям хабры.

Всего несколько дней осталось до конференции DevOops 2018: она пройдет в конгресс-центре гостиницы «Park Inn by Radisson Пулковская» 14 октября. Вы уже знаете про 17 докладов и сотни участников, но мы подготовили кое-что ещё.

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

Ссылка на трансляцию

В трансляцию попадут только первые четыре доклада из семи (до Баруха включительно, и интервью после него). Видео по ссылке заработает утром в воскресенье, когда начнётся DevOops. Cейчас там можно посмотреть программу первого зала.

Для тех же, кто пойдёт вживую, хочется напомнить несколько дополнительных фишек.