Очередная статья в серии «Инструменты мониторинга Logicify» рассказывает о Grafana. Это программное средство мы используем для визуализации и анализа данных как внутренних, так и внешних проектов. Статья может быть полезна техническим директорам, разработчикам, DevOps, системным администраторам, менеджерам проектов, а также всем заинтересованным лицам.
Вот и наступила осенне-зимняя пора. За окном дожди и желания проводить время на открытом воздухе все меньше и меньше. И вот приходит мне сообщение от товарища "А давай поиграем в Lineage 2?". И опять я, поддавшись ностальгии, согласился. Выбрали мы свеженький сервер на ру-офе и создали персонажей.
В отличии от World of Warcraft в Lineage 2 совершенно другая система добычи игровой валюты. Нужно круглыми сутками охотиться на монстров с целью получения наживы. Для меня было даже открытием, что для некоторых людей RMT (Real money trading) является чем то вроде работы. Также, в игре присутствует экономика, которую формируют игроки. Иными словами, можно заработать на купи-продай или же покупать дешевые ресурсы, из них делать вещи и продавать с наценкой. Так как для нас игра остается чем то вроде отдыха именно такой способ получения игровой валюты был выбран нами.
Чтобы покупать и продавать предметы игрок должен находиться online (Скриншот сверху). Соответсвенно, кто-то хочет побыстрее продать (дешевле) а кто-то побыстрее купить (дороже). А что если разница продать — купить положительная? Как раз этот пример и будет рассмотрен в статье как итог.
Однако, цены на рынке достаточно нестабильны и часто меняются. По этому существует вероятность купить что то "дешево" и потом еще дешевле продать и отрицательной прибылью. Этого мы и стараемся избежать. В общем было решено написать систему аналитики рынка и разобраться с парочкой интересных мне технологий.
Spoiler:
В статье будут использованы следующие технологии
Docker, DigitalOcean, NodeJs, Ktor, Prometheus, Grafana, Telegram bot notification
И снова здравствуйте!
Представляем вам открытый урок курса «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, поэтому думаю, что могу рассказать о нём достаточно для того, чтобы начать пользоваться.
В последнем посте я рассказывал о 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 — прим. перев.), работу с сетью.Читать полностью »
Любой компании, разрабатывающей софт, нужны тестовые среды, приближенные к продакшн-окружению. Особенно это актуально для коробочного ПО, у которого длинный цикл релизов.
Многие проблемы построения тестовых сред решает их размещение в облаке. Мы расскажем про возможности тестирования на нашей облачной платформе Mail.Ru Cloud Solutions (MCS). Но часть из того, что мы расскажем, верна для любого облака.
Читать полностью »
