DevOps *

Прим. перев.: Этой статьёй, написанной Scott Rahner — инженером в Dow Jones, мы продолжаем цикл многочисленных материалов, доступно рассказывающих о том, как устроен Kubernetes, как работают, взаимосвязаны и используются его базовые компоненты. На сей раз это практическая заметка с примером кода для создания хука в Kubernetes, демонстрируемого автором «под предлогом» автоматического создания sidecar-контейнеров.


(Автор фото — Gordon A. Maxwell, найдено на просторах интернета.)

Когда я начал изучать sidecar-контейнеры и service mesh'и, мне потребовалось разобраться в том, как работает ключевой механизм — автоматическая вставка sidecar-контейнера. Ведь в случае использования систем вроде Istio или Consul, при деплое контейнера с приложением внезапно в его pod'е появляется и уже настроенный контейнер Envoy (схожая ситуация происходит и у Conduit, о котором мы писали в начале года — прим. перев.). Что? Как? Так начались мои исследования…

Всем добрый вечер!

Вот и осталось всего ничего (то есть один день) до запуска потока курса «DevOps практики и инструменты», а значит нам надо успеть за это время довыложить оставшиеся части статьи «Почему важна SRE документация».

Продолжаем.

Документы для Онбординга Нового Сервиса

SRE проводят PRR (production readiness review, обзор готовности производства) для проверки соответствия сервиса стандартам операционной готовности, а также чтобы убедиться, что владельцы сервиса понимают, как пользоваться знаниями SRE для управления большими системами.

Сервису необходимо пройти эту проверку до запуска в продакшн. (До запуска его поддерживают не SRE, а сама команда разработки.) Цель PRR на данном этапе — убедиться, что сервис будет удовлетворять минимальным стандартам надежности на момент запуска.

Каждый раз, когда приходится читать про очередного новорожденного убийцу айфона или фейсбука, невольно начинаешь улыбаться. За эти годы столько их уже было, а воз и ныне там. Поэтому, наткнувшись на очередную публикацию, где ключевой мыслью была идея о том, что наступающая эпоха бессерверных вычислений приложений (Serverless) «съест» DevOps, скепсису не было предела.

С приходом .Net Core у нас появилась прекрасная возможность не только запускать наш код на разных ОС, но и тестировать его на разных ОС. А что может быть лучше Docker при работе с разными ОС?

Привет, друзья. Так как мы сами активно используем OpenStack, то решили позвать к себе в гости других адептов технологии на @OpenStack Meetup, который мы делаем совместно с российским сообществом OpenStack.

Встреча пройдет 30 ноября (пятница) в 19:00 в московском офисе Mail.Ru Group (Ленинградский проспект, д. 39, стр. 79).

Приглашаем всех, кто работает с OpenStack и кого интересуют особенности платформы. Среди спикеров – «Яндекс.Деньги», Canonical и Mail.Ru Group. Начнет встречу амбассадор OpenStack в России Илья Алексеев, который поделится с гостями новостями недавнего OpenStack Summit в Берлине.

Регистрация обязательна и закрывается 28 ноября в 23:59 (или раньше, если закончатся места).

Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.

Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.

Очередная статья в серии «Инструменты мониторинга Logicify» рассказывает о Grafana. Это программное средство мы используем для визуализации и анализа данных как внутренних, так и внешних проектов. Статья может быть полезна техническим директорам, разработчикам, DevOps, системным администраторам, менеджерам проектов, а также всем заинтересованным лицам.

После выделения DevOps внутри компании «Неофлекс» в отдельное бизнес-направление команда стала активно наращивать экспертизу и делиться найденными источниками знаний друг с другом. В этом посте я поделюсь с вами личным опытом погружения в тему и наиболее интересными ресурсами.

Основными источниками информации по теме стали следующие:

• Интернет-ресурсы – как независимые, так и компаний разработчиков
• Статьи и презентации
• Литература
• Конференции
• Программы обучения – как платные, так и бесплатные

Вот и наступила осенне-зимняя пора. За окном дожди и желания проводить время на открытом воздухе все меньше и меньше. И вот приходит мне сообщение от товарища "А давай поиграем в Lineage 2?". И опять я, поддавшись ностальгии, согласился. Выбрали мы свеженький сервер на ру-офе и создали персонажей.

 
В отличии от World of Warcraft в Lineage 2 совершенно другая система добычи игровой валюты. Нужно круглыми сутками охотиться на монстров с целью получения наживы. Для меня было даже открытием, что для некоторых людей RMT (Real money trading) является чем то вроде работы. Также, в игре присутствует экономика, которую формируют игроки. Иными словами, можно заработать на купи-продай или же покупать дешевые ресурсы, из них делать вещи и продавать с наценкой. Так как для нас игра остается чем то вроде отдыха именно такой способ получения игровой валюты был выбран нами.

Чтобы покупать и продавать предметы игрок должен находиться online (Скриншот сверху). Соответсвенно, кто-то хочет побыстрее продать (дешевле) а кто-то побыстрее купить (дороже). А что если разница продать — купить положительная? Как раз этот пример и будет рассмотрен в статье как итог.

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

Spoiler:
В статье будут использованы следующие технологии
Docker, DigitalOcean, NodeJs, Ktor, Prometheus, Grafana, Telegram bot notification

[часть 2 из 2]

[часть 1 из 2]

