Популярная сегодня методология разработки программного обеспечения DevOps (development и operations) нацелена на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию. Характерно, что в ходе DevOps генерируются большие объемы данных, которые можно использовать для упрощения рабочих процессов, оркестрации, мониторинга, диагностики неисправностей или других задач. Проблема в том, что данных этих слишком много. Одни только серверные логи могут накапливать несколько сотен мегабайт в неделю. Если используются инструменты мониторинга, то за короткий промежуток времени генерируются мегабайты и гигабайты данных.

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

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

Вместе с большим количеством кода появляется и старая, знакомая проблема: страх изменений. Люди не желают вносить изменения в «чужую» роль, опасаясь испортить её, вместо этого создают собственную копию. Рефакторинг кода не производится, если код прямо сейчас не находится в фокусе разработки, из-за опасения, что внесённые проблемы могут быть обнаружены спустя слишком большое время. Итог: плохой код растёт как снежный ком.

В начале этого года мы посчитали, что наша Open Source-утилита для сопровождения процессов CI/CD — dapp версии 0.25 — обладает достаточным набором функций и была начата работа над нововведениями. В версии 0.26 появился синтаксис YAML, а Ruby DSL был объявлен классическим (далее перестанет поддерживаться вовсе). В следующей версии, 0.27, основным нововведением можно считать появление сборщика с Ansible. Пришло время рассказать об этих новинках подробнее.

Обновлено 13 августа 2019 г.: в настоящее время проект dapp переименован в werf, его код переписан на Go, а документация значительно улучшена.

Abstract: как заставить себя изучить любую из существующих систем конфигураций и перестать редактировать файлы на сервере руками.

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

Введение для отшельников, которые не слышали что такое configuration management systems

Уже многие годы (по айтишным меркам — три поколения как) существуют программы, которые позволяют автоматизировать процесс конфигурации серверов. Все эти программы сложные, они вторгаются в святую святых администраторов и заставляют их делать "всё не так, как раньше". Их изучение и интернализация (признание, что "так надо и так правильно") — абсолютный must have в карьере любого системного администратора.

Главная боль любой системы управления конфигурациями

Главная боль состоит в том, что система управления конфигурациями ломает привычную автоматику пальцев. Раньше вы могли поднять веб-сервер за 2 минуты почти не глядя на экран. Теперь вам предлагают потратить на абсолютно те же самые действия минут 15-20 (если вы хорошо знаете систему управления конфигурациями) или даже несколько дней (!!!!!), если вы её изучаете.

Это преступление против личной эффективности. Уменьшить её в десять (0xA) раз — и это они называют прогрессом?

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

Последний год Hyperpilot работал в скрытом режиме, поэтому позвольте объяснить, что мы собирались делать. Наша миссия – дать интеллект инфраструктуре, чтобы увеличить эффективность и производительность. DevOps и системные инженеры постоянно сталкиваются с необходимостью принимать множество решений, связанных с контейнерной инфраструктурой и процессами, требующими ручной работы. Эти решения включают в себя весь путь от конфигурации виртуальных машин (тип инстанса, регион и т.д.), конфигурации контейнеров (запрос ресурсов, количество экземпляров контейнера и т.д.) до вариантов конфигурации уровня приложения (jvm и т.д). Операторы и разработчики часто делают статический выбор, и эксплуатационный персонал понятия не имеет, почему было принято такое решение. Хуже всего, что операторы склонны к переусердствованию, а это приводит к неэффективному использованию инфраструктуры. Мы работали над тремя продуктами, которые могли бы помочь операторам находить инструменты для лучших решений и автоматизации рекомендаций в будущем. Далее я расскажу о высокоуровневых продуктах, находящихся в открытом доступе.

“Нам есть, что рассказать миру о белорусском DevOps,”– говорили они. “Инфраструктура тестирования меняется и скоро произойдет перелом. Нам нужна площадка для общения с правильными практиками,” – говорили они. Они говорили – они сделали Delex. А еще 300+ человек пришли, чтобы послушать доклады, познакомиться и стать свидетелями рождения нового технологического комьюнити. Были там и EPAMеры: состояли в программном комитете, читали доклады и представляли новые разработки.

Мы запускаем новое направление Университетов DataLine — семинары по поддержке интернет-проектов и взаимодействию разработки и эксплуатации.

