Мониторинг бывает разный :) Наверняка, на этом канале собрались поклонники автоматизации, а она может касаться любых сфер жизни, в том числе и личной. Поэтому сегодня хотим затронуть тему самомониторинга как части жизни IT-специалиста ;)

В бесконечном потоке проектов и тасок повседневная жизнь, как система, тоже нуждается в мониторинге. С его помощью рутина может быть как минимум предсказуемой и как максимум ー стабильной. Ловите список подходов, которые помогут IT-специалисту в мониторинге рабочей и личной жизни.

✅ Трекинг рабочего времени
Помогает контролировать, на какие активности мы тратим время в течение дня. Например, RescueTime или Be Focused. В RescueTime можно гибко настраивать активности даже в бесплатной версии. Be Focused работает по принципу Pomodoro ー в нем можно декомпозировать задачи на временные отрезки.

✅ Привычки
Формат треккинга привычек может быть любым ー от банального блокнота до Things. Отслеживать (читай ー прививать) можно привычки как в личной жизни, так и в рабочей рутине. Если проведете такой эксперимент, сможете узнать, за сколько формируется привычка конкретно у вас.

✅ Физическая активность и здоровье
Начиная с банального ー сколько шагов вы прошли за день, и заканчивая контролем сна. Сюда можно добавить тренировки, изменение пульса в течение дня, расписание сна, контроль потребления воды, расход калорий и т.д. Приложений и девайсов предостаточно ー Sleepy Bot, MyFitnessPal, Garmin, Xiaomi Mi Band, Endomondo.

✅ Финансовое планирование
Неважно DevOps ты или бухгалтер, деньги уплывают незаметно практически у всех одинаково. Тут можно начать с банальных таблиц Excel или использовать специальные приложения ー JustMoney, Family12, Mobilis, Monefy, CoinKeeper. Не факт, что приложухи помогут сэкономить, но так вы хотя бы будете знать, куда сливается весь доход.

✅ Метод пустого инбокса
Всегда есть пул постоянно прилетающих задач, и не забыть их запланировать ー вот в чем вопрос. Можно использовать Things (методика GTD) или (откровение) Saved Messages в Telegram. Туда можно быстро отправлять задачи, а раз в неделю, к примеру, разбирать их и превращать в полноценные запланированные таски.

Надеемся, это простые советы помогут вам оптимизировать ваши жизненные процессы.

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

Контейнеризация служит для виртуализации и изоляции ресурсов на уровне ОС. Система контейнеризации является легковесной, и не использует ресурсы машины, на которой она разворачивается. Системные библиотеки и приложения запускаются в изолированной среде – стандартизированном контейнере, который не зависит от ресурсов и архитектуры гостевой ОС, на которой он работает. Каждое приложение функционирует в собственной среде, что обеспечивает изолированность процессов внутри каждого модуля.

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

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

Жми на 💥, чтобы узнать больше о преимуществах и недостатках контейнеризации.

Продолжаем тему контейнеров. Итак, какие их основные преимущества?

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

👍 Высокая производительность. Повышается производительность разработки – нивелируются межсетевые зависимости и конфликты. Каждый контейнер – это отдельный микросервис, который может обновляться независимо от других модулей.

👍 Переносимость образа. Контейнер собирает в себе все данные, например, зависимости программ, ОС для запуска. Контейнеры легко релоцировать между средами разработки, при этом есть возможность отслеживать версии и различия между ними.

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

👍 Безопасность. Образ и процессы каждого отдельного контейнера изолированы от других контейнеров и от базовой инфраструктуры. Благодаря этому обеспечивается полная безопасность при обновлениях или изменениях – то, что происходит с одним модулем, никак не касается других.

Ну и не обойдем вниманием недостатки контейнеризации – об этом расскажем в следующем посте.

Как и у любой технологии, у контейнеризации есть и свои недостатки.

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

👎 База Linux. Ввиду того, что большинство контейнеризаторов основаны на Linux, запуск контейнерных модулей и их работа в среде Microsoft усложняют работу. А учитывая, что контейнеры – относительно новая технология, придется покопаться, чтобы выяснить, как решить возникшие проблемы.

Почему контейнеры обогнали виртуальные машины? Увеличение мощностей серверов и необходимость разворачивать несколько приложений одновременно, при этом с разными настройками, стимулировало переход на контейнеры. Вы будете спокойны, когда в одном контейнере поднимаете Windows, в другом – Linux, и еще в одном – MacOS, и они друг друга не ломают.

В отличие от виртуальных машин, отдельные процессы в контейнере – очень компактные (например, Ubuntu-образ занимает 68Mb), быстро запускаются и более гибкие в настройке. И стоит упомянуть о том, что контейнер обеспечивает независимость среды. ВМ призвана подменить аппаратные возможности, а контейнер – выделяет программный объект из программной среды.

Вы запускаете программу на MacOS и описываете ее запуск, а потом делаете тоже самое на Windows – программы быстро перемещаются между серверами. Когда запускаем приложение на ВМ, запросы приложений будут идти по длинному пути из одной среды ОС в другую и обратно. Переход на контейнеризацию призван создать наиболее оптимальные условия для обработки объекта и отделить его от программной оболочки сервера.

