DevOps *

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

Очень кстати, в недавно вышедшем релизе Gitlab 14.1, появился долгожданный функционал хранения Helm-чартов во встроенном Package Registry. Отлично, заодно и разберемся, как его использовать.

Kubernetes используют так или иначе сейчас примерно все, но и задачи решаются совсем разные. Я расскажу про наши требования и разработанные под них решения для управления множеством кластеров. По теме GitOps не так много статей и обсуждений на Хабре, в отличие от англоязычных источников, поэтому будет интересно и услышать мнение тех, кто применял подход на своей практике.

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

Первая часть вышла более двух месяцев назад.
После второй с сайта убрали Яндекс.Метрику.
Надеюсь, после третьей приведут инфраструктуру в порядок.

Infrastructure as Code — ключевой элемент наиболее эффективных инженерных сетапов. То, как сейчас DevOps-инженеры взаимодействуют со своей инфраструктурой — это несомненно большой скачок вперед. Но тем не менее спорные моменты с определением и лучшими практиками IaC до сих пор есть. Эта статья стремится четко описать IaC, его преимущества и важные ограничения.

Infrastructure as Code, или сокращенно IaC, — это фундаментальный сдвиг не только для Ops в том, как они подходят к провизионированию и обслуживанию инфраструктуры, но и в разработке программного обеспечения в целом. Несмотря на то, что за последние несколько лет IaC де-факто зарекомендовал себя как отраслевой стандарт, многие до сих пор спорят о его определении, лучших практиках и ограничениях.

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

Команда Data Phoenix Events приглашает всех, 31 августа в 19:00, на третий технический вебинар из серии "The A-Z of Data", который будет посвящен превращению исследования в продукт с использование Hydrosphere.

Предыстория: выбирали сертифицированное облако для всякой там сертифицированной жизни. Остановились на кое-каком B2B-колоссе, руководство заключило договор, и отделу SRE пришлось работать с облаком на основе VMware vCloud Director. И, как подобает секте свидетелей Infrastructure as Code, хотелось поменьше сидеть в веб-морде облака и больше -- в конфигурациях какого-нибудь Ansible и Terraform.
Эта статья - плод нескольких вечеров девопсера и бог знает скольких дней и ночей CTO. По горячим следам, поэтому, возможно, она несколько скомканная. Тем не менее, если вы столкнулись с облаком на основе vCloud - будет интересно.

20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.

Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер. 

Во второй части мы перенесемся на несколько месяцев вперед - в март 2013, когда докер был представлен на конференции PyCon. На тот момент он уже обладал практически всеми знакомыми нам функциями. А в третьей части я постараюсь рассмотреть переход Docker с LXC на собственную разработку, произошедший годом позже.

Привет! Меня зовут Александр Петровский, я инженер в DINS. Я работаю в команде, которая участвует в разработке сервисов облачной телефонии и видеоконференций для RingCentral. Каждый из них состоит из большого количества микросервисов.

Когда мы мигрировали один из наших микросервисов с CentOS 7 с ядром 4.19 на Oracle Linux 7 с ядром 5.4, мы заметили рост утилизации процессора на наших stress/performance-тестах. В статье я расскажу, как мы исследовали причины роста утилизации процессора сначала в user-space, а потом и в kernel-space и о том, к какому результату это нас привело.

Команда Data Phoenix Events приглашает всех, 25 августа в 19:00, на второй технический вебинар из серии "The A-Z of Data", который будет посвящен мониторингу ML моделей в продакшене.

Тех, кто работал с Kubernetes, вряд ли удивит ситуация, когда внезапно пришла идея по автоматизации, унификации, преобразованию чего-либо в кластере, но так, чтобы не волноваться за конечный результат. Когда возникает потребность в какой-то песочнице, чтобы провести тестирование, проверить гипотезу «на коленке», не используя рабочий Kubernetes-кластер.

В таких случаях приходят на помощь «мини-кластеры». Их можно запустить на рабочем ПК, «поиграться» с примитивами, построить новую структуру, а после завершения эксперимента — безвозвратно удалить (ведь это уже отработанный материал!).

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