Новым будет и формат — теперь мы будем вести онлайн-трансляции со всех наших семинаров!

Дата: 22 марта в Москве.
Тема: «Разработка vs Эксплуатация. Почему ни Agile, ни DevOps – это не волшебная пилюля, и как с этим жить.»
Ведущий курса: Алексей Приставко, директор по веб-проектам DataLine.

Осталось всего несколько мест, будем рады видеть ИТ-директоров, руководителей и инженеров команд разработки и эксплуатации, менеджеров и руководителей веб-проектов и всех тех, кто отвечает за производительность и работу крупных сайтов.

Прим. перев.: Автор статьи — Amanpreet Singh — называет себя «всё ещё начинающим в мире сетей», однако именно это и побудило его разобраться в их базовом устройстве в Kubernetes (который он использует в production), а затем — поделиться с сообществом очень доступным материалом с наглядными иллюстрациями. В оригинале он разбит на две части, однако в этом переводе мы объединили их в одну статью.



Вот вы запустили множество сервисов в кластере Kubernetes и пожинаете плоды… или хотя бы собираетесь это сделать. Однако, даже несмотря на существование ряда утилит для настройки кластера и управления им, вам всё же интересно, как всё работает «под капотом». Куда смотреть, если что-то сломается? По себе знаю, что это важно.

В нашей прошлой статье мы рассказали о том как строили централизованный конвейер, но описали его довольно поверхностно. Это породило массу вопросов, которые мы не можем оставить без ответа. Здесь мы попробуем максимально глубоко залезть «под капот» и рассказать, как работает наш централизованный конвейер.

8 марта фонд CNCF, созданный при The Linux Foundation, представил значительно обновлённую версию своей «карты ранее неизведанной территории облачных (cloud native) технологий» — Cloud Native Landscape 2.0. Собранная в рамках этого проекта информация ориентирована на компании, которые только начинают свой путь в мир инфраструктуры для cloud native-приложений, и призвана познакомить их с множеством имеющихся решений с открытым исходным кодом и не только.

То, о чем я хочу рассказать, началось 30 декабря 2010 года, когда компания Etsy выложила на GitHub первый коммит своей системы StatsD. Эта, сейчас уже, суперпопулярная система, написанная на JavaScript (хипстеры ликуют), в которую можно отправлять метрики, замеры исполнения кусков вашего кода, а она их агрегирует и отправляет уже агрегированными в систему хранения time-series.



На фоне популярности StatsD и других time-series систем появилась идея «Monitor Everything»: чем больше различных вещей в системе измеряется, тем лучше, потому что в случае неожиданной ситуации будет возможно найти нужную, уже собранную метрику, которая позволит во всем разобраться.

Давайте вообще все, что можно, мониторить — и будет классно!

Но как часто бывает с любой модной технологией, которая изначально сделана с некоторыми ограничениями, при начале использования люди не очень задумываются об этих ограничениях, а делают как написано, как придется.

И так получилось, что есть много проблем со всем этим, про которые, собственно, нам и расскажет Павел Труханов ( tru_pablo ).

От переводчика:
Это перевод статьи Container runtimes Part 1: An Introduction to Container runtimes.
Автор оригинальной публикации: Ian Lewis.

Один из терминов, который вы часто слышите, имея дело с контейнерами — «container runtime» (далее «runtime» переводится как «среда запуска» — прим. переводчика). «Среда запуска контейнеров» может иметь различные значения для разных людей, так что нет ничего удивительного в том, что это такой сбивающий с толку и смутно понятный термин, даже в самом сообществе пользователей и разработчиков Docker.

Этот пост — первый в серии, которая состоит из 4 частей:

1. Часть 1: Введение в среды запуска контейнеров: почему они так сбивают с толку?
2. Часть 2: Глубокое погружение в низкоуровневые среды запуска (eng)
3. Часть 3: Глубокое погружение в высокоуровневые среды запуска
4. Часть 4: Среды запуска в Kubernetes и CRI

Этот пост объяснит что такое среды запуска контейнеров и откуда столько недопонимания. После этого я углублюсь в различные типы сред запуска контейнеров, что они делают и как они отличаются друг от друга.


(На картинке игра слов: Не уверен относится ли это к средам запуска Kubernetes контейнера, низкоуровневой среде запуска контейнера или продолжительности фильма — примечание переводчика)

Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.

За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь "инфраструктура" — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.

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

У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.

Краткое руководство по началу работы, которое вы ищете.

Если вы следовали тенденциям развития программного обеспечения в прошлом году, то, должно быть, устали слышать термин Docker. Вероятнее всего, вы ошеломлены огромным количеством разработчиков, говорящих о контейнерах, изолированных виртуальных машинах, супервизорах и другой магии Вуду, связанной с DevOps. Сегодня мы во всем разберемся. Пора наконец понять, что такое контейнеры как услуга и зачем они нужны.

Здравствуйте, уважаемые хабравчане! Сегодня я хотел бы рассказать о том, как «скормить» Java-приложение докеру, как при этом лучше действовать, а чего делать не стоит. Я занимаюсь разработкой на Java более 10 лет, и последние года три провёл в самом тесном общении с Docker, так что у меня сложилось определённое представление о том, что он может и чего не может. Но ведь гипотезы надо проверять на практике, не так ли?

Я представил весь процесс как старую добрую компьютерную игру с тёплым ламповым пиксель-артом.

Начнем мы, как и полагается любой игре, с некоторого брифинга. В качестве вводной возьмем немного рекламы докера.

На сайте докера можно ознакомиться с рядом рекламных посулов – а именно, с обещанием увеличить скорость разработки и развертывания аж в 13 раз и повысить портативность в разработке (в частности, избавиться о сакраментального «работает на моей машине»). Но соответствует ли это реальности?

Сейчас мы попробуем доказать/опровергнуть эти утверждения.

Развитие сложной ИТ-инфраструктуры китайской компании Huawei, насчитывающей более 180 тысяч сотрудников, привело к новым вызовам и требованиям, ответом на которые стало создание PaaS, основанной на Kubernetes и Docker. Внутреннее применение новой платформы не просто отлично зарекомендовало себя, но и продемонстрировало реальную заинтересованность извне — со стороны заказчиков Huawei. Так, используя Open Source-продукты и свой обширный enterprise-опыт, компания сумела закрыть внутренние потребности, предложить конкурентные услуги на рынке и помочь сообществу с разработкой важных проектов.

Docker начиная с версии 17.05 и выше стал поддерживать многоэтапные сборки (multi-stage builds). С удивлением обнаружил, что никто еще не написал об этом на хабре. Поэтому давайте исправим этот пробел.

Предисловие

Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…

Что такое DevOps

Согласно википедии DevOps набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Т.е. это попытка масштабировать Agile весь процесс разработки ПО включая внедрение и сопровождение. Основное назначение DevOps-а — увеличение частоты релизов и повышение ответственности команды за продукт. Звучит идеально… как и любые маркетинговые слоганы…

С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).

Наверняка не все знают, что по нагрузке и числу пользователей iFunny является настоящим highload-сервисом. API обслуживает в пиках порядка 15000 запросов в секунду, система аналитики обрабатывает около 5 миллиардов событий в сутки, а для поддержки полного функционала работает до 400 инстансов EC2. Поэтому для приложения очень важно иметь сильную команду инженеров. Чтобы решать типичные проблемы высоконагруженных систем и улучшать свою работу каждый день, команда iFunny постоянно ищет новые инструменты и решения. И в этот раз невозможно было пройти мимо интервью одного из основных контрибьюторов мирового IT-сообщества — Келси Хайтауэра. Достойно перевода и вашего внимания.

Добрый день!

Все чаще стучась в различные компании разработчиков в качестве DevOps инженера, я получаю приблизительно одни и те же тестовые задания. Они отличаются друг от друга версиями PHP или проектами которые надо запустить.

Но в целом они упираются в одну связку это Nginx\Appache, SQL (тут вариаций много, все зависит от предпочтений заказчика), PHP и желательно чтобы это было разложено по контейнерам.
Поэтому я решил рассказать на примере, как все это поднять без особых усилий.

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

В данной статье, мы подготовим небольшую структуру:

• В качестве вэб сервера будет использоваться Nginx с минимальной настройкой для запуска проекта.
• В качестве SQL будет использовать MySQL.
• PHP7.0-fpm версия c небольшими надстройками для запуска нашего проекта.
• В качестве проекта который мы будем разворачивать — берем magento2.