Якщо ви ー новачок в IT та прагнете розвиватися у галузі, вам точно необхідно знати, що таке об'єктно-орієнтоване програмування. А ми якраз написали про це статтю у нашому блозі DevOps. Спойлер: про застосування ООП з різними мовами програмування теж не забули.

#devopsспросил_devopsответил
Конфигурации Jenkins: job и branch

Разберем пример: мы создаем отдельную job под отдельный branch. Почему не можем создать одну job, которая будет билдить несколько бранчей по mask? Например, в TeamCity есть возможность указывать бранч, делая конфигурацию source control, подкладывая branch под job. Получаем возможность мониторить появление бранчей по mask, можем разграничивать бранчи – некоторые билдятся под одной job, другие – под другой. Но почему в Jenkins одна job – одна branch, а не одна job – несколько branch?

В данном примере ответ скрыт в разных конфигурациях. В Jenkins можно сделать Discover Branch и билдить в одной бранче, например, только job с маской dev. Еще суть в том, что TeamCity – платное ПО, поэтому и настраивается там все гораздо проще. В Jenkins нужно все делать скриптами, например, под определенный скрипт подкладывается конкретный бранч. В Jenkins первоначальное значение имеет branch, а потом уже скрипт.

Будет ли при большом количестве бранчей (когда количество доходит до сотни) перегружен сервер? Навряд ли. При Discover Branch вы выбираете определенную mask – dev, prod и т.д. Например, мы планируем деплой с master – получается, что мы создаем multibranch pipeline deploy и отдельный jenkins-файл, и в данном случае будем деплоить только с master.

В Jenkins есть способ полностью автоматизировать шаги по конфигурированию plugins и jobs – можно менять мета-данные. Подкладываем .xml файл в volume, и он запускается на базе volume.

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

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

В DevOps часто используется архитектура микросервисов. Это подход к разработке, когда приложение состоит из набора небольших сервисов. У каждого из них свой процесс, и с другими сервисами он обменивается данными через детально продуманный интерфейс. Как правило, для обмена используется простой механизм: например, программный интерфейс на базе HTTP (API).

ОТВЕТ: Чтобы модули приложения могли работать отдельно друг от друга.

У каждого из них своя задача.
Более того, эти модули могут быть написаны на разных языках. Многие приложения, с которыми мы постоянно сталкиваемся: интернет-банки, YouTube, например — созданы с использованием множества технологий. Это и есть архитектура микросервисов.

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

#devops_tools
KubeScrape

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

Хорошее чтиво подвезли :)

Кристофер Александер «Язык шаблонов»

Больше тысячи страницы, читать можно год, но оно того стоит! Must-have для всех, кто связан с разработкой, проектированием, архитектурой в айти. Книгу можно использовать как справочник ー там много про паттерны, принципы и подходы в проектировании и архитектуре, которые можно перенести на любой проект.

Взгляд на концепции Service Level Objectives и Service Level Indicators на примере Instana
В статье идет речь о показателях работы сервиса, связанных с удовлетворенностью пользователей и производительностью программы. Автор пишет о двух показателях ー Service Level Indicator (SLI) и Service Level Objectives (SLO), рассказывает, как их внедрить в проект и на примере инструмента Instana показывает, как контролировать метрики.

Мабуть, немає людини з IT, яка б не чула про Git. Це місце, де зберігається найцінніше будь-якого проєкту розробки ー його величність код. Зручна, легка та відкрита платформа для роботи з репозиторіями дає можливість відстежити будь-яку точку в історії проєкту. Саме про роботу з цими спеціальними відмітками (Git Tags) розповідаємо у нашій статті.

Llama — еще один terminal file manager?
Легкий и минималистичный, с быстрой навигацией по файловой системе. Легкая интеграция cd & ls. А еще из llama можно запускать vim.

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

#devops_tools grimd
Скоростной dns proxy, который запускается где угодно. Блокирует Интернет-рекламу и вредоносные серверы.

Всім привіт 💛💙

17-18 травня наші друзі з DevOps ком’юніті та команда DevOpsDays Kyiv роблять велику міжнародну благодійну онлайн конференцію DevOpsDays #StandWithUkraine.

Будуть говорити про DevOps in crisis з Patrick Debois, Kelsey Hightower, Martin Woodward, Kris Nova, Lena Hall, Andrew Clay Shafer та українськими спікерами – Олегом Миколайченко, Володимиром Цапом та Антоном Бабенко.

Після доповідей буде Open Space Discussions, де планують обговорити теми, які оберуть самі учасники.

Також цей івент має й масштабну благодійну мету – зібрати €100 000 на допомогу Україні та передати трастовим благодійним фондам – дуже віримо в те, що робимо!

Обов’язково розкажіть про івент своїм DevOps друзям та знайомим з усього світу. Запрошуємо до реєстрації. До зустрічі на DevOpsDays #StandWithUkraine! 👋