Кому-то этот пост покажется запоздавшим, кому-то — очевидным. Однако общаясь с коллегами из QA-сообщества я продолжаю сталкиваться с тем, что удаленная работа вызывает кучу неудобств: количество чатов в мессенджерах зашкаливает, нельзя прийти ногами и объяснить все на пальцах или в деталях передать особенности окружения для воспроизведения бага, — хотя все уже давно было создано и внедрено.

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

ДИСКЛЕЙМЕР: На самом деле у каждого инструмента есть как минимум по несколько альтернатив, выбор из которых может привести к знатному холивару. Если у вас есть свои соображения на тему "автор дурак, надо было брать не Х, а Y", приходите в комментарии!

Три года назад в группе компаний ЦФТ задачи бизнеса потребовали увеличения штата разработчиков в два раза. Перед отделом эксплуатации встало две задачи: не допустить линейного роста OPS и уменьшить TTM, не потеряв при этом в недоступности, непрерывности и безопасности.

В результате в компании теперь есть всё — и NoOps, и DevOps. Где-то пришлось пойти на компромиссы и доработать концепт NoOps напильником под себя. Сергей Бердников, руководитель отдела эксплуатации, сегодня расскажет, что получилось, и разберет — почему.

Несколько больших нод или много маленьких?

Управление Kubernetes-кластером - это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь - это обеспечение стабильной и отказоустойчивой работы приложений.

Как site-reliability и DevOps инженерам вам нужно иметь в виду потребности приложений, которые будут запускаться в кластере, и учитывать различные факторы при его проектировании.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших - это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

Фото Ricardo Gomez Angel, Unsplash.com

Используем метрики для отправки уведомлений через Slack

В предыдущей статье мы задеплоили оператор Prometheus с помощью helm-чарта и на примере набора сервисов увидели, как можно собирать метрики через prom-client и экспортеры. Как вы помните, цель observability (наблюдаемости) — узнать статус системы, поэтому нужные люди должны получать уведомления, когда значения метрик выходят за установленные пределы. Для этого надо настроить алерты.

В интернете есть уже тысячи споров о том, чем является DevOps. Мы решили подойти иначе: не навязывать вам точку зрения «понимайте это слово так-то», а оглянуться в прошлое и проследить историю его возникновения. Что привело к появлению DevOps? Какие люди первыми стали употреблять это слово и что они под ним подразумевали? Что изменилось за это время, а что осталось неизменным? И что там дальше?

А разобравшись со всем этим, в итоге можно обнаружить, что теперь и на вопрос «что такое DevOps» отвечаешь себе более четко.

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

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

Всем привет! Меня зовут Илья, и я девопс. В 2020-м году я с женой и котом, после трех лет жизни на Кипре, решил перебраться в Испанию, а именно в Барселону. В этой статье я расскажу о своих впечатлениях от релокации, пока они свежи в памяти. В Барселоне мы уже почти год  и, сразу оговорюсь, о переезде мы не пожалели, хотя у нашего «кипрского периода» тоже были свои плюсы. Надеюсь, моя история окажется полезной для тех ИТ-инженеров, кто выбирает между Барселоной и Лимассолом, или задумывается о поиске возможностей в Европе. 

В этой статье мы поверхностно затронем сборку Java-приложений в GitLab CI, но сделаем так, чтобы в вашем merge request-е были отчёты о пройденных юнит-тестах и code coverage. А ещё мы соберём приложение при помощи образа с JDK, который тоже соберём сами.

На КДПВ шутка — а в тексте всё серьёзно.

Стажёрскую программу в Southbridge мы запустили три с половиной месяца назад, чтобы найти новых коллег и поделиться знаниями и опытом с теми, кому интересно развиваться в DevOps-направлении. За это время на стажировку было принято 54 начинающих инженера, большая часть из них ещё проходит программу. Первый поток завершен, в этом посте делимся итогами и историей Михаила Снеткова, который теперь работает в одной из команд Southbridge.

В первом потоке стажёрской программы участвовало девять специалистов. До конца дошло шесть. Михаил Снетков получил оффер в Southbridge, Александр Зольников — в Слёрм, еще три инженера получили офферы в другие компании во время стажировки.