Как нам это удалось

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

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

И снова здравствуйте!

Представляем вам открытый урок курса «DevOps практики и инструменты» на тему «Инфраструктура как код». Игорь Курочкин, преподаватель курса, на пример этой практики рассказывает как можно улучшить взаимодействие команд, ускорить процесс поставки ПО и снизить количество ошибок и показывает основные практики и инструменты для разработки инфраструктурного кода.


Если есть вопросы и комментарии можете оставить их тут или зайти на день открытых дверей и пообщаться с преподавателями курса там.

Всем привет!

Мы допечатали книгу «Философия DevOps», а также планируем делать и новую книгу на эту тему.


Немало копий сломано по поводу того, чем является и чем не является DevOps, а также о соотношении DevOps и непрерывной интеграции. Поэтому мы просим вас максимально объективно высказаться, разделяете ли вы точку зрения сегодняшнего автора Адама Маккея (Adam Mackay) относительно сути DevOps — либо, на ваш взгляд, предложенная им картина в чем-то неполна или ангажирована?

Читаем и комментируем!

Прим. перев.: Мы написали уже не одну публикацию (см. ссылки в конце статьи) об исполняемых средах контейнеров (container runtimes) — речь в них, как правило, идёт в контексте Kubernetes. Однако зачастую эти материалы вызывали у читателей вопросы, свидетельствующие о недостаточном понимании, откуда взялся очередной проект, как он связан с другими и что вообще происходит во всём этом контейнерном «зоопарке».



Недавняя статья от технического директора подразделения IBM Watson & Cloud Platform по стратегии в области контейнеров и архитектуры Linux — Phil Estes — предлагает отличную ретроспективу и помогает сориентироваться, получить более обширное понимание тем, кто потерял (или так и не уловил) нить событий. Будучи одним из мейнтейнеров проекта Moby и containerd, членом технических комитетов Open Container Initiative (OCI) и Moby, а также обладая статусом Docker Captain, автор пишет о прошлом, настоящем и будущем нового дивного мира container runtimes. И для самых ленивых материал начинается с компактного TL;DR по теме…

Удивительно, на на хабре до сих пор нет поста о такой, весьма интересной, замене шеллу как xonsh (github), с моей точки зрения синтаксис всяких shell'ов ужасен и не вижу никаких оснований сохранять его в 21 веке, а Python, в свою очередь, обладает прекрасным синтаксисом и массой других преимуществ, поэтому, на мой взгляд, он и должен быть языком автоматизации по умолчанию, чего и пытаеся достичь xonsh.

Какое-то время использую xonsh, поэтому думаю, что могу рассказать о нём достаточно для того, чтобы начать пользоваться.

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

Цель данной статьи — показать простую технику настройки стенда на несколько веток. Данная статья написана разработчикам от разработчика, поэтому вряд ли будет представлять существенный интерес для профессиональных DevOps инженеров.

В последнем посте я рассказывал о Kubernetes, о том, как ThoughtSpot использует его для собственных нужд по поддержке разработки. Сегодня хотелось бы продолжить разговор о короткой, но от того не менее интересной истории отладки, которая произошла совсем недавно. Статья базируется на том, что containerization != virtualization. К тому же наглядно показывается, как контейнеризированные процессы конкурируют за ресурсы даже при оптимальных ограничениях по cgroup и высокой производительности машины.

Всем добрый вечер!

Интенсивность запусков у нас меняется от месяца к месяцу. Не успели сентябрьские студенты закончить второй месяц курса «Devops — практики и инструменты», как у нас открывается следующий поток. Так что мы снова готовы делиться с вами полезными материалами по теме и ждём на не менее полезных открытых уроках.

Сегодня мы рассмотрим первую часть статьи о том как документация позволяет SRE-командам управлять новыми и существующими сервисами.

SRE (site reliability engineering, примерно переводится как “обеспечение надежности информационных систем”, специалисты этой сферы носят ту же аббревиатуру) — особая дисциплина, мышление и набор технических подходов, направленных на обеспечение безотказной работы веб-продуктов и сервисов. SRE находятся на стыке разработки ПО и системной инженерии, решают эксплуатационные задачи и разрабатывают масштабируемые, надежные и эффективные решения для проектирования, создания и эксплуатации крупномасштабных распределенных систем.

Основные задачи SRE:

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



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

Pods (Поды) — базовые строительные блоки Kubernetes, однако даже опытные пользователи Kubernetes не всегда могут объяснить, что же это такое.

Данная публикация предлагает лаконичную мысленную модель, которая проливает свет на определяющие характеристики pod'ов Kubernetes. Ради этой краткости пришлось опустить некоторые другие особенности Pod'ов, такие как liveness и readiness probes, разделение ресурсов (включая появившееся недавно namespace sharing — прим. перев.), работу с сетью.

Helm без хайпа. Трезвый взгляд

Helm — это менеджер пакетов для Kubernetes.

На первый взгляд, неплохо. Этот инструмент значительно упрощает процесс релиза, но порой может и хлопот доставить, ничего не попишешь!

Мы уже писали о «консольных помощниках» для Kubernetes год назад, а ещё раньше делали обзор других полезных утилит. Однако с развитием K8s и его сообщества претерпевает изменения и сопутствующая экосистема. Поэтому нам снова есть о чём рассказать любителям консоли. Поехали!