DevOps *

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

Последний год 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.

Мы продолжаем наш путь к Continuous Delivery (CD) и High Availability (HA), основанной на избыточности. В предыдущей серии мы перевели API для мобильного приложения на .NET Core. Следующий логичный шаг для достижения CD — настроить сборку в Docker-контейнер.

Сегодня поделимся нашим getting-started гайдом по настройке сборки docker-образов и деплоя в Kubernetes в TFS для разработчиков .NET.

(Предполагается, что к этому моменту вы уже мигрировали ваше ASP.NET приложение на ASP.NET Core, а если нет, читайте нашу прошлую статью).

В конце прошлого года компания Buoyant, уже прославившаяся выпуском одного из популярнейших решений категории service mesh (т.е. «сетки», обеспечивающей взаимодействие между сервисами) — Linkerd, — анонсировала своё второе детище под названием Conduit. Можно было бы удивиться, что новый продукт — это ещё один service mesh с открытым кодом, но есть тому причины.

Однажды в одно прекрасное утро перед нами встал вопрос архивирования индексов Elasticsearch. Захотелось увидеть в хранилище стройные ряды сжатых файлов, по одному на каждый индекс.

«Из коробки» Elastic такого решения не предлагает, по крайней мере, в версии 5.х. Немного поспрашивав у Гугла Всемогущего, мы решили создать собственный велосипед. Пусть немного неуклюжий, зато родной.

С того момента как мы начали вести корп. блог на Хабре, на демо и при обращениях в поддержку нас стали чаще сравнивать с оркестраторами. И если раньше были вопросы о том, в чем отличия D2C от Heroku, Clou66 и тому подобных сервисов, то теперь, видимо, нас стали рассматривать как альтернативное решение для оркестрации.

Чтож, попробую поправить ситуацию и провести сравнение с несколькими популярными решениями, о которых слышно чаще: Docker swarm, Kubernetes и Rancher. А чтобы зайти не «с конца», кратко дам по маленькому обзору на каждую